If you’re running Linux on your desktop, you’re probably using Network Manager to handle your network connections. The configuration interface doesn’t let you specify a DHCP hostname, which strikes me as odd. Luckily there’s a solution; add the following to /etc/dhclient-eth0.conf:
Fedora releases are sometimes a bit flaky, and Fedora 13 isn’t an exception – at least not when I was trying to install it on my MacBook Pro 5,5. It simply froze while booting the installation operating system – last display error was “Waiting for hardware to initialize”. Hours later, it turns out the magic trick is to add the nomodeset kernel option when booting the installation.
So you want to live your life on the edge, and do a remote reinstall of your server? The reasons can be many – maybe the server was compromised, or – like me – you just received a freshly installed new system with a horrible disk partitioning or maybe even the wrong choice of architecture. I’ll show you how! 
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!
With the release of PHP 5.3, many functions automatically trigger a function is deprecated error. With Magento, that error effectively stops execution, even if it’s actually just a small notice. I won’t beat around the bush – this is the quick and very dirty fix that turns off error reporting completely. Varien’s Object class also needs a small fix, but then you should be ready to go.
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.
I’m old school. I don’t have one of those fancy multimedia keyboards, but I do have one of those new fancy Windows-keyboards. That’s right – I’ve now got three extra keys I can’t really use for anything. I tried to map Win+F11 and Win+F12 to adjust my volume in Gnome, but no dice – it just displays Super R the moment I hit the Win-key. But there is a solution
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:
I couldn’t find any updated information on this online, so this is my ultra short guide to converting VMWare disk images to VirtualBox. This is tested with VirtualBox 3.0.0 under Fedora 11.
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.
I’ve had a few issues with my Firefox previously, but this time it somehow forgot all my saved passwords and stopped offering to remember new ones. This one was a quickie, but I’ll post it for later reference.
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.
I’ve been playing around with Sun VirtualBox. Installation of both Windows XP and CentOS 5 went smooth, but installing the guest OS tweaks – in the VirtualBox world referred to as Additions – gave me a little trouble on CentOS. It’s done the same way as on VMWare, by mounting an ISO with the scripts and drivers required. It’s not as painless as on VMWare 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 recently installed mod_security on our Apache server, and everything seemed to be working fine. Suddenly, while working on the previous post, I was presented with this error:
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:
Administrating a Linux system is always interesting, especially when something starts hogging the resources and people start complaining. Everyone wants their e-mail on time and spam free, but nobody wants to wait on a slow web server. What to do? Put a priority on your services!
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:
Datacenter Maintenance