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!

perl -p -i -e ’s/^\s*(error_reporting)\(.*\);\s*$/$1(0);/g’ `find docs/ -name “*.php”`
perl -p -i -e ’s/__toString/__invode/g’ docs/lib/Varien/Object.php

Hopefully the coming Magento 1.4 release will have fixed these issues, so a hack won’t be needed.

The solution is to redefine the Win-key behaviour. Open up System » Keyboard » Preferences, select the Layout tab, click Latyout Options… and change Alt/Win key behaviour from Default to Hyper is mapped to Win-keys.

I went straight back to Keyboard Shortcuts and tried Win+F11 again – this time I got Mod4+F11, proving that the Win-key now works as a modifier instead of a normal key:

Step one is to concatenate fragmented VMWare images. This might not me necessary in your case, but we’ll do it anyway. Let’s assume the image you want to convert is called leopard-fragmented.vmdk:

Now you’re got a rather huge VMWare disk image file, and we’ll use qemu to convert it into a raw disk image:

This will take a while, and you’ll probably end up with a less-than-huge file since this is the raw file, without any fancy compression. Now you’ll want to convert this to the VirtualBox disk format, vdi:

The vdi ended up being around 7GB – more or less the exact size of the vmdk file. The temporary bin file was 32GB though. Be sure you’re got enough room on your disk for this job.

This problem can be fixed by removing the files key3.db and signons3.txt from your Firefox profile directory. On Unix, it’s usually a random generated directory under ~/.mozilla/firefox. Be aware that removing these files will remove any stored passwords – mine were already gone though.

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:

My initial thought was “wow, someone must have thought about this before me”, and I looked briefly through the service scripts in /etc/rc.d/init.d. I was specifically interested in tweaking the nice level for the Amavis daemon, but found nothing in the amavisd file – just a simple call to the daemon function in /etc/rc.d/init.d/functions.

With my initial thought still fresh in my mind, I dug down in the functions script, and saw that it actually honours a couple of environment variables set by the configuration scripts in /etc/sysconfig – one of them being NICELEVEL.

In short: if you want a service – like the Amavis daemon – to run with priority 15, add this to /etc/sysconfig/amavisd: