Geek projects, tidbits and things I'm working on at the moment…

So I’ve expanded my SCST compiles onto other Linux OSes namely Fedora 14 & Red Hat 6.0 and I’ve come across another issue when attempting to get the modified kernel to compile, namely it doesn’t pass the precompile check and never fully assembles into a binary! This one took me a while to figure out but thankfully Google provides for those that seek…

The errors I was seeing were similar to below:

linux/X64/usr/include/drm/drm_mode.h:85: found __[us]{8,16,32,64} type without #include

linux/X64/usr/include/drm/i915_drm.h:120: found __[us]{8,16,32,64} type without #include

linux/X64/usr/include/drm/mga_drm.h:260: found __[us]{8,16,32,64} type without #include

linux/X64/usr/include/drm/radeon_drm.h:758: found __[us]{8,16,32,64} type without #include

linux/X64/usr/include/drm/via_drm.h:117: found __[us]{8,16,32,64} type without #include

linux/X64/usr/include/scsi/scsi_netlink.h:108: found __[us]{8,16,32,64} type without #include

linux/X64/usr/include/linux/resource.h:49: found __[us]{8,16,32,64} type without #include

Essentially a precompiler option #include was messing things up. Thankfully someone over on kernel.org found it and knew what to do about it. You’ve got to do your make menuconfig, make your new .config file then edit it w/ vi. Search for a line stating CONFIG_HEADERS_CHECK=y and make it =n instead.

After that it was smooth sailing and the kernel compiled just fine on Red Hat 6.0 & Fedora 14. I eventually had another problem w/ Fedora 14 down the road but installing redhat-lsb via yum solved that problem (had to do w/ the initial functions that are included in Linux Standard Base!)

Here’s the link I found regarding the compile issue:

https://patchwork.kernel.org/patch/274141/

I’m currently working on building my own iSCSI SAN w/ SCST & a modified Linux kernel. Things are going pretty well but I needed to also bond out the 5 Gb nics so my VMHosts can maximize their connections. In Linux, you bond out an interface by creating a new network interface and telling the physical nics to register w/ that virtual network interface. There’s also 7 different types of bonding modes but the most common one is mode 6 or balance-ALB (active load balancing.)

If you’re using CentOS or RHEL like I am you cd to /etc/sysconfig/network-scripts/ and vi ifcfg-bond0.

Once you’ve got vi open, you dump the following in (this is an example only. Please change your IPADDR, NETMASK and NETWORK parameters as needed.)

DEVICE=bond0
BOOTPROTO=none
ONBOOT=yes
NETWORK=10.0.0.0
NETMASK=255.255.0.0
IPADDR=10.0.0.100
USERCTL=no

From there, you then modify your individual eth# interface config files so they point to the bonded device. As an example, here’s my /etc/sysconfig/network-scripts/ifcfg-eth0 interface file.

DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no

And oh ya, don’t forget to modify your modprobe.conf file to specify the loading of the bond kernel module and what options it will needed @ run-time.

alias bond0 bonding 
options bond0 mode=6 miimon=100

Couple of useful links. There’s tons of good info on bonding w/ Linux. Keep in mind, some distros don’t want you to modify the individual interface config files so use their administrator control panel first if possible.

http://www.how2centos.com/how-to-set-up-network-bonding-with-centos-5x/
http://www.howtoforge.com/network_card_bonding_centos

I’m a real big fan of nVidia’s Linux drivers for their GPUs and have installed them numerous times with CentOS 5. I just recently installed them under Red hat 6 (RHEL 6) and happened to notice a warning by the nVidia driver that Nouveau was already installed and needed to be removed first. Further investigation reveals that Fedora & the latest version of RHEL 6 are including Nouveau at the initial ramdisk so not only do you need to create your own modprobe.conf blacklist file but you also need to add a line on the end of your grub.conf file to tell the ramdisk not to load Nouveau at boot up.

First, creating a modprobe blacklist file to prevent the kernel from loading the Nouveau kernel module. You could easily add blacklist nouveau to any ole modprobe.conf file but you never know when your linux distribution may overwrite your modified file w/ the next update. You’re better off to just create your own modprobe blacklist file and dropping it inside /etc/modprobe.d/ folder. I went ahead and followed some directions I stumbled upon on the interwebs and created a file called /etc/modprobe.d/disable-nouveau.conf.

I then added the following to that file…

blacklist nouveau options nouveau modeset=0

Once that was done, I then needed to modify my /etc/grub.conffile so the initial ramdisk would stop loading Nouveau too. To do this I added rdblacklist=nouveauto my kernel vmlinuz line like such…

.
.
.
kernel /vmlinuz-2.6.32-71.14.1.el6.x86_64 ro root=UUID=209502fb-f4f0-4755-a275-de807916fb76 rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us crashkernel=128M rhgb rdblacklist=nouveau
.
.
.
.

Oh ya, I always remove the “quiet” at the end of the line too. Something about watching all of the modules load…

Here’s a couple links as usual:

http://us.download.nvidia.com/XFree86/Linux-x86_64/260.19.36/README/commonproblems.html
http://www.if-not-true-then-false.com/2009/howto-install-nvidia-driver-on-fedora-and-just-disable-the-nouveau-driver/

I’m in the process of building up a SAN from scratch using SCST & CentOS. I’ve played around w/ kernels in the past but hadn’t done it in a while. When downloading 2.6.36.2 from Kernel.org recently I couldn’t get a bootable kernel no matter what I did w/ CentOS (and yes, I did load the CentOS .config file into menuconfig before compiling my kernel.)

  Come to find out, because CentOS is using a modified 2.6.18 kernel that little .config file is very out dated. As of kernel 2.6.31 a new kernel parameter is available called “enable deprecated sysfs features to support old userspace tools” which is under the General setup area. Once I enabled that option, I was good to go. It has something to do with why my SAS RAID card wasn’t getting picked up upon boot up. Everything else after that was a piece of cake!

You could have also just added this to your .config file. (NOTE: Hats off to Vanecka!)
CONFIG_SYSFS_DEPRECATED_V2=y

Couple Kernel compile links for CentOS 5:

http://wiki.centos.org/HowTos/Custom_Kernel  (official CentOS wiki kernel build page)
http://www.howtoforge.com/kernel_compilation_centos_p2  (HowtoForge article)
http://kerneltrap.org/node/1783 (Old kernel trap article which mentions the use of -j8 for make parameters so you’ll use all of your cores on compiles! I did a ‘make -j8 all’ and finished my kernel compile in under 5 minutes on a Xenon E5620 CPU!)
http://www.linuxfromscratch.org/lfs/view/6.4/chapter08/kernel.html (LFS link on kernel compile)

I’ve used both CDs personally countless times and can’t recommend them enough. If you’re just looking to reset your administrator password to blank or need to move data off the system’s hard disk these CDs will help greatly. I’m always forgetting the acronyms so I decided to write them down for once. I typically carry UBCD w/ me at all times.

Couple quick links to the prospective websites…

http://www.prime-expert.com/ebcd/

We were having some issues at work w/ a profile migration when a user got a new laptop. During my “Googling” I happened to stumble upon how to change the users profile path via the registry which can be useful. The following registry location is still valid for Windows 7 which is good news.

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

One thing to keep in mind, you’ll need to assign ownership of the users profile w/ full permissions so things don’t get messed up upon reboots or when that user tries to login!

Original link:
http://msmvps.com/blogs/clustering/archive/2004/10/06/15096.aspx

  One of my relatives, whom I’m hosting a WordPress site for, recently forgot their administrator password and couldn’t get into their WordPress Dashboard. I of course being the server provider was able to see the actual user table where their account was stored inside of MySQL but wasn’t able to interpret the password since it’s stored as a hash. We tried several times to retrieve the password using the “Lost your password?” option on the user login screen but I guess his work was filtering the emails. So, I started doing some digging around. A number of folks said to use PHPMyAdmin to manipulate the database that’s connected to the WordPress blog and change it that way. To that I reply, “Over my dead body.” I refuse to install PHPMyAdmin on a production machine since it simply opens up yet another attack vector. So digging a little bit deeper past the PHPMyAdmin recommendations I found the emergency.php script for WordPress. Essentially this is a drop-in PHP page that you FTP to your website, use it once and quickly delete it! It allows you to reset your WordPress admin account password for those times when you’ve forgotten the password. Again, I can’t say it enough, remove the file afterwards else someone else stumbles upon your emergency.php page and resets your password w/o your authorization!

Couple of links that might be helpful:

http://lorelle.wordpress.com/2009/02/06/the-agony-of-the-lost-wordpress-password/
http://codex.wordpress.org/Resetting_Your_Password
http://codex.wordpress.org/User:MichaelH/Orphaned_Plugins_needing_Adoption/Emergency

At work, we’ve installed SharePoint servers a couple of times. A reoccurring issue, is a permissions issue that appears in the event logs as Event ID: 10016 or 10017 but doesn’t seem to effect SharePoint performance. We just recently installed SharePoint 2010 and I decided to chase these errors down since it’s annoying and fills up the log files. Seems the local domain account you create to run specific SharePoint services during the initial installation don’t have specific permissions for local activation.


The machine-default permission settings do not grant Local Activation permission for the COM Server application with CLSID
{000C101C-0000-0000-C000-000000000046}
and APPID
{000C101C-0000-0000-C000-000000000046}
to the user SOMEDOMAIN\SOMEUSERACCOUNT_SVC SID (S-1-5-21-BLAHBLAHBALHBLAH) from address LocalHost (Using LRPC). This security permission can be modified using the Component Services administrative tool.


So if you run off to the Component Services, find the offending CLSID object and right click->properties, hit the Security tab to allow this account to run this DCOM object it’s greyed out!

You’ve apparently got to find it in the registry first (should be “Computer\HKEY_CLASSES_ROOT\AppID\YOUR_CLASSID_HERE.”)

Once found, right click the key in the left pane and goto permissions. From there, you’ll want to take ownership of the registry object from the Trusted Installer which will allow you, the admin, to change its’ security permissions w/in the dcomcnfg application.

Now that’s done, open up the “DCOM Config” node of the local computer, find your AppID GUID, right click and select properties. Now select the Security tab and change your Launch & Activation Permissions for your domain account that’s generating your error.

As always, here’s some links to explain:

http://social.msdn.microsoft.com/Forums/en/tfsadmin/thread/883b5f1c-1718-4b9a-a6c8-bf32c5d4d6d2

http://support.microsoft.com/kb/920783

http://www.wictorwilen.se/Post/Fix-the-SharePoint-DCOM-10016-error-on-Windows-Server-2008-R2.aspx

Here’s a tidbit of information that I had to use last night on a Windows 2003 server which got hung up on a reboot in a remote location. I’ve used this a couple times before but always double check the “help shutdown” before proceeding. The shutdown command has been available on all Windows OSes since Windows 2000 came out and can be very useful when working with a virtualized server, a headless server or a box in a remote location. Last night’s server reboot somehow got hung; probably on some application that required user interaction (I could still ping the box remotely, couldn’t RDP back into it but could still access it via RPC.) I just issued a quick:

shutdown /r /f /m \\"IP ADDRESS HERE!"

And the box finished its reboot and I was back in business. If it hadn’t been for that command at 10pm last night I would have had to wait until morning to get it back up and running!

Here’s a couple useful links w/ more info.

http://www.computerperformance.co.uk/w2k3/shutdown.htm

http://www.shutdown.cc/

Moving lots of data:I do all sorts of networking related stuff and one of the few things I do often are server migrations. So eventually, there comes a time for me to copy a large amount of data from one server to another while maintaining the file permissions and structure. That’s where tar & ssh come into play. If I’m moving a users’ home directory from one server to another I usually use tar & ssh together via a pipe and let it copy off the files perfectly.

tar zcvf - jsmith | ssh "destinations IP" "cd /home/; tar zpxvf -"

Within seconds of the command starting off, you’ll be asked for the password for your ssh session. Then, the data will get flung across the network to the destination folder. Works great!

Verifying Apache Configuration:When adding additional Virtual Hosts to your Apache config file it’s nice to make sure they’ve been picked up correctly (or! that you’ve modified the right httpd.conf file!) A simple way of letting Apache tell you what it’s going to use is via the -t option.

httpd -t -D DUMP_VHOSTS

It parses the running configuration and dumps the virtual hosts a nice readable format. You can also use “DUMP_MODULES” to see a list of the modules it will use which can be useful for whether or not that database module is going to be loaded or not.

MySQL database dump:It never fails, when doing a migration you’re going to need to dump your databases from a MySQL DB into another DB on your newer system. If they’re the same version however you can run mysqldump w/ a couple command-line switches and then import them on the new server.

mysqldump -u root -p --databases "your DB here" > dbfilename.sql

After you’ve moved your database file to the new server you can then import it in via:

mysql -u root -p -D "your DB here" < /path/to/dbfilename.sql

Keep in mind, we’re assuming you’ve already created the database inside your new MySQL server and will assign it proper permissions so your end user can connect to it!

Just a couple quickies for today’s post.

As always, a couple useful links:

http://www.debuntu.org/how-to-create-a-mysql-database-and-set-privileges-to-a-user

http://www.webmasterworld.com/forum49/723.htm

http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html

http://dev.mysql.com/doc/refman/5.0/en/default-privileges.html