Upgrade from Fedora 9 to 10

It went smooth… so I thought…

Oh. wait, this sounds worse than it is… it WENT smooth.. but not totally flawless!.. Here’s what I found out when upgrading Fedora 9 to 10.

First of all, I had my system online and performed a ‘yum upgrade’ to upgrade the system.. After downloading over 800MB of RPMs, the upgrade went well…

Cyrus-imapd

Cyrus-imapd got stressful after the upgrade, due to the incompatible upgrade of db4 from 4.6 to 4.7.

This is what I got when checking the maillog for errors:

Dec 22 18:39:51 thunderbolt cvt_cyrusdb[9261]: DBERROR db4: file /var/lib/imap/deliver.db has LSN 1/807708, past end of log at 1/544
Dec 22 18:39:51 thunderbolt cvt_cyrusdb[9261]: DBERROR db4: Commonly caused by moving a database from one database environment
Dec 22 18:39:51 thunderbolt cvt_cyrusdb[9261]: DBERROR db4: to another without clearing the database LSNs, or by removing all of
Dec 22 18:39:51 thunderbolt cvt_cyrusdb[9261]: DBERROR db4: the log files from a database environment
Dec 22 18:39:51 thunderbolt cvt_cyrusdb[9261]: DBERROR db4: /var/lib/imap/deliver.db: unexpected file type or format
Dec 22 18:39:51 thunderbolt cvt_cyrusdb[9275]: DBERROR db4: file /var/lib/imap/tls_sessions.db has LSN 1/703034, past end of log at 1/544
Dec 22 18:39:51 thunderbolt cvt_cyrusdb[9275]: DBERROR db4: Commonly caused by moving a database from one database environment
Dec 22 18:39:51 thunderbolt cvt_cyrusdb[9275]: DBERROR db4: to another without clearing the database LSNs, or by removing all of
Dec 22 18:39:51 thunderbolt cvt_cyrusdb[9275]: DBERROR db4: the log files from a database environment
Dec 22 18:39:51 thunderbolt cvt_cyrusdb[9275]: DBERROR db4: /var/lib/imap/tls_sessions.db: unexpected file type or format

As usual I forgot some administrative precautions.. like this cyrus-imapd which should have been taken offline before the upgrade.. because of the db4 upgrade, the cyrus-imapd was unable to dump the old ‘deliver.db’ and ‘tls_sessions.db’. Without the dump, a restart of the daemon (with the new db4 libraries) were not possible to read the mentioned database files, causing an error when stopping the daemon.

While I read it was easy and safe to remove the mentioned files and start up the server, it was my honor of making a dump of the databases manually and loading them in an upgraded version of the database. Here’s how I did this..

# cd /var/lib/imap
# db_dump deliver.db >deliver.db.dump
# rm deliver.db
# db_load -f deliver.db.dump deliver.db
# db_dump tls_sessions.db >~/tls_sessions.db.dump
# rm tls_sessions.db
# db_load -f ~/tls_sessions.db.dump tls_sessions.db

This, of course while the imapd is stopped… after this the daemon works as expected.. This is a simple action, but not done very often if you are not inclined in this manual work… easy when described for future reference 🙂

SELinux

Yep, also SELinux caused little trouble after the upgrade.. Being familiar with SELinux, it was no problem for me to recover the errors at hand, but it needs to be mentioned..

As it turned out, the /home/ directories got a weird situation in SELinux contexts, where (and here’s where I found out) sshd isn’t able to retrieve pubkeys / authorized_keys entries. A simple restorecon fixed the issue though..

maia-mailguard

After the upgrade, mail didn’t get checked by maia-mailguard. This was due to a change in the Crypt::CBC perl module. No solution I could find was satisfying (downgrade Crypt::CBC because it breaks when above 2.24). I found that at (or around) line 2993 the Crypt::CBC module is initialized using a key. This has to be untainted before getting used. Not reading in depth about this, I found out this solution helps and satisfied my system:

— amavisd.org    2008-12-23 07:52:59.000000000 +0100
+++ amavisd    2008-12-23 07:53:37.000000000 +0100
@@ -2990,7 +2990,7 @@
require Crypt::CBC;

$key = $1 if $key =~ /^([^\0]{56})$/si; # untaint
–    $cipher = Crypt::CBC->new( {‘key’ => $key,
+    $cipher = Crypt::CBC->new( {‘key’ => untaint($key),
‘cipher’ => ‘Blowfish’,
‘regenerate_key’ => 0,
‘padding’ => ‘null’,

Any more?

As the upgrade was rather smooth, I am not fully convinced what more I can run into… My checks aren’t complete yet. I will add my possible findings to this post.