First I found out what would allow the action that was being defeated using audit2allow

# echo "avc: denied { read } for pid=3736 comm="gitweb.cgi" name="cgi-bin" dev=md7 ino=5079272 scontext=system_u:system_r:httpd_sys_script_t:s0 tcontext=system_u:object_r:httpd_sys_script_exec_t:s0 tclass=dir" | audit2allow
#============= httpd_sys_script_t ==============
allow httpd_sys_script_t httpd_sys_script_exec_t:dir read;


Basically the gitweb cgi calls some perl that does the equivalent of getcwd(), and this was being disallowed. The advice that was correct for setting local policy on F7 was found here. In short I did

# mkdir /root/tmp; cd /root/tmp
# touch local.te local.if local.fc
# yum install selinux-policy-devel
# vi local.te
policy_module(local, 1.0)

require {
attribute httpdcontent;
type httpd_sys_script_t;
type httpd_sys_script_exec_t;
}
allow httpd_sys_script_t httpd_sys_script_exec_t:dir read;
# make -f /usr/share/selinux/devel/Makefile
# semodule -i local.pp

Immediately after doing this gitweb was back working normally again.

Don’t embark on this unless you have some Linux-fu and know how to get yourself out of trouble, because at every step you can easily trash your server and lose all your data. We are literally going to format the main filesystems and install a new bootloader on a remote server… we can call that “not a beginner project”.

Sanity check that we have the same layout

Zero’th move is a sanity check. Confirm that your 1&1 server still has the same Raid 1 layout (the result of fdisk /dev/sd[a-b] and pressing p):

Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

# mount
/dev/md1 on / type ext3 (rw)
none on /proc type proc (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/md5 on /usr type xfs (rw)
/dev/md7 on /var type xfs (rw,usrquota)
none on /tmp type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)


If that is the same you are in with a chance with these instructions.

Create missing raid config file

First create /etc/mdadm.conf … NOT /etc/mdadm/mdadm.conf

ARRAY /dev/md5 devices=/dev/sda5,/dev/sdb5
ARRAY /dev/md6 devices=/dev/sda6,/dev/sdb6
ARRAY /dev/md7 devices=/dev/sda7,/dev/sdb7
ARRAY /dev/md1 devices=/dev/sda1,/dev/sdb1

Grub will need this later and mkinitrd in the next step for the new kernel will use it also.

Dist-upgrade to F7

Next move is to dist-upgrade to F7 from inside the mutant FC4 environment.

# wget http://www.mirrorservice.org/sites/download.fedora.\
redhat.com/pub/fedora/linux/releases/7/Fedora/i386/os/\
Fedora/fedora-release-7-3.noarch.rpm
# rpm -Uvf --nodeps fedora-release-7-3.noarch.rpm
# yum clean all
# yum update yum
# yum update
# yum install grub

This package contains the yum repo set down /etc/yum.repos.d configured for Fedora 7 repos. So the next yum update you do is going to “update” you to F7 since all the packages it can see are now of F7 vintage. However, on reboot, you are going to come back up in the old mutant 2.6.16 Debian kernel. If you try to use the Fedora kernel, you will have immediate deadly trouble with lilo and xfs support. Nice “Fedora” they got there, with freaking lilo.

Reformatting all xfs into ext3

Next move is to get rid of this xfs-format crud and replace it with ext3. I started out doing it inside the normal boot environment for /usr, and then was forced to change to using the rescue environment to do /var, so I will describe both ways as I did them.

I logged into the serial console from my local machine here using

$ ssh (magic userid)@sercon.onlinehome-server.info

and gave my “original root password”. You can find this and the (magic userid) in your 1&1 control panel under “serial console”

Then I logged into the box there using my real root credentials, and did

# telinit 1

this will kill all your networking and disable all services. Confirm everything went down with ps -Af and kill anything that is still up, except your sh session.

Now we get rid of any junk in the yum cache and then backup /var

sh-3.1# yum clean all
sh-3.1# tar czf /usr/backup-var.tar.gz /var
sh-3.1# umount /var

At this point, the 2.6.16 weirdo kernel blew a warning, which I ignored because that XFS formatted filesystem is about to get a well-deserved deletion

Badness in mutex_destroy at kernel/mutex-debug.c:458

Call Trace: {mutex_destroy+109} {xfs_qm_destroy+140}
{xfs_qm_rele_quotafs_ref+165} {xfs_qm_destroy_quotainfo+18}
{xfs_mount_free+160} {xfs_unmountfs+171}
{xfs_unmount+275} {vfs_unmount+34}
{linvfs_put_super+49} {generic_shutdown_super+153}
{kill_block_super+36} {deactivate_super+103}
{sys_umount+111} {error_exit+0}
{system_call+126}

Oh well, let’s destroy the /var filesystem by rewriting it ext3.

sh-3.1# mkfs.ext3 /dev/md7
mke2fs 1.39 (29-May-2006)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
17956864 inodes, 35889184 blocks
1794459 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
1096 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872

This filesystem will be automatically checked every 39 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.

Edit /etc/fstab to reflect our change (shows from -> to)

/dev/md7 /var xfs defaults,usrquota 0 2
/dev/md7 /var ext3 defaults 0 2

Okay now we mount our clean empty ext3 /var back in place

sh-3.1# mount /var
kjournald starting. Commit interval 5 seconds
EXT3 FS on md7, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
sh-3.1# ll /var
total 16
drwx------ 2 root root 16384 Sep 4 20:49 lost+found
sh-3.1# cd /
sh-3.1# tar zxf /usr/backup-var.tar.gz
sh-3.1# rm /usr/backup-var.tar.gz

At this point /var is back how it was, but it is now on ext3. Now we backup /usr and /home into our nice new /var

sh-3.1# rsync -a /usr /var
sh-3.1# rsync -a /home /var

Now unfortunately I was unable to get /usr into a state that I could umount it cleanly… the sh had handles open to /usr/lib/ libraries. So I had to use a different technique to reformat /usr and /home in place.

Go to your 1&1 control panel and select the “recovery tool” option. Make sure “reboot now” is unchecked, and select “Linux Rescue System (debian/woody – 2.6.x) “. Confirm it and you will get a one-time login password generated for the rescue system. Wait a couple of minutes and then

sh-3.1# shutdown -r now

your server. When it reboots, it will come up in the recovery system, which is a network boot with none of your local partitions mounted… this is most excellent and a really powerful solution for the kind of work we are doing on this server. However, save yourself some time and go back to the “recovery tool” page now, and again with “reboot now” unchecked, select “Normal System” again and confirm it. Otherwise you keep coming back into the rescue system in future boots too.

Next we reformat the /usr partition, /dev/md5

rescue:~# mkfs.ext3 /dev/md5
mke2fs 1.40-WIP (14-Nov-2006)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
611648 inodes, 1222912 blocks
61145 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=1254096896
38 block groups
32768 blocks per group, 32768 fragments per group
16096 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736

This filesystem will be automatically checked every 22 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.

Let’s mount our new, empty ext3 /usr partition at /mnt in the rescue filesystem

rescue:~# mount /dev/md5 /mnt
kjournald starting. Commit interval 5 seconds
EXT3 FS on md5, internal journal
EXT3-fs: mounted filesystem with ordered data mode.

and we can mount our ext3 /var partition we made earlier at /opt

rescue:~# mount /dev/md7 /opt
kjournald starting. Commit interval 5 seconds
EXT3 FS on md7, internal journal
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.

Restore the contents of /usr from the copy we made in /var, and nuke the redundant copy: finally unmount the new, filled /usr

rescue:~# rsync -a /opt/usr/* /mnt
rescue:~# rm -rf /opt/usr
rescue:~# umount /mnt

Do the same for /home

rescue:~# mkfs.ext3 /dev/md6
rescue:~# mount /dev/md6 /mnt
rescue:~# rsync -a /opt/home/* /mnt
rescue:~# rm -rf /opt/home
rescue:~# umount /mnt

Alright, xfs is GONE, everything is ext3 and has its old content back in it

Let’s get our / filesystem mounted at /mnt now and update our fstab to record the demise of xfs

rescue:~# mount /dev/md1 /mnt
and edit /mnt/etc/fstab (notice the /mnt!) to reflect that we got rid of xfs on /usr and /home and replaced it with ext3 (from -> to again)

/dev/md5 /usr xfs defaults 0 2
/dev/md5 /usr ext3 defaults 0 2

/dev/md6 /home xfs defaults,userquota 0 2
/dev/md6 /home ext3 defaults 0 2


Alright, the filesystem messing is done.

Goodbye lilo

Next job is to expunge lilo and replace it with grub.

rescue:~# grub-install --no-floppy /dev/sda
rescue:~# grub-install --no-floppy /dev/sdb

You need to change the bogus /boot/grub/grub.conf that 1&1 mislead you with, into this (change the kernel and initrd version number to what you actually have from your f7 kernel in /mnt/boot ).

rescue:~# vi /mnt/boot/grub/grub.conf
serial --unit=0 --speed=57600 --word=8 --parity=no --stop=1
terminal --timeout=5 console serial
default=0
timeout=10

title Normal Fedora
root (hd0,0)
kernel /boot/vmlinuz-2.6.22.2-42.fc6 ro root=/dev/md1 console=ttyS0,57600 panic=30
initrd /boot/initrd-2.6.22.2-42.fc6.img

Reboot into F7 with F7 kernel

Finally we should umount and reboot into your new Fedora kernel

rescue:~# umount /mnt
rescue:~# umount /opt
rescue:~# reboot

On reboot you should see a grub menu on the serial console which will timeout and boot you (all being well).

Adding selinux

The bogus FC4 install from 1&1 did not include any selinux. This is a pretty bad omission, and we can fix it now. Edit /etc/sysconfig/selinux and set initially to be

SELINUX=permissive

Then

# touch /.autorelabel
# reboot

This will cause the initscripts to relabel all your filesystems according to your Fedora 7 policy. It will reboot automatically after doing this, when it comes back up selinux will be working in a “firing blanks” mode. It just reports any errors and lets the access occur anyway. You can judge from this what will break when you enable it properly. In my case there were three areas that were broken, first one user has ~/public_html, it needed to be enabled in selinux and then marked up as okay to serve by httpd

# setsebool -P httpd_enable_homedirs 1
# chcon -R -t httpd_sys_content_t /home/user/public_html

Second for some reason named couldn’t start because it wasn’t allowed to write its own pid in the chroot, I worked around it with this

# setsebool -P named_write_master_zones on

The third problem was gitweb, I am asking about it on the selinux mailing list and will update when I have a resolution. UPDATE 2007-09-05: No response from the fedora-selinux ml, I resolved it myself as described here.

When you are sure that any remaining avcs (you can find them in /var/log/messages) are trivial or there are no more being generated, you can properly turn selinux on by editing /etc/sysconfig/selinux again and this time setting

SELINUX=enforcing

and rebooting.

Conclusion

Hopefully I recorded everything that was needed to convert the craptasic bogus unsafe FC4 install in 1&1 servers to clean and true Fedora 7. Certainly being able to yum update kernels as usual is a major step forward, getting you 2.6.22 (in fact I installed a Fedora development repo kernel which is 2.6.23-rc5) from the original non-Fedora 2.6.16. And it’s crazy to not have selinux when it’s provided by normal Fedora.

First it is FC4, which is out of security update coverage, and Fedora Legacy has gone away too. I update it to FC6 via yum (worried about the libata change in the F7 kernels making it unbootable… needn’t've worried since I can make it unbootable all by myself). After the update the /boot/grub/grub.conf looks a bit strange, grubby did not make an entry for the FC6 kernel so I add it by hand.

On reboot, it ignores the new kernel and boots the old one. Further digging reveals that it is set up to use LILO, not grub. They provide and cook their own 2.6.17 kernel which was built on a Debian box and does not use an initrd: it has all the drivers it needs built into the monolithic kernel. Hm.

I google through pages from 1998 to learn about LILO, I make a mistake: I saw they had a symlink /boot/vmlinuz to point to the kernel they boot from, so I changed the symlink, reran lilo and rebooted… it doesn’t come back up. Now 1&1 have a cool serial console server concept, you can ssh into their central site with your per-server credentials and you are looking at your server’s serial console. From this I see it can’t find the root filesystem. Well no problem, I will choose one of the backup lilo.conf configurations at the prompt, right? Nope, they all rely on the same vmlinuz symlink I changed.

So at this point after an hour or so of having the shiny new server, it is borked. However 1&1 offer a free network boot recovery feature you can select from the web page: I did this and came up in a Debian recovery boot presumably over PXE. From there I could mount my root fs /dev/md1 on /mnt and undo my kernel symlink change, and so got back a working system. Whatever else, that is a pretty robust setup, I could trash the thing into an unbootable state and recover it all by myself without any tech support or even having to wait. Great!

However considering they advertise it as a “Fedora” system, aside from not being able to use Fedora kernels, the jarring strangeness continued. There is no selinux set up. This is pretty bad considering the support is everywhere in Fedora for it and it doesn’t cause any trouble nowadays. Nor is it possible to enable selinux simply: because the partition-happy Debian admins that set it up decided to format some (not all) of the partitions as xfs.

There is no firewall enabled… all of your entrails like network MySQL access are hanging out for the world to see. I installed system-config-securitylevel and had it set up a bare Fedora-style firewall on top of which I copied over my long, long (and growing) list of DROP netblocks.

Some evil and perverse web admin stuff was on by default, dozens of PHP apps, that involved redirecting your mailserver log to somewhere crazy on /usr. This seems like an invitation for bad things to happen, so I tore them all out with yum remove.

After some hours all of the virtual hosts on Apache were back up except yahoeuvre, which was creating problems in the error logs and not working properly. Since it has been deprecated for a long while due to Yahoo format changes, I didn’t bother fixing it and set it to redirect here instead.

However, I am left wondering… is it fair to call that… well, “heavily customized” Debian-Fedora hybrid OS “Fedora”? The Fedora kernel does have an xfs module, but they don’t allow to format stuff xfs in Anaconda so it’s “not really supported”. They provide great admin tools though, not the PHP garbage but the serial console server and the recovery netboot are fantastic remote server admin powers: really allowing you to get out of jail when you need to. Maybe it will be possible to come up in the recovery console, copy out the contents of the xfs partitions somewhere and reformat them ext3 and gradually convert the thing to “proper Fedora”.

EDIT 2007-09-05: In fact I have now converted this 1&1 server to “proper Fedora 7″, see this post for details.

But to my surprise I tried Fedora 7 Rhythmbox a few minutes ago, expecting nothing much but the pile of Gnomic crud that assaulted me last time I tried it. Ah no, mashed up with Jamendo (but apparently not as planned Magnatune) Rhythmbox has become more than the sum of the parts and has crashed uninvited into iTunes territory.

It has become a native client app you can start up and listen to a big catalogue of liberally licensed music, not only without the expectation of having money sucked from your living veins but even with the expectation of being moved to voluntarily donate to the people sending you their hard work for free, when you especially appreciated what they offered.

And there on the menu bar is the legal, sanctioned, intentional “download album” button. In the face of this must you go and give money to the lawyer loving corporate coke snorting beast-creatures for mainstream crud? Or should you not set out to make a direct connection with the artists and show them your appreciation in a direct and personal way?

An extraordinary advance for standard Linux media players!

This works well except for a correspondent in Australia, who is on bigpond.com. They use a blackholing service which has blackholed the whole residential ADSL netblock for their ISP, on the basis a lot of spam is coming directly from compromised Windows boxes, meaning that the Postfix on their box doesn’t get anywhere talking to bigpond (and annoyingly bigpond rejects the mail with a 450 not a 550, delaying notification that there are problems).

I am in a similar position, I run my own MX at home where I work, so mail is sent directly to me, but I am unable to reliably send outgoing mail directly due to some blackhole lists including my whole netblock. My solution is to run a Postfix instance on warmcat.com, which is not used for incoming mail and is firewalled off from everyone except my home IP address. As a belt-and-braces, the Postfix on warmcat.com is configured to only relay from my IP address anyway.

So the obvious solution to the problem with the in-laws would be to also route their outgoing mail through warmcat.com, which pretty much everybody will talk to since it is sat in a server farm. But the fly in the ointment is that they are on residential ADSL, their IP address is changing every boot. I don’t want to add an authentication layer because I don’t want to disrupt their mail any further while I get it working and the pinhole in the Firewall method is working fine for me too.

The first move was to regularize their dynamic IP using dyndns.org and the perl client from there. This gave me a reliable FQDN that always resolves to their machine. Then the problem was simplified to “how can I get Postfix to accept a list of clients allowed to relay using FQDNs? And to track changes where the DNS mapping is dynamic?”. It seems that you can’t, it only accepts netblocks.

To solve this problem I created the following script which runs from a cronjob. See inside the script for instructions.

#!/bin/bash

# update-valid-postfix-clients
# 2006-08-09 - andy@warmcat.com - v1.0
#
# Allows FQDNs to specify trusted clients to Postifx, including detection of IP address
# change and firewall opening and closing

# list the FQDNs you are allowing to see you server here, separated by spaces
# the DNS for these can be dynamic
# the script will open and close your firewall as the IPs for these change
# the script will take care to notify postfix to allow and disallow these IPs as they change

TRUSTED_FQDNS="home.warmcat.com some.domain.dyndns.org"

# list the networks that are trusted here separated by spaces
# notice that netblocks are handled by specifying the active part only
# eg, 192.168.0.0/24  --> 192.168.0 in this table
# You must open your firewall for these netblocks manually, the script does not do it

TRUSTED_NETS="127"

# VERBOSE=0   No output except fatal errors
# VERBOSE=1   Output only when something changes
# VERBOSE=2   Output each time run, even if nothing changed

VERBOSE=1

#
# Installation instructions
#
#  1) copy this file to /usr/local/bin/update-valid-postfix-clients
#
#  2) edit the above vars to configure for your situation
#
#  3) edit /etc/postfix/main.cf, comment out any existing mynetworks= line and uncomment the following line
#      mynetworks = hash:/etc/postfix/network_table
#
#  4) Add this to /etc/crontab
#      # open firewall and allow good users in postfix
#      00,05,10,15,20,25,30,35,40,45,50,55 * * * * root /usr/local/bin/update-valid-postfix-clients

#----------------------------------------
# no user serviceable parts below

DIRTY=0

function allow {
IP=`host "$1" | cut -d' ' -f4`
if [ ! -z "$IP" ] ; then
if [ -z "`cat /etc/postfix/network_table | grep $IP`" ] ; then  # IP was not in force before
DIRTY=1
if [ $VERBOSE -gt 0 ] ; then echo "IP change $1 -> $IP" ; fi
OLDIP=`cat /etc/postfix/network_table | grep $1 | cut -d' ' -f1`
if [ ! -z $OLDIP ] ; then
if [ $VERBOSE -gt 0 ] ; then echo "Removing firewall setting for $1 -> $OLDIP" ; fi
iptables -D INPUT -p tcp -s "$OLDIP" --dport 25 -j ACCEPT
fi
fi
echo "$IP OK # $1" >>/etc/postfix/network_table-new

# note that we open the firewall always even if we are not marked as dirty for postfix
# this is so a local reboot will get the firewall fixed up even if the remote DNS is unchanged

if [ -z "`iptables -L INPUT -n | grep "dpt:25" | tr -s ' ' | cut -d' ' -f4 | grep "$IP"`" ] ; then
if [ $VERBOSE -gt 0 ] ; then echo "Opening port 25 for $1 -> $IP"; fi
iptables -I INPUT -p tcp -s "$IP" --dport 25 -j ACCEPT
else
if [ $VERBOSE -gt 1 ] ; then echo "(Port 25 for $1 -> $IP already open)" ; fi
fi
fi
}

# give us an empty network_table file if it doesn't exist to avoid harmless errors

if [ ! -e /etc/postfix/network_table ] ; then
if [ $VERBOSE -gt 0 ] ; then echo "Creating /etc/postfix/network_table" ; fi
touch /etc/postfix/network_table
fi

# regenerate list

for i in $TRUSTED_FQDNS ; do allow $i ; done
for i in $TRUSTED_NETS ; do echo "$i OK" >>/etc/postfix/network_table-new ; done

if [ $DIRTY = 1 ] ; then
if [ $VERBOSE -gt 0 ] ; then echo "reloading postfix due to changes" ; fi
rm /etc/postfix/network_table
mv /etc/postfix/network_table-new /etc/postfix/network_table
postmap /etc/postfix/network_table
service postfix reload
else
if [ $VERBOSE -gt 1 ] ; then echo "(No changes)" ; fi
rm /etc/postfix/network_table-new
fi

The script runs in a 5-minute cronjob, and takes care to do nothing if the IP address situation has not changed for the allowed FQDNs. If it does find a change, it removes the firewall pinhole to Postfix from that IP address, and creates a new pinhole for the new address. It also regenerates the list of allowed clients that can relay in Postfix, hashes the list and does a Postfix reload. The result is that just adding a FQDN to the script at the top will allow that FQDN access to the server no matter if it has a dynamic IP, but nobody else can even see the mailserver thanks to the firewall.

http://ftp.cvut.cz/vmware/

allows VMware to work fine on Fedora normally (I have an XP install that runs inside VMware to provide Protel). But since I migrated the VM to this laptop, networking seems to be fixed on host-only. I can ping the host from inside the VM but nothing else, despite (or because of perhaps) I selected “bridged”.

Going to have a fiddle.

Edit: Hm, looks like arp proxying is broken on the wlan0 interface. Moving to a brdige on eth0 works fine.

A few weeks ago the drive started acting erratically, I would waken in the morning and find that the ext3 filesystem on there had been remounted read-only because filesystem corruption had been detected. I was able to fsck the filesystem back into sanity and the drive would act fine for several days. Well these stories always end the same way, with a drive that won’t complete a boot, and that was the case for this idiot too.

The particular disease was that the area of the disc that contained the LVM structure — Fedora sends in LVM by default now — was spewing hard IO errors when touched. Therefore it couldn’t get past trying to bring up the LVM on boot and simply dropped dead. I documented the evasive actions I took on this fedora-list mail , basically I was able to recover the ext3 filesystem that was inside the LVM block on to a new SATA drive. “LVM”’s physical footprint is basically an 0×30000 byte header before the ext3 filesystem starts.
I installed FC5 on the new drive and brought over most of the data from the copy of the ext3 filesystem from the damaged drive, and went on pretty much as normal, with brief interruptions while I fished something I had forgotten I needed from the old filesystem. But then to my disbelief, after just a week, the new drive — the only drive in the machine — blew chunks in a similar way, hard IO errors one morning. I came in my work room and heard it performing the click of death.
I recovered from this rather grimly from backups, I did not fancy attempting a second recovery of 60GB of data from a second drive inside of a week. I stared at the AMD box for a minute or two though… I could think of two likely causes, the most likely one being the power supply. If it was having trouble with its 12VDC line, serious trouble, it might cause the drive to reset itself as if a poweron was happening repeatedly. It’s not hard to imagine that a set of such resets at random intervals might eventually catch the drive out in its initialization phase and cause it to throw a fit ending it its head scratching the surface. The other possible cause is a bit more uncertain, both boxes were running the new FC5 2.6.17 kernel which has had a lot of work going on with libata and the kernel code for SATA. I wonder if that is repeatedly attempting drive resets as a last resort.
Anyway it had caused enough trouble, I swore off it and migrated back to running from this Centrino Duo laptop, it is plenty fast enough for a main workstation. One nice feature of vmware is that the XP I am running inside it has no idea that it has moved machine, there is no activation crap — although this is of course a genuine retail copy of XP, one of two I own. I shall probably have cause to write about it another time but I have to have XP for Protel. It runs on top of Fedora Core thanks to Vmware workstation.