Re: usenet
On Fri, 2014-12-05 at 04:19 -0600, Patrick Goetz wrote: excerpted from my /etc/cyrus/cyrus.conf file: # these are only necessary if receiving/exporting usenet via NNTP # nntp cmd=nntpd listen=nntp prefork=0 # nntpscmd=nntpd -s listen=nntps prefork=0 I wonder if it's finally time to trim all the usenet/news cruft out of cyrus? Yes. Are all the old-timers willing to let go, or is this a backup plan just in case Skynet actually happens and takes over google? What? Google IS Skynet. -- Adam Tauno Williams mailto:awill...@whitemice.org GPG D95ED383 OpenGroupware Developer http://www.opengroupware.us/
Re: Cyrus 2.5 release plan
On Wed, 2014-09-17 at 08:18 +1000, Bron Gondwana wrote: sIf you have a pet feature that MUST be in, or a pet bug that MUST be fixed - let us know now. Bonus points if you've already got a patch for it, or a test case :) I'd really like to see SIEVE scripts assigned to folders are not executed fixed. https://bugzilla.cyrusimap.org/show_bug.cgi?id=3617 Message store events notification is closed, so I assume that is in 2.5.x already. Yay! https://bugzilla.cyrusimap.org/show_bug.cgi?id=3605 -- Adam Tauno Williams mailto:awill...@whitemice.org GPG D95ED383 OpenGroupware Developer http://www.opengroupware.us/
Re: Replication documentation anywhere?
On Fri, 2013-05-24 at 09:41 +0100, Karl Pielorz wrote:
--On 24 May 2013 11:10 +1000 Bron Gondwana br...@fastmail.fm wrote:
I'm afraid there isn't much :( Feel free to ask questions about
specific things you run in to, and we can use that as a basis to put
together more detailed documentation.
Thanks for your reply (which I've read through now!) - if we have an
existing mailstore (with ~2-3 million emails) and we setup a replica is
'sync_client' going to be able to bring the replica to the same state as
the master? (given time, and not too many changes on the master?) - or are
we better off using another method (such as FS snapshot - replica).
Yes, a syncrepl will theoretically transfer all the contents of the
server. But it might be rather brutal.
Personally I would:
(1) rsync the message store from the master to the slave [this will
bulk move tons of files, mailboxes moved first could be quite out of
date by the end.]
(2) rsync the message store from the master to the slave [this will
only moved changed stuff, and give you a reasonably current snapshot of
the mailstore.
(3) rsync the meta-data [/var/lib/imap] from the master to the slave.
(4) run reconstruct on the slave to make sure everything is consistent
(5) run sync_client -v -r -z in screen and watch it for a bit,
verify that messages get replicated as expected
(6) switch to running sync_client 'for real'
You can run sync_client -z -u {user} to sync a user, so if you have an
easy to use list of all your users, or -m {mailboxes} if you generate
a list of all your mailboxes. This can help to 'push' the towards
making sure the replica is up to date; and running multiple
sync_client's seems to work OK.
Presumably the replication doesn't do anything for users (we use sasl for
auth, i.e. saslpasswd2 to create the users) - if we intend to have users
'hitting' the replica (when the master as failed) presumably we'd need to
create those users / passwords on the replica as well?
In a nutshell - when we have the master / replica setup, if we 'switch' to
having users hit the replica (because the master has failed) - it appears
we can simply 'switch' the replication configs over, and then have what was
the master 're-sync' with the new master?
I guess what I'm trying to figure out is if the replication / 'sync_client'
is the 'magic' solution is appears to be - i.e. given enough bandwidth,
time / 'grunt' low enough volume of changes on the master - it'll drag an
empty mailstore up to be an identical replica, or re-sync a once failed
master to be a new replica.
Thanks again for your time,
-Karl
Adam Tauno Williams mailto:awill...@whitemice.org GPG D95ED383
OpenGroupware Developer http://www.opengroupware.us/
Re: Special-Use and Cyrus 2.5 git
On Sun, 2013-05-19 at 12:30 +0200, Jeroen van Meeuwen (Kolab Systems) wrote: On 2013-04-26 16:17, Bron Gondwana wrote: Is anybody actually using cyrus 2.5 git in production other than FastMail? Yes, though admittedly I should say production. No, only just beginning to think about it and look into what is going to get changed in terms of database formats [ - 2.4 was a bit ugly ]. I'm planning to do the mailboxes.db format changes before releasing 2.5, so that we don't have to support a stupid intermediate format. It's been on my todo list for AGES as one of the final blockers to 2.5 being released, and I've finally got some spare cycles away from our internal search code. It would be nice to have all the changes happen at once and just 'get them over with'. Database updates always hit hard. But it would simplify things considerably if I don't have to write an importer that goes upstream. I'd just manually script a conversion of the FastMail servers, and then toss away the intermediate code. None of our systems with 2.5 in production use special-use, nor are they expected to be upgraded smoothly without manual / scripted sysadmin intervention. Adam Tauno Williams mailto:awill...@whitemice.org GPG D95ED383 Systems Administrator, Python Developer, LPI / NCLA
Michel's Proprietary Patches [Was: Cyrus 2.3.16 \Seen flag problem]
On Fri, 2011-04-22 at 15:38 +0200, Julien Coloos wrote: However we think that a better way would be to split at attachment level instead of body level, it could be possible to save base64 overhead, permit de-duping and do data compression (i.e on PDF or Office). May be it would be nice to add an http/webdav daemon to Cyrus to give direct access to the attachments... Pretty wild, and very cool. I know one of the challenges I see is integrating with mail to the same level one can with proprietary packages like Exchange, Google, etc... While at the same time being 'standard'. [And I've developed a WebDAV server, so always interested in WebDAV stuff] - RFC 5423 - Internet Message Store Events is mostly implemented to send external notifications. We add an activemq plugin to notifyd to send JMS notifications. Really?! We are a Cyrus shop and make use of AMQP. I'd love to see this patch [for my own selfish uses].
Re: Cyrus 2.4.8 Released
On Wed, 2011-04-13 at 17:04 +0200, Bron Gondwana wrote: We are pleased to announce the release of Cyrus IMAPd 2.4.8. This is a stable release in the 2.4.x series, fixing a few bugs found since the release of 2.4.7. We urge all users of the 2.4 series to update to this release. The list of reported bugs fixed can be found here: http://cyrusimap.org/mediawiki/index.php/Bugs_Resolved_in_2.4.8 Or if you want extreme detail of all changes made, check git: http://git.cyrusimap.org/cyrus-imapd/log/?id=cyrus-imapd-2.4.8 This list is empty You can download via HTTP or FTP: http://cyrusimap.org/releases/cyrus-imapd-2.4.8.tar.gz ftp://ftp.cyrusimap.org/cyrus-imapd/cyrus-imapd-2.4.8.tar.gz
Re: Universal tool - /usr/bin/cyrus
On Wed, 2011-01-05 at 13:29 +0100, Ondřej Surý wrote: as a part of packaging cyrus-imapd for debian we have talked (and I have coded it) about universal tool (like f.e. git has) which will support all those commands in $libdir/bin/ directory. Does it automatically su to the cyrus [or appropriate] user? I have called it /usr/bin/cyrus, but it's not published yet, so if we can agree on a need to have such command (and since there is several name clash if the cyrus binaries are installed into /usr/bin I think it's good idea to have such command). I would be happy to recode this into something more universal than just a wrapper script to call /usr/lib/cyrus/bin/command so new commands (like make_sha1) could be implemented directly as a subcommand of this universal tool - with fallback to calling external commands. (Look at git source it has a nice example how to implement that.) Sounds sweet. Regarding Look at git source - in what repository?
Re: expire 2.4.5 on replica?
On Thu, 2010-12-02 at 22:31 +1100, Bron Gondwana wrote: On Thu, Dec 02, 2010 at 11:35:16AM +0100, Rudy Gevaert wrote: With the recent changes in 2.4.X it isn't clear to me if I need to run cyr_expire (to expunge mails) on the replica too. Yes, you do still need to run cyr_expire to clean up expunged messages. Not so sure about deleted mailboxes. In fact, that's probably slightly bogus still. The tricky part is - I'd like to not lose messages that were delivered just before the mailbox got deleted... hmm. +1 Would it be possible to delete a deleted-mailbox once it is empty and not until? Then message expiration can continue [like normal (?)] as calculated from the delivery date.
Re: Reconstruct behaviour on IO error
On Mon, 2010-10-04 at 14:26 -0500, Patrick Goetz wrote: On 10/04/2010 02:07 PM, Bron Gondwana wrote: Keep going and remove entires for messages with IO errors reading their file, or bail and make the administrator fix the underlying permissions first? I can see arguments for both - though remember that once you've removed the index record you can never go back under strict UID existence semantics, so if the admin fixes the files later then reconstruct will actually give them new UIDs. Definitely bail. +1 Now I think that error should at least include the file name Absolutely, yes. Nothing is more annoying than File not found.
Re: Add cyrus-devel list to Bugzilla bugs?
On Wed, 2010-05-26 at 15:26 +0200, Bron Gondwana wrote: Look for useqacontact. First, thanks for saving me a ton of time, Dan. useqacontact was set to off, and I changed that so it's now on. I noticed that pretty much every component of the Cyrus IMAP product already had a QA Contact defined as cyrus-bugzi...@lists.andrew.cmu.edu, which would, as the address implies, be delivered to the cyrus-bugzilla list. The archives of this list show that some amount of mail was already being sent there, but if useqacontact does what it's documented to do, this list should now begin getting a lot more mail. Is everyone okay with just keeping things the way they are configured now, assuming that the mail is actually being sent out, or would you rather I change the QA contact to be cyrus-devel@lists.andrew.cmu.edu instead of cyrus-bugzi...@lists.andrew.cmu.edu? I can't see why we can't sign up to cyrus-bugzilla if we want to see it! There hasn't been any traffic on cyrus-bugzilla since January 2010 according to the archives - and that was two people asking troubleshooting questions. You have to go back to April 2007 to see bug traffic. https://lists.andrew.cmu.edu/mailman/private/cyrus-bugzilla/ Doesn't seem to me like it is working. Is there any way to automatically set up the reply-to so that replies come to cyrus-devel? That way we can choose if we want to see every bug or only the discussion that bugs spark... -- Adam Tauno Williams awill...@whitemice.org LPIC-1, Novell CLA http://www.whitemiceconsulting.com OpenGroupware, Cyrus IMAPd, Postfix, OpenLDAP, Samba
Re: ANNOTATEMORE = METADATA and rfc 5464
Do we have a roadmap for what else people want on the 2.4 branch? I'd be happy to put a bit more effort into polishing up those features that are there so we can ship a 2.4 soonish. Say by April next year, which gives us 6 months to prepare. My original vision for 2.4 was to be compliant with the LEMONADE v2 profile. Sounds like a good plan :) At this point is can morph into anything we want. Some of the 2.4 features required changes that I felt were too in depth to put into a relatively stable 2.3. I'm pretty close to having the time to dive back into the 2.4 code. The first thing that needs to be done is to merge all of the new 2.3 stuff into 2.4. Sure. I'm happy to put the more unstable stuff (even including the charset changes) into 2.4. I just want to have some idea that they won't get stuck waiting for some lemonade scented towlettes forever. Is Lemonade still alive? I haven't heard much about it, and I'm pretty sure I read a couple of articles/BLOGs that the initiative was essentially dead. Dump and restore your DB and do it this way! In general I'd like to simplify configuration where possible even at the expense of backwards compatibility. +1 Fine with me. We could have a config_version: 2.4 key which needs to be changed over major version differences, and keep configs compatible within the major versions. (2.x that is) -- OpenGroupware developer: awill...@whitemice.org http://whitemiceconsulting.blogspot.com/ OpenGroupare Cyrus IMAPd documenation @ http://docs.opengroupware.org/Members/whitemice/wmogag/file_view
