The Annual Fedora Linux Upgrade

For the past several years, the end of the year has been the time for me to upgrade the home Linux system from Fedora N to Fedora N+2.  The Fedora people have the reasonable policy of only providing updates on the most recent two Fedora Linux distributions, and they release a new distribution every six months.  So, in order to keep my home Linux system up-to-date, I upgrade to the latest Fedora distribution once a year.  I began with Fedora Core 2, am now running Fedora 12, and have run all the even-numbered releases in between.

This year’s upgrade seemed like it had more than the usual number of issues, in part because I’m doing more things with my Linux system these days.  Since some of them might be avoided had I been better prepared, I thought I would describe what I ran into.

Performing the Upgrade

I downloaded the Fedora 12 DVD distribution via BitTorrent soon after it came out.  As part of the reciprocal nature of BitTorrent, I left my client running until it had uploaded at least two times as much data as I had downloaded.  I suggest others do the same.  I verified the checksum on the distribution and burned a DVD from it.

The DVD booted fine, but the installer wouldn’t recognize the DVD drive when it came to performing the upgrade.  This is apparently a long-standing problem that has existed since Fedora 7, which has been closed as a “can’t be fixed” bug.  I haven’t gone through all of the text in the bug in detail, but I have trouble understanding why the installer, anaconda, can’t talk to the drive any more.  I must have run into this on either the Fedora 8 or Fedora 10 upgrades, but other than a vague sense of déjà vu, I don’t remember solving this problem.

Fortunately, one of the options available is a network installation.  So I created a share on my network-attached storage box, and loaded the distribution DVD onto it.  This is done by mounting the ISO image as a “loop” filesystem:

# mount -o loop,ro Fedora-12-i386-DVD.iso /mnt
# mount -t cifs -o username=admin //nas/Fedora12 /mnt2
# cd /mnt2
# tar c /mnt | tar xv

One of the options was to install via http, but after enabling http on the NAS and attempting the installation, the installer crashed.  I then enabled NFS and used it successfully for the install.

Graphics

I have an Nvidia graphics board in my system, and as a result the upgrade didn’t have working graphics when it installed.  I disabled the ‘nouveau’ video driver (although not sure that was necessary) and installed the nvidia_kmon package and graphics started working again.

Non-standard software

As expected, I needed to recompile the sendmail ‘milters’ that I use for SenderID (sid_milter) and DKIM (opendkim), since they’re not part of the standard Fedora distribution.  I also found that I needed to re-install the python_daemon package used by my solar power data connection daemon.

PostgreSQL

I had only recently started using PostgreSQL, since it is used by the DAViCal calendar server I installed recently.  I discovered the hard way that new versions (such as 8.3->8.4) of PostgreSQL change the structure of the data they store on disk in a way that is incompatible with previous versions.  I should have backed up the PostgreSQL database prior to the upgrade, but didn’t (since I had backed up the entire disk).  After checking a few machines I have access to and finding the proper (old) version of PostgreSQL on none of them, I gave up and recreated the database.  I hadn’t lost that much because we had just started using the calendar server.  A lesson for the future, though.

BIND

I operate a BIND name server on my system for my domain and as a secondary for a couple of friends’ domains.  My DNS has two views:  An internal view that includes hosts on NATted networks available only internally, and an external view that shows only public addresses.  The internal view allows recursion since internally we use my Linux machine as the primary name server, but this stopped working.  A little research revealed a change that was made in BIND 9.4.1P1 on the configuration of allowing recursion.  Rather than the ‘recursion no;’ or ‘recursion yes;’ statements in the view definitions in the BIND configuration file, these statements are needed in the general section of the file:

allow-recursion { mylan; };
allow-query { any; };
allow-query-cache { mylan; };

DAViCal and PHP

The DAViCal calendar server software uses PHP extensively.  While I have had a little experience with its use in MovableType and MediaWiki, I was unprepared when all I got was a white screen (in the browser window) when trying to use DAViCal.  At first I thought that there was something wrong with my Apache web server configuration, but after considerable testing found that PHP was working correctly, but something happened with respect to DAViCal since Fedora 10.

After much flailing, I found that the configuration line (in the suggested DAViCal configuration for httpd):

php_value error_reporting "E_ALL & ~E_NOTICE"

doesn’t work because the error flag symbols aren’t available to Apache so all error reporting was turned off.  Replacing this with a value of 22527 caused errors to be reported (this value also disables warnings about deprecated code usage).  It was now visible that the setting

php_value open_basedir 1

is the wrong thing; open_basedir takes as its value the list of directories that should be available to PHP scripts.  I replaced this with:

php_value open_basedir "/usr/share/davical/:/usr/share/awl/:/etc/davical:/tmp"

Including /tmp in the open_basedir is perhaps not a best practice, but in this stance it seemed like it would be OK.

With respect to both of these changes, I wonder how it ever worked under Fedora 10.

Reverse Path Filtering

At this point, I should point out that my Linux machine has two interfaces, one to the network with public IP addresses, and one to the NAT (network address translation) network.  The Linux machine does not route packets between the networks though; this and the NAT function is done by a Cisco 881 router.  The primary reason for the interface to the NAT network is to give the Linux machine a direct gigabit Ethernet connection to the network-attached storage box.

I noticed that some nodes within the house were mysteriously not working.  After considerable packet sniffing and head scratching, I found that it was not possible to ping the public IP address of the Linux machine from the NAT network.  The failing hosts were making DNS requests to that public address, which were also failing.

It turns out that by default Fedora 12 is configured by default to perform reverse path filtering, whereby incoming packets are ignored if they aren’t coming from the interface having a route to the source address.  In order to change this, one needs to edit /etc/sysctl.conf to change the line:

net.ipv4.conf.default.rp_filter = 1

The right-hand side needs to be changed from 1 to 0.  I’m not positive of the default in Fedora 10, but I don’t remember changing this before so I suspect that the default has been changed.

Summary

Having made the above changes, Fedora 12 is working fine, and it’s definitely worth it to be on a release that’s getting bug-fix updates, especially since some of those correct security vulnerabilities.  Perhaps I just wasn’t diligent enough in reading the release notes this time.  In any case, if I run into any problems upgrading to Fedora 14, I’ll know what the new issues are.