Re: Injecting a mail folder into a users inbox/restore from backup
--On 12. Dezember 2012 08:51:58 +0100 Michael Neumann michael.neum...@ub.tu-dortmund.de wrote: Am 12.12.2012 08:35, schrieb Michael Menge: expunge_mode is only for mails, delete_mode is the option for folders but works slightly different. The deleted folder is moved to a special folder (option deletedprefix in imapd.conf) You can restore the folder with cyradm by movin it to the old place. cyr_expire will remove the old mails an folders. Take a look at the options and configure a cyr_expire run in the EVENT section of cyrus.conf Thanks, so the delete_duration for mailboxes is set using the -D option of cyr_expire. I am now unsure about expunge_mode, there is an option expunge_days in imapd.conf and the -X option of cyr_expire, how do those two options work together? It pays to read the archive: https://lists.andrew.cmu.edu/pipermail/info-cyrus/2012-January/035731.html -- .:.Sebastian Hagedorn - Weyertal 121 (Gebäude 133), Zimmer 2.02.:. .:.Regionales Rechenzentrum (RRZK).:. .:.Universität zu Köln / Cologne University - ✆ +49-221-470-89578.:. p7skE32wXDfpi.p7s Description: S/MIME cryptographic signature Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Fwd: Too many entries of mystore: reusing txn....
On Sun, 2012-12-09 at 10:49 +0530, Anant Athavale wrote: As you say, the imap DEBUG logs are coming to maillog. RHEL 6.3 ships with Rsyslogd and also it looks like cyrus-imapd is compiled to use MAIL_LOG facility. (I tried local6.info /var/log/imapd.log. but it did log anything in imapd.log ). I am attaching rsyslog.conf (Not modified). What I ultimately want is 'maillog should not contain imap logs. And imapd.log should contain all logs related to cyrus/imapd with only info level logs. ' As I could not achieve it in short span of time, I have released the system, but, would like to do that in near future. Any pointers to achieve? Yes. Give up on syslog. Seriously. The model provided by syslog is very simplistic and kludgy. Just use syslog as a transport to get messages into an NMS, and sort, categorize, and record them there. We send all our syslog messages to ZenOSS. There syslog messages can be mapped into categories, prioritized [and discarded], recorded, viewed, and generate notifications. And you get a user interface to do it all in, and a coherent way to backup/restore all your machinations. Syslog messages from imapd have a tag of imapd, and messages from postfix have a tag of postfix, which is almost invisible in syslog itself. So you have the host of origin, the tag, the facility, and the level [and the text of the message] all to work with to categorize [and potentially discard] any way you want. Obviously you want to discard DEBUG messages as the syslog level - that is just too much noise for anything. But a decent host for you NMS can handle a surprising load of messages. -- Adam Tauno Williams awill...@whitemice.org Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Injecting a mail folder into a users inbox/restore from backup
Am 12.12.2012 10:20, schrieb Sebastian Hagedorn: It pays to read the archive: https://lists.andrew.cmu.edu/pipermail/info-cyrus/2012-January/035731.html Yes, sorry and thanks, that clarifies it. Best Regards Michael -- Michael Neumann michael.neum...@ub.tu-dortmund.de Universitaetsbibliothek Dortmund Bibliotheks-IT Telefon: +49 231 755 4773 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Injecting a mail folder into a users inbox/restore from backup
On 12/12/2012 08:16 AM, Michael Neumann wrote: Am 12.12.2012 10:20, schrieb Sebastian Hagedorn: It pays to read the archive: https://lists.andrew.cmu.edu/pipermail/info-cyrus/2012-January/035731.html Yes, sorry and thanks, that clarifies it. For what it's worth, you can also set expire times, for specific mailboxes, via annotations. We frequently use a script like this to handle such a task on a regular basis, to accommodate users who delete and recreate mailboxes we wish to handle exceptionally: - #!/bin/sh # # set_cyrus_annotations.sh - Set the standard annotations for the Spam, #Trash and systems mailboxes so they expire #properly. # USER=cyrus user PASS=secret HOST=localhost cyradm -u $USER -w $PASS $HOST _EOF_ mboxcfg systems expire 60 mboxcfg user/%/Spam expire 7 mboxcfg user/%/Trash expire 2 _EOF_ - Also, as to documentation, the Kolab folks have some good info available here http://www.cyrusimap.org/%7Evanmeeuwen/cyrus-imapd-2.4-docs/Administrator_Guide/html/chap-Administrator_Guide-Deleting_and_Undeleting_Messages_and_Folders.html, including a step-by-step guide to locating and restoring (via cyradm rename) deleted mailboxes. This is the way to go, and the Perl example there shows how to make sense of the datestamp on folders in the DELETED hierarchy. Cheers, -nic -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 219 N. Milwaukee St., Suite 2av. 414.272.4477 Milwaukee, Wisconsin 53202 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Fwd: Too many entries of mystore: reusing txn....
On Wed, 12 Dec 2012, Adam Tauno Williams wrote: On Sun, 2012-12-09 at 10:49 +0530, Anant Athavale wrote: As you say, the imap DEBUG logs are coming to maillog. RHEL 6.3 ships with Rsyslogd and also it looks like cyrus-imapd is compiled to use MAIL_LOG facility. (I tried local6.info /var/log/imapd.log. but it did log anything in imapd.log ). I am attaching rsyslog.conf (Not modified). What I ultimately want is 'maillog should not contain imap logs. And imapd.log should contain all logs related to cyrus/imapd with only info level logs. ' As I could not achieve it in short span of time, I have released the system, but, would like to do that in near future. Any pointers to achieve? Yes. Give up on syslog. Seriously. The model provided by syslog is very simplistic and kludgy. Just use syslog as a transport to get messages into an NMS, and sort, categorize, and record them there. We send all our syslog messages to ZenOSS. There syslog messages can be mapped into categories, prioritized [and discarded], recorded, viewed, and generate notifications. And you get a user interface to do it all in, and a coherent way to backup/restore all your machinations. Syslog messages from imapd have a tag of imapd, and messages from postfix have a tag of postfix, which is almost invisible in syslog itself. So you have the host of origin, the tag, the facility, and the level [and the text of the message] all to work with to categorize [and potentially discard] any way you want. Obviously you want to discard DEBUG messages as the syslog level - that is just too much noise for anything. But a decent host for you NMS can handle a surprising load of messages. Just to add another thought here... You could use syslog-ng instead of rsyslog. Syslog-ng has more advanced filtering capabilities than rsyslog, and you can probably just drop-in replace rsyslog with syslog-ng. However, I would not discourage you from looking at ZenOSS too. Syslog-ng might be less work to implement if you do not need ZenOSS features. Andy Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Reconstruct mailbox for a specific user.
On Wed, 12 Dec 2012, an...@isac.gov.in wrote: - Message from mor...@orst.edu - Date: Tue, 11 Dec 2012 20:55:04 -0800 (PST) From: Andrew Morgan mor...@orst.edu Subject: Re: Reconstruct mailbox for a specific user. To: an...@isac.gov.in Cc: info-cyrus@lists.andrew.cmu.edu On Wed, 12 Dec 2012, an...@isac.gov.in wrote: One of the users mailbox has one more level of sub folder like user.xxx.ABC user.xxx.ABC.def Right now, folders of level user.xxx are seen, but folders at user.xxx.ABC including ABC are not seen. Should I run, /usr/lib/cyrus-imapd/reconstruct -rf user.xxx.ABC now? That is when Cyrus-imapd is already running? Or I should stop the service and run reconstruct? Please advise. You can run reconstruct and quota while cyrus-imapd is running. If reconstruct does not succeed, verify the mailbox(es) are listed within the output of 'ctl_mboxlist -d'. If not, you should add them via cyradm. reconstruct may also fail for a given mailbox if you are missing the cyrus.* files within its directory. You might wish to backup the contents of the directories in question before proceeding, in case you end up with missing flags or other data. -- Dan White What I found is 1. /var/spool/imap/user/xxx exists 2. /var/spool/imap/user has several directories 3. All other directories except ABC are listed as folders under user.xxx and are seen by IMAP clients. 4. ABC directory has subfolders like /var/spool/imap/user/xxx/ABC/1, 2 3 etc and each of these subdirectories has cyrus.* files except ABC directory. As you said, as ABC directory does not have cyrus.* files, reconstruct has failed to recognise it and hence its subdirectories. Should I run reconstruct -r -f user.xxx.ABC or cm user.xxx.ABC and then run reconstruct -r -f user.xxx.ABC? Create a cyrus.header file in the ABC directory, set the ownership and permissions. Something like this: touch cyrus.header chown cyrus:mail cyrus.header chmod 600 cyrus.header Then run: reconstruct -x -f user.xxx.ABC I should have asked at the beginning - are there any message files in (1., 2., 3., etc) in the ABC directory? Andy NO. There are no message files in ABC directory. There are only directories in ABC directory and each such directory has message files and also cyrus.* files. I am thinking of another option, move all such directories under ABC to one level higher, that is at user.xxx level and run reconstruct -r -f user.xxx. But, you still suggest, which is the best way. What happens when you run: reconstruct -x -f user.xxx.ABC.def ? Andy NO output. lm does not list user.xxx.ABC or user.XXX.ABC.def. Hmmm. Could this be a bug in reconstruct? Maybe it won't reconstruct a mailbox is the parent is not also a mailbox... Why don't you try creating user.xxx.ABC in cyradm, then running the same reconstruct command? Andy Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Reconstruct mailbox for a specific user.
- Message from mor...@orst.edu - Date: Wed, 12 Dec 2012 09:33:03 -0800 (PST) From: Andrew Morgan mor...@orst.edu Subject: Re: Reconstruct mailbox for a specific user. To: an...@isac.gov.in Cc: info-cyrus@lists.andrew.cmu.edu On Wed, 12 Dec 2012, an...@isac.gov.in wrote: - Message from mor...@orst.edu - Date: Tue, 11 Dec 2012 20:55:04 -0800 (PST) From: Andrew Morgan mor...@orst.edu Subject: Re: Reconstruct mailbox for a specific user. To: an...@isac.gov.in Cc: info-cyrus@lists.andrew.cmu.edu On Wed, 12 Dec 2012, an...@isac.gov.in wrote: One of the users mailbox has one more level of sub folder like user.xxx.ABC user.xxx.ABC.def Right now, folders of level user.xxx are seen, but folders at user.xxx.ABC including ABC are not seen. Should I run, /usr/lib/cyrus-imapd/reconstruct -rf user.xxx.ABC now? That is when Cyrus-imapd is already running? Or I should stop the service and run reconstruct? Please advise. You can run reconstruct and quota while cyrus-imapd is running. If reconstruct does not succeed, verify the mailbox(es) are listed within the output of 'ctl_mboxlist -d'. If not, you should add them via cyradm. reconstruct may also fail for a given mailbox if you are missing the cyrus.* files within its directory. You might wish to backup the contents of the directories in question before proceeding, in case you end up with missing flags or other data. -- Dan White What I found is 1. /var/spool/imap/user/xxx exists 2. /var/spool/imap/user has several directories 3. All other directories except ABC are listed as folders under user.xxx and are seen by IMAP clients. 4. ABC directory has subfolders like /var/spool/imap/user/xxx/ABC/1, 2 3 etc and each of these subdirectories has cyrus.* files except ABC directory. As you said, as ABC directory does not have cyrus.* files, reconstruct has failed to recognise it and hence its subdirectories. Should I run reconstruct -r -f user.xxx.ABC or cm user.xxx.ABC and then run reconstruct -r -f user.xxx.ABC? Create a cyrus.header file in the ABC directory, set the ownership and permissions. Something like this: touch cyrus.header chown cyrus:mail cyrus.header chmod 600 cyrus.header Then run: reconstruct -x -f user.xxx.ABC I should have asked at the beginning - are there any message files in (1., 2., 3., etc) in the ABC directory? Andy NO. There are no message files in ABC directory. There are only directories in ABC directory and each such directory has message files and also cyrus.* files. I am thinking of another option, move all such directories under ABC to one level higher, that is at user.xxx level and run reconstruct -r -f user.xxx. But, you still suggest, which is the best way. What happens when you run: reconstruct -x -f user.xxx.ABC.def ? Andy NO output. lm does not list user.xxx.ABC or user.XXX.ABC.def. Hmmm. Could this be a bug in reconstruct? Maybe it won't reconstruct a mailbox is the parent is not also a mailbox... Why don't you try creating user.xxx.ABC in cyradm, then running the same reconstruct command? Andy YES. This helped and all folders got recognised. Thank you for your guidance. Regards, Anant. - End message from mor...@orst.edu - -- Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. -- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
