Re: how to deal with mail retention/archival.
I saw that someone proposed to make a sort of abuse of delayed expunge, but I think that in order to comply with regulatory retention should be better considering some specific software. For example: http://www.mailpiler.org (Fully Free Software) https://www.mailarchiva.com (the old version is opensource but the latest is closed) The specific software will be much better for searching the archive. Finding something in the delayed_expunge folders after many years of archive will absolutely be a nightmare! Giuseppe On 08/26/2016 03:09 PM, Alvin Starr via Info-cyrus wrote: > A company I am working with is facing issues of regulatorymail retention. > > Some searching has yielded little useful results other than putting a > system in front to store all incoming messages. > > What are others doing for mail archival? > > An ideal solution would let the users carry on using current use > patterns and not impose extra restrictions. > > -- > Alvin Starr || voice: (905)513-7688 > Netvel Inc. || Cell: (416)806-0133 > al...@netvel.net || > > > > > 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 > 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
Server Backup
Hi, I'm rewriting my backup script and I cannot find any hint about how to backup the cyrus server in a good way. Actually I'm using this method: - Stop Postfix and Cyrus - making tar of /var/lib/sieve - making tar of /var/lib/imap - dumping mailboxes.db in plain text (ctl_mboxlist -d) - taking snapshots of all the mailstores - Restarting the Services - taking mailstore backups from the snapshots The last night the imaps was not restarted because the socket for IMAPS was busy and so I was wondering if today it's really needed to stop the service before taking the snapshots. Avoiding the service stop could also be useful in order to stop having a 1/2min downtime (I also take vmware snapshots of the machine) I was thinking to move in this direction: - Checkpoint and archive the databases (with ctl_cyrusdb -r) - making tar of /var/lib/imap - making tar of /var/lib/sieve - dumping mailboxes.db in plain text (ctl_mboxlist -d) - taking snapshots of all the mailstores - taking mailstore backups from the snapshots What kind of backup strategy are you using? Thanks Giuseppe 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
IDLE: error sending message
Hi,
I've just migrated a quite busy cyrus install to 2.5.7.
It seems all going well except for the fact that in the logs there are a
lot of messages like:
Feb 8 09:07:06 mail cyrus/imaps[13868]: IDLE: error sending message
DONE to idled for mailbox ${SHARED_FOLDER}: Resource temporarily
unavailable.
and
Feb 8 09:14:27 thot cyrus/imaps[10661]: IDLE: error sending message
INIT to idled for mailbox ${SHARED_FOLDER}: Resource temporarily
unavailable. Falling back to polling every 60 seconds.
All the log messages refers to two folders that are shared to and
subscribed by all users.
I couldn't find any hint about this error with google.
I hope that someone could explain me this message.
Thanks
Giuseppe
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
Cyrus 2.3.8 to 2.5.6
Hi, I'm testing the migration of a quite large IMAP server from 2.3.8 to the latest version. I'm syncing: - mailboxes partitions - sieve - var/lib/imap/user - var/lib/imap/quota - var/lib/imap/annotations.db After the sync: - recompile sieve scripts - ctl_mboxlist -u guid) cyrus/master[5994]: process type:SERVICE name:imaps path:/usr/local/lib/cyrus/bin/imapd age:43.479s pid:11803 exited, status 75 The files will be moved to the new folder and sometimes reappears in the original folder, other times disappears whithout beeing shown with: unexpunge -l $FOLDER It's possible to insert expernal messages in thoose old mailbox but It's not possible to delete because the message reappears and the error above is shown in the logs. If I try to delete with SHIFT-DEL the message disappears from Thunderbird, the error is shown in the logs, the file is still on the disk but "unexpunge -l" doesn't show the missing email. It's a bug or I'm not supposed to open the service until the full reconstruct? Thanks Giuseppe it also get deleted from the client (Thunderbird) from the original one, but thoose mail aren't sown via IMAP until the reconstruct. 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: [POLL] Cyrus ACLs and group names
Same here Giuseppe On 11/17/2015 12:23 PM, Adam Tauno Williams via Info-cyrus wrote: > On Tue, 2015-11-17 at 07:40 +1100, Bron Gondwana via Info-cyrus wrote: >> For those of you using Cyrus with group ACLs, how are your groups >> named? >> I know with the auth_unix backend, they are >> 'group:'. What I've seen from CMU's groups is that they >> are of the form ':'. > > Ours are group: > 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: Migrate from 2.2.13 to 2.4.17 disasters
I think that the key difference between using imapsync and upgrading cyrus is the amount of states that will be lost. I almost sure that with imapsync you cannot recreate: 1. Subscribed folders 2. Seen states for shared folders (also for INBOX if imapsync isn't used properly) 3. Shared seen states 4. Email flags (also for INBOX if imapsync isn't used properly) 5. Custom permissions Therefore I think that imapsync is not the best choice for corporate email servers or big installations. Giuseppe On 08/24/2015 01:44 PM, bs...@vsvinc.com wrote: > Apologizes for the thread diversion here but I've been seeing a lot of > discussion about using imapsync to migrate servers. From what I have > read in the documentation, you must have each user's password. How is > this possible in a business environment where you can't have (or > shouldn't have) that information because of legal/privacy/ethical > reasons? Is there something I'm missing in the docs? > > Brian > > > *From:* Marcus Schopen > *Sent:* Aug 24, 2015 3:54 AM > *To:* mog...@fumlersoft.dk > *Cc:* info-cyrus@lists.andrew.cmu.edu > *Subject:* Re: Migrate from 2.2.13 to 2.4.17 disasters > > Am Sonntag, den 23.08.2015, 20:36 +0200 schrieb Mogens Melander: >> For a task like this, I would use imapsync, a well documented, >> well supported and open source tool. >> >> https://github.com/imapsync/imapsync > > I've used imapsync to migrate an internal server from 2.1.18 to 2.4.17 > without any problems. Good tool. > > Ciao! > > > > 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 > > > > > 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 > 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: Lock Folder and cyr_expire
> I'm using a tmpfs for the Cyrus {configdir}/proc directory, like so:
>
> tmpfs /var/spool/cyrus/config/proctmpfs
> size=25M,nr_inodes=10k 0 0
> Maybe it would be better to create {configdir}/lock as a separate tmpfs?
> Something like:
>
> tmpfs /var/spool/cyrus/config/proctmpfs
> size=25M,nr_inodes=1k 0 0
Great! I tough that the nr_inodes for a tmpfs could not be set so high
as inode/size ratio! Thnaks.
Shuld be interesting to know how much ram space will need a tmpfs volume
with 1k inodes used by 0k files!
I couldn't find any information about inode size in tmpfs.
I also did a small test and on my workstation and it turns out that:
Creating 1 0k files on tmpfs
(-o size=25M,nr_inodes=1k) took 8sec
Creating 1 0k files on XFS loopback device on my SSD
(mkfs.xfs -i maxpct=0 ) took 9sec
Creating 1 0k files on XFS loopback device on tmpfs
(mkfs.xfs -i maxpct=0) took 8sec
> There is no reason for lock files to persist between Cyrus restarts, right?
No. the doc say:
"
There is a new lock folder which defaults to configdir/lock/ and
contains one zerobyte file per mailbox. These can get pretty hot, and
don't need to persist over reboots (they will be auto-created when
needed) - so you may want to define mboxname_lockpath to be on tmpfs or
ramfs or similar. It certainly makes sense to clean it out on restart,
because names will persist in there forever otherwise. Even on mailbox
delete these files aren't removed (to avoid potential race conditions)
"
But if you're using cyr_expire I think that cleaning do not make sense
because at the first run all the files will be recreated.
Giuseppe
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
Lock Folder and cyr_expire
Hi, recently I faced an outage for one of my IMAP server that runs out of inodes. We have about 500k growing (that aren't opened daily!) imap folders and the 0k lock files are filling the inode table of the partition containing the mboxname_lockpath I was hoping that cleaning mboxname_lockpath on cyrus restart will solve the issue but when cyr_expire job was started it created all the locks filling the inode table. Obiouvsly I will address the issue creating a specific filesystem for the mboxname_lockpath with XFS (that allows me to keep the inode/space ratio at maximum). There is a clean workaround that I'm missing? Anyway I think that would be useful to address this problem in some way (I don't know the reason of thoose lock files, so I don't have any ideas) or at least say in the Doc that mboxname_lockpath should be able to contain as many 0k files as the number of folders, because in 24h it will reach the top ( I think that 99% of cyrus users are running cyr_expire ) Thanks Giuseppe 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
