Fedora 9 Server Upgrade Experiences

I recently upgraded my aging server from Fedora 7 --> Fedora 9, now that the 7th distribution is no longer supported. Fedora 7 was an old favorite, a trouble-free experience to both my laptop and server, a 7th-inning stretch if you will. But alas it's baseball season, and the 9th inning has arrived, and it's come time to get on board before the game is over. As usual I'm providing a summary of my experiences in case you might find it useful for your own upgrade.

Netinst Installation CD

My server dates back from the last millenium and is pushing a decade since its birth in 1999. A Pentium III 450 MHz, it's done its share of work but presses on. Even if it doesn't have a DVD drive. I needed a way to install by CD, and rather than downloading the entire 6-volume set, I learned that new to Fedora 9 is a "netinst" disc image that replaces boot.iso, rescue.iso, and diskboot.img and provides "everything the user needs to install a system over the network."

It serves as a small disc that contains just enough to run the installer, download the files for an installation, and even rescue a system. One just needs to remember to point the URL to the official Fedora 9 release rpms, such as http://mirrors.kernel.org/fedora/releases/9/Fedora/i386/os, or of course to a local repository of mirrored Fedora files.

During the upgrade, my internet connection went down, and the netinst install failed at the final file. Not to fear. A retry completed the upgrade, and Fedora 9 came to life on my server.

Web Server Down!

A quirk from the initial release of Fedora 9 is that the httpd Apache web server failed to start on several of my machines. Apparently some libphp module couldn't be found, and the server never started. Again, not to fear. A sudo yum update resuscitated httpd, and it started serving pages immediately.

Subversion Subverted

While updating some CCF web files, I found that I couldn't commit my changes to the server. I got

can't open db activity permission denied

error messages when running svn commit commands. At first I thought that the permission bits had been misapplied, or perhaps files had been overwritten by a different user, but even setting permissions to 777 failed to permit commits.

Eventually I came across a solution on a Fedora forum that pointed to an SELinux context error. Apparently during the upgrade, the security labels got changed, flagging SELinux to prevent those files' usage. One workaround was to switch SELinux from "enforcing" to "permissive" mode via

sudo /usr/sbin/setenforce 0

Of course this change dramatically alters security just for Subversion. An alternative solution is to restore the context of the Subversion files. I saw "httpd_sys_content" several times in forums but didn't find the label to solve permission erros on my machine, so I left the server in permissive mode while making a file commit. One of the files that gets changed during a commit is /path/to/repos/db/current. Using ls -ldZ /path/to/repos/db/current, I found that the file had been labeled to "unconfined_u:object_r:httpd_sys_content_rw_t".

That last bit was what flagged me that a similar "httpd_sys_content" label might work. Using

sudo chcon -R system_u:object_r:httpd_sys_content_rw_t /path/to/repos
sudo /usr/sbin/setenforce 1

I found that I could again commit files with SELinux in enforcing mode. Note that I used "system_u" rather than "unconfined_u" and that SELinux is still much of a mystery to me.

Fun with Fedora? or Fedora frustrations? As with most things Linux, how can there be one without the other?

Comments

Popular Posts