Re: [Dovecot] what to expect from changing index location
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/29/2011 06:36 PM, William Blunn wrote: On 28/06/2011 17:13, Davide Vaghetti wrote: I have one thousand virtual users with mdbox mailbox format and 10 GByte quota. I have noticed some performance problem related to I/O (the mailbox disk is a 6TB raid1+0 on ISCSI), so I want to put the index files on a different disk. My actual mail_location is: mail_location = mdbox:/var/vmail/%-1.1u/%u/mdbox and I want to switch to mail_location = mdbox:/var/vmail/%-1.1u/%u/mdbox:INDEX=/var/indexes/%-1.1u/%u/ But I cannot figure out a pair of things: - - do the switch trigger the rebuilding of the index files? ! DANGER, DANGER !! Index files cannot be re-generated under mdbox Go away and read http://wiki2.dovecot.org/MailboxFormat/dbox ... with dbox the Index files actually contain significant data which is held nowhere else. Index files for both *single-dbox* and *multi-dbox* contain message flags and keywords. For *multi-dbox*, the index file also contains the map_uids which link (via the map index) to the actual message data. This data cannot be automatically recreated, so it is important that Index files are treated with the same care as message data files. If you don't already know this, then you probably shouldn't even be using mdbox. - - can I get rid of all the old index files? NO! - - how much the index files (no fts squat) can grow? First solve your understanding problem with mdbox, then worry about details such as this. Bill, thanks for all the __important__ info. You almost saved my ass ;-) (BTW, that is why I was asking) I'll check again the documentation to better understand index in the mdbox context. Nontheless, I still have to care about the index files grow factor, so if you, or anyone else, can point me to the right documentation, or have a rule of thumbs to know it, please share it. Regards davide - -- Dott. Davide Vaghetti Centro Servizi Informatici Facolta' di Ingegneria Universita' di Pisa PGP: http://keys.keysigning.org:11371/pks/lookup?op=getsearch=0x7A1B3BA18C4E0A4D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4MIUYACgkQehs7oYxOCk1pHwCfeomYITfTiyAhMC2oQhM3cFhW Vh8AoPBSRflEWP4sFTpD1vgZKya+0KtV =e7rX -END PGP SIGNATURE-
Re: [Dovecot] what to expect from changing index location
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/28/2011 07:29 PM, Charles Marcus wrote: On 2011-06-28 12:13 PM, Davide Vaghetti wrote: mail_location = mdbox:/var/vmail/%-1.1u/%u/mdbox and I want to switch to mail_location = mdbox:/var/vmail/%-1.1u/%u/mdbox:INDEX=/var/indexes/%-1.1u/%u/ But I cannot figure out a pair of things: - - do the switch trigger the rebuilding of the index files? - - can I get rid of all the old index files? I'm by no means an expert, but with that many users I think if you did this in one shot (all indexes being rebuilt simultaneously as users logged in) your system would slow to a crawl... I would first rsync the existing indexes over live, then stop dovecot, do another quick rsync of the indexes, then make the change and restart dovecot... That will minimize the impact (rebuilding of indexes)... Good hint! Thank you. What about the index grow factor? Do some of you folks have any idea about that (no ftp squat)? bye davide - -- Dott. Davide Vaghetti Centro Servizi Informatici Facolta' di Ingegneria Universita' di Pisa PGP: http://keys.keysigning.org:11371/pks/lookup?op=getsearch=0x7A1B3BA18C4E0A4D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4LSr0ACgkQehs7oYxOCk2iBwCfbcygrvBaO4JJFAtgTb9fXwZg FPMAoI/yZFborIJH+U3gTx28In602H7k =pHbw -END PGP SIGNATURE-
[Dovecot] what to expect from changing index location
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello everybody, I have one thousand virtual users with mdbox mailbox format and 10 GByte quota. I have noticed some performance problem related to I/O (the mailbox disk is a 6TB raid1+0 on ISCSI), so I want to put the index files on a different disk. My actual mail_location is: mail_location = mdbox:/var/vmail/%-1.1u/%u/mdbox and I want to switch to mail_location = mdbox:/var/vmail/%-1.1u/%u/mdbox:INDEX=/var/indexes/%-1.1u/%u/ But I cannot figure out a pair of things: - - do the switch trigger the rebuilding of the index files? - - can I get rid of all the old index files? - - how much the index files (no fts squat) can grow? thanks in advance bye davide - -- Dott. Davide Vaghetti Centro Servizi Informatici Facolta' di Ingegneria Universita' di Pisa PGP: http://keys.keysigning.org:11371/pks/lookup?op=getsearch=0x7A1B3BA18C4E0A4D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4J/Z4ACgkQehs7oYxOCk3QagCfd+yVvR2Ps6hbjZOCumn2Wx2W 6cgAnjOvQDfe1O9jDOAbp4k0deEmytd3 =ZJFQ -END PGP SIGNATURE-
Re: [Dovecot] the right way to delete mailbox/user home
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/20/2011 05:15 PM, Timo Sirainen wrote: On Tue, 2011-04-19 at 17:36 +0200, Davide Vaghetti wrote: we are using dovecot with mdbox to provide mail services for a community of 1000 academic users. We have quite a big turnover of guest users, so we often have to deprovision the allocated resources, that is the mailboxes. Given that the users are virtual, and that the mdbox directory is located in the home directory of each virtual user (static userdb), is it ok to simply delete (rm -rf) the home directory to get rid of the mailbox? As long as you haven't enabled a separate attachment storage (mail_attachment_dir) it's safe to rm -rf. Could the delete, without say a dovecot reload, be harmful for dovecot processes and the like? No need to reload or anything. Other than the attachment storage, there is no global shared state across users. Thanks a lot! bye davide - -- Dott. Davide Vaghetti Centro Servizi Informatici Facolta' di Ingegneria Universita' di Pisa PGP: http://keys.keysigning.org:11371/pks/lookup?op=getsearch=0x7A1B3BA18C4E0A4D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2wDhgACgkQehs7oYxOCk391QCdGggHTTQnVbw5y+JFb1wehGNs TooAoIbGk4Mbb6ONn8whLm2zXiH1F00M =KyfM -END PGP SIGNATURE-
[Dovecot] the right way to delete mailbox/user home
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear list, we are using dovecot with mdbox to provide mail services for a community of 1000 academic users. We have quite a big turnover of guest users, so we often have to deprovision the allocated resources, that is the mailboxes. Given that the users are virtual, and that the mdbox directory is located in the home directory of each virtual user (static userdb), is it ok to simply delete (rm -rf) the home directory to get rid of the mailbox? Could the delete, without say a dovecot reload, be harmful for dovecot processes and the like? thanks davide - -- Dott. Davide Vaghetti Centro Servizi Informatici Facolta' di Ingegneria Universita' di Pisa PGP: http://keys.keysigning.org:11371/pks/lookup?op=getsearch=0x7A1B3BA18C4E0A4D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2tq/cACgkQehs7oYxOCk1ECgCg6Q5Pj+0k9GVYlS1ggmDLkwAr srkAoKMixJmyB7E+Ki6T9/8IzwYRC55z =/ZoN -END PGP SIGNATURE-
Re: [Dovecot] Dovecot LDA and Postfix/local for local users.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/09/2011 10:07 AM, i...@promax.media.pl wrote: Hello, I would like to configure dovecot lda for local users. My dovecot vesion is 1.2.15. Dovecot documentation for System users says that only thing I should add to main.cf is: mailbox_command = /usr/local/libexec/dovecot/deliver (path to deliver) After that should I commented postfix/local process from master cf ? I've the same setup, and no, you don't need to comment anything in master.cf, since those are just definitions, you decide the actual use via the main.cf (at least as regards the delivery). bye davide - -- Dott. Davide Vaghetti Centro Servizi Informatici Facolta' di Ingegneria Universita' di Pisa PGP: http://keys.keysigning.org:11371/pks/lookup?op=getsearch=0x7A1B3BA18C4E0A4D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk13ai8ACgkQehs7oYxOCk0G8wCg8vdpLGnVXRyoo0s90ZbOPyhw QKUAoJ7CruRo9TxJcEdFP/nC60Xjm8/O =V1Lo -END PGP SIGNATURE-
Re: [Dovecot] solaris 10 dovecot-1.0.rc29 - building issue
Jeff A. Earickson wrote: Hi, Works great for me; it has for a long time. My advice: upgrade your C compiler. I usually build dovecot with gcc 4.1.1, but it will also work well with Sun Studio 11. Sun Studio 11 is free if you have a Sun support contract/sunsolve login. See: http://developers.sun.com/sunstudio/downloads/ Dovecot has been pretty bullet-proof for me. For me too... on linux ;-) I solved using bash instead of ksh, thanks anyway. bye davide -- -- Davide Vaghetti Centro SerRA - University of Pisa NOC
Re: [Dovecot] solaris 10 dovecot-1.0.rc29 - building issue
Frank Cusack wrote: On April 4, 2007 5:53:10 PM +0200 Davide Vaghetti [EMAIL PROTECTED] wrote: Hi all, I'm having terrible time, and a lot of core dumps, building dovecot on Solaris 10. ... When I try to actually make it, this is the result: Making all in imap make[3]: Entering directory `/usr/local/src/dovecot-1.0.rc29/src/imap' /bin/ksh ../../libtool --tag=CC --mode=link gcc -std=gnu99 -g -O2 ... make[3]: *** [imap] Bus Error (core dumped) ... This is a ksh bug. Try setting CONFIG_SHELL in libtool to /usr/xpg4/bin/sh. You were right, but on my solaris 10 /usr/xpg4/bin/sh is nothing but a copy of /bin/ksh. Anyway following your hint I modified the libtool to use GNU bash and the built-in echo instead of the ksh's print -r and it worked ! thanks bye davide -- -- Davide Vaghetti Centro SerRA - University of Pisa NOC
[Dovecot] solaris 10 dovecot-1.0.rc29 - building issue
Hi all, I'm having terrible time, and a lot of core dumps, building dovecot on Solaris 10. My environment: gcc 3.3.2 LDFLAGS=-L/usr/local/ssl/lib -lssl -lcrypto \ -L/usr/local/BerkeleyDB.4.2/lib -ldb -L/usr/local/lib -lldap CPPFLAGS=-I/usr/local/BerkeleyDB/include \ -I/usr/local/include -I/usr/local/ssl/include my configure: ./configure --prefix=/usr/local --with-ldap ...that is: Install prefix .. : /usr/local File offsets : 64bit I/O loop method . : poll File change notification method . : none Building with SSL support ... : yes (OpenSSL) Building with IPv6 support .. : yes Building with pop3 server ... : yes Building with mail delivery agent .. : yes Building with GSSAPI support : no Building with user database modules . : static prefetch passwd passwd-file checkpassword ldap (modules) Building with password lookup modules : passwd passwd-file shadow pam checkpassword ldap (modules) Building with SQL drivers : When I try to actually make it, this is the result: Making all in imap make[3]: Entering directory `/usr/local/src/dovecot-1.0.rc29/src/imap' /bin/ksh ../../libtool --tag=CC --mode=link gcc -std=gnu99 -g -O2 -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -export-dynamic -L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.2/lib -L/usr/local/lib -o imap cmd-append.o cmd-capability.o cmd-check.o cmd-close.o cmd-copy.o cmd-create.o cmd-delete.o cmd-examine.o cmd-expunge.o cmd-fetch.o cmd-idle.o cmd-list.o cmd-logout.o cmd-lsub.o cmd-namespace.o cmd-noop.o cmd-rename.o cmd-search.o cmd-select.o cmd-sort.o cmd-status.o cmd-store.o cmd-subscribe.o cmd-thread.o cmd-uid.o cmd-unselect.o cmd-unsubscribe.o client.o commands.o commands-util.o imap-expunge.o imap-fetch.o imap-fetch-body.o imap-messageset.o imap-search.o imap-sort.o imap-sync.o imap-thread.o mail-storage-callbacks.o main.o namespace.o ../lib-storage/register/libstorage-register.a ../../src/lib-storage/index/maildir/libstorage_maildir.a ../../src/lib-storage/index/mbox/libstorage_mbox.a ../../src/lib-storage/index/dbox/libstorage_dbox.a ../../src/lib-storage/index/libstorage_index.a ../../src/lib-index/libindex.a ../lib-storage/libstorage.a ../lib-storage/subscription-file/libstorage_subscription_file.a ../lib-imap/libimap.a ../lib-mail/libmail.a ../lib-dict/libdict.a ../lib-charset/libcharset.a ../lib/liblib.a ../lib/mountpoint.o /usr/local/lib/libiconv.so -L/usr/openwin/lib -R/usr/local/lib -export-dynamic -lsocket -lnsl -lrt -lsendfile gcc -std=gnu99 -g -O2 -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -o imap cmd-append.o cmd-capability.o cmd-check.o cmd-close.o cmd-copy.o cmd-create.o cmd-delete.o cmd-examine.o cmd-expunge.o cmd-fetch.o cmd-idle.o cmd-list.o cmd-logout.o cmd-lsub.o cmd-namespace.o cmd-noop.o cmd-rename.o cmd-search.o cmd-select.o cmd-sort.o cmd-status.o cmd-store.o cmd-subscribe.o cmd-thread.o cmd-uid.o cmd-unselect.o cmd-unsubscribe.o client.o commands.o commands-util.o imap-expunge.o imap-fetch.o imap-fetch-body.o imap-messageset.o imap-search.o imap-sort.o imap-sync.o imap-thread.o mail-storage-callbacks.o main.o namespace.o ../lib/mountpoint.o /usr/local/lib/libiconv.so -L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.2/lib -L/usr/local/lib ../lib-storage/register/libstorage-register.a ../../src/lib-storage/index/maildir/libstorage_maildir.a ../../src/lib-storage/index/mbox/libstorage_mbox.a ../../src/lib-storage/index/dbox/libstorage_dbox.a ../../src/lib-storage/index/libstorage_index.a ../../src/lib-index/libindex.a ../lib-storage/libstorage.a ../lib-storage/subscription-file/libstorage_subscription_file.a ../lib-imap/libimap.a ../lib-mail/libmail.a ../lib-dict/libdict.a ../lib-charset/libcharset.a ../lib/liblib.a -L/usr/openwin/lib -lsocket -lnsl -lrt -lsendfile -R/usr/local/lib make[3]: *** [imap] Bus Error (core dumped) make[3]: *** Deleting file `imap' make[3]: Leaving directory `/usr/local/src/dovecot-1.0.rc29/src/imap' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/src/dovecot-1.0.rc29/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/dovecot-1.0.rc29' make: *** [all] Error 2 I tried the rc27 and rc28 too with the same results. Does anybody experienced similar issues ? thanks in advance bye -- Davide Vaghetti Centro SerRA - University of Pisa NOC
