Verifying if everything is ok after upgrading to db-4.1.25 ?

[Christian Schulte]

Hello all,

I just upgraded my 2.2-cvs installation from berkeley db-3.2 to db-4.1. 
The new system now seems to work properly. I had to do some things for 
which I would like to know if they may cause future trouble.
First of all I would need to know what these directories are used for 
exactly:

configdirectory/db
configdirectory/db.backup1
configdirectory/db.backup2

To be able to start the old installation if anything goes wrong during 
the upgrade I kept the old configdirectory and defaultpartition in 
theire places and copied them to completely other locations for use with 
the new db-4.1 installation.

So here is what I did exactly:

1. Copied the old default partition /var/spool/imap to 
/var/opt/spool/imap without loosing permissions or timeinformation.
2. Copied the old configuration directory /var/imap to /var/opt/imap the 
same way
3. With the new ctl_mboxlist binary:
$> cd /var/opt/imap (the duplicated new configdirectory)
$> ctl_mboxlist -d > mboxlist.dump
$> mv mailboxes.db mailboxes.db.old
$> ctl_mboxlist -u < mboxlist.dump
$> diff mailboxes.db mailboxes.db.old
Binary files mailboxes.db and mailboxes.db.old differ
---snip---

If I now start the new db-4.1 installation by letting all tools read 
another default imapd.conf (changed in config.h at compiletime; I think 
idled does not support -C option right now ?) I get lots of DB4ERROR: 
entries in syslog and nothing works.

After reading doc/install-configure.html I now first tried to setup the 
new db-4.1 installation to run without any existing old data just as if 
it would get installed for the very first time. One of the steps 
required to do was to run mkimap on the empty configdirectory.
Doing so will not create configdirectory/db.backup1 and 
configdirectory/db.backup2 directories nor does the db directory contain 
any file after. So I did:

---snip---
$> rm -r db.backup*
$> rm db/*
---snip---

Now starting the new installation some DB4ERROR: entries disappeared but 
  things still did not work. After stopping cyrus I inspected the 
configdirectory to see what had changed and saw that cyrus created the
db.backup1 directory and some files in the db directory. I now spent 
several hours on getting things to run and found out the following:

1. Setting the umask in the imapd.conf file does not leed to cyrus using 
it as specified. Even setting an umask in imapd.conf of 000 or even 
00000 really does not lead to make cyrus create the files in db/ and 
even db.backup directories with rwxrwxrwx!
The point where I looked at before giving up on umask issues was in 
imap/global.c on the following lines:

140     /* Look up umask */
141     val = config_getstring(IMAPOPT_UMASK);
142     while (*val) {
143         if (*val >= '0' && *val <= '7') umaskval = umaskval*8 + *val 
- '0';
144         val++;
145     }
146     umask(umaskval);

I cannot check if this really does what I expect it to do but for me the 
  umask value in imapd.conf does not work! Setting umask:000 makes cyrus 
create the db.backup directories like

drwxr-xr-x   2 cyrus    bin          512 Mär 28 05:38 db.backup1

and this should be

drwxrwxrwx   2 cyrus    bin          512 Mär 28 05:38 db.backup1

or am I wrong ?


2. After the start of the new db-4.1 installation cyrus created some 
files in the db directory but stated DB4ERROR:s on deliver.db and 
tls_sessions.db. So I did:

---snip---
$> mv deliver.db deliver.db.old
$> mv tls_sessions.db tls_sessions.db.old
--snip---

At this point the new installation would have started if I would have 
erased all files previously created in the db directory because cyrus 
now stated DB4ERROR:s for files in the db directory which I absolutely 
did not understand for hours....
As it seems to me cyrus tried to archive the old deliver.db and 
tls_sessions.db to some files in the db directory which lead to 
corrupting something therein. After repeating

---snip---
$> rm -r db.backup*
$> rm db/*
---snip---

and now restarting without any db file (I think/hope ?!) being from the 
old db-3.2 installation everything seems to work for now! But what have 
I lost ? What exactly is deliver.db used for ? (I think used for the 
duplicate delivery suppression ?) Did I loose any data because of not 
being able to re-use the old db-3.2 file ? The same for tls_sessions.db 
? Is there anything I need to do else ? The system is currently being 
configured like the following and everything seems to work. But will it 
also work next week/month/year ? Am I missing something ?

checking for db_create in -ldb-4.1... no <<< yes for the new cyrus
checking for db_create in -ldb4.1... no
checking for db_create in -ldb-4.0... no
checking for db_create in -ldb4.0... no
checking for db_create in -ldb-4... no
checking for db_create in -ldb4... no
checking for db_create in -ldb-3.3... no
checking for db_create in -ldb3.3... no
checking for db_create in -ldb-3.2... yes <<< no for the new cyrus
checking "duplicate db" database backend... berkeley_nosync
checking "mboxlist" database backend... skiplist
checking "seen state" database backend... skiplist
checking "pts" database backend... berkeley
checking "subscription" database backend... flat
checking "TLS cache" database backend... berkeley_nosync
checking "netnews db" database backend... berkeley


Thanks for your help!


--Christian--