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

I’ve installed WordPress websites several times on various Linux distros w/o issue but today I needed to install WordPress on a Windows 2008 R2 Server for the first time. Thankfully WordPress.org had an entire webpage up on just how to do it. Looks like they’re using a Microsoft publishing site called Web App Gallery or Web Platform Installer to install not only WordPress but also any dependencies and also do the initial configuration. The only problem I had was getting WordPress to update itself via FTP. Not only do you need to install the FTP server under the IIS additional roles but you need to explicitly give that FTP user account modify & write permissions to your wwwroot folder which is housing your WordPress files.

WordPress IIS page:
http://codex.wordpress.org/Installing_on_Microsoft_IIS

Microsoft’s Web App Gallery page:
http://www.microsoft.com/web/downloads/platform.aspx

So a couple of months ago I had to stand up a DOORS Web Access server for work. It was pretty straight forward except for the creation of a certificate in your Java Keystore and then using it inside of your Tomcat server’s server.xml file.

  To create the Java Keystore file you’ll first need to have downloaded Jetty which will do the command-line magic for you. I downloaded it from the codehaus.org website but you can find it by doing a Google for Jetty keytool. Once downloaded ensure your Java environment is setup correctly by issuing via command-line java -classpath lib/jetty-6.1.1.jar org.mortbay.jetty.security.PKCS12Import . It should return back w/ usage information letting you know your Java environment is setup for command-line Java execution. Next, put your PFX file in the same directory where you are via command-line and then issue java -classpath lib/jetty-6.1.1.jar org.mortbay.jetty.security.PKCS12Import <mycert>.pfx <myjavakeystorefile>.jks. You’ll be prompted for the password that allows you to use the PFX file, then you’ll be asked for a password for your JKS file. Once it’s done, you’ll have your Java Keystore and password.

Now, you need to open up your server.xml file and find the SSL part which needs to be modified to point to your Java Keystore file. When I found my server.xml file the https port was changed to 8443 which from what I hear is pretty common. I simply changed mine back to 443 so I wouldn’t have to do any firewall redirection. Now, I simply had to add SSLEnabled="true" keyAlias="server" keystoreFile="C:\path\to\keystore\file\mykeystorefile.jks" keypass="supersecretpasswordwhichI'mnotstupidenoughtoblogabout" . Once I had those attributes correctly set I simply stopped and restarted the Tomcat server.

All credit really goes to DigiCert & Entrust 🙂

Jetty tool kit explained:
http://www.entrust.net/knowledge-base/technote.cfm?tn=7925

Tomcat SSL certificate installation:
http://www.digicert.com/ssl-certificate-installation-tomcat.htm

Jetty’s website:
http://docs.codehaus.org/display/JETTY/Jetty+Wiki

So I’ve recently installed Remote Desktop Services at work for testing purposes. I haven’t decided if we’re going to use RDS or something from Citrix. When doing the install I opt’d for the RD web access & gateway pieces so folks can use RDS over port 443. One of the first things I noticed was the generic title page of “Remote Desktop Services Default Connection” which I wasn’t to happy about. Did some quick Googling and found out you can change the text on the webpage by editing the RDWebAccess.config file. Just look for the <WorkspaceSettings Name=””> key and change it to what you want. I found the file at C:\Windows\Web\RDWeb\App_Data folder.

Need to give credit to Matt’s blog over at Bunker Hollow.
http://www.bunkerhollow.com/blogs/matt/archive/2010/02/05/rename-quot-remote-desktop-services-default-connection-quot.aspx

Thanks Matt!

  So way back in the beginning I developed a simple web file manager for our company that allowed us to upload files to a Linux server and share them w/ noncorporate users. Things worked great but I’ve been left maintaining the server even though I’m now playing Network Engineer.

  Well, as time has progressed, the requirement to upload ever bigger files has ballooned and it orginally was built for files around 500MB. So I did a quick php -i | grep php.ini to find where my php.ini file was and started editing the config. I quickly found upload_max_filesize and increased it to over a 1GB for file uploads. Next I found post_max_size and increased that to the same size. Quick restart of the apache server and I was off testing. Started to do some large file uploads and I started getting some errors. I placed some debug code in my php subroutine and low and behold, I was getting an error = 2. This particular error meant I hadn’t increased the HTML form attribute MAX_FILE_SIZE to 1GB either. Once I had all three attributes set to a higher setting I was GTG.

Couple quick links:

Talks about the HTML form input field MAX_FILE_SIZE:
http://www.tizag.com/htmlT/htmlupload.php

PHP move_uploaded_file function call over on php.net/manual. Has LOTS of good demo code below:
http://php.net/manual/en/function.move-uploaded-file.php

Actual PHP file upload errors one can get when using move_uploaded_file:
http://php.net/manual/en/features.file-upload.errors.php

So I’ve got my own Active Directory server at home w/ multiple network segments. On one of these network segments, I’ve got a Win2008R2 server w/ a static IP address that needs to join the domain but isn’t on the same network segment as the AD server. When I attempt to join the domain I get the following error message.

Once I get the error message and do a reboot I’ve joined the domain w/ no perceivable errors except the one shown above. I can log into the server w/o any issues using domain user accounts and everything appears fine. Obviously not satisfied w/ this conclusion I start doing some searches and remove the server from the domain to see if I can repeat the above error message.

Finally after searching for an hour I stumble upon a similar domain joining error on Lumbgaps blog and add a domain suffix to my server via the advanced settings on my network card. Once joined, I remove the domain suffix w/o any issues. Seems the server was having a domain searching issue and wasn’t appending the right FQDN on the end of whatever it was doing. This fixed it.

Link to Lumbgaps blog:
http://lumbgaps.blogspot.com/2010/03/changing-primary-domain-dns-name-of.html

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/