Upgrading to Fedora Core 2
Over a year ago (circa April 2003), I installed a small company network of computers consisting of 3 linux boxen, and 4 windows machines. RedHat 9 was still new at the time, and so I decided to go with RedHat 8 on the Linux machines. Of course I never had the time to administer these machines properly, but since they were behind a firewall, it wasn't a pressing concern. Of course I had to deal with issues like sound cards not working and missing features that eventually showed up in newer software, but life was relatively good with RedHat 8.
Fast forward to summer 2004. In Internet time, we're light years from 2003. RedHat has already put RH9 on end-of-life status and introduced new product lines including Fedora Core. Fedora Core can be called RH10, and since the current version is Fedora Core 2, you might call it RH10.2. There are impressive new software projects available like K3B for burning CDs and K3diff for doing file comparisons and merge operations. Plus there are major advances in existing software like QuantaPlus, OpenOffice.org. And, of course there are major new developments in the underlying systems like X-windows and printing subsystems. With the advances in MySQL (sub-selects) and PHP (version 5) to round out the list, there are too many reasons why I must upgrade these systems to work efficiently.
Upgrading, it seems, is not well handled by patching your existing system, but instead must be done from a fresh install. The first approach is fraught with the conflicts of third-party applications that you've installed and are now included in the base distribution. Your distributor (RedHat) can not be expected to control all the things you do with your environment, so it's not reasonable to expect the distributor to write an installer that perfectly handles all the unique software and configuration you've done to personalize their original distribution. Of course, if you kept scrupulous records of everything you did to change the system and everything that the distributor did to change their system, you could theoretically plan and execute an upgrade. But that's not gonna happen. So on to plan 'b'
Install the fresh system, and using backups of your various files, you restore the personality of your old system to the new system. When I say 'your files' I mean: configuration files, scripts, crontab entries, databases, CVS repositories, personal files, resource configuration files etc. It's not a trivial matter.
Oh well.
I got through it in about a day, without even going through a detailed preparation and planning effort. Here then are some of the things that I learned along the way.
Cervisia is hard to find when installing FC2 (I thought I had, but it could not be found on my system) Cervisia is hard to find on the Internet. I could find the project page, and know that it's part of the KDE project, but it was not obvious what part of KDE it lived in, and for that matter what part of KDE I was missing. It turns out that Cervisia is part of KDE called KDESDK. Knowing that, you can install Cervisia on Fedora Core 2 with
yum install KDESDK
Aparently a new replacement for inetd came into existence around 2002, but inetd is still widely used today. FC2 implements the new replacement called xinetd. In my particular case, I was moving a CVS server from one machine to another, and the pserver access method would no longer work. This is because the syntax that I was using in the /etc/inetd.d/cvspserver file was the old syntax instead of the new form. Even the 'Cederqvist' tells you to use the old syntax
