My system’s a pretty straight forward Intel i7-based setup with some kind of nVidia graphics adapter. Honestly, I don’t remember which model, but I don’t think it makes that much of a difference. Its rather large and looks more like a vacuum cleaner than a electronic device for producing shiny pixels. The box has 6GB of RAM and two monitors attached via DVI. There’s a Logitech HD webcam attached too. Other than this, it’s pretty much plain vanilla.

First issue: After burning the 64 bit install DVD, I rebooted and found that the installation process (Anaconda?) failed to provide me with the bottom part of the dialog window, meaning I can’t see the Back and Next buttons. I tried to make it through the process just by counting my tabs, but I finally gave in, rebooted and started the install with VNC by adding the parameters ip=dhcp vnc vncconnect={ip of laptop}. This issue could perhaps be is due to my dual monitor setup, and it could be a showstopper for many people who want to give Fedora a spin.

A picked a pretty basic installation – Graphical Desktop on a freshly formatted root partition with my old home partition preserved. I rarely do a lot of system wide customization on my office box, so reinstalling like this really isn’t a big deal for me.

Besides the dual monitor issue and the general confusion about the new data/install media dialog box – which didn’t seem to work – the installation process itself went without a hitch. When completed, I rebooted my system, and was presented with a blank screen and a blinking cursor.

I rebooted from the installation media in rescue mode, mounted the system and ran this:

That seemed to do the trick – I expect my three hard drives got in each others way. First boot drags me through a lengthy SELinux relabelling, which annoys me since I’m probably going to disable it anyway.

After relabelling, the system rebooted and presented me with a text-mode login. Logging in as root and issuing “init 5″ seemed to fix that problem, and presented me with the usual graphical “Welcome” dialogue. I’m not sure if my previous boot problems caused this? Changes in the system now means that /etc/inittab isn’t the place to fix this – instead a symbolic link is required:

Next up – installing the right repositories:

Then make sure the system is fresh:

Install drivers for my nVidia graphics card:

Make absolutely sure the open sourced nVidia driver – Nouveau – does not conflict with the proprietary driver:

Disable (or partially disable) SELinux to allow Gnome Shell to use the nVidia driver:

Reboot, and the proprietary nVidia driver should be rolling. If you need dual monitor support, run nvidia-settings as root.

Various multimedia stuff that isn’t distributed with Fedora itself:

Stuff that Fedora thinks I can live without, but I really think I need:

That was easy, wasn’t it? I’m not so impressed with the installation process of Fedora 16 – even if it’s due to multiple hard drives and monitors on my system, someone should have caught the issues mentioned above before it was released. Once fixed though, the system seems to work find. Can’t seem to find the new “j” command mentioned in the release notes though.

UPDATE: Tried to install the office printer (HP Color LaserJet CP2025n), but the graphical setup tool said it couldn’t detect network printers without installing, enabling and starting firewalld. I did so, but it didn’t help much – I still had to select Search by address and punch in the printer’s IP.

UPDATE: Xorg seems to take up ~99% CPU at times according to top, and it’s really sluggish. Not sure what’s causing this.

UPDATE: VirtualBox-OSE seems to be broken – I get this error:

UPDATE: This morning my system greeted me with one black screen and one half gray. It turned out this was the locked screen dialogue, so entering my password and hitting return brought my desktop back. Still horribly slow, especially when changing focus to another window. Switching tabs in Firefox is just unbearable. I miss Fedora 15.

[945751.683883] usb 2-2.3: USB disconnect, device number 5
[945756.456657] usb 2-2.3: new full speed USB device number 13 using ehci_hcd
[945756.543124] usb 2-2.3: New USB device found, idVendor=2548, idProduct=1001
[945756.543129] usb 2-2.3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[945756.796580] cdc_acm 2-2.3:1.0: ttyACM0: USB ACM device
[945756.797164] usbcore: registered new interface driver cdc_acm
[945756.797167] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters

Compiled and installed the latest Git-version of Pulse-Eight’s libCEC (note, add -b release to the git clone command), and fired up the cec-client. The device doesn’t show up in the Sony TV’s Bravia Link menu. All HDMI ports were tried on the TV.

$ cec-client
No device type given. Using ‘playback device’
CEC Parser created – libcec version 1.0
no serial port given. trying autodetect:
path: /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-2/2-2.3
com port: /dev/ttyACM0

cec device opened
DEBUG: [ 0] trying to autodetect all CEC adapters
DEBUG: [ 18] connection opened
DEBUG: [ 19] communication thread started
DEBUG: [ 20] FindLogicalAddresses – device 0: type 4
DEBUG: [ 20] detecting logical address for type ‘playback device’
DEBUG: [ 20] trying logical address ‘playback 1′
DEBUG: [ 20] setting ackmask to 10
DEBUG: [ 24] command sent
NOTICE: [ 159] << 4 -> 4: POLL
TRAFFIC: [ 159] << 44
DEBUG: [ 164] command sent
DEBUG: [ 371] COMMAND_ACCEPTED
DEBUG: [ 371] COMMAND_ACCEPTED
DEBUG: [ 371] COMMAND_ACCEPTED
ERROR: [ 371] did not receive ack
DEBUG: [ 371] >> POLL not sent
NOTICE: [ 371] using logical address ‘playback 1′
DEBUG: [ 371] >> 4 changed physical address from ffff to 1000
DEBUG: [ 371] setting ackmask to 10
DEBUG: [ 376] command sent
DEBUG: [ 511] processor thread started
DEBUG: [ 511] COMMAND_ACCEPTED
DEBUG: [ 511] << powering on device with logical address 0
TRAFFIC: [ 511] << 40:04
DEBUG: [ 516] command sent
DEBUG: [ 819] COMMAND_ACCEPTED
DEBUG: [ 819] COMMAND_ACCEPTED
DEBUG: [ 819] COMMAND_ACCEPTED
ERROR: [ 819] did not receive ack
NOTICE: [ 820] << 4 -> broadcast: active view (1000)
TRAFFIC: [ 820] << 4f:82:10:00
DEBUG: [ 874] command sent
DEBUG: [ 1369] COMMAND_ACCEPTED
DEBUG: [ 1369] COMMAND_ACCEPTED
DEBUG: [ 1369] COMMAND_ACCEPTED
DEBUG: [ 1369] COMMAND_ACCEPTED
DEBUG: [ 1369] COMMAND_ACCEPTED
DEBUG: [ 1369] TRANSMIT_SUCCEEDED
waiting for input

I tried to get some feedback on Pulse-Eight’s IRC channel, but most people there seemed to be idling I was horribly impatient and they didn’t fix my problem in the first 60 seconds One thing was worth mentioning though – the HDMI ports on the device are labeled “IN” and “OUT”, but according to one user it actually doesn’t matter which port you use.

Stay tuned for part 2, where I will be taking this mysteriout device with me home and hooking it up to my Panasonic Viera TV. Fingers crossed.

Assuming the new Grub entry is the first one (0), ask Grub to boot pick it next reboot:

Now cross your fingers, pray to your preferred deity or lack thereof and reboot. If your karma is good, the server should come up in a few minutes. Now connect to it with the VNC client of your choice. Example:

If you’re lucky, you should be presented with something along the lines of this:

Now it’s all up to you. Based on my experience, I recommend making good use of RAID and LVM and keep your /root and /home partitions separate, but it’s all up to you. Be careful though – once you’ve started messing with the partition table, your disk is wiped and there is no way back – you have to finish the installation before you can give the remote reinstall another go.

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!

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 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 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?

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.