Cyrus IMAPd 2.3.10 Released

[Ken Murchison]

Ian G Batten wrote:
> 
> On 25 Oct 07, at 1230, Ian G Batten wrote:
> 
>>
>>
>> I've just compiled 2.3.10 on batten.eu.org (my private x86 servers) 
>> and although it looks OK on the Solaris 10 system, it's in deep 
>> trouble on the elderly Linux machine.  Both are upgrades from 2.3.7, 
>> the Solaris box is a replication target, the Linux box is a 
>> replication master that handles deliver and reading.  The intent is to 
>> swap them over, and that intent might come sooner than I planned.
>>
>> LSUB produces expected output, LIST doesn't (to put it mildly) and 
>> examine/select can't select anything.  strace on the running imapd 
>> shows it's doing roughly sensible things: finding the correct 
>> partition and metapartition from the mailbox database, opening the 
>> metadata files correctly, but then it says NO.  I've reconstructed the 
>> mailbox, dumped and reloaded (ctl_mboxlist -d // ctl_mboxlist -u) the 
>> mailboxes file and run reconstruct -G ``in case it makes any odds''.  
>> No joy.  And nothing useful in the logs, either...
> 
> Re-installing 2.3.7 has everything back working again (apart from 
> replication to the now-2.3.10 replication target: I assume 2.3.7 master, 
> 2.3.10 replica isn't supported).  The Linux machine is very, very old 
> (2.4.20, but the userland is a massively patched and upgraded Redhat 
> 7.1).  Looking at master's logs on 2.3.10 shows a lot of imapd processes 
> getting signal 11: I'm going to hunt for the coredumps and see what's 
> causing the issue.  The version of db is very old, but I'm not using any 
> db format databases any more.
> 
> [igb at offsite igb]$ ldd /usr/cyrus/bin/imapd
>         libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x40020000)
>         libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x40032000)
>         libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x40061000)
>         libresolv.so.2 => /lib/libresolv.so.2 (0x40122000)
>         libdb-3.1.so => /lib/libdb-3.1.so (0x40134000)
>         libnsl.so.1 => /lib/libnsl.so.1 (0x401ad000)
>         libc.so.6 => /lib/i686/libc.so.6 (0x401c4000)
>         libdl.so.2 => /lib/libdl.so.2 (0x40300000)
>         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
> [igb at offsite igb]$
> 
> [igb at offsite igb]$ cat /etc/imapd.conf
> configdirectory: /var/imap
> partition-default: /var/imap/messages
> metapartition_files: header index cache expunge squat
> metapartition-default: /var/imap/metadata
> sievedir: /var/imap/sieve
> imap_admins: offsite
> lmtp_admins: deliver
> sasl_pwcheck_method: auxprop
> expunge_mode: delayed
> 
> imaps_tls_cert_file: /var/imap/certs/imap-cert.pem
> imaps_tls_key_file: /var/imap/certs/imap-private.pem
> imap_tls_cert_file: /var/imap/certs/imap-cert.pem
> imap_tls_key_file: /var/imap/certs/imap-private.pem
> 
> # there is no STARTTLS for POP3, so this can only happen over port 995
> pop3s_tls_cert_file: /var/imap/certs/pop-cert.pem
> pop3s_tls_key_file: /var/imap/certs/pop-private.pem
> 
> # there is ONLY STARTTLS for LMTP, so the service name is always lmtp
> lmtp_tls_cert_file: disabled
> lmtp_tls_key_file: disabled
> 
> # same for everyone
> tls_ca_path: /var/imap/certs/ca
> 
> sasl_maximum_layer: 0
> tls_cipher_list: RC4
> idled_shutdown_check: 0

Are you applying third-party patches?  'idled_shutdown_check' isn't a 
valid option in the stock distro.

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University