Moving Cyrus mailing lists to Topicbox
Hi, I'm working with Fastmail to transition the Cyrus mailing lists from lists.andrew.cmu.edu over to cyrus.topicbox.com. Our plan is to transition the active mailing lists as follows: cyrus-annou...@lists.andrew.cmu.edu -> annou...@cyrus.topicbox.com cyrus-de...@lists.andrew.cmu.edu -> de...@cyrus.topicbox.com info-cyrus@lists.andrew.cmu.edu -> i...@cyrus.topicbox.com cyrus-s...@lists.andrew.cmu.edu -> s...@cyrus.topicbox.com We have already copied over subscriber information and list archives to Topicbox for these lists. You should begin using Topicbox immediately. If you have questions about using Topicbox, please see: http://www.topicbox.com/helpspot I will unsubscribe everyone from the lists.andrew.cmu.edu mailing lists later today. I will be deleting the following mailing lists which are no longer in use: cyrus-bugzi...@lists.andrew.cmu.edu cyrus-...@lists.andrew.cmu.edu cyrus-proj...@lists.andrew.cmu.edu Thanks! Dave 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: Request: Please sign this list's messages via DKIM or SPF
On Fri, 2016-04-01 at 15:38 +0200, Binarus via Info-cyrus wrote: > Dear list administrator, > > the messages which are being sent from this mailing list's server don't seem > to be protected by SPF or signed by DKIM. Are there plans to implement at > least one of these in the near future? > We currently have no plans to implement either, but I can put it on our list of things to do. Thanks! Dave 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: IDLE error
On Thu, 2016-01-07 at 13:51 +0200, D CATALIN BADIRCA via Info-cyrus wrote: > Hi, > > I’ve installed a Postfix with Cyrus IMAP and Cyrus SASL. All good, can > send/receive email very fast. > There is one error in the logs that I cannot understand what impact has on > the mail system. I’ve tried searching books,documentations, mail lists, > google and nothing helped me. Maybe some of you gurus will help me understand. > Here is the error I have in the log: > > imaps[9717]: IDLE: error sending message INIT to idled for mailbox user.test: > No such file or directory. Falling back to polling every 60 seconds. > Guessing that the idled notify socket is missing. Do you have idled set up as a service in cyrus.conf? hth, Dave 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: Upgraded cyrus 2.5.6: lmtpd segfaults
On Mon, 2015-11-02 at 19:11 +0100, Stefan G. Weichinger via Info-cyrus wrote: > Am 2015-11-02 um 14:06 schrieb Stefan G. Weichinger via Info-cyrus: > > > > gentoo server here, > > > > yesterday I upgraded cyrus-imapd from 2.4.x to 2.5.6 > > Alongside I reinstalled glibc, cyrus-sasl, postfix ... and corrected all > > the new config options etc in cyrus.conf etc > > > > I now see problems with lmtpd. > > I tried multiple things over the last few hours, even upgraded the > kernel and rebuilt all(?) the relevant packages. > > I still have over 100 emails in the queue which don't get delivered to > cyrus, and I still get the segfaults. > > Could someone pls advise how to proceed and maybe debug this issue? We recently upgraded our MX servers to what will eventually be 3.x and had a series of issues with lmtpproxyd (which is actually a link to lmtpd). I'm not sure how much of the code is common with what's in the 2.5.x releases, but Ken (cc'd on this) managed to track down and fix our sigsegv issues. Ken, do you know if the things you fixed are present in the 2.5.x code as well? 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: Issue with deletions
Apologies for the top-post (and for what is likely an html-formatted message).
Unless you didn't include all of the protocol, the problem is that the client
never sent an EXPUNGE command. It only set the deleted flag on the message, so
the message still exists.
Here's some example protocol showing what I mean with a bunch of stuff snipped
for brevity.
1 SELECT INBOX
* 797 EXISTS
1 OK [READ-WRITE] Completed
2 UID STORE 95578 +FLAGS (\Deleted)
* 784 FETCH (FLAGS (\Deleted NonJunk) UID 95578)
2 OK Completed
3 SELECT INBOX
* OK [CLOSED] Ok
* 797 EXISTS
3 OK [READ-WRITE] Completed
Notice that there are still 797 existing messages. Now if I send an expunge
command:
4 EXPUNGE
* 784 EXPUNGE
4 OK [HIGHESTMODSEQ 104051] Completed
5 SELECT INBOX
* OK [CLOSED] Ok
* 796 EXISTS
5 OK [READ-WRITE] Completed
hth,
Dave
From: info-cyrus-bounces+dave64=andrew.cmu@lists.andrew.cmu.edu
[info-cyrus-bounces+dave64=andrew.cmu@lists.andrew.cmu.edu] on behalf of
Hans-Peter Jansen [h...@urpla.net]
Sent: Tuesday, June 09, 2015 9:55 AM
To: info-cyrus@lists.andrew.cmu.edu
Subject: Issue with deletions
Hi,
I'm innvestigating a pretty nagging issue from kmail, and seek some advice from
an
cyrus imap expert, if this log is consistent.
Env: openSUSE 13.2/x86_64 on server and client, cyrus-imapd 2.4.17, kdepim
4.14.{5,6,8,9}
The failing operation is: moving a mail to trash.
The net effect is, that kmail removes the mail from the list, notices an
inconsisteny,
and refetches all mails from this folder.
C: Client
S: Server
#: Comment above command
# client copies the mail 32602 to the trash folder (german version)
C: A24 UID COPY 32602 "INBOX.M&APw-lleimer"
# server successfully created 9933 in trash
S: A24 OK Completed [ COPYUID 1432637812 32602 9933 ]
# client flags mail as deleted
C: A25 UID STORE 32602 +FLAGS (\Deleted)
# server flagged it as deleted, seen was set before
S: * 13712 FETCH ( FLAGS (\Deleted \Seen) UID 32602 )
S: A25 OK Completed
# client investigates folder settings
C: A26 GETANNOTATION "INBOX" "*" "value.shared"
S: * ANNOTATION INBOX /vendor/cmu/cyrus-imapd/duplicatedeliver ( value.shared
false )
S: * ANNOTATION INBOX /vendor/cmu/cyrus-imapd/sharedseen ( value.shared false )
S: * ANNOTATION INBOX /vendor/cmu/cyrus-imapd/pop3newuidl ( value.shared true )
S: * ANNOTATION INBOX /vendor/cmu/cyrus-imapd/lastpop ( value.shared )
S: * ANNOTATION INBOX /vendor/cmu/cyrus-imapd/lastupdate ( value.shared
9-Jun-2015 14:57:56 +0200 )
S: * ANNOTATION INBOX /vendor/cmu/cyrus-imapd/size ( value.shared 2371801752 )
S: * ANNOTATION INBOX /vendor/cmu/cyrus-imapd/partition ( value.shared default )
S: A26 OK Completed
C: A27 GETACL "INBOX"
S: * ACL INBOX hp lrswipcda cyrus lrswipkxtecda
S: A27 OK Completed
C: A28 MYRIGHTS "INBOX"
S: * MYRIGHTS INBOX lrswipkxtecda
S: A28 OK Completed
C: A29 GETQUOTAROOT "INBOX"
S: * QUOTAROOT INBOX user.hp
S: * QUOTA user.hp ( STORAGE 54982759 1 )
S: A29 OK Completed
# client investigates folder state
C: A30 SELECT "INBOX" (CONDSTORE)
S: * OK Ok [ CLOSED ]
S: * 13724 EXISTS
S: * 0 RECENT
S: * FLAGS ( \Answered \Flagged \Draft \Deleted \Seen $TODO $NOTJUNK $JUNK )
S: * OK Ok [ PERMANENTFLAGS ( \Answered \Flagged \Draft \Deleted \Seen $TODO
$NOTJUNK $JUNK \* ) ]
S: * OK Ok [ UNSEEN 13670 ]
S: * OK Ok [ UIDVALIDITY 1430161627 ]
S: * OK Ok [ UIDNEXT 32615 ]
S: * OK Ok [ HIGHESTMODSEQ 1235 ]
S: * OK Ok [ URLMECH INTERNAL ]
S: A30 OK Completed [ READ-WRITE ]
Server responded with 13724 mails in this folder. This is the problem, since
akonadi expects 13723 mails only:
akonadi_imap_resource_1(25099) RetrieveItemsTask::onFinalSelectDone: Detected
inconsistency in local cache, we're missing some messages. Server: 13724
Local: 13723
Resulting in a full refetch. Although missing in the log, be assured, that
there were
13724 mails in that folder before this operation.
Is that result to be expected? Shouldn't it be 13723 on the server side, too?
Could this be some kind of server side race?
Thanks in advance,
Pete
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: cyrus mailboxes format
On Wed, 2015-03-04 at 13:59 -0200, Andres Tarallo wrote: > Hi > > We're about to migrate a very old installation based on cyrus 2.3.11. The > target system is zimbra collaboration. Many users have years of mail stored > in their maiboxes, we want to migrate those mails to the nuew server. > > I have the idea to do so with the aid of lmtpinject, a tool provided by > zimbra. This tool insert into the mailboxes mails in maildir format. I need > to confirm that cyrus stores mails in that format. Cyrus does not use maildir. Have you considered using imapsync? hth, Dave 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: sieve and global/default scripts
Hi, First, apologies for the top-post. The client I'm responding from doesn't allow me to quote inline because apparently in 2015 we no longer need to do that. But I digress... I think everyone agrees that the state of Cyrus documentation is deplorable, but it's very understandable. The people who contribute the most to the Cyrus project are the people who are writing code. There is nobody dedicated full-time to writing documentation and the result of that is what you've observed: lackluster documentation. Jeroen has put considerable effort into improving that, but it's been mostly a solo effort up to this point. You can see his work at http://cyrusimap.org/~vanmeeuwen/. In the true spirit of open source collaboration, I invite you to contribute to the project by improving the documentation that exists and adding any documentation that is missing. I can create an account for you in the wiki if you're interested. Please let me know. Thanks! Dave From: info-cyrus-bounces+dave64=andrew.cmu@lists.andrew.cmu.edu [info-cyrus-bounces+dave64=andrew.cmu@lists.andrew.cmu.edu] on behalf of Eugene M. Zheganin [eug...@zhegan.in] Sent: Friday, February 06, 2015 6:20 AM To: info-cyrus@lists.andrew.cmu.edu Subject: Re: sieve and global/default scripts Hi. On 06.02.2015 14:46, Niels Dettenbach wrote: > did you still have read the manual?: I really do. The most sad thing - is that I have to read the part that isn't yet written. The thought of the author of this particular article was dwelling for some reason, there's no explanation about how the global script can be enabled by default for all users (without the need of linking them manually): the author first decided to explain different kinds of scripts, then he switched to another topic - shared folders, and then he totally forgot what he was talking about at the start. I'm using cyrus-imapd for like 12 years. I often see complaints that it's documented badly. I often see the responses to such complaints - with appropriate manual quoting. Well, "badly documented" doesn't mean that it's not documented - it means that the documentation is fragmented across a set of man pages, README files, web articles - and they all aren't linked together, and this situation doesn't change. There's no definitive guide on Cyrus (at least I didn't see such one). I assume there can be an article on sieve and about how to enable the global scripts, but I decided it would be more simple to ask here - I assume one of the reasons for having such unorganized documentation set is the need to communicate with users inside this mailing list. I really do need to read the manual - do you by any chance have it by any chance ? Thanks. Eugene. 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: xfer problems between 2.3.15 and 2.4.17
On Thu, 2014-06-05 at 16:15 +0100, gavin.g...@ed.ac.uk wrote: > As you may be aware we are attempting this and have run into various > problems. > > Currently we have a mixed murder of 2.3.15 backends and 2.4.17 backends. > We are now fairly confident that we can xfer accounts succesfully between > these backends. The problems we had appear to have been with a very small > number of accounts on our older backends that had corrupt cyrus.index > files. > > However we are now having trouble configuring frontends that will work > with this mixed murder environment while we xfer our users accross. > > If we use our existing 2.3.15 frontends then users have who have been > migrated lose the ability to see other accounts in the "Other Users" name > space. > > On the other hand if we introduce 2.4.17 frontends then we see strange > behaviour around folder creation. Clients can create the folders but > autosubscription fails with the client being told the new folder doesn't > exist. If one waits a minute or two one can manually subscribe to the > folder. > > So far we have not upgraded the mupdate master. Is this a mistake? > > In terms of the frontend config we have added > > suppress_capabilities: ESEARCH QRESYNC WITHIN XLIST LIST-EXTENDED > > to the 2.4.17 frontends, otherwise the config is identical to our 2.3.15 > frontends. Is there any other config changes we should be aware of? > > any ideas greatly appreciated... What you're doing should work just fine. It's exactly what we did to migrate our murder environment from 2.3.x to 2.4.x. I think I posted to the info-cyrus list about how we upgraded, but maybe I didn't. I got all the 2.4 backend servers built and ready to go, then I upgraded all the frontends to 2.4, then I used XFER to move all the mail from 2.3 to 2.4 servers. I don't recall exactly when I upgraded our mupdate server, but I don't think it matters. I don't believe anything changed in mupdate protocol or in the mailbox.db format between 2.3 and 2.4. Have you tried grabbing telemetry on the 2.4 server when the subscription fails? Is there anything being logged? Thanks! Dave 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: Ban some users from accessing IMAP
Sorry for the top-post... We had exactly this requirement, so Ken added the user_deny database a couple years ago. Coincidentally, it was added in the 2.3.16 release, so you're set there. The good news is that user_deny.db does exactly what you want. It allows you to deny any specific service to a valid user, even if they can successfully authenticate to your Cyrus server. The bad news is that there's no utility that will add things to the user_deny database for you. I wrote a web interface that we use here. You'll need to do something similar. You could probably use cyr_dbtool or write a script to populate user_deny.db. The format of it is described here: http://cyrusimap.org/docs/cyrus-imapd/2.4.17/internal/database-formats.php (we weren't publishing the internal stuff for earlier versions of Cyrus, but the user_deny.db is still the same). Thanks! Dave From: info-cyrus-bounces+dave64=andrew.cmu@lists.andrew.cmu.edu [info-cyrus-bounces+dave64=andrew.cmu@lists.andrew.cmu.edu] on behalf of Jason L Tibbitts III [ti...@math.uh.edu] Sent: Monday, April 28, 2014 12:18 PM To: info-cyrus@lists.andrew.cmu.edu Subject: Ban some users from accessing IMAP I have a pretty simple cyrus setup; I have a long-running 2.3.16 install on RHEL5 (one day I'll update), with authentication handled by cyrus-sasl 2.1.22 and everything authenticating to a kerberos server. What I would like to do is ban some valid users from accessing IMAP. We've had a rash of users falling victim to phishing attacks and would like to simply prevent those users from any remote access. So they need a valid kerberos principal in order to access desktops here, but would lose IMAP access. (Need to ban remote SSH access as well, but that's trivial with DenyGroups). I know this probably isn't strictly a Cyrus IMAPd thing, but I figure some folks must have run into this kind of requirement before. I realize I also need to restrict SMTP logins as well, but that goes through SASL and the Kerberos server as well so if the solution involves either of those then perhaps I get it for free. - J< 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: nntp not working after upgrade
Do you have the "newsgroups" configuration option set in imapd.conf? That didn't exist in 2.2. In 2.4, it should default to serving your entire hierarchy (under your news prefix, since you have that set), but I'm not certain. Take a look at http://cyrusimap.org/docs/cyrus-imapd/2.4.16/man/imapd.conf.5.php for details about the "newsgroups" option and give that a try. I can tell you that we're running nntp here from the caldav-2.4 branch in production and it's working fine. hth, Dave From: info-cyrus-bounces+dave64=andrew.cmu@lists.andrew.cmu.edu [info-cyrus-bounces+dave64=andrew.cmu@lists.andrew.cmu.edu] on behalf of Ulrich Eckhardt [c...@uli-eckhardt.de] Sent: Sunday, January 05, 2014 10:03 AM To: info-cyrus@lists.andrew.cmu.edu Subject: nntp not working after upgrade Hi, I have upgraded my server to from debian 6 (with cyrus 2.2) to debian 7 (with cyrus 2.4.16). After this upgrade it is not possible anymore to feed news into my imap-spool. In the logs i get the following output from fetchnews: Jan 5 12:21:55 h1690828 cyrus/fetchnews[6474]: fetchnews: nntp.aioe.org offered 4; localhost rejected 0, accepted 0, failed 4 The nntpd logs the following: -- 127.0.0.1 Sun Jan 5 13:28:06 2014 >1388924886>200 h1690828.stratoserver.net Cyrus NNTP v2.4.16-Debian-2.4.16-4+deb7u1 server ready, posting allowed <1388924886 >1388924886>335 Send article <13889248861388924886>436 Failed receiving article (Mailbox does not exist) <1388924887 So it seems there is something wrong with my mailboxes. So I have removed the mailboxes for news and recreated them as described in http://cyrusimap.web.cmu.edu/mediawiki/index.php/NNTP According cyradm the mailboxes exist and seems to have the correct permissions: h1690828:/var/lib/cyrus/log/127.0.0.1# cyradm localhost Password: localhost.localdomain> lm INBOX (\HasNoChildren) Trash (\HasNoChildren) news.de.alt.netdigest (\HasNoChildren) news.de.alt.sysadmin.recovery (\HasNoChildren) user.uli (\HasChildren) .. localhost.localdomain> lam news.de.alt.netdigest anyone lrsp localhost.localdomain> lam news.de.alt.sysadmin.recovery anyone lrsp In the imapd.conf file I have the following entries regarding news: # News setup partition-news: /var/spool/cyrus/news allownewnews: 0 newsprefix: news # Alternate namespace # If enabled, activate the alternate namespace as documented in # /usr/share/doc/cyrus-doc-2.4/html/altnamespace.html, where an user's # subfolders are in the same level as the INBOX # See also userprefix and sharedprefix on imapd.conf(5) altnamespace: no # UNIX Hierarchy Convention # Set to yes, and cyrus will accept dots in names, and use the forward # slash "/" to delimit levels of the hierarchy. This is done by unixhierarchysep: no So I have no idea where to search next for this problem. Is there a possibility to log which mailbox the nntpd expects? Best Regards Uli -- Ulrich Eckhardt http://www.uli-eckhardt.de Ein Blitzableiter auf dem Kirchturm ist das denkbar stärkste Misstrauensvotum gegen den lieben Gott. (Karl Krauss) 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: nntp not working after upgrade
We're running nntp from the caldav-2.4 git branch and it works. I recall that we had a few issues, but I'm unaware of Ken fixing anything that wouldn't have been committed back. Sent from my iPhone > On Jan 5, 2014, at 4:04 PM, "Bron Gondwana" wrote: > > I think the problem is that just about nobody is running nntp, so it didn't > get > much testing. I have a rough idea what the bug is likely to be. > > Can you please file this on bugzilla and assign it to me. I'll try to build a > testcase. You might need to build your own Cyrus to get it fixed though :( > > Bron. > >> On Mon, Jan 6, 2014, at 02:03 AM, Ulrich Eckhardt wrote: >> Hi, >> >> I have upgraded my server to from debian 6 (with cyrus 2.2) to debian 7 >> (with cyrus 2.4.16). After this upgrade it is not possible anymore to >> feed news into my imap-spool. >> >> In the logs i get the following output from fetchnews: >> Jan 5 12:21:55 h1690828 cyrus/fetchnews[6474]: fetchnews: nntp.aioe.org >> offered 4; localhost rejected 0, accepted 0, failed 4 >> >> The nntpd logs the following: >> -- 127.0.0.1 Sun Jan 5 13:28:06 2014 >> >>> 1388924886>200 h1690828.stratoserver.net Cyrus NNTP >> v2.4.16-Debian-2.4.16-4+deb7u1 server ready, posting allowed >> <1388924886 >>> 1388924886>335 Send article >> <1388924886> aioe.org!news.mb-net.net!open-news-network.org!.POSTED!not-for-mail >> From: Henning Sponbiel xxx >> Newsgroups: de.alt.netdigest >> Subject: [de.rec.sport.fussball] Re: Es brennt der Baum... >> Followup-To: de.talk.jokes.d >> Date: Mon, 21 Oct 2013 20:48:43 + (UTC) >> Organization: MB-NET.NET for Open-News-Network e.V. >> >>> 1388924886>436 Failed >> receiving article (Mailbox does not exist) >> <1388924887 >> >> >> >> So it seems there is something wrong with my mailboxes. So I have >> removed the mailboxes for news and recreated them as described in >> http://cyrusimap.web.cmu.edu/mediawiki/index.php/NNTP >> >> According cyradm the mailboxes exist and seems to have the correct >> permissions: >> >> h1690828:/var/lib/cyrus/log/127.0.0.1# cyradm localhost >> Password: >> localhost.localdomain> lm >> INBOX (\HasNoChildren) >> Trash (\HasNoChildren) >> news.de.alt.netdigest (\HasNoChildren) >> news.de.alt.sysadmin.recovery (\HasNoChildren) >> user.uli (\HasChildren) >> .. >> localhost.localdomain> lam news.de.alt.netdigest >> anyone lrsp >> localhost.localdomain> lam news.de.alt.sysadmin.recovery >> anyone lrsp >> >> In the imapd.conf file I have the following entries regarding news: >> # News setup >> partition-news: /var/spool/cyrus/news >> allownewnews: 0 >> newsprefix: news >> >> # Alternate namespace >> # If enabled, activate the alternate namespace as documented in >> # /usr/share/doc/cyrus-doc-2.4/html/altnamespace.html, where an user's >> # subfolders are in the same level as the INBOX >> # See also userprefix and sharedprefix on imapd.conf(5) >> altnamespace: no >> >> # UNIX Hierarchy Convention >> # Set to yes, and cyrus will accept dots in names, and use the forward >> # slash "/" to delimit levels of the hierarchy. This is done by >> unixhierarchysep: no >> >> So I have no idea where to search next for this problem. Is there a >> possibility to log which mailbox the nntpd expects? >> >> Best Regards >> Uli >> -- >> Ulrich Eckhardt http://www.uli-eckhardt.de >> >> Ein Blitzableiter auf dem Kirchturm ist das denkbar stärkste >> Misstrauensvotum gegen den lieben Gott. (Karl Krauss) >> >> 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 > > > -- > Bron Gondwana > br...@fastmail.fm > > 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: Code for manipulating all messages matching some criteria?
>From my phone, so excuse my brevity. It might be worth your while to build >cyr_virusscan. It comes with the distribution but doesn't build by default. >It should be able to scan your mail spool and remove viruses (things that >match a virus signature) for you. You could create a signature using ClamAV's >sigtool if necessary. If you are interested, I can try to help or Ken can chime in. Hth, Dave On Oct 22, 2013, at 3:37 PM, "Jason L Tibbitts III" wrote: > Recently our campus was hit with a particularly bad targeted trojan > attach and the IT overlords sent out a demand that we (a small > department with several hundred mailboxes on our own server) go through > all user mailboxes and actually delete the offending messages. At least > using the admin account this is actually kind of reasonable to do. > While I'm sure I could whip something up if I actually had enough free > time, I was wondering if anyone had already been through this kind of > thing and had cobbled together any code to do it. > > I see something called imapfilter which might do the trick, but it seems > to be completely opaque. > > - J< > > 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
cyrusimap.org environment undergoing maintenance tomorrow
Hi, We're doing some hardware maintenance, so the entire cyrusimap.org environment (git, ftp, www, bugzilla, ci) will be unavailable from roughly 2pm to 4pm (EST) tomorrow. Thanks! Dave 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: mailboxes.db discrepancies between mailbox and mupdate servers
On 7/9/13 3:04 PM, "Shawn Winnington-Ball" wrote: >Hi all, > >I'm having an issue with a Cyrus murder wherein the mupdate server >believes that a set of mailboxes are in mid-transfer, when in fact >they don't exist on any of the downstream mailbox servers. Here's >an example of a lone entry gleaned from the output of `ctl_mboxlist >-d' run on the mupdate server: > >user.foo 3 mailbox-03-internal!spool > >If I login to mailbox-03 and use `cyradm' to create the mailbox >directory for user.foo, I get > >createmailbox: unable to reserve mailbox on mupdate server > >It seems that I need to get these sorts of entries removed from the >mupdate server's mailboxes.db file so that I can go about creating >the mailboxes afresh. If you log in to mailbox-03-internal and run: # ctl_mboxlist -d | grep "^user\.foo" is anything returned? For that matter, run this on each of your backend servers and see if it exists anywhere. > >My question is how to do this? Looking through this list's archives, >I see that the cyr_dbtool command can be used to query and manipulate >the mailboxes.db file itself, but someone mentioned that it's best >not to modify the mupdate server's mailboxes.db file directly. In >my case, if I were to try running > >cyr_dbtool /path/to/mailboxes.db skiplist delete 'user.foo' > >on the mupdate server, would I be taking an unnecessary risk? It might be safer to clear the reserved state via mupdate protocol. You can do this manually by using mupdatetest. You can google for the mupdate RFC if you want more details about the protocol, but basically: $ mupdatetest your.mupdate.server.com. 1 ACTIVATE "user.foo" "mailbox-03-internal!spool" "foo" "lrswipcda" > Are >there other means by which to force mailbox-03 to report a complete >and accurate list of its mailboxes to the mupdate server, thereby >overwriting those mailboxes.db entries marked `in-transit' ? You can force a backend to push all of its mailboxes to the mupdate master by running "ctl_mboxlist -m" on the backend. If you're not 100% sure whether you want to push every mailbox before you know what state things are in, you can individually push mailboxes, again using mupdate protocol. Log in to the backend and run $ mupdatetest your.mupdate.server.com. 1 MUPDATEPUSH user.foo I don't think a mupdate push will change the RESERVED state of the mailbox, though. HTH, Dave Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
RE: cyrus-imapd-2.4.17-caldav-beta4 released
Hi Sebastian, The calendar and contact data is stored within a user's normal mailbox heirarchy. imapd from cyrus-imapd-caldav-2.4.17 knows to not return the calendar and contact folders to an IMAP client in LIST output. If you just copy the htttpd binary in place, I think it should work, but your IMAP users will see those folders. At the very least they'll wonder what they are. At the worst, they'll manipulate them with an IMAP client and make them unstable for CalDAV use. If I missed anything, I'm sure Ken can chime in. HTH, Dave From: info-cyrus-bounces+dave64=andrew.cmu@lists.andrew.cmu.edu [info-cyrus-bounces+dave64=andrew.cmu@lists.andrew.cmu.edu] on behalf of Sebastian Hagedorn [haged...@uni-koeln.de] Sent: Tuesday, May 21, 2013 4:49 AM To: Ken Murchison Cc: info-cy...@andrew.cmu.edu Subject: Re: cyrus-imapd-2.4.17-caldav-beta4 released Hi Ken, --On 17. Mai 2013 09:08:56 -0400 Ken Murchison wrote: > We are pleased to announce the fourth beta release of Cyrus IMAP with > integrated calendaring and contacts (beta3 was an internal release only). > This is a security and bug fix release, with only one new feature added. > Sites that are using or testing any of the HTTP-based services are urged > to upgrade to this release. > > This code is based on the stable Cyrus 2.4.17 release with support for > CalDAV, CardDAV and RSS added. All of the standard Cyrus IMAP daemons > and utilities should be considered production quality in this release, > but the HTTP support (CalDAV, CardDAV and RSS) is in beta status. > > You can download via HTTP or FTP: > > http://cyrusimap.org/releases/cyrus-imapd-2.4.17-caldav-beta4.tar.gz > ftp://ftp.cyrusimap.org/cyrus-imapd/cyrus-imapd-2.4.17-caldav-beta4.tar.gz > > Installation documentation will be found in doc/install-http.html in the > distribution. > > Thanks for your continued support, and we look forward to any and all > feedback. I have successfully installed and tested this version on a test VM. I'm considering a limited test on our production server. There we run 2.4.17 built using Simon Matter's RPM. I wasn't able to adapt the SPEC file to use the caldav-beta tgz, so I compiled manually using the same configure parameters that Simon uses. Now I wonder if it would be considered safe to manually install just the httpd binary and to use it alongside the ones provided by the RPM? Cheers, Sebastian -- .:.Sebastian Hagedorn - Weyertal 121 (Gebäude 133), Zimmer 2.02.:. .:.Regionales Rechenzentrum (RRZK).:. .:.Universität zu Köln / Cologne University - ✆ +49-221-470-89578.:. 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: successful create but unsuccessful subscribe
On Dec 14, 2012, at 10:07 AM, Kerstin Espey wrote: > On 13.12.2012 18:28, Dave McMurtrie wrote: > >> In our case, the mupdate process on one of our frontends was not >> receiving updates from the mupdate master. If a webmail user created >> a new folder and then immediately reconnected to that frontend, the >> folder wouldn't exist. If they connected to a different frontend, it >> would work fine. >> > In our case, the session is hold open between create and subscription of > the mailbox. It wouldn't matter. The create and mupdate push both happen on the backend. The frontend just proxies the traffic. If the mupdate process on your frontend isn't getting updates from the mupdate server, it won't know that the new mailbox has been created. > After logout and login again (to the same frontend), everythings works fine. > I don't know why this would happen. >> To see if this is your problem, you need to determine if mailboxes.db >> is the same across all of your frontends. The easiest thing is to >> compare the datestamp on the file. You may need to ctl_mboxlist -d >> each of them and compare. If you find that one of the mailboxes.db >> files on a frontend is considerably older than the rest, kill mupdate >> on that frontend and let master re-spawn it. It will reconnect to >> the mupdate master and scarf a fresh database. > > Half an hour after deletion of a folder, three of our four frontends are > still behind the fourth frontend, which is the one we use with our clients. > Killing the mupdate does work - the mailbox.db is now up2date again. This is not normal. You need to determine why your frontends are not updating. >> >> In our case, the problem was that the mupdate process on the frontend >> makes one connection to the mupdate master and then remains >> connected. Unfortunately, it does not use tcp keepalives so if >> there's an issue at the network layer where that connection goes away >> without actually being closed (meaning, the cyrus frontend never >> receives a tcp reset), the mupdate process will sit in a blocking >> read() on the mupdate socket forever without ever getting any >> updates. You can use lsof and/or netstat to see if this is the case, >> should you discover that you have a stale mailboxes.db on one of your >> frontends. netstat shows you the source and destination port. If >> that port isn't open on your mupdate server, and mupdate on your >> frontend is stuck in a blocking read(), you'll know that's the >> issue. >> > > ngrep shows activity on every frontend port 3905. Nevertheless the > mailbox.db differs: Yes, as I mentioned, the mupdate process on our broken frontend was running and still held an open socket descriptor to our mupdate server. The problem was that the mupdate server did not still have that connection open, so the client mupdate process was stuck in a blocking read() indefinitely, but was not getting any updates. > > amanda/janis: > ~# ctl_mboxlist -d | grep Kerstin > user.mailteam.Kerstin 1 regina!default mailteam lrswipkxtecda > user.mailteam.Kerstin.info 1 regina!default mailteam > lrswipkxtecda > user.mailteam.Kerstin.kernel1 regina!default mailteam > lrswipkxtecda > user.mailteam.Kerstin.newlog1 regina!default mailteam > lrswipkxtecda > > tegan: > # ctl_mboxlist -d | grep Kerstin > user.mailteam.Kerstin 1 regina!default mailteam lrswipkxtecda > user.mailteam.Kerstin.info 1 regina!default mailteam > lrswipkxtecda > > sara: > # ctl_mboxlist -d | grep Kerstin > user.mailteam.Kerstin 1 regina!default mailteam lrswipkxtecda > user.mailteam.Kerstin.kernel2 1 regina!default mailteam > lrswipkxtecda > user.mailteam.Kerstin.newlog1 regina!default mailteam > lrswipkxtecda > > The mailbox.db file has nearly the same timestamp on all frontends. > Existing mailboxes under user.mailteam.Kerstin are kernel and kernel2, > all others are deleted. This is broken. You need to determine why your frontends aren't all in sync. Crank the logs up to debug level (local6) on your mupdate master and the frontends. If you don't find anything in the logs, confirm that you actually see an open socket (using netstat) on both sides (frontend and mupdate). Also, I didn't look at your configs, but make sure you don't have proxyservers set on your frontends like Bron mentioned. 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: successful create but unsuccessful subscribe
I tried to respond to the list before but the list server told me to get bent. Here's a cut-n-paste of my previous reply: Hi, I have seen this problem before. If you only have a single frontend in your dev environment, it's likely a different problem than what I found. In our case, the mupdate process on one of our frontends was not receiving updates from the mupdate master. If a webmail user created a new folder and then immediately reconnected to that frontend, the folder wouldn't exist. If they connected to a different frontend, it would work fine. To see if this is your problem, you need to determine if mailboxes.db is the same across all of your frontends. The easiest thing is to compare the datestamp on the file. You may need to ctl_mboxlist -d each of them and compare. If you find that one of the mailboxes.db files on a frontend is considerably older than the rest, kill mupdate on that frontend and let master re-spawn it. It will reconnect to the mupdate master and scarf a fresh database. In our case, the problem was that the mupdate process on the frontend makes one connection to the mupdate master and then remains connected. Unfortunately, it does not use tcp keepalives so if there's an issue at the network layer where that connection goes away without actually being closed (meaning, the cyrus frontend never receives a tcp reset), the mupdate process will sit in a blocking read() on the mupdate socket forever without ever getting any updates. You can use lsof and/or netstat to see if this is the case, should you discover that you have a stale mailboxes.db on one of your frontends. netstat shows you the source and destination port. If that port isn't open on your mupdate server, and mupdate on your frontend is stuck in a blocking read(), you'll know that's the issue. HTH, Dave From: info-cyrus-bounces+dave64=andrew.cmu@lists.andrew.cmu.edu [info-cyrus-bounces+dave64=andrew.cmu@lists.andrew.cmu.edu] on behalf of Frank Elsner [frank.els...@tu-berlin.de] Sent: Thursday, December 13, 2012 2:09 PM To: info-cyrus@lists.andrew.cmu.edu Subject: Re: successful create but unsuccessful subscribe On Thu, 13 Dec 2012 11:13:21 -0600 Dan White wrote: [ ... ] > Did this work for you differently in a previous version of cyrus? We have exactly the same problem with cyrus 2.3.16 on RHEL. --Frank Elsner 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: Want to create DC DR Mailbox server
On 08/22/2012 04:09 AM, jayesh shinde wrote: > Hello all , > > I require suggestion for building up the DC DR server. I want to build > the Mailbox server with 5000 users , 1 TB size of total mailbox data. > > 1) DC and DR server will be in two different IDC , with internet > connectivity or with dedicated pipe. > > 2) How to sync the every email ( add / delete / seen / unseen ... etc > ) on the fly from DC to DR ? > Please share if any have good URLs / Blog / wiki / howto steps > information for implementing the above. > > 3) If point 2 have solution , then in case of drill if I point the > LIVE IP from DC to DR and if all emails come on DR server for 1-2 days , > then how to sync back that emails to DC again. > > 4) For syncing data back from DR to DC , Is there any method other that > IMAPSYNC ? > > 5) Is it possible again on the fly syncing of emails from DR to DC ? > > 6) How other sysadmins are managing the Drill situation and DC to DR > syncing ? You can accomplish what you want using Cyrus replication. You can read about it here: http://www.cyrusimap.org/docs/cyrus-imapd/2.4.16/install-replication.php Note that all Cyrus gets you is a second copy of the data. You have to handle failover on your own by either swapping IP addresses and hostnames or munging mailboxes.db, etc. Thanks, Dave 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: IMAP error reported by server. Invalid body section.
On Jun 22, 2012, at 5:10 PM, Simon Matter wrote: >> On 06/22/2012 09:43 AM, Dave McMurtrie wrote: >>> On 06/22/2012 06:35 AM, Adam Tauno Williams wrote: >>>> On Thu, 2012-06-21 at 13:07 -0300, Rodrigo Abantes Antunes wrote: >>>>> The source from horde3 is exactly the same as horde4 >>>> >>>> That is expected. It isn't the message but the interpretation of the >>>> message. These evil messages contain many named parts separated by a >>>> boundry (the boundry value is declared in the header of the message). >>>> Then parts of a message can refer to other parts of the message. So >>>> either H4 can't correctly [or incorrectly!] parse the message into >>>> parts >>>> by boundry or one part references another part that isn't found. >>>> >>>> It would be useful to ask this question on the Horde / IMP mail list. >>> >>> I think this originated as a bug report to Horde and they think it's the >>> IMAP server's fault. >>> >>> Rodrigo, can you forward the message to me? >> >> Hi. Rodrigo sent me the message. I wanted to confirm that the MIME >> structure was correct so I used munpack which was able to successfully >> unpack all the message parts. This isn't a guarantee that the MIME >> structure is correct, but at the very least I can't definitely say the >> message is malformed. >> >> I then imported the message into my mailstore. reconstruct was not >> pleased with it from the start: >> >> Jun 22 15:29:48 cyrusbe-d04 reconstruct[28021]: ERROR: message has more >> than 1000 header lines, not caching any more > > I did the same test on my box and reconstruct worked fine and I can view > the message with Squirrelmail and Thunderbird without any problems. > > What's your version of cyrus-imapd you tested with? I have tested with a > 2.4.16 server. > Interesting. The server I'm testing on isn't a released version, but rather a snapshot build from the caldav-2.4 Git branch. It should be fairly close to 2.4.16. Can you grab telemetry and see what Squirrelmail/tbird is requesting? 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: IMAP error reported by server. Invalid body section.
On 06/22/2012 09:43 AM, Dave McMurtrie wrote:
> On 06/22/2012 06:35 AM, Adam Tauno Williams wrote:
>> On Thu, 2012-06-21 at 13:07 -0300, Rodrigo Abantes Antunes wrote:
>>> The source from horde3 is exactly the same as horde4
>>
>> That is expected. It isn't the message but the interpretation of the
>> message. These evil messages contain many named parts separated by a
>> boundry (the boundry value is declared in the header of the message).
>> Then parts of a message can refer to other parts of the message. So
>> either H4 can't correctly [or incorrectly!] parse the message into parts
>> by boundry or one part references another part that isn't found.
>>
>> It would be useful to ask this question on the Horde / IMP mail list.
>
> I think this originated as a bug report to Horde and they think it's the
> IMAP server's fault.
>
> Rodrigo, can you forward the message to me?
Hi. Rodrigo sent me the message. I wanted to confirm that the MIME
structure was correct so I used munpack which was able to successfully
unpack all the message parts. This isn't a guarantee that the MIME
structure is correct, but at the very least I can't definitely say the
message is malformed.
I then imported the message into my mailstore. reconstruct was not
pleased with it from the start:
Jun 22 15:29:48 cyrusbe-d04 reconstruct[28021]: ERROR: message has more
than 1000 header lines, not caching any more
I tried reading the message with Squirrelmail and that fails. It does 2
FETCH operations. First:
A009 UID Fetch 1 (FLAGS UID RFC822.SIZE INTERNALDATE
BODY.PEEK[HEADER.FIELDS (Date To Cc From Subject X-Priority Importance
Priority Cont
ent-Type)])
I'll sanitize the response to protect people's email addresses:
* 1 FETCH (FLAGS (\Seen) UID 1 INTERNALDATE "22-Jun-2012 15:23:39 -0400"
RFC822.SIZE 739385 BODY[HEADER.FIELDS (Date To Cc From Subject X
-Priority Importance Priority Content-Type)] {1968}
From: X
To: X
Subject: PAPAI,COMO EU NASCI ?
Date: Tue, 22 May 2012 21:59:42 -0300
Content-Type: multipart/related;
boundary="=_NextPart_000_0001_01CD3866.57075390"
Content-Type: multipart/alternative;
boundary="=_NextPart_001_0002_01CD3866.570D6E10"
Content-Type: text/plain; charset="iso-8859-1"
Content-Type: text/html; charset="iso-8859-1"
Content-Type: image/jpeg; name="image004.jpg"
Content-Type: image/jpeg; name="image011.jpg"
Content-Type: image/jpeg; name="image002.jpg"
Content-Type: image/jpeg; name="image009.jpg"
Content-Type: image/jpeg; name="image008.jpg"
Content-Type: image/jpeg; name="image010.jpg"
Content-Type: image/jpeg; name="image003.jpg"
Content-Type: image/jpeg; name="image006.jpg"
Content-Type: image/jpeg; name="image001.jpg"
Content-Type: image/jpeg; name="image005.jpg"
Content-Type: image/jpeg; name="image007.jpg"
)
A009 OK Completed (0.080 sec)
When it attempts to fetch a body part, however, this happens:
A004 UID Fetch 1 BODY[1]
* 1 FETCH (UID 1 BODY[1] "")
A004 OK Completed (0.000 sec)
For kicks, I edited out a ton of X-UOL-SMTP: header fields and
reconstructed the folder again. This time I didn't get the error about
too many header lines, but the result is the same.
I'm heading home to drink cheap beer now and won't get back to this
until Monday, but it does appear that Cyrus is somehow unhappy with this
message.
Thanks,
Dave
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: IMAP error reported by server. Invalid body section.
On 06/22/2012 06:35 AM, Adam Tauno Williams wrote: > On Thu, 2012-06-21 at 13:07 -0300, Rodrigo Abantes Antunes wrote: >> The source from horde3 is exactly the same as horde4 > > That is expected. It isn't the message but the interpretation of the > message. These evil messages contain many named parts separated by a > boundry (the boundry value is declared in the header of the message). > Then parts of a message can refer to other parts of the message. So > either H4 can't correctly [or incorrectly!] parse the message into parts > by boundry or one part references another part that isn't found. > > It would be useful to ask this question on the Horde / IMP mail list. I think this originated as a bug report to Horde and they think it's the IMAP server's fault. Rodrigo, can you forward the message to me? Thanks, Dave 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: GSSAPI for various murder component setups
On 06/14/2012 12:02 AM, Stephen Ingram wrote: > This is exactly the part I'm really confused about. For murder, I see > connections from the frontends and backends to the mupdate server. I > also see connections from the frontends to the backends. The > connections to the mupdate server are, in a very simplistic sense, to > spread information about the mailboxes. I was thinking these should be > machine to machine connections using Kerberos service accounts. Let me try to run through which keys exist on various servers in our environment. I think that will possibly clear things up a bit. In the keytab on our Cyrus frontend servers: * imap/cyrus.andrew.cmu@andrew.cmu.edu service principal. This is used for end-user client authentication to the imap service running on cyrus.andrew.cmu.edu hosts. * pop/cyrus.andrew.cmu@andrew.cmu.edu service principal. This is used for end-user client authentication to the pop service running on cyrus.andrew.cmu.edu hosts. * sieve/cyrus.andrew.cmu@andrew.cmu.edu service principal. This is used for end-user client authentication to the sieve service running on cyrus.andrew.cmu.edu hosts. * nntp/cyrus.andrew.cmu@andrew.cmu.edu service principal. This is used for end-user client authentication to the nntp service running on cyrus.andrew.cmu.edu hosts. * imap/`hostname`@ANDREW.CMU.EDU. The Cyrus master process runs authenticated as this principal. We accomplish this by having a simple cyrus.auth script run on startup from cyrus.conf, and also as a recurring event in cyrus.conf. It does nothing more than set KRB5CCNAME and run kinit. These credentials are used to authenticate to our mupdate server and to each of our Cyrus backend servers. * host/cyrus.andrew.cmu@andrew.cmu.edu. This could really use some documentation. It's used by saslauthd when saslauthd is configured to use kerberos5. The idea is that saslauthd takes the user credentials via a socket and uses those to request a tgt. To make sure it wasn't talking to a spoofed KDC, it then uses that tgt to request a "host" service ticket. "host" is hard-coded in saslauthd. In the keytab on our Cyrus backend servers: --- * imap/`hostname`@ANDREW.CMU.EDU. The Cyrus master process runs authenticated as this principal. We accomplish this by having a simple cyrus.auth script run on startup from cyrus.conf, and also as a recurring event in cyrus.conf. It does nothing more than set KRB5CCNAME and run kinit. These credentials are used to authenticate to our mupdate server. If a client were to connect directly to one of our backends, it would use this service principal to authenticate. If you disable referrals, you won't need to account for clients connecting directly to your backends and you therefore won't need any service principals for client authentication. > However, I'm not really sure, should only the mupdate server have an > mupdate service principals and then the frontend clients and backend > clients connect to mupdate using "user" kerberos principals, or if all > servers involved have service principals. Also when proxying a mail > connection from frontend to backend, how should this be done? The frontends authenticate to the backends using their imap/`hostname`@ANDREW.CMU.EDU credentials (remember, our master process runs authenticated). Proxy authentication is supported in Cyrus-SASL for GSSAPI, so the imap/`hostname` credentials are used for authentication, but the connection is authorized as the "real" user, or the user who authenticated to the frontend. Hence, in the Cyrus logs on the backend you'll see the real username as having logged in, not your imap/`hostname` principal. > And then there is replication This works much the same. Our replicas are all configured with our imap/`hostname` principals as "admins:". sync_client runs with the same imap/`hostname` credentials and authenticates to sync_server thusly. > I guess I'm mostly confused about whether and where to use user and/or > service principals and how does the other end know that it is being > connected to correctly. The backends all look at "proxyservers" in imapd.conf to know if the authenticated user is a frontend or not. The mupdate server uses the "admins:" option in imapd.conf. > For instance is the mupdate server expecting a > user in the admins group to connect to retrieve the mailbox list or > simply a machine and where is that specified in the configuration > files? Correct. mupdate uses "admins" in imapd.conf to determine who may authenticate. > I've found a couple of configuration files floating around in > the mailing list archives and was confused even more after looking at > it for they only seem to cache credentials for service principal type > accounts by inserting lines into the cyrus.conf file to create and > then renew credentials on a regular
Re: GSSAPI for various murder component setups
On 06/13/2012 03:57 PM, Stephen Ingram wrote: > There seems to be quite a bit of information on the Website about > setting up a murder configuration. Most of the documentation, however, > seems to be centered on basic authentication. Is there a good resource > somewhere to using Kerberos to setup the communication between the > mupdate, frontend and backend servers for mupdate, imap and > replication processes? I see some configs in the distribution conf > directory from CMU setups, but they are only partially complete and > based on Kerberos 4. Hi Stephen, I'm not aware of any documentation at all, but it would be nice to have that. We're running a murder configuration at CMU and we use kerberos auth between servers. Please feel free to ask any questions you need and I'll do my best to answer promptly. If you don't even know where to start, I can try to put together some basic information in an email and we can go from there. Perhaps when you get it all working you could contribute some docs back :) Thanks! Dave 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: (important) cyrus-imapd 2.4.16 released
On 05/10/2012 11:45 AM, Marc Patermann wrote: > Hi, > > Jeroen van Meeuwen schrieb (19.04.2012 12:00 Uhr): > >> I'm forwarding this message posted to the announcement mailing list >> originally, to let you know any upgrades should target 2.4.16 as opposed to >> 2.4.15. >> >> We are pleased to announce the release of Cyrus IMAPd 2.4.16. >> >> This is a stable release in the 2.4.x series. > http://www.cyrusimap.org/mediawiki/index.php/Downloads#IMAP_Server > claims 2.4.14 is the latest release: > > "The latest stable/current release of the IMAP server is 2.4.14" Fixed. > The release process should include updating the wiki. Or moving that out of the wiki, but yes, whatever is the least amount of effort for the release engineer but still conveys all the correct information to folks downloading it. > There is not "CHANGES" page in the wiki, is there? Do you mean for changes to the wiki site, or for changes to Cyrus? Both exist. http://www.cyrusimap.org/mediawiki/index.php/Special:RecentChanges will show you recent changes to the wiki. Each release of Cyrus contains a change summary like the following: http://www.cyrusimap.org/docs/cyrus-imapd/2.4.16/changes.php It was recently discussed that we need to improve upon the Cyrus ChangeLog. That will be coming. Thanks, Dave Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Lock problem with mupdate
strace the server and find out what it's doing. Look at the logs on the server. Run netstat to confirm both sides still have an established connection and that iptables isn't silently dropping packets, etc. On Apr 17, 2012, at 5:10 AM, Frank Elsner wrote: > On Tue, 17 Apr 2012 04:41:57 -0400 Dave McMurtrie wrote: >> lsof so you can find out what file descriptor 9 is that read() is blocking >> on. If it's the socket to your mupdate server, figure out why it isn't >> responding. > > Thanks. Indeed it is the connection to the mupdate server: > > mupdate 7395 cyrus9u IPv43273817 0t0 TCP > eg-mailfrontend-febe.intern.elgouna.tu-berlin.de:40362->172.26.17.69:mupdate > (ESTABLISHED) > > So we have to investigate why we can ping in both directions, why the > frontend can autheticate on the mupdate server and why the answer doesn't get > through. > > > Thanks so far, > Frank Elsner > Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Lock problem with mupdate
lsof so you can find out what file descriptor 9 is that read() is blocking on. If it's the socket to your mupdate server, figure out why it isn't responding. On Apr 17, 2012, at 4:01 AM, Frank Elsner wrote: > On Tue, 17 Apr 2012 03:17:12 -0400 Dave McMurtrie wrote: >> mupdate is multithreaded. Try strace -f -p to see what it's doing. > > Process 7393 attached with 2 threads - interrupt to quit > [pid 7398] read(9, > [pid 7393] futex(0x7fdc39d53e84, FUTEX_WAIT_PRIVATE, 1, NULL > > Nearly the same info, not very informative :-( > > > --Frank Elsner > Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Lock problem with mupdate
mupdate is multithreaded. Try strace -f -p to see what it's doing. Thanks, Dave On Apr 17, 2012, at 2:43 AM, Frank Elsner wrote: > > Hi experts, > > we have a mupdate server (Solaris 10, Cyrus 2.3.16) and frontnend and backend > servers (Redhat Linux due to migration from Solaris environment). > > The RHEL frontend connects to the (Solaris) mupdate server, authentication > work. > > But after > > Apr 17 07:27:21 eg-mailfrontend cyrus/mupdate[7395]: successful mupdate > connection to mupdate-febe.intern.tu-berlin.de > Apr 17 07:27:21 eg-mailfrontend cyrus/mupdate[7395]: scarfing mailbox list > from master mupdate server > > nothing happens, the mailbox list lacks update. > > Lets look what mupdate does: > > [root@eg-mailfrontend elsnccpa]# ps -ef | grep mupdate | grep -v grep > cyrus 7393 7388 0 07:27 ?00:00:00 mupdate > cyrus 7395 7388 0 07:27 ?00:00:00 mupdate > [root@eg-mailfrontend elsnccpa]# strace -p 7396 > Process 7396 attached - interrupt to quit > accept(4, ^C > Process 7396 detached > [root@eg-mailfrontend elsnccpa]# man tcpdump > [root@eg-mailfrontend elsnccpa]# man imapd.conf > [root@eg-mailfrontend elsnccpa]# man imapd.conf > [root@eg-mailfrontend elsnccpa]# strace -p 7395 > Process 7395 attached - interrupt to quit > futex(0x7f8af2249e84, FUTEX_WAIT_PRIVATE, 1, NULL^C > > The frontends running the same cyrus version under Solaris work perfect. > > Any clue? > > > --Frank Elsner > > 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: Problem with folder subscriptions and LIST/LSUB
Quick workaround (assuming that you have root access to the server): 1) using your mail client, create a new folder named newfolder. 2) log in to your server and from a root shell, su to your cyrus user. 3). Navigate the filesystem and cp all the mail files from the directory with the funky name that Cyrus won't list to newfolder. 4) reconstruct newfolder. Hth, Dave On Feb 1, 2012, at 8:32 PM, "Anthony L. Awtrey" wrote: > Hello all, > > Okay, I now realize this probably is a known issue: > > https://bugzilla.cyrusimap.org/show_bug.cgi?id=3628 > > I don't ordinarily try to help with these kinds of bugs, because I don't > know enough about imap or the code base to be much more than annoying. > So let me cut to the chase. > > 1. My wife has our tax information in folders with numbers as names. > 2. Those folders cannot currently be subscribed. > 3. The improved sorting change did not appear to work for me. > 4. If I can't provide her access to these folders, she will not be > happy. > 5. When the Mama ain't happy, ain't nobody happy. > > Therefore, > > 6. I am willing to pay $50 US to get a fix or workaround for this bug. > > I realize I could probably dork around with dumping and reloading > databases, copying email, renaming email folders, and reconstructing the > indexes. However, the last time I did that kind of thing (after an > upgrade), I think I fat fingered the steps and screwed up the wife's > seen mail status and priority labels. This has made me a little hesitant > about trying this again without someone helping who is more familiar > with what's involved. > > If anyone can provide a work-around patch to close bug 3628, or even a > step-by-step process to change the troublesome folder names, contact me > with details on how I may provide remuneration. Paypal? Want something > from Amazon? A check in the mail? Just let me know. > > I know that my problems are small in the world of servers with thousands > of email accounts and gigabytes of email, but I really want to keep the > wife happy. Can anyone help me? > > Tony > -- > Anthony L. Awtrey > > http://awtrey.com/ > > 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: Imap-Proxy and Cyrus Aggregator
On Jan 5, 2012, at 8:15 PM, "Fabio S. Schmidt" wrote: > Hi, on a Cyrus Aggregator enviroment, in which servers should I deploy > Imap-Proxy (http://www.imapproxy.org)? > If you're using imapproxy with a stateless webmail product, install imapproxy on your webmail servers. If you're using imapproxy for some other purpose, you probably don't need it. Hth! Dave Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: cyrus 2.3.16 ssl/tls and no deleting message on Samsung galaxy
On 12/28/2011 09:00 AM, Josef Karliak wrote: > Hi there, > it maybe some error or bug somewhere - we use Samsung galaxy S2, android > 2.3.3. I've set it up as a imap client. When I delete a message, it > disapears from the phone email list. After "renewing" mail box the > deleted message is in the new messages again. I'm going to guess that your phone is only locally deleting the messages and failing to propagate that deletion to the server. Check your server logs to see if the user is actually connecting and logging in to the server when the delete occurs on the phone. You may also enable telemetry logging [1] for this user to verify that the deleted flag is being set and an expunge command is being sent. >I n the imapd.conf file > I've delete mode "immediate": > expunge_mode: immediate > delete_mode: immediate These don't have any effect on what the client will perceive with regard to deleting folders and expunging messages. When a client deletes a folder, it will always see that folder as having been deleted. If you have delete_mode set to delayed, the server will rename the folder to the DELETED hierarchy when a client deletes it instead of actually removing it. The client will think it's deleted either way. When you have expunge_mode set to delayed, the server will just mark the file as having been expunged but leave the actual file on disk. > Cyrus service is restarted after change. So what I missed ? Check your logs and enable telemetry logging for the user that's having this issue. You should be able to see what's going on then. hth, Dave [1] http://wiki.kolab.org/Cyrus_imap_telemetry_logging Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: 2.3 to 2.4 Murder upgrade
On 12/08/2011 03:20 PM, Andrew Morgan wrote: > On Thu, 8 Dec 2011, Bron Gondwana wrote: > >> On Thu, Dec 08, 2011 at 10:00:26AM -0800, Andrew Morgan wrote: >>> So, I tried adding all the new 2.4 capabilities to the >>> suppress_capabilities setting. I found that if I added URLAUTH=BINARY to >>> suppress_capabilities, I was unable to establish an IMAP connection >>> to the >>> frontend. imtest didn't print any output, and proxyd on the frontend was >>> spinning at 100% cpu. If I remove URLAUTH=BINARY from >>> suppress_capabilities, leaving all the other new capabilities >>> suppressed, >>> it works fine. I'm not sure if this is a bug... Let me know if I should >>> file it as a bug. >> >> Meep - sorry, it's a bug. Fixed on master. I really REALLY >> need to take some time fixing stable. >> >>> suppress_capabilities: ESEARCH LIST-EXTENDED QRESYNC WITHIN XLIST >>> ENABLE SORT=DISPLAY >>> >>> The imapd.conf manpage says I only need: >>> >>> suppress_capabilities: ESEARCH QRESYNC WITHIN XLIST LIST-EXTENDED >>> >>> if I have 2.3 murder backends. Is that correct, or should I suppress the >>> new ENABLE and SORT=DISPLAY too? >> >> Probably should suppress SORT=DISPLAY. That's even newer than the >> imapd.conf docs! I think ENABLE is OK, because clients are expected >> to handle NO responses. > > Okay. Is there any harm not suppressing URLAUTH=BINARY? :) I'm not aware of any clients that use it, so it probably doesn't matter if it's offered as a capability. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: 2.3 to 2.4 Murder upgrade
On 12/06/2011 05:48 PM, Andrew Morgan wrote: > On Fri, 14 Oct 2011, Dave McMurtrie wrote: ...snipped... >>> Upgrading from 2.4.5 >>> >>> New config option: suppress_capabilities, which takes a space >>> separated list of capabilities which will NOT be given in any imap >>> capability response. This can be used on frontends to not display >>> capabilities that older backends don't have, so clients don't get >>> confused >>> >>> >>> This leads me to believe that I should upgrade the backends to 2.4 >>> first. >>> Is that true? Has anyone done a Murder upgrade from 2.3 to 2.4 and can >>> tell me what order they upgraded the hosts? >>> >> >> Yes, you'll want to upgrade the frontends first and suppress the new >> capabilities on the frontends that the old backends aren't yet aware of. I should have mentioned the reason why we did the frontends first for the benefit of anyone else who is searching for this information. You need to do the frontends first because as of 2.4, the backends will (correctly) return the NoSelect flag for any remote folders that you're subscribed to in an LSUB response. This is most common with shared folders, where the shared folder may not be on the same backend as the user's Inbox. The 2.4 frontends will know to scrub the NoSelect flag in this case. > Hmmm, how do I know which capabilities to suppress? Should I just > compare the CAPABILITY response from a 2.3 and a 2.4 server? We used: suppress_capabilities: ESEARCH QRESYNC WITHIN but your idea is perfectly cromulent, also. HTH, Dave Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Virus Scanning moved imap files
On 11/30/2011 12:41 PM, Marc Patermann wrote: > Shelley, > > Shelley Waltz schrieb (30.11.2011 16:47 Uhr): >> I have two imap servers, one which has smtp(postfix) and virus scanning >> before delivery to imap. >> >> I have another imap archive server which has no smtp, but users simply >> move messages from their imap account(s) to the archive server. It appears >> that some messages have infections. >> >> My question is, other than wholesale scanning the entire imap directory, >> moving >> infected messages to a virus folder, and reconstructing the mailbox, is >> there a >> more elegant way? One which scans on arrival before depositing into inbox? > I think you mean an "on access scanner". > There are a few IMHO i.e. > http://www.clamav.net/lang/en/download/third-party-tools/3rdparty-fs/ > > But I am not sure what happens, if the just created/copied infected > cyrus message file is (somehow) /handled/ by the scanner. It's not exactly what you're asking for, but I figure it's worth a mention in case you didn't know it existed, and it is somewhat related. Cyrus contains a tool called cyr_virusscan that is capable of scanning messages for viruses, optionally removing infected messages and optionally appending a new message to the mailbox with an explanation of what it removed. I doubt anyone has ever used cyr_virusscan outside of CMU because it doesn't build by default and it's not documented anywhere that I'm aware of. If you look at the source files, however, you'll see it there. To build it, you have to manually: make cyr_virusscan after you run configure. I think Ken intended for it to be able to use any virus scanning engine, but it might currently only work with libclam. At the very least, I know we've only ever used it with ClamAV. Also, the ClamAV api changed since Ken wrote cyr_virusscan. Not long ago, I updated the code to work with the new ClamAV api but it hasn't been well tested since then. HTH, Dave -- Dave McMurtrie, SPE Email Systems Technical Lead Carnegie Mellon University, Computing Services Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: fatal error: failed to mmap new message file
> On Sun, 2011-11-27 at 13:26 -0500, Dave McMurtrie wrote:
>> > On Sun, 2011-11-27 at 12:37 -0500, Adam Tauno Williams wrote:
>> >> On Sun, 2011-11-27 at 12:14 -0500, Adam Tauno Williams wrote:
>> >> > I updated one of my production boxes to Cyrus IMAPd 2.4.12 [using
>> >> > Simon's excellent packages]
>> >> > On my test box / replica I was able to reconstruct all the
>> mailboxes
>> >> > But [of course] on the production box I have a few mailboxes
>> >> [important
>> >> > ones, of course] that fail a reconstruc
>> >> > $ /usr/lib/cyrus-imapd/reconstruct -r user.steve
>> >> > fatal error: failed to mmap new message file
>> >> > $ /usr/lib/cyrus-imapd/reconstruct -r user.barnosky
>> >> > fatal error: failed to mmap new message file
>> >> > Reconstructing other mailboxes is working. Hints / Tips?
>> reconstruct
>> >> > doesn't seem top have a verbose / debug switch.
>> >> In the log file I see -
>> >> Nov 27 12:36:23 sardine reconstruct[9524]: seen_db: user barnosky
>> >> opened /var/lib/imap/user/b/barnosky.seen
>> >> Nov 27 12:36:23 sardine reconstruct[9524]: IOERROR: mapping new
>> message
>> >> file: No such device
>> > If I trace the reconstruct it fails at -
>> > connect(9, {sa_family=AF_FILE, path="/dev/log"...}, 110) = 0
>> > send(9, "<23>Nov 27 12:50:42 reconstruct["..., 103, MSG_NOSIGNAL) =
>> 103
>> > fcntl64(8, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0})
>> =
>> > 0
>> > fstat64(8, {st_mode=S_IFREG|0600, st_size=7924, ...}) = 0
>> > stat64("/var/lib/imap/user/b/barnosky.seen", {st_mode=S_IFREG|0600,
>> > st_size=7924, ...}) = 0
>> > fcntl64(8, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0})
>> =
>> > 0
>> > munmap(0xb7eb7000, 16384) = 0
>> > close(8)= 0
>> > open("/var/spool/imap/b/user/barnosky/cyrus.expunge", O_RDWR) = 8
>> > fstat64(8, {st_mode=S_IFREG|0600, st_size=1200504, ...}) = 0
>> > mmap2(NULL, 1200504, PROT_READ, MAP_SHARED, 8, 0) = 0xb7d95000
>> > brk(0x908b000) = 0x908b000
>> > open("/proc/meminfo", O_RDONLY) = 10
>> > fstat64(10, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
>> > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
>> > 0) = 0xb7d94000
>> > read(10, "MemTotal: 775008 kB\nMemFre"..., 4096) = 771
>> > close(10) = 0
>> > munmap(0xb7d94000, 4096)= 0
>> > open("/var/spool/imap/b/user/barnosky/cyrus.index.NEW",
>> O_RDWR|O_CREAT|
>> > O_TRUNC, 0666) = 10
>> > open("/var/spool/imap/b/user/barnosky/cyrus.cache.NEW",
>> O_RDWR|O_CREAT|
>> > O_TRUNC, 0666) = 11
>> > write(11, "\236\0w\233", 4) = 4
>> > write(10, "\236\0w\233\0\0\0\0\0\0\0\f\0\0\0\200\0\0\0`\0\0\0\0N\321\5
>> > \227\0\0018\313"..., 128) = 128
>> > open("/var/spool/imap/b/user/barnosky", O_RDONLY) = 12
>> > fstat64(12, {st_mode=S_IFDIR|0700, st_size=282624, ...}) = 0
>> > mmap2(NULL, 282624, PROT_READ, MAP_SHARED, 12, 0) = -1 ENODEV (No such
>> > device)
>> mmap() is supposed to fail with ENODEV if the underlying filesystem
>> doesn't support mmap. What filesystem is
>> /var/spool/imap/b/user/barnosky
>> on?
>
> The same filesystem all the other mailboxes are on. It is one logical
> volume.
Indeed, and I can see that an earlier mmap for a file in the same
directory succeeded. I'm sorry, but I have no idea why mmap is failing in
this manner.
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: fatal error: failed to mmap new message file
> On Sun, 2011-11-27 at 12:37 -0500, Adam Tauno Williams wrote:
>> On Sun, 2011-11-27 at 12:14 -0500, Adam Tauno Williams wrote:
>> > I updated one of my production boxes to Cyrus IMAPd 2.4.12 [using
>> > Simon's excellent packages]
>> > On my test box / replica I was able to reconstruct all the mailboxes
>> > But [of course] on the production box I have a few mailboxes
>> [important
>> > ones, of course] that fail a reconstruc
>> > $ /usr/lib/cyrus-imapd/reconstruct -r user.steve
>> > fatal error: failed to mmap new message file
>> > $ /usr/lib/cyrus-imapd/reconstruct -r user.barnosky
>> > fatal error: failed to mmap new message file
>> > Reconstructing other mailboxes is working. Hints / Tips? reconstruct
>> > doesn't seem top have a verbose / debug switch.
>>
>> In the log file I see -
>>
>> Nov 27 12:36:23 sardine reconstruct[9524]: seen_db: user barnosky
>> opened /var/lib/imap/user/b/barnosky.seen
>> Nov 27 12:36:23 sardine reconstruct[9524]: IOERROR: mapping new message
>> file: No such device
>
> If I trace the reconstruct it fails at -
> connect(9, {sa_family=AF_FILE, path="/dev/log"...}, 110) = 0
> send(9, "<23>Nov 27 12:50:42 reconstruct["..., 103, MSG_NOSIGNAL) = 103
> fcntl64(8, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) =
> 0
> fstat64(8, {st_mode=S_IFREG|0600, st_size=7924, ...}) = 0
> stat64("/var/lib/imap/user/b/barnosky.seen", {st_mode=S_IFREG|0600,
> st_size=7924, ...}) = 0
> fcntl64(8, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0}) =
> 0
> munmap(0xb7eb7000, 16384) = 0
> close(8)= 0
> open("/var/spool/imap/b/user/barnosky/cyrus.expunge", O_RDWR) = 8
> fstat64(8, {st_mode=S_IFREG|0600, st_size=1200504, ...}) = 0
> mmap2(NULL, 1200504, PROT_READ, MAP_SHARED, 8, 0) = 0xb7d95000
> brk(0x908b000) = 0x908b000
> open("/proc/meminfo", O_RDONLY) = 10
> fstat64(10, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb7d94000
> read(10, "MemTotal: 775008 kB\nMemFre"..., 4096) = 771
> close(10) = 0
> munmap(0xb7d94000, 4096)= 0
> open("/var/spool/imap/b/user/barnosky/cyrus.index.NEW", O_RDWR|O_CREAT|
> O_TRUNC, 0666) = 10
> open("/var/spool/imap/b/user/barnosky/cyrus.cache.NEW", O_RDWR|O_CREAT|
> O_TRUNC, 0666) = 11
> write(11, "\236\0w\233", 4) = 4
> write(10, "\236\0w\233\0\0\0\0\0\0\0\f\0\0\0\200\0\0\0`\0\0\0\0N\321\5
> \227\0\0018\313"..., 128) = 128
> open("/var/spool/imap/b/user/barnosky", O_RDONLY) = 12
> fstat64(12, {st_mode=S_IFDIR|0700, st_size=282624, ...}) = 0
> mmap2(NULL, 282624, PROT_READ, MAP_SHARED, 12, 0) = -1 ENODEV (No such
> device)
mmap() is supposed to fail with ENODEV if the underlying filesystem
doesn't support mmap. What filesystem is /var/spool/imap/b/user/barnosky
on?
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: 2.3 to 2.4 Murder upgrade
On Oct 14, 2011, at 7:16 PM, Andrew Morgan wrote: > I finally have some time to work on upgrading our Cyrus Murder > installation from 2.3.16 to 2.4.12. We have 3 backends, 3 frontends, and > a mupdate master, all separate systems. > > When I upgraded from 2.2 to 2.3, I had to upgrade the backends first. > Otherwise, the 2.3 frontends would issue commands that the 2.2 backends > didn't know yet. I see the following note in the install-upgrade guide: > > Upgrading from 2.4.5 > > New config option: suppress_capabilities, which takes a space > separated list of capabilities which will NOT be given in any imap > capability response. This can be used on frontends to not display > capabilities that older backends don't have, so clients don't get confused > > > This leads me to believe that I should upgrade the backends to 2.4 first. > Is that true? Has anyone done a Murder upgrade from 2.3 to 2.4 and can > tell me what order they upgraded the hosts? > Yes, you'll want to upgrade the frontends first and suppress the new capabilities on the frontends that the old backends aren't yet aware of. hth, Dave Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Thunderbird's IMAP COMPRESS and Cyrus-IMAP 2.4.11
On 10/14/2011 08:49 AM, Bron Gondwana wrote: > (CC: info-cyrus - hopefully people can read the problem in my response > at least!) > > The easiest fix will be: > > suppress_capabilities: COMPRESS=DEFLATE > > in your imapd.conf. > > I think you can change it in Thunderbird as well, in the advanced config: > > mail.server.default.use_compress_deflate > > I'd be interested in more detail about it not working. Given that I > wrote both ends (pretty much - Ken did the initial implementation at the > Cyrus end, but I did work on it too) and I use it with Thunderbird all > the time, I do care about it working! We've had a ton of reports about it here, as well. We generally just have folks disable compression in Thunderbird. I could re-enable compression and wait until I find another message that breaks it. The problem was that I couldn't come up with a good method for diagnosing this. If you can offer me some assistance, that would be great. Thanks! Dave Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: SQL database backend
On Oct 10, 2011, at 7:04 PM, Bron Gondwana wrote: > Hi, > > Is there anyone out there using the SQL backend in production? > Yes. We use it for the userdeny database. > Would you be really sad if I redesigned it? > Not at all. Thanks! Dave Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: autocreate / autosieve patches on 2.4.10
On Aug 8, 2011, at 7:13 PM, "Jeroen van Meeuwen (Kolab Systems)" wrote: ...snipped... >>> >>> >> >> > - must be compatible with running in a murder, In theory, this should be much less work in the 2.4 code since creates can be blindly issued to any frontend in a murder now. Dave Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Cyrus Murder - Move mailbox with user connected -
On 5/12/11 7:06 PM, Lucas Zinato Carraro wrote: > > I can move mailboxes between servers with a user connected ? Generally, yes, but I'm not 100% sure that there aren't edge cases. Actually, I'm going to assume that there are probably edge cases. Also, newer versions should be somewhat better than older versions at dealing with this. At the very least, if you're running any version more recent than 2.3.15 you'll want to make sure you set disconnect_on_vanished_mailbox to true in imapd.conf. If you don't set this, the client will remain connected to proxyd on the frontend and proxyd will remain connected to imapd on the backend. After the move, there will be no mail on that backend server and the user will see an empty mailbox. Setting disconnect_on_vanished_mailbox will cause imapd to disconnect proxyd and hence, the client. Depending on the client, it may silently reconnect and the user won't notice. That behavior varies by client. > Exist a way to block the connection until the operation finish ? Cyrus takes care of this for you by setting the mailbox state to MBTYPE_RESERVE during the move. Note that this happens per-folder as each one is being moved, and not for the entire mailbox hierarchy. If an IMAP client attempts to access a folder while it's in reserved state it will get either a BAD or NO (I didn't look to see which) "Mailbox is currently reserved" back. hth, Dave Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Upgrading from 2.3 to til 2.4
On 05/10/2011 01:00 PM, Frank Elsner wrote: > On Tue, 10 May 2011 12:19:42 -0400 Wesley Craig wrote: >> It's usually possible in a murder configuration to do a zero downtime >> upgrade by xfer-ing users to a backend running the new version. The admin >> is then in control of how much index upgrade load to inflict on the new >> machine. > > I'm very interested in details of the "xfer-ing". Can you provide them? This is how we accomplished our upgrade from 2.3 to 2.4. We originally planned an in-place upgrade, but we encountered the same performance problems you noted. Instead, we vacated one server at a time and did the upgrades with no mailboxes in place. We were then free to move mailboxes back on to the newly upgraded server. If you are running a Cyrus Murder, simply connect via cyradm and issue a "rename" command using the same source and destination mailbox name, but specify a different server. The result will be that the mailbox will keep its original name but will be moved to the different server. For example, if my mailbox was on server1 and I wanted to move it to server 2 I could: $ cyradm server1 > rename user.dave64 user.dave64 server2 To specify a partition instead of moving it to the defaultpartition, > rename user.dave64 user.dave64 server2!u1 hth, Dave Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Mailbox quota after reconstruct
On 04/18/2011 06:35 AM, "Eero Hänninen" wrote: > Hi, > > Whatever reason I have move mailboxes between mailbox hosts without murder > setup, so I do: > * create destination mailbox over imap port > * set destination acl over imap port > * set destination mailbox quota over imap port > * copy from source host to destination host mailbox content (with cyrus.* > files) with scp > * do reconstruct -rf on destination host for mailbox > > After that everything fine but quota. Quota shows 0% usage and new mails > only will increase use of mailbox quota. So I run quota -f and everything > went ok. So my question is this normal and I must run quota -f such kind > messages move or should reconstruct/cyr_expire take care about it ? Are you copying over the quota file? If you're not setting quota_db in imapd.conf to something other than quotalegacy, you'll find the user's quota file under $conf_dir/quota/ If you copy that over, the quota won't be zero. It may not, however, be correct depending on whether or not you're dealing with the potential for mail delivery to that mailbox during the move. Thanks! Dave Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re : Error when compilating cyrus imap
On 04/13/2011 11:28 AM, Ami Stage wrote: > the problem is solved, > i had a mistake in the file configure.in Did you modify configure.in, or is there a bug in the distributed version? Thanks! Dave Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Cyrus 2.4.7beta1 Released
On Mar 29, 2011, at 4:27 PM, "Rosenbaum, Larry M." wrote: > I've just installed beta1 on Solaris 9 Sparc and got the following error from > cyradm: > > # cyradm localhost --tls > verify error:num=19:self signed certificate in certificate chain > Password: ld.so.1: perl: fatal: relocation error: file > /usr/local/lib/perl5/site_perl/5.10.1/sun4-solaris/auto/Cyrus/IMAP/IMAP.so: > symbol cyrus_getpass: referenced symbol not found > Killed > I think this is my fault. I will have a look later tonight. > Here is the configure command I used: > > CC=gcc LDFLAGS="-L/usr/local/lib -R/usr/local/lib" \ > ./configure \ > --enable-idled \ > --disable-gssapi \ > --without-krb \ > --with-cyrus-prefix=/usr/local/cyrus \ > --without-bdb \ > --with-openssl=/usr/local/ssl \ > --with-zlib=/usr/local/lib \ > --with-sasl=/usr/local > > > Thanks, Larry > >> -Original Message- >> From: info-cyrus-bounces+info-cyrus=ornl@lists.andrew.cmu.edu >> [mailto:info-cyrus-bounces+info-cyrus=ornl@lists.andrew.cmu.edu] On >> Behalf Of Bron Gondwana >> Sent: Sunday, March 27, 2011 10:16 AM >> To: cyrus-annou...@lists.andrew.cmu.edu; cyrus-de...@lists.andrew.cmu.edu; >> info-cyrus@lists.andrew.cmu.edu >> Subject: Cyrus 2.4.7beta1 Released >> >> We are pleased to announce the release of Cyrus IMAPd 2.4.7beta1 >> >> You can download it from the snapshots directory: >> >> http://www.cyrusimap.org/releases/snapshots/cyrus-imapd-2.4.7beta1.tar.gz >> >> This is an beta release in the 2.4.x series, fixing a whole pile >> of bugs found since the release of 2.4.6, including all the >> remaining bugs in bugzilla marked for fix in 2.4.7. If no >> issues are found, this is what will be released as 2.4.7 >> later this week. >> >> Changes to the Cyrus IMAP Server since 2.4.7alpha1: >> * Fixed bug #3423 - STARTTLS plaintext command injection >> vulnerability >> * Bug #3382 Added "failedloginpause" config option >> * Bugs #3383/3385 Removed some obsolete config options >> * Bug #3389 $confdir/proc not created on the fly >> * Bug #3394 fix imtest parsing of MECHLIST >> * Bug #3399 fix with_ldap option default >> * Bug #3307 fix mbpath crash on remote mailbox >> * Bug #3420 use getpassphrase on Solaris, now passwords >> over 8 characters long work with cyrus tools >> * Bug #3400 and others - lots of bugs with XFER between >> different versions in murder clusters fixed, including >> a bug that caused only mailboxes with zero messages to >> be rejected for upgrade >> * Bug #3391 fix rename which just moves between partitions >> * Bug #3103 fix imtest using plain authentication when it must not >> >> Please send any feedback to the cyrus-devel mailing list. I'm STILL >> hoping to have a stable 2.4.7 before the end of the month (and I >> have 3 days left!) >> >> Regards, >> >> Bron. >> >> 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/ > Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Problem configuring lmtp on cyrus backend
On 03/16/2011 09:12 AM, Michael Menge wrote: > Hi, > > i have a problem configuring cyrus backend in a almost traditional > murder setup. > > I have one master process which starts the forntend and backend services. > The forntend services use /etc/imapd_fe.conf as config file and listen > on the external network interface and the backend services listen to > the internal network interfaces and use /etc/imapd_be.conf > > The lmtpdproxy delivers the mail to the backend using lmtp over tcp. > The backend lmtpd asks the mupdate server where the mailbox is, > which results in the "wrong" answer that the mailbox is remote. > The backend tries to proxies the mail to an other lmtpd > on the same backend. This results in an infinite loop. > I tried this with 2.4.6 and 2.3.16. > > AFAIK the backend config must contain the mupdate_server > because create mailbox, rename mailbox and delete mailbox > information must be send to the mupdate master. > But if mupdate_server is configured lmtpd will ask > the mupdate_server where the mailbox is, which will always > result in an "remote mailbox" as answer > > What do i need to change? If you're running 2.3.x on your frontends and 2.4.x on your backends, you need to upgrade your frontends. hth, Dave Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: email in shared folders not showing up with multiple backend servers
On 03/02/2011 02:17 PM, Robert Spellman wrote: > I'm in the process of moving users from back end servers running cyrus > 2.2.12 to 2.4.6. Users who have been moved over can no longer see the > content of shared folders if the shared folder resides on the 2.2.12 > server. The front end and murder servers are still running 2.2.12. The > shared folders show up in Thunderbird when trying to subscribe to them, > but they are greyed out in the "All Folders" pane, and the next time you > go into subscribe, they are unchecked again. > > Oddly enough, we are running imp for a webmail client, and they continue > to see the content of the shared folders. > > Here's my imapd.conf from the backend server: The frontend servers being 2.2.12 is most likely your problem. The LSUB is being proxied to the backend server since that's where the subscription information is. Your 2.4.x backend will correctly list mailboxes on remote servers as \Noselect. The 2.4.x frontends know how to magically strip the \Noselect from the proxied response, but the 2.2.12 frontends don't. You should upgrade your frontends to 2.4.6 first, but the other trick is that you have to make sure you disable any capabilities that the old 2.2.12 backends don't support using the suppress_capabilities config option in imapd.conf. Something like suppress_capabilities: ESEARCH QRESYNC WITHIN Thanks, Dave Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Problems with NNTP access
On Mar 2, 2011, at 3:49 AM, Bron Gondwana wrote: > On Tue, 1 Mar 2011 23:47:20 -0500 > Lars Kellogg-Stedman wrote: > >> Hello all, >> >> I'm getting some odd errors from Cyrus trying to access mailboxes via >> NNTP, and I'm hoping you can help out. The basic symptoms are that >> the mailboxes should up in an NNTP LIST command, but trying to select >> the via GROUP results in an a "unknown error": > > Oh good - someone who actually USES NNTP! > >> LIST >> 215 List of newsgroups follows: >> sample 0 1 y >> . >> GROUP sample >> 411 No such newsgroup (Unknown error: 0) > > Can you please create a bug report at bugzilla.cyrusimap.org, with a copy of > the config files (imapd.conf and cyrus.conf) you're using, and a summary of > the traffic. > > I didn't have any NNTP users to test when putting 2.4.x together, so it will > be good to get this fixed. > We tested it and we're running 2.4.x nntpd in production now. I thought I had mentioned that to you, but I guess not. Let me know if you need me to test anything for you. Thanks! Dave Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: custom notifications
...initially forgot to send to the list. sorry. On 02/15/2011 04:37 AM, Wolfgang Hennerbichler wrote: > Hi, > > I'd like to write a custom notification system (using xmmp or something like > that, I don't know yet :)) for cyrus. > I've had a look at the notify_unix/simple_notify - file in the > contrib-directory. It doesn't seem to work in my installation (the script > doesn't log any notifications, although notifyd does for example notify > zephyr, which works), or maybe I don't understand the concept of > notifications. So I'd like to ask a couple of questions: > * does anybody have custom notifications up and running Yes. > by reading the notification-socket of cyrus? No. > * does notifyd need to be running in order to make the notify-socket > readable, or is the notify-socket filled by the cyrus-master process? > * where would I find instructions on that? You want to set the notify_external option in imapd.conf and point that at a program (script, binary, whatever) that you write. notifyd will fork/exec your program and pass it -c, -p, -u and -m command line arguments. Your program can then to whatever custom notification you want it to. This was added in the 2.4.x series. The imapd.conf option is documented in the imapd.conf manpage here: http://cyrusimap.org/docs/cyrus-imapd/2.4.6/man/imapd.conf.5.php Let me know if you need any additional information. Thanks! Dave Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: DELETED folders appear with the tag \NoSelect in Cyrus IMAP 2.4.6
On 01/13/2011 09:18 PM, Lucas Zinato Carraro wrote: > Using cyrus imapd 2.4.6 with delay expunge for folders enabled. > > When i delete a folder this folder is moved to DELETED/user/.. correctly > > But when i use the subscribe function the deleted folder folder appears > for user with \NoSelect flags. > > > DELETED \NoSelect > user \NoSelect > jonh.doe \NoSelect > folder_deleted \NoSelect > > INBOX >Sent >Trash > Junk > > User can not select the deleted folder but it appears for him. > Its possible to hide deteted folders from users ?? > Hide entire DELETED/ preffix ?? Are you running a murder configuration, and if so, do you have delete_mode set on your frontend servers as well as your backend servers? Thanks, Dave Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Put /lock and /proc in tmpfs
On 1/2/11 7:50 PM, Lucas Zinato Carraro wrote: > It's safe to put/proc and/lock in tmps ? It's safe to put both of these in tmpfs, and since they're fairly busy it's a good idea for performance reasons. Further, nothing ever removes files from /lock/, so it's probably a good idea in general to mount that on tmpfs such that a reboot will purge it. The Cyrus code will create all the necessary directory structure under /lock on-demand. Thanks, Dave Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Does anyone allow unlimited or extremely large quotas?
On 11/16/2010 10:36 AM, Wesley Craig wrote: > Didn't Dave write up.imapproxy? It makes a huge difference for, e.g., IMP& > roundcube. Also, configuring client to not retrieve the LIST of mailboxes > during every transaction is a big win. Coincidentally, yes I did originally write that :) Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Fwd: Re: Does anyone allow unlimited or extremely large quotas?
I didn't realize that I only responded to Rob here. Perhaps my additional information will shed some light on the kind of information I'm looking for. Original Message Subject: Re: Does anyone allow unlimited or extremely large quotas? Date: Tue, 16 Nov 2010 07:06:53 -0500 From: Dave McMurtrie To: Rob Mueller On 11/16/2010 06:45 AM, Rob Mueller wrote: > >> This may be slightly off-topic, so apologies in advance. Is there >> anyone out there who allows unlimited quota for their users or provides >> extremely large quotas when asked for? > > What do you consider extremely large? And what sort of problems are you > referring to? I don't actually know what sort of problems I'm referring to, hence the question. The big problem I can imagine would be opendir() and readdir() with a huge number of files in a directory, but the cyrus code doesn't appear to do that in a lot of places that would matter to a user (deleting an entire folder, delete sieve scripts, etc) in the course of normal operations. My manager has asked me how well Cyrus will cope with large (100GB+) or unlimited quotas. My answer to him was that it should be okay, but I have very little practical experience with such so I wanted to ask on the list. > The usual issue is just the huge number of emails and thus files that > accumulate. Creating a fresh replica, body searching, reconstructing, > etc all take quite a bit of time because of the large amount of random > IOs. Apart from that, everything does actually work ok... The only issue we ever had was with a bboard that our network group sends automated system messages to. Something in their environment went haywire and we ended up with ~1.5 million messages in that bboard. They were unable to find a client that was willing to deal with the folder to be able to clean it up. I was able to connect using imtest and SELECT and FETCH messages without any problems, though. I also recall that replication was broken by this folder, but I don't remember exactly why. So basically, I have this tiny amount of practical experience that tells me if there are 1.5 million files in a single folder, clients may be unhappy and replication may break but the server was still generally working. Any anecdotal evidence I can collect in addition to this would be helpful for me to be able to go back to my manager with. Thanks! Dave Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Does anyone allow unlimited or extremely large quotas?
On 11/16/2010 06:45 AM, Gavin McCullagh wrote: > Hi, > > On Tue, 16 Nov 2010, Dave McMurtrie wrote: > >> This may be slightly off-topic, so apologies in advance. Is there >> anyone out there who allows unlimited quota for their users or provides >> extremely large quotas when asked for? > > What do you regard as extremely large? 10GB, 100GB, 1TB, ...? Well, unlimited was the largest I had in mind. Short of that, sure, 10GB, 100GB 1TB would all be large. Thanks, Dave Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Does anyone allow unlimited or extremely large quotas?
Good morning, This may be slightly off-topic, so apologies in advance. Is there anyone out there who allows unlimited quota for their users or provides extremely large quotas when asked for? If so, can you describe any problems you've had with this? Thanks, Dave Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Anyone using ptloader with AFS?
On 10/20/2010 10:51 AM, Dave McMurtrie wrote: > Hi, > > I'm curious to learn whether anyone is using ptloader with AFS. > > We're using it here, but our build environment is somewhat... > interesting. I'd be mildly surprised if anyone is actually able to > compile and link ptclient/afskrb.c from the provided Cyrus source tarballs. > > In the not-so-distant future, I'd like to take a stab at cleaning up > some of the autoconf bits of Cyrus and the AFS checks look like a ripe > target for cleanup. Before I go off and break things for some number of > people, I'd like to get a rough guess as to how many people are even > using AFS. > > Even better, if you are using AFS/ptloader, does it actually build for > you without any modifications? Nobody answered this, so I'm going to assume that nobody else is using it. I consider this to be a good thing, because it means there's less of a chance that my changes will break what other people are doing and I already know my changes work for us. At any rate, I created a dev/dave64 git branch that contains the changes I made. I encourage you to test it if you're interested. You'll need to specify --enable-afs and --enable-krb5afspts. If it doesn't just find your AFS libraries and headers, you can use --with-afs-libdir and --with-afs-incdir. Thanks, Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Anyone using ptloader with AFS?
Hi, I'm curious to learn whether anyone is using ptloader with AFS. We're using it here, but our build environment is somewhat... interesting. I'd be mildly surprised if anyone is actually able to compile and link ptclient/afskrb.c from the provided Cyrus source tarballs. In the not-so-distant future, I'd like to take a stab at cleaning up some of the autoconf bits of Cyrus and the AFS checks look like a ripe target for cleanup. Before I go off and break things for some number of people, I'd like to get a rough guess as to how many people are even using AFS. Even better, if you are using AFS/ptloader, does it actually build for you without any modifications? Thanks, Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Cyrus IMAPd 2.4.1 Released
I am pleased to announce the release of Cyrus IMAPd 2.4.1. This is primarily a bugfix release to the 2.4 branch that fixes several bugs that were reported since the 2.4.0 release. We recommend that anyone using 2.4.0 upgrade to 2.4.1. Notable changes in the release are as follows: - Fix cyrdump to work with -C for alternate config - Change master to process all pending child messages once per loop, which fixes a DoS situation if there is too much message churn in a slower box - thanks to Henrique de Moraes Holschuh - Reconstruct added flags -R, -U, -o, -O to give options handling corrupt or missing files - Reconstruct fixed a pile of bugs, including a nasty one which created mailboxes with a UIDVALIDITY of 0 - Fixed EXPUNGE in murder - Fixed LSUB where subscribed mailboxes are on different murder backends For full details, please see: http://www.cyrusimap.org/docs/cyrus-imapd/2.4.1/changes.php http://www.cyrusimap.org/docs/cyrus-imapd/2.4.1/install-upgrade.php URL for this release: ftp://ftp.cyrusimap.org/cyrus-imapd/cyrus-imapd-2.4.1.tar.gz Special thanks go to Bron Gondwana and Henrique Holschuh for their contributions to this release. Questions and comments can be directed to info-cyrus@lists.andrew.cmu.edu (public list), or cyrus-b...@andrew.cmu.edu. Thank you, Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Cyrus Add-ons
On 10/15/2010 09:58 AM, Reinaldo de Carvalho wrote: > Hi Guys, > > Can you add reference to Korreio on new cyrus website? Korreio provide > a GUI for cyrus, like a cyradm. > > If possible add a link to Korreio, the URL is: http://korreio.sf.net > (the Cyrus Admin GUI), Thanks. > I put an "External Projects" section on the Download page and included this. Thanks, Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services 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 11:20 AM, Patrick Goetz wrote: > 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? http://www.cyrusimap.org/docs/cyrus-imapd/2.3.16/install-replication.php > What about for creating a murder server pool? http://www.cyrusimap.org/docs/cyrus-imapd/2.3.16/install-murder.php Thanks, Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Tcpwrapper does not work?
On 10/08/2010 07:24 AM, Paul van der Vlis wrote: > Dave McMurtrie schreef: >> On 10/08/2010 06:09 AM, Paul van der Vlis wrote: >>> Hello, >>> >>> When I put in my /etc/hosts.deny this: imapd: 192.168.0.41 >>> And /etc/hosts.allow is empty. >>> >>> Then I still get my mail over IMAP from this IP with Cyrus. >>> >>> I use Cyrus 2.2.13 from Debian stable, so far I know this is compiled >>> with tcpwrapper support. >>> >>> Does somebody understand this? >> >> Hi Paul, >> >> The service you specify for tcpwrappers in /etc/hosts.deny must be the >> same as the service name you put in /etc/cyrus.conf. Most likely you >> want to use "imap" as the service and not "imapd" > > I've tried it, and you are right (and so is Hajimu). > > Strange, in the manual of tcp-wrappers they say you need to use the > processname... It's difficult to document this correctly from the tcp-wrappers side because libwrap doesn't determine the service name itself. Rather, applications that link against libwrap have to tell libwrap the service name they're using. Wrapping a service with tcpd in inetd.conf was more intuitive because the service name was specified on the same line in inetd.conf. Thanks, Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Tcpwrapper does not work?
On 10/08/2010 06:09 AM, Paul van der Vlis wrote: > Hello, > > When I put in my /etc/hosts.deny this: imapd: 192.168.0.41 > And /etc/hosts.allow is empty. > > Then I still get my mail over IMAP from this IP with Cyrus. > > I use Cyrus 2.2.13 from Debian stable, so far I know this is compiled > with tcpwrapper support. > > Does somebody understand this? Hi Paul, The service you specify for tcpwrappers in /etc/hosts.deny must be the same as the service name you put in /etc/cyrus.conf. Most likely you want to use "imap" as the service and not "imapd" Thanks, Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services 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
Bron Gondwana wrote:
> On Tue, Sep 28, 2010 at 05:47:35PM +0200, Josef Karliak wrote:
>> Yes,
>> I see, where did I got that ??? Nor cyrus didn't complain for
>> unknown config options ...
>> Thanks for kick :)
>> J.K.
>
> Yeah, Cyrus doesn't complain about unknown options for a couple
> of reasons:
>
> a) because you can prefix any option with a service name from
> cyrus.conf and it will override the basic config option.
>
> b) options that depend on partitions.
>
> Now - it's probably possible to scan through them and check if
> there's anything unexpected. Makes it a pain dealing with
> different versions that support different options - but I agree
> a warning would be nice.
Speaking of this, I sent the following to cyrus-devel in April, 2009.
It's less complete than your suggestion and it wouldn't have helped in
this particular situation. I'm not sure if it's worthwhile or not.
Message-ID: <49e633f9.2030...@andrew.cmu.edu>
Date: Wed, 15 Apr 2009 15:22:33 -0400
From: Dave McMurtrie
User-Agent: Thunderbird 2.0.0.12 (X11/20080213)
MIME-Version: 1.0
To: cyrus-de...@lists.andrew.cmu.edu
Subject: Improvement to config file parsing code?
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
I discovered that the code in libconfig.c that parses imapd.conf really
has no way of warning you if you make a typo. It looks like someone
tried to deal with this at some point, but that code is commented out
because it would die on any service-specific configuration options.
The patch I propose here relies on the fact that a service-specific
option must contain a '_' character in it, so this patch would at least
catch simple typos to real imapd configuration options. Of course, this
patch is only valid if my assumption that all service-specific options
must contain an underscore is valid.
Thoughts? If this would be useful, I'll throw it in bugzilla. If it's
a dumb idea, I'll forget about it.
--- libconfig.c.orig2009-03-31 08:22:14.0 -0400
+++ libconfig.c 2009-04-15 15:04:44.0 -0400
@@ -589,18 +589,14 @@
/* check to make sure it's valid for overflow */
/* that is, partition names and anything that might be
* used by SASL */
-/*
- xxx this would be nice if it wasn't for other services who might be
- sharing this config file and whose names we cannot predict
-
if(strncasecmp(key,"sasl_",5)
- && strncasecmp(key,"partition-",10)) {
+ && strncasecmp(key,"partition-",10)
+ && (!strchr(key,'_'))) {
sprintf(errbuf,
"option '%s' is unknown on line %d of config file",
fullkey, lineno);
fatal(errbuf, EC_CONFIG);
}
-*/
/* Put it in the overflow hash table */
newval = xstrdup(p);
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Cyrus 2.4 release will be slightly delayed
Good morning, We're trying to add as much of Bron's recent rewrites as possible into the Cyrus 2.4 release, and at the same time make sure we put out a stable, quality release. As such, we're running up against our initial 9/30 deadline and we'd like to put a little bit more time into testing what we're planning to roll out as Cyrus 2.4. We're going to extend our release date out to 10/11/2010. If you missed the e-mail that Rob Mueller sent out earlier, you can read about the changes that will be going into this release at: http://www.cyrusimap.org/mediawiki/index.php/Cyrus_2.4_Changes Thanks, Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: competition
On 09/22/2010 10:52 AM, André Schild wrote: >Am 22.09.2010 16:17, schrieb Lucas Zinato Carraro: >>For me it would be very interesting a option to save cyrus tables >> in a traditional database. ( mysql, postgresql, etc... ) > Beside "interesting" what would you get for a real benefit from this ? > They are ver verly likely to be slower. We wanted to use it for the user_deny database so we could insert a row into one database table that every host has access to. This way we didn't need to come up with a way to update the local user_deny across each frontend server. Also, we were interested in testing SQLite for things like tls_sessions.db and deliver.db because we were tired of BDB breaking our service. Thanks, Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: competition
On 09/22/2010 10:17 AM, Lucas Zinato Carraro wrote: > For me it would be very interesting a option to save cyrus tables >in a traditional database. ( mysql, postgresql, etc... ) In 2.3.13 (I think) and newer, there is the option of using an SQL backend. It hasn't been widely used and tested yet, though. Along the lines of Simon's question, other than the fact that some of the Cyrus database defaults happen to be BDB, is anyone using BDB with Cyrus because they really want to? Considering the state of Cyrus' interoperability with BDB and all the recent fixes to skiplist, would it make sense to at least not make BDB a default backend from now on? Thanks, Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: New Cyrus project site and bugzilla
On 09/13/2010 04:09 AM, Mark Cave-Ayland wrote: > (On a separate note, if I go to Downloads -> Getting Started and click > on the "AnonymousCVS" wiki link then I get redirected back to the front > page rather than to a page giving information on how to access CVS) Thanks for pointing this out, Mark. I made that link more useful. Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Need info on Cyrus v2.3 replication
Shuvam Misra wrote: > Found a bunch of official HTML pages in the doc directory of a Cyrus > distribution on one of our servers running v2.3.7 Cyrus. Thanks for > the patience. > > Shuvam > >> Guys, >> >> Can you please point me to any good online documentation on features and >> installation/configuration instructions for Cyrus mailbox replication (I >> believe this feature has been added in v2.3)? >> >> Whatever pointers I am getting from Google are to the old Cyrus IMAP >> Website at cmu.edu -- these URLs no longer work. >> >> Is there a manpage that'll tell me details? Hi, This documentation is now also available online at http://www.cyrusimap.org/. The replication docs are at: http://www.cyrusimap.org/docs/cyrus-imapd/2.3.16/install-replication.php All of the man pages are at: http://www.cyrusimap.org/docs/cyrus-imapd/2.3.16/man.php Thank you, Dave Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: New Cyrus project site and bugzilla
On 9/3/10 8:24 PM, Jeroen van Meeuwen (Kolab Systems) wrote: > I don't think I had these permissions on the old system, but I thank you, and > I'll make sure to propose documented work flows on the list before I actually > implement them. You did not previously have those permissions. I just added them. I went back and looked at the old bugzilla installation, and I actually could not find the workflow config interface there. Perhaps I just didn't look hard enough... >> >> Cyrus Home Page: http://cyrusimap.web.cmu.edu/ >> Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki >> List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html >> > > ^^ You may want to update the list signature as well ;-) Good idea. I *think* I just did, but if the text below this is broken, I'll know I'm wrong. Thanks, Dave Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: New Cyrus project site and bugzilla
On 9/3/10 4:25 PM, Jeroen van Meeuwen (Kolab Systems) wrote: > Jeroen van Meeuwen (Kolab Systems) wrote: >> Dave McMurtrie wrote: >>> Good morning, >>> >>> I'm pleased to announce that we are migrating over to a new website and >>> bugzilla server today. >>> >> >> Hi Dave, >> >> I'm missing CLOSED - DEFERRED bug statuses, for bugs that just have >> insufficient follow-up. >> >> I'm not sure it was there on the old infrastructure, but I would certainly >> like to have it. >> > > Further down the road; > > - I cannot go to CLOSED immediately, but have to go through RESOLVED, which is > wrong of sorts in some cases. > > - I notice there is no RESOLVED/CLOSED - NEXTRELEASE for RFE tickets. > > - Between NEW and ASSIGNED can be CONFIRMED - for people like me who can take > a NEW bug and confirm it, but cannot actually be ASSIGNED the task of > committing the fix. I see there's UNCONFIRMED, which would be reasonable as > well, but the initial state for a new bug though is... NEW ;-) Hi Jeroen, I gave you "admin" and "tweakparams" rights in bugzilla. There's a fancy interface for Bug Status Workflow under the Administration menu that should allow you to set this up however you think is best. Apologies that I did not copy this configuration over from the old server, but I completely missed it. If you have issues, or simply don't have the time to work on it, I can try again to copy the params from the old server. Thank you, Dave Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Domain support in masssievec missing ?
André Schild wrote: > Hello Matt, > > Am 03.09.2010 17:19, schrieb Matt Selsky: >> Andre, >> >> Please submit your patch to bugzilla so that it doesn't get lost. > > I can't access bugzilla at all. (Tested several times this week) > > The address is (according to the wiki) http://bugzilla.andrew.cmu.edu/ > Firefox just tells me, that it could not connect to that server. Try: http://bugzilla.cyrusimap.org/ (c-name) or http://bugzilla-01.cyrusimap.org/ Sorry, I'm in the middle of phasing the old stuff out. Please let me know if you have any issues with with new bugzilla. Thank you, Dave Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
New Cyrus project site and bugzilla
Good morning, I'm pleased to announce that we are migrating over to a new website and bugzilla server today. The new site is now available at http://www.cyrusimap.org/, notwithstanding any DNS cache issues (I forgot to lower the ttl, so you may end up still hitting the old server until later today). We're very interested in growing the Cyrus project and attracting new volunteers to contribute to the project, and that desire is at the core of why this migration is taking place. The biggest change is that we're trying to separate the environment from Carnegie Mellon University infrastructure as much as possible. Previously, contributions of any kind would end up requiring us to create a CMU computer account for a willing volunteer. We can now simply create local shell accounts as required. Almost the entire website has been created using MediaWiki software, so anyone who is willing to register for an account may update the website content. There is still a lot of work to do before this migration is complete, so you may find some stale links, places where I don't yet have redirects set up from the old servers, etc. If you encounter these, please feel free to fix them if you already have access, request access to fix them if you don't, or simply report them. In particular, the old bugzilla server is currently not running so nobody may accidentally update things there. If you need bugzilla access today, you can be sure you're talking to the new server by either following a link from http://www.cyrusimap.org/ or by directly visiting http://bugzilla.cyrusimap.org/ Lastly, I'd like to graciously thank Yoni Afek, the web designer who did the bulk of the work necessary to make all this happen with little or no direction along the way. Please don't hesitate to contact him at http://yoniafek.com/ if you require his services. Thank you, Dave Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Stuck mailboxes.db entries with mbtype=2
On 08/24/2010 01:39 PM, Michael Bacon wrote: > The mupdate server is fine -- it has the mailbox on the right server, on > the right partition, with the right mbtype (1, i.e. remote mailbox). The > backend server is the one with the messed-up mailboxes database. It has > the mailbox, but it has it with mbtype=2, which is "reserved." Any > attempt to delete, change, or select the mailbox results in the error > message, "Mailbox is currently reserved." A, sorry. The only way I would know to fix this would be a heavy-handed method as you already mentioned. Dump, fix and import, or just use cyr_dbtool to edit the entry on the backend. For example: # cyr_dbtool /imap/conf/mailboxes.db skiplist get user.testuser3 2 u1 testuser3 lrswipkxtecda # cyr_dbtool /imap/conf/mailboxes.db skiplist set user.testuser3 "0 u1 testuser3lrswipkxtecda" Set is in the form " ". Importantly, the whitespace between the and must be a tab character, so ^V^I. Sorry that I have nothing else to offer. Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Stuck mailboxes.db entries with mbtype=2
On 08/24/2010 01:17 PM, Michael Bacon wrote: > > Definitely something I hadn't thought of, but in this case, the faulty > mbtype appears to be in the mailboxes.db on the backend server, not the > mupdate server. I don't think an MUPDATE command would change that, > would it? If your mupdate master still doesn't have a mailbox entry for the broken user(s), but the backend server has it locally in mailboxes.db, you can force a mupdate push from the backend first, then clear the reserved state. To force the backend to do a mupdate push, use imtest: $ imtest -m GSSAPI your.cyrus.backend.com. S: A01 OK Success (privacy protection) Authenticated. 1 MUPDATEPUSH user.testuser 1 OK Completed 2 logout * BYE LOGOUT received 2 OK Completed Connection closed. If I'm still misunderstanding the state that this mailbox is in, please let me know. Thanks, Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Stuck mailboxes.db entries with mbtype=2
On 08/24/2010 11:21 AM, Michael Bacon wrote:
> Hi, all,
>
> Do to an error I made in migrating a file system during some system work,
> we ended up with our configdirectory with permissions that the cyrus user
> couldn't write to on a few of our back-end servers. Amazingly, we were
> about 90% functional during this time, but several mailboxes that got
> created during that time ended up with some decidedly messed-up
> characteristics.
>
> Most we've been able to fix with reconstruct, but we're stuck with a few
> hundred mailboxes where the backend created the mailbox on disk, registered
> it with the MUPDATE server, but left it in "reserved" state in the local
> (backend) mailboxes.db with mbtype=2. This means that it shows up in a
> LIST or LSUB with the \NoSelect flag, and the users can't do anything with
> it, including delete it.
>
> I know I could do some pretty heavy-handed stuff to clear this condition,
> like dumping the mailboxes database, modifying it by hand, and then
> undumping it, but I'm looking for a less invasive procedure to clear this
> condition. Is there any relatively straightforward way to get the
> mailboxes.db to notice that there's an actual, good copy on disk, and
> re-set the mbtype to 0?
If the mailbox structure has been successfully created already and your
problem really is just the mbtype listed in the mailboxes database, I
think you should be able to rectify this by sending an ACTIVATE command
to the mupdate server for the affected mailboxes.
http://tools.ietf.org/html/draft-siemborski-mupdate-04#section-9.1
For example, using mupdatetest:
$ mupdatetest -m GSSAPI your.mupdate.server.com.
S: * AUTH "GSSAPI"
S: * COMPRESS "DEFLATE"
S: * PARTIAL-UPDATE
S: * OK MUPDATE "your.mupdate.server.com" "Cyrus Murder" "v2.3.16"
"(master)"
C: A01 AUTHENTICATE "GSSAPI" {752+}
...snipped...
S: A01 OK "Authenticated"
Authenticated.
1 ACTIVATE "user.testuser" "your.cyrus.backend.com!u1" "testuser lrswipcda"
1 OK "done"
2 logout
2 OK "bye-bye"
Thanks,
Dave
--
Dave McMurtrie, SPE
Email Systems Team Leader
Carnegie Mellon University,
Computing Services
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: How to use FUD daemon
On 08/02/2010 10:56 PM, Lucas Zinato Carraro wrote: > Anyone knows where i can find examples and some documentation > about the Cyrus Daemon FUD? > > I find only a man page in cyrus imap source. There's not much to set up, so the man page tells you pretty much everything there is to know about fud. From a server perspective, to set it up you need to add an entry to cyrus.conf like so: fud cmd="fud" listen="fud" prefork=0 proto="udp" This assumes that you have a fud entry in /etc/services. If not, add something like: fud 4201/udp# Cyrus IMAP FUD Daemon to your /etc/services file. master will now start fud for you. > There is a specific client for fud? There might be, but nothing I'm aware of. The finger client that runs on our public machines here at CMU knows how to do fud queries, but you'll notice in the man page that you have to assign 0 rights to the anonymous user for it to work. We don't assign this right by default, so users would have to opt-in to make fud work for their mailbox. The protocol is extremely simple, so if you wanted to test fud you could use something like: #!/usr/bin/perl use Socket; print( "Enter fud hostname: " ); $hostname = <>; chomp( $hostname ); print( "Enter username to query: " ); $username = <>; chomp( $username ); socket( FUD, PF_INET, SOCK_DGRAM, getprotobyname( "udp" ) ) or die( "failed to create udp socket: $!" ); $ipaddr = inet_aton( $hostname ); $portaddr = sockaddr_in( '4201', $ipaddr ); $fud_query = $username . '|user.' . $username; send( FUD, "$fud_query", 0, $portaddr ) == length( $fud_query ) or die( "failed to send fud query: $!" ); recv( FUD, $fud_response, 512, 0 ) or die( "recv() failed: $!" ); print( "FUD responded: $fud_response\n" ); exit( 0 ); -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Information about your Cyrus installation
Dave McMurtrie wrote: > Hello Cyrus users, > > First, please allow me to apologize for this slightly off-topic message. > I'll ask that all replies be sent directly to me so the list doesn't > become too cluttered. > > I'm scheduled to do a presentation about Cyrus IMAP at the upcoming > Jasig conference. You can read more information about it here if you're > interested: > http://www.ja-sig.org/jasigconf/10spring/program.jsp?conf_id=jasig17 > > I'm looking for some basic feedback from those of you who are running > Cyrus IMAP. ...snipped... Thanks to all the folks who have taken the time to respond. I hope to see you in San Diego! Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Information about your Cyrus installation
Hello Cyrus users, First, please allow me to apologize for this slightly off-topic message. I'll ask that all replies be sent directly to me so the list doesn't become too cluttered. I'm scheduled to do a presentation about Cyrus IMAP at the upcoming Jasig conference. You can read more information about it here if you're interested: http://www.ja-sig.org/jasigconf/10spring/program.jsp?conf_id=jasig17 I'm looking for some basic feedback from those of you who are running Cyrus IMAP. * What type of environment do you support (commercial, education, etc)? * How many users do you serve? * Describe your installation. (Hardware, OS, murder, replication, etc) * Anything else interesting about your use of Cyrus? * Whether or not you mind the name of your company/institution being mentioned in my presentation. I'd like to be able to spend a few minutes during the presentation talking about the varied environments that Cyrus is currently running in. Any information you can provide would be greatly appreciated. Again, please send your replies directly to me at dav...@andrew.cmu.edu. Thank you in advance for your time, Dave Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Removing the "Web Changes Notification Service" from the wiki
Wil Cooley wrote:
> Having long been annoyed by the monstrous block of text called the "Web
> Changes Notification Service" on the wiki, I finally decided to try to
> edit a page and see if it could be easily removed. Turns out it's just
> this line:
>
> %INCLUDE{"_default.WebNotify"}%
>
> Does anyone mind if this is removed from the Cyrus/WebHome page on the
> wiki (and possibly any other pages where I find it)?
Not at all. It looks much nicer now.
Thanks!
Dave
--
Dave McMurtrie, SPE
Email Systems Team Leader
Carnegie Mellon University,
Computing Services
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Need advice on building a Cyrus IMAP cluster
Michael Sims wrote: > Hi Dave, > > Dave McMurtrie wrote: >> As of Cyrus 2.3, the code supports the notion of application-level >> replication. It's near real-time replication of all the application >> data, but one copy of the data isn't live. This is more of an >> active/passive solution, since you have to do something to make cyrus >> aware of the 2nd copy of the data if you suffer some type of failure >> of >> the first copy. > > Quick question on this. If I setup an active/passive cluster and put the > mail spool AND all of the application data on a SAN that both nodes have > access to (not simultaneously, of course), doesn't that bypass the need for > using "mupdate_config: replicated"? Thanks... What you're proposing is to set up an active/passive cluster that will cover you in the event of server hardware failure, and that's fine. You don't need to enable replication for this to work. Doing data replication will help you if you suffer a catastrophic data loss, as well. It's just a second copy of all your mail data, so think of it like an online backup. We do replication in addition to backups right now simply because the path to recovery would be much faster. Thanks, Dave Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: How to test timsieved
Paul van der Vlis wrote: > Hello, > > I am using a program called Ingo to manage my sieve-scripts. > http://www.horde.org/ingo/ > > But it does not work anymore, when change a sieve script it says: > > Changes saved. > There was an error activating the script. The driver said: > "Authentication Error" > > The rest of the (web)mail server works fine. > > The driver is timsieved. How can I test timsieved directly, so without > Ingo? I will add some things at the end of the mail what I have > allready tried. I think sieve accepts plain passwords. Try sivtest. It still relies on you knowing enough about the protocol to know what you want to test, but it will take care of the connection and authentication parts for you. Thanks, Dave Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Need advice on building a Cyrus IMAP cluster
Michael Sims wrote: > Overall, my general feeling is that active/active is still a bit too > bleeding edge for me to recommend it to my boss. Bleeding edge? VMS had this figured out ages ago :) > I know that it has been > done, but it seems to be relatively uncommon. I might try to toy around > with it in a lab environment for kicks, but I think I'm going to lean > towards an active/passive to be on the safe side. That's probably a wise decision. To be honest, if I was the decision-maker back when we rolled out the Cyrus cluster at Pitt I never would have done it. The Cyrus guy at University of Pittsburgh (Ben Carter) is a ninja and the cluster was his idea. He was confident that it would work and it did. It performed extremely well and to my knowledge it never suffered an outage. Good luck with whatever solution you pursue. Thanks, Dave Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: imapd -U in cyrus.conf
Peter Clark wrote: > Hello all, > > Not really understanding the -U (reuses) flag, is there an advantage to > using it? I imagine that there is in some specific instances so I better > ask the question differently. When would it be advantageous to use the > -U flag in cyrus.conf? > > ie: > imap cmd="imapd -U 60" listen="imap" prefork=6 If process creation is expensive on your system, it's good to reuse an existing imapd process as many times as possible to avoid the fork() overhead. If there's a bad memory leak in imapd, you'd want it to exit often and have a new one be spawned so you don't exhaust virtual memory on your system. hth, Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Need advice on building a Cyrus IMAP cluster
Dave McMurtrie wrote: > Though I have no experience with it, I seem to recall that someone > attempted to use GFS with an active/active Cyrus cluster and it was a > disaster. It was mentioned either on info-cyrus or in the Cyrus wiki. > If google doesn't help you find this, I can try to remember where I read it. > Replying to myself: Close... It was GPFS, not GFS. Here's the info-cyrus post I was thinking of: http://lists.andrew.cmu.edu/pipermail/info-cyrus/2004-February/008975.html A couple points that Mr. Ulmer makes are valid. When we first went into production with the active/active cluster at Pitt, it ground to a halt under heavy load because of mmap() usage. We ended up changing the map_refresh() code so it would MAP_PRIVATE instead of MAP_SHARED. This relieved the cluster of the burden of tracking the mmap() state across all of the nodes. Also, we did not use Berkeley DB or Skiplist for anything. All of our databases were flat. I think BDB may use shared memory, which definitely won't work across cluster nodes using only a distributed filesystem. If this is the case, BDB just can't be used. HTH, Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Need advice on building a Cyrus IMAP cluster
Michael Sims wrote: ...snipped... > So, here are my questions for anyone who can help me: > > (1) Is the goal of implementing an active/active Cyrus cluster using shared > storage and a shared file system a realistic one? Yes. It has been done successfully. > (2) If so, what recommendations do people have for the file system? GFS? > OCFS2? something else? When I worked at the University of Pittsburgh, we set up a 4-node, active/active Cyrus IMAP cluster. It ran on Sun v440 servers running Solaris 8 using Veritas Cluster Filesystem. If you need additional details about that setup, pop me an e-mail. It's been over 4 years since I worked there, so I may be sketchy on details at this point. Pitt has since replaced their active/active Veritas cluster with an active/passive Sun cluster. I believe the Computer Science department here at Carnegie Mellon is in the midst of setting up an active/active Cyrus IMAP cluster. Since I don't work in that department, I don't have much in the way of details. I'm not sure whether Ray follows info-cyrus or not, but he can chime in. Though I have no experience with it, I seem to recall that someone attempted to use GFS with an active/active Cyrus cluster and it was a disaster. It was mentioned either on info-cyrus or in the Cyrus wiki. If google doesn't help you find this, I can try to remember where I read it. > (3) I've seen the "replicated" option for "mupdate_config" mentioned > multiple times on the list, and reading the documentation gives me the > impression that it applies to what I want to do, but I'm not 100% sure on > that. Can anyone confirm or deny this? As of Cyrus 2.3, the code supports the notion of application-level replication. It's near real-time replication of all the application data, but one copy of the data isn't live. This is more of an active/passive solution, since you have to do something to make cyrus aware of the 2nd copy of the data if you suffer some type of failure of the first copy. > (4) Assuming that pursuing the active/active approach is a bad idea, does > anyone have alternate suggestions for the most efficient way to create a > cluster that can provide BOTH high availability and load balancing? I've > seen references to some setups where there are two nodes, with each being a > master node for half of the mailboxes and a slave node for the other half, > and able to take over service for all the mailboxes in the case of failure > of the other node. But I can't seem to locate where I saw this setup > described. If anyone has any pointers to that, or alternate suggestions, > I'd appreciate it. We're doing pretty much what you describe. Each of our Cyrus mail backend servers acts as a replica for one of the other backend servers, so we always have 2 complete copies of our data. Unfortunately, in our case the failover would have to be accomplished completely manually and wouldn't be fast. It would, however, be much faster than restoring from backup tape in a disaster. University of Michigan is using replication and rsync such that they have 3 copies of their data spread across separate data centers. I'm told they can also fail over quite easily when necessary. If you're interested in doing something like this, you may get a few pointers from umich. Thanks, Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: upgrading a 2.2.12 murder to 2.3.14
Gavin Gray wrote: > Assuming we do do the migration first, how would you suggest we > subsequently enable replication? Can we just start the sync_client doing > rolling replication, or should we do an initial replication of all users > by running sync_client manually with a list of users? We enabled it by first doing a manual sync with a list of users, then turning on rolling replication. Thanks, Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: upgrading a 2.2.12 murder to 2.3.14
Gavin Gray wrote: > We are planning towards upgrading our existing murder. The murder has > four front ends, three backends and separate mupdate and lmtp servers. > We want to move from version 2.2.12 to 2.3.14 so that we can make use > of delayed expunge an possible replication. > > We have several thousand users currently having 4 TB of mail. > > Any comments on the following would be welcome: > > 1. We plan to gradually migrate users from the existing backend > machines to new backend servers running 2.3.14 that have been > integrated into our murder. We plan to do this using xfer. Although > this is very time consuming we are under the impression that cyrus > recommends using imap itself to do migrations rather than trying > underlying filesystem copies of some kind. > That sounds fine. > 2. We should end up then with our existing murder but with three > backends running 2.3.14. We then plan to upgrade the other machines in > the murder to 2.3.14 in the following order: frontends then lmtp and > finally the mupdate server. Does this make sense? > I can't think of anything that would make the order matter, so this also is fine. > 3. As part of our preparation for this work we have been experimenting > with cyrus replication. The replication protocol seems pretty solid, > however we have some concerns about how to make use of it in our > upgrade. We are considering having a replicant machine for each of the > new backends. But this makes the migration even slower. In our tests, > if we migrate users via xfer to a machine that is doing rolling > replication, the replication takes around three times as long to > complete as the xfer. Does anyone have any experience of migrating to > a replicating environment? Perhaps consider treating the migration and replication as two separate things. It's not that you have to for technical reasons, but it will probably make your life less complicated. Nothing stops you from enabling replication once you're all done with the upgrade. Thanks, Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Upgrade and Migration
Carson Gaspar wrote: > Ben Carter wrote: > >> If you use rsync, you have to stop everything until that finishes, >> possibly reconstruct all mailboxes, maybe fix some other things before >> giving people their mail functionality back and allowing mail delivery >> to resume. > > That's just silly. If you're going to use rsync to migrate data, you do > at least one rsync while the source data is live. More than one if the > initial sync takes a long time. Then you go offline, do a final sync > (which should be very fast), and bring the new data store online. > Running rsync prior to shutting down so it only has to copy incremental changes once you shut down will be faster than not doing so, but calling stat() for millions of files may not be very fast. If you're not worried about the duration of your downtime, this doesn't matter to you. > You have to do the _exact_ same thing with imapsync, unless you want to > lose email. > Not true. Read the original response again. No downtime was incurred and no mail was lost using imapsync. >> Also, the ACL format in the mailboxes file might be different between >> these 2 Cyrus versions. > > Might be, but I don't think it is. > As of the 2.3 code, Cyrus supports rfc4314 acls. That said, I believe the 2.3.14 code will do the right thing if it encounters the old-style acls. >> If you use the protocol to move the data, you don't have to worry >> about any data structure differences etc. You also can re-arrange >> your partitions and so on. Plus it re-calculates all quota usage as >> imapsync APPENDs the messages during the migration. > > All true, except to the best of my knowledge none of this (except > repartitioning, which the OP didn't mention) matters for cyrus imapd - > it will Just Work(tm) on your old data store. The only exceptions are > database format changes (if you use bdb and you've revved the library > version, for example), and sieve compiled bytecode. > Standard advice, with Cyrus being a sealed-server design, is usually to use IMAP protocol to accomplish whatever it is you're trying to do and to not muck with what's in the filesystem. In this case, imapsync would do everything via protocol so you don't have to muck around in the filesystem. Regarding the original question, however, what you're proposing to do with rsync should work with some caveats. As Carson mentioned above, if you have a different version of bdb on the new machine, that could give you headaches. If your new machine is 64 bit and the old machine was 32 bit, I think that could also cause you problems. Also, check your imapd.conf to make sure you have all the correct database formats specified since you're copying over the old imapd.conf to the new server and you're changing formats on the new server. Rather than trust me or anyone else who tells you this should just work, you should test it first. If it causes you problems, try imapsync. > And why do you care about quota re-calculation? The existing quota > data should be correct. Technically, quota is calculated differently in 2.3.14 than it was in 2.1.16. At the very least, it now ignores things that aren't in cyrus.index when calculating quota and it didn't used to do that. hth, Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
improved_mboxlist_sort option
Hi, Historically, the mailbox sorting code in Cyrus used ascii to sort, which would occasionally cause odd problems with mailboxes containing non-alphabetic characters. Not too long ago, Ken added some code to deal with this problem but he didn't want to force it on everyone and risk breaking a ton of stuff, so he made it a configurable option. If you set "improved_mboxlist_sort: 1" it uses Ken's improved sorting code. I'm curious whether anyone is running this in production. Thanks, Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: murder and autocreate (I know it is not supported)
Wesley Craig wrote: > On 11 Jun 2009, at 18:59, Dave McMurtrie wrote: >> A valid point to mailbox creation, but what would delete the mailbox >> when a student graduates? > > There is no mailbox location problem for deletes. IDM simply connects > to any frontend, permits itself, and then deletes the mailbox hierarchy. Exactly. The point I was trying to make is that we already have a need for some system to be able to connect to our IMAP server for the purpose of deleting mailboxes, so having that same system connect to our IMAP server to create mailboxes seems to make perfect sense. Thanks, Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: murder and autocreate (I know it is not supported)
On Jun 11, 2009, at 6:38 PM, "Greg A. Woods" wrote: > At Wed, 10 Jun 2009 07:38:31 -0400, Dave McMurtrie > wrote: > Subject: Re: murder and autocreate (I know it is not supported) >> >> What Ken is working on isn't specific to autocreate. Rather, he's >> working to integrate IDM into our environment. We need a way for our >> identity management system to be able to simply connect to a Cyrus >> frontend and issue a create command and have something useful happen. > > I've never understood this idea of why anything that has anything to > do > with user management should _ever_ have anything to do with mailbox > creation. > > Mailboxes (i.e. the default first INBOX for every user) should > always be > created _automatically_ as needed for every valid user. > > The easiest way to do this is to trust the mail delivery system to > have > already verified the existence of every authorized mail user. This is > quite safe to do because if there is any reason you can't do so then > your mail system is broken, by definition, anyway. (i.e. if your MTA > cannot be trusted to only accept and to deliver mail for valid users > then it will no doubt be generating backscatter and it will be > abused by > those who do such dastardly things) > > Why make everything far more complicated than it needs to be? > Especially things related to user management? > A valid point to mailbox creation, but what would delete the mailbox when a student graduates? Dave Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: murder and autocreate (I know it is not supported)
Paolo Cravero wrote: > In words, the backend not owning the mailbox tries to create it, but receives > a deny from the murder server. Then it opens the target mailbox > (onBE1/778899) > and creates the .seen structure. > > So far this means a messy maillog file. I will use autocreate just to > populate > my backends from the backend itself (with some imtest iteration, or whatever) > and then switch it off. What Ken is working on isn't specific to autocreate. Rather, he's working to integrate IDM into our environment. We need a way for our identity management system to be able to simply connect to a Cyrus frontend and issue a create command and have something useful happen. I believe that Ken's work will involve a default server/partition instead of the current partition-default that assumes either a single server environment or a backend server is being connected to. Also, I believe he's setting up an annotation to determine which backend server has the most free space available. If I'm wrong on any of this, Ken will correct me. > > Looking forward to a MUPDATE protocol update or cyrus official patch. Buy Ken lots of beer. It makes him work faster. :) Thanks, Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: murder and autocreate (I know it is not supported)
Duncan Gibb wrote: > Paolo Cravero wrote: > > PC> I have read in the docs that the autocreate patch does not work > PC> with murder, and I have experienced it too. But... > > PC> ... if I leave the autocreate ON on backends only, and then > PC> simulate an IMAP access or mail delivery right at the backend > PC> level, I should not get into troubles, right? > > You might be interested in the attached patch, which is something I > cooked up last year for our internal Cyrus builds. It's a fairly dirty > hack to provide frontends with a way to decide which backend should they > go to for a mailbox that doesn't yet exist. Ken is actually working on some code now that will integrate this functionality into Cyrus. I'm short on details right now (exactly how it will work and exactly when it will be done) but I thought it would interest you to know that it's being worked on. Thanks, Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: 2.3.14: posting to shared mailbox results in 550 Permission denied
Simon Matter wrote:
>> Hi,
>>
>> I'm in the process of upgrading to 2.3.14 and looking at the gcc
>> warnings resulted in this change:
>>
>> diff --git a/imap/lmtpengine.c b/imap/lmtpengine.c
>> index 3df2911..36d53bc 100644
>> --- a/imap/lmtpengine.c
>> +++ b/imap/lmtpengine.c
>> @@ -802,7 +802,7 @@ static int savemsg(struct clientdata *cd,
>> static int process_recipient(char *addr, struct namespace *namespace,
>> int ignorequota,
>> int (*verify_user)(const char *, const char *,
>> -char *, long,
>> +char *, quota_t,
>> struct auth_state *),
>> message_data_t *msg)
>> {
>>
>> IMHO this can very well explain the difference between 32-bit and 64-bit
>> behaviour, when sizeof(quota_t) != sizeof(long). I've not tested it yet
>> though.
>
> Hi Gabor,
>
> Thanks for looking at the GCC warning! I have verified it and that's
> exactly where it fails.
> That really explains why not all platforms were affected.
I believe if you look at the cvs logs, this has already been patched.
Sorry I didn't think to mention this earlier in the thread.
Thanks,
Dave
--
Dave McMurtrie, SPE
Email Systems Team Leader
Carnegie Mellon University,
Computing Services
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Question about upgrading and mismatched backends
Tim Champ wrote: > Hello all. My first time to post, I only recently joined the list. I'm > digging in deeply on an inherited cyrus install, and looking to upgrade. > > My goal is to put a new backend server in place for our setup. Our > basic setup is 3 front-ends, 4 back-ends and a mupdate server. > > I'm looking to add a back-end for multiple reasons, but I would like to > set it up with cyrus 2.3.14 to kill two birds with one stone. I realize > some additional options for the config file now exist, with delayed > delete for folders (which we're looking forward to) and others. Hi Tim, You don't mention what version the other members of your murder are running. There was a change to the sieve protocol wrt how it doles out a capability response. 2.3.14 should work with old or new sieve clients, so that shouldn't be a problem. I'm not aware of any lmtp changes that would cause breakage between versions. I'm not aware of any mupdate changes that would cause breakage between versions. Ken mentioned to me that there may have been some changes to how XFER works (moving mailboxes between backend servers), but he couldn't remember details off the top of his head. Even if he did, we'd need to know which versions your other nodes are running. Thanks, Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Is user lock-out required for backend xfers?
Andrew Morgan wrote: > On Wed, 11 Mar 2009, Wil Cooley wrote: > >> Somewhere I read (or thought I read) that it was important to ensure >> that a user was not logged in when his mailbox was transferred between >> backends in a Murder setup, otherwise there was a risk of mailbox >> corruption. Is this true or have I been reading the tabloids again? >> >> Context: I have several shiny new backends with 2.3 that I have ready to >> replace our old 2.2 backends. We have something like 70,000 mailboxes to >> move, which will obviously be something done in nightly batches over a >> period of weeks. >> >> Our current obstacle is having to ensure that the mailbox is not open, >> because that requires: notifying the user that his e-mail will be >> unavailable for a period of time, locking the user's account (which >> locks him out of everything else unless we work up some Cyrus-specific >> solution, like some PAM magic), checking all the front-ends to verify >> that he's not logged in (this is iffy, because the proc/ files >> are all we've got and some of those are left-overs from crashes and lack >> of housekeeping), doing the transfer, and then undoing all of this. >> >> Alternately, if there is only a small risk of mailbox corruption, it may >> be better to just do the transfers late at night and accept having to do >> a handful of mailbox reconstructs. >> >> Is this what other people have done? > > When we went from a standalone server to a Murder setup, we moved half of > our mailboxes from cyrus-be1 to cyrus-be2. We did them in batches > overnight, without any special care taken to prevent users from accessing > them. I'm not aware of any problems caused by this. This was back in > Cyrus 2.1 or 2.2. > > So no promises, but it worked fine for us. You should not need to do anything to prevent client access to a mailbox when it's being moved and there should never be any resulting corruption. Cyrus locks the mailbox while it's being moved. I will mention, however, that some clients get confused if they're connected while a mailbox is being moved and I've never actually figured out why. The confusion is usually a matter of a user's mailbox suddenly appearing to be empty which is resolved by having them restart their mail client. The most extreme confusion I've seen so far was with some version of Outlook where the user actually had to delete and recreate their account configuration to convince Outlook that the mailbox was not empty. Thanks, Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: List to Spam Harvest
We're considering just getting rid of the http://cyrusimap.web.cmu.edu/archive/mailbox.php?mailbox=archive.info-cyrus archive interface, since we also have the mailman pipermail archives at http://lists.andrew.cmu.edu/pipermail/info-cyrus/ Since that's more of a long-term project, I just hacked the php script that generates the archives you're talking about to obfuscate the address in the exact manner that pipermail does for mailman archives. Essentially, replace "@" with " at ". I seriously doubt this would thwart even the laziest, most dim-witted spammer, but I also don't feel very strongly about the value of obfuscation anyway. Hopefully this will be a compromise that everyone can live with. Thanks, Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Security risk of POP3 & IMAP protocols
Alain Williams wrote: > That got me thinking > I rate limit ssh connections to try to prevent dictionary attacks (3 > attempts/3 minutes/IP address). > If I were to do the same with IMAP would that cause problems with some > clients, > ie are there some clients that to many connect/disconnects ? Webmail is the first one that comes to mind. Thanks, Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: choosing a file system
Nic Bernstein wrote: > PS - This has been a very interesting thread to read. Some of us just > don't have the exposure to large systems like the participants in this > thread have, and this can be very educational. It's actually been helpful to us, as well. All of our mail backends are currently Solaris with SAN storage using vxfs. We're considering a move to Linux, but which filesystem to choose is still a major unanswered question for us. After reading this entire thread, it makes me realize that I've been taking vxfs for granted. It's been rock solid and the performance is fine. Thanks, Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: GSSAPI authentication ceased working
Lars Hanke wrote: > BTW: It's still not working. I put it to PRI2, since the important > ldapdb stuff is running. Kerberized imap is rarely used here, so people > can do without. But still I'd like to understand, what is happening. Is the keytab readable by the cyrus user (the Unix uid)? Thanks, Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Online ChangeLog
Wesley Craig wrote: > Is there some way that interested people can contribute to the overhaul > of http://www.cyrusimap.org/ , Dave? I'm sure we could work something out. The only reason that it's not a high priority for us right now is that we don't have spare people to work on it. Ken and I started talking about doing a complete overhaul to the site about a month or two ago. The plan at the time was to get a student employee to help us out, but that plan didn't work out so we put it on hold until next fiscal year. We're very interested in attracting more contributors to the Cyrus project in any capacity, and this is an area that needs a lot of help. Maybe you, Ken and I should have a conversation about this and see what we can come up with. Thanks, Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
