Re: OT: Enhanced IMAP protocol
Robert Banz wrote: An extension or protocol enhancement is only good as the client implementations are -- and we know how successful that's been for other optional capabilities -- such as ACL management. Almost nobody cares about ACLs, so almost nobody implements it (sad, but true). I would argue that a much larger percentage of users care about credential management. Now if it's large enough or not remains to be seen. I suspect it would take a large email provider to drive the standard and provide the reference implementation for it to be successful. -- Carson Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: cyrus replication : master to replica and replica to master
On 10/23/09 7:42 AM, David Carter wrote: On Fri, 23 Oct 2009, Bron Gondwana wrote: I've seen heartbeat get split brain before. We gave up on it. We do all our fencing via humans now! Check the KVM, kick the box, manually run the failover script. Some of my colleagues have had a lot of grief with Heartbeat going split brain. It seems to really be designed for a pair of machines sitting next to each other in a rack with a serial link for the heartbeat, rather servers installed in a pair of machine rooms three miles apart. To be fair to heartbeat, if you're getting unexpected split brain, then you have configured it incorrectly. A 2 node cluster without _extremely_ reliable communication and fencing between the nodes requires a tie-breaker service. This is true of any clustering technology I have ever seen. Heartbeat provides a light-weight quorum service for just this purpose. Of course if you only have 2 sites, and the site with the extra vote goes down, you lose the service. Anything else requires 3 sites, or a meatware failover decision. -- Carson Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Upgrade and Migration
Ben Carter wrote: Carson Gaspar wrote: Ben Carter wrote: You have to do the _exact_ same thing with imapsync, unless you want to lose email. As has already been pointed out, you are incorrect. The order is: [Pre-create inboxes with large quotas on new server] 1. Shut off mail delivery to old server 2. Shut off imapd on old server. 3. Bring up new server with imapd running 4. Start mail delivery to new server. 5. Start imapd on old server with a new IP address or bound to a nonstandard port so MUAs will not get to it. 6. Migrate data using imapsync. And your service can be down literally for only a few minutes if you plan correctly. You have chosen to have users see missing data. You have made a tradeoff between correctness and length of downtime by bringing up your new server in a client visible way before you sync your data. I (foolishly, it seems) assumed that you wouldn't want your users to log in to empty mailboxes, and would leave your new server non-user-visible until your sync completed. -- Carson Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Upgrade and Migration
Ben Carter wrote: If you use rsync, you have to stop everything until that finishes, possibly reconstruct all mailboxes, maybe fix some other things before giving people their mail functionality back and allowing mail delivery to resume. That's just silly. If you're going to use rsync to migrate data, you do at least one rsync while the source data is live. More than one if the initial sync takes a long time. Then you go offline, do a final sync (which should be very fast), and bring the new data store online. You have to do the _exact_ same thing with imapsync, unless you want to lose email. Also, the ACL format in the mailboxes file might be different between these 2 Cyrus versions. Might be, but I don't think it is. If you use the protocol to move the data, you don't have to worry about any data structure differences etc. You also can re-arrange your partitions and so on. Plus it re-calculates all quota usage as imapsync APPENDs the messages during the migration. All true, except to the best of my knowledge none of this (except repartitioning, which the OP didn't mention) matters for cyrus imapd - it will Just Work(tm) on your old data store. The only exceptions are database format changes (if you use bdb and you've revved the library version, for example), and sieve compiled bytecode. And why do you care about quota re-calculation? The existing quota data should be correct. -- Carson Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Calling all regressions
Bron Gondwana wrote: AAA+++ to cyr_conf! I'll write it up :) I think we want it to have the following spec: * cyr_conf - output all configuration variables and their current value * cyr_conf -C $file - as above with the following config file * cyr_conf -n $name - all configuration variables for process $name (eg cyr_conf -n imapd = show imapd overrides where given) * cyr_conf -q - only show variables that are different than default - those three can be mixed and matched * cyr_conf -D - show all the DEFAULT variables. Obviously, ignores all other options! Please include one of the most useful options that postconf has (postconf -n) - emit only those config key/value pairs that are not set to their default values. More often useful in real life than just emitting all config key/value pairs. -- Carson Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Calling all regressions
Bron Gondwana wrote: On Thu, Mar 12, 2009 at 02:55:03AM -0700, Carson Gaspar wrote: Bron Gondwana wrote: ... * cyr_conf -q - only show variables that are different than default ... Please include one of the most useful options that postconf has (postconf -n) - emit only those config key/value pairs that are not set ... Yeah, I called that -q. If we make it -n then we'll have to make the named process config a different character. The spec isn't nailed down yet, I haven't even written anything! I clearly suffered a fault in my reading subsystem... my apologies, and consider this a +1 for the whole idea. Which letter does what I really don't care about. -- Carson Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: imapd and spamassassin
Daniel Aquino wrote: Instead of doing spam checking in the mta. Could spam assassin be ran on submission to the impad daemon? My spamassassin sits between my MTA and cyrus via an LMTP proxy (spampd). This may do mostly what you want. -- Carson Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: digest-md5 password store
Ken Murchison wrote: The SASLv1 library used to store a non-plaintext secret for use with DIGEST-MD5. In fact, it stored separate secrets for each mechanism. In SASLv2, it was decided to use a single plaintext secret. Part of this decision was based on the fact that the DIGEST-MD5 secret was tied to the servername/domain, which made the database non-portable. And I've complained about that decision ever since. I still maintain that it was a _terrible_ idea :-( As someone else said, it is possible to store an interim hash that is user and realm specific to avoid storing the plain text password. If you want portability, you just have to use the same realm on all servers in the same authentication group. _You_ get to choose the scope of validity for the stored secret. Sadly with cyrus-sasl v2 the maintainers have chosen for you, and they chose the entire known universe :-( -- Carson Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: setrlimit: Unable to set file descriptors limit to -1: Operation not permitted
Benjamin Donnachie wrote: JOYDEEP wrote: setrlimit: Unable to set file descriptors limit to -1: Operation not permitted I seem to recall this either being covered in here before or in the docs. Basically, some operating systems let you set the file descriptor limit to -1, which means unlimited. Some don't and generate that error. You can safely ignore it. If it's meaningless, and expected, why log it at all? Logging noise is almost always a bad idea. -- Carson Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: how to enable digestmd5 and crammd5 ?
Goetz Babin-Ebell wrote: The problem is that cram-md5 and digest-md5 need direct access to the pass phrase in plain text. AFAIK LDAP doesn't support this. You have to use TLS if you want to transmit the pass phrase securely... Technically not true, you need the password hashed with the username and realm. But cyrus-sasl dropped support for storing the hashes a long time ago and has never brought it back. I can't comment on the LDAP plugin's ability to store/retreive plain text passwords, as I've never used it. -- Carson Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: SQUAT failed
Marten Lehmann wrote: or change the cyrus loglevel to disable the No such file. How? I looked through the manpages, but there is no loglevel or syslog-threshold in cyrus. syslog.conf (Or whatever syslogd replacement config file you use) -- Carson Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: [CVS] pidfile support
--On Tuesday, December 17, 2002 1:12 PM -0200 Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: [A] 1. stat pidfile 2. file exists? 2a (yes) - read pid from file, kill(pid,0) it 2a1 - kill says process exists? fail to start if so No no no. You must check and see if the PID that exists is sane - e.g. has the correct process name. Otherwise, you can get into a situation where you never restart at reboot, if some other process has that PID. -- Carson
Re: Problems with ./configure on SunOS 9
--On Wednesday, December 08, 2027 11:13 PM +0100 [EMAIL PROTECTED] wrote: Laurent Larquère wrote: Thank you very much ! We´ve tried it this way now. And ... IT WORKS ! :) It´s been a long time now that i´ve had my hands on a non-linux system and so i relied 100% on the configure-script :/ I thought it is supposed to do things properly, you know :) The cyrus configure scripts still need some work. Does anyone know if they work with the current autoconf yet? I've been waiting for that to happen before I go in and fix the pathing problems, as I really am not set up to test autoconf 2.13. -- Carson
Re: Problems with cyrus-imapd 2.1.11 under Solaris 8
--On Thursday, December 05, 2002 10:22 PM +0300 Oleg Derevenetz [EMAIL PROTECTED] wrote: When some pop3d dies with signal (i.e. SIGTERM), all incoming connections to corresponding address:port are hangs. For example, if I have pop3d I can confirm that the same bug exists under Solaris 8 x86 (fully patched) with imapd. To reproduce: - Start master - connect to imapd - kill the imapd process No further imapd processes will be spawned. This is reliable - not a race condition. I'll see if I can figure out what died in the code. -- Carson
Re: Problems with cyrus-imapd 2.1.11 under Solaris 8
--On Thursday, December 05, 2002 4:58 PM -0500 Rob Siemborski [EMAIL PROTECTED] wrote: This isn't good enough for me to reproduce it. I have tried both with preforking and without preforking. I cannot get 2.1.11 to behave like this on Solaris 8. Master didn't change since 2.1.10 so I don't know what this could be. And of course now I can't, either. Odd... -- Carson
Re: Getting SASL from CVS --- automake complains about errors
--On Sunday, October 06, 2002 4:08 AM +0200 Christian Schulte [EMAIL PROTECTED] wrote: I do not have a /usr/share/lib/tmac/tmac.doc file for my nroff. I wanted to try groff but could not compile it on my system. Can someone send me this file ? I am using Solaris 8 on ix86 and I do not know, why nroff -mdoc cannot work. Solaris does not include the Berkeley 4.4 doc macros. Either compile groff (it builds fine for me), or grab mdoc2man.pl from the OpenSSH package. -- Carson
Re: Time has come to stop with /usr/local path pollution!
--On Friday, September 27, 2002 10:34 AM -0400 Ken Murchison [EMAIL PROTECTED] wrote: A lot of bitching, and no proposed fixes. It works for me, and I'm sure I have submitted patches in the past to fix this dain-bramaged configure behaviour. They have been ignored. Lots of the --with-foo options are implemented badly in configure.in. I'd like to fix them, but can't until the maintainers stop insisting on supporting autoconf-2.13. At this point, I've basically given up, and just manually hack configure to be non-idiotic before I configure a new release. -- Carson
