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!
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 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:
I’ve always had trouble understanding exactly why I would get a million .rpmnew files after updating my servers, especially when those files were exactly identical to their original counterparts. Luckily there seems to be a solution – the yum-merge-conf plugin!
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:
Package sudo: merging configuration for file “/etc/sudoers”:
By default, RPM would keep your local version and rename the new one to /etc/sudoers.rpmnew
What do you want to do ?
– diff the two versions (d)
– do the default RPM action (q)
– install the package’s version (i)
– merge interactively with vim (v)
– background this process and examine manually (z)
Your answer ?
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?
As a website developer, I unfortunately need to test everything in Microsoft’s dreaded Internet Explorer. For this, I’ve got a Windows XP running on an installation of VMware® Workstation on my Linux desktop. It works like a charm, except when the kernel is updated.
Aside from being a website developer, I’m also a paranoid system administrator. One of the first thing I add to my login scripts, is umask 077 – the command that sets the permission mask for newly created files. Setting this to 077 prevents anyone but the current user from being granted any rights – read, write or execution. It’s a sane thing to do, but unfortunately a lot of scripts fail to explicitly grant access to other users, especially when installing RPM packages or – in this case – running VMWare after a kernel upgrade to build new VMWare-specific kernel modules.
In this specific case, VMWare kernel modules were built by the root user, and ended up in /lib/modules/2.6.27.19-170.2.35.fc10.x86_64/misc/ which was created by the build process. Read permissions were not explicitly granted to everyone, so when running vmware as a mortal user, it was unable to actually read and verify the newly built kernel modules. The natural response to the user wasn’t “Unable to read kernel module files”, but instead “You need to build kernel modules for your specific kernel”. Makes a lot of sense, eh?
Manually granting read and execution rights on the /misc directory and the files in it fixed the issue.
This is just an easy one-liner to install the Danish language pack for OpenOffice.org in recent versions of Fedora Linux:
Recently I needed sendmail and sendmail-devel to compile some software, but when I installed Sendmail, it decided to make itself my preferred MTA – and I suddenly got the same feeling of powerlessness that accompany running Microsoft Windows.
Newer Linux distributions offer the Alternatives system, which basically lets you choose between different installed software that serve the same purpose. If you’re running Sendmail and Postfix like me, you can use Alternatives to pick which MTA you prefer to use:
--config mta
There are 2 programs which provide ‘mta’.
Selection Command
-----------------------------------------------
* 1 /usr/sbin/sendmail.sendmail
+ 2 /usr/sbin/sendmail.postfix
Enter to keep the current selection[+], or type selection number: 2
Today I lost my Ethernet devices, probably as a result of upgrading the apartment server from Fedora 9 to Fedora 10. The culprit turned out to be the service responsible for dynamic device management – udev. These symptoms started showing up in the logfile:
The udev daemon creates and renames devices according to configuration files in /etc/udev/rules.d/ called rules. One of them – 70-persistent-net.rules – specifically handles network devices. This file was screwed up badly by Anaconda, and had dupes and network devices from a previous hardware configuration. I cleaned up this file, so it had only contained rules that matched the hardware addresses of the installed network devices:
Various external “plug-and-play” helpers may add newly found network devices to this file, so if your network devices start changing names, you might want to check /etc/udev/rules.d/70-persistent-net.rules.
Datacenter Maintenance