I just received my dedicated server at bulk price, but unfortunately also with a bulk installation of CentOS. It’s fitted with two 250G disks, yet there is no mirroring or anything installed. On top of this, this delicious 64-bit system was running a 32-bit operating system. I was not amused. Asking for a special reinstall would probably cost me a fortune in support, and even then I probably wouldn’t get it exactly like I wanted it.

Luckily most new Linux distributions feature remote installation via VNC. If the system is already running Linux – like this one – its both easy and safe to play around with this method. In this example, we’ll be installing CentOS 5.4 x86_64.

Step 1: Get a hold of the bootstrap files. This includes the Linux kernel image and the ramdisk image. Put these on your /boot partition:

Step 2: Add an entry to the Grub boot loader. Adjust values for network (ip, netmask, dns, gateway) and pick a better VNC password than me. Copy the “root (…)” line from a working entry:

Step 3: Ask the Grub boot loader to boot your new entry next time, and only next time. This makes a lot of sense if your hosting facility allows you to power cycle the server remote – and they should. Really. If you can’t do this yourself, at least you can have some support drone push the reset button if the server doesn’t come up. Note what number your new entry in the Grub configuration file has. First one is 0, second is 1 etc. I had two entries already, so that made my new entry number 2:

Step 4: Reboot and be patient. Some servers take up to five minutes to come back up – probably because of a BIOS misconfiguration. Anyway, reboot it:

Step 5: Connect to your server with your favorite VNC client. Mine’s Chicken of the VNC You’ll need to connect to port 5901, which in VNC-terms often is referred to as “Display 1″. Use the password you specified:

Step 6: Run the install After this, your neat remote installation will be wiped, so double check all your network settings.

Good luck!

For starters, you have to find the ISO yourself – but I’ll give you a hint: look in /usr/share/virtualbox/ After mounting the ISO image, a directory popped up. I tried double clicking on autorun.sh but nothing ever comes easy, does it? I tried running it in the terminal, and was somewhat enlightened as I realized it was looking in vain for gksu – probably a Gnome frontend for su. Luckily there seemed to be another script I could run – VBoxLinuxAdditions-amd64.run – but it whined about OpenGL direct rendering:

Before I ran the script, I made sure the newly installed CentOS was crispy by running yum upgrade. I also had a sneaking suspicion that a C compiler was required, so I made sure the system also sported gcc. The only thing I personally noticed by reading the message above, was that some missing OpenGL crap prevented the additions to be installed. As I was typing the message in this blog, I also noticed something about kernel headers. Rather embarrassing, but I really didn’t see it until now. Anyway, obviously the thing needed was kernel goodness, so I ran yum install kernel-devel. That seemed to make the VirtualBox additions script more happy and now it seems to be running flawlessly.

So, to summarize – what to do to make the damned thing work:

I rebooted as I was told to, but mouse integration didn’t seem to work. Probably due to the kernel being upgraded without rebooting and actually utilizing it. So, I ran the additions script again, rebooted again and woo – mouse integration seems to work. The clipboard doesn’t though, and the maching is still creating some really nasty spikes on my CPU graph every three seconds or so:

It’s worth mentioning that when I’m running my Windows XP guest in VirtualBox, the CPU graphs on the host system are nice and flat.

I’m not entirely pleased, but I think VirtualBox will eventually win me over from VMWare.

I checked the log files, and found these hits:

In short, it’s mod_security telling me that the text /etc/ triggered rule 950005, which should be protecting our server against malicious attempts to access local files – like the ones in the /etc directory. The access file only showed a POST to /wp/wp-admin/post.php so I had no idea where the /etc/ string was coming from. Maybe some weird hidden Javascript? Maybe something else?

This post narrowed acknowledged it to be related to mod_security and suggested to disable it permanently or just turn it temporarily off while posting. I aim to do better.

The previous post has a wonderful nugget of enlightenment about prioritizing services on Linux, and suggested a couple of changes to the Linux configuration files – most of which are located in.. the /etc/ folder. In short, I triggered mod_security rule 950005 by posting data containing /etc/.

If you ever plan to cover issues related to deployment and administration of operating system in the Unix family, this rule absolutely has got to go. Obviously it’s written with the best of intentions, but as it is doesn’t work and should be disabled.

Avoid messing with /etc/httpd/modsecurity.d/modsecurity_crs_40_generic_attacks.conf and just disable the specific rules in /etc/httpd/conf.d/mod_security.conf by adding this:

To do this, I’ve decided to use the Apache suexec option for all my scripts. I won’t go into specific details about the setup here, but present a pretty solution to an annoying problem that arises when using suexec and applying software updates for the Apache server.

If your web files are located in /var/www, you won’t need this. For security reasons, suexec is compiled with various configuration options that can’t be changed runtime – the “safe” location of scripts is one of them. If you – like me – have your web files located somewhere else, you’ll need to recompile suexec and re-install it every time you upgrade Apache. If you decide to get the entire source code tree for Apache, just for this, you’ll find yourself in a mess that could easily be avoided.

Here is my solution: Since the suexec source files themselves rarely change, I picked out exactly the files needed to compile the suexec binary and simplified the Makefile. This way, I’ve got a very small directory with the files required to build my suexec with my own configuration options, without messing with the rest of the Apache source code. As long as I remember to run make install after updating Apache, it’s all good.

First of all, you need to set up a directory for the suexec files:

Now make the changes you need to suexec.h and write a suitable Makefile:

You’ll need the apr-devel and httpd-devel packages for this to work. Remember that you need to indent with tabs in makefiles. Run make install to install:

If you’re running php-cgi and getting http error 500, your suexec probably needs to be re-installed. Remember to check the suexec logfile.

I updated my CentOS 5.2 to 5.3 by running yum --merge-conf, and after downloading and updating, yum asked me what it should do about the new configuration files – kindly sparing me the identical ones:

I chose install the package’s version for everything I know I didn’t mess with, and do the default RPM action (keep local version) for the ones I had been tweaking.

Now, isn’t that cool?