Cyrus IMAP 3.2.2 released

2020-06-21 Thread ellie timoney
The Cyrus team is proud to announce the immediate availability of a new version 
of Cyrus IMAP: 3.2.2

Download URLs:


https://github.com/cyrusimap/cyrus-imapd/releases/download/cyrus-imapd-3.2.2/cyrus-imapd-3.2.2.tar.gz

https://github.com/cyrusimap/cyrus-imapd/releases/download/cyrus-imapd-3.2.2/cyrus-imapd-3.2.2.tar.gz.sig


Please consult the release notes and upgrade documentation before upgrading to 
3.2.2:

https://www.cyrusimap.org/imap/download/release-notes/3.2/x/3.2.2.html
https://www.cyrusimap.org/imap/download/upgrade.html

And join us on Github at https://github.com/cyrusimap/cyrus-imapd to report 
issues, join in the deliberations of new features for the next Cyrus IMAP 
release, and to contribute to the documentation.

On behalf of the Cyrus team,

Kind regards,

ellie timoney

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: backupd and sync_client IOERROR

2020-06-21 Thread ellie timoney
Hi Marco,

On Fri, Jun 19, 2020, at 6:44 PM, Marco wrote:
> wow, yes, it works. With this config, after the Cyrus restart the 
> mailboxes.db and the skipstamps dbs are created and the error disappears 
> from syslog.

Great! I've updated the documentation, and the website should update shortly.

> I suggested the possibility to choose the recovery date (ie: all 
> messages and mailboxes deleted or expunged from  to ). I 
> hope you could add this feature.

Yep, I saw that, thanks for the request :)

> I now tried a restore, but I still have some problems. I very appreciate 
> if you could read the following issue.
> 
> My goal is to recover a message that was removed (expunged) from the 
> IMAP server, ignoring already existing messages.
> 
> It seems the "-x" flag could help. It seems it allows to restore and 
> unexpunge a previously expunged messages in the IMAP server.

No, you've misunderstood.  The "-x" flag is to ONLY restore expunged messages.  
If you've specified a list of mailboxes or messages on the command line, and 
some of them are not expunged, the "-x" option will cause it to ignore the ones 
that are not expunged, and only restore the expunged ones.  The "-X" option 
does the inverse -- they're filters.  Without one of these filters, it will 
restore everything you asked for, regardless of its expunged status.

So like, maybe a user has deleted some stuff, and you don't want to mess around 
figuring out which individual messages they need restored, so you just want to 
restore everything, and let the user figure it out.  This is what -x is for -- 
so you can say "restore the contents of mailbox foo, but only the expunged 
stuff" or "restore every mailbox (-a), but only the expunged stuff".

Think about it: if the messages _weren't_ expunged, there would usually be no 
need to restore them from backup!  You would simply remove the \Deleted flag 
over IMAP.  So, you are almost always using restore to bring back expunged 
messages, thus there is no special flag needed to enable this functionality.

(But, if you had lost an entire server to some disaster, and restoring to its 
replacement, then you would need to also restore the unexpunged stuff.)
 
> Yesterday I expunged the message 16ceead9802286784d7a54c5bc782891f76f2f2e:
> 
> 2020-06-18T15:44:37.374556+02:00 tst-msg03 cyrus/imap[9461]: auditlog: 
> expunge sessionid= 
> mailbox= 
> uniqueid= uid=<32092> modseq=<46828> 
> sysflags= guid=<16ceead9802286784d7a54c5bc782891f76f2f2e>
> 
> 
> I tried today to restore it:
> cyr_restore -v -U -x tst-msg03.example.com -u 
> utente.archivi...@example.com 16ceead9802286784d7a54c5bc782891f76f2f2e
> example.com!user.utente^archivista: trying to keep 
> uidvalidity(1550228105), uniqueid(nvf96uirjgfs6xaekwwc7g44), 
> highestmodseq(46828)
> 
> and I see:
> 2020-06-19T09:29:24.030624+02:00 tst-msg03 cyrus/imap[32742]: login: 
> tst-msg03-bck.example.com [10.102.42.169] cyr_restore LOGIN User logged 
> in SESSIONID=
> 
> 2020-06-19T09:29:24.162909+02:00 tst-msg03 cyrus/imap[32742]: auditlog: 
> append sessionid= 
> mailbox= 
> uniqueid= uid=<32096> modseq=<46829> 
> sysflags= guid=<16ceead9802286784d7a54c5bc782891f76f2f2e> 
> messageid=
> 
> 2020-06-19T09:29:24.163058+02:00 tst-msg03 cyrus/imap[32742]: auditlog: 
> expunge sessionid= 
> mailbox= 
> uniqueid= uid=<32096> modseq=<46829> 
> sysflags= guid=<16ceead9802286784d7a54c5bc782891f76f2f2e>
> 
> 2020-06-19T09:29:24.167561+02:00 tst-msg03 cyrus/imap[32742]: auditlog: 
> modseq sessionid= 
> mailbox= 
> uniqueid= highestmodseq=<46829>
> 
> 2020-06-19T09:29:24.215036+02:00 tst-msg03 cyrus/imap[32742]: USAGE 
> cyr_restore user: 0.042492 sys: 0.015435
> 
> 2020-06-19T09:29:24.215191+02:00 tst-msg03 cyrus/imap[32742]: auditlog: 
> traffic sessionid= 
> bytes_in=<2412> bytes_out=<1039>
> 
> 2020-06-19T09:29:32.855379+02:00 tst-msg03 cyrus/sync_client[32566]: 
> IOERROR: zero length response to MAILBOXES (end of file reached)
> 
> 2020-06-19T09:29:32.855682+02:00 tst-msg03 cyrus/sync_client[32566]: 
> IOERROR: zero length response to RESTART (end of file reached)
> 
> 2020-06-19T09:29:32.855713+02:00 tst-msg03 cyrus/sync_client[32566]: 
> Error in do_sync(): bailing out! Bad protocol
> 
> 2020-06-19T09:29:32.855738+02:00 tst-msg03 cyrus/sync_client[32566]: 
> Processing sync log file /var/lib/imap/sync/bck/log-run failed: Bad protocol
> 
> I tried again and I see the same result, but without the IOERROR:
> 
> 2020-06-19T09:36:51.153939+02:00 tst-msg03 cyrus/imap[32762]: login: 
> tst-msg03-bck.example.com [10.102.42.169] cyr_restore LOGIN User logged 
> in SESSIONID=
> 
> 2020-06-19T09:36:51.199742+02:00 tst-msg03 cyrus/imap[32762]: 
> example.com!user.utente^archivista: same message appears twice 32096 32097
> 
> (why twice? It expunges 32096 just above)
> 
> 2020-06-19T09:36:51.225525+02:00 tst-msg03 cyrus/imap[32762]: auditlog: 
> append sessionid= 
> mailbox= 
> uniqueid= uid=<32097> modseq=<46834> 
> sysflags= guid=<16ceead9802286784d7a54c5bc782891f76f2f

SOLVED Re: cyrus-imapd exporting databases failed on shutdown - deliver.db.skiplist 2048M

2020-06-21 Thread Pongrácz István
2020. 06.  21, vasárnap keltezéssel 10.53-kor Simon Matter ezt írta:
> 2020. 06.  20, szombat keltezéssel 21.31-kor Simon Matter ezt írta:
> 
> The deliver.db still about 48MB.
> 

I just deleted deliver.db and restart cyrus.
Restarting was pretty quick, takes only some seconds.
New deliver.db created, its size is 8KByte.

So far, so good.

Thank you!

István

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: cyrus-imapd exporting databases failed on shutdown - deliver.db.skiplist 2048M

2020-06-21 Thread Pongrácz István


2020. 06.  21, vasárnap keltezéssel 10.53-kor Simon Matter ezt írta:
> 2020. 06.  20, szombat keltezéssel 21.31-kor Simon Matter ezt írta:
> Please make sure the options here are also valid for your cyrus version.
> However, I also guess your deliver.db is corrupted somehow. From my own
> experience skiplist dbs are easier to handle than bdb and using skiplist
> only has not shown any issues.
> 
> Regards,
> Simon

Hi,

Thank you the hint Simon.
They are valid.

What do you think, should I just delete deliver.db after I stopped cyrus-imap 
and restart again?
What can I loose?

Cheers,
István

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: cyrus-imapd exporting databases failed on shutdown - deliver.db.skiplist 2048M

2020-06-21 Thread Simon Matter via Info-cyrus
> 2020. 06.  20, szombat keltezéssel 21.31-kor Simon Matter ezt írta:
>> Hi,
>>
>> The question is why is the deliver db > 2GB in skiplist format? Is it
>> normal or do you have a corrupt BDB db or does your db pruning not work
>> for deliverdb. I think that should be something like 'delprune
>> cmd="cyr_expire -D 7 -E 3 -X 7" at=0400' in cyrus.conf.
>>
>> I think the easiest way would be to make sure you have pruning
>> configured
>> correctly, then change config of deliver db to skiplist, and start
>> without
>> a db so a new, empty deliver db is created.
>>
>> Then have an eye on the db file to see if it grows again to almost 2GB.
>> If
>> it doesn't grow so much, you should be fine.
>>
>> Regards,
>> Simon
>
> Hi,
>
> Something definitely not seems fine:
>
> -bash-3.2$ /usr/lib/cyrus-imapd/cyr_expire -E 3 -D 7 -X 7 -v

Please make sure the options here are also valid for your cyrus version.
However, I also guess your deliver.db is corrupted somehow. From my own
experience skiplist dbs are easier to handle than bdb and using skiplist
only has not shown any issues.

Regards,
Simon

>
> expunged 0 out of 0 messages from 0 mailboxes
>
> The deliver.db still about 48MB.
>
> Tomorrow I will continue.
>
> Thanks,
> István
>



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