Default ACL for new user mailbox
Hello, Is it somehow possible to set a default ACL which a new mailbox will inherit when I create it with cyradm ? What I would like to do is give automatically full permissions to all new mailboxes to the cyrus administrator. Or maybe there is another way to do that ? Regards Marc
Re: Thoughts on the age-old cyradm thingie
Jay Levitt wrote: I'm new to Cyrus imapd - and, for that matter, to autoconf, perl, Linux, younameit. Building cyrus-imapd-2.1.10 on Mandrake 9.0, I ran into a http://perso.wanadoo.es/olivetti/cyrus/ -- Luca Olivetti Wetron Automatización S.A. http://www.wetron.es/ Tel. +34 93 5883004 Fax +34 93 5883007
Re: Preserving flags, and their global nature
Unfortunately for me, I think that my client (the Mail::IMAPClient perl module) only supports LOGIN. - Original Message - From: Rob Siemborski [EMAIL PROTECTED] To: Ian McDonald [EMAIL PROTECTED] Sent: Friday, November 15, 2002 7:45 PM Subject: Re: Preserving flags, and their global nature On Fri, 15 Nov 2002, Ian McDonald wrote: So central is this requirement to my helpdesk application, that I'm considering storing all the passwords in plain text in order to do just that :( :( :(. Administrative users can authorize as any user they want without needing the user's password (sort of like root can su to whatever userid it wants). You just need a SASL mechanism that supports authorization (basically, all of them except LOGIN and CRAM-MD5). -Rob
Re: Default ACL for new user mailbox
Heyho, Is it somehow possible to set a default ACL which a new mailbox will inherit when I create it with cyradm ? What I would like to do is give automatically full permissions to all new mailboxes to the cyrus administrator. Or maybe there is another way to do that ? Read ' man 5 imapd.conf ' respectively '/etc/imapd.conf' and look for defaultacl:. Its just for your problem. If you want to give acls to more than one user, you can do it this way: defaultacl: user1 acl1 user2 acl2 ... Regards and HTH Marko D. -- Home: http://www.mdam.de 1st / 2nd March 2003 5th Chemnitz LinuxTag http://www.tu-chemnitz.de/linux/tag +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
DBERROR: error listing log files: Permission denied
After doing cvs update on my perfectly running 2.2 installation these messages appear in the logs which did not happen before I did the update! Is that anything serious ? Can it be ignored ? What changed that this suddenly happens ? Nov 18 12:53:36 mail ctl_cyrusdb[7462]: [ID 854764 local6.error] DBERROR: error listing log files: Permission denied Nov 18 12:53:36 mail ctl_cyrusdb[7462]: [ID 686478 local6.error] DBERROR: archive /var/imap/db: cyrusdb error Nov 18 12:53:36 mail ctl_cyrusdb[7462]: [ID 854764 local6.error] DBERROR: error listing log files: Permission denied Nov 18 12:53:36 mail ctl_cyrusdb[7462]: [ID 686478 local6.error] DBERROR: archive /var/imap/db: cyrusdb error
Please help! Probs with cyrus-imapd 2.1.9 and db3 - DBERROR db3: Unable to allocate memory
Hello, i successfully compiled cyrus-imapd 2.1.9 with SASL 2.1.9 and Berkeley DB 3.1.17 on a Sun Sparc 10 with SuSE 7.3 and 128MB RAM and get the following errors in /var/log/messages after starting the '/usr/cyrus/bin/master' process and try to test it via 'telnet prime 143'. Telnet opens the connection and then 'hangs' - no prompt from the imap-Server. I read the mailinglist-archives, searched the SuSE Help-DB and read the FAQ's but didnt find anything that solves the problem. I only found questions from users with the same problem - but no answers. Please help! :) cyrus-imapd is configured with: ./configure --prefix=/opt/local/cyrus_imapd --with-cyrus-user=mail --with-cyrus-group=nogroup --with-dbdir=/opt/local/db3 --disable-sieve --with-auth=unix # --- /var/log/messages - Nov 18 13:24:06 prime master: setrlimit: Unable to set file descriptors limit to 2147483647: Operation not permitted Nov 18 13:24:06 prime master[25357]: process started Nov 18 13:24:06 prime master[25358]: about to exec /usr/cyrus/bin/ctl_cyrusdb Nov 18 13:24:06 prime ctl_cyrusdb[25358]: recovering cyrus databases Nov 18 13:24:09 prime ctl_cyrusdb[25358]: DBERROR db3: Unable to allocate memory for the lock table Nov 18 13:24:42 prime ctl_cyrusdb[25358]: DBERROR: dbenv-open '/var/imap/db' failed: Cannot allocate memory Nov 18 13:24:42 prime ctl_cyrusdb[25358]: DBERROR: init /var/imap/db: cyrusdb error Nov 18 13:24:42 prime ctl_cyrusdb[25358]: DBERROR db3: environment not yet opened Nov 18 13:24:42 prime ctl_cyrusdb[25358]: DBERROR: opening /var/imap/mailboxes.db: Invalid argument Nov 18 13:24:42 prime ctl_cyrusdb[25358]: DBERROR: opening /var/imap/mailboxes.db: cyrusdb error Nov 18 13:24:42 prime master[25357]: process 25358 exited, status 75 Nov 18 13:24:42 prime master[25357]: ready for work Nov 18 13:24:42 prime master[25360]: about to exec /usr/cyrus/bin/ctl_cyrusdb Nov 18 13:24:42 prime master[25361]: about to exec /usr/cyrus/bin/ctl_deliver Nov 18 13:24:42 prime master[25362]: about to exec /usr/cyrus/bin/tls_prune Nov 18 13:24:42 prime ctl_cyrusdb[25360]: checkpointing cyrus databases Nov 18 13:24:45 prime ctl_cyrusdb[25360]: DBERROR db3: Unable to allocate memory for the lock table Nov 18 13:24:47 prime master[25363]: about to exec /usr/cyrus/bin/imapd Nov 18 13:24:47 prime imap[25363]: executed Nov 18 13:24:48 prime tls_prune[25362]: DBERROR db3: Unable to allocate memory for the lock table Nov 18 13:24:49 prime ctl_cyrusdb[25360]: DBERROR: dbenv-open '/var/imap/db' failed: Cannot allocate memory Nov 18 13:24:49 prime ctl_cyrusdb[25360]: DBERROR: init /var/imap/db: cyrusdb error Nov 18 13:24:49 prime ctl_cyrusdb[25360]: done checkpointing cyrus databases Nov 18 13:24:49 prime master[25357]: process 25360 exited, status 1 Nov 18 13:24:53 prime ctl_deliver[25361]: DBERROR db3: Unable to allocate memory for the lock table Nov 18 13:24:55 prime tls_prune[25362]: DBERROR: dbenv-open '/var/imap/db' failed: Cannot allocate memory Nov 18 13:24:55 prime tls_prune[25362]: DBERROR db3: environment not yet opened Nov 18 13:24:55 prime tls_prune[25362]: DBERROR: opening /var/imap/tls_sessions.db: Invalid argument Nov 18 13:24:56 prime tls_prune[25362]: DBERROR: opening /var/imap/tls_sessions.db: cyrusdb error Nov 18 13:24:56 prime master[25357]: process 25362 exited, status 1 Nov 18 13:24:57 prime ctl_deliver[25361]: DBERROR: dbenv-open '/var/imap/db' failed: Cannot allocate memory Nov 18 13:24:57 prime ctl_deliver[25361]: DBERROR: init /var/imap/db: cyrusdb error Nov 18 13:24:57 prime master[25357]: process 25361 exited, status 1 Nov 18 13:25:01 prime imapd[25363]: DBERROR db3: Unable to allocate memory for the lock table Nov 18 13:25:02 prime imapd[25363]: DBERROR: dbenv-open '/var/imap/db' failed: Cannot allocate memory Nov 18 13:25:02 prime master[25357]: process 25363 exited, status 75 # --- second try: 18 13:37:47 prime master: setrlimit: Unable to set file descriptors limit to 2147483647: Operation not permitted Nov 18 13:37:47 prime master[25386]: process started Nov 18 13:37:48 prime master[25387]: about to exec /usr/cyrus/bin/ctl_cyrusdb Nov 18 13:37:48 prime ctl_cyrusdb[25387]: recovering cyrus databases Nov 18 13:37:48 prime master[25386]: process 25387 exited, signaled to death by 11 Nov 18 13:37:48 prime master[25386]: ready for work Nov 18 13:37:48 prime master[25388]: about to exec /usr/cyrus/bin/ctl_cyrusdb Nov 18 13:37:48 prime master[25389]: about to exec /usr/cyrus/bin/ctl_deliver Nov 18 13:37:48 prime master[25390]: about to exec /usr/cyrus/bin/tls_prune Nov 18 13:37:48 prime ctl_cyrusdb[25388]: checkpointing cyrus databases Nov 18 13:37:48 prime ctl_cyrusdb[25388]: DBERROR db3: region error detected; run recovery. Nov 18 13:37:48 prime ctl_cyrusdb[25388]: DBERROR: dbenv-open '/var/imap/db' failed: DB_RUNRECOVERY: Fatal error, run database recovery Nov 18 13:37:48 prime ctl_cyrusdb[25388]: DBERROR: init /var/imap/db: cyrusdb error Nov 18 13:37:48 prime
Re: Default ACL for new user mailbox
Hi, Well if I read the imapd.conf man page again it states the following: defaultacl: anyone lrs The Access Control List (ACL) placed on a newly-created (non-user) mailbox that does not have a parent mailbox. What I can see here which disturbs me is the ...(non-user) mailbox... part and what I am creating are user mailboxes like user.testuser or user.testser.myfolder, so this doesn't work for my case... Any other ideas ? Regards Marc [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: [EMAIL PROTECTED] 11/18/02 12:31 Subject: Re: Default ACL for new user mailbox PM Heyho, Is it somehow possible to set a default ACL which a new mailbox will inherit when I create it with cyradm ? What I would like to do is give automatically full permissions to all new mailboxes to the cyrus administrator. Or maybe there is another way to do that ? Read ' man 5 imapd.conf ' respectively '/etc/imapd.conf' and look for defaultacl:. Its just for your problem. If you want to give acls to more than one user, you can do it this way: defaultacl: user1 acl1 user2 acl2 ... Regards and HTH Marko D. -- Home: http://www.mdam.de 1st / 2nd March 2003 5th Chemnitz LinuxTag http://www.tu-chemnitz.de/linux/tag +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
Re: Please help! Probs with cyrus-imapd 2.1.9 and db3 - DBERROR db3: Unable to allocate memory
On Mon, Nov 18, Marc Sebastian Pelzer wrote: i successfully compiled cyrus-imapd 2.1.9 with SASL 2.1.9 and Berkeley DB 3.1.17 on a Sun Sparc 10 with SuSE 7.3 and 128MB RAM and get the following errors in /var/log/messages after starting the '/usr/cyrus/bin/master' process and try to test it via 'telnet prime 143'. Telnet opens the connection and then 'hangs' - no prompt from the imap-Server. I read the mailinglist-archives, searched the SuSE Help-DB and read the FAQ's but didnt find anything that solves the problem. I only found questions from users with the same problem - but no answers. Please help! :) You need the attached patch for the bdb3. -- With best regards, Carsten Hoeger SuSE, The Linux Experts, http://suse.com - http://unitedlinux.com --- db-3.1.17/./lock/lock_region.c~ Tue May 30 04:31:14 2000 +++ db-3.1.17/./lock/lock_region.c Tue Mar 19 14:22:14 2002 @@ -686,17 +686,17 @@ * map one-to-one with the __db_shalloc calls in __lock_init. */ retval = 0; - retval += ALIGN(sizeof(DB_LOCKREGION) + gb, 1); - retval += ALIGN(dbenv-lk_modes * dbenv-lk_modes + gb, 1); - retval += ALIGN(nelements * (sizeof(DB_HASHTAB) + gb), 1); - retval += ALIGN(nelements * (sizeof(DB_HASHTAB) + gb), 1); + retval += ALIGN(sizeof(DB_LOCKREGION) + gb, sizeof(db_align_t)); + retval += ALIGN(dbenv-lk_modes * dbenv-lk_modes + gb, sizeof(db_align_t)); + retval += ALIGN(nelements * (sizeof(DB_HASHTAB) + gb), sizeof(db_align_t)); + retval += ALIGN(nelements * (sizeof(DB_HASHTAB) + gb), sizeof(db_align_t)); for (i = 0; i nlocks; ++i) retval += ALIGN(sizeof(struct __db_lock) + gb , MUTEX_ALIGN); for (i = 0; i nlocks; ++i) - retval += ALIGN(sizeof(DB_LOCKOBJ) + gb , 1); + retval += ALIGN(sizeof(DB_LOCKOBJ) + gb , sizeof(db_align_t)); for (i = 0; i nlocks; ++i) - retval += ALIGN(sizeof(DB_LOCKER) + gb , 1); + retval += ALIGN(sizeof(DB_LOCKER) + gb , sizeof(db_align_t)); /* * Aproximate the memory allocation overhead. This breaks the msg09290/pgp0.pgp Description: PGP signature
Re: DBERROR: error listing log files: Permission denied
Christian Schulte wrote: After doing cvs update on my perfectly running 2.2 installation these messages appear in the logs which did not happen before I did the update! Is that anything serious ? Can it be ignored ? What changed that this suddenly happens ? Nov 18 12:53:36 mail ctl_cyrusdb[7462]: [ID 854764 local6.error] DBERROR: error listing log files: Permission denied Nov 18 12:53:36 mail ctl_cyrusdb[7462]: [ID 686478 local6.error] DBERROR: archive /var/imap/db: cyrusdb error Nov 18 12:53:36 mail ctl_cyrusdb[7462]: [ID 854764 local6.error] DBERROR: error listing log files: Permission denied Nov 18 12:53:36 mail ctl_cyrusdb[7462]: [ID 686478 local6.error] DBERROR: archive /var/imap/db: cyrusdb error Did you do: make distclean rm configure sh SMakefile ./configure ... make If not, you should. Even if your code compiled cleanly, things frequently change enough to cause weird behavior if you don't do a complete rebuild. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
Re: DBERROR: error listing log files: Permission denied
On Mon, 18 Nov 2002, Christian Schulte wrote: After doing cvs update on my perfectly running 2.2 installation these messages appear in the logs which did not happen before I did the update! Is that anything serious ? Can it be ignored ? What changed that this suddenly happens ? [snip] There was a recent change to init all of the database backends at once, which I suspect is causing this problem What are the permissions on (configdirectory)/db, out of curiosity? -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: DBERROR: error listing log files: Permission denied
Ken Murchison wrote: Christian Schulte wrote: After doing cvs update on my perfectly running 2.2 installation these messages appear in the logs which did not happen before I did the update! Is that anything serious ? Can it be ignored ? What changed that this suddenly happens ? Nov 18 12:53:36 mail ctl_cyrusdb[7462]: [ID 854764 local6.error] DBERROR: error listing log files: Permission denied Nov 18 12:53:36 mail ctl_cyrusdb[7462]: [ID 686478 local6.error] DBERROR: archive /var/imap/db: cyrusdb error Nov 18 12:53:36 mail ctl_cyrusdb[7462]: [ID 854764 local6.error] DBERROR: error listing log files: Permission denied Nov 18 12:53:36 mail ctl_cyrusdb[7462]: [ID 686478 local6.error] DBERROR: archive /var/imap/db: cyrusdb error Did you do: make distclean rm configure sh SMakefile ./configure ... make If not, you should. Even if your code compiled cleanly, things frequently change enough to cause weird behavior if you don't do a complete rebuild. I just did that again but the error did not disappear ! I wonder what happened right now, because nothing was changed than cvs update;rm configure;./SMakefile;./configure --same-options-than-before;make;make install and then there are these messages in the log althought the imapd seems to work propperly ?!?
Re: DBERROR: error listing log files: Permission denied
Rob Siemborski wrote: On Mon, 18 Nov 2002, Christian Schulte wrote: After doing cvs update on my perfectly running 2.2 installation these messages appear in the logs which did not happen before I did the update! Is that anything serious ? Can it be ignored ? What changed that this suddenly happens ? [snip] There was a recent change to init all of the database backends at once, which I suspect is causing this problem What are the permissions on (configdirectory)/db, out of curiosity? -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper schulte-15:19:47:~ ls -l /var/imap total 464 drwxr-xr-x 2 cyrussmmsp512 Nov 12 18:06 db drwx-- 2 cyrussmmsp512 Nov 18 15:12 db.backup1 drwx-- 2 cyrussmmsp512 Nov 18 14:45 db.backup2 -rw--- 1 cyrussmmsp 172032 Nov 18 15:12 deliver.db drwxr-xr-x 5 cyrussmmsp512 Nov 8 16:40 domain drwxr-xr-x 2 cyrussmmsp512 Okt 21 18:54 log -rw--- 1 cyrussmmsp 11600 Nov 15 03:06 mailboxes.db drwxr-xr-x 2 cyrussmmsp512 Okt 21 18:54 msg drwxr-xr-x 2 cyrussmmsp 3072 Nov 18 14:54 proc drwxr-xr-x 28 cyrussmmsp512 Okt 21 18:54 quota drwxr-xr-x 2 cyrussmmsp512 Nov 18 08:03 socket -rw--- 1 cyrussmmsp 32768 Nov 18 06:03 tls_sessions.db drwxr-xr-x 28 cyrussmmsp512 Okt 21 18:54 user schulte-15:19:50:~ ls -l /var/imap/db total 30850 -rw-rw 1 cyrussmmsp 16384 Nov 12 18:06 __db.001 -rw-rw 1 cyrussmmsp 270336 Nov 15 18:10 __db.002 -rw-rw 1 cyrussmmsp 98304 Nov 12 18:06 __db.003 -rw-rw 1 cyrussmmsp18563072 Nov 12 18:06 __db.004 -rw-rw 1 cyrussmmsp 24576 Nov 12 18:06 __db.005 -rw-rw 1 cyrussmmsp3187063 Nov 18 15:20 log.01 -rw-rw 1 cyrussmmsp 4 Nov 12 18:06 skipstamp --Christian--
Problems configuring cyrus imap (./configure)
I can't get a successful .configure of the cyrus imap, it keeps complaining about Kerberos DES libraries, which I don't want to use. Tried ./configure --disable-krb4 ./configure --without-krb4 ./configure --with-krb4=no They all return with the same fscking message: checking for des_ecb_encrypt in -ldes... no configure: error: The Kerberos DES library is required for Kerberos support. Of course! I told you I didn't want it, silly computer! Argh. What am I doing wrong? Currentlly using cyrus-imapd-2.1.10 on RH8. Any help appreciated. Tnx in advance. -- Jakob Breivik Grimstveit, [EMAIL PROTECTED], www.grimstveit.net/jakob/ Morvikbotn 341, 5122 Morvik. Heim: 55195667, mob: 48298152, jobb: 55239715 System Integrator, Star Shipping as, [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: DBERROR: error listing log files: Permission denied
How are you invoking ctl_cyrusdb in cyrus.conf? On Mon, 18 Nov 2002, Christian Schulte wrote: Rob Siemborski wrote: On Mon, 18 Nov 2002, Christian Schulte wrote: After doing cvs update on my perfectly running 2.2 installation these messages appear in the logs which did not happen before I did the update! Is that anything serious ? Can it be ignored ? What changed that this suddenly happens ? [snip] There was a recent change to init all of the database backends at once, which I suspect is causing this problem What are the permissions on (configdirectory)/db, out of curiosity? -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper schulte-15:19:47:~ ls -l /var/imap total 464 drwxr-xr-x 2 cyrussmmsp512 Nov 12 18:06 db drwx-- 2 cyrussmmsp512 Nov 18 15:12 db.backup1 drwx-- 2 cyrussmmsp512 Nov 18 14:45 db.backup2 -rw--- 1 cyrussmmsp 172032 Nov 18 15:12 deliver.db drwxr-xr-x 5 cyrussmmsp512 Nov 8 16:40 domain drwxr-xr-x 2 cyrussmmsp512 Okt 21 18:54 log -rw--- 1 cyrussmmsp 11600 Nov 15 03:06 mailboxes.db drwxr-xr-x 2 cyrussmmsp512 Okt 21 18:54 msg drwxr-xr-x 2 cyrussmmsp 3072 Nov 18 14:54 proc drwxr-xr-x 28 cyrussmmsp512 Okt 21 18:54 quota drwxr-xr-x 2 cyrussmmsp512 Nov 18 08:03 socket -rw--- 1 cyrussmmsp 32768 Nov 18 06:03 tls_sessions.db drwxr-xr-x 28 cyrussmmsp512 Okt 21 18:54 user schulte-15:19:50:~ ls -l /var/imap/db total 30850 -rw-rw 1 cyrussmmsp 16384 Nov 12 18:06 __db.001 -rw-rw 1 cyrussmmsp 270336 Nov 15 18:10 __db.002 -rw-rw 1 cyrussmmsp 98304 Nov 12 18:06 __db.003 -rw-rw 1 cyrussmmsp18563072 Nov 12 18:06 __db.004 -rw-rw 1 cyrussmmsp 24576 Nov 12 18:06 __db.005 -rw-rw 1 cyrussmmsp3187063 Nov 18 15:20 log.01 -rw-rw 1 cyrussmmsp 4 Nov 12 18:06 skipstamp --Christian-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Problems configuring cyrus imap (./configure)
--with-auth=unix The error message was just recently made more clear. -Rob On 18 Nov 2002, Jakob Breivik Grimstveit wrote: I can't get a successful .configure of the cyrus imap, it keeps complaining about Kerberos DES libraries, which I don't want to use. Tried ./configure --disable-krb4 ./configure --without-krb4 ./configure --with-krb4=no They all return with the same fscking message: checking for des_ecb_encrypt in -ldes... no configure: error: The Kerberos DES library is required for Kerberos support. Of course! I told you I didn't want it, silly computer! Argh. What am I doing wrong? Currentlly using cyrus-imapd-2.1.10 on RH8. Any help appreciated. Tnx in advance. -- Jakob Breivik Grimstveit, [EMAIL PROTECTED], www.grimstveit.net/jakob/ Morvikbotn 341, 5122 Morvik. Heim: 55195667, mob: 48298152, jobb: 55239715 System Integrator, Star Shipping as, [EMAIL PROTECTED] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
housekeeping of *.db
Dear all, I found numberous error of DBERROR: at my /var/log/messages. It keeps the wrong location of *.db and I would like to do housekeeping on it. Is there any method? Many thanks! Boris --- PLEASE READ: The information contained in this e-mail is confidential and intended for the named recipient(s) only. If you are not an intended recipient of this e-mail you must not copy, distribute or take any further action in reliance upon it and you should delete it and notify the sender immediately. E-mail is not a secure method of communication. GuruBase Technology Limited cannot accept responsibility for the accuracy or completeness of this message or any attachment(s). This transmission could contain viruses, be corrupted, destroyed, incomplete, intercepted, lost or arrive late. If verification of this e-mail is sought then please request a hard copy. Unless otherwise stated any views or opinions presented are solely those of the author and do not represent those of GuruBase Technology Limited. This e-mail is intended for information purposes only.
Re: Please help! Probs with cyrus-imapd 2.1.9 and db3 - DBERROR db3: Unable to allocate memory
On Mon, 18 Nov 2002 14:20:51 +0100 Carsten Hoeger [EMAIL PROTECTED] wrote: Hi, thanks to Carsten for the quick answer. i successfully compiled cyrus-imapd 2.1.9 with SASL 2.1.9 and Berkeley DB 3.1.17 on a Sun Sparc 10 with SuSE 7.3 and 128MB RAM and get the following errors in /var/log/messages after starting the '/usr/cyrus/bin/master' process and try to test it via 'telnet prime 143'. Telnet opens the connection and then 'hangs' - no prompt from the imap-Server. I read the mailinglist-archives, searched the SuSE Help-DB and read the FAQ's but didnt find anything that solves the problem. I only found questions from users with the same problem - but no answers. You need the attached patch for the bdb3. I apply the patch and 'make clean' re-compile db3, SASL and imapd but it doesnt work for me: Nov 18 17:08:55 prime master: setrlimit: Unable to set file descriptors limit to 2147483647: Operation not permitted Nov 18 17:08:55 prime master[7532]: process started Nov 18 17:08:55 prime master[7533]: about to exec /usr/cyrus/bin/ctl_cyrusdb Nov 18 17:08:55 prime ctl_cyrusdb[7533]: recovering cyrus databases Nov 18 17:08:59 prime ctl_cyrusdb[7533]: DBERROR db3: Unable to allocate memory for the lock table Nov 18 17:09:31 prime ctl_cyrusdb[7533]: DBERROR: dbenv-open '/var/imap/db' failed: Cannot allocate memory Nov 18 17:09:31 prime ctl_cyrusdb[7533]: DBERROR: init /var/imap/db: cyrusdb error Nov 18 17:09:31 prime ctl_cyrusdb[7533]: DBERROR db3: environment not yet opened Nov 18 17:09:31 prime ctl_cyrusdb[7533]: DBERROR: opening /var/imap/mailboxes.db: Invalid argument Nov 18 17:09:31 prime ctl_cyrusdb[7533]: DBERROR: opening /var/imap/mailboxes.db: cyrusdb error Nov 18 17:09:31 prime master[7532]: process 7533 exited, status 75 Nov 18 17:09:31 prime master[7532]: ready for work Nov 18 17:09:31 prime master[7534]: about to exec /usr/cyrus/bin/ctl_cyrusdb Nov 18 17:09:31 prime master[7535]: about to exec /usr/cyrus/bin/ctl_deliver Nov 18 17:09:31 prime master[7536]: about to exec /usr/cyrus/bin/tls_prune Nov 18 17:09:31 prime ctl_cyrusdb[7534]: checkpointing cyrus databases Nov 18 17:09:34 prime ctl_cyrusdb[7534]: DBERROR db3: Unable to allocate memory for the lock table Nov 18 17:09:37 prime tls_prune[7536]: DBERROR db3: Unable to allocate memory for the lock table Nov 18 17:09:38 prime ctl_cyrusdb[7534]: DBERROR: dbenv-open '/var/imap/db' failed: Cannot allocate memory Nov 18 17:09:38 prime ctl_cyrusdb[7534]: DBERROR: init /var/imap/db: cyrusdb error Nov 18 17:09:38 prime ctl_cyrusdb[7534]: done checkpointing cyrus databases Nov 18 17:09:38 prime master[7532]: process 7534 exited, status 1 Nov 18 17:09:41 prime ctl_deliver[7535]: DBERROR db3: Unable to allocate memory for the lock table Nov 18 17:09:42 prime tls_prune[7536]: DBERROR: dbenv-open '/var/imap/db' failed: Cannot allocate memory Nov 18 17:09:42 prime tls_prune[7536]: DBERROR db3: environment not yet opened Nov 18 17:09:42 prime tls_prune[7536]: DBERROR: opening /var/imap/tls_sessions.db: Invalid argument Nov 18 17:09:42 prime tls_prune[7536]: DBERROR: opening /var/imap/tls_sessions.db: cyrusdb error Nov 18 17:09:42 prime master[7532]: process 7536 exited, status 1 Nov 18 17:09:43 prime ctl_deliver[7535]: DBERROR: dbenv-open '/var/imap/db' failed: Cannot allocate memory Nov 18 17:09:43 prime ctl_deliver[7535]: DBERROR: init /var/imap/db: cyrusdb error Nov 18 17:09:43 prime master[7532]: process 7535 exited, status 1 Nov 18 17:10:07 prime master[7537]: about to exec /usr/cyrus/bin/imapd Nov 18 17:10:07 prime imap[7537]: executed Nov 18 17:10:10 prime imapd[7537]: DBERROR db3: Unable to allocate memory for the lock table Nov 18 17:10:10 prime imapd[7537]: DBERROR: dbenv-open '/var/imap/db' failed: Cannot allocate memory Nov 18 17:10:10 prime master[7532]: process 7537 exited, status 75 Regards, Marc.
Skiplist / best practice for 2.1 branch
All, Hello, and I must first apologize because I know that what I am asking has been covered before, but I am having a difficult time finding information in the archives. I am still running the 1.6 branch on all of my production servers, and want to bring everything up to 2.1. I have resisted thus far for a few reasons, one being reported problems with Sleepycat DB (as well as grief trying to get all the software on my system to use one particular version of DB). I have done some research on the skiplist algorithm, but am wondering about the cyrus implementation. Is it stable? What is the current recommended/best practice for configuring 2.1.10? Which components should be DB as compared to skiplist? duplicate? mboxlist? seen? subs? tls? I definately favor reliability over performance. Thanks, and pointers to relevant articles or past discussions welcomed. Tim
Re: Please help! Probs with cyrus-imapd 2.1.9 and db3 - DBERROR db3: Unable to allocate memory
On Mon, Nov 18, Marc Sebastian Pelzer wrote: You need the attached patch for the bdb3. I apply the patch and 'make clean' re-compile db3, SASL and imapd but it doesnt work for me: Nov 18 17:08:55 prime master: setrlimit: Unable to set file descriptors limit to 2147483647: Operation not permitted Nov 18 17:08:55 prime master[7532]: process started Nov 18 17:08:55 prime master[7533]: about to exec /usr/cyrus/bin/ctl_cyrusdb Nov 18 17:08:55 prime ctl_cyrusdb[7533]: recovering cyrus databases Nov 18 17:08:59 prime ctl_cyrusdb[7533]: DBERROR db3: Unable to allocate memory for the lock table Sure that you installed the recompiled sasl libraries? -- mit freundlichen Gruessen, Carsten Hoeger SuSE Linux AG, - The Linux Experts - Nuernberg, Germany http://www.suse.de - http://www.unitedlinux.com msg09303/pgp0.pgp Description: PGP signature
DB problem during recovery.
Hello all, I am using cyrus-imapd-2.1.10 and Berkeley DB 4.1.24 for duplicate delivery and tls cache. During database initialization I am always get the following errors: master[22732]: [ID 965400 local6.notice] process started ctl_cyrusdb[22733]: [ID 702911 local6.notice] recovering cyrus databases master[22732]: [ID 970914 local6.error] process 22733 exited, signaled to death by 10 idled[22747]: [ID 275131 local6.notice] skiplist: recovered /opt/Cyrus/var/mailboxes.db (50892 records, 3671372 bytes) in 18 seconds master[22732]: [ID 139525 local6.notice] ready for work ctl_cyrusdb[22993]: [ID 702911 local6.notice] checkpointing cyrus databases tls_prune[22991]: [ID 866726 local6.warning] DBERROR db4: operation not permitted during recovery oceanus tls_prune[22991]: [ID 729713 local6.error] DBERROR: opening /opt/Cyrus/var/tls_sessions.db: Invalid argument oceanus tls_prune[22991]: [ID 729713 local6.error] DBERROR: opening /opt/Cyrus/var/tls_sessions.db: cyrusdb error oceanus ctl_deliver[22992]: [ID 866726 local6.warning] DBERROR db4: operation not permitted during recovery oceanus ctl_deliver[22992]: [ID 729713 local6.error] DBERROR: opening /opt/Cyrus/var/deliver.db: Invalid argument oceanus ctl_deliver[22992]: [ID 729713 local6.error] DBERROR: opening /opt/Cyrus/var/deliver.db: cyrusdb error lmtpd[23000]: [ID 866726 local6.warning] DBERROR db4: operation not permitted during recovery Until now the only way out from this problem is the removal of all __db00x and log under db/ directory Any advice will be highly appreciated. Nikos Voutsinas.
Re: Skiplist / best practice for 2.1 branch
Rob Siemborski wrote: This is in the mailing list about 8 times, but.. duplicate? mboxlist? seen? subs? tls? db3_nosync, skiplist, skiplist, flat, db3_nosync I had nothing but trouble using db3_nosync for duplicate so I would suggest using skiplist as well for duplicate. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Skiplist / best practice for 2.1 branch
Rob Siemborski wrote: On Mon, 18 Nov 2002, Tim Pushor wrote: I have done some research on the skiplist algorithm, but am wondering about the cyrus implementation. Is it stable? I didn't know anyone else was implementing a persistant skiplist. Our implementation is stable (and I thought proprietary). Ahh, I didn't dig deep enough (or notice) that if the various implementations are persistent or just memory resident. What is the current recommended/best practice for configuring 2.1.10? Which components should be DB as compared to skiplist? This is in the mailing list about 8 times, but.. I apologize. I truly couldn't find much on the recommended configuration. duplicate? mboxlist? seen? subs? tls? db3_nosync, skiplist, skiplist, flat, db3_nosync If this truly is a 'best practice', should it be added to the documentation? or to a FAQ? While I'm at it - what does the 'db3' of 'db3_nosync' mean? I have to assume it isn't the version of Berkeley (Sleepycat) DB as one can use 4.1 .. Thanks, Tim
Re: Skiplist / best practice for 2.1 branch
On Mon, 18 Nov 2002, Tim Pushor wrote: db3_nosync, skiplist, skiplist, flat, db3_nosync If this truly is a 'best practice', should it be added to the documentation? or to a FAQ? Some people have claimed problems with berkeley DB in general, but from a theoretical standpoint the above should give the best performance (and ease of use, in the case of subscriptions) While I'm at it - what does the 'db3' of 'db3_nosync' mean? I have to assume it isn't the version of Berkeley (Sleepycat) DB as one can use 4.1 .. It's an anachronism. Berkeley 4.1 is supported as of 2.1.10. In Cyrus 2.2 not only is this documented but it will be the default (and db3 will be renamed berkeley) -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Skiplist / best practice for 2.1 branch
Patrick, What version of Berkeley (Sleepycat) DB were you using? What OS? Thanks, Tim Patrick Boutilier wrote: duplicate? mboxlist? seen? subs? tls? db3_nosync, skiplist, skiplist, flat, db3_nosync I had nothing but trouble using db3_nosync for duplicate so I would suggest using skiplist as well for duplicate.
Re: Skiplist / best practice for 2.1 branch
Tim, RedHat 7.2 with BDB 4.0.14 Tim Pushor wrote: Patrick, What version of Berkeley (Sleepycat) DB were you using? What OS? Thanks, Tim Patrick Boutilier wrote: duplicate? mboxlist? seen? subs? tls? db3_nosync, skiplist, skiplist, flat, db3_nosync I had nothing but trouble using db3_nosync for duplicate so I would suggest using skiplist as well for duplicate.
Re: Skiplist / best practice for 2.1 branch
On Mon, 18 Nov 2002, Tim Pushor wrote: duplicate? mboxlist? seen? subs? tls? db3_nosync, skiplist, skiplist, flat, db3_nosync For Linux: 1. Heavily tested and debugged AND patched BerkeleyDB 3.2, stay away from 4.x for now. (i.e. use the ones from RedHat or Debian, not upstream). 2. Linux stability patches for Cyrus (see the Debian Cyrus package :-) Cyrus upstream source works wonderfuly on Solaris, but not in Linux. I think some of the RPMs distributed by people in this list have many, if not all the patches recommended by me and the fastmail.fm crew. 3. Use the db3_nosync, skiplist, skiplist, flat, db3_nosync like Rob recommended. 4. Journaling filesystem (xfs, ext3, Reiser), in a 2.4.20pre kernel. For other OS: I have no idea :-) but it is unlikely the answers above are correct for them. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: Skiplist / best practice for 2.1 branch
On 18 Nov 2002, Henrique de Moraes Holschuh writes: For Linux: 1. Heavily tested and debugged AND patched BerkeleyDB 3.2, stay away from 4.x for now. (i.e. use the ones from RedHat or Debian, not upstream). Red Hat now supplies 4.0.14, for example the db4-4.0.14-14.i386.rpm in Red Hat 8.0. It appears to work OK for me, but we have small setups only here... maybe we have just not met the bug(s) yet?? In general, though the statement Use 3.2... ie. use the ones from RedHat or Debian ... is confusing, because for Red Hat 8.x users, the current RH-supplied production release of these libraries is now 4.0.14. Are you recommending that RH 8.0 users running Cyrus should downgrade their BDB libraries to a 3.x RPM set for db3 (perhaps as supplied for RH 7.3)? Wouldn't that tend to have adverse consequences for other software (Sendmail comes to mind) which expects them and which might well be on a Red Hat 8.0 mail server along with Cyrus? 2. Linux stability patches for Cyrus (see the Debian Cyrus package :-) Cyrus upstream source works wonderfuly on Solaris, but not in Linux. I think some of the RPMs distributed by people in this list have many, if not all the patches recommended by me and the fastmail.fm crew. What will it take to get some/all of these patches into 2.1.11 or 2.2 or both? Is that a worthwhile objective? Or are these changes so Linux-specific that they have would negative consequences if applied to a source tree used for a Solaris or *BSD build?? With Linux being a more and more commonly chosen platform for smaller Cyrus installations, to me it seems worthwhile getting these patches incorporated into the upstream codebase -- if that can be done without adversely affecting Cyrus on other platforms. 3. Use the db3_nosync, skiplist, skiplist, flat, db3_nosync like Rob recommended. Unlike the other things you mention, this is something that *does* seem to be constant across OS platforms. If that is the case, then putting this info into a FAQ (as well as making it the default in 2.2) seems approriate. Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
Re: Skiplist / best practice for 2.1 branch
On Mon, 18 Nov 2002, Jonathan Marsden wrote: On 18 Nov 2002, Henrique de Moraes Holschuh writes: 1. Heavily tested and debugged AND patched BerkeleyDB 3.2, stay away from 4.x for now. (i.e. use the ones from RedHat or Debian, not upstream). Red Hat now supplies 4.0.14, for example the db4-4.0.14-14.i386.rpm in Then stick to Debian :-) Red Hat 8.0. It appears to work OK for me, but we have small setups only here... maybe we have just not met the bug(s) yet?? Well, people report a good range of trouble with DB4 in this list, but not many in DB 3.2. Maybe too few of us still use 3.2, though. In general, though the statement Use 3.2... ie. use the ones from RedHat or Debian ... is confusing, because for Red Hat 8.x users, the current RH-supplied production release of these libraries is now 4.0.14. I will keep that in mind. Are you recommending that RH 8.0 users running Cyrus should downgrade their BDB libraries to a 3.x RPM set for db3 (perhaps as supplied for No. That will break the OS. What will it take to get some/all of these patches into 2.1.11 or 2.2 or both? Is that a worthwhile objective? Or are these changes so No. CMU is slowly making their mind about the patches while they study them, but they will take a lot of time to leak into cyrus. And I don't expect all of them to, either. Linux-specific that they have would negative consequences if applied to a source tree used for a Solaris or *BSD build?? With Linux being No negative consequences that I know of. But increased resilience hides the real problems sometimes. putting this info into a FAQ (as well as making it the default in 2.2) seems approriate. It is in both AFAIK. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: Skiplist / best practice for 2.1 branch
Henrique de Moraes Holschuh wrote: On Mon, 18 Nov 2002, Jonathan Marsden wrote: On 18 Nov 2002, Henrique de Moraes Holschuh writes: 1. Heavily tested and debugged AND patched BerkeleyDB 3.2, stay away from 4.x for now. (i.e. use the ones from RedHat or Debian, not upstream). Red Hat now supplies 4.0.14, for example the db4-4.0.14-14.i386.rpm in Then stick to Debian :-) Red Hat 8.0. It appears to work OK for me, but we have small setups only here... maybe we have just not met the bug(s) yet?? Well, people report a good range of trouble with DB4 in this list, but not many in DB 3.2. Maybe too few of us still use 3.2, though. In general, though the statement Use 3.2... ie. use the ones from RedHat or Debian ... is confusing, because for Red Hat 8.x users, the current RH-supplied production release of these libraries is now 4.0.14. I will keep that in mind. Are you recommending that RH 8.0 users running Cyrus should downgrade their BDB libraries to a 3.x RPM set for db3 (perhaps as supplied for No. That will break the OS. What will it take to get some/all of these patches into 2.1.11 or 2.2 or both? Is that a worthwhile objective? Or are these changes so No. CMU is slowly making their mind about the patches while they study them, but they will take a lot of time to leak into cyrus. And I don't expect all of them to, either. Linux-specific that they have would negative consequences if applied to a source tree used for a Solaris or *BSD build?? With Linux being No negative consequences that I know of. But increased resilience hides the real problems sometimes. putting this info into a FAQ (as well as making it the default in 2.2) seems approriate. It is in both AFAIK. Correct me if I'm wrong...wasn't one of the changes with 2.1.10 the ability to run with BDB 4.1? =G=
Re: Skiplist / best practice for 2.1 branch
Jonathan Marsden wrote: Are you recommending that RH 8.0 users running Cyrus should downgrade their BDB libraries to a 3.x RPM set for db3 (perhaps as supplied for RH 7.3)? Wouldn't that tend to have adverse consequences for other software (Sendmail comes to mind) which expects them and which might well be on a Red Hat 8.0 mail server along with Cyrus? I think a lot of people would recommend you stay away from RH 8.0 for production servers. Not that I know of any particular problems... it's just that there's a lot of bleeding-edge stuff that hasn't proved itself as far as I'm concerned. IMHO, if you want a reliable Cyrus server on RedHat, use RH 7.3 or Advanced Server with all updates applied.
Re: Skiplist / best practice for 2.1 branch
-- Henrique de Moraes Holschuh [EMAIL PROTECTED] is rumored to have mumbled on Montag, 18. November 2002 19:20 Uhr -0200 regarding Re: Skiplist / best practice for 2.1 branch: 4. Journaling filesystem (xfs, ext3, Reiser), in a 2.4.20pre kernel. Why do you suggest using 2.4.20pre? Is there something wrong with 2.4.18 (+XFS patches)? -- Sebastian Hagedorn M.A. - RZKR-R1 (Flachbau), Zi. 18, Robert-Koch-Str. 10 Zentrum für angewandte Informatik - Universitätsweiter Service RRZK Universität zu Köln / Cologne University - Tel. +49-221-478-5587 msg09316/pgp0.pgp Description: PGP signature
Re: Skiplist / best practice for 2.1 branch
On 18 Nov 2002, Jules Agee writes: Jonathan Marsden wrote: Are you recommending that RH 8.0 users running Cyrus should downgrade their BDB libraries to a 3.x RPM set ... I think a lot of people would recommend you stay away from RH 8.0 for production servers. Not that I know of any particular problems... it's just that there's a lot of bleeding-edge stuff that hasn't proved itself as far as I'm concerned. Fair enough as a personal choice. However, do bear in mind that Red Hat 8.0 will not go away -- and in a few months there will be 8.1. Red Hat 8.x is here and is a reality that must be faced. If application software doesn't work well with a popular Linux distribution, IMO the appropriate response is Let's find out why, and work to get the problems fixed, either in that distribution or in our software. A response of Let's just not use or recommend that distribution is not likely to be a useful long-term approach if you want the application to be widely used :-) FYI, I don't actually have Red Hat 8.0 on any production servers here yet. I do have Cyrus 2.2 from CVS running against db-4.0.14 though... on Red Hat 7.3. Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
Re: Skiplist / best practice for 2.1 branch
On Tue, 19 Nov 2002, Sebastian Hagedorn wrote: -- Henrique de Moraes Holschuh [EMAIL PROTECTED] is rumored to have mumbled on Montag, 18. November 2002 19:20 Uhr -0200 regarding Re: Skiplist / best practice for 2.1 branch: 4. Journaling filesystem (xfs, ext3, Reiser), in a 2.4.20pre kernel. Why do you suggest using 2.4.20pre? Is there something wrong with 2.4.18 (+XFS patches)? Assorted kernel bugs that are of no major concern in a closed, tightly-controlled system (otherwise, there are very nasty local DoS problems). And some EXT3/EXT2 buglets too, but since you're using xfs, that doesn't concern you. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: Skiplist / best practice for 2.1 branch
Jonathan Marsden wrote: On 18 Nov 2002, Jules Agee writes: I think a lot of people would recommend you stay away from RH 8.0 for production servers. Not that I know of any particular problems... it's just that there's a lot of bleeding-edge stuff that hasn't proved itself as far as I'm concerned. Fair enough as a personal choice. However, do bear in mind that Red Hat 8.0 will not go away -- and in a few months there will be 8.1. Red Hat 8.x is here and is a reality that must be faced. Right, after many moons, and no doubt many bugfixes and updates, it will have proved itself and will then be useful for production servers. I wasn't saying anything about Cyrus. Berkeley DB 4.1 is supported in the latest Cyrus releases, after all. You mentioned using RH 8.0 as a server platform, and all I'm saying is that anyone using 8.0 in production right now is a lot more adventurous than most.
Re: locking problems with 2.1.9
--On Friday, November 8, 2002 7:49 PM -0500 Peter Krotkov [EMAIL PROTECTED] wrote: | Prior to a code fix to address the problems you observed, do you think it | would be unreasonable to configure master so that imaps is not offered? | We could revert to running stunnel for ssl support and then take our Could this also be an entropy issue? On this Solaris 8 box, what are you using for /dev/random, anyway? That Solaris patch? Amos
Re: Skiplist / best practice for 2.1 branch
--On Monday, November 18, 2002 8:57 PM -0200 Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: Linux-specific that they have would negative consequences if applied to a source tree used for a Solaris or *BSD build?? With Linux being No negative consequences that I know of. But increased resilience hides the real problems sometimes. Some of them (the lock timeout/wait is what I have in mind) will make the system perform not as well. But mostly Henrique has it just right: it's either fairly complicated and I'm very slow (the master patches), we haven't been nagged about it enough (we suck, sorry), or it feels very OS specific. So a lot of it is mostly waiting on me. Hopefully if something is really painful for Henrique to maintain seperately, he'll tell cyrus-bugs and we'll work it out. Larry
Re: Skiplist / best practice for 2.1 branch
Henrique de Moraes Holschuh wrote: For Linux: 1. Heavily tested and debugged AND patched BerkeleyDB 3.2, stay away from 4.x for now. (i.e. use the ones from RedHat or Debian, not upstream). 2. Linux stability patches for Cyrus (see the Debian Cyrus package :-) Cyrus upstream source works wonderfuly on Solaris, but not in Linux. I think some of the RPMs distributed by people in this list have many, if not all the patches recommended by me and the fastmail.fm crew. I tried those stability patches and they didn't help. The only thing that stopped lmtp from hanging was switching from db3_nosync to skiplist. What are the advantages of using db3_nosync over skiplist?
Re: Skiplist / best practice for 2.1 branch
On Mon, 18 Nov 2002, Patrick Boutilier wrote: I tried those stability patches and they didn't help. The only thing that stopped lmtp from hanging was switching from db3_nosync to skiplist. What are the advantages of using db3_nosync over skiplist? db3_nosync uses the Berkeley DB backend, which should be faster than skiplist for random access. Also, since the duplicate delivery database doesn't *need* consistancy, the lack of syncing to disk (which skiplist probably does more than is strictly necessary) makes it much faster to update than skiplist ever could be. Skiplist's main advantage is that it can enumerate the database much faster than the other backends (except for flat, possibly), and avoids the massive cost of updates present in flat. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Skiplist / best practice for 2.1 branch
I've just finished doing some benchmarking and general server abusing using ZD Labs IMAP test tool (http://www.etestinglabs.com/benchmarks/svrtools/email/t1intro.asp) and lmtpd performance makes sense. Each inbound message goes through lmtpd which does duplicate suppression (by default) meaning each deliver requires a lookup and more than likely a write. Doing a write requires a LOCK which costs -- on any os. I found 8-10 was an upper limit on the number of lmtp processes otherwise they just sit and spin waiting for a LOCK. With a limit of 10 lmtpds I was able to get 8-10 messages / second inbound. Using an mta upfront helps manage the backlog (queuing). Bottom line if I didn't limit lmtpd the whole thing went down the drain - quickly, but with cmd=lmtpd listen=/var/imap/socket/lmtp prefork=5 maxchild=10 I was able to hammer the server at 5-7 messages/second for hours. I'm using 2.1.10 w/ a a custom auth (regular expression based - another note when I get time) module everything else vanilla and I could hammer out 8-10 messages/second inbound (LMTP) and upwards of 20-30 outbound (IMAP). This is on a RedHat 7.1 box. I'm going to write this mess up when I'm done .. beating up murder tonight -- appropriate name cause it's murder ;-) name : Cyrus IMAPD version: v2.1.10 2002/11/11 22:12:50 vendor : Project Cyrus support-url: http://asg.web.cmu.edu/cyrus os : Linux os-version : 2.4.18-17.7.x environment: Cyrus SASL 2.1.9 Sleepycat Software: Berkeley DB 3.1.17: (July 31, 2000) OpenSSL 0.9.6 24 Sep 2000 CMU Sieve 2.2 TCP Wrappers mmap = shared lock = fcntl nonblock = fcntl auth = regexp idle = poll mboxlist.db = skiplist subs.db = flat seen.db = flat duplicate.db = db3-nosync tls.db = db3-nosync Rob Siemborski wrote: On Mon, 18 Nov 2002, Patrick Boutilier wrote: I tried those stability patches and they didn't help. The only thing that stopped lmtp from hanging was switching from db3_nosync to skiplist. What are the advantages of using db3_nosync over skiplist? db3_nosync uses the Berkeley DB backend, which should be faster than skiplist for random access. Also, since the duplicate delivery database doesn't *need* consistancy, the lack of syncing to disk (which skiplist probably does more than is strictly necessary) makes it much faster to update than skiplist ever could be. Skiplist's main advantage is that it can enumerate the database much faster than the other backends (except for flat, possibly), and avoids the massive cost of updates present in flat. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Thoughts on the age-old cyradm thingie
Thanks! That's very helpful, especially given the notes from Henrique about patches - sounds like I don't want to be running a stock imapd on Linux. Still, it'd be good to fix this in the source distribution as well. After thinking about it, I suspect adding --perl-prefix to configure is probably the right way to do it; if it's not specified, leaving it blank would then let MakeMaker put it in the right place. What do people think? I'm happy to try my hand at a patch; I've been meaning to learn autoconf for a few years now, and I even bought the dead-tree version of the book. Jay - Original Message - From: Luca Olivetti [EMAIL PROTECTED] To: Jay Levitt [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, November 18, 2002 3:12 AM Subject: Re: Thoughts on the age-old cyradm thingie Jay Levitt wrote: I'm new to Cyrus imapd - and, for that matter, to autoconf, perl, Linux, younameit. Building cyrus-imapd-2.1.10 on Mandrake 9.0, I ran into a http://perso.wanadoo.es/olivetti/cyrus/ -- Luca Olivetti Wetron Automatización S.A. http://www.wetron.es/ Tel. +34 93 5883004 Fax +34 93 5883007
RE: Skiplist / best practice for 2.1 branch
First of all, I used skiplist for mailboxes.db with imap-2.1.9 for better performance. But, I found sometimes the db gone to be corrupted, so I had to make a daily backup. As the author wrote in the skiplist code, there would be some bug. I think care must be taken to use skiplist so far. -Original Message- From: Tim Pushor [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 19, 2002 3:08 AM To: [EMAIL PROTECTED] Subject: Skiplist / best practice for 2.1 branch All, Hello, and I must first apologize because I know that what I am asking has been covered before, but I am having a difficult time finding information in the archives. I am still running the 1.6 branch on all of my production servers, and want to bring everything up to 2.1. I have resisted thus far for a few reasons, one being reported problems with Sleepycat DB (as well as grief trying to get all the software on my system to use one particular version of DB). I have done some research on the skiplist algorithm, but am wondering about the cyrus implementation. Is it stable? What is the current recommended/best practice for configuring 2.1.10? Which components should be DB as compared to skiplist? duplicate? mboxlist? seen? subs? tls? I definately favor reliability over performance. Thanks, and pointers to relevant articles or past discussions welcomed. Tim
Re: Skiplist / best practice for 2.1 branch
On Mon, 18 Nov 2002, Lawrence Greenfield wrote: Some of them (the lock timeout/wait is what I have in mind) will make the system perform not as well. I'd have to profile it to know more, and I am quite short on time to do that right now. Maybe the fastmail.fm crew has any comments on this issue? (we suck, sorry), or it feels very OS specific. So a lot of it is mostly waiting on me. Hopefully if something is really painful for Henrique to maintain seperately, he'll tell cyrus-bugs and we'll work it out. Well, there are two sets of patches I really would like to make it upstream. The first one are the shutdown() ones. They're quite safe, and they could increase wire performance in other kernels as well. And it IS a bother to periodically go all over the code trying to track down new calls to close that need a shutdown(). And I am sure I missed a few places where one side of the conection could be shutdown earlier due to the protocol... The second one is the master pidfile control. It is very safe, useful, and portable (the code was borrowed from Vixie cron...). It also makes for far better behaved init scripts. Both are simple patches, if a bit scattered all over in the case of the shutdown patch. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: Skiplist / best practice for 2.1 branch
On Mon, 18 Nov 2002, Patrick Boutilier wrote: Henrique de Moraes Holschuh wrote: For Linux: 1. Heavily tested and debugged AND patched BerkeleyDB 3.2, stay away from 4.x for now. I tried those stability patches and they didn't help. The only thing They are NOT supposed to help your problem, except for the lock timeout patches. Did you apply those? They will NOT fix the issue, but at least the lmtps would die out far faster when deadlocked, thus reducing the problem a bit. that stopped lmtp from hanging was switching from db3_nosync to skiplist. What are the advantages of using db3_nosync over skiplist? Your problem is inside the Berkeley DB environment, and deadlocking. No stability patch will help that... there IS a reason I recommend DB 3.2, and a reason why Debian didn't really bother switching to DB 4 yet. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
