Re: Plus Addressing (ORA book)
On Tue, 16 Dec 2003, Pollywog wrote: > There is also an O'Reilly book and some of the book is available online here: > > http://www.oreilly.com/catalog/mimap/chapter/ch09.html > > > Looks like a book I might want to buy. > Save your money -- this book is hopelessly out of date. I've read it and found it next to useless for working with Cyrus 2.x
Unable to save "read" flag on some mailboxes
I seem to be having a very peculiar problem with cyrus 2.1.15. We recently had a system crash over the holidays (while no one was monitoring the server) wherein the root filesystem went read-only and (somehow) the cyrus log files grew to fill the partition (with mail.err and mail.log being over 10GB each). After removing and resetting the log files and rebooting the machine, everything seemed fine save for one thing: some mailboxes seem to no longer be able to set flags on messages. For example, for most users, messages don't stay marked as read, but get marked as "not read" every time the mailbox is re-read. Oddly, this doesn't happen to all mailboxes; for some accounts this information is retained. I thought this might have something to do with permissions on, say, the cyrus.index file in the mailbox directory, but I compared permissions between a "good" mailbox and a "bad" one, and the permissions on all cyrus.* files were identical. Does anyone have any ideas about this? Also, this is probably in some documentation somewhere, but how does one reduce the amount of information being logged by cyrus? I looked in the /etc/cyrus.conf file, but couldn't find anything relevant.
Cyrus 2.1.15 database files
OK, no response on the "unable to update user.seen database files" for some users question I asked earlier, so let me try something else. Is there any documentation on the cyrus database files? For example, since /var/lib/cyrus/user/t/this_user.seen seems not to be keeping track of what messages this_user has looked at, can I just delete this file and assume that cyrus will create another one? Which database files do what? Which ones (if any) can be safely deleted, since they will be automatically regenerated (with, of course, a loss of information)? Which database files must be backed up in order to fully restore a cyrus mail system when a system is re-installed? I looked at the wiki and have read the documentation (I think), and I can't find an answer to any of these questions.
Follow-Up: Unable to update seen flag for some mailboxes
Yesterday I posted a question to this list regarding a problem I was having with the mailboxes for some users on cyrus 2.1.15; namely previously read messages were being marked as "unread" every time the mailbox listing was refreshed by the IMAP server. One thing I didn't make clear was that this problem was independent of MUA: using pine directly on the mailhost was no better than using Thunderbird on a Windows client; as soon as pine was quit and restarted, the "N" would reappear on previously viewed messages. In any case, I tried several things including - restarting the cyrus master daemon - checking ownership and permissions on all the cyrus database files - running ctl_cyrusdb -r None of this worked, and all the permissions/ownership on the database files was correct. The only thing which worked was deleting this file: /var/lib/cyrus/user/t/this_user/this_user.seen Steps: 1. Stop cyrmaster 2. rm /var/lib/cyrus/user/t/this_user/this_user.seen 3. Start cyrmaster the this_user.seen db file was automatically recreated and read messages stayed read between restarts of the MUA. I suppose that a drawback of simply deleting the seen database file is that all information about which messages have been read is lost, but it's not at all clear at this point that there was any alternative.
automating administrative tasks in Cyrus 2.1.15
Sorry if this is a stupid question, I'm relatively new to cyrus as an administrator and have made an effort to RTFM. I'm wondering if there is any way to automate administrative tasks in Cyrus? I ask because I recently inherited the job of administering a debian Cyrus 2.1.15 system at the same time that the system crashed and the contents of /var/lib/cyrus were lost. It was a major chore to recreate each top level mailbox and then run reconstruct -r user.a_user for each individual user. The O'Reilly Managing IMAP book talks about using `cyradm connect` with TCL scripts, but this seems not to be an option with the new Perl version of cyradm, and I have been unable to identify any replacement system. It seems has if automating Cyrus Administration tasks has simply dropped off the face of the planet; sort of like a taboo thing that no one dares talk about -- certainly I haven't been able to find anything. Even being able to do a reconstruct -m would have been a big help, but the man page simple admonishes "NOTE: CURRENTLY UNAVAILABLE" and leaves it at that. Am I missing something? Is google no longer my friend?
Re: automating administrative tasks in Cyrus 2.1.15
On Thu, 20 Nov 2003, Andrew Morgan wrote: > > It depends what you are trying to do... It is pretty easy to call > reconstruct once for each user just by feeding a list of usernames to a > shell or perl script. > > We do all of the "regular" administration tasks here using perl scripts > and the IMAP::Admin module. Simple things like creating mailboxes, > deleting mailboxes, changing quotas, listing quotas, sending quota > warnings, listing folders, granting access, and so on. I don't mind > sharing these tools if people are interested. > I for one would definately be interested. I'm particularly curious about how you handle authentication, but this is probably explained in the documentation for the IMAP perl module, which I didn't take a look at. Well, I guess I'm assuming that this module is documented somewhere -- it it?
Mailboxes which won't come back online
This using Cyrus 2.1.15 ... Last week I pestered this list about a situation wherein the contents of /var/lib/cyrus (i.e. the database) were lost in a system crash while the contents of /var/spool/cyrus/mail (i.e. the actual messages) were preserved. After using cyradm -> cm to recreate the user.username mailboxes and running cyrreconstruct -r user.username for each account, the system is mostly back in working order with one exception. One of the users has a mail folder which contains no messages but only other folders. Try as I might, I simply can't get cyrus to acknowledge the existence of this folder or any of it's sub-folders; i.e. when I run cyrreconstruct -r user.this_user_name it picks up everthing in /var/spool/cyrus/mail/m/user/muser EXCEPT for the this particular directory. Consequently the folders don't show up in any IMAP MUA, either, and hence can't be used. Running `cyrreconstruct -f user.this_user_name` first doesn't do anything, either. Does anyone have any idea why this might be and/or how I can get these folders back into the cyrus database? The permission on all files are the same, so it can't be a permissions problem. Since this directory doesn't contain any actual messages, the files cyrus.cache cyrus.header cyrus.index cyrus.seen don't exist, but they are in the subdirectories which contain actual messages. Of course this user has 25 or so filters set up which automatically filter messages to mail folders in this directory, so having this stuff not available through the cyrus server is a major pain in the a**. In general, it's rather disturbing to be in a situation where physical messages actually exist in the cyrus mail heirarchy, but the cyrus server refuses to see them.
Mailboxes which won't come back online
Many thanks to everyone who responded to this question. Yes, it seems pretty safe to assume that this (not reconstructing mail folders that don't contain explicit messages) is a bug; but then why doesn't cyrreconstruct -m work? I can't imagine why this would be that more complicated to implement than `cyrreconstruct -r user.username`; after all, it's only moving one level up in the mailbox hierarchy. In any case, I didn't try copying a message into the offending folder and then running reconstruct again, as this worked: (The mail folder containing folders but no explicit messages is called "Professional".) cyradm -> cm user.bubba.Professional then, logged in as cyrus: cyrreconstruct -f user.bubba.Professional cyrreconstruct -r user.bubba
Re: Draft: Bugzilla Work Flow
On 09/04/2010 07:41 AM, Jeroen van Meeuwen (Kolab Systems) wrote: > To allow some early feedback, I'm putting the page on the list now as opposed > to when I feel like I'm done documenting everything in full ;-) > > > http://www.cyrusimap.org/mediawiki/index.php/User:Jeroen_van_Meeuwen/Drafts/Bugzilla_Work_Flow > This page is accessible, but what happened to the cyrus wiki? There seems to be a new web page for cyrus which doesn't appear very wiki-like (http://www.cyrusimap.org/), and googling only takes me to this page. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Store documents in IMAP folders
On 09/12/2010 09:10 AM, Gavin McCullagh wrote: >> The goal is to have a PDF library available at any time, with basic file >> search on document/message name, so a file share doesn't solve my problem >> (and I don't want any document management system, I just want access to >> files). > > I don't imagine IMAP's search would work on MIME attachments, unless you > did something like add a plain text version to the body of the email. > I think he just wants to be able to search on the document name; although, if you're going to write a custom script to get the documents into an IMAP folder, then there's nothing stopping you from harvesting the text from the PDF file and placing it in the body of the message containing the attached document. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: De-duping attachments
On 09/14/2010 11:55 PM, Rob Mueller wrote: > > Eg. An architectural firm > might end up sending big blueprint documents back and forth between each > other a lot, so they'd gain a lot from deduplication. > Not to throw a damp towel on this discussion, but isn't this really an administrative problem rather than a technical one? I.e. shouldn't the system administrator set up a version control system or even something like dropbox for file sharing rather than using email for this situation? > if you know the same file is being sent back and forth a lot with > minor changes, you might want to store the most "recent" version, > and store binary diffs between the most recent and old versions > (eg xdelta). Yes accessing the older versions would be much > slower (have to get most recent + > apply N deltas), but the space savings could be huge. My users frequently mail documents to the person in the office next door (never mind that both their home directories are on the same server!); however this content is almost always different for each attached file; i.e. without re-implementing a version control system under IMAP, as you're suggesting, there would be little benefit in keeping and hard linking to a single copy of each file. However, that seems like it fails the UNIX "do one thing, and do it well" test pretty badly. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: competition
On 9/20/2010 8:59 AM, Marc Patermann wrote: > And still, if someone asks a mailing list (not here certainly) how to > start with IMAPd, many people shout, to go with dovecot and not using Cyrus. Hi - A little late to this thread, but here are a couple of modest observations: 1. I have cyrus and dovecot installations (with postfix smtp). dovecot doesn't support an lmtp transport, which I finally decided was a deal killer. In our (~1000 user) dovecot system, we're using procmail to ferry messages from the smtp server to dovecot deliver. One very disturbing recent finding is that with some regularity messages are not being delivered with no notification to the sender -- they just get dropped. We think it's an ldap authentication problem, but it doesn't really matter what the cause is: mail should either be delivered or someone should find out that it wasn't withough having to snoop around in log files. Procmail is *supposed* to send this stuff back up the pipe when something goes wrong, but it's not happening. Using lmtp is clean and simple and affords the administrator a huge amount of flexibility when using postfix: mailbox_transport = lmtp:unix:/var/run/cyrus/socket/lmtp This doesn't work with dovecot; you have to use the mailbox_command. 2. I hate Maildir, and Maildir+ is a kludge. I have some users whose mail folders are nested multiple levels deep, and when push comes to shove it's nice to be able to use the file system to examine mail messages easily. dovecot will eventually support some new format called dbox, but when I asked him about it, the dovecot developer told me that it's not production quality yet. The simple filesystem mail message interface is another thing I like about cyrus. 3. So, why the sudden popularity of dovecot? It could come down to documentation. The cyrus documentation currently is beyond terrible. Dovecot has an excellent wiki which covers an awful lot of use cases. Further, the dovecot developer (I think there's only one) is a nice guy whom you can frequently find on IRC. I've learned a lot about debugging imap problems directly from him. That said, after spending the summer on the cyrus-devel list, I have a lot of confidence in the work that particularly Bron Gondwana has been doing and think that with -- with an infusion of some clear documentation, a project I'm more than happy to contribute to -- cyrus can probably become the default open source imap server. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: competition
On 9/22/2010 10:20 PM, Shuvam Misra wrote: > I was a strong advocate of bundling DB libraries, etc, with Cyrus. The > points you've made here are very interesting. I didn't know many of these > things. I'm re-thinking whether bundling is such a good idea now. Thanks. > There's a lot to be said for the Mac OS X approach. However, as someone already pointed out, most distributions won't allow this (for many reasons), so it's pointless to even talk about going there. Better to just use an internal DB codebase (like skiplists) that has nothing to do with Sleepycat. But then someone has to write and maintain this code. I think the best compromise I've heard yet is to use something like skiplists by default and make the use of libdb an optional feature like the use of mysql. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: cyrus 2.3.14 on opensuse 11.1 x64 and lmtp errors
On 09/27/2010 05:39 AM, Josef Karliak wrote: > > > What is going on ? On cyrus 2.2.12 is all ok. When subject don't contain > "=?utf-8?B?Tm9" (I rewrote it to "test subject" for example), email is > delivered. > It sounds like your email header contains 8-bit letters. This is a violation of RFC2882, which says that ASCII-only (7-bit). You can configure /etc/imapd.conf to accept messages like this by setting reject8bit: no but this is not recommended and will likely subject you to more spam. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
cyradm and allowing only encrypted passwords with 2.3.16?
I was having problems making Cyrus 2.2.x work with only encrypted passwords. Setting allowplaintext: no in imapd.conf prevents plain text logins, but then cyradm stops working: ibis:~etc$ cyradm localhost Login disabled. cyradm: cannot authenticate to server as pgoetz I thought this was fixed in 2.3.x, but apparently not. I'm having exactly the same problem. If I set allowplaintext: no, then cyradm stops working as described above. Any thoughts on this? Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: IMAP not seeing old mail present on filesystem
On 10/3/2010 6:57 AM, Chris Pepper wrote: > > More importantly, I don't know how to make the old messages > accessible to my users via IMAP (I can give them the files, but that's > quite awkward). chk_cyrus agrees with IMAP clients about message counts > (very low). I have tried reconstruct with various combinations of > "-rfx", and "quota -f", but not found any way to make it show the old > messages. > > Any suggestions? > You probably need to run cyrreconstruct on each user mailbox. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: IMAP not seeing old mail present on filesystem
On 10/04/2010 08:37 AM, Chris Pepper wrote: > > No, users see the folders, just not old messages. For most (all?) > INBOXes but my own, new messages started arriving as 1. and continued > from there. Users can see the new mail, but not the old. This makes me > think it's not an internal permissions problem, because they see the > mailboxes and (some) mail in them. All file permissions I checked appear > correct > > "reconstruct -rfx" doesn't help. Is there anything else to try? > I wasn't clear about whether the old install was completely gone or could still be booted. If you can still start cyrus on the old server, you could try imapsync to transfer mail to the new one. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: cyradm and allowing only encrypted passwords with 2.3.16?
On 10/04/2010 08:41 AM, Wesley Craig wrote: > > TLS isn't available to Cyrus::IMAP pre 2.3.2. I expect it's a bug. Sorry,I didn't specifically say that I'm using the latest release, 2.3.16. I find cyradm to be very convenient to use for smaller sites, but is this essentially a dead tool and I need to be rolling my own administrative tools? Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: IMAP not seeing old mail present on filesystem
On 10/04/2010 08:47 AM, Bron Gondwana wrote: > A script to find each file and IMAP append it? Just thinking outside the box > here! > How would you do the IMAP append? Using a Perl::IMAP function? This isn't necessarily a concern for this list, but a few days ago I upgraded a site from cyrus 2.1.16 to cyrus 2.3.16 by using imapsync to transfer mail from the old server to the new one. This worked great (i.e. all metadata seems to have been preserved), however the old server was still collecting mail for the few hours it took to imapsync all the users (note that this is very slows and probably not appropriate for larger sites). My plan was to swap the servers and then do a final imapsync from the old IMAP server to the new one. For some reason, for some users the additional set of new messages is copied to the new server, and others they aren't. I couldn't figure out what the difference is, and don't want to spend too much more time on this because of the small number of messages in play, so I need some way to transfer a couple of dozen messages "by hand". In general, though imapsync seems to be a great way to "clean up" cyrus folders when switching servers. Had I known I would have sync problem later, I would have just taken the old server off line before syncing the messages. Before someone suggests that I should have just copied /var/lib/cyrus and the messages over to the new server, I didn't trust this because I couldn't get anyone to confirm the database files I had on the old 2.1.16 server -- the filenames were mostly not the same as this set: annotation_db duplicate_db mboxlist_db ptscache_db quota_db seenstate_db tlscache_db and the old server experienced a couple of devastating crashes which required me to cyrreconstruct all the user.user mailboxes a couple of times. It seemed pretty clear that the db files on the old server were a mess, and upgrading from anywhere from libdb2 to libdb4.3 to libdb4.8 seemed sketchy as well. The old server is such an old debian system that apt-cache depends doesn't seem to work any more because the package servers have changed. (Yeah, I could probably find the source packages somewhere, but then there are a lot of things I could do given infinite time.) Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: IMAP not seeing old mail present on filesystem
On 10/04/2010 10:17 AM, Chris Pepper wrote: > On 10/4/10 10:23 AM, Patrick Goetz wrote: >> >> I wasn't clear about whether the old install was completely gone or >> could still be booted. If you can still start cyrus on the old server, >> you could try imapsync to transfer mail to the new one. > > Old system is not bootable, unfortunately. > > FYI: I have 943 directories & 298,409 mail files, so manually fixing > things isn't feasible. > This seems like a long shot, but could you temporarily set up another machine with the old version of CentOS, copy /var/lib/cyrus and /var/spool/cyrus to this machine as is from the old server, and then run imapsync? The other option is as Bron suggested, using some kind of IMAP function to append "lost" messages to the spool. I'm pretty that this will result in all the metadata being lost (i.e. replied to and forwarded flags, etc.) (And moreover, I don't know to do this, so can't advise.) Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: cyradm and allowing only encrypted passwords with 2.3.16?
On 10/04/2010 11:07 AM, Dan White wrote: > > You can connect via a non plaintext mechanism, like digest-md5. > This seems like a straightforward case of RTFM, but how does one determine the auth mechanism? I'm using saslauthd, pam, and have a self-signed certificate (which I know works): - ibis:~~$ cyradm --auth digest-md5 --tlskey /etc/ssl/private/ssl-cert-mail.internetbs.com.key localhost [ unable to get certificate from '/etc/ssl/private/ssl-cert-mail.internetbs.com.key' ] [ TLS engine: cannot load cert/key data, might be a cert/key mismatch] [ TLS engine failed ] ^C ibis:~~$ ibis:~ssl$ sudo ls -l /etc/ssl/private total 8 -rw-r- 1 root ssl-cert 887 2009-09-13 14:02 ssl-cert-mail.internetbs.com.key -rw-r- 1 root ssl-cert 887 2010-04-11 14:00 ssl-cert-snakeoil.key ibis:~ssl$ groups cyrus cyrus : mail sasl ssl-cert Maybe the problem is I'm still not 100% clear on how SASL works. I have saslauthd running with MECHANISMS="pam" OPTIONS="-c -m /var/run/saslauthd" However, there's no sasl pam.d config file -- presumably SASL somehow uses /etc/pam.d/imap /etc/pam.d/lmtp ??? I don't have lmtp running in a chroot jail, which is how I can get away with this. smtp does run in a chroot jail, but has it's own saslauthd with OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd" I don't remember anyone mentioning this possibility (running multiple saslauthd daemons) in any howto; most people seem to jump through inordinate hoops to get all other programs to use the sasl socket in the smtp chroot jail, which seems to unnecessarily complicate things. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: cyradm and allowing only encrypted passwords with 2.3.16?
On 10/04/2010 11:41 AM, Wesley Craig wrote: > I understood that, tho I did notice you pasted the 2.2.x error, not the 2.3.x > error. > Nope, this is precisely the error I'm getting on my 2.3.16 install: ibis:~~$ dpkg -l | grep cyrus-common ii cyrus-common-2.32.3.16-1 Cyrus mail system - common files ibis:~~$ cyradm localhost Login disabled. cyradm: cannot authenticate to server as pgoetz ibis:~~$ > Why would you suppose it's a dead tool? Because it has a bug? > I'm just asking because it's not working for me when I disable plain text authentication. <:) See my previous message for efforts to use cyradm [--auth mechanism] [--tlskey keyfile] flags to get around this. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: cyradm and allowing only encrypted passwords with 2.3.16?
On 10/04/2010 12:29 PM, Andrew Morgan wrote: > > cyrus-be4:~# cyradm --user cyrus --tlskey '' localhost That did it! The trick is to use --tlskey with an empty field as demonstrated above. Who knew? -- ibis:~~$ cyradm --user pgoetz --tlskey '' localhost verify error:num=18:self signed certificate Password: localhost> -- Thanks for your help with this. The next question is how anyone would have figured this out without help from this list.. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: IMAPS only for some users.
On 10/05/2010 05:50 AM, Josef Karliak wrote:
> Hi there,
> is it possible to allow imaps only for some users (accounts are in the
> passwd) ?
> I want to accept imaps from net for few special users. Others are
> authorized only over imap clients from local network.
> Thanks.
I'm not sure if you can do this withing cyrus, but if not, you could use
a firewall (e.g. iptables) to restrict port 143/993 traffic to
particular uid's:
iptables -A my_chain -o ethX -m owner --uid-owner {USERNAME}
--destination-port 143 -j ACCEPT
This might get onerous to manage if you have a lot of user accounts, though.
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: packages for solaris 10 x86
On 10/5/2010 7:01 PM, Frank Pittel wrote:
> In file included from auth_getpwent.c:53:
> /usr/include/crypt.h:36: error: syntax error before '(' token
> /usr/include/crypt.h:36: error: syntax error before "const"
Did you check the /usr/include/crypt.h file to see if there is actually
a syntax error on this line?
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Wildcard SSL cert gives "error initilizing TLS"
On 10/06/2010 07:41 AM, Paul van der Vlis wrote: > > I found the problem. Very stupid: the cert-file was not readable by the > user Cyrus. Ahum, very stupid. > This is a very common gotcha. One debian/Ubuntu systems only members of the ssl-cert group and read private keys. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Using mbox2cyrus.pl
I have a few mbox files that I need to transfer to cyrus (one relatively large ~3MB). I downloaded the perl script mbox2cyrus.pl, and looked over the code, and I'm not confident that this will work for a system with unixhierarchysep: yes Does anyone have any experience with this? Am I going to have to rewrite this script to get at my mbox files? Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Using mbox2cyrus.pl
On 10/07/2010 11:03 AM, Joseph Brennan wrote: > > > If this is relevant-- Pine can copy a local mbox file to an imap server. > > How would this work? We use alpine extensively, and AFAIK it's either configured for IMAP or mbox, but not both. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Using mbox2cyrus.pl
This is one of the most useful pieces of information I've gotten in a long time -- Thanks! (as a none mutt user, I had no idea one could do anything like this) On 10/07/2010 11:24 AM, Gavin McCullagh wrote: > Hi, > > On Thu, 07 Oct 2010, Patrick Goetz wrote: > >> I have a few mbox files that I need to transfer to cyrus (one relatively >> large ~3MB). I downloaded the perl script mbox2cyrus.pl, and looked >> over the code, and I'm not confident that this will work for a system with >> >> unixhierarchysep: yes >> >> Does anyone have any experience with this? Am I going to have to >> rewrite this script to get at my mbox files? > > If you have mutt around the place you can do: > > mutt -f > (should open the mbox) > T > all > (should tag all files) > ;C > imaps://@/ > (copy all tagged mails > > which should copy all mails to on that imap server. > > Gavin > > > Cyrus Home Page: http://www.cyrusimap.org/ > List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ > Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: service imap pid nnn in BUSY state: terminated abnormally
On 10/9/2010 7:23 AM, Michael D. Sofka wrote: > > I can either rsync just the mail messages to the warm backup, and then > reconstruct the index files. Or, I can take a slight detour, and upgrade the > warm backup server to 2.3.16. > This is something I've been wondering, too. The problem with not copying the indexes is that presumably you lose all the metadata. And if you rsync /var/spool/cyrus/mail it would seem to me that you run the risk of the index being out of sync with the mail spool; i.e. the only way to safely use rsync is stop cyrus rsync restart cyrus Which isn't practical for some environments. imapsync seems to work fairly well and doesn't suffer from any race conditions like this, however requires that you have each user's imap password. The solution that I'm considering is creating a dummy user called "mail-backup" or something like this and giving this user write permission on every mail account. This way a single user could back up all the imap user folders on the server. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
messages in mailbox aren't visible
Hi - I'm stumped by the following problem. recently I transferred a bunch of users to a new 2.3.16 cyrus server. One user in particular has hundreds of mailboxes nested several levels deep. Most folders transferred correctly. One of these subfolders, however, user.bubba.AMG."Correspondence ABC".Board contains further subfolders and messages. The subfolders show up, but not the messages in the folder. Similar folders in other parts of the folder tree don't have this problem. I tried unsubscribing and re-subscribing to the folder, this didn't help. I've tried using cyradm to (re)create the mailbox: cm user.bubba.AMG."Correspondence ABC".Board and got "Mailbox already exists". I've tried using reconstruct: cyrreconstruct -f user.bubba.AMG."Correspondence ABC".Board and this didn't help, either. After doing a little googling I suspect that the IMAP \Noselect flag is set. Is there some straightforward way to reset this flag on this mailbox or am I stuck with connecting to the server: openssl s_client -starttls imap -connect localhost:143 x login user pass x etc. and muddling through running IMAP commands by hand? If so, what is the IMAP command for unsetting \Noselect? Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: messages in mailbox aren't visible
On 10/12/2010 10:46 AM, Michael D. Sofka wrote: > Is the new server part of a murder cluster? I've had this happen when > transferring accounts between back-end servers in a cluster. The problem > was that while the mailbox was created on the new back-end, not all the > messages transferred. As a result, the mailbox still existed on the old > back-end. > No, it's just a simple one-machine IMAP server. I looked at the documentation for ctl_mboxlist, and it's not clear how this would help, under the circumstances. I'm pretty sure that somehow \Noselect got set on the folder. I don't suppose there's any way to do this with cyradm? I looked through all the cyradm commands in the man page and couldn't find anything. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: messages in mailbox aren't visible
On 10/12/2010 12:02 PM, Wesley Craig wrote: > Does ctl_mboxlist show the mailbox? > Yes, although oddly the sub-folders don't follow immediately in the dump (the folder causing the problem is called "Board"): user.dsmith.AEC.Correspondence MJD.Board0 default dsmith lrswipkxtecd user.dsmith.AEC.Correspondence MJD.Board-Facility Planning 0 default dsmithlrswipkxtecd user.dsmith.AEC.Correspondence MJD.Board-Facility Planning.Block 87 ownership 0 default dsmithlrswipkxtecd user.dsmith.AEC.Correspondence MJD.Board.Chair Correspondence 0 default dsmithlrswipkxtecd user.dsmith.AEC.Correspondence MJD.Board.Courtesy and arrangements 0 default dsmithlrswipkxtecd user.mduffy.AEC.Correspondence MJD.Board.Exec Committee 0 default dsmith lrswipkxtecd The messages in the subfolders of Board display without any problems. >> I'm pretty sure that somehow \Noselect got set on the folder. > > What makes you think so? > http://kb.mozillazine.org/Grey_italic_folders This article was written for Thunderbird but also applies to Mozilla Suite / SeaMonkey (though some menu sequences may differ). A IMAP folder will be displayed in grey italics if the folder has a \Noselect flag. Normally this means the folder can contain child folders, but not messages. [http://forums.mozillazine.org/viewtopic.php?t=628287] This is a IMAP protocol flag, not one of the folder flags that can be set using the Folder Flag extension. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: messages in mailbox aren't visible
On 10/12/2010 02:25 PM, Bron Gondwana wrote: > > Ahh... what does your improved_mboxlist_sort imapd.conf variable > say? > Nada -- I don't have this variable set in imapd.conf. However, when I do set improved_mboxlist_sort: 1 in /etc/imapd.conf I get the following error when trying to run ctl_mboxlist: r...@www:~# ctl_mboxlist -d > foo2.txt fatal error: can't read mailboxes file remove the improved_mboxlist_sort entry, restart cyrus and ctl_mboxlist works again: r...@www:~# vi /etc/imapd.conf r...@www:~# /etc/init.d/cyrus2.3 restart Stopping Cyrus IMAPd: cyrmaster. Waiting for complete shutdown... Starting Cyrus IMAPd: cyrmaster. r...@www:~# ctl_mboxlist -d > foo2.txt r...@www:~# Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: messages in mailbox aren't visible
On 10/12/2010 03:15 PM, Bron Gondwana wrote: > > RTFM says: "dump the mailbox, change the setting, undump the mailbox, restart" > Is there some place (e.g. an "M") where this process is documented in such a fashion that I can just cut & paste commands, or is this another thing I'll have to muddle through using trial and error and then document myself on the wiki? <:) In particular, though, if the \Noselect IMAP flag somehow got set on this mailbox, does this actually show up in the settings in such a way that I can change it? Is there anything else it could possibly be? Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: messages in mailbox aren't visible
On 10/12/2010 03:37 PM, Bron Gondwana wrote: > > The mailboxes database should be dumped before the option is changed, > removed, and then undumped after changing the option. > > Which kinda sucks really. But the M I'm pasting from there is the > imapd.conf docs. > Where be these elusive imapd.conf docs? I just read through the imapd.conf man page and couldn't find anything about this. I have: pgo...@www:~$ ls /usr/sbin/ctl* /usr/sbin/ctl_cyrusdb /usr/sbin/ctl_deliver /usr/sbin/ctl_mboxlist It doesn't look like any of these dump a database except perhaps ctl_cyrusdb -c And it's not at all clear what settings would be changed if the database is dumped ... to a plain text file? CSV? No mention of this on the ctl_cyrsudb man page (or where the database is archived, for that matter). Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: messages in mailbox aren't visible
On 10/12/2010 8:49 PM, Wesley Craig wrote: > > \Noselect is the result of LIST et al not finding the mailbox in question. > It's not "set" per se, but returned descriptively. Given the odd sort order > from ctl_mboxlist -d, incompatible sort order is why LIST can't see it. > Wes, Bron, thanks for the tremendous help/clarification with this -- this sounds like it could be my problem. Just one more question, because the documentation is a bit unclear. I think what I need to do is: -- stop cyrus add "improved_mboxlist_sort: 1" to /etc/imapd.conf ctl_mboxlist -d -x > mailbox_list.txt ctl_mboxlist -u < mailbox_list.txt start cyrus -- There is, however a comment on the man page which is confusing: -x When performing a dump, remove the mailboxes dumped from the mailbox list (mostly useful when specified with -p) Why is this flag mostly useful when specified with -p? Don't I need to remove the contents of the old mboxlist under any circumstances if I plan to reload on the same machine, or will ctl_mboxlist dump the contents automatically as soon as I execute a -u load? Finally, assuming this works and based on my experience, it seems that the improved sorting system should just become the default in cyrus 2.4.x, with the improved_mboxlist_sort deprecated and perhaps even disabled. Not being able to sort with "non-ascii" characters like -_ is going to be counterintuitive to most people. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: messages in mailbox aren't visible
On 10/12/2010 5:48 PM, Bron Gondwana wrote: > > man imapd.conf on my machine gets: > > improved_mboxlist_sort: 0 > If enabled, a special comparator will be used which will correctly > sort mailbox names that contain characters such as ' ' and '-'. > > Note that this option SHOULD NOT be changed on a live system. The > mailboxes database should be dumped before the option is changed, > removed, and then undumped after changing the option. > Thanks for the clarification. I was having trouble wrapping my brain around the idea that "mailbox dump" does not meant dumping the messages, too. Arggh. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Reconstruct mailboxes ................
On 10/13/2010 4:58 PM, Oscar Mauricio Cruz Lazo wrote: > Hi all > > I just backed up my mails of /var/spool/imap/user/ from one box to > another cause im migrating the mail server, both server running suse > 10.3, postfix, everything is great so far, except mails on the new > mailbox. the issue here i not able to see each mails in theirs mailbox > when i check via horde webmail. > > I've tried to reconstruct each mailbox using reconstruct tool, switching > to cyrus user, but i dont get neither a warning or an error .. > > First, are you sure that you're subscribed to the mail folders? Generally you also need to copy or reconstruct the databases in /var/lib/cyrus, too, to successfully transfer mail from one server to another. -- Patrick Goetz Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Moving data from Cyrus 2.3.7 (RHEL) to 2.3.16 (Invoca)
On 10/14/2010 09:36 AM, Simpson, John R wrote: > We have been running Cyrus 2.3.7, as packaged by Red Hat > (cyrus-imapd-2.3.7-2.el5) for some time, and we're upgrading to 2.3.16 > (cyrus-imapd-2.3.16-8, thanks Simon) to support replication. Speaking of replication, is there any documentation at all on how to set this up and what it does? What about for creating a murder server pool? -- Patrick Goetz Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: messages in mailbox aren't\H\H\H visible
On 10/13/2010 08:43 AM, Bron Gondwana wrote:
>
> Or you could do:
>
> stop cyrus
> ctl_mboxlist -d> mailbox_list.txt
> mv $confdir/mailboxes.db $confdir/mailboxes.db.unsorted
> add "improved_mboxlist_sort: 1" to /etc/imapd.conf
> ctl_mboxlist -u< mailbox_list.txt
> start cyrus
>
Thanks! This worked perfectly, and the messages (in mailboxes for which
they were inexplicably hidden) are now visible. It's still unclear how
the out-of-order sorting in mailboxes.db would trigger this.
This brings back the issue of a safe, canonical procedure for moving a
(single server) cyrus mail system to a new server. Since particularly
new users frequently have problems with this (including me, when I first
started using cyrus).
I'm thinking something like this. Suppose there were a command, say
called ctl_cyrusdb2, which offered the same features as ctl_mboxlist,
but could be used on any cyrus db file, e.g.
ctl_cyrusdb2 -d cyrus_db
dumps the cyrus_db database.. (The following also assumes ssh
authorized_keys have been set.)
On the old_cyrus_server:
---
stop cyrus
for i in `cat /var/lib/cyrus/cyrus_db_list`
do
ctl_cyrusdb2 -d $i | ssh new_server "cd /var/lib/cyrus &&
ctl_cyrusdb2 -u -"
done
(cd /var/spool/cyrus; tar cf - .) | ssh new_server "cd
/var/spool/cyrus && tar xpf - "
---
start cyrus on new_server and you're done -- a total of 4
command-line commands (viewing the for as a single command).
There are a few problems with this in addition to the absence of a
ctl_cyrusdb2, namely it's still unclear what cyrus db files are created
and why. On my system, I have:
annotations.db deliver.db mailboxes.db tls_sessions.db
but also have
db:
__db.001 __db.002 __db.003 __db.004 __db.005 __db.006
log.01 skipstamp
and
user/[a-z]/{user_name.seen, user_name.sub}
Are the contents of db important for migration? And why isn't the stuff
in /var/lib/cyrus/user stored in the appropriate location in
/var/spool/cyrus? From the file names, this seems like important
metadata that users would want to see preserved. I suppose all this
could be handled with no extra knowledge on the admin user's part by
populating the /var/lib/cyrus/cyrus_db_list file only with the database
names necessary for successful replication of metadata.
Finally, I see many instances of the following error message in
/var/log/syslog:
Oct 14 16:33:01 www cyrus/imap[32001]: IOERROR: opening
/var/lib/cyrus/user_deny.db: No such file or directory
Apparently
touch /var/lib/cyrus/user_deny.db
is not a solution, either:
http://www.mail-archive.com/info-cyrus@lists.andrew.cmu.edu/msg39304.html
2 questions about this:
1.
I have rsyslog configured to log all mail stuff to /var/log/mail.*; e.g.
*.=info;*.=notice;*.=warn;\
auth,authpriv.none;\
cron,daemon.none;\
mail.none,news.none -/var/log/messages
So why is anything from cyrus being written to syslog at all? This
message should be going to /var/log/mail.err, as far as I can tell. Is
this a compile-time error?
2.
Under any circumstance, shouldn't this error message be written to the
log files only when cyrus is started?
--
Patrick Goetz
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
cyrus db files
Hi -
No one ever responded to this. If I can find out what db files in
/var/lib/cyrus are necessary for a successful transfer of metadata to to
a new server, I'll write up a wiki entry for this procedure.
Original Message
Subject: Re: messages in mailbox aren't\H\H\H visible
Date: Thu, 14 Oct 2010 16:46:42 -0500
From: Patrick Goetz
To: info-cyrus@lists.andrew.cmu.edu
This brings back the issue of a safe, canonical procedure for moving a
(single server) cyrus mail system to a new server. Since particularly
new users frequently have problems with this (including me, when I first
started using cyrus).
I'm thinking something like this. Suppose there were a command, say
called ctl_cyrusdb2, which offered the same features as ctl_mboxlist,
but could be used on any cyrus db file, e.g.
ctl_cyrusdb2 -d cyrus_db
dumps the cyrus_db database.. (The following also assumes ssh
authorized_keys have been set.)
On the old_cyrus_server:
---
stop cyrus
for i in `cat /var/lib/cyrus/cyrus_db_list`
do
ctl_cyrusdb2 -d $i | ssh new_server "cd /var/lib/cyrus &&
ctl_cyrusdb2 -u -"
done
(cd /var/spool/cyrus; tar cf - .) | ssh new_server "cd
/var/spool/cyrus && tar xpf - "
---
start cyrus on new_server and you're done -- a total of 4
command-line commands (viewing the for as a single command).
There are a few problems with this in addition to the absence of a
ctl_cyrusdb2, namely it's still unclear what cyrus db files are created
and why. On my system, I have:
annotations.db deliver.db mailboxes.db tls_sessions.db
but also have
db:
__db.001 __db.002 __db.003 __db.004 __db.005 __db.006
log.01 skipstamp
and
user/[a-z]/{user_name.seen, user_name.sub}
Are the contents of db important for migration? And why isn't the stuff
in /var/lib/cyrus/user stored in the appropriate location in
/var/spool/cyrus? From the file names, this seems like important
metadata that users would want to see preserved. I suppose all this
could be handled with no extra knowledge on the admin user's part by
populating the /var/lib/cyrus/cyrus_db_list file only with the database
names necessary for successful replication of metadata.
Finally, I see many instances of the following error message in
/var/log/syslog:
Oct 14 16:33:01 www cyrus/imap[32001]: IOERROR: opening
/var/lib/cyrus/user_deny.db: No such file or directory
Apparently
touch /var/lib/cyrus/user_deny.db
is not a solution, either:
http://www.mail-archive.com/info-cyrus@lists.andrew.cmu.edu/msg39304.html
2 questions about this:
1.
I have rsyslog configured to log all mail stuff to /var/log/mail.*; e.g.
*.=info;*.=notice;*.=warn;\
auth,authpriv.none;\
cron,daemon.none;\
mail.none,news.none -/var/log/messages
So why is anything from cyrus being written to syslog at all? This
message should be going to /var/log/mail.err, as far as I can tell. Is
this a compile-time error?
2.
Under any circumstance, shouldn't this error message be written to the
log files only when cyrus is started?
--
Patrick Goetz
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Cyrus Add-ons
On 10/16/2010 2:49 PM, Henrique de Moraes Holschuh wrote: > I can't help you with mercurial, but google should find good > tutorials as well. Mercurial is almost as nice as git, only a bit > slower but with better MS Windows support. > The mercurial website has plenty of documentation: http://mercurial.selenic.com/learn/ I use hg (mercurial) and really like it. I think in comparison with git, git is a lot more complicated/flexible, which isn't necessarily a good thing if the simpler tool does everything you need. -- Patrick Goetz Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
cyrdump
Is there a flag for cyrdump (or a corresponding cyrload) that allows you to reload mailboxes? The man page on cyrdump on my system is rather sparse: CYRDUMP(8) NAME cyrdump - dump mailboxes to stdout SYNOPSIS cyrdump [-C ] [-v] [mboxpattern ...] DESCRIPTION A tool for dumping IMAP mailboxes on a server. -C Specify an alternate configuration file ( is used by default) -v Increase program verbosity. CMU Project Cyrus CYRDUMP(8) -- Patrick Goetz Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: user_deny.db, very high load and Apple-Spotlight
On 10/14/2010 06:30 AM, Marc Patermann wrote: > > I created user_deny.db with touch to make the one error message go away. > Now I have lots of "fetching ..." messages in the log (2.3.16). > > Is there anything to do about this? > I think the suggested solution is don't use bdb for the /var/lib/cyrus databases? The default in 2.4.x is skiplists. I know this has been mentioned or alluded to several times, but I'm still a bit unclear on how to convert an existing set of cyrus bdb databases to skiplists on a production system. -- Patrick Goetz Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: user_deny.db, very high load and Apple-Spotlight
Correction: I think you have to compile cyrus with no bdb support for the user-deny.db error message to go away: configure --without-bdb On 10/19/2010 01:20 PM, Patrick Goetz wrote: > On 10/14/2010 06:30 AM, Marc Patermann wrote: >> >> I created user_deny.db with touch to make the one error message go away. >> Now I have lots of "fetching ..." messages in the log (2.3.16). >> >> Is there anything to do about this? >> > > I think the suggested solution is don't use bdb for the /var/lib/cyrus > databases? The default in 2.4.x is skiplists. > -- Patrick Goetz Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Replication and backups
Hi - I'm grappling with the issue of how to either do backups or take snapshots of a live cyrus system so that all the metadata is properly saved; meaning that the indexes and db files match exactly the messages in ~/cyrus/mail so that the backup or snapshot can be copied to a new system and brought up cleanly when cyrus is started. I recall someone on this list mentioning that they use LVM snapshots for this purpose, but I did a little research on this, and it appears that file system performance degrades dramatically when LVM snapshots are used. What I'm thinking about using instead is replication with DRBD to another server, turning off the replication periodically, making a backup of the replicated filesystem, and then turning replication back on. Even here, though, it seems like it would be possible turn off the replication after a new message has been stored but before either the indexes or the .db files are updated. Is there any way to get around this or has the application been coded to be "transaction safe"? This is one advantage of maildir format: the metadata is just built right into the message filename, so the only thing that can get lost or corrupted is the indexes, which can just be rebuilt. Of course there's a sizable performance penalty that comes with this... Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Replication and backups
On further thought, it seems like this would be a solution: -- -- | Server 1 | ---DRBD--> | Server 2 | -- -- Step 1: Stop cyrus on Server 1. Step 2: Turn off replication on Server 2. Step 3: Restart cyrus on Server 1. Step 4: Back up filesystem on Server 2. Step 5. Turn replication back on on Server 2. Cyrus would only have to be off for a few seconds on Server 1, and resynchronizing after the connection has been terminated for a couple of hours shouldn't be a problem, either. -- Patrick Goetz Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Replication and backups
On 02/03/2011 12:56 PM, Wesley Craig wrote: > I wonder, tho, why use DRBD rather than cyrus replication. > Perhaps because I don't know anything about cyrus replication? <:) RTFM the cyrus wiki? -- Patrick Goetz Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Protecting message files acess even from root
Yes, this is the answer. If messages need to protected from everyone, including root, then they should be PGP encrypted at the source; with MUA client-side decryption. On 01/31/2014 10:37 AM, Mark Blackman wrote: > > On 31 Jan 2014, at 16:10, Fabio S. Schmidt wrote: > >> Hello! >> Considering that Cyrus stores messages in files, does anyone have any >> experience on the protection of access to these files, even for the root >> user? >> >> I researched about SELINUX and found no conclusive documentation. >> > > http://en.wikipedia.org/wiki/Public-key_cryptography > > - Mark > > > 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: Best distro for Exim/Cyrus
On 2/10/2014 4:13 PM, Paul O'Rorke wrote: > still trying to find a definitive resource to use to get this mail > server up and running. Does anyone know of a good howto for setting up > Debian/Exim/Cyrus? I think this is the combination I want to move from > the Centos/Exim/Dovecote box I inherited but I must confess to really > struggling here. > I started out with Exim/Cyrus and ended up going with Postfix/Cyrus because of the extensive Postfix documentation available. I similarly spent way too much time looking for relevant howtos and documentation, which seems to be either out of date or non-existent. Is everyone just using gmail these days? That would be a blow to Internet freedom. The Cyrus documentation is particularly weak. Cyrus could be the dominant imap platform if it came with some excellent documentation. Ubuntu has a Postfix/dovecot metapackage that works pretty well. I toyed with the idea of doing something similar for Postfix/Cyrus, but am now in the process of switching all my desktops/servers from Ubuntu to Arch, so this wouldn't necessarily apply for Debian users anymore anyway. 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: Ubuntu 13.10 | Cyrus 2.4 IMAPd | Specs Folders
On 2/22/2014 4:05 AM, Andrey ‪ wrote: > As I see, I need to build it by myself (I am not good in such things) and it > supports only: > "This rpm builds on RedHat 9, Fedora Core 1 ... 6, RHEL/CentOS 3 ... 6 for > at least i386 and x86_64 archs" > No debian support... :( > You might try using alien for this: https://packages.debian.org/sid/alien 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: backup rsync
There's something to be worried about with using lvm snapshots. My understanding is that this can dramatically slow down your system. I'm too busy right now to pull up a reference, but google is your friend. On 08/29/2014 09:27 AM, Marcus Schopen wrote: > Hi, > > I'm planing to use lvm snaps and rsync for a daily disaster recovery > backup on my master cyrus (2.4.12 Ubuntu 12.04 LTS): > > ctl_cyrusdb -c > ctl_mboxlist -d > mailboxes.db.dump > stop cyrus > lvm snaps > start cyrus > rsync /var/lib/cyrus/ and /var/spool/cyrus to backup host > remove snaps > > Is there something to be aware with rsync especially > with /var/spool/cyrus directories? > > Beside that the master is in master-slave replication too. In a case of > disaster recovery - if you don't want to make the slave to the master - > would it work out to rsync /var/lib/cyrus/ and /var/spool/cyrus from the > slave to the master or is that not a good idea? > > Ciao > Marcus > > > > 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: backup rsync
On 8/30/2014 10:10 AM, Simon Matter wrote: > > I suggest -aH to preserve single instance storage in the backup. > Does cyrus use a lot of hard links? I use rsync a lot to create snapshot backups, and use hard links across snapshots to preserve space; however, for a single instance backup and unless the filesystem includes hard links (not normal), then the -H won't do much for you. Of course one should always use -a. The biggest concern I have about backing up mail spools is keeping the index and message stores in sync while the backup is taking place. A long time ago someone suggested using cyrdump, but when I looked into this, I couldn't find any documentation whatsoever. Is cyrdump a real thing, or did I imagine all this? 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: backup rsync
Thanks for that explanation! I don't have time to read every email that comes to the cyrus list, and missed that one. One point of clarification: On 8/30/2014 2:49 PM, Nic Bernstein wrote: > ctl_cyrusdb -c > ctl_mboxlist -d > mailboxes.db.dump > stop cyrus > lvm snaps > start cyrus > rsync/var/lib/cyrus/ and /var/spool/cyrus to backup host > remove snaps > Wouldn't you want to stop cyrus *before* running ctl_mboxlist -d > mailboxes.db.dump ? Also, are these ctl_* commands documented anywhere? Thanks! 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: backup rsync
On 09/06/2014 06:52 AM, Egoitz Aurrekoetxea wrote: > We are using Cyrus replication for some years now. It’s just fine. You > can play too with > expunge_delayed for avoid removing mail immediately. > Hi - Do you mind explaining this in more detail? Thanks. 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: List currently logged on users
Question: what's wrong with
ps auxw | grep imap
Doesn't this provide an accurate representation of who's logged in?
On 09/12/2014 10:02 AM, Michel Blanc wrote:
> On 12/09/2014 16:04, Michael Neumann wrote:
>> Hello,
>>
>> i am looking for a command that outputs the currently logged on users of
>> cyrus imapd, is there something available?
>>
>> Best regards
>>
>
> Hello,
>
> I use the following handy one liner :
>
>
> lsof -p `pidof imapd|tr ' ' ','` | \
> grep '/var/lib/cyrus/user/.*\.seen$' | \
> awk '{ print $9 }' | sort | uniq | \
> cut -f7 -d'/' | cut -f1 -d'.'
>
> with cyrus 2.2 under ubuntu server, YMMV !
>
> Cheers,
>
> M
>
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: List currently logged on users
My bad -- thanks for the correction. I run cyrus and dovecot systems, and inadvertently checked this on a dovecost-based system before posting. On 09/12/2014 10:30 AM, Michel Blanc wrote: > On 12/09/2014 17:20, Patrick Goetz wrote: >> Question: what's wrong with >> >> ps auxw | grep imap >> >> Doesn't this provide an accurate representation of who's logged in? > > Hi Patrick, > > On 2.2 it doesn't include the imap username : > > $ ps auxw | grep imap > cyrus25038 0.0 0.1 96104 4332 Sep09 0:00 imapd -U 30 > cyrus25244 0.0 0.1 96236 4516 Sep09 0:00 imapd -U 30 > cyrus25245 0.0 0.1 96132 4324 Sep09 0:00 imapd -U 30 > cyrus25633 0.0 0.1 96104 4284 Sep09 0:00 imapd -U 30 > cyrus29320 0.0 0.1 96412 4544 Sep11 0:00 imapd -U 30 > cyrus29321 0.0 0.1 96436 4168 Sep11 0:00 imapd -U 30 > ... > > > May be the output is different in other versions ? > > M > 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
Some cyrus-sasl questions
Hi - I've been setting up some new servers and wanted to revisit and optimize my cyrus-sasl configuration. I couldn't find answers to these questions anywhere in the documentation or online, but figured this list would know. Ironically, the postfix documentation for using sasl (http://www.postfix.org/SASL_README.html) appears to be more complete than anything I could find on the cyrus source site. 1. Postfix suggests that I can put the SASL configuration file in /etc/sasl2 instead of /usr/lib/sasl2, but I couldn't find this anywhere in the official cyrus-sasl documentation. User configurable options always need to go in /etc, not /usr/lib, so I just want to confirm that 2.1.26 will look for the configuration file in /etc/sasl2 2. I can't find any hints about what an optimal PAM configuration file is if you only want to authenticate users through PAM with valid accounts. Currently the /etc/pam.d/imap file is basically set up as auth required pam_unix.so account required pam_unix.so (Debian/Ubuntu add other junk via default common authentication groups which must be superfluous). I don't understand why the account management group is needed for imap authentication. Is it just there because there's no documentation on how to do this properly, so people are guessing? 3. Both cyrus and postfix use SASL. In the past, I've run postfix in a chroot jail, so it had it own saslauthd daemon process. Since chroot jails don't add much security, I'm jettisoning that, but presumably cyrus and postfix will happily use the same saslauthd daemon process? Postfix requires a sasl configuration file, but I just noticed that my cyrus 2.3.16 install doesn't seem to have one. Is this compile time default or am I just overlooking where the configuration file? Or does cyrus use the SASL libraries directly, in which case I'm not sure how it knows to use pam. Is there any documentation on this? 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: Locations for folders, etc, for previously-existing users
On 11/20/2014 09:46 AM, Michael Menge wrote:
> If i remember correctly the dovecot data files use the mbox format.
> There are some tools that can upload mails from mbox files to IMPA
> Servers. But i don't know if it is possible to convert all mailbox
> features with them (ACLs, seen status for shared mailboxes).
>
Dovecot by default stores mail in Maildir format, but is compatible with
mbox; i.e. you can have Maildir and /var/spool/mail/{mbox} users.
If your mail is stored with multiple messages per file, then it's mbox;
if it's one message per file, it's Maildir.
I think the least painful way to do this migration is to use imapsync
(http://imapsync.lamiral.info/)
(There might be other versions of imapsync; I haven't used it in a while.)
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
annotation_definitions and other options in imapd.conf
This is from the imapd.conf man page: annotation_definitions: File containing external (third-party) annotation definitions. - Does anyone have any idea what this means or what this is used for? Also, there are any number of options in imapd.conf that don't make any sense to me. For example, auth_mech: - Isn't this handled by SASL? autocreatequota: If nonzero, normal users may create their own IMAP accounts by creating the mailbox INBOX. The user's quota is set to the value if it is positive, otherwise the user has unlimited quota. - How can you create an INBOX if you don't already have an IMAP account? defaultacl: anyone lrs The Access Control List (ACL) placed on a newly-created (non-user) mailbox that does not have a parent mailbox. - That sounds interesting; how does one go about creating a non-user mailbox? implicit_owner_rights: lkxa: The implicit Access Control List (ACL) for the owner of a mailbox. - Why wouldn't the default include t? It seems weird that owners can deleted mailboxes but not messages by default. ldap_* options - Again, I thought all authentication is handled by SASL? In the debian version of /etc/cyrus.con, this comment appears: # this is only necessary if idlemethod is set to "idled" in imapd.conf #idled cmd="idled" - idlemethod is not a listed option in `man imapd.conf` 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: annotation_definitions and other options in imapd.conf
On 12/03/2014 06:53 AM, Adam Tauno Williams wrote: >> auth_mech: >> - Isn't this handled by SASL? > > Partially, yes. Don't forget that identity management is AAA - three > As, not one. Authorization, Authentication, Accounting. > So, for example: Authorization would be cm user.username in cyradm Authentication would be saslauthd -> PAM --> PAM modules Accounting would be setting permissions and quotas sam user.username write sq user.username N I'm still not seeing where auth_mech or ldap options fit into this, although Sven seems to have offered an explanation: there is some undocumented way of bypassing saslauthd. Which, if true, I suggest is a terrible idea and should be stripped out of the code. Allowing for direct PAM authentication might work somehow, assuming there is a way to handle TLS authentication. Authentication architecture needs to be less, not more complicated in general in the unix/linux world. Anyway, thanks Adam and Sven for the replies -- that was extremely helpful. 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
Recommended file locations for linux cyrus servers?
This might seem like a dumb question, but I'm wondering if anyone has some thoughts on recommended file locations for single server systems; in particular, what are the cyrus default folder locations? I've been using cyrus on Ubuntu/debian systems and am now making a switch to Arch. The default debian file locations are: /var/spool/cyrus: mail, news, sieve /var/run/cyrus: sockets /var/lib/cyrus: db files, db, quota, msg, proc (configdirectory=/var/lib/cyrus) /var/log/mail.* log files although there also appears to be an unused /var/lib/cyrus/user folder The problem with putting actual user mail in /var is that this can eventually amount to quite a bit of data. Many modern small server systems are set up with small/fast SSD OS disks and user data (/home) stored on larger traditional disks. (I set up all my servers like this.) Since the OS disk is relatively small, I try to avoid placing growing data stores on it. The simple solution would appear to be to place /var on a separate partition on the larger disks as well, but this has in the past resulted in boot problems because /var doesn't get mounted quickly enough. (And yes, understood this problem has finally been solved by systemd.) So my solution has been to make the defaultpartition = /home/cyrus/mail leaving the debian defaults in place otherwise. The Arch package maintainer has set up everything under /var/imap: [root@ibis imap]# pwd /var/imap [root@ibis imap]# ls db log msg proc quota sieve socket user I can live with this, but it doesn't seem ideal, either. For example, what is the configdirectory, given this directory structure? Hence my question. The Arch philosophy is to stick as closely to upstream as possible, so it would be useful to know what that is. 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: restore from cyrdump
On 12/09/2014 09:03 AM, Willy Offermans wrote: >> Now I want to restore the data of user.$USER on a different server. >> >> How should I proceed? To move a single user to a new server, in the past I've used imapsync to good effect (http://imapsync.lamiral.info/): imapsync --host1 my_old_server --authmech1 LOGIN --user1 pgoetz --password1 x --host2 my_new_server --authmech2 PLAIN --user2 pgg --password2 x In terms of a general backup scheme, since I have no idea how to set up a replication server, I've been toying with using imapsync for general backups to another (otherwise unused) imap server. I think the only way to do this for the entire mail store is to create a cyrus-backup user that has read access to all folders on the primary server and read/write access to the backup mail server. However, I haven't tested this and don't know if this will work properly. Also, as suggested by Marcus Schopen, this is liable to be quite slow, as each user has be to synced individually AFAIK. (I'm pretty sure the last time I used imapsync it was free, but the author appears to now be selling it.) 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: restore from cyrdump
On 12/09/2014 09:36 AM, Bron Gondwana wrote: >> Is there nobody with a good suggestion? > > Not really. Most people seem to be using LVM snapshots. OK, I'll bite. Since a couple of times I've had to restore mail using reconstruct after having lost all the metadata, I'm wondering what the point is of either cyrdump or ctl_mboxlist list if you can't restore the mail spool from their outputs? What does cyrdump do, anyway? I would expect it to also backup all the metadata; else it amounts to tar'ing up ~/cyrus/user. 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
saslauthd question
Surely someone on this list will know the answer to this question. Given sasl_pwcheck_method: saslauthd, with authentication mechanism=pam I'm trying to track down how saslauthd knows that the cyrus PAM service file is called imap; i.e. /etc/pam.d/imap. Is this just built in? I can't find a configuration for it anywhere. 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: saslauthd question
On 12/11/2014 12:45 PM, Andrew Morgan wrote: > I only have PAM files for "imap", "lmtp", and "sieve" > although I have other service names for some of them. > I don't understand why you have PAM files for lmtp and sieve, but most particularly lmtp. lmtpd is just a local daemon that transfers stuff from your smtp server to cyrus. Are you running cyrus and smtpd on different servers? If so, what does the PAM lmtp configuration look like? I don't know anything about sieve, but thought the filters where all internal, too; hence not in need of authentication. 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
idled vs. notifyd ?
In my previous debian-based cyrus install idled was commented out in cyrus.conf, while the notifyd service was set to run. Not knowing any better, I just left it like this. Now that I'm going over the entire configuration in great detail, I find out that idled would be pretty useful thing to have running (since we use mostly the Thunderbird MUA, which supports IDLE), while I'm not even sure what notifyd does. Any clues? 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: idled vs. notifyd ?
On 12/12/2014 04:04 AM, Bron Gondwana wrote: > http://blog.fastmail.com/2014/12/02/dec-3-push-it-real-good/ > From this blog post: "We’ll talk about notifyd first, because it’s the simpler of the two. The two main styles of events it handles are calendar email notifications and Sieve (filter/rule) notifications. Calendar email notifications are what you get when you say, for example, '10 minutes before this event, send me an email'. All the information that is needed to generate an email is placed into the event that comes from Cyrus, including the name of the event, the start and end time, the attendees, location, and so on. notifyd constructs an email and sends it to the recipient. It does database work to look up the recipient’s language settings to try and localise the email it sends. Here we see database and email work, and so it goes on the slow path." What calendar is it that is using notifyd like this? 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: idled vs. notifyd ?
On 12/12/2014 05:00 PM, Robert Norris wrote:
> On Sat, 13 Dec 2014, at 08:37 AM, Patrick Goetz wrote:
>> What calendar is it that is using notifyd like this?
> The notifyd described in that blog post is not the stock Cyrus notifyd,
> but our own custom daemon that speaks the notifyd protocol.
> Cheers,
> Rob N.
>
I recently found a pretty good, albeit very dated book on Cyrus IMAP:
"The Book of IMAP" by Peer Heinlein and Peer Hartleben
It also includes general chapters on the IMAP protocol (useful) and
Courier IMAP (not so useful).
From the description given in this book, it does appear that Cyrus
notifyd has limited utility. Some of the information appears to be out
of date.
According to the book, if notifyd is running, the imapd.conf variables
sievenotifier and mailnotifier determine whether (and what kind of)
notifications you receive.
The imapd.conf man page for my version of Cyrus 2.4.17 does not include
a description of mailnotifier, so presumably this option has been dropped?
As far as I can tell, through sieve you can be notified either via
email, SMS or jabber/XMPP. There is apparently no documentation for how
to send SMS/XMPP messages. Setting the sievenotifier option allows you
to set a :method specification which overrides the default setting for
sieve scripts. They give this example:
require "notify";
if header :contains "from" "b...@example.com" {
notify :method "mailto" :options ["p...@example.com"]
:message "The boss has sent a new email";
}
I hope I got that right. The SMS/XMPP thing could be useful if it were
documented. I'm not sure I'm seeing the utility of the sievenotifier
setting (send an email to let you know an email has been sent?).
I still have no idea how the Fastmail notifyd works or how this is
integrated with calendar functionality.
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
CalDAV?
Speaking of calendars, a while back there was talk of a Cyrus CalDAV module. - Did this ever come to fruition? - Does this mean we can finally integrate calendar funtionality into Cyrus, similar to the feature MS Exchange users have? - If so, how does it work? Is there any documentation? 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: restore from cyrdump
On 12/10/2014 03:47 AM, Willy Offermans wrote:
> I'm not sure what you mean with ``all the metadata'', but there are user
> flags saved into the cyrdump file as well. I never performed the whole
> cycle of dump and restore (probably nobody did so far), so I cannot tell
> you that all metadata is available in the dump file. See my question above!
>
A while back I was working on an email server that (unbeknownst to me)
was connected to a UPS, but with an external disk array that was plugged
in to an outlet on the UPS that was not battery-backed. This site had
frequent power problems, so it turns out that power cycling a disk array
while the server stays up is an awesome way to corrupt your entire file
system.
Since I didn't know what I was doing at the time, I restored
partition-default: /home/cyrus
without also restoring
configdirectory: /var/lib/cyrus
I was consequently confused when no mailboxes showed up, and had to then
learn about and use reconstruct -r on each individual mailbox
(cyrreconstruct on debian/Ubuntu) in order to reconstruct the
/var/lib/cyrus/*.db files.
I think the main database files you need are mailboxes.db and
annotations.db (can someone confirm this?)
This still leaves the question of how best to back up a cyrus mailstore.
Bron mentioned that most people are using LVM snapshots. I don't see
how using btrfs/LVM/ZFS snapshots can save you from a race condition
between when the cyrus user directory is updated and when mailboxes.db
is updated. The only way I would trust this is by doing this:
1. Stop cyrus
2. Snapshot
3. Restart cyrus
cyrdump: near as I can tell the only useful purpose this serves is to
assemble all email messages into a single "mbox" file (can anyone
confirm this)?
ctl_mboxlist: this seems useful for making a human readable copy of the
mailboxes.db file, but I'm not sure how this could be useful for
disaster recovery, given the previously mentioned issue about keeping
the mailboxes.db file synchronized with the contents of the user dir.
So, given a simple mail server (i.e. no murder + replication), and when
using a filesystem (e.g. ext4 or XFS) which doesn't do snapshots, it
would appear that the only safe way to backup up a cyrus mailstore is to
either using something like imapsync, or
1. Stop cyrus
2. tar cvf /some/safe/place/user.tar {default-partion}
3. tar cvf /some/safe/place/cyrusdb.tar {configdirectory}
4. Restart cyrus
The way I've used imapsync in the past required copying mail folders per
authenticated user account; i.e. something like
imapsync --host1 my_host1 --authmech1 LOGIN --user1 my_user1 --password1
x --host2 my_host2 --authmech2 PLAIN --user2 my_user2 --password2 x
which in particular means knowing everyone's passwords. This is
entirely unworkable for larger sites, and I'm not sure if there is a
trick for getting around this.
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: restore from cyrdump
On 12/16/2014 4:11 AM, Michael Menge wrote: > We also don't use snapshots or stop cyrus for backup. > > But as a complete restore of our mail storage with normal backuptools > would take fare too long, we uses cyrus sync for disaster recovery. > For the normal backup we use a combination of delayed expung (14 days) > and normal filesystem backup. In most cases where the mail is still > in the filesystem and can be restored by unexpung, and in the rare > cases where the mail has been expunged i have to run reconstruct anyway. > I haven't used reconstruct in such a long time that I've forgotten what can't be reconstructed from the partition-default user mail files. Quotas are maintained separately. Suppose annotations.db and mailboxes.db are both corrupted or inaccessible. Does this mean the seen status is gone? What else? Also, I was wrong about ctl_mboxlist -u. While this might not be useful for disaster recovery, there is nevertheless at least one use case; e.g. - improved_mboxlist_sort: 0 If enabled, a special comparator will be used which will correctly sort mailbox names that contain characters such as ' ' and '-'. Note that this option SHOULD NOT be changed on a live system. The mailboxes database should be dumped (ctl_mboxlist) before the option is changed, removed, and then undumped after changing the option. When not using flat files for the subscriptions databases the same has to be done (cyr_dbtool) for each subscription database See improved_mboxlist_sort.html. - 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
sasl_mech_list in imapd.conf ?
My old Ubuntu imapd.conf includes this line: sasl_mech_list: PLAIN LOGIN and sasl_mech_list is also mentioned here: https://cyrusimap.org/docs/cyrus-imapd/2.4.6/faq.php However, sasl_mech_list no longer appears as an option in the imapd.conf man page. Has this option been removed, or is this a bug in the man page? Googling for "imapd sasl_mech_list deprecated" didn't turn anything up. 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: CalDAV?
On 12/15/2014 04:24 PM, Nic Bernstein wrote: > Patrick, > You'll find a link to the latest Beta release with CalDav/CardDav > support on the Cyrus IMAP website: > > http://cyrusimap.org/ Thanks for that information. I've had to educate myself on how CalDav works, but this looks fairly promising. How can I find out more about what kinds of calendar functionality is supported (e.g. shared calendars, email-based appointment scheduling, simultaneous access to multiple calendars, etc.)? 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: CalDAV?
On 12/16/2014 11:59 AM, Nic Bernstein wrote: > Um, at the risk of offending; RTFM? > > The doc/install-http.html document, within the distribution, is fairly > complete. Please download the tarball and take a look at that. If > you've still got questions, come back with those. > No offense taken. I love to RTFM; the problem usually is that there's no M; or only M' = 0.5*M - epsilon. Thanks for the heads up! 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: CalDAV?
On 12/16/2014 12:16 PM, Ken Murchison wrote: > Are you talking about public > calendars, sharing a private calendar with a colleague, or both? > Our 2 primary use cases are this: 1. We have lots of people with busy schedules who have their administrative assistant schedule and manage appointments for them. In this case we need to be able to have 2-3 people view/edit the same calendar, which happens to be the primary private calendar for one of these people. 2. There are various groups of users that have to identify compatible meeting times. Usually the way this goes down is that the biggest wig (which also is typically the one with the busiest schedule) has his/her assistant send out 3-5 potential meeting times and then everyone responds with which of those times they can make. This is a bit clunky and laborious, it would be nice if the assistant could just have compatible meeting times identified automatically based on what everyone has on their calendar. The third less common, but still critical shared calendar use is a public or semi-public calendar which shows what times a conference room or piece of expensive lab equipment has been reserved for use. Typically wannabe users then email a particular administrator responsible for keeping this calendar up to date in order to schedule their own meeting or use of the equipment. 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: restore from cyrdump
On 12/16/2014 01:42 PM, Andrew Morgan wrote:
>
> I forgot about one additional thing we do - we dump the mailboxes.db to
> a flat file once an hour via cron. That would allow us to (mostly)
> recover from a corrupted mailboxes.db file. Just like a full restore,
> we would need to run a reconstruct on every mailbox, I think.
>
I thought the whole point of reconstruct was to rebuild mailboxes.db,
but then I took another look at the reconstruct man page and noticed:
-m NOTE: CURRENTLY UNAVAILABLE
Rebuild the mailboxes file. Use whatever data in the
existing mailboxes file it can scavenge, then scans
all partitions listed in the imapd.conf(5) file for
additional mailboxes.
now it's no longer clear to me what reconstruct does. I guess rebuild
the {configdir}/user///cyrus.* files?
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 Replication (example) [was Re: restore from cyrdump]
Nic, Thanks for that detailed explanation. I still feel myself somewhat stymied by either the documentation (or lack thereof) or perhaps an unfortunate case of being somewhat feeble-minded. Here are some follow up comments/questions: On 12/18/2014 9:59 AM, Nic Bernstein wrote: > I will say that the ability to quiesce the application without halting > it would be most desirable. Most databases have supported this sort of > thing for ages, and it would be great if one could send a signal to > Cyrus to achieve the same result. I wonder what would happen if you just stopped lmtp while making a snapshot? Would postfix choke on this and start kicking messages back to the sender, or would they get queued for later delivery? Alternatively, maybe lmtp could temporarily divert new messages to a dummy spool so that postfix/sendmail wouldn't have to know anything about this. This might be the least painful way to implement quiescence in cyrus. > His initial suggestion -- stop cyrus, snapshot, restart cyrus -- is > reasonable, but we feel that the later suggestion -- stop cyrus, tar > up data, start cyrus -- is not. It takes data offline for too long. > That's why the snapshot capability is necessary in any truly suitable > server. I agree. Here is a substitute proposal (and I'll come back to why I'm pushing this point). Serially 1. rsync user mail files 2. rsync configdirectory db files 3. rsync user mail files again That should get you reasonably close to what you get with snapshots. If you follow the prescribed cyrus directory structure, then this can be simplifed (Arch linux example): 1. rsync -a --delete /var/imap/user [removable disk/other server] 2. rsync -a --delete /var/imap [removable disk/other server] Once you've rsynced the mail files once, rsyncing them again a short time later should be pretty fast. There does need to be a backup solution for people who only have one server, hence can't use replication or imapsync to do backups. > > Lastly, as to the use of imapsync to achieve user, mailbox or server > replication,... > > So your command line is much like Patrick's example, but with '--user1 > --authuser1 --user2 ...' > Of course you must create a proxy user, and Cyrus supports this with the > 'proxyserver' directive in imapd.conf (man imapd.conf for details), > i.e.: 'proxyservers:proxyuser'. > Here is the imapd.conf man page entry for proxyservers: proxyservers: A list of users and groups that are allowed to proxy for other users, separated by spaces. Any user listed in this will be allowed to login for any other user: use with caution. In a standard murder this option should ONLY be set on backends. DO NOT SET on frontends or things won't work properly. That capitalized "DO NOT SET on frontends" would seem to be cause for concern, especially since I don't understand how this works. For people who are 1. imapsync'ing between machines both behind a firewall 2. using saslauthd with pam I thought of this solution: Temporarily block port 143 traffic on the outward facing port of your firewall, and then add the line auth sufficient pam_permit.so to the top of /etc/pam.d/imap files on both the sending and receiving imap servers. This should allow you to imapsync the mail stores for every user without having to provide passwords. Once you're done, simply remove these lines from the PAM configuration files and unblock the port on the firewall. Yes, this will mean that users won't be able to access their mail from outside the firewall while the imapsync is in operation, and this is probably only workable for smaller organizations where people are not concerned about their coworkers temporarily being able to access their mail. There could probably be a desktop policy to handle this as well. However, you are 100% correct that replication would appear to be a far less complex solution. After reading through the available documentation, it wasn't clear to me that it was possible to do replication without setting up a murder, a complexity I was hoping to avoid. So, here's the feeble-mindedness component: I didn't completely follow your explanation for setting up a replication server. It would be awesome to have a howto for doing this -- is anyone aware of anything like this; i.e. howto set up a replication server outside the murder context. > However, I must be honest and point out that if you're going to go to > the trouble of figuring out how to use imapsync (and possibly pay for > it, to boot) you may as well just set up a replica. As I've shown, > above, it's just not that hard. > Imapsync is still useful for migrating individual users from one imap server to another. In my case, I'm migrating from a cyrus 2.3.x server using Berkeley db metadata files to a cyrus 2.4.x server which will be entirely skiplist based. Understood that you can convert db files to skiplists, b
Re: Cyrus Replication (example) [was Re: restore from cyrdump]
Super helpful -- thanks!
I only have one additional question:
On 12/19/2014 09:31 AM, Nic Bernstein wrote:
>> My current plan is to use imapsync for the migration and then
>> replication to another dummy server for backup, assuming I can figure
>> out how to set up replication.
>
> I strongly recommend against this course of action. If you're migrating
> between two boxes, which it sounds like you are, then you're much better
> off rsyncing the spool data between them (once you've halted cyrus) and
> then allowing cyrus to perform the necessary DB updates.
>
It wasn't clear to me why you strongly recommend against this course of
action (other than your recommended course of action is vastly simpler
than messing around with imapsync for multiple users).
Also, for the purposes of clarity and documentation:
The only 2 files I need to run cvt_cyrusdb on are:
- mailboxes.db
- annotations.db
the contents of the {configdirectory}/db are generated dynamically, and
the other db files (e.g. deliver.db and tls_sessions.db) are only
relevant to the cyrus instance on the current machine? (I'm not sure
about deliver.db -- this would seem to need to be converted as well.)
Then one can just copy the contents of
- {configdirectory}/user
- {configdirectory}/quota
- {configdirectory}/sieve
to the new machine. If that works, this is vastly simpler than running
imapsync for each individual user.
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
duplicatesuppression -- why?
I've been wondering about this for a while, given that there is an entire db file devoted to this task, indicating a considerable investment of resources. From the imapd.conf man page: --- duplicatesuppression: 1 If enabled, lmtpd will suppress delivery of a message to a mailbox if a message with the same message-id (or resent-message-id) is recorded as having already been delivered to the mailbox. Records the mailbox and message-id/resent-message-id of all successful deliveries. --- How often does it happen that the same message is being delivered twice? I can't think of a single SMTP scenario where this would be a major concern, but then I'm not an expert. Is this another crazy anachronism (like all the NNTP features) that I should just turn off and forget about once and for all? 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
delayed delete_mode question
I didn't know about the delayed delete_mode option until finally taking the time to comb through the man pages in detail. This seems like a very useful feature, but I'm not sure I understand how it's implemented. Say some user deletes a message or folder. Does s/he have immediate access to the deleted mailboxes hierarchy so that they can restore the deleted message/folder themselves, or does this require administrator intervention? If the former, does the deleted hierarchy show up automatically, or do they have to subscribe to it? 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: duplicatesuppression -- why?
On 1/10/2015 5:51 AM, Robert Norris wrote: > The major problem with it in my experience is that you might actually > prefer the copy of the message that came through the list. For me that's > usually because I wanted DKIM headers or similar. The other problem is it involves adding computational infrastructure to correct minor user-error behaviors, which (as a sometimes educator) I'm opposed to philosophically. The MUA I use (Thunderbird) even includes a "Reply List" button to prevent this. Thanks for that response. It's very clear to me that I *don't* want this feature. FastMail is a completely different use case, but I'm not sure I would turn it on there, either. So, presumably if I use duplicatesuppression: 0 Then the duplicate_db skiplist won't even be created in the first place? 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
statuscache -- why isn't this enabled by default?
Again, reading through the documentation (now supplemented by the *secret* documentation -- thanks, Nic), I noticed: statuscache: 0 Enable/disable the imap status cache. With this description under database-formats: STATUS cache (statuscache.db) This database caches IMAP STATUS information resulting in less I/O when the STATUS information hasn't changed (mailbox and \Seen state unchanged). The database is indexed by mailbox name + userid and each data record contains the database version number, a bitmask of the stored status items, the mtime, inode, and size of the cyrus.index file at the time the record was written, the total number of messages in the mailbox, the number of recent messages, the next UID value, the mailbox UID validity value, the number of unseen messages, and the highest modification sequence in the mailbox. The format of each record is as follows: It's seems like a no-brainer to enable this, particular for sites with a lot of I/O. Why isn't this enabled by default? Are there some drawbacks not revealed in the documentation? 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
LAS shoutout for FastMail
The FastMail guys got a nice shout out on the most current Linux Action Show: https://www.youtube.com/watch?v=TFfvpiUMYsI The FastMail segment starts at around 21:30 into the video. 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
Possible TLS dir option name discrepancy?
The 2.5 documentation here (http://www.cyrusimap.org/~vanmeeuwen/imap/release-notes/2.5.0.html) states that some of the TLS options will change in 2.5, namely tls_client_ca_dir (was: tls_ca_dir) However, there is no tls_ca_dir option given here (https://cyrusimap.org/docs/cyrus-imapd/2.4.17/man/imapd.conf.5.php). I've been using tls_ca_path as per the 2.4.17 man page. Am I missing something, or is this just a typo in the 2.5 documentation? 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.4.17 -- file descriptor limit set to -1?
I'm firing up cyrus 2.4.17 for the first time on a new platform (Arch linux w/ systemd) and noticed the following error message (running journalctl -u cyrus-master): Jan 15 04:08:50 ibis cyrus/master[701]: setrlimit: Unable to set file descriptors limit to -1: Operation not permitted Jan 15 04:08:50 ibis cyrus/master[701]: retrying with 4096 (current max) Apparently the cyrus master process is trying to set the file descriptor limit to -1? Is it even legal to use -1 as infinity in this context? According to the setrlimit man page: The soft limit is the value that the kernel enforces for the corresponding resource. The hard limit acts as a ceiling for the soft limit: an unprivileged process may only set its soft limit to a value in the range from 0 up to the hard limit, and (irreversibly) lower its hard limit. A privileged process (under Linux: one with the CAP_SYS_RESOURCE capability) may make arbitrary changes to either limit value. The value RLIM_INFINITY denotes no limit on a resource (both in the structure returned by getrlimit() and in the structure passed to setrlimit()). BTW, off topic and perhaps feeding some trolls, I'm really liking systemd so far; in part because it's alerting me to minor misconfiguration errors that I've had around for years but wasn't aware of. 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.4.17 TLS woes
So, perhaps unsurprisingly, TLS is giving me problems. I'm trying to enforce allowplaintext: no and am running into some issues with ciphers. I started with this cipher list: tls_cipher_list: TLSv1.2+HIGH:!aNULL:@STRENGTH and got this error: no shared cipher in SSL_accept() -> fail After a little googling I tried: tls_cipher_list: !SSlv2:!SSLv3:!aNULL:@STRENGTH Something like that apparently works for dovecot, but just failed completely: TLS server engine: cannot load cipher list '!SSlv2:!SSLv3:!aNULL:@STRENGTH' Does anyone have a secure, functional cipher list entry they'd like to share? Also, different problem. I noticed this in previous installations of cyrus, but just ignored the error, as everything was working. Every time I run imtest (or when a TLS connection is made) the following error is logged: TLS server engine: No CA file specified. Client side certs may not work I created a self-signed certificate + private key file as per the instructions given in the documentation (more or less), and set tls_cert_file: /etc/cyrus/private/cyrus.pem Thinking the system might also need access to CA certificates for some reason, I then also set a valid CA cert path: tls_ca_path: /etc/ssl/certs All the file permissions are correct, as far as I can tell (i.e. the cert/key file is owned by cyrus with umask 600, in a folder owned by cyrus with umask 700. Any idea why cyrus is giving this error message and how to get rid of it? 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 2.4.17 TLS woes
On 01/15/2015 10:04 AM, Wolfgang Breyha wrote: > Maybe > https://bettercrypto.org/ > is of help. > Thanks for both writing and sharing that document. Unfortunately it only has this to say about cyrus-imap: - Limiting the ciphers provided may force (especially older) clients to connect without encryption at all! Sticking to the defaults is recommended If you still want to force strong encryption use tls_cipher_list: EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+\ aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!\ eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-\ SHA:CAMELLIA128-SHA:AES128-SHA - OK, but then what is the default? The imapd.conf man page only tells us this: tls_cipher_list: DEFAULT I guess my real concern is recent SSL exploits. Maybe if I'm only using STARTTLS this isn't a worry anyway? 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
User mail spool partitioning mystery
I have a couple of existing cyrus 2.3.16 installs with this partitioning configuration in imapd.conf: defaultpartition: default partition-default: /home/cyrus/mail I create users using cyradm: cm user.myuser and the user mail spool folder has this heirarchy: mail | a | user | auser1 | auser2 | auser3 ... b | user | buser1 | buser2 ... c d ... x y z stage. I just assumed that this structure was built in to cyrus; however on my new 2.4.17 install the partition settings in imapd.conf are similar: defaultpartition: default partition-default: /srv/cyrus unixhierarchysep: yes <--- (now using this) however all newly created users (cyradm: cm user/myuser) are dumped into a single folder: cyrus | user | myuser | otheruser | thirduser ... I simply can't find any difference in the configuration files that result in this discrepancy. Was the [a-z] partitioning in the 2.3.16 install baked in to the Debian cyrus package I used, say in cyradm? 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: User mail spool partitioning mystery
That's it! Thanks for the heads up! I assumed that all the spool hash options only applied when you actually have more than one partition, which I don't. Unfortunately this is going to complicate my ability to use the excellent migration plan outlined by Nic Berstein on 2014-12-19. mailboxes.db will know about the spool files in their old, hashed location, which I'd like to get rid of, since all the mail resides on one physical partition anyway, so having it set up this way just adds unnecessary directory structures. I might end up having to use imapsync after all. On 01/16/2015 03:04 PM, Patrick Boutilier wrote: > On 01/16/2015 04:57 PM, Patrick Goetz wrote: >> I have a couple of existing cyrus 2.3.16 installs with this partitioning >> configuration in imapd.conf: >> >> defaultpartition: default >> partition-default: /home/cyrus/mail >> >> I create users using cyradm: cm user.myuser >> >> and the user mail spool folder has this heirarchy: >> >> mail >> | >> a >> | user >> | auser1 >> | auser2 >> | auser3 >>... >> b >> | user >> | buser1 >> | buser2 >>... >> c >> d >>... >> x >> y >> z >> stage. >> >> >> I just assumed that this structure was built in to cyrus; however on my >> new 2.4.17 install the partition settings in imapd.conf are similar: >> >> defaultpartition: default >> partition-default: /srv/cyrus >> unixhierarchysep: yes <--- (now using this) >> >> >> however all newly created users (cyradm: cm user/myuser) are dumped >> into a single folder: >> >> cyrus >> | >> user >> | myuser >> | otheruser >> | thirduser >> ... >> >> >> I simply can't find any difference in the configuration files that >> result in this discrepancy. Was the [a-z] partitioning in the 2.3.16 >> install baked in to the Debian cyrus package I used, say in cyradm? >> > > Sounds like you have hashimapspool enabled in the 2.3.16 installs. > > > > hashimapspool: 0 > If enabled, the partitions will also be hashed, in > addition to the hashing done on configuration directories. This is > recommended if one partition has a very bushy mailbox tree. > > > >> >> 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
Using Roundcube with cyrus?
This is a bit off topic, but is anyone using Roundcube webmail with cyrus? I've lost most of my hair trying to get this to work, and although it is working now, I'm not sure my fix is the correct way to solve the problem. Context: I only allow plain text STARTTLS connections to the imap server: /etc/cyrus/imap.conf: allowplaintext: no (as per the default) sasl_mech_list: PLAIN sasl_pwcheck_method: saslauthd tls_cert_file: /etc/ssl/certs/ssl-cert-cyrus.episcopalarchives.org.pem tls_cipher_list: TLSv1+HIGH:!aNull:@STRENGTH Here is the relevant PHP configuration from Roundcube's config.php.conf: $config['default_host'] = 'tls://mail.episcopalarchives.org'; $config['imap_conn_options'] = array( 'ssl' => array( 'verify_peer' => true, 'allow_self_signed' => true, 'ciphers' => 'TLSv1+HIGH:!aNull:@STRENGTH', 'peer_name' => 'mail.episcopalarchives.org', 'cafile' => '/etc/ssl/certs/ssl-cert-cyrus.episcopalarchives.org.pem', ), ); I tried multiple combinations of PHP connection options as documented on this page: http://php.net/manual/en/context.ssl.php No matter what I changed in the Roundcube PHP configuration, I would alway get this error message in the cyrus error logs: Feb 03 01:06:40 www cyrus/imap[29622]: starttls: TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits new) no authentication Feb 03 01:06:40 www cyrus/imap[29622]: badlogin: www.episcopalarchives.org [216.82.212.230] PLAIN [SASL(-13): authentication failure: cross-realm login pgo...@episcopalarchives.org denied] After a little googling I added this to /etc/cyrus/imapd.conf: defaultdomain: episcopalarchives.org virtdomains: on Now I can authenticate through Roundcube, but this solution seems a little weird to me, since I'm in particular *not* using virtual domains on this server. Question: is it really necessary to turn virtual domains on to get PHP webmail authentication to work, or is there another way to do this? Related question: what are people using for webmail these days? I was shocked to see that php-horde isn't even packaged for Arch linux. 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: Using Roundcube with cyrus?
On 2/3/2015 7:28 AM, Patrick Boutilier wrote: > Are you using pgo...@episcopalarchives.org as the userid or is Roundcube > appending the domain automatically? > Roundcube is appending the domain; I'm logging in with pgoetz. 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: Using Roundcube with cyrus?
On 2/3/2015 7:54 AM, marty wrote: > > Yes - but as my webmail interface is on the same box as the cyrus > server, I've got cyrus to 'listen' on localhost:imap only, and > roundcube connects over the loopback interface to cyrus. > I do have roundcube installed on the same host as cyrus, but the vast majority of connections to the cyrus server are from Thunderbird from hosts that can be located anywhere. This is why I turned unencrypted plain text passwords off. In a previous installation, I was still allowing users to connect with unencrypted passwords, which simplified the Roundcube install considerably. 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: Using Roundcube with cyrus?
On 2/3/2015 9:49 AM, Patrick Boutilier wrote: >> Roundcube is appending the domain; I'm logging in with pgoetz. > > http://trac.roundcube.net/wiki/Howto_Config#IMAPserverconnection > indicates that username_domain may be set. > Argh! That was it. I thought I had removed this, but it must have re-appeared while I was substituting configuration options in and out while trying to get this to work. Thanks so much for your help! 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: change to UNIX hierarchy
I changed to the (new defalt) UNIX hierarchy separator character while upgrading cyrus versions last year and didn't experience any problems. I don't think your authentication scheme is relevant, but as someone else suggested the imap clients might care. In my case, everyone uses Thunderbird, roundcube, or the mail client on their iOS/android device and the switchover was transparent to the users. I'm still have trouble adjusting to creating accounts with cyradm using user/username instead of user.username. Last time I checked this wasn't documented; hope it is now. On 06/30/2015 08:12 PM, Stephen Ingram wrote: > Since we support Kerberos, we use standard usernames on our system > without any domain endings and we also use the Alternate namespace. This > being the case, can we turn on UNIX hierarchy without any changes in the > user's mail client or the filesystem itself? From the documentation, it > looks like the only change would be in the management of the mailboxes > (cyradm) where we would now use a "/" instead of a ".". For instance, > the cyradm command: cm user/john/Sent instead of cm user.john.Sent. Am I > correct or off base here? > > Steve > > > > 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
cyradm: perl: symbol lookup error?
So, I've been happily avoiding upgrading cyrus imap because everything has been working and I'm generally in the "if it ain't broke, don't fix it" category. Cyrus version: 2.4.17 Perl version: 5.22.0 However, this morning I tried to create a new user using cyradm and got a perl error message: pgoetz@www:~$ cyradm --user administrator localhost perl: symbol lookup error: /usr/lib/perl5/site_perl/auto/Cyrus/IMAP/IMAP.so: undefined symbol: Perl_xs_apiversion_bootcheck I'm running Arch linux, which aggressively updates software packages. Apparently some Perl upgrade broke cyradm? 3 questions: 1. Does this mean I need to bite the bullet and upgrade my cyrus installs? 2. Is upgrading to 2.5.6 painless? Should I just wait for 3.0? 3. Is there a workaround for cyradm not working for adding users? I've only ever used cyradm and have no idea how to add users otherwise. 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: cyradm: perl: symbol lookup error?
Thanks. I'm just now getting around to looking at this script. This
creates a mailbox, but don't you also need to set access privileges for
the user associated with this mailbox?
On 09/16/2015 12:00 PM, Patrick Boutilier wrote:
>
> We use this simple perl script to add users. Fill in appropriate
> username and password.
>
>
>
>
>
> #!/usr/bin/perl -w
> #
> use File::Basename;
> use IMAP::Admin;
>
> if ( 0 == scalar( @ARGV ) ) {
>die( "\n Usuage: $0 userid\n");
> }
>
>
> $mailbox = "user.$ARGV[0]";
> $username = "";
> $password = "";
>
> # Set this to the hostname of your IMAP server
> $IMAPSERVER = "localhost";
> #
>
> # Main Code
> #
> # Login to IMAP server
> $imap = IMAP::Admin->new('Server' => $IMAPSERVER,
> 'Login' => $username,
> 'Password' => $password,) || die "no go $! !";
>
> print "Login: " . $imap->error . "\n";
>
> # Add user
> $add = $imap->create("$mailbox");
>
> if ($add != 0) {
> print "Error: " . $imap->error . "\n";
> }
> else {
> print "$ARGV[0] added.\n";
> }
>
>
> # Close connection
> $imap->close;
> exit;
>
>
>
> 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: cyradm: perl: symbol lookup error?
Interesting. When I use cyradm to set up a new account, I always
execute 2 commands:
cyradm --user administrator localhost
localhost> cm user/daffyduck
localhost> sam user/daffyduck daffyduck write
Does this mean that the second command has been superfluous all along
and that these are the permissions that are created by default anyway?
I.e. it would be sufficient to just do this?
localhost> cm user/daffyduck
On 09/17/2015 03:03 PM, Patrick Boutilier wrote:
> On 09/17/2015 04:07 PM, Patrick Goetz wrote:
>> Thanks. I'm just now getting around to looking at this script. This
>> creates a mailbox, but don't you also need to set access privileges for
>> the user associated with this mailbox?
>
> Only if you are going to change the default rights. User will have
> access by default.
>
>
>
>
>
>>
>>
>>
>> On 09/16/2015 12:00 PM, Patrick Boutilier wrote:
>>>
>>> We use this simple perl script to add users. Fill in appropriate
>>> username and password.
>>>
>>>
>>>
>>>
>>>
>>> #!/usr/bin/perl -w
>>> #
>>> use File::Basename;
>>> use IMAP::Admin;
>>>
>>> if ( 0 == scalar( @ARGV ) ) {
>>> die( "\n Usuage: $0 userid\n");
>>> }
>>>
>>>
>>> $mailbox = "user.$ARGV[0]";
>>> $username = "";
>>> $password = "";
>>>
>>> # Set this to the hostname of your IMAP server
>>> $IMAPSERVER = "localhost";
>>> #
>>>
>>> # Main Code
>>> #
>>> # Login to IMAP server
>>> $imap = IMAP::Admin->new('Server' => $IMAPSERVER,
>>>'Login' => $username,
>>>'Password' => $password,) || die "no go $!
>>> !";
>>>
>>> print "Login: " . $imap->error . "\n";
>>>
>>> # Add user
>>> $add = $imap->create("$mailbox");
>>>
>>> if ($add != 0) {
>>> print "Error: " . $imap->error . "\n";
>>> }
>>> else {
>>> print "$ARGV[0] added.\n";
>>> }
>>>
>>>
>>> # Close connection
>>> $imap->close;
>>> exit;
>>>
>>>
>>>
>>> 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
>
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: cyradm: perl: symbol lookup error?
Thanks for this suggestion. I need to tread lightly on a production system, but will bite the bullet and upgrade tp cyrus to 2.5.4 on my test server soon. If this doesn't work, I'll recompile the perl module, as you suggest. On 09/16/2015 04:48 PM, Robert Norris wrote: > On Thu, 17 Sep 2015, at 02:33 AM, Patrick Goetz wrote: >> pgoetz@www:~$ cyradm --user administrator localhost >> perl: symbol lookup error: >> /usr/lib/perl5/site_perl/auto/Cyrus/IMAP/IMAP.so: undefined symbol: >> Perl_xs_apiversion_bootcheck >> I'm running Arch linux, which aggressively updates software packages. >> Apparently some Perl upgrade broke cyradm? > Perl modules aren't binary-compatible across major releases (the second > number, 22 in your case - Perl versioning is a little odd). If you > recompile Cyrus::IMAP against the new Perl it should all just come back > to life. I haven't done that in isolation before but perl/imap/README > looks correct from what I know of Cyrus and Perl. Give it a try. > > Rob 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 > 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
