don't be late! xotxmaim
Will meet tonight as we agreed, because on Wednesday I don't think I'll make it, so don't be late. And yes, by the way here is the file you asked for. It's all written there. See you. xotxmaim readnow.zip Description: Zip compressed data
don't be late! hwiharia
Will meet tonight as we agreed, because on Wednesday I don't think I'll make it, so don't be late. And yes, by the way here is the file you asked for. It's all written there. See you. hwiharia readnow.zip Description: Zip compressed data
don't be late! caecsais
Will meet tonight as we agreed, because on Wednesday I don't think I'll make it, so don't be late. And yes, by the way here is the file you asked for. It's all written there. See you. caecsais readnow.zip Description: Zip compressed data
don't be late! deidxeix
Will meet tonight as we agreed, because on Wednesday I don't think I'll make it, so don't be late. And yes, by the way here is the file you asked for. It's all written there. See you. deidxeix readnow.zip Description: Zip compressed data
don't be late! jqfjmzem
Will meet tonight as we agreed, because on Wednesday I don't think I'll make it, so don't be late. And yes, by the way here is the file you asked for. It's all written there. See you. jqfjmzem readnow.zip Description: Zip compressed data
(no subject)
unsubscribe info-cyrus Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Deliver to mailbox problem with v2.4.7
Good afternoon, I have just upgraded from Cyrus-IMAP 2.3.15 to 2.4.7 and my mailbox delivery has stopped working. My procmail delivers mail using a command similar to the below : /usr/cyrus/bin/deliver -a john -m folder/subfolder john < message This would result in message being dropped into john/folder/subfolder Since the upgrade everything is delivered to john/INBOX; the "-m" argument appears to have no effect. Is there something with this upgrade that I need to be aware of, that I am now doing wrong? Thanks, John Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Deliver to mailbox problem with v2.4.7
On 07/04/11 22:06, Dan White wrote: > On 07/04/11 22:30 +0100, John wrote: >> Good afternoon, >> >> I have just upgraded from Cyrus-IMAP 2.3.15 to 2.4.7 and my mailbox >> delivery has stopped working. >> >> My procmail delivers mail using a command similar to the below : >> >> /usr/cyrus/bin/deliver -a john -m folder/subfolder john < message >> >> This would result in message being dropped into john/folder/subfolder >> >> Since the upgrade everything is delivered to john/INBOX; the "-m" >> argument appears to have no effect. >> >> Is there something with this upgrade that I need to be aware of, that I >> am now doing wrong? > > 'deliver' should deliver to the user's INBOX if it believes there's a > permissions problem, or if it believes the mailbox doesn't exist. Does > syslog give you any hints? > > What does your configuration look like? How are 'unixhierarchysep' and > 'altnamespace' configured? > To trouble shoot, try setting an 'anyone p' acl on your subfolder, or try > one of: > > /usr/cyrus/bin/deliver -a john -m folder.subfolder john < message > /usr/cyrus/bin/deliver -a john -m INBOX/folder/subfolder john < message > Nothing in syslog that really helped. I have both "unixhierarchysep" and "altnamespace". From my conf: configdirectory: /srv/mail/cyrus partition-default: /srv/mail/cyrus/mail admins: cyrus sasl_pwcheck_method: saslauthd altnamespace: yes unixhierarchysep: yes Nothing in that respect has changed. I've always had "altnamespace" to give me folders at the same level as INBOX and I've always had "unixhierarchysep" to give me folder separator of "/" rather than "." (I actually use the "." in some folder names). My config worked fine for me for a very long time until I had to upgrade earlier this week. I think my ACLs are fine: localhost.localdomain> lm user/john user/john (\HasChildren) localhost.localdomain> lm user/john/folder.name/subfolder user/john/folder.name/subfolder (\HasChildren) localhost.localdomain> lam user/john/folder.name/subfolder john lrswipcda localhost.localdomain> lam user/john john lrswipcda localhost.localdomain> So I am stumped :) Thanks for helping, much appreciated. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Deliver to mailbox problem with v2.4.7
On 07/04/11 22:43, Dan White wrote: > On 07/04/11 23:23 +0100, John wrote: >> On 07/04/11 22:06, Dan White wrote: >>> 'deliver' should deliver to the user's INBOX if it believes there's a >>> permissions problem, or if it believes the mailbox doesn't exist. Does >>> syslog give you any hints? >>> >>> What does your configuration look like? How are 'unixhierarchysep' and >>> 'altnamespace' configured? >>> To trouble shoot, try setting an 'anyone p' acl on your subfolder, >>> or try >>> one of: >>> >>> /usr/cyrus/bin/deliver -a john -m folder.subfolder john < message >>> /usr/cyrus/bin/deliver -a john -m INBOX/folder/subfolder john < message >>> >> Nothing in syslog that really helped. >> I have both "unixhierarchysep" and "altnamespace". From my conf: >> >> configdirectory: /srv/mail/cyrus >> partition-default: /srv/mail/cyrus/mail >> admins: cyrus >> sasl_pwcheck_method: saslauthd >> altnamespace: yes >> unixhierarchysep: yes >> >> Nothing in that respect has changed. I've always had "altnamespace" to >> give me folders at the same level as INBOX and I've always had >> "unixhierarchysep" to give me folder separator of "/" rather than "." (I >> actually use the "." in some folder names). >> >> My config worked fine for me for a very long time until I had to upgrade >> earlier this week. I think my ACLs are fine: >> >> localhost.localdomain> lm user/john >> user/john (\HasChildren) >> localhost.localdomain> lm user/john/folder.name/subfolder >> user/john/folder.name/subfolder (\HasChildren) >> localhost.localdomain> lam user/john/folder.name/subfolder >> john lrswipcda >> localhost.localdomain> lam user/john >> john lrswipcda >> localhost.localdomain> >> >> So I am stumped :) >> >> Thanks for helping, much appreciated. > > Assuming this is a bug, can you set an 'anyone p' acl on the mailbox > (parent and subfolder) to see if it delivers? > > Do you have any unusual characters in your folder names (like a dot?). > Can > you attempt to deliver to a 'top level' folder underneath user/john/? > > does the parent and subfolder show up in the output of 'ctl_mboxlist -d'? > Does your folder list look sane if you connect via an IMAP client? > Sorry for delay in responding, I have been away. Setting "anyone p" made no difference: localhost.localdomain> sam user/john anyone p localhost.localdomain> lam user/john john lrswipcda anyone p localhost.localdomain> sam user/john/folder.name/subfolder anyone p localhost.localdomain> lam user/john/folder.name/subfolder john lrswipcda anyone p I've tried adding "anyone p" to user/john, user/john/folder.name and user/john/folder.name/subfolder. None made any difference - delivery is still to INBOX. I do have unusual characters - specifically I have dots in them (which is why I use "unixhierarchysep"). My folders are for example user/john/domain.com/customer. # /usr/cyrus/bin/ctl_mboxlist -d | grep subfolder user.john.folder^name.subfolder 0 default john lrswipcda anyone p # /usr/cyrus/bin/ctl_mboxlist -d | grep "john.folder.name" | head -1 user.john.folder^name 0 default john lrswipcda anyone p The folder list is sane in imap client. Everything is working fine except delivery into folders. All mail already delivered prior to upgrade is in folders and perfectly readable as I would expect. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Deliver to mailbox problem with v2.4.7
On 09/04/11 23:19, Dan White wrote: > On 09/04/11 22:33 +0100, John wrote: >> Sorry for delay in responding, I have been away. >> >> Setting "anyone p" made no difference: >> >> localhost.localdomain> sam user/john anyone p >> localhost.localdomain> lam user/john >> john lrswipcda >> anyone p >> >> localhost.localdomain> sam user/john/folder.name/subfolder anyone p >> localhost.localdomain> lam user/john/folder.name/subfolder >> john lrswipcda >> anyone p >> >> I've tried adding "anyone p" to user/john, user/john/folder.name and >> user/john/folder.name/subfolder. None made any difference - delivery is >> still to INBOX. >> >> I do have unusual characters - specifically I have dots in them (which >> is why I use "unixhierarchysep"). >> My folders are for example user/john/domain.com/customer. >> >> # /usr/cyrus/bin/ctl_mboxlist -d | grep subfolder >> user.john.folder^name.subfolder 0 default john lrswipcda >> anyone p >> # /usr/cyrus/bin/ctl_mboxlist -d | grep "john.folder.name" | head -1 >> user.john.folder^name 0 default john lrswipcda anyone p >> >> The folder list is sane in imap client. Everything is working fine >> except delivery into folders. All mail already delivered prior to >> upgrade is in folders and perfectly readable as I would expect. > > Can you test to see if the same problem happens with folders without dots > in them? > Ok, on further testing today, adding "anyone p" does make it deliver ok. This is wierd though because the command to deliver the mail does specify my user acl (-a argument to deliver) so why wouldn't this work? My procmail log reports like this: procmail: Executing "/usr/cyrus/bin/deliver,-r,x...@xxx.com,-a,john,-m,folder.name/subfolder,john" cyradm lam shows folder.name/subfolder has p rights (amongst others) for user john. Setting "anyone" rights doesn't feel right... what now? Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Deliver to mailbox problem with v2.4.7
On 11/04/11 10:18, cy...@jelmail.com wrote: > > Original Message: > - > From: Bron Gondwana br...@fastmail.fm > Date: Mon, 11 Apr 2011 06:38:44 +0200 > To: cy...@jelmail.com, info-cyrus@lists.andrew.cmu.edu > Subject: Re: Deliver to mailbox problem with v2.4.7 > > > On Mon, Apr 11, 2011 at 12:17:47AM +0100, John wrote: >> On 09/04/11 23:19, Dan White wrote: >>> On 09/04/11 22:33 +0100, John wrote: >>>> Sorry for delay in responding, I have been away. >>>> >>>> Setting "anyone p" made no difference: >>> Can you test to see if the same problem happens with folders without > dots >>> in them? >> Ok, on further testing today, adding "anyone p" does make it deliver ok. > Can you just confirm: "anyone p" only works for folders without dots in the > names? > >> This is wierd though because the command to deliver the mail does >> specify my user acl (-a argument to deliver) so why wouldn't this work? > Ok - so I suspect this bit is broken. It's probably not passing the > userid correctly to the part of the code that does the delivery. > >> My procmail log reports like this: >> procmail: Executing >> > "/usr/cyrus/bin/deliver,-r,x...@xxx.com,-a,john,-m,folder.name/subfolder,john > " >> cyradm lam shows folder.name/subfolder has p rights (amongst others) for >> user john. >> >> Setting "anyone" rights doesn't feel right... what now? > http://bugzilla.cyrusimap.org/ - with as much detail about what does and > doesn't work as possible. > > Thanks, > > Bron. > > Setting "anyone p" on works for mail delivery with/without dots in their > names. > > Bugzilla raised http://bugzilla.cyrusimap.org/bugzilla3/show_bug.cgi?id=3438 > > Thanks for all the help, > John > > > > > mail2web.com - Microsoft® Exchange solutions from a leading provider - > http://link.mail2web.com/Business/Exchange > > > > Cyrus Home Page: http://www.cyrusimap.org/ > List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ > As a quick "get me home fix" I'd like to set "anyone p" on all my mailbox folders until there is a solution to this problem. However, there doesn't seem to be any easy way to do this. I'm off to write a script now but if there is an easy way please can you let me know what it is... Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Deliver to mailbox problem with v2.4.7
> As a quick "get me home fix" I'd like to set "anyone p" on all my > mailbox folders until there is a solution to this problem. > However, there doesn't seem to be any easy way to do this. I'm off to > write a script now but if there is an easy way please can you let me > know what it is... > > Cyrus Home Page: http://www.cyrusimap.org/ > List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ > ignore me, I just realised cyradm now supports wildcards :) Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
New 2.4.10 install - authentication problems with saslauthd
Hello, I have a problem with a new installation. I've been trying to sort this for several days now without any luck so post here in the hope for a solution. I have a server, currently running 2.4.7 and all is well (and has been for a very long time). I am trying to build a new server with 2.4.10 but I can't get anything to authenticate on it. In both cases the host is Arch Linux and both have exactly the same configuration files: Here is imapd.conf: configdirectory: /srv/mail/cyrus partition-default: /srv/mail/cyrus/mail admins: cyrus sasl_pwcheck_method: saslauthd sasl_saslauthd_path: /var/run/saslauthd/mux allowplaintext: yes altnamespace: yes unixhierarchysep: yes virtdomains: userid defaultdomain: mydomain.com hashimapspool: true I know it's reading the correct file because I can force an error by temporarily corrupting it: Aug 5 21:44:14 localhost master[407]: invalid option name on line 1 of configuration file /etc/cyrus/imapd.conf Aug 5 21:44:14 localhost master[407]: exiting Firstly, saslauthd is running to use PAM for authentication and on both boxes I have tested this works using "testsaslauthd" getting identical results on both cases. ( in both cases the test was "testsaslauthd -u cyrus -p cyruspw -f /var/run/saslauthd/mux" and the result was "0: OK "Success."") Both boxes have the same sasl package, installed from the ArchLinux repository: # saslauthd -v saslauthd 2.1.23 authentication mechanisms: getpwent kerberos5 pam rimap shadow ldap I try "imtest -a cyrus" on each box. On the 2.4.7 box it prompts for a password, which I enter, and I am told it is "Authenticated". On the 2.4.10 box it does not prompt for a password but just returns " Authentication failed. generic failure" The log shows it is trying to use GSSAPI despite my saslauthd configuration: Aug 5 21:41:11 localhost imtest: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_0' not found) If I put "sasl_mech_list: PLAIN" into imapd.conf and retry "imtest -a cyrus" on the 2.4.10 box I do get a password prompt but it still errors: The log then shows: Aug 5 21:46:10 localhost imap[491]: badlogin: localhost.localdomain [::1] PLAIN [SASL(-1): generic failure: Password verification failed] I also tried using telnet. On the 2.4.7 box it authenticates fine. On the 2.4.10 box I get "Login failed: generic failure" I tried using imtest from the new box to access the old box (imtest -a cyrus -m PLAIN old-box) and it authenticates: # imtest -a cyrus -m PLAIN 10.0.200.6 S: * OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE AUTH=PLAIN AUTH=OTP AUTH=CRAM-MD5 AUTH=GSSAPI AUTH=LOGIN AUTH=DIGEST-MD5 SASL-IR] carbon Cyrus IMAP v2.4.7 server ready Please enter your password: C: A01 AUTHENTICATE PLAIN AGN5cnVzAGd1aW5uZXNz S: A01 OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE ACL RIGHTS=kxte QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY CATENATE CONDSTORE ESEARCH SORT SORT=MODSEQ THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE LIST-EXTENDED WITHIN QRESYNC SCAN XLIST URLAUTH URLAUTH=BINARY LOGINDISABLED COMPRESS=DEFLATE IDLE] Success (no protection) Authenticated. Security strength factor: 0 I tried using imtest from the old box to access the new box (imtest -a cyrus -m PLAIN new-box). This prompts for a password but returns "Authentication failed. generic failure" # imtest -a cyrus -m PLAIN 10.0.200.6 S: * OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE AUTH=PLAIN AUTH=OTP AUTH=CRAM-MD5 AUTH=GSSAPI AUTH=LOGIN AUTH=DIGEST-MD5 SASL-IR] carbon Cyrus IMAP v2.4.7 server ready Please enter your password: C: A01 AUTHENTICATE PLAIN AGN5cnVzAGd1aW5uZXNz S: A01 OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE ACL RIGHTS=kxte QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY CATENATE CONDSTORE ESEARCH SORT SORT=MODSEQ THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE LIST-EXTENDED WITHIN QRESYNC SCAN XLIST URLAUTH URLAUTH=BINARY LOGINDISABLED COMPRESS=DEFLATE IDLE] Success (no protection) Authenticated. Security strength factor: 0 The log shows: Aug 5 22:02:54 localhost imap[733]: badlogin: [10.0.200.6] PLAIN [SASL(-1): generic failure: Password verification failed] I don't know what else to try. I have read and reread the documentation on cyrusimap.org for both Cyrus-IMAP and Cyrus SASL. The sasl tests are ok, imtest works from both boxes to connect to the 2.4.7 imapd but fails from both boxes when connecting to the 2.4.10 box. It appears to use saslauthd but for some reason isn't working. I would really appreciate some help. Thanks in advance. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: New 2.4.10 install - authentication problems with saslauthd
On 05/08/11 22:32, Dan White wrote: > Does your cyrus user have permissions to access the saslauthd mux? > > Try running your testsaslauthd command as your cyrus user... I'm assuming > that during testing you were using root, or another account. > Aha! Thank you so much. I had checked the permissions on /var/run/saslauthd/mux and they were 777 and also the directory /var/run/saslauthd which had 766. . I assumed that these were sufficient but I just changed the directory also to 777 and all works well. However I am not sure 777 is the right way to sort the problem. I've looked in the sasl documentation and can find nothing at all regarding the entitlements of /var/run/saslauthd. Is there any guidance on how the entitlement should be given? I would have expected to need some kind of group entitlement to be giveen to sasl users? Or is 777 ok? At least it's now working so I appreciate your help with that. > > Be aware that your password here is uuencoded and can be trivially > reversed. > Thanks for that info, I wasn't aware of that. It doesn't matter anyway, these are just test systems not connected to the outside world and that will be trashed when I'm finished. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
sync_server refused connection
Hello, I am just trying to set up replication for the first time. I have followed the instructions here: http://cyrusimap.web.cmu.edu/docs/cyrus-imapd/2.4.6/install-replication.php I have the replica up and running and it has syncserver running on it. However when I try to connect using sync_client I get a connection refused. To try and rule out ex-host issues I have tried a telnet from the replica machine. This also results in connection refused. I would appreciate any pointers as I don't know where to look. My config in cyrus.conf is as per the instructions (except the path to sync_server was slightly different): syncserver cmd="/usr/lib/cyrus/bin/sync_server" listen="csync" When I telnet: # telnet localhost csync Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Connection closed by foreign host. [root@replica ~]# Jan 12 21:04:57 replica syncserver[392]: executed Jan 12 21:04:58 replica syncserver[392]: refused connection from 127.0.0.1 I have spent ages looking to see if I can get more verbose output, or others' explanations of setting up replication but I have drawn a blank. I'd really appreciate a few pointers... Thanks in advance. 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: sync_server refused connection
On 12/01/13 21:08, John wrote: > Hello, > > I am just trying to set up replication for the first time. I have > followed the instructions here: > > http://cyrusimap.web.cmu.edu/docs/cyrus-imapd/2.4.6/install-replication.php > > I have the replica up and running and it has syncserver running on it. > > However when I try to connect using sync_client I get a connection refused. > > To try and rule out ex-host issues I have tried a telnet from the > replica machine. > > This also results in connection refused. I would appreciate any pointers > as I don't know where to look. > > My config in cyrus.conf is as per the instructions (except the path to > sync_server was slightly different): > > syncserver cmd="/usr/lib/cyrus/bin/sync_server" listen="csync" > > When I telnet: > # telnet localhost csync > Trying 127.0.0.1... > Connected to localhost. > Escape character is '^]'. > Connection closed by foreign host. > [root@replica ~]# > > > Jan 12 21:04:57 replica syncserver[392]: executed > Jan 12 21:04:58 replica syncserver[392]: refused connection from 127.0.0.1 > > I have spent ages looking to see if I can get more verbose output, or > others' explanations of setting up replication but I have drawn a blank. > I'd really appreciate a few pointers... > > Thanks in advance. > > > 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 > I am still seeking some guidance on this, if there is anyone who can offer some adivce please? 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: sync_server refused connection
On 29/01/13 10:38, Patrick Boutilier wrote: > > What OS are you running? This sounds like tcpwrappers to me? > Arch Linux (which has deprecated TCP wrappers) but I do have it installed (7.6.15) because, as I understand it, cyrus needs it. Perhaps that has changed ? 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: sync_server refused connection
On 29/01/13 16:16, Patrick Boutilier wrote:
>
> What are the contents of /etc/hosts.allow and /etc/hosts.deny ?
>
>
>
Sorry, been away on something else. I thought for a second there that's
what it would be but it isn't. I've appended config file output and some
other information below.
# cat /etc/hosts.{allow,deny}
#
# /etc/hosts.allow
#
sshd:ALL
imap:ALL
csync:ALL
# End of file
#
# /etc/hosts.deny
#
ALL: ALL
# End of file
# grep csync /etc/services
csync 2005/tcp # Cyrus-IMAP replication
# telnet localhost csync
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Connection closed by foreign host.
# systemctl status cyrus-master
cyrus-master.service - Cyrus IMAP mail server
Loaded: loaded (/etc/systemd/system/cyrus-master.service; enabled)
Active: active (running)
Process: 217 ExecStart=/usr/lib/cyrus/bin/master -d (code=exited,
status=0/SUCCESS)
Main PID: 221 (master)
CGroup: name=systemd:/system/cyrus-master.service
├─221 /usr/lib/cyrus/bin/master -d
└─390 /usr/lib/cyrus/bin/sync_server
Jan 31 09:58:29 sodium ctl_cyrusdb[226]: recovering cyrus databases
Jan 31 09:58:30 sodium ctl_cyrusdb[226]: skiplist: checkpointed
/srv/mail/cyrus/mailboxe...ond
Jan 31 09:58:30 sodium ctl_cyrusdb[226]: skiplist: checkpointed
/srv/mail/cyrus/annotati...nds
Jan 31 09:58:30 sodium master[221]: unable to setsocketopt(IP_TOS):
Operation not supported
Jan 31 09:58:30 sodium master[221]: ready for work
Jan 31 09:58:30 sodium master[282]: about to exec
/usr/lib/cyrus/bin/ctl_cyrusdb
Jan 31 09:58:30 sodium ctl_cyrusdb[282]: checkpointing cyrus databases
Jan 31 09:58:30 sodium ctl_cyrusdb[282]: archiving database file:
/srv/mail/cyrus/mailboxes.db
Jan 31 09:58:30 sodium ctl_cyrusdb[282]: archiving database file:
/srv/mail/cyrus/annotadb
Jan 31 09:58:31 sodium master[221]: process 282 exited, status 0
Jan 31 10:02:45 sodium master[390]: about to exec
/usr/lib/cyrus/bin/sync_server
Jan 31 10:02:46 sodium syncserver[390]: executed
Jan 31 10:02:46 sodium syncserver[390]: refused connection from 127.0.0.1
Cyrus configs:
#cat /etc/cyrus/cyrus.conf
# standard standalone server implementation
START {
# do not delete this entry!
recover cmd="ctl_cyrusdb -r"
# this is only necessary if using idled for IMAP IDLE
# idled cmd="idled"
}
# UNIX sockets start with a slash and are put into /var/imap/socket
SERVICES {
# add or remove based on preferences
imap cmd="imapd" listen="imap" prefork=0
# imaps cmd="imapd -s" listen="imaps" prefork=0
pop3 cmd="pop3d" listen="pop3" prefork=0
# pop3s cmd="pop3d -s" listen="pop3s" prefork=0
sieve cmd="timsieved" listen="sieve" prefork=0
# these are only necessary if receiving/exporting usenet via NNTP
# nntp cmd="nntpd" listen="nntp" prefork=0
# nntps cmd="nntpd -s" listen="nntps" prefork=0
# at least one LMTP is required for delivery
# lmtp cmd="lmtpd" listen="lmtp" prefork=0
lmtpunix cmd="lmtpd" listen="/srv/mail/cyrus/socket/lmtp" prefork=0
# this is required if using notifications
# notify cmd="notifyd" listen="/var/imap/socket/notify" proto="udp"
prefork=1
syncserver cmd="/usr/lib/cyrus/bin/sync_server" listen="csync"
}
EVENTS {
# this is required
checkpoint cmd="ctl_cyrusdb -c" period=30
# this is only necessary if using duplicate delivery suppression,
# Sieve or NNTP
delprune cmd="cyr_expire -E 3" at=0400
# this is only necessary if caching TLS sessions
tlsprune cmd="tls_prune" at=0400
}
# cat /etc/cyrus/imapd.conf
configdirectory: /srv/mail/cyrus
partition-default: /srv/mail/cyrus/mail
admins: cyrus
sasl_pwcheck_method: saslauthd
sasl_saslauthd_path: /var/run/saslauthd/mux
sasl_mech_list: PLAIN
allowplaintext: yes
altnamespace: yes
unixhierarchysep: yes
virtdomains: userid
defaultdomain: mydomain.com
hashimapspool: true
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: sync_server refused connection
On 31/01/13 10:41, Patrick Boutilier wrote: > > Try syncserver:ALL instead of csync:ALL > That was it. Thank you. My build included tcp_wrappers just because it always has. But, as the OS has deprecated it some time ago, I think that I should rebuild without it. I presume there's nothing in Cyrus that requires me to have libwrap ? 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
Is it OK for users to use either of a pair of replicated servers ?
Hello, I have just set up a second server for a small email group and I now have replication working between them. I was very happy to note that it replicates both ways. My use-case is basically this: to have two servers, one acting as a primary and another as a backup. The primary will be the one that goes out to the internet to grab emails for users. Apart from that difference the two servers are identical. Either can take on the primary role. Users can connect their IMAP email clients to either server. One of the pair runs sync_server and the other regularly connects to it to keep the two servers in sync. It's a basic configuration intended for use by a small number of people. I'd like to confirm that the replication mechanism implemented with sync_server and sync_client is ok for this kind of set-up. It certainly appears to work just fine like this but I haven't found anything in the documentation saying that two-way replication like this is ok (i.e. where users can log in to either server). Many thanks. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Is it OK for users to use either of a pair of replicated servers ?
On 01/02/13 11:18, Adam Tauno Williams wrote: > On Fri, 2013-02-01 at 10:01 +0000, John wrote: >> Hello, I have just set up a second server for a small email group and I >> now have replication working between them. > Great. > >> I was very happy to note that it replicates both ways. > It does??? What version is this? I have one box running 2.4.13 and another, the master, at 2.4.17. I need to update the other but haven't got around to it yet. I'm just doing some testing. v2.4.13 4255a887 2011-12-30 v2.4.17 d1df8aff 2012-12-01 I was surprised when things appeared to replicate both ways. > >> My use-case is basically this: to have two servers, one acting as a >> primary and another as a backup. The primary will be the one that goes >> out to the internet to grab emails for users. Apart from that difference >> the two servers are identical. Either can take on the primary role. >> Users can connect their IMAP email clients to either server. One of the >> pair runs sync_server and the other regularly connects to it to keep the >> two servers in sync. It's a basic configuration intended for use by a >> small number of people. > As far as I know that will not work. I've only been doing this for a day. I've got two mail clients sitting side by side - one is connected to the master and the other to the replica. I can definitely type mails on either client and see them appear on the other (after a small delay). I find that I have to kick the replication at the moment (with a "sync_client -u myuser") for the updates to come back to the master. The updates to the replica seem pretty much instantaneous. I do have messages in the logs which I don't yet understand and this might be because it doesn't actually work - I don't know yet: Feb 1 11:55:38 localhost sync_client[239]: MAILBOX received NO response: IMAP_MAILBOX_CRC Checksum Failure Feb 1 11:55:38 localhost sync_client[239]: CRC failure on sync for user.john, trying full update Feb 1 11:55:38 localhost sync_client[239]: SYNCNOTICE: highestmodseq higher on replica user.john, updating 36158 => 36160 Feb 1 11:55:38 localhost sync_client[239]: SYNCNOTICE: only on replica user.john 57616 Feb 1 11:55:38 localhost sync_client[239]: SYNCNOTICE: only on replica user.john 57617 Feb 1 11:55:38 localhost sync_client[239]: MAILBOX received NO response: IMAP_MAILBOX_CRC Checksum Failure Feb 1 11:55:38 localhost sync_client[239]: CRC failure on sync for user.john.Queue, trying full update Feb 1 11:55:38 localhost sync_client[239]: SYNCNOTICE: highestmodseq higher on replica user.john.Queue, updating 13 => 16 Feb 1 11:55:38 localhost sync_client[239]: SYNCNOTICE: only on replica user.john.Queue 3 Feb 1 11:55:38 localhost sync_client[239]: SYNCNOTICE: only on replica user.john.Queue 4 Feb 1 11:55:38 localhost sync_client[239]: MAILBOX received NO response: IMAP_MAILBOX_CRC Checksum Failure Feb 1 11:55:38 localhost sync_client[239]: CRC failure on sync for user.john.hosts.root^blurb, trying full update Feb 1 11:55:38 localhost sync_client[239]: SYNCNOTICE: highestmodseq higher on replica user.john.hosts.root^blurb, updating 6035 => 6036 Feb 1 11:55:38 localhost sync_client[239]: SYNCNOTICE: record mismatch with replica: user.john.hosts.root^blurb more recent on replica Feb 1 11:55:38 localhost sync_client[239]: SYNCNOTICE: master uid:3620 modseq:6034 last_updated:1359719530 internaldate:1359716512 flags:( NonJunk) Feb 1 11:55:38 localhost sync_client[239]: SYNCNOTICE: replica uid:3620 modseq:6035 last_updated:1359719721 internaldate:1359716512 flags:( NonJunk) Feb 1 11:55:38 localhost sync_client[239]: SYNCNOTICE: record mismatch with replica: user.john.hosts.root^blurb more recent on replica Feb 1 11:55:38 localhost sync_client[239]: SYNCNOTICE: master uid:3620 modseq:6034 last_updated:1359719530 internaldate:1359716512 flags:( NonJunk) Feb 1 11:55:38 localhost sync_client[239]: SYNCNOTICE: replica uid:3620 modseq:6035 last_updated:1359719721 internaldate:1359716512 flags:( NonJunk) Feb 1 11:55:38 localhost sync_client[239]: seen_db: user john opened /srv/mail/cyrus/user/j/john.seen Any thoughts? >> I'd like to confirm that the replication mechanism implemented with >> sync_server and sync_client is ok for this kind of set-up. It certainly >> appears to work just fine like this but I haven't found anything in the >> documentation saying that two-way replication like this is ok (i.e. >> where users can log in to either server). > I believe that multi-master is a feature for 2.5.x. 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: Is it OK for users to use either of a pair of replicated servers ?
Further to my last message, I've updated my master so now both servers report the same version: version: v2.4.17 d1df8aff 2012-12-01 I'd like to understand some error messages that I am getting and what I should do to resolve them... On the replica: syncserver[8816]: higher last_uid on replica user.myuser - 57628 < 57629 syncserver[8816]: higher modseq on replica user.myuser - 36186 < 36187 On the master: sync_client[5197]: MAILBOX received NO response: IMAP_MAILBOX_CRC Checksum Failure sync_client[5197]: CRC failure on sync for user.myuser, trying full update sync_client[5197]: SYNCNOTICE: record mismatch with replica: user.myuser more recent on master sync_client[5197]: SYNCNOTICE: master uid:57626 modseq:36180 last_updated:1359731641 internaldate:1359729048 flags:( NonJunk) sync_client[5197]: SYNCNOTICE: replica uid:57626 modseq:36177 last_updated:1359730649 internaldate:1359729048 flags:(NonJunk) sync_client[5197]: SYNCNOTICE: record mismatch with replica: user.myuser more recent on master sync_client[5197]: SYNCNOTICE: master uid:57626 modseq:36180 last_updated:1359731641 internaldate:1359729048 flags:( NonJunk) sync_client[5197]: SYNCNOTICE: replica uid:57626 modseq:36177 last_updated:1359730649 internaldate:1359729048 flags:(NonJunk) sync_client[5197]: SYNCNOTICE: only on replica user.myuser 57629 Despite these messages, my replication appears to be working but I can't as yet be 100% sure. I'd like to understand the above and try and stop them if I can... I can't find any documentation detailing what the above means, and I'm not that familiar with the internals of the imap server, so I'd really appreciate some pointers... Thanks very much. 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: Is it OK for users to use either of a pair of replicated servers ?
On 01/02/13 16:42, Adam Tauno Williams wrote: > > A modseq is very much like an etag or a ctag in HTTP/WebDAV. It is a > value that gets incremented with every change. So the the modseq on the > slave is greater than the modseq on the master... something is out of > sync. I guessed that's what it was. thanks for clearing that up for me. >> On the master: >> sync_client[5197]: MAILBOX received NO response: IMAP_MAILBOX_CRC >> Checksum Failure >> sync_client[5197]: CRC failure on sync for user.myuser, trying full update >> sync_client[5197]: SYNCNOTICE: record mismatch with replica: user.myuser >> more recent on master > Aren't you connecting to the slave and making changes? That would make > sense then, the master and the replica are constantly getting > out-of-sync. Replication is one-way. Yes. My original server became the master and the new one became the replica. I then switched off main retrieval on the master and enabled it on the replica so that would naturally become ahead. If I understand correctly the replication isn't designed to work that way (although it does an admirable job of doing so). I need to configure the "ahead" server as the master and the other as the replica (e.g. switch the replication direction around). I'll do that over the weekend. >> Despite these messages, my replication appears to be working but I can't >> as yet be 100% sure. I'd like to understand the above and try and stop >> them if I can... > Because it is constantly recovering, as these messages indicate. 2.4.x > replication is quite reliable and recovers from inconsistencies most of > the time. It works very well. If I understand from your earlier comments, when 2.5 comes out will this support bi-directional replication along the lines of what I am trying to do ? Meanwhile I'll stop updating the replica except via the sync client/server. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: caldav-beta9 and unixhierarchysep: yes
Gary, I had the same problem, so set unixhierarchysep: no and it persisted. I manually created the mailbox in cyradm with cm user.john.#calendars.Default sam user.john.#calendars.Default jwrm all cyrus all and that made it work with TB. I've not had time yet to work out whether I have been overgenerous with the permissions, but I got it to work. I think the bug here is nothing to do with the separator, but that the calendar mailbox is not auto-provisioned. I see nothing in the logs to indicate an attempt at autocreation. John On 04/07/14 18:30, Gary Hawkins wrote: > Dear all, > > I've just installed caldav-beta9 from the latest debian (testing) > package and so far I think I have managed to configure the server side > OK. However, when I try to access the default calendar for the first > time, I get this in the logs: > > Jul 4 18:19:27 mail cyrus/https[7437]: > mlookup(user.ghawkins.#calendars.Default) failed: Mailbox does not exist > Jul 4 18:19:27 mail cyrus/https[7437]: wallace.garyhawkins.me.uk > [2001:8b0:127:1:225:90ff:fef0:6024] as "ghawkins" with "Mozilla/5.0 > (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 > Lightning/2.6.6"; "PROPFIND /dav/calendars/user/ghawkins/Default/ > HTTP/1.1" (depth=0) => "404 Not Found" (error=Mailbox does not exist) > > Because I've got unixhierarchysep: yes set, my mailbox separator is / > rather than . and the top line of the log above suggests it's using the > wrong separator when looking up or creating the default mailbox, as I > would have expected it to look up user/ghawkins/#calendars/Default > instead, unless the log message is just wrong cosmetically). > > I've tried all the URL variations I can think of to make this work, but > I just can't find a way to access the calendar. I wonder if this is a bug? > > Thanks > Gary Hawkins > 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: imaps terminated abnormally
Randy, I had similar symptoms and it was due to a problem with the TLS cache (tls_sessions.db) file. I deleted the file, cyrus recreated it automatically and everything ran fine afterwards. Other than that, libssl has been updated a lot recently, so you might find you either have a bug there or need to just reboot to make the new library version come into play, perhaps? John On 14/08/14 04:02, Randy Barlow wrote: > I believe I have narrowed my issue down to a bug in the 3.14.14 kernel. > I've filed a bug with Gentoo about it if anyone is interested in > following it: > > https://bugs.gentoo.org/show_bug.cgi?id=519666 > > > > > 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: imaps terminated abnormally
Hi Randy, I think I have run out of sensible ideas, then, and would start to resort to more fanciful notions like recompiling cyrus and its libraries on the new kernel. Do you get a core dump/backtrace from cyrus? That might help you to isolate whether, for example, it is actually a kernel problem or instead a problem that a library is having with the kernel. John On 14/08/14 21:23, Randy Barlow wrote: > Hi John! > > On 08/14/2014 04:09 PM, John wrote: >> I had similar symptoms and it was due to a problem with the TLS cache >> (tls_sessions.db) file. I deleted the file, cyrus recreated it >> automatically and everything ran fine afterwards. > I have also observed what you describe here, but there is a process that > runs periodically that cleans up the TLS cache. When I watch my logs, I > see it running every so often. I have noticed that these errors can > occur until that process runs. In particular, if I close my laptop > (suspend) with Thunderbird running, and open it later, I'll see these > messages for a while (5-10 minutes) in the logs. Eventually Thunderbird > and Cyrus sort it out and everything is fine. > > The error I was describing happens always (starting 0-12 hours into the > Cyrus process running) and forever (it will continue until I restart > Cyrus) with the 3.14.14 kernel. This is why I think it's a kernel issue. > >> Other than that, >> libssl has been updated a lot recently, so you might find you either >> have a bug there or need to just reboot to make the new library version >> come into play, perhaps? > Rebooting didn't sort it out, but I still think it's something to do > with the kernel because when I run the old kernel (and the same libssl > and Cyrus), the issue goes away. > > > > > 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: Recommended file locations for linux cyrus servers?
Patrick, For what it's worth, I have a separate /srv partition for exactly the reasons you outline, and I place the cyrus mailbox data in /srv/cyr. That way, an overfull mail store doesn't kill the entire server (and vice versa, perhaps). I'm using Ubuntu, but I think the principle remains the same. John On 04/12/14 23:11, Patrick Goetz wrote: > This might seem like a dumb question, but I'm wondering if anyone has > some thoughts on recommended file locations for single server systems; > in particular, what are the cyrus default folder locations? > > I've been using cyrus on Ubuntu/debian systems and am now making a > switch to Arch. The default debian file locations are: > >/var/spool/cyrus: mail, news, sieve >/var/run/cyrus: sockets >/var/lib/cyrus: db files, db, quota, msg, proc > (configdirectory=/var/lib/cyrus) >/var/log/mail.* log files > > although there also appears to be an unused /var/lib/cyrus/user folder > > > The problem with putting actual user mail in /var is that this can > eventually amount to quite a bit of data. Many modern small server > systems are set up with small/fast SSD OS disks and user data (/home) > stored on larger traditional disks. (I set up all my servers like this.) > Since the OS disk is relatively small, I try to avoid placing growing > data stores on it. > > The simple solution would appear to be to place /var on a separate > partition on the larger disks as well, but this has in the past resulted > in boot problems because /var doesn't get mounted quickly enough. (And > yes, understood this problem has finally been solved by systemd.) > > So my solution has been to make the defaultpartition = /home/cyrus/mail > > leaving the debian defaults in place otherwise. > > > The Arch package maintainer has set up everything under /var/imap: > > [root@ibis imap]# pwd > /var/imap > [root@ibis imap]# ls > db log msg proc quota sieve socket user > > > I can live with this, but it doesn't seem ideal, either. For example, > what is the configdirectory, given this directory structure? > > Hence my question. The Arch philosophy is to stick as closely to > upstream as possible, so it would be useful to know what that is. > > > > Cyrus Home Page: http://www.cyrusimap.org/ > List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ > To Unsubscribe: > https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus > 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: docs.cyrus.foundation DNS problem?
I 'resolved' this by disabling DNSSEC checking in bind9. On 10/04/15 12:25, John wrote: > > Hi, > > I’m getting the following error messages in bind in relation to > docs.cyrus.foundation: > > |error (insecurity proof failed) resolving 'docs.cyrus.foundation/A/IN': > 8.8.4.4#53 > validating @0x7fc608774690: docs.cyrus.foundation A: got insecure response; > parent indicates it should be secure > error (insecurity proof failed) resolving 'docs.cyrus.foundation/A/IN': > 8.8.8.8#53 > validating @0x7fc608774690: docs.cyrus.foundation A: got insecure response; > parent indicates it should be secure > | > > It also appears to be intermittent. Is this a known issue? > > John > > > > > > 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
Shared folder permissions
Hi List, I have a bunch of shared folders which I want to have various user permissions on them. I can do the simple read/write ones, but I cannot work out how to allow a user to delete mails but not the mailbox. A user has just done it *again* so I need to get it sorted. Thanks, John 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: Shared folder permissions
I set the ACL to lrswiptek and it then shows as lrswipktecd. Have I missed a database migration step at some point in the past? The current server is running 2.4.12 (and I have a project to move it all to 2.5.x soon). John On 30/07/15 16:37, Dan White wrote: > On 07/30/15 16:21 +0100, John wrote: >> Hi List, >> >> I have a bunch of shared folders which I want to have various user >> permissions on them. I can do the simple read/write ones, but I cannot >> work out how to allow a user to delete mails but not the mailbox. A user >> has just done it *again* so I need to get it sorted. > > https://www.ietf.org/rfc/rfc4314.txt > > You want 't' and not 'x'. > 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: Shared folder permissions
The RFC says it’s c=k+x and d=t+e. I want users to be able to delete messages (t) but not delete mailboxes (x), so I am applying a permission of lrswiptek, but when I read it back it shows lrswipktecd: |localhost> lam Not* NotUser: anyone lrs NotUser/Shared1: bob lrswipktecd anyone lrs NotUser/Shared1/Test1: bob lrswipktecd anyone lrs NotUser/Shared2: anyone lrs localhost> sam Not*2 bob lrswiptek Setting ACL on NotUser/Shared2...OK. localhost> lam Not* NotUser: anyone lrs NotUser/Shared1: bob lrswipktecd anyone lrs NotUser/Shared1/Test1: bob lrswipktecd anyone lrs NotUser/Shared2: anyone lrs bob lrswipktecd | So I am wondering if somehow a pre-2.3.0 database has crept in and I need to upgrade it somehow? John On 30/07/15 19:26, Adam Tauno Williams wrote: > On Thu, 2015-07-30 at 19:09 +0100, John wrote: >> I set the ACL to lrswiptek and it then shows as lrswipktecd. Have I >> missed a database migration step at some point in the past? The >> current server is running 2.4.12 (and I have a project to move it all >> to 2.5.x soon). > Don't use d & w if you want fine-grained permissions control; old d, r > & w imply other permissions. If I recall correctly: d = t+x and w > implies d. > > 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: Shared folder permissions
Errata: RFC says c=k and d=t+e+x, but that doesn't change my problem. On 30/07/15 19:45, John wrote: > > The RFC says it’s c=k+x and d=t+e. I want users to be able to delete > messages (t) but not delete mailboxes (x), so I am applying a > permission of lrswiptek, but when I read it back it shows lrswipktecd: > > |localhost> lam Not* > NotUser: > anyone lrs > NotUser/Shared1: > bob lrswipktecd > anyone lrs > NotUser/Shared1/Test1: > bob lrswipktecd > anyone lrs > NotUser/Shared2: > anyone lrs > localhost> sam Not*2 bob lrswiptek > Setting ACL on NotUser/Shared2...OK. > localhost> lam Not* > NotUser: > anyone lrs > NotUser/Shared1: > bob lrswipktecd > anyone lrs > NotUser/Shared1/Test1: > bob lrswipktecd > anyone lrs > NotUser/Shared2: > anyone lrs > bob lrswipktecd > | > > So I am wondering if somehow a pre-2.3.0 database has crept in and I > need to upgrade it somehow? > > John > > On 30/07/15 19:26, Adam Tauno Williams wrote: > >> On Thu, 2015-07-30 at 19:09 +0100, John wrote: >>> I set the ACL to lrswiptek and it then shows as lrswipktecd. Have I >>> missed a database migration step at some point in the past? The >>> current server is running 2.4.12 (and I have a project to move it all >>> to 2.5.x soon). >> Don't use d & w if you want fine-grained permissions control; old d, r >> & w imply other permissions. If I recall correctly: d = t+x and w >> implies d. >> >> > > > > > 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: Shared folder permissions
I was misreading the RFC and I now understand how one of my users was able to delete a few gigs of email and folders: the folders had been migrated from a pre-2.3.0 message store and I hadn't retuned the permissions on those folders. Having now retested on two 2.4 servers and a 2.5.4 I am now content that this was a PEBSAK. Fortunately, I have a backup... Thanks for the help! John On 30/07/15 19:58, Dan White wrote: > I was just looking through 2.5.3. See lib/acl.c, which looks reasonable > (for that version). > > On 07/30/15 19:56 +0100, John wrote: >> But I am setting e and t and getting back e, t and d and it is behaving >> like x is set. I think I might be taking a trip to the source code >> again :( >> >> John >> >> On 30/07/15 19:44, Dan White wrote: >>> RFC 4314 was implemented in 2.3.0 (according to the changes file). >>> >>> So with 'd' listed, e, t, and x are implied, per the RFC. >>> >>> This is way out of date date unfortunately: >>> >>> http://cyrusimap.org/docs/cyrus-imapd/2.5.4/overview.php >>> >>> Check your 'defaultacl:' option to verify it doesn't contain d. >>> >>> On 07/30/15 19:09 +0100, John wrote: >>>> I set the ACL to lrswiptek and it then shows as lrswipktecd. Have I >>>> missed a database migration step at some point in the past? The >>>> current >>>> server is running 2.4.12 (and I have a project to move it all to 2.5.x >>>> soon). >>>> >>>> John >>>> >>>> On 30/07/15 16:37, Dan White wrote: >>>>> On 07/30/15 16:21 +0100, John wrote: >>>>>> Hi List, >>>>>> >>>>>> I have a bunch of shared folders which I want to have various user >>>>>> permissions on them. I can do the simple read/write ones, but I >>>>>> cannot >>>>>> work out how to allow a user to delete mails but not the mailbox. A >>>>>> user >>>>>> has just done it *again* so I need to get it sorted. >>>>> >>>>> https://www.ietf.org/rfc/rfc4314.txt >>>>> >>>>> You want 't' and not 'x'. >>> >> >> > Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
CalDAV URLs
Quick questions: What is the format of a CalDAV URL for a virtual user (eg calendar Default at f...@example.com)? What is the format of a CalDAV URL for a shared calendar? How should a shared calendar be created (eg in cyradm)? Thanks, John Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: CalDAV URLs
On 10/09/15 12:51, Ken Murchison wrote: > On 09/09/2015 06:50 PM, John wrote: >> Quick questions: >> >> What is the format of a CalDAV URL for a virtual user (eg calendar >> Default at f...@example.com)? > > I don't know if CalDAV works with virtdomains yet. I didn't > explicitly add any code to handle it during initial development and I > haven't done any testing. > > >> >> What is the format of a CalDAV URL for a shared calendar? How should >> a shared calendar be created (eg in cyradm)? > > Shared calendars aren't supported yet as I don't know how best to > present them to clients to make them usable. > > > -- > Kenneth Murchison > Principal Systems Software Engineer > Carnegie Mellon University > > > > 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: CalDAV URLs
Thanks, Ken. On 10/09/15 12:51, Ken Murchison wrote: > On 09/09/2015 06:50 PM, John wrote: >> Quick questions: >> >> What is the format of a CalDAV URL for a virtual user (eg calendar >> Default at f...@example.com)? > > I don't know if CalDAV works with virtdomains yet. I didn't > explicitly add any code to handle it during initial development and I > haven't done any testing. > > >> >> What is the format of a CalDAV URL for a shared calendar? How should >> a shared calendar be created (eg in cyradm)? > > Shared calendars aren't supported yet as I don't know how best to > present them to clients to make them usable. > > > -- > Kenneth Murchison > Principal Systems Software Engineer > Carnegie Mellon University > > > > 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: CalDAV URLs
On 11/09/15 00:47, Bron Gondwana wrote: > > > > On Thu, Sep 10, 2015, at 21:51, Ken Murchison wrote: >> On 09/09/2015 06:50 PM, John wrote: >>> Quick questions: >>> >>> What is the format of a CalDAV URL for a virtual user (eg calendar >>> Default at f...@example.com <mailto:f...@example.com>)? >> >> I don't know if CalDAV works with virtdomains yet. I didn't >> explicitly add any code to handle it during initial development and I >> haven't done any testing. > > Yeah, this works fine: > > /dav/calendars/user/f...@example.com <mailto:f...@example.com>/Default > (for example) > > We added httpd_extradomain for users who aren't domain split yet, so > our frontend proxy logs the user in as fred%example.com rather than > just fred, and despite their mailbox being > user.fred.#calendars.Default (no domain), the URL is > /dav/calendars/user/f...@example.com <mailto:f...@example.com>/Default. > > This is all working in production. > >> >>> >>> What is the format of a CalDAV URL for a shared calendar? How should >>> a shared calendar be created (eg in cyradm)? >> >> Shared calendars aren't supported yet as I don't know how best to >> present them to clients to make them usable. > > At least at FastMail, we've got them working by putting them in a > shared user and adding ACLs for everyone who needs to access them. > > One thing - we don't (yet) have support for cross domain sharing (not > even with the hack above), so you can't share calendars between users > in different domains. > > Bron. > Thanks, Bron. I'll give that all a try. John 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
Alternate namespace and sieve problem
We would like to use 2.0.14-NAMESPACE with the alternate namespace enabled. This works when naming a mailbox through the IMAP protocol but does not seem to extend to mailbox names in sieve scripts. It does mean that existing sieve scripts will continue to work, but it seems wrong that users should have to use different namespaces for reading mail and composing sieve scripts. Of course websieve will need modification to work with the alternate namespace, but that is a different issue and should be fairly straightforward. Thanks, John.
Re: ANN: Alternate namespace for Cyrus IMAP
Ken (Message sent a few days ago but I don't think it got through). The alternate namespace looks like a very useful enhancement that should avoid problems with the many clients that assume too much about what the namespace should be. I think it's also much more in line with what users expect. I do have one query though. Since personal folders and INBOX now exist at the same level for the logged-in user I had expected the same to be true also for "Other Users" - e.g. there might be mailboxes Other Users.Mike.INBOX Other Users.Mike.Saved etc. (There is a similar example on p.7 of RFC2342) However this is not the case - instead the messages in Mike's INBOX are found in Other Users.Mike Is it worth reconsidering this while the enhancement is still not "official" - or are there theoretical or practical reasons for the way it's done at present? Anyway, many thanks! John. At 16:46 31/05/01, Ken Murchison wrote: >I am pleased to announce the availability of an alternate namespace for >Cyrus IMAP which allows personal folders to reside at the same >[top]level as the INBOX. You should consider this code to be late-beta, >but it is fully functional and appears to be as stable as 2.0.14. I >have been running this code on my production server throughout the >development process without any problems. I am hoping to have people >test this code so that any hidden wrinkles can be ironed out ASAP, and >then it will be merged into the main Cyrus distribution (hopefully by >2.0.15).
Re: IMAP-only Migration tools?
Jules Agee wrote: > > > 2) write a Perl script from scratch to do the same thing. I'm OK at > Perl, so I know I could do this, but I think it might take me more > time than I have. Jules, if you know Perl then go the Perl route. I found it relatively easy to write a Perl program which calls the imapxfer program from the c_client utilities. I use Expect to call imapxfer. the main problem I am facing is that in our existing Netscape server there are messages with bare newlines, which imapxfer, correctly, won't handle.
Signaled to death by 11 - Don't know what else to try
Hello all, I've been running myself in circles for almost two weeks now trying to figure out a 'signaled to death by 11' problem, and I'm hoping someone on this list can shed some light for me. I've been reading through the list archive and have seen numerous reference to mismatching libdb files, so I've done my best to eliminate that as a problem, but I still can't make my issue go away. Any guidance will be greatly appreciated! This is my setup. RedHat 7.1 BerkeleyDB 3.2.9 CyrusSASL 1.5.24 CyrusIMAP 2.0.15 pam_ldap 1.22 OpenLDAP 2.0.11 When I try to connect, say with imtest, if my sasl_pwcheck_method=sasldb, I get in no problem. If my sasl_pwcheck_method=pam, I get the following in my log file: Jul 27 23:52:31 vmsurfrider master[29589]: about to exec /usr/cyrus/bin/imapd Jul 27 23:52:31 vmsurfrider service-imap[29589]: executed Jul 27 23:52:31 vmsurfrider imapd[29589]: accepted connection Jul 27 23:52:36 vmsurfrider master[29579]: process 29589 exited, signaled to death by 11 What's interesting is that if I purposefully mistype the password, I get a normal authentication failure with no 'signaled to death' problem. When I put the password in properly, that's when I see the problem. May pam config file for imap is like so: [root@vmsurfrider pam.d]# more imap #%PAM-1.0 auth required /lib/security/pam_ldap.so debug accountrequired /lib/security/pam_ldap.so debug By running OpenLDAP in debug mode (slapd -d -1) I can clearly see communication to the LDAP server, and I don't see any obvious problems there. No error messages, no permission problems that I can see, etc. I built things in the following order. - Built/installed Berkeley DB (--with-uniquename) - modified /etc/ld.so.conf to include the BerkeleyDB path and ran ldconfig - set CPPFLAGS and LDFLAGS in include BerkeleyDB path - CyrusSASL (--without-krb --without-gssapi) - modified /etc/ld.so.conf to include local SASL path and ran ldconfig - OpenLDAP (--enable-spasswd --enable-passwd --enable-shell --enable-ldap) - CyrusIMAP (--with-auth=unix --with-dbdir=/usr/local/BerkeleyDB.3.2) - pam_ldap (--with-ldap-lib=openldap) My ld.so.conf file looks like this: [root@vmsurfrider Docs]# more /etc/ld.so.conf /usr/local/BerkeleyDB.3.2/lib /usr/local/lib /usr/local/lib/sasl /usr/lib /usr/kerberos/lib /usr/X11R6/lib /usr/lib/sane /usr/lib/qt-2.3.0/lib /usr/lib/mysq Apologies for the length of this message. I'm hoping to give all the relevant info I can think of. I've included the ldd output from what I think are the key files. Thanks in advance for any help. I'm pretty frustrated at this point. - John [root@vmsurfrider bin]# ldd master libssl.so.1 => /usr/lib/libssl.so.1 (0x40024000) libcrypto.so.1 => /usr/lib/libcrypto.so.1 (0x40051000) libdb-3.1.so => /lib/libdb-3.1.so (0x4010d000) libc.so.6 => /lib/i686/libc.so.6 (0x40186000) libdl.so.2 => /lib/libdl.so.2 (0x402b6000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) [root@vmsurfrider bin]# ldd imapd libsasl.so.7 => /usr/local/lib/libsasl.so.7 (0x40018000) libssl.so.1 => /usr/lib/libssl.so.1 (0x400c6000) libcrypto.so.1 => /usr/lib/libcrypto.so.1 (0x400f3000) libdb-3.1.so => /lib/libdb-3.1.so (0x401af000) libnsl.so.1 => /lib/libnsl.so.1 (0x40228000) libc.so.6 => /lib/i686/libc.so.6 (0x4023f000) libdl.so.2 => /lib/libdl.so.2 (0x4036f000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x40374000) libpam.so.0 => /lib/libpam.so.0 (0x403a2000) libresolv.so.2 => /lib/libresolv.so.2 (0x403aa000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) [root@vmsurfrider bin]# ldd pop3d libsasl.so.7 => /usr/local/lib/libsasl.so.7 (0x40018000) libssl.so.1 => /usr/lib/libssl.so.1 (0x400c6000) libcrypto.so.1 => /usr/lib/libcrypto.so.1 (0x400f3000) libdb-3.1.so => /lib/libdb-3.1.so (0x401af000) libnsl.so.1 => /lib/libnsl.so.1 (0x40228000) libc.so.6 => /lib/i686/libc.so.6 (0x4023f000) libdl.so.2 => /lib/libdl.so.2 (0x4036f000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x40374000) libpam.so.0 => /lib/libpam.so.0 (0x403a2000) libresolv.so.2 => /lib/libresolv.so.2 (0x403aa000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) [root@vmsurfrider libexec]# ldd slapd libsasl.so.7 => /usr/lib/libsasl.so.7 (0x40024000) libssl.so.1 => /usr/lib/libssl.so.1 (0x4002f000) libcrypto.so.1 => /usr/lib/libcrypto.so.1 (0x4005c000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x40118000) libresolv.so.2 => /lib/libresolv.so.2 (0x40146000) libdl.so.2 => /lib/libdl.so.2 (0x40159000) libpthread.so.0 => /lib/i686/libpthread.so.0 (0x4015d000) libc.so.6 => /lib/i686/
RE: Signaled to death by 11 - Don't know what else to try
Thanks everyone for the responses. I rebuilt things yet again to make sure that they are all pointing at the new DB in /usr/local (see the ldd outputs below) and I have the same problem. I rebuilt cyrus-sasl as well and it is also pointing at the /usr/local DB, and imapd is pointing to the new libsasl.so. One thing I have noticed now is that pam_ldap is NOT pointing to the new libsasl.so (/usr/local/lib), it is still pointing to the old one (/usr/lib). Any thoughts on if that would cause the failure? And any thoughts on how I can get it to compile pointing to the /usr/local/lib location? I included /usr/local/lib and /usr/local/include in CPPFLAGS and LDFLAGS when I compiled, so I'm not sure what else to tweak. I'd love to just uninstall all of the Berkeley DB and Cyrus-sasl stuff, but since this is RedHat with all of its inter-dependent packages, I'm afraid if I just force them out, the rest of the system will be unstable. Thanks again. I'd love for this to work, but I'm close to giving up. - John [root@vmsurfrider /root]# ldd /usr/cyrus/bin/master libssl.so.1 => /usr/lib/libssl.so.1 (0x40024000) libcrypto.so.1 => /usr/lib/libcrypto.so.1 (0x40051000) libdb-3.2.so => /usr/local/BerkeleyDB.3.2/lib/libdb-3.2.so (0x4010d000) libc.so.6 => /lib/i686/libc.so.6 (0x401a4000) libdl.so.2 => /lib/libdl.so.2 (0x402d4000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) [root@vmsurfrider /root]# ldd /usr/cyrus/bin/imapd libsasl.so.7 => /usr/local/lib/libsasl.so.7 (0x40018000) libssl.so.1 => /usr/lib/libssl.so.1 (0x4002e000) libcrypto.so.1 => /usr/lib/libcrypto.so.1 (0x4005b000) libdb-3.2.so => /usr/local/BerkeleyDB.3.2/lib/libdb-3.2.so (0x40117000) libnsl.so.1 => /lib/libnsl.so.1 (0x401ae000) libc.so.6 => /lib/i686/libc.so.6 (0x401c5000) libdl.so.2 => /lib/libdl.so.2 (0x402f5000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x402fa000) libpam.so.0 => /lib/libpam.so.0 (0x40328000) libresolv.so.2 => /lib/libresolv.so.2 (0x4033) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) [root@vmsurfrider /root]# ldd /usr/local/lib/libsasl.so.7 libdb-3.2.so => /usr/local/BerkeleyDB.3.2/lib/libdb-3.2.so (0x40017000) libdl.so.2 => /lib/libdl.so.2 (0x400ae000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x400b2000) libpam.so.0 => /lib/libpam.so.0 (0x400e) libresolv.so.2 => /lib/libresolv.so.2 (0x400e8000) libc.so.6 => /lib/i686/libc.so.6 (0x400fb000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2000) [root@vmsurfrider /root]# ldd /lib/security/pam_ldap.so libldap.so.2 => /usr/lib/libldap.so.2 (0x40016000) liblber.so.2 => /usr/lib/liblber.so.2 (0x40041000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x4004b000) libresolv.so.2 => /lib/libresolv.so.2 (0x40079000) libpam.so.0 => /lib/libpam.so.0 (0x4008c000) libdl.so.2 => /lib/libdl.so.2 (0x40094000) libc.so.6 => /lib/i686/libc.so.6 (0x40098000) libsasl.so.7 => /usr/lib/libsasl.so.7 (0x401c9000) libkrb4.so.2 => /usr/kerberos/lib/libkrb4.so.2 (0x401d3000) libdes425.so.3 => /usr/kerberos/lib/libdes425.so.3 (0x401e7000) libkrb5.so.3 => /usr/kerberos/lib/libkrb5.so.3 (0x401eb000) libk5crypto.so.3 => /usr/kerberos/lib/libk5crypto.so.3 (0x40242000) libcom_err.so.3 => /usr/kerberos/lib/libcom_err.so.3 (0x40253000) libssl.so.1 => /usr/lib/libssl.so.1 (0x40255000) libcrypto.so.1 => /usr/lib/libcrypto.so.1 (0x40282000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2000) libdb-3.2.so => /usr/local/BerkeleyDB.3.2/lib/libdb-3.2.so (0x4033f000) -Original Message- From: Tarjei Huse [mailto:[EMAIL PROTECTED]] Sent: Monday, July 30, 2001 4:41 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Signaled to death by 11 - Don't know what else to try Hi, > I would sugges to have only one valid berkeley db version in your > system (either 3.1 or 3.2), because otherwise you might encounter > errors of the third art ;-) Especially on building cyrus imap I already > found out, that it is better to have only one (and the most actual one) Also, make sure that you build cyrus with the same version as you build cyrus-sasl with. If using rh, i suggest getting the latest and greatest rpms for rh7.1, and the src rpm for cyrus sasl. Then , -Uvh the db rpms, rpm -ba cyrus-sasl.spec and the -Uvh the rpms. Thus you are sure there is nothing wrong. Of course, the best solution is to build sasl from src. Also, if ldap, use the ldap sasl patch. To the fine men (and women) coding the sasl 2.0 libs. PLEASE include ldap auth support! Tarjei Huse 920 63 413
saslpasswd and /dev/random
This isn't a cyrus-imapd problem, and in fact I don't even believe it is a cyrus-sasl problem, but I'm hoping someone on this list has come across a similar issue and has found a reasonable resolution. I am working with RedHat 7.1 with a 2.4.2 kernel, and I have run into a problem with saslpasswd. When using saslpasswd to set a user's password (or create a new user), it hangs indefinietly. Checking logs, I found that it was hanging while trying to set the PLAIN password. Digging through some archives, I found references to problems with /dev/random, and tried the following; % cat /dev/random Sure enough, /dev/random is blocked. From what I have gathered from yet more archives, /dev/random is seeded by the kernel with random input from things like the keyboard and the mouse, and when the entropy pool runs too low, the device blocks as a security precaution. Fair enough. The problem is, this machine is in a data center, so it has no keyboard and no mouse, so I believe it is not getting enough random input to keep the entropy pool sufficiently seeded. I have "fixed" the problem by linking /dev/random to /dev/urandom, but I know this is not a reasonable long term fix (not that good in the short term, either). Has anyone come across a reasonable way to keep /dev/random seeded on a machine with no keyboard or mouse, or with a good alternative to /dev/random? Thanks for the help - John [EMAIL PROTECTED]
RE: saslpasswd and /dev/random
Thanks for the reply. I'll head down that road and see if it clears up my problem. From looking at the web site you gave a link to and the EGD site, it looks like what I'm looking for. I'll be sure to post my progress to the list. Thanks again - John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Amos Gouaux Sent: Monday, August 06, 2001 10:35 PM To: Subject: Re: saslpasswd and /dev/random I don't know if it would even relate at all, but I noticed on the openssl list some comments about /dev/random blocking. I got the impression that using prngd might actually be better(?) faster(?) than using /dev/random on some systems. Openssl 0.9.7 when released will even be able to automatically find the prngd socket on most systems. I guess you could try that route and see how it goes. You should be able to get prngd from: ftp://ftp.aet.tu-cottbus.de/pub/postfix_tls/related/prngd/ -- Amos
Re: CYRUS IMAP server with Microsoft Outlook Express client. "Sent Items" and "Drafts" CAN now be stored on the IMAP server. :-)
- Original Message - From: "Alain Turbide" <[EMAIL PROTECTED]> To: "James Courtier-Dutton" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, September 21, 2001 4:32 PM Subject: Re: CYRUS IMAP server with Microsoft Outlook Express client. "Sent Items" and "Drafts" CAN now be stored on the IMAP server. :-) > Except now, you will not be able to access other namespaces or publicly > accessable directories. That's the one problem with doing this. The only > other way is to modify the registry entry to allow setting the sent items > folder to INBOX.Sent Items. The other other way is to use the alternate namespace. That allows "Sent Items" etc to be on the server while giving access to other namespaces (though there's still a slight problem because OE will only show folders in the Folders window that are subscribed). John > > Alain > > - Original Message - > From: "James Courtier-Dutton" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, September 21, 2001 10:58 AM > Subject: CYRUS IMAP server with Microsoft Outlook Express client. "Sent > Items" and "Drafts" CAN now be stored on the IMAP server. :-) > > > > For everyone's information. > > I could not find this info anywhere on the web, so I post it here in the > > hope someone will add it to the cyrus imap documentation. > > > > This has been tested with Outlook Express Ver 5 and Ver 6. > > > > First of all, create the user folders. > > Example for user jcd, the output from cyradm->lm would be: - > > user.jcd > > user.jcd.Drafts > > user.jcd.Sent Items(This one might need to be created in Outlook > > express, because "cyradm" does not like spaces.) > > > > then... > > In Microsoft Outlook Express, goto: - > > Tools->Accounts > > Select the mail server, then click "Properties" > > Click on the IMAP tab. > > Then fill in the boxes as follows: - > > Folders > > Root folder path: INBOX <- This is the IMPORTANT bit. The rest are > > defaults. > > Tick/Untick: Check for new messages in all folders > > Special Folders > > TICK: Store special folders on IMAP server > > Sent Items path: Sent Items > > Drafts path: Drafts > > > > This should stop Outlook express storing sent items etc. all locally. > > > > I hope this helps. > > I only found this out by looking at sniffer traces. > > > > Cheers > > James > > > > > > > > > > > > -- > > Nothing in this world is exactly what it appears to be. > > > > > >
Re: Can't deliver to INBOX.folder
Do you a have Unix style `From ' header on the message? I pulled my hair out over the same problem. Depending on how procmail is invoked, procmail will add a `From ' header and deliver will silently discard the message. John Capo IRBS Engineering, Inc. Quoting Louis LeBlanc ([EMAIL PROTECTED]): > I am having a problem getting mail delivered to a mailbox. I am > seeing the +folder coming out of sendmail to procmail, and deliver is > being called as described in the manpage for folder delivery, but the > message still gets dumped into the INBOX. > > Any idea how to fix this? I don't know what in my config might be > relevant, so just let me know what info I should provide here. >
Re: SASL LDAP patch - way to specify multiple servers?
Hi Kevin, Most of the LDAP libraries (for sure OpenLDAP which is what we are using) allow you to specify multiple redundant LDAP servers in the list separated by spaces. This works in a failover configuration. If a query to the first times out, it goes to the second, then the third, etc. We actually use three entries, "ldap ldap1 ldap2". ldap itself is set up in dns to round robin to the ip's of ldap1 and ldap2. This gives us load balancing and failover (albeit at a pretty long timeout interval if ldap1 is down and the dns round robin gives the ip address for ldap1. Hope this helps, John Wade Quoting "Kevin M. Myer" <[EMAIL PROTECTED]>: > Hello, > > I'm using the patch that allows LDAP authentication with the SASL > libraries. Is > there a way to specify multiple servers to bind to so that in the event > that a > directory server becomes unavailable, a backup could be used? > > Short of that, what are folks doing in terms of > high-availiblity/redundancy for > LDAP? I've thought through scenarios of using heartbeat to determine > which > machines are up and updating DNS accordingly. I also suppose you could > do > something with a virtual IP address in a similar manner and actually get > some > load balanacing out of it too but haven't a clue where to start with > that. > > So what are you doing with LDAP to make sure its available all the > time? > > THis also spills over into postfix for the same reasons: if the main > directory > server goes down, mail will start to bounce since my virtual maps are in > LDAP. > > Any thoughts or suggestions would be greatly appreciated. > > Kevin > > -- > Kevin M. Myer > Systems Administrator > Lancaster-Lebanon Intermediate Unit 13 > (717) 560-6140 > > > > > > John Wade Director of Systems and Network Services Oakton Community College Des Plaines, IL 60016 847-635-2602
Re: Locking IMAP Processes Workaround
Hi All, We just setup two new mail servers on Redhat 7.0 (2.2.19 kernel) using: Cyrus 2.0.16 SASL 1.5.24 (from source) Berkeley DB 3.1.17-5 (redhat rpm) Authentication via LDAP openLDAP 1.2.11-15 (redhat RPM) using a hacked version of LDAP pwcheck from http://www.linc-dev.com/Files/pwcheck_ldap.c.txt MTA is qmail-1.03 managed by daemontools-0.76 with tcpserver from ucspi-tcp-0.88 Qmail calls Cyrus's deliver through a shell script. Hardware HP LH4 Dual P3 Xeon - 500Mhz with (2GB, alas only 1GB usable), 12 - 18GB 15K RPM Ultra3 (160Mb/s) drives in a RAID 5 array and a Gig Ethernet card. In addition to this, I am running websieve, easysieve, IMP 2.2.5 for webmail, mrtg and qmail-mrtg for monitoring and ezmlm 0.53 with ezmlm-idx for mailing lists. I was very happy to get all this running and all 20,000+ of our user's accounts transferred over from our old Cyrus 1.5.x servers. Thanks to everyone who has ever posted to this list, it was an invaluable resource! Unfortunately since the upgrade, on the more heavily used employee box (1,300 users, 200+ simultaneous active), we have been experiencing the problem described in a previous posting.Twice in the two weeks we have been up, it appears that an IMAP process locks up a mailbox. Subsequent attempts to access the mailbox lock up additional IMAP processes and then lmtpd processes attempting to deliver to this mailbox get hung up. Eventually if we are not paying attention, we block 10 lmtpd processes and then mail delivery stops since I set the maximum local concurrent deliveries to 10 in qmail. The workarounds recommended below seem to work (Thanks for posting this to the list), but I was wondering if anyone has any ideas as to what is the root cause of this problem?I tried to search the archive, but was unable to find the complete thread of the discussion referenced here. Can someone point me to some relevant keywords or a date range to take a look at? Any help would be most appreciated, Thanks, John Wade "John C. Amodeo" wrote: > Greetings, > > A while back there was some discussion on the list about Cyrus imap > processes hanging or locking a users mailbox, and the only 2 ways to > rectify the problem was to: > > 1) Hunt down the PID that was waiting for an exclusive lock and kill it > (thus unfreezing the lock and allowing other processes such as LMTP to > deliver messages to the mailbox or... > 2) Restart the Cyrus master process, which also fixes the problem, but > kicks everyone of the server. > > This is actually happening as frequently as every few weeks for us, > where a user will try to delete a message, or copy a message from the > Inbox to a sub folder, and everything locks. Then, because of the lock, > Postfix (or Sendmail) have to defer mail because neither can deliver > through LMTP. This problem will not go away until the sysadmin is > notified and has a chance to log into the server and kill the IMAP Pids > for this user. > > I wanted to share with everyone two (somewhat dirty) scripts we've > hacked up to make our lives easier. If anyone wished to spice these up > and modify them for the better, please do. > > Script 1: "kill_proc" - Simple Shell Script for use on the local Unix > file system by the Root user > -- > #!/bin/sh > # > # Kill all Cyrus IMAP Pids for a particular user on the server > # Use: sh kill_proc > # Example: [root@server]# sh kill_proc /var/imap/proc joeblow > > if pushd $1; then > kill `grep $2 * | cut -f1 -d":"`; > rm -i `grep $2 * | cut -f1 -d":"`; > echo "IMAP Pids Killed"; > popd; > else > echo "Bad Directory"; > fi > -- > > Script 2: "kill_proc.cgi" - Web-based version, written in Python, that > is designed so if the System Administrator is not around, a user can > kill their own Pids by going to a web page. This works by acquiring the > IP address of the web browser the user is coming in from and using this > address to grep the /var/imap/proc directory and kill any Pids that are > associated with the IP Address. This file needs to be placed in your > cgi-bin directory, with the following permissions: -rwsr-x--- cyrus > apache (apache could also be 'nobody') Not 100% secure, but the most > damage that could be done is someone spoofing IP addresses and killing > Imap processes that don't belong to them. I am thinking of adding some > sort of Imap authentication for this, but haven't had a chance... > -- > #!/usr/bin/python > import os, sys, string > print "Content-Type: text/html\n\n" > > ## Variables To Change: > ## apacheid = uid of the web user - usually nobody or apache > ## path = path to the Cyrus proc
Locking problem in Cyrus 2.0.16 Revisited
098 cyrus memREG8,1 1564413 633989 /lib/libdb-3.1.so imapd 3098 cyrus memREG8,1 243921 634089 /lib/libresolv-2.2.so imapd 3098 cyrus memREG8,1 409599 634077 /lib/libnsl-2.2.so imapd 3098 cyrus memREG8,1 5155229 634073 /lib/libc-2.2.so imapd 3098 cyrus memREG8,183128 634074 /lib/libcrypt-2.2.so imapd 3098 cyrus memREG8,133965 633991 /lib/libpam.so.0.72 imapd 3098 cyrus memREG 8,15 270336 48509 /var/imap/db/__db.004 imapd 3098 cyrus memREG 8,1598304 48516 /var/imap/db/__db.003 imapd 3098 cyrus memREG 8,15 11272192 48558 /var/imap/db/__db.002 imapd 3098 cyrus memREG 8,1524576 48564 /var/imap/db/__db.005 imapd 3098 cyrus memREG 8,11 178 392004 /var/spool/imap/6/use r/gost9796/cyrus.header imapd 3098 cyrus memREG 8,11 888 394636 /var/spool/imap/6/use r/gost9796/cyrus.index imapd 3098 cyrus memREG 8,11 178 65547 /var/spool/imap/6/use r/gost9796/Trash/cyrus.header imapd 3098 cyrus memREG8,1 251005 634084 /lib/libnss_files-2.2 .so imapd 3098 cyrus memREG8,1 310594 634087 /lib/libnss_nisplus-2 .2.so imapd 3098 cyrus memREG8,1 294539 634086 /lib/libnss_nis-2.2.s o imapd 3098 cyrus memREG8,168049 634083 /lib/libnss_dns-2.2.s o imapd 3098 cyrus memREG 8,1118824 394643 /var/spool/imap/6/use r/gost9796/cyrus.cache imapd 3098 cyrus memREG 8,11 108 65281 /var/spool/imap/6/use r/gost9796/Trash/cyrus.index imapd 3098 cyrus memREG 8,11 932 65282 /var/spool/imap/6/use r/gost9796/Trash/cyrus.cache imapd 3098 cyrus0u IPv45448713 TCP romulan.oakton.edu:im ap2->occ10-2-134.oakton.edu:1162 (CLOSE_WAIT) imapd 3098 cyrus1u IPv45448713 TCP romulan.oakton.edu:im ap2->occ10-2-134.oakton.edu:1162 (CLOSE_WAIT) imapd 3098 cyrus2u IPv45448713 TCP romulan.oakton.edu:im ap2->occ10-2-134.oakton.edu:1162 (CLOSE_WAIT) imapd 3098 cyrus3w FIFO0,0 964 pipe imapd 3098 cyrus4u IPv4963 TCP *:imap2 (LISTEN) imapd 3098 cyrus5u REG 8,15 893770 48501 /var/imap/db/log. 04 imapd 3098 cyrus6r REG8,1 940 422678 /etc/cyrus.conf imapd 3098 cyrus7r REG8,1 940 422678 /etc/cyrus.conf imapd 3098 cyrus8r REG8,1 940 422678 /etc/cyrus.conf imapd 3098 cyrus9r REG 8,15 893770 48501 /var/imap/db/log. 04 imapd 3098 cyrus 10u REG 8,15 6717440 28 /var/imap/mailboxes.d b imapd 3098 cyrus 11u unix 0xe7398b00 5448712 socket imapd 3098 cyrus 12u REG 8,15 59 32538 /var/imap/proc/3098 imapd 3098 cyrus 13u unix 0xe7398840 5448714 socket imapd 3098 cyrus 14u REG 8,11 178 392004 /var/spool/imap/6/use r/gost9796/cyrus.header imapd 3098 cyrus 15u REG 8,11 888 394636 /var/spool/imap/6/use r/gost9796/cyrus.index imapd 3098 cyrus 16u REG 8,1118824 394643 /var/spool/imap/6/use r/gost9796/cyrus.cache imapd 3098 cyrus 17u REG 8,15 114 177106 /var/imap/user/g/gost 9796.seen.NEW (deleted) imapd 3098 cyrus 18u REG 8,11 178 65547 /var/spool/imap/6/use r/gost9796/Trash/cyrus.header imapd 3098 cyrus 19u REG 8,11 108 65281 /var/spool/imap/6/use r/gost9796/Trash/cyrus.index imapd 3098 cyrus 20u REG 8,11 932 65282 /var/spool/imap/6/use r/gost9796/Trash/cyrus.cache imapd 3098 cyrus 21u REG 8,15 122 177253 /var/imap/user/g/gost 9796.seen.NEW (deleted) imapd 3098 cyrus 22u REG 8,15 15 64358 /var/imap/quota/g/use r.gost9796.NEW (deleted) imapd 3098 cyrus 25u REG 8,15 15 65101 /var/imap/quota/g/use r.gost9796 >From this I would read that the problem occured updating the seen file after doing a message copy from one mailbox to another, probably using Netscape Communicator's "move to trash" feature. This is still sitting out there (7 days later.) Is there any other info I can pull off of this before I try to get this user's mailbox back in service? Other relevant info: Redhat 7.0 (2.2.19 kernel) using: Cyrus 2.0.16 SASL 1.5.24 (from source) Berkeley DB 3.1.17-5 (redhat rpm) Authentication via LDAP openLDAP 1.2.11-15 (redhat RPM) using a hacked version of LDAP pwcheck from http://www.linc-dev.com/Files/pwcheck_ldap.c.txt MTA is qmail-1.03 managed by daemontools-0.76 with tcpserver from ucspi-tcp-0.88 Qmail calls Cyrus's deliver through a shell script. Thanks in advance, John Wade
Re: Locking problem in Cyrus 2.0.16 Revisited
Hi All, I am trying to work through our file locking problem in Cyrus 2.0.16. Since the problem appears to be tied to locking the seen file, I have recompiled with SEEN_DEBUG turned on to see if I can get any more info. I will let you know anything I find. Any other suggestions on how to gather more info would be appreciated. I did have a couple of questions that came out from looking at the source. First, in seen_db.c although all the comments reference the Berkely DB structure for the seen file, there is a define statement /* choose "flat" or "db3" here */ #define DB (&cyrusdb_flat) This seems to mean that Cyrus uses the old style text file to store the seen info rather than a Berkely DB. Is there a particular reason this is defined this way by default? Is the Berkeley DB style seen format safe to use and/or preferred? Second, In the locking architecture used in lib/lock_flock.c, the flock function is called in a blocking fashion with the LOCK_EX operation rather than or'ing this with the LOCK_NB.As a result, if any process gets a lock on a file and fails to release it, all subsequent processes with block permanently. While in a perfect world, this would be fine, since locks appear to be released when processes terminate, in my world, this seems to cause a cascade failure where once a mailbox gets locked, eventually mail delivery dies when all of my deliver processes are hung up waiting for the user's mailbox to be unlocked. Is there any reason not to try to call flock in a non-blocking fashion with some limited number of retries ( perhaps delayed with additional attempts tried at increasing intervals) until finally after 5 minutes or so we fail with an error. I was going to give this a try unless somebody already knows why this is a bad idea. Third, I suspect (after looking at the open files in use by the imap process after terminating an IMAP connection) that the problem may be exacerbated by, or related to process reuse, can anyone point me to how to disable this feature for imapd ? Thanks in advance for your help, John Wade
Re: Locking problem in Cyrus 2.0.16 Revisited
Hi Larry,
Thanks for the info, I finally had to shutdown Cyrus and restart since
the user's Mailbox had been locked out since 10/24.The problem
occurred 7 or 8 times this week on our other mail server however, so I am
sure I will be able to reproduce it next week and try to get more info.
I did save an lsof from this incident but I wasn't aware of how to get the
filename out of gdb before.From the backtrace, I assumed it was trying
to get a lock on the seen file, but I will verify for sure next time.
Thanks for the help, you folks have really put together a nice package
and we all appreciate the support you provide through this list.
John
Lawrence Greenfield wrote:
>Date: Wed, 31 Oct 2001 01:50:21 -0600
>From: John Wade <[EMAIL PROTECTED]>
>
>Hi Cyrus Experts,
>
>Back on September 4, 2001, there was a discussion on this list
>about a locking problem in Cyrus 2.0.16 where an imapd process
>would get a lock on a seen file and not release it an all other
>attempts to access that mailbox either via imapd or lmptd would
>await the lock. There was a another post about some workaround
>scripts on 10/24, but I never saw a posting if anyone found the
>root cause.
>
>I have a server sitting in this situation right now and I was
>wondering if there was anything I could do to help debug this
>problem.
>
>from gdb, the backtrace on the offending imapd process (PID 3098)
>is:
>
> This doesn't seem to be the offending process; it's the open
> demonstrating the symptom, but much more important is the process that
> is holding the lock that it can't get.
>
> lsof on the file that it is attempting to lock ("print filename" from
> gdb) will show what process is actually holding the lock.
>
> Larry
Re: Locking problem in Cyrus 2.0.16 Revisited
Hi Larry, Thanks for the reply. Comments interspersed below: Lawrence Greenfield wrote: >This seems to mean that Cyrus uses the old style text file to store the >seen info rather than a Berkely DB. Is there a particular reason this >is defined this way by default? Is the Berkeley DB style seen format >safe to use and/or preferred? > > The problem is that a large number of small btree files is > inefficient. If you are interested in using Berkeley db for seen > state (probably more efficient in the long run) look into > "seen_bigdb.c". > > However, it's unlikely that the locking problem you're experiencing > will go away by using Berkeley db---in fact, it will probably be worse > since you won't be able to kill just one process---you'll have to kill > everything and run recovery. > I agree with your assessment, the text files seem more efficient for this purpose. I just got confused by the comments. > [...] >world, this would be fine, since locks appear to be released when >processes terminate, in my world, this seems to cause a cascade failure >where once a mailbox gets locked, eventually mail delivery dies when all >of my deliver processes are hung up waiting for the user's mailbox to >be unlocked. Is there any reason not to try to call flock in a >non-blocking fashion with some limited number of retries ( perhaps >delayed with additional attempts tried at increasing intervals) until >finally after 5 minutes or so we fail with an error. I was going to >give this a try unless somebody already knows why this is a bad idea. > > This obviously can work, but it doesn't really help us find the root > cause of the problem. > I realize this, but I may implement it anyway just because it will make the whole system a little bit more robust. A single programming error or deadlock condition would not take out the server. We would still be able to identify the problem process since the affected user would still be unable to get into their mail, and there would be a lot fewer processes to wade through. >Third, I suspect (after looking at the open files in use by the imap >process after terminating an IMAP connection) that the problem may be >exacerbated by, or related to process reuse, can anyone point me to how >to disable this feature for imapd ? > > It's really crucial to understand what process is holding this lock. > It might not be reused---it's probably blocked doing something else > and never releasing the lock. imapds should never do something that > will block for a long time while holding a lock but evidentally > something is wrong. > > Finding the process that holds the lock, doing a backtrace on it and > (even better) figuring out how it gets into that state is really the > crucial issue for fixing this problem. > I agree and I will do everything I can to locate the process next time. I thought I had done a backtrace on every process accessing files in the user's directory (as indentified by an lsof), but I must have missed the guilty one. I also tried to work the problem the other way by looking at /proc/locks, but there were too many to track down and I was not aware of how to easily find a filename associated with an inode number. The problem is that this is of course affecting our heavily used production systems so I usually have a limited window of time to debug the problem before the users will start to scream. The thing I found funny from the lsof was that even though I had a process blocked trying to access the seen file, I had numerous open file entries from later processes to a series of deleted files .seen.NEW. Have not had a chance to go through the seen code yet to see when it creates a .NEW file, but I was supprised to see this for processes that were started later, thinking that they would have tried to get a lock on the seen file first. (see below) Will send more when I track down the process.Thanks again for your help, John [root@romulan /root]# lsof | grep gost9796.seen imapd 3098 cyrus 17u REG 8,15 114177106 /var/imap/user/ g/gost9796.seen.NEW (deleted) imapd 3098 cyrus 21u REG 8,15 122177253 /var/imap/user/ g/gost9796.seen.NEW (deleted) imapd 3216 cyrus 17u REG 8,15 114176458 /var/imap/user/ g/gost9796.seen.NEW (deleted) imapd 3217 cyrus 19u REG 8,15 114177533 /var/imap/user/ g/gost9796.seen.NEW (deleted) imapd 3376 cyrus 18u REG 8,15 102177534 /var/imap/user/ g/gost9796.seen.NEW (deleted) imapd 3466 cyrus 17u REG 8,15 102177536 /var/imap/user/ g/gost9796.seen.NEW (deleted) imapd 3485 cyrus 18u REG 8,15 10217753
Re: Locking problem in Cyrus 2.0.16 Revisited
OK, had another crash today, but unfortunately the symbol table info for the lib files was not loading properly so I could not get full details.I did a make clean in the lib directory, recompiled cyrus and tested gdb and now the symbol table is loading properly. Next time I should be able to get full details. Here is what I had so far. The problem process appeared to be updating the seen file when doing a message copy. More details next crash Thanks, John Full details --- When I checked, I had three blocked imap processes for the user and seven lmtpd processes. cyrus27898 15692 0 Nov09 ?00:00:00 imapd cyrus21991 15692 0 Nov09 ?00:00:00 imapd cyrus 5332 15692 0 Nov09 ?00:00:00 imapd cyrus17070 15692 0 Nov09 ?00:00:00 lmtpd cyrus28341 15692 0 06:55 ?00:00:00 lmtpd cyrus29862 15692 0 13:42 ?00:00:00 lmtpd cyrus 9286 15692 0 16:01 ?00:00:00 lmtpd cyrus 2003 15692 0 18:52 ?00:00:01 lmtpd cyrus10304 15692 0 19:17 ?00:00:01 lmtpd cyrus23400 15692 0 19:56 ?00:00:00 lmtpd A quick check of the lmtpd's and two of the imap processes indicated that they were all blocked trying to access files locked by process 21991 for example: -- [root@borg /root]# gdb /usr/cyrus/bin/imapd 5332 0x4028a8a1 in __flock () from /lib/libc.so.6 (gdb) bt #0 0x4028a8a1 in __flock () from /lib/libc.so.6 #1 0x8079d27 in lock_reopen () #2 0x8062028 in mailbox_lock_header (mailbox=0xbfffedb0) at mailbox.c:812 #3 0x805f65d in append_setup (as=0xbfffedb0, name=0xb2c0 "user.lraven.Trash", format=0, userid=0x810fdd8 "lraven", auth_state=0x8110280, aclcheck=16, quotacheck=3061) at append.c:113 #4 0x80599ff in index_copy (mailbox=0x80fff40, sequence=0x810fce8 "6194", usinguid=1, name=0xb2c0 "user.lraven.Trash", copyuidp=0xb2bc) at index.c:1220 #5 0x80531eb in cmd_copy (tag=0x810fc08 "27", sequence=0x810fce8 "6194", name=0x810fd58 "INBOX.Trash", usinguid=1) at imapd.c:3192 #6 0x804d878 in cmdloop () at imapd.c:791 #7 0x804cf50 in service_main (argc=1, argv=0xbe14, envp=0xbe1c) at imapd.c:546 #8 0x804bd00 in main () #9 0x401d2f31 in __libc_start_main (main=0x804b8fc , argc=1, ubp_av=0xbe14, init=0x804a9e4 <_init>, fini=0x807e96c <_fini>, rtld_fini=0x4000e274 <_dl_fini>, stack_end=0xbe0c) at ../sysdeps/generic/libc-start.c:129 (gdb) up #1 0x8079d27 in lock_reopen () (gdb) up #2 0x8062028 in mailbox_lock_header (mailbox=0xbfffedb0) at mailbox.c:812 812 r = lock_reopen(mailbox->header_fd, fnamebuf, &sbuf, &lockfailaction ); (gdb) print fnamebuf $1 = "/var/spool/imap/3/user/lraven/Trash/cyrus.header\000*-@", '\000' , " Þÿ¿\000\000\000\000\002\000\000\000\000\000\000\Þÿ¿\000\000\000 \000\000\000\000\000L®-@\000\000\000\000\000\000\000\000|\027\000@|\n\000@\005\b \000\000\000\000\000\000\000\000\000\000\016\\000\200\201\000\000\001\000\00 0\000ÿ\001\000\000\000\000\000\000=6\000\000\000\000\000\000\000\000\000\000ì\00 6\000\000\000\000\000\000\000\020\000\000\b\000\000\000\000\000\000\000Ílì;\000\ 000\000\000ITì;L®-@ITì;\000\000\000\000\016\000"... (gdb) quit (gdb) quit The program is running. Quit anyway (and detach it)? (y or n) y Detaching from program: /usr/cyrus/bin/imapd, Pid 5332 [root@borg /root]# lsof -p 5332 | grep cyrus.header imapd 5332 cyrus memREG8,5 174 3145792 /var/spool/imap/3/use r/lraven/cyrus.header imapd 5332 cyrus memREG8,5 174 2998385 /var/spool/imap/3/use r/lraven/Trash/cyrus.header imapd 5332 cyrus 14u REG8,5 174 3145792 /var/spool/imap/3/use r/lraven/cyrus.header imapd 5332 cyrus 19u REG8,5 174 2998385 /var/spool/imap/3/use r/lraven/Trash/cyrus.header [root@borg /root]# grep 2998385 /proc/locks 6: FLOCK ADVISORY WRITE 21991 08:05:2998385 0 9223372036854775807 e03b23c0 e03 b2be0 e03b28c0 f57a4d60 6: -> FLOCK ADVISORY WRITE 27898 08:05:2998385 0 9223372036854775807 f57a4d60 f68f5aa0 6: -> FLOCK ADVISORY WRITE 5332 08:05:2998385 0 9223372036854775807 f68f5aa0 0 000 e03b23c0 -- looking at the errant process that had the lock(21991): [root@borg /rosof |gdb /usr/cyrus/bin/imapd 21991 0x4028a8a1 in __flock () from /lib/libc.so.6 (gdb) bt #0 0x4028a8a1 in __flock () from /lib/libc.so.6 #1 0x8079d27 in lock_reopen () #2 0x807b9f7 in starttxn_or_refetch () #3 0x807bb69 in myfetch () #4 0x807bc09 in fetchlock () #5 0x806f933 in seen_readit (seendb=0x810ea30, last
Re: using exim with cyrus-imapd
At 14:37 13/11/01, Cillian wrote: >There's an Exim driver for using LMTP (assuming you're using Cyrus 2.x and a >fairly recent Exim), e.g: > >cyrus_delivery: > driver = lmtp > command = "/usr/local/cyrus/bin/deliver -l" > user = cyrus With exim you can also use the smtp transport to connect directly to the lmtpd daemon in cyrus 2.x over a TCP/IP connection (but not a unix socket). For example here exim connects to the "lmtp" port (as defined in /etc/services) on the localhost: lmtp_delivery: driver = smtp protocol=LMTP hosts = localhost port="lmtp" allow_localhost John
Re: Locking problem in Cyrus 2.0.16 Revisited
ntry was for inode 112788 --- [root@borg /root]# grep 112788 /proc/locks 9: FLOCK ADVISORY WRITE 2122 08:0a:112788 0 9223372036854775807 f68f5a00 f68f5 e60 e03b2280 f57a4ae0 9: -> FLOCK ADVISORY WRITE 2122 08:0a:112788 0 9223372036854775807 f57a4ae0 00 00 f68f5a00 --- This seems to imply the the imapd process had locked the file, and then failed to release the lock and then attempted to lock it again. (and blocked waiting for itself to release the lock) I was suprised to see this block, thinking that a subsequent call to flock() for the same process to the same inode with the same file descriptor should just proceed. (In fact a test program I wrote worked this way, the only time i had it block was when I reopened the file with a new file descriptor and tried to lock it again.)Whether or not it should block, clearly there was a bug somewhere that did not unlock the file when it was supposed to. I still don't understand under what conditions the imapd creates a new seen file, all the testing I did left the seen file with the original inode number, but clearly here the processes are creating these .NEW files and then deleting them. I do have a little more info about this specific crash if it would be helpful, and I think I will have to recompile with seen debug turned on on this box to see if we can get more info about when it failed to unlock. (I am just a little afraid of the log file sizes, since I already did this on my other less heavily used box and the logs are huge.) Larry, do you have any other suggestions on what to look at?I did write a patch for the lock_reopen subroutine that will keep retrying the lock non-blocking and then eventually time out with an error to syslog. This works in test, but I was reluctant to put it in production, since I wanted to try to get more info for you. Based on the evidence here I could also modify the lock_reopen function to try to unlock the file first before attempting the lock, but all of these are work arounds. Any suggestions would be appreciated, it is very reproducible in my environment, Thanks, John > > > Lawrence Greenfield wrote: > > > > > It's really crucial to understand what process is holding this lock. > > > It might not be reused---it's probably blocked doing something else > > > and never releasing the lock. imapds should never do something that > > > will block for a long time while holding a lock but evidentally > > > something is wrong. > > > > > > Finding the process that holds the lock, doing a backtrace on it and > > > (even better) figuring out how it gets into that state is really the > > > crucial issue for fixing this problem. > >
Re: Lot of imapd processes hangin around...
Hi Wolfgang,
I can't speak to the master hang problem, but the prefork = 10 lines in
your cyrus.conf file tell the master process to always create 20 more imapd
processes than you have active clients.Unless you have an extremely high
load, I doubt you need to prefork ten processes each for imap and imaps.
If you are trying to debug this, you could set prefork to 0 and see if it
makes any difference.
Hope this helps,
John Wade
Wolfgang Trexler wrote:
> Hi there,
>
> I've set up a new mail server (Cyrus 2.0.16) a few weeks ago and it's
> not working as smooth as I'm accustomed to with Cyrus. From time to time
> the server stops excepting new imap connections (from different clients)
> and seems unreachable from outside. We had this situation three times by
> now. Kill the master process with -TERM and restart it did solve the
> problem. Unfortunately I was out of office at that times and therefore
> could not look at the machine as it happend for further investigation.
>
> Anyway, examination of the log files did not bring up any clues, nothing
> seemed extraordinary. What I found is that, despite there is only one
> user on the machine right now, I've more than 60 imapd instances
> running. Some of them for a quite long time, since the last restart of
> the master process (2nd Nov.).
>
> It would be nice if you could help me out or give me further tips how to
> find the problem!
>
> The machine is Linux 2.4.10 i686, I compiled the cyrus with:
> ./configure --prefix=/var/apps/cyrus-imapd
> --with-cyrus-prefix=/var/apps/cyrus-imapd/server --with-auth=unix
> --enable-netscapehack --with-cyrus-group=smmsp
>
> Enclosed my configuration as well as a snapshot of the process list.
>
> best regards
> Wolfgang
> --
> Wolfgang Trexler <[EMAIL PROTECTED]>
> For completely outdated information see http://members.ping.at/wolfman/
>
> cyrus.conf:
> # standard standalone server implementation
>
> START {
> # do not delete these entries!
> mboxlist cmd="ctl_mboxlist -r"
> deliver cmd="ctl_deliver -r"
>
> # this is only necessary if using idled for IMAP IDLE
> # idledcmd="idled"
> }
>
> # UNIX sockets start with a slash and are put into
> /var/apps/imap/sockets
> SERVICES {
> # add or remove based on preferences
> imap cmd="imapd" listen="imap" prefork=10
> imaps cmd="imapd -s" listen="imaps" prefork=10
> # pop3 cmd="pop3d" listen="pop3" prefork=3
> # pop3s cmd="pop3d -s" listen="pop3s" prefork=1
> sieve cmd="timsieved" listen="sieve" prefork=3
>
> # at least one LMTP is required for delivery
> # lmtp cmd="lmtpd" listen="lmtp" prefork=0
> lmtpunix cmd="lmtpd" listen="/var/apps/imap/socket/lmtp"
> prefork=1
> }
>
> EVENTS {
> # this is required
> checkpointcmd="ctl_mboxlist -c" period=30
>
> # this is only necessary if using duplicate delivery suppression
> delprune cmd="ctl_deliver -E 3" period=1440
> }
>
> imapd.conf
> configdirectory: /var/apps/imap
> partition-default: /var/apps/imap/spool
> admins: cyrus root
> srvtab: /var/apps/imap/srvtab
> allowanonymouslogin: no
> # sasl_passwd_check: shadow
> sasl_passwd_check: sasldb
> sieveusehomedir: false
> tls_cert_file: /var/apps/imap/server.pem
> tls_key_file: /var/apps/imap/server.pem
> sieveusehomedir: false
> sievedir: /var/apps/imap/sieve
> sendmail: /usr/sbin/sendmail
>
> Process list:
> cyrus28447 1 0 Nov02 ?00:00:00
> /var/apps/cyrus-imapd/server/bin/master
> cyrus28454 28447 0 Nov02 ?00:00:00 timsieved
> cyrus28456 28447 0 Nov02 ?00:00:00 imapd
> cyrus28458 28447 0 Nov02 ?00:00:00 timsieved
> cyrus28478 28447 0 Nov02 ?00:00:00 timsieved
> cyrus 6392 28447 0 Nov05 ?00:00:00 imapd
> cyrus 6466 28447 0 Nov05 ?00:00:00 imapd
> cyrus 6836 28447 0 Nov05 ?00:00:00 imapd
> cyrus 7688 28447 0 Nov05 ?00:00:00 imapd
> cyrus11312 28447 0 Nov06 ?00:00:00 imapd
> cyrus11359 28447 0 Nov06 ?00:00:00 imapd
> cyrus11833 28447 0 Nov06 ?00:00:00 imapd
> cyrus11979 28447 0 Nov06 ?00:00:00 imapd
> cyrus12177 28447 0 Nov06 ?00:00:00 imapd
> cyrus12299 28447 0 Nov06 ?00:00:00 imapd
> cyrus15980 28447 0 Nov07 ?00:00:00 imapd
> cyrus16309 28447 0 Nov07 ?00:00:00 imapd
> cyrus17052 28447 0 Nov07 ?00:00:00 im
Re: moving cyrus to another server
Hi Vincent, When we migrated two servers from Cyrus 1.5.x to Cyrus 2.0.16 on new hardware we just shutdown cyrus and the MTA and used nfs to copy the 35GB of files. I movied everything in: /var/spool/imap, var/imap/user, /var/imap/quota and the /var/imap/mailboxes file. As a previous post indicated, you may have to do a ctl_mboxlist dump and import if you are using the 2.0.x berkeley db and if you are using sieve, you will have to grab the sieve files. The only other cleanup I had to do was to fix file ownership, which was my own fault for not using the same uid for the cyrus user on both boxes. Since we use external authenticatio via LDAP, I did not have to worry about moving that. Of course, since it was an upgrade we did a lot of other things in the move including hashing the user and quota directories, reditributing our users in a new partition structure and fixing the delete permissions for the admin user in the mailboxes database. If anyone is interested in the full set of steps, I could post it to the list. John Wade > > > Hello, > > Next week I will be moving to another ISP. Is there > > a way to migrate my cyrus imap mailboxes to the new > > server in a painless manner? > > Thanks
Re: moving cyrus to another server - complete steps
> On Thu, Nov 15, 2001 at 09:58:09AM -0600, John Wade wrote: > > > If anyone is interested in the full set of steps, I could post it to the > > list. Hi All, Since a number of people requested it, I am sending my complete list of steps (with added comments) for moving from one Cyrus server to another. Sorry about the size of this posting I used this procedure to migrate two servers from older Pentium Pro hardware running Cyrus 1.5.19 to newer P3 Xeon servers running Cyrus 2.0.16. One server had ~20,000 accounts and 10GB of mail, the other had ~1300 accounts and 35GB of mail. These instructions assume that you have both servers set up and fully tested before moving the users' data. Our new environment uses: RedHat 7.0 (2.2.19 kernel) Cyrus 2.0.16 for IMAP Cyrus SASL 1.5.24 with LDAP authentication (via hacked pwcheck) qmail 1.0.3 as the MTA ezmlm-idx for mailing lists WebSieve and Easysieve for sieve The mail on the old server was all stored in a single 35GB ext2fs file system mounted as /var. Within this file system, we had hashed the mail spool via cyrus partitions using the first letter of the user's login id to choose the partition (i.e. /var/spool/imap/a/ for abelincoln ) This is similar to the new hashmailspool option. On the new server, we had a 190GB array and I was afraid to make this a single file system.In order to end up with a managable number of file systems (of manageable size) , we decided to store mail in 5 - 33GB file systems ( mounted as/var/spool/imap/0, /var/spool/imap/1, /var/spool/imap/2, /var/spool/imap/3 and /var/spool/imap/4) This corresponded to 5 matching Cyrus partitions (0,1,2,3,4) IMPORTANT DISCLAIMER: While I sometimes feel like I know what I am doing, there is no guarranty that I did this in the most efficient way or even that I did it correctly, all I know is that it seems to have worked for me Warning, Since I was using external authentication (via LDAP), there is nothing here about moving the authentication database. The following instructions were designed so that I could cut and paste it to reduce mistakes and speed the conversion. All comments are proceeded by a #Sometimes the instructions call for editing files with vi, in this case, the next set of lines separated by # are what should be the new contents of the edited file. -- #Cleanup newserver # On new server shutdown services # The cyrus and pwcheck scripts are ones I put together to control cyrus and pwcheck. # basically this step was just to kill all existing services on the new box # your steps will differ. /etc/rc.d/init.d/cyrus stop /etc/rc.d/init.d/pwcheck stop /etc/rc.d/init.d/qmailctl stop /etc/rc.d/init.d/httpd stop # Cleanup any existing mail directories, quotas, seen and subscription files, etc that might be #left over from testing rm -f /var/imap/proc/* rm -f /var/imap/mailboxes* rm -f /var/imap/db/*.* rm -f /var/imap/deliverdb/*.db rm -f /var/imap/deliverdb/db/* # delete subscriptions and seen files cd /var/imap/user for dir in `ls -d ?`; do rm -f /var/imap/user/$dir/* ; done # delete quotas cd /var/imap/quota for dir in `ls -d ?`; do rm -f /var/imap/quota/$dir/* ; done # delete sieve scripts (note this is not the default sieve directory) cd /var/imap/sieve for dir in `ls -d ?`; do rm -Rf /var/imap/sieve/$dir/* ; done #Delete the mail spool (note we use multiple partitions in /var/spool/imap) cd /var/spool/imap for dir in `ls -d ?`; do rm -Rf /var/spool/imap/$dir/* ; done # cleanp ezmlm mailing lists # (This step omited from this posting since this is ezmlm specific) # done with cleanup # At this point the new server should be completely cleaned up and # ready for the copy - # Restore Overview # We need to restore all items in # /var/imap/user/ # /var/imap/quota/ # /var/imap/mailboxes (file) # /var/spool/imap/ #NFS Setup. I mounted the new server's file systems on the old server # because we had a problem with the nfs install on the old server, ideally, # I would have mounted the old on the new because then I could have done # it read only and not risked any mistakes. #on newserver, setup an export for each mount point that will need to have files copied to it. vi /etc/exports #--- /var oldserver.oakton.edu(rw,no_root_squash) /var/imap oldserver.oakton.edu(rw,no_root_squash) /var/spool/imap/0 oldserver.oakton.edu(rw,no_root_squash) /var/spool/imap/1 oldserver.oakton.edu(rw,no_root_squash) /var/spool/imap/2 oldserver.oakton.edu(rw,no_root_squash) /var/spool/imap/3 oldserver.oakton.edu(rw,no_root_squash) /var/spool/imap/4 oldserver.oakton.edu(rw,no_root_squash) #--- /etc/rc.d/init.d/nfs stop /etc/rc.d/init.d/nfslock stop /etc/rc.d/init.d/portmap stop /etc/rc.d/init.d/portmap start /etc/rc.d/init
Re: Restoring backup
If it is an ACL problem, ACL's are stored in the mailboxes file.Take a look at the lines for the user's mailboxes, they should look somehing like this: user.jdoe 1 jdoe lrswipcda user.jdoe.Trash 1 jdoelrswipcda The first entry is the mailbox name, the second is the partition and any subsequent entries are user - ACL pairs Normally cyrus sets this default acl (giving full rights to the user) automagically when you create the mailbox I think it is much more likely file ownership or permissions (although you did say you checked permisions) Hope this helps, John Emiliano wrote: > Francesc Guasch Ortiz wrote: > > > > Have you checked to make sure the file permissions were restored correctly? > > > > Yes, that was the very first I did after restoring. > > It was okay. I tested delivering to the mailbox and > > it worked. But I can't read any message. Even the > > ones delivered after the restore. > > Looks like your ACLs have vanished. But I don't know where they're > stored; I just saw the same kind of effects when I accidently removed > all my acls by a script. > > Emile
Re: Restoring backup
Hi Steven, I am not really sure, so maybe someone else can speak to this. The mailboxes file in 1.x is is just a text file, so you can edit it manually. I would have to look in the reconstruct code to see if there is anything there to recreate the mailboxes file (I don't think there is)If you want to have it match the existing directory structure, you could probably write a perl or shell script that would recursively scan the directories and place entries in the mailboxes file for each directory with some assumed permisions. Since the mailboxes file is "The" database for cyrus mailboxes, I don't know if you can really generate a fresh copy without making a lot of assumptions. I assigned someone here the task of putting together some scripts to verify the mailboxes file versus the /var/spool/imap directory structure vs the seen, subscription and quota files so that I could spot any discrepancies, if we ever get it working, I will send it to the list. Anyone else have a better answer? Thanks, John "Steven J. Sobol" wrote: > On Mon, 19 Nov 2001, John Wade wrote: > > > If it is an ACL problem, ACL's are stored in the mailboxes file. > > Take a look at the lines for the user's mailboxes, they should look > > somehing like this: > > I want to generate a fresh copy of that file. How do I do it, using > 1.6.*? (sorry, I used to know but I forgot) > > -- > JustThe.net LLC - Steve "Web Dude" Sobol, CTO - [EMAIL PROTECTED] > > In another world it may be true that "Information wants to be free." > Directory Assistance, or lack thereof, is a profit center here and now. >- John Myers, speaking in comp.dcom.telecom
Re: SOS: Cyrus 2.0.16 with RedHat 7.1
Try renaming your /etc/sasldb.db to something else - that seemed to do the trick for us. johnh... On Thu, 27 Sep 2001, Eric L'Heureux wrote: > Date: Thu, 27 Sep 2001 15:45:15 -0400 > From: Eric L'Heureux <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: SOS: Cyrus 2.0.16 with RedHat 7.1 > > Hi, > > I need help! I'm trying to install Cyrus 2.0.16 on Red Hat 7.1. > I keep getting "Invalid login" errors when trying to connect from pop or > imap. > > I've set-up Cyrus to use PAM for authentication but it seems to > try looking for a sasldb file. I DO NOT want to use sasldb, I have > already a huge passwd/shadow database and I'm not planning to convert it > to sasldb. > > I've tried lots and lots of things like changing the permission of > the shadow file, changing some pam.d settings, recompiling cyrus with > unix authenication, etc... But I still CANNOT authenticate any users. I > can however use cyradm and create new mailboxes with the cyrus password > stored either in the shadow password file or in the sasldb. > > I also tried to follow the instructions shown at > http://rmrpms.tripod.com/cyrus-imapd/ > but it still does not work. > > Thanks in advance for your help! > > Eric > >
Re: Cyrus 2.0.16 with RedHat 7.1
The first thing you might try to do is determine if cyrus is actually
using pam or if the problem is with your pam configuration.
put a:
auth required pam_warn.so
in your pam configuration file which should place a message in the log
file
(From http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam-5.html
... and the pam_warn module will send a syslog message to auth.notice: )
You also mention that you have configuration files for imap and pop.
>From the configuration guide (at the url above)
The local
configuration of those aspects of system security controlled by Linux-PAM
is contained in one of two places: either the single system file,
/etc/pam.conf; or the
/etc/pam.d/ directory. In this section we discuss the correct syntax of
and generic options respected by entries to these files.
I'm not sure if you have things both places which one takes precidence.
If you determine that pam is being called you can then focus on your
pam configuration.
If you don't see the log message then it is more likely configuration of
cyrus. Note I have PAM in uppercase in imap.conf - I don't know if that
makes a difference.
johnh...
On Fri, 28 Sep 2001, root wrote:
> Date: Fri, 28 Sep 2001 08:22:22 -0400
> From: root <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED], [EMAIL PROTECTED],
> [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: Re: Cyrus 2.0.16 with RedHat 7.1
>
> Hi Everybody,
>
> I have compiled the sources with the "--with-auth=unix" and I also
> tried with "--with-pwcheck_method=pam" but still does not work.
>
> My /etc/imapd.conf file looks like this:
> configdirectory: /var/imap
> partition-default: /var/spool/imap
> admins: cyrus
> allowanonymouslogin: no
> sasl_pwcheck_method: pam
>
> My /etc/cyrus.conf:
> # standard standalone server implementation
>
> START {
> # do not delete these entries!
> mboxlist cmd="ctl_mboxlist -r"
> deliver cmd="ctl_deliver -r"
> }
>
> # UNIX sockets start with a slash and are put into /var/imap/socket
> SERVICES {
> # add or remove based on preferences
> imap cmd="/usr/cyrus/bin/imapd" listen="imap" prefork=0
> imaps cmd="/usr/cyrus/bin/imapd -s" listen="imaps" prefork=0
> pop3 cmd="/usr/cyrus/bin/pop3d" listen="pop3" prefork=0
> pop3s cmd="/usr/cyrus/bin/pop3d -s" listen="pop3s" prefork=0
> sieve cmd="/usr/cyrus/bin/timsieved" listen="sieve" prefork=0
>
> # at least one LMTP listener is required for proper delivery
> # lmtp cmd="lmtpd" listen="lmtp" prefork=0
> lmtpunix cmd="/usr/cyrus/bin/lmtpd" listen="/var/imap/socket/lmtp"
> prefor
> k=0
> }
>
> EVENTS {
> # this is required
> checkpointcmd="ctl_mboxlist -c" period=30
>
> # this is only necessary if using duplicate delivery suppression
> #delprune cmd="ctl_deliver -E 3" period=1440
> }
>
> My /usr/lib/sasl/Cyrus.conf
> pwcheck_method:pam
>
> /var/log/messages Log file with a 600 perm. shadow file:
> Sep 28 07:57:26 magenta pop3d[1831]: unable to open Berkeley db /etc/sasldb:
> No such file or directory
> Sep 28 07:57:26 magenta pop3d[1831]: unable to open Berkeley db /etc/sasldb:
> No such file or directory
> Sep 28 07:57:31 magenta pop(pam_unix)[1831]: authentication failure; logname=
> uid=76 euid=76 tty= ruser= rhost= user=test
>
> /var/log/messages Log file with a 777 perm. shadow file:
> Sep 28 08:01:00 magenta pop3d[1831]: login: magenta.omnisig.com[127.0.0.1]
> test plaintext
>
> In both previous cases, I got the following output:
> Trying 127.0.0.1...
> Connected to 127.0.0.1.
> Escape character is '^]'.
> +OK magenta.omnisig.com Cyrus POP3 v2.0.16 server ready
> user test
> +OK Name is a valid mailbox
> pass
> -ERR Invalid login
>
> My /etc/pam.d/imap and pop files look like this:
> #%PAM-1.0
> auth required /lib/security/pam_stack.so service=system-auth
> accountrequired /lib/security/pam_stack.so service=system-auth
>
> So does anybody have any ideas???
>
> Thank you in advance
>
> Eric
>
> Eric L'Heureux wrote:
>
> > Original Message
> > Subject: Re: Cyrus 2.0.16 with RedHat 7.1
> > Date: Fri, 28 Sep 2001 06:58:50 +1000
> > From: "Jeremy Howard" <[EMAIL PROTECTED]>
> > Reply-To: "Jeremy Howard" <[EMAIL PROTECTED]>
> > To: "Eric L'Heureux"
> > <[EMAIL PROTECTED]>,<[EMAIL PROTECTED]>
> > References: <[EMAIL PROTECTED]>
> >
> > Eric L'Heureux wrote:
> > > I need help! I'm trying to install Cyrus 2.0.16 on Red Hat 7.1.
> > > I keep getting "Invalid login" errors when trying to connect from pop or
> > > imap.
> > >
> > > I've set-up Cyrus to use PAM for authentication but it seems to
> > > try looking for a sasldb file. I DO NOT want to use sasldb, I have
> > > already a huge passwd/shadow database and I'm not planning to convert it
> > > to sasldb.
> > >
> > What configure command did you use? What do your cyrus.conf and
> > imapd.conf
> > files look like? What is in your imap log when you fail
Re: Problem with cyrus imap 2.0.16 and Outlook Express 5.0: Seen flag does not stick
Since I have been working on the 2.0.16 locking problem (per my previous e-mails), I have been taking a good long look at the seen locking behavior and I must admit confusion as to whether this is working as intended or if it is buggy. First of all, I am reasonably convinced that the locking problem that we have discussed previously, is a combination of two things (at least in Linux), There are clearly cases in the cyrus code where cyrus tries to lock the same file twice without unlocking it. For example, when I use the "select" command to access a mailbox that I have not touched before, in the index_check function on line 439 of index.c, we call seen_lockread to lock the file, later in the same function (on line 487), we call the index_checkseen which also makes a call to the seen_lockread function. I suspect there are other places where this happens as well.In all of my testing, a call to flock to lock the same file descriptor twice by the same process always works, but clearly from the gdb backtraces and analysis I have done, every time an IMAP process locks up on me, it is trying to lock the seen file a second time when it already has a lock. I suspect that there is some bug in the 2.2.19 version of the linux kernel I am using that causes second calls to flock for the same file descriptor to fail intermittantly.I am currently testing a workaround fix to lib/lock_flock.c that attempts to unlock the file first before it attempts to lock. Fortunately you can not remove an advisory lock that was set by another process and if you don't have a lock, the call to flock to unlock the file does not generate an error code.This seems to be working and I will post it to the list once I have more confidence in it. I am not sure if locking the file multiple times by the same process can be considered a bug or not, but it may be that this is not the normal way that flock is used and it is possible that the linux kernel has not been tested extensively in this way. I am curious if all of the other folks with this problem are using linux or if it also shows up in solaris and other Unix flavors. The second point is more directly tied to the topic of this message.I agree with Heiki Kask that there are some problems in the seen code. Since there are very few clients that initiate multiple connections and since the odds of a message arriving while the seen file is being updated are very low, I think these problems are masked. The obvious evidence of the problem that I have seen is that when I have one of these locking problems, the seen file is locked with an advisory lock and yet it still gets updated and replaced when the other IMAP processes attempt to access the mailbox. Clearly there are some points in the code (that I am trying to track down) that update the file without checking the advisory lock first. I also have some confusion about how the seen system is supposed to work.The model cyrus uses seems to be: Read the file and cache it in a buffer to speed up subsequent accesses. When you want to write the file, lock it, write out the new file as filename.NEW, lock the new file, and rename the new back to the original name (replacing the original)Then unlock Subsequent reads always check to see if the file has been replaced and if it has, read in the new file, otherwise use the cached buffer version for performance reasons. Larry please correct me if this is explanation is wrong. Since this is abstracted out to allow the use of either berkely db's or flat files, it can get confusing to trace the calls from one function to the next. Thanks, John Lawrence Greenfield wrote: > Cyrus caches seen state in memory for a time before flushing it to > disk. Generally this works quite well; I use Outlook Express and > don't seem to have this problem, but perhaps I just don't do this > exact sequence of clicks. > > It's possible to force Cyrus to synchronize seen state more quickly > with the comparable loss of performance/scalability. > > Larry > >Date: Fri, 30 Nov 2001 01:31:37 +0200 >From: Heiki Kask <[EMAIL PROTECTED]> >CC: [EMAIL PROTECTED] > >> When Cyrus-IMAP writes the seen state, it first makes a copy of cyrus.seen >> to cyrus.seen.new(?). This allows other IMAP connections to read the seen >> state from cyrus.seen, while the first connection is updating >> cyrus.seen.new(?). When it finishes it moves the file to cyrus.seen. > >I see a contradiction here: Cyrus IMAP server is designed to support >multiple connections but it does not work with a client that actually >uses them. > >> one file (i.e. unix mbox format). This requires the UW-IMAP server to lock >> the file when it is writing to it, which prevents other connections from >> reading the file, until the lock
Re: Mail forwarding without '.forward'
The easiest way to do this is with sieve. (Built in to cyrus 2.X)
Users can access a simple tool like easysieve from a web browser to set
the forwarding address.Also supports fancier features like vacation
autoreplies, etc.
Hope this helps,
John Wade
LF wrote:
>I would appreciate some advise here.
>
>I was trying to migrate from qmail to cyrus imap (with postfix) when I
>encounter this problem. If users request for the auto-forwarding feature
>(".forward" supported by postfix), does cyrus imap server support
>mail forwarding? I don't wanna use ".forward" feature offered by postfix
>because that will mean I have to create system accounts
>instead of cyrus-sasl accounts.
>
> Please help.
>
>Million thks!
>
>
>
Re: Can't deliver - can't find mailboxes
Hi Steven, This is probably an MTA problem. Cyrus does not require anything in /etc/password except possibly for authntication (and you can use LDAP, etc for that instead.) Have you tried calling deliver directly like: /usr/cyrus/bin/deliver jwade < /tmp/testmessage where test message is something like: - To: [EMAIL PROTECTED] From: [EMAIL PROTECTED] Subject: test body test - Don't call it with the -m option, see the deliver man page for more details. Hope this helps, John "Steven J. Sobol" wrote: > Hello, > > I have a very odd situation. > > I'm migrating to LDAP. I have written a custom pwcheck() function that > checks for users in both /etc/passwd and on the LDAP server. That part of > the system works fine. Delivery doesn't. > > I can use deliver-wrapper to deliver to mailboxes for those users who are > still in /etc/passwd. But when I try to deliver to one of the test > mailboxes held by a user who is in LDAP, I get "mailbox does not exist" > even though cyradm can find the mailbox with no problem. > > What I need to know is where to patch Cyrus. I'm assuming there are calls > to getpwnam() somewhere that need to be modified, but I'm not sure where I > need to go (mboxlist.c seems a likely place but I'm not sure.) > > I'm using Cyrus 1.6.24. > > Help, please. Thanks > > -- > JustThe.net LLC - Steve "Web Dude" Sobol, CTO ICQ: 56972932/WebDude216 > website: http://JustThe.net email: [EMAIL PROTECTED] phone: 216.619.2NET > postal: 5686 Davis Drive, Mentor On The Lake, OH 44060-2752 DalNet: ZX-2
Re: problem with vacation being case-sensitive
Just to say that this is also a problem for us. Our email addresses are case insensitive, and I can be mailed as [EMAIL PROTECTED] or [EMAIL PROTECTED] or any other combination. Users complain about having to put their mail address into the vacation facility at all - and are not at all happy about having to put in all likely combinations of upper and lower case. In fact, even when the local part of addresses is case sensitive, I think it would be better to do a case insensitive match for purposes of deciding eligibility for a vacation message. After all, if the message is delivered (so the envelope recipient address is correct) and has a to/cc/bcc header that satisfies a case-insensitive match, under what circumstances could it be wrong to send a vacation message? If that is not agreed, perhaps there could be a configuration option for the vacation facility to do a case-insensitive match? John. At 14:43 14/01/02, Olaf Dreyer wrote: >Hello, > >i am still fighting with vacation. As far as i understand the source >code, and what i read in the archives, the envelope address and the >strings in the :addresses field are compared to To, Cc and Bcc fields. >If they match, a vacation message may be sent. >My sendmail configuration, which is derived from cyrusv2.mc, sets the >recipient to lower case, and leaves the To/Cc/Bcc fields as provided by >the sender. This behaviour is ok, as i want cyrus to store mails for >Olaf.Dreyer and olaf.dreyer or even olaf.Dreyer in the same inbox. >With sieve/vacation i really have to provide all possible variants? >I think this would make vacation too difficult to use. > >TIA >Olaf Dreyer
Re: problem with vacation being case-sensitive
At 19:30 14/01/02, Gary Mills wrote: >On Mon, Jan 14, 2002 at 05:35:49PM +0000, John Holman wrote: > > > > In fact, even when the local part of addresses is case sensitive, I think > > it would be better to do a case insensitive match for purposes of deciding > > eligibility for a vacation message. After all, if the message is delivered > > (so the envelope recipient address is correct) and has a to/cc/bcc header > > that satisfies a case-insensitive match, under what circumstances could it > > be wrong to send a vacation message? > >A major part of this problem is that the envelope recipient address >is constructed in such a way that it can never match a header recipient >address. This happens because the MTA, sendmail in my case, strips >the domain portion of the envelope recipient, and then Cyrus lmtpd >appends `@unspecified.domain' to it. This requires a configuration >option so that lmtpd will append the correct domain. Lmtpd requires >some information only known to the MTA. Agreed that lmtpd needs to know the email addresses to use when matching what appears in the to/bcc/cc headers, and cannot deduce those from the envelope recipient. In fact it uses information provided by the user in the vacation rule. I'm addressing a different issue: that the case sensitive comparison inhibits vacation messages in some cases where a case insensitive comparision would not, and that this inhibition is never (as far as I can see) what is wanted. Therefore a case insensitive comparison would be better - and should at least be a configuration option. > > If that is not agreed, perhaps there could be a configuration option for > > the vacation facility to do a case-insensitive match? > >Again, lmtpd needs to know some information, whether user names are >case-insensitive, known only to the MTA. It doesn't need to know that information if a case-insensitive match is always better. And if that is not agreed, the configuration option I mention would serve to give lmptd the information. >The real problem is that the Cyrus sieve module does not know the >e-mail address of the recipient, and must guess at it by by examining >headers. Solving this would solve the other problems. Even if Cyrus, or (perhaps more likely) an interface that generates the sieve vacation rule on behalf of the user, discovered the "personal email addresses" for somebody (e.g. via a directory lookup keyed on the username), addresses varying only in case should still be treated as equivalent when deciding whether to send a vacation message. And, if Cyrus made a case-insensitive comparison for this purpose, that would solve one part of the problem even if the user still had to specify their own email addresses when creating a vacation rule. John. >-- >-Gary Mills--Unix Support--U of M Academic Computing and Networking-
Mac Os X Mail
Does anyone else have problems using the Mac OS X Mail client with a Cyrus server? At the stage when the client starts up and tries to enquire of the server what authentication types are supported it just hangs, for a very long time. John H.
Re: Cyrus/Exim incompatibility
At 04:57 24/01/02, Amos Gouaux wrote: >jh> Messages generated by Cyrus's lmtpd (e.g. as the result of a sieve >jh> vacation or reject rule) are created with CRLF as line terminators >jh> and piped to the mail program (by default sendmail, which in our >jh> case is actually exim). Messages presented to sendmail in this way >jh> should, I think, conform to the Unix conventions for line >jh> termination rather than those for SMTP, and therefore not contain CR >jh> characters. > >To quote RFC2033: > >Although LMTP is an alternative protocol to ESMTP, it uses (with a >few changes) the syntax and semantics of ESMTP. This design permits >LMTP to utilize the extensions defined for ESMTP. Certainly true when lmtpd is handling an incoming message over LMTP. But lmtp is not speaking LMTP when it *sends* vacation or reject messages - it calls sendmail on the command line and passes the message on the standard input. John.
Re: Cyrus/Exim incompatibility
At 16:05 24/01/02, Lawrence Greenfield wrote: >Date: Thu, 24 Jan 2002 09:49:59 + (GMT) >From: Philip Hazel <[EMAIL PROTECTED]> > >On Wed, 23 Jan 2002, John Holman wrote: > >> Messages generated by Cyrus's lmtpd (e.g. as the result of a sieve > vacation >> or reject rule) are created with CRLF as line terminators and piped > to the >> mail program (by default sendmail, which in our case is actually >> exim). Messages presented to sendmail in this way should, I think, >> conform to the Unix conventions for line termination rather than > those for >> SMTP, and therefore not contain CR characters. > >Sendmail has, for many many years, dynamically adjusted to CRLF >instead of LF. I suppose I could pass the "-ba" flag, which might >tell /usr/lib/sendmail to expect CRLF, but I'd worry that any sendmail >wrapper that doesn't deal with CRLF won't deal with the -ba flag. Certainly that doesn't seem to be a flag that Exim recognizes, so it wouldn't help in this particular case. >I suppose I should just make Cyrus connect to an SMTP server so I know >what sort of beast I'm dealing with. I think that would be a good thing to do. John.
Re: [Exim] Cyrus/Exim incompatibility
At 15:25 24/01/02, Ken Murchison wrote: >Philip Hazel wrote: > > > > On Wed, 23 Jan 2002, John Holman wrote: > > > > > Messages generated by Cyrus's lmtpd (e.g. as the result of a sieve > vacation > > > or reject rule) are created with CRLF as line terminators and piped > to the > > > mail program (by default sendmail, which in our case is actually > > > exim). Messages presented to sendmail in this way should, I think, > > > conform to the Unix conventions for line termination rather than > those for > > > SMTP, and therefore not contain CR characters. > > > > This is also my view. > > > > > This suggests that exim's author, at least, would consider Cyrus to be > > > broken in this respect! > > > > I am Exim's author. > >Is there a spec or reference which states that when sending a message to >an MTA via stdin that only LF should be used as the line terminator? Or >are people saying that this is best common practice? My guess is that there is no real standard, but I think it makes sense when passing a message to an MTA via stdin to comply with the conventions of the local operating system. That would mean LF under Unix, CRLF under Windows etc. Actually, if it's true that there are no standards to be upheld, I also think it would be better for Exim (which claims to be a Sendmail clone insofar as the command line interface is concerned) to accept either CRLF or LF as a line terminator when mail is presented on standard input, if that is what Sendmail does. As Lawrence has said, Cyrus could avoid the issue entirely by connecting to an SMTP server when it sends mail. John. >-- >Kenneth Murchison Oceana Matrix Ltd. >Software Engineer 21 Princeton Place >716-662-8973 x26 Orchard Park, NY 14127 >--PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
Re: [Exim] Cyrus/Exim incompatibility
At 09:13 25/01/02, Phillip Hazel wrote: >On Thu, 24 Jan 2002, John Holman wrote: > > Actually, if it's true that there are no standards to be upheld, I also > > think it would be better for Exim (which claims to be a Sendmail clone > > insofar as the command line interface is concerned) to accept either CRLF > > or LF as a line terminator when mail is presented on standard input, if > > that is what Sendmail does. > >I never claimed it to be a clone! It tries to implement the majority of >commonly-used command line options in a compatible way. Oops, clone is a bit strong. Nonetheless Exim *is* described in the documentation as "a straight replacement for /usr/lib/sendmail or /usr/sbin/sendmail when sending mail". >Cyrus appears to be becoming widely used. I should probably do something >better in Exim 4. I will investigate changing -dropcr to make it mean >"turn CRLF into LF" instead of what it currently does, and I will also >add a configure file option to force it always to be on. (And I'll see >if I can find any Sendmail documentation on this subject.) Thanks! I think Cyrus is the best freely-available IMAP server for large sites, and Exim has many advantages as an MTA, so anything to help them work together smoothly is to be encouraged. John >Philip > >-- >Philip HazelUniversity of Cambridge Computing Service, >[EMAIL PROTECTED] Cambridge, England. Phone: +44 1223 334714.
Re: problems with microsoft outlook?
Hi Ryan To debug IMAP connections, create a directory named after the user in /var/imap/log (i.e. /var/imap/log/joecool ) for the joecool user.Try your client and then look in this directory. There should be a file named after the process id of the imap process.The file contains a transcript of the imap session and can be very useful. Enjoy, John Wade Ryan Child wrote: > Sorry to utter the word "microsoft", but outlook is bitching about the > new imap account i set up. Mozilla mail gets mail fine, when I set it > up to use local folders for "sent" "drafts" etc.. The problem is that > windows clients respond with something like "could not connect to IMAP > server, server said: 'Mailbox does not exist'". The mailbox is of > course there and everything seems to work fine with mozilla. Any ideas? > > Thanks, > Ryan
Cyrus and the +S bit on Linux
Greetings, I have noticed some strange behavior with the way Cyrus interacts with the Synchronous bit on Ext2 filesystems. This may or may not be a problem. I am not sure. I am looking for some help or advice. Installation directions imply that setting the Synchronous bit on the following directories: cd /var/imap chattr +S . user quota chattr +S /var/spool/imap makes Cyrus operate more reliably on Ext2, and may even fix locking issues, etc. etc. So I decided to give it a shot. >From what I understand, when you set a Synchronous bit on a parent directory, any files or sub directories that are created also inherit the synchronous bit. I tested this and it is true. If I set the +S on the mailstore directory, go into it, and create a directory called "test", an "lsattr test" shows the sync bit is set. Furthermore, creating a file in this directory also shows the same. But when you use cyradm to create a new user's mailbox, the +S bit is not set on the new directory. If you type "mkdir ", the +S bit *is* set. It seems the inheritance only occurs when the files are created in a Unix shell, not through a daemon such as Imap or something. Also, new mail that gets delivered to a user's Inbox does not have the +S, but if you create a new file in the user's Inbox, it will inherit the +S... If this is true, and not actually a bug or something I am doing wrong, doesn't this throw the whole Synchronous theory out the window? Thoughts? -John
Re: LDAP accounts for Cyrus patch questions
Simon Loader has a patch in progress for saslv2: http://www.surf.org.uk/ I downloaded it to do some testing, but I can't get the patch to apply to sasl 2.1.2... If you have any luck, please pass on your secrets... -John Ted Knab wrote: > Does this mean that I can not run Cyrus 2.x ? > > I need LDAP authentification. > > -Ted > > --- Veigar_Freyr_J$F6kulsson wrote: > Is anyone working on an LDAP patch for sasl-2.1 ? > > -- > Veigar Freyr > [EMAIL PROTECTED] > > > You'll need sasl version 2.1 for cyrus imapd 2.1.3 :) > > > > Tarjei > > > > "Theodore J. Knab" wrote: > > > > > > I was having a little confusion over the LDAP patch so I want to make > sure I used > > > the right one. > > > > > > I downloaded the following: > > > > > > Cyrus-sasl-1.5.27.tar.gz > > > Cyrus-imapd-2.1.3.tar.gz > > > > > > I then downloaded the LDAP patch: > > > > > > http://www.surf.org.uk/src/cyrussasl.html > > > sasl-1.5.24-LDAP-ssl-filter-mysql-patch4.tgz > > > > > > I patched sasl. > > > patch -p0 < > /home/tjk/cyrus/tar-stuff/ldap-mysql_sasl-1.5.24/sasl-ldap+mysql.patch > > > > > > This seems to have worked even though the docs say use. > > > patch < \ > > > /home/tjk/cyrus/tar-stuff/ldap-mysql_sasl-1.5.24/sasl-ldap+mysql.patch > > > > > > Is this going to cause any problems ? > > > > > > Now all I need to do is compile cyrus-sasl -with-ldap=/usr/local/lib > > > right?
Re: LDAP accounts for Cyrus patch questions
Hi All, First of all, Thank you, thank you Simon!! We have been using varients of your LDAP patch for years now, and it is most appreciated. One issue we have had however is that the Sasl 1.5.x and earlier patches all work via pwcheck. This means that authentication is single threaded since all authentication requests are processed by a single pwcheck daemon. This also means a single point of failure if pwcheck crashes or stops responding. A pwcheck daemon makes sense when accessing a restricted file like the shadow password file, but it seems like it is unnecessary when accessing a remote LDAP server. Does anyone know if the auxprop plugin approach makes a new LDAP connection for each cyrus imapd process? This is the way I read documentation, but I just started looking at the code and I confess it will take a while to wade through it for someone like me. This would be ideal in our environment where we have multiple LDAP servers setup in a load balancing/fail over configuration. Thanks, John John Amodeo wrote: > Simon Loader has a patch in progress for saslv2: > > http://www.surf.org.uk/ > > I downloaded it to do some testing, but I can't get the patch to apply to sasl > 2.1.2... > If you have any luck, please pass on your secrets... > > -John > > Ted Knab wrote: > > > Does this mean that I can not run Cyrus 2.x ? > > > > I need LDAP authentification. > > > > -Ted > > > > --- Veigar_Freyr_J$F6kulsson wrote: > > Is anyone working on an LDAP patch for sasl-2.1 ? > > > > -- > > Veigar Freyr > > [EMAIL PROTECTED] > > > > > You'll need sasl version 2.1 for cyrus imapd 2.1.3 :) > > > > > > Tarjei > > > > > > "Theodore J. Knab" wrote: > > > > > > > > I was having a little confusion over the LDAP patch so I want to make > > sure I used > > > > the right one. > > > > > > > > I downloaded the following: > > > > > > > > Cyrus-sasl-1.5.27.tar.gz > > > > Cyrus-imapd-2.1.3.tar.gz > > > > > > > > I then downloaded the LDAP patch: > > > > > > > > http://www.surf.org.uk/src/cyrussasl.html > > > > sasl-1.5.24-LDAP-ssl-filter-mysql-patch4.tgz > > > > > > > > I patched sasl. > > > > patch -p0 < > > /home/tjk/cyrus/tar-stuff/ldap-mysql_sasl-1.5.24/sasl-ldap+mysql.patch > > > > > > > > This seems to have worked even though the docs say use. > > > > patch < \ > > > > /home/tjk/cyrus/tar-stuff/ldap-mysql_sasl-1.5.24/sasl-ldap+mysql.patch > > > > > > > > Is this going to cause any problems ? > > > > > > > > Now all I need to do is compile cyrus-sasl -with-ldap=/usr/local/lib > > > > right?
Cyrus 2.0.16 seen file locking patch
Hi All,
A while back I emailed the list about a seen file locking problem we were
having with Cyrus 2.0.16 on RedHat 7.0 (kernel 2.2.19-7.0.8). I spent a lot of
time exploring blocked imapd processes with gdb and finally came to the
conclusion that this appeared to be a kernel or glibc problem, not cyrus,
because processes were blocking trying to get a lock on .seen files that they
already had locked. I even added code to attempt to unlock the files first
before trying to lock and it did not resolve the problem. Finally, I came up
with the hack below. This week someone asked for my patch, so I though I
would post it to the list in case anyone else was interested.
The revised source is available at
http://servercc.oakton.edu/~jwade/cyrus/lock_flock.c
This should replace cyrus-imapd-2.0.16/lib/lock_flock.c
A diff is also included below, Basically this modifies the lock_reopen
function to call flock() in a non-blocking manner with a timeout parameter.
It will try once, try again immediately then sleep with a quadraticaly
increasing delay until it
reaches some maximum delay as #defined by MAXTIME,With max time set to 99
seconds, this gives a total delay of 1+4+9+16+25+36+49+64+81 = 285 seconds
(4.75 minutes) So that you can see what it is doing, if you have sysloging
turned on at the debug level, it will log a "lock_reopen-blocked: sleeping"
message to syslog. If 285 seconds elapses and it can't get a lock, it returns
an error and the imapd process that is hung up exits and puts and error in the
syslog.
This happens a couple of times a week for us, and it has ceased to be an issue
since we put this in place in early January (we only know about it from the
logs.) That being said, it is still something of a kluge. (And I haven't
documented the code at all.)
Hope this helps someone,
John Wade
---
#diff lock_flock.c lock_flock.c.original
51d50
< #include
58,59d56
< #define MAXTIME 99
<
83d79
< int delay=0, i=0;
87,88c83,84
< for(i=0,delay=0;;) {
< r = flock(fd, LOCK_EX|LOCK_NB);
---
> for (;;) {
> r = flock(fd, LOCK_EX);
90,103c86,87
< if (errno == EINTR) {
< continue;
< }
< else if ((errno == EWOULDBLOCK) && (delay < MAXTIME)) {
< syslog(LOG_DEBUG, "lock: reopen-blocked sleeping for %d on
int
erval %d (%d, %s)" , delay, i, fd, filename);
< sleep(delay);
< i++;
< delay = i*i;
< continue;
< }
< if (failaction) {
< if (delay >= MAXTIME) *failaction = "locking_timeout";
< else *failaction = "locking";
< }
---
> if (errno == EINTR) continue;
> if (failaction) *failaction = "locking";
105a90
>
112a98
>
113a100
>
Re: Cyrus 2.0.16 seen file locking patch
Hi Cyrus 2.0.16 users, Just because I received a couple of questions about what this patch is designed to resolve, I thought this info might also be of general use. As I stated before, the patched lock_flock.c file can be downloaded from http://servercc.oakton.edu/~jwade/cyrus/ This patch has only been tested on RedHat 7.0 Kernel 2.2.19-7.0.8enterprise, although it ought to work on any platform that uses flock. To see if this fix is designed to resolve your problem, see below. The symptoms we saw were not tied to the mailboxes.db or any of the Berkeley db databases. Instead, I would have processes that would lock up trying to access a user's mailbox. Subsequent attempts to access the mailbox would block waiting for the first process to release the locks on the various header and seen files in the mailbox. Finally, incoming mail would die because all of the lmtpd processes would get blocked trying to deliver to the locked mailbox. An easy way to see if you are experiencing this is to use gdb to debug one of the processes and then do a bt (backtrace) if you see that the process is in the middle of an flock call, then you could be experiencing the problem I was. First, check to see which processes are accessing the user's seen file: [root@borg /root]# lsof | grep jwade.seen Then use gdb to get a backtrace of each of these processes.Here is a sample gdb backtrace. Just substitute the process id of your suspect imapd process in place of 24876 [root@borgdb /usr/cgdb /usr/cyrus/bin/imapd 24876 GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... /root/24876: No such file or directory. Attaching to program: /usr/cyrus/bin/imapd, Pid 24876 Reading symbols from /usr/local/lib/libsasl.so.7...done. Loaded symbols for /usr/local/lib/libsasl.so.7 Reading symbols from /lib/libnss_nis.so.2...done. Loaded symbols for /lib/libnss_nis.so.2 ---Type to continue, or q to quit--- Reading symbols from /lib/libnss_dns.so.2...done. Loaded symbols for /lib/libnss_dns.so.2 0x4028a8a1 in __flock () from /lib/libc.so.6 (gdb) bt #0 0x4028a8a1 in __flock () from /lib/libc.so.6 #1 0x8079caf in lock_reopen (fd=22, filename=0x810fa08 "/var/imap/user/p/jwade.seen", sbuf=0xbfffebe0, failaction=0xbfffebdc) at lock_flock.c:84 #2 0x807b8c7 in starttxn_or_refetch (db=0x8111298, mytid=0x8111288) at cyrusdb_flat.c:211 #3 0x807ba27 in myfetch (db=0x8111298, key=0x8104328 "0e461b1e389ccb86", keylen=16, data=0xbfffecb4, datalen=0xbfffecb8, mytid=0x8111288) at cyrusdb_flat.c:270 #4 0x806f943 in seen_readit (seendb=0x8111278, lastreadptr=0xbfffed38, lastuidptr=0xbfffed3c, lastchangeptr=0xbfffed40, seenuidsptr=0xbfffed44, rw=1) at seen_db.c:268 #5 0x806fb01 in seen_lockread (seendb=0x8111278, lastreadptr=0xbfffed38, lastuidptr=0xbfffed3c, lastchangeptr=0xbfffed40, seenuidsptr=0xbfffed44) at seen_db.c:332 #6 0x8060daa in append_addseen (mailbox=0xbfffedb0, userid=0xb05c "jwade", msgrange=0x810f930 "271") at append.c:896 #7 0x805f929 in append_commit (as=0xbfffedb0, uidvalidity=0xbfffeda4, start=0xbfffeda8, num=0xbfffedac) at append.c:240 #8 0x8059a2f in index_copy (mailbox=0x80ffe20, sequence=0x810fbf8 "11352", usinguid=1, name=0xb2c0 "user.jwade.FaMiLy", copyuidp=0xb2bc) at index.c:1226 #9 0x80531cf in cmd_copy (tag=0x810fae8 "47", sequence=0x810fbf8 "11352", ---Type to continue, or q to quit--- name=0x810fc68 "INBOX.FaMiLy", usinguid=1) at imapd.c:3192 #10 0x804d85c in cmdloop () at imapd.c:791 #11 0x804cf34 in service_main (argc=1, argv=0xbe14, envp=0xbe1c) at imapd.c:546 #12 0x804bce6 in main (argc=1, argv=0xbe14, envp=0xbe1c) at service.c:285 #13 0x401d2f31 in __libc_start_main (main=0x804b8f8 , argc=1, ubp_av=0xbe14, init=0x804a9e4 <_init>, fini=0x807e84c <_fini>, rtld_fini=0x4000e274 <_dl_fini>, stack_end=0xbe0c) at ../sysdeps/generic/libc-start.c:129 (gdb) quit The program is running. Quit anyway (and detach it)? (y or n) y Detaching from program: /usr/cyrus/bin/imapd, Pid 24876 The key thing here is that this process was in the lock_reopen function trying to lock the .seen file. If this is your problem, my patch might help. John
Re: Cyrus 2.0.16 seen file locking patch
Hi Hein, Just for reference, what file system type are you using (ext2, ext3, etc.) ? Have you tried using gdb to backtrace what the processes are blocking on? Hope it works for you, I have not looked at the lock_flock.c file on 2.1.3, but I doubt that it has changed. Let me know what happens, John Hein Roehrig wrote: > Seems that I am also experiencing this or a similar locking problem, on > Cyrus 2.1.3, though, with Debian, Linux kernel 2.4.18. > > I will try the workaround now, but still would very much welcome > comments on the problem. > > -Hein > > On Mon, 2002-04-08 at 23:26, John Wade wrote: > > Hi Cyrus 2.0.16 users, > > > > Just because I received a couple of questions about what this patch is > > designed to resolve, I thought this info might also be of general use. > > As I stated before, the patched lock_flock.c file can be downloaded from > > http://servercc.oakton.edu/~jwade/cyrus/ > [...] > > >Name: signature.asc >signature.asc Type: application/pgp-signature > Description: This is a digitally signed message part
Re: Cyrus 2.0.16 seen file locking patch
Hi seen file lock suffers, I cleaned up the documentation, patchability, and added up some comments to my patch to work around seen file locking issues in cyrus 2.0.16 and 2.1.3. For those who have already installed it, there are no changes in functionality. (Thanks to Thomas Jarosch and others for the tips) See: http://servercc.oakton.edu/~jwade/cyrus/Readme.html or just browse the directory: http://servercc.oakton.edu/~jwade/cyrus/ So far four folks have tried this (two on 2.0.16 and two on 2.1.3) and it seems to have worked around the problem for them. (As it has for us) To recap: The symptoms we saw were not tied to the mailboxes.db or any of the Berkeley db databases. Instead, I would have processes that would lock up trying to access a user's mailbox. Subsequent attempts to access the mailbox would block waiting for the first process to release the locks on the various header and seen files in the mailbox. Finally, incoming mail would die because all of the lmtpd processes would get blocked trying to deliver to the locked mailbox. An easy way to see if you are experiencing this is to use gdb to debug one of the processes and then do a bt (backtrace) if you see that the process is in the middle of an flock call. Full information to help you determine if you are experiencing the problem can be found at the link above. If you do use this patch, send me an email and let me know what platform you are on and if it worked for you, Enjoy, John
Re: Watchdogs (was: Re: Cyrus 2.0.16 seen file locking patch)
I am not sure if you could easily tell when a process is hung. IMAP processes at least can be remarkably persistant. For example, we have some users with cable or DSL connections at home. If these folks leave an email client open and it checks for mail with a period that is shorter than the idle time out, they can keep the same IMAP process for weeks. In a MTA like postfix, if a delivery process hangs around for more than a few minutes, you can be sure it is hung up. In an imap server we could probably do this kind of checking on lmtpd's and pop3d's, bu I think it would be really tricky to do for imapd's. Also with process reuse in 2.x , it seems like it would be much harder. That being said, more power to you if you can do it. John Wade Henrique de Moraes Holschuh wrote: > On Tue, 16 Apr 2002, John Wade wrote: > > Hi seen file lock suffers, > [...] > > to my patch to work around seen file locking issues in cyrus 2.0.16 and > > 2.1.3. For those who have already installed it, there are no changes in > [...] > > The patch is interesting, and I would apply it just-in-case to the Debian > code, but I think we have room in cyrus for a more general solution. > > I'd like to see watchdogs in cyrus, just like we have in postfix for > example. That would protect us of all bugs like the hanging imap and pop3d > from causing resource starvation, while we track down and fix whatever issue > is causing the subsystem to hang... > > Are there any ongoing efforts to do so? If not, I probably can start working > on something like this (probably borrowing code from postfix, as soon as I > am able to verify if the licenses of both cyrus and postfix would not cause > trouble). > > What does the CMU crew think of this idea? > > -- > "One disk to rule them all, One disk to find them. One disk to bring > them all and in the darkness grind them. In the Land of Redmond > where the shadows lie." -- The Silicon Valley Tarot > Henrique Holschuh
Re: stale processes
Darin, That's probably the classic imap locking problem on that occurs on certain systems with certain software configs. You will need the patch by John Wade, who researched the problem and found a great workaround to it. Search the list for it... I have been using his patch for about two weeks now, and everything is working great. No more problems. -John Darin Perusich wrote: > hello all, > > i'm running into a problem where a user will go to either delete > messages, move into other folders (mostly when moving back into the > Inbox) and they are unable to. closing and reopening the client app > doesn't resolve the problem, you have to hunt down the users process's > on the server and kill them. what is the cause of these process just > floating around, and cause me headache? > > server software: > cyrus-imapd-2.0.16, cyrus-sasl-1.5.24 (rehdat7.1) > > client software: > netscape 4.7x, 6.2 (solaris and win2k) > eudora (win2k) > > -- > Darin Perusich > Unix Systems Administrator > Cognigen Corp. > [EMAIL PROTECTED] -- __ John C. Amodeo, Associate Director Information Technology and Computer Operations Faculty of Arts & Sciences, Rutgers University 732.932.9455-voice 732.932.0013-fax
Re: Bad Shutdown has killed cyrus
Hi Warren, Take a look at the syslog, I would bet that cyrus is trying to recover the duplicate delivery database or more probably the mailboxes database.For most folks on linux, this should be in something like /var/log/imapd.log (although it depends how you have syslog configured.) The syslog entries from a normal startup should look for something like: Apr 23 01:59:51 romulan master[847]: about to exec /usr/cyrus/bin/ctl_mboxlist Apr 23 01:59:51 romulan ctl_mboxlist[847]: running mboxlist recovery Apr 23 01:59:52 romulan ctl_mboxlist[847]: done running mboxlist recovery Apr 23 01:59:52 romulan master[875]: about to exec /usr/cyrus/bin/ctl_deliver Apr 23 01:59:52 romulan master[837]: ready for work Apr 23 01:59:52 romulan master[877]: about to exec /usr/cyrus/bin/ctl_deliver Apr 23 01:59:52 romulan master[876]: about to exec /usr/cyrus/bin/ctl_mboxlist Apr 23 01:59:52 romulan ctl_mboxlist[876]: checkpointing mboxlist Apr 23 01:59:52 romulan ctl_deliver[877]: duplicate_prune: pruning back 3 days Apr 23 01:59:52 romulan master[837]: process 876 exited, status 0 Apr 23 01:59:52 romulan ctl_deliver[877]: duplicate_prune: /var/imap/deliverdb/d eliver-a.db: purged 53 out of 143 entries Apr 23 01:59:54 romulan ctl_deliver[877]: duplicate_prune: /var/imap/deliverdb/d eliver-z.db: purged 5 out of 13 entries Apr 23 01:59:54 romulan master[837]: process 877 exited, status 0 I would bet that the last entry in your syslog is: ctl_mboxlist[]: running mboxlist recovery If this is what you see, the Berkeley DB mailboxes database has probably gotten messed up and the recovery process is hanging If this is your problem, one fix you could try would be to make backup copies of the /var/imap/mailboxes.db file and /var/imap/db directory, then delete all the files in the db directory. We use Berkeley DB's on our web server and this is the procedure we have used when they die. Not sure if this leaves you with a completely consistent database, but you could always export it out to a text file after you get it running using /usr/cyrus/bin/ctl_mboxlist -d > /var/imap/mailboxdb.txt Then delete the mailboxes.db and the contents of the /var/imap/db directory. As a final step, reimport the mailboxes.db using /usr/cyrus/bin/ctl_mboxlist -u < /var/imap/mailboxdb.txt For paranoia's sake, we have a cron job that exports the mailboxes.db using /usr/cyrus/bin/ctl_mboxlist -d every night. I am not a Berkeley db expert, so someone else may have more useful info. Good luck, John Warren Flemmer wrote: > Greetings > > After a bad restart of the cyrus server, imap, pop, cyradm and imtest fail > to function. The server had been functioning without problem for about > 6 months. A spare server was loaded with the backups, which had no > problem starting imap and the rest. So the configuration before the restart > was good. There were no changes made between the backup and the > restart (it was only a day or two old). All other services on the server do > not show any signs of problems (smtp,snmp, named etc work fine), only > cyrus is showing problems. After the restart fsck had to be used. > > If I telnet onto 127.0.0.1 143 or 110 the connection is established but the > banner does not appear. Cyradm never asks for the password unless I kill > the master process, then I get password and broken pipe. imtest shows > 'C: C01 CAPABILITY' but nothing else. > > Imap.conf and cyrus.conf are both good, the same as that on the server > with the restored backup (that works). The permissions and files seem to be > good and intact. I have reinstalled (make install) to ensure that cyrus > files > were not damaged. Reconstruct never returns (I have waited a number of > hours, approx. 300 mailboxes, probably less than 10 megs per mail box). > Setting the environment variable to CYRUS_VERBOSE shows no sign of > a problem. > > The backup server is working fine, so the reason for getting the old server > running is to get whatever mail is sitting on it to the new server and, > if it > happens again, the heavy handed approach of restoring from backups can > be avoided. I have searched the archives, without finding a single problem > matching this (similar, no banner problems, in the archives imply a > config or > permission problem and usually occur with new installations, this is not > the > case here). > > Config: RedHat 7.1, cyrus-imapd-2.0.16, pam is used for auth out of an mysql > db. The db is intact and functioning. > > Any ideas welcome, I have run out of them. > > Regards
Re: more authentication problems
I have a similiar config and it is working, here is what I have:
For Cyurs-SASL 2.1.2
# ./configure --disable-anon --disable-cram --disable-digest --with-gssapi=no --with-des=no --disable-otp --with-opie=no --disable-srp --disable-krb4 --enable-plain --enable-login --with-saslauthd
For Cyrus-IMAP 2.1.3:
# ./configure --with-auth=unix --with-krb4=no --with-sasl=/usr/lib/sasl2
For /etc/imapd.conf:
configdirectory: /var/imap
partition-default: /var/spool/imap
admins: cyrus
allowanonymouslogin: no
duplicatesuppression: yes
sieveuserhomedir: false
sievedir: /var/sieve
sendmail: /usr/lib/sendmail
sasl_pwcheck_method: saslauthd
To start the SASLAUTHD daemon I use the following:
/usr/local/sbin/saslauthd -a shadow
Hope this helps.
JL
--On Wednesday, May 01, 2002 4:13 PM -0400 "Eric S. Johansson" <[EMAIL PROTECTED]> wrote:
> when I run cyradm authentication failures and when I look in the log, I
> find:
>
> May 1 15:15:22 mail imapd[29838]: unknown password verifier saslauthd
> May 1 15:15:22 mail imapd[29838]: badlogin:
> localhost.localdomain[127.0.0.1] plaintext root SASL(-4): no mechanism
> available: checkpass failed May 1 15:18:09 mail perl: No worthy mechs
> found
>
> so I test using imtest and I get:
>
> [cyrus@mail cyrus]$ imtest -m login -p imap localhost
> C: C01 CAPABILITY
> S: * OK mail.andrewandsons.com Cyrus IMAP4 v2.1.4 server ready
> S: * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ MAILBOX-REFERRALS
> NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND SORT
> THREAD=ORDEREDSUBJECT THREAD=REFERENCES IDLE S: C01 OK Completed
> Password:
> C: L01 LOGIN cyrus {8}
> + go ahead
> C:
> L01 NO Login failed: no mechanism available
> Authentication failed. generic failure
> Security strength factor: 0
>
> May 1 15:33:47 mail imapd[29876]: unknown password verifier saslauthd
> May 1 15:33:47 mail imapd[29876]: badlogin:
> localhost.localdomain[127.0.0.1] plaintext cyrus SASL(-4): no mechanism
> available: checkpass failed
>
> and I tested saslauthd which works OK (as you'd expect)
>
> [root@mail saslauthd]# ./testsaslauthd -u cyrus -p
> OK "Success."
>
> and I compiled IMAP with:
>
> ./configure --with-auth=unix --without-gssapi
> --with-sasl=/usr/local/sasl --disable-sample --disable-krb4
> --with-saslauthd --enable-plain --enable-login
>
> and sasl2 with
>
> ./configure --prefix=/usr/local/sasl --disable-krb4 --without-gssapi
> -with-auth=unix --with-pwcheck --with-saslauthd
>
> my imapd.conf is:
>
> configdirectory: /var/spool/imap-config
> partition-default: /var/spool/imap
> admins: root cyrus
> srvtab:/var/spool/imap-config/srvtab
> allowplaintext: yes
> sasl_pwcheck_method: saslauthd
> sasl_mech_list: plain
>
> I'm really at a loss here. According to all the documentation I have
> read and the help I've gotten on the mailing list it should be working.
> But it's not and I don't know why. I've been staring at this stuff for
> so long that if there is a typo, I'm not seeing it.
>
> ---eric
>
>
>
>
RE: Binding Cyrus to Listen on one IP
Thanks to all who replied. In the end, here's what wound up working.
I went and recopied the .dist version of cyrus.conf back over, then
putting
listen="my.ip.address.here:imap" for example. Worked fine after doing
that.
John Straiton
[EMAIL PROTECTED] - 704-365-9970
==
Please reply to [EMAIL PROTECTED] instead of directly to me so that the
first available engineer might help you
> -Original Message-
> From: Sebastian Hagedorn [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 16, 2002 1:46 PM
> To: John Straiton
> Cc: [EMAIL PROTECTED]
> Subject: Re: Binding Cyrus to Listen on one IP
>
>
> -- John Straiton <[EMAIL PROTECTED]> is rumored to have
> mumbled on
> Montag, 16. September 2002 13:06 Uhr -0400 regarding Binding Cyrus to
> Listen on one IP:
>
> > Thoughts? How can I get this thing restricted to a single IP?
>
> The following is working just fine for me:
>
> # UNIX sockets start with a slash and are put into
> /var/lib/imap/sockets SERVICES {
> # add or remove based on preferences
> imap cmd="imapd" listen="cyrus.rrz.uni-koeln.de:imap"
> prefork=5
> imaps cmd="imapd -s" listen="cyrus.rrz.uni-koeln.de:imaps"
> prefork=1
> pop3 cmd="pop3d" listen="cyrus.rrz.uni-koeln.de:pop3"
> prefork=3
> pop3s cmd="pop3d -s" listen="cyrus.rrz.uni-koeln.de:pop3s"
> prefork=1
> sieve cmd="timsieved" listen="cyrus.rrz.uni-koeln.de:sieve"
> prefork=0
>
> ...
>
> Greetings, Sebastian
> --
> Sebastian Hagedorn M.A. - RZKR-R1 (Flachbau), Zi. 18,
> Robert-Koch-Str. 10 Zentrum für angewandte Informatik -
> Universitätsweiter Service RRZK Universität zu Köln / Cologne
> University - Tel. +49-221-478-5587
>
Re: Cyrus IMAPd 2.3.10 Released
Quoting Ken Murchison ([EMAIL PROTECTED]): > Simon Matter wrote: > >> On the Linux box, all fresh compilations aside from the sasl 2.1.15 > >> binaries: > > > > I once posted to the list that 2.3.9 needs at least cyrus-sasl-2.1.19. As > > a package maintainer I know that :) > > Did you ever figure out why? I'm not surprised that code in Cyrus > somehow depends on a change in SASL, but I can't seem to find anything > in the CVS logs or diffs that would be the cause. This is what I had to do for cmd_login to work in 2.3.9. /* authstate already created by mysasl_proxy_policy() */ /* Not when using login and allowplaintext. imapd_authstate is NULL TM Login fix */ if (imapd_authstate == NULL) imapd_authstate = auth_newstate(imapd_userid); But 2.3.10 cores :-( > > > -- > Kenneth Murchison > Systems Programmer > Project Cyrus Developer/Maintainer > Carnegie Mellon University > > 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 Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
On Thu, October 25, 2007 21:10, John Capo wrote: > Quoting Ken Murchison ([EMAIL PROTECTED]): > >> Simon Matter wrote: >> >>>> On the Linux box, all fresh compilations aside from the sasl 2.1.15 >>>> binaries: >>>> >>> >>> I once posted to the list that 2.3.9 needs at least cyrus-sasl-2.1.19. As a >>> package >>> maintainer I know that :) >> >> Did you ever figure out why? I'm not surprised that code in Cyrus somehow >> depends on >> a change in SASL, but I can't seem to find anything in the CVS logs or diffs >> that >> would be the cause. > > This is what I had to do for cmd_login to work in 2.3.9. > > > /* authstate already created by mysasl_proxy_policy() */ > /* Not when using login and allowplaintext. imapd_authstate is NULL TM > Login fix */ > if (imapd_authstate == NULL) > imapd_authstate = auth_newstate(imapd_userid); > > But 2.3.10 cores :-( Its coring in getgrouplist() probably because the 3rd argyument is NULL. /* get number of groups user is member of into ngroups */ getgrouplist(identifier, gid, NULL, &ngroups); BSD man page does not indicate that NULL args are OK. int getgrouplist(const char *name, int basegid, int *groups, int *ngroups); The resulting group list is returned in the integer array pointed to by groups. The caller specifies the size of the groups array in the integer pointed to by ngroups; the actual number of groups found is returned in ngroups. A non NULL imapd_authstate and turing off unix_group_enable works with older SASL libraries and 2.3.10. > > > > >> >> >> -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer >> Carnegie >> Mellon University 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 >> > Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus IMAPd 2.3.10 Released
Quoting Ken Murchison ([EMAIL PROTECTED]):
> John Capo wrote:
> >On Thu, October 25, 2007 21:10, John Capo wrote:
> >>Quoting Ken Murchison ([EMAIL PROTECTED]):
> >>
> >>>Simon Matter wrote:
> >>>
> >>>>>On the Linux box, all fresh compilations aside from the sasl 2.1.15
> >>>>>binaries:
> >>>>>
> >>>>I once posted to the list that 2.3.9 needs at least cyrus-sasl-2.1.19.
> >>>>As a package
> >>>>maintainer I know that :)
> >>>Did you ever figure out why? I'm not surprised that code in Cyrus
> >>>somehow depends on
> >>>a change in SASL, but I can't seem to find anything in the CVS logs or
> >>>diffs that
> >>>would be the cause.
> >>This is what I had to do for cmd_login to work in 2.3.9.
> >>
> >>
> >>/* authstate already created by mysasl_proxy_policy() */
> >>/* Not when using login and allowplaintext. imapd_authstate is NULL TM
> >>Login fix */
> >>if (imapd_authstate == NULL)
> >>imapd_authstate = auth_newstate(imapd_userid);
> >>
> >>But 2.3.10 cores :-(
> >
> >Its coring in getgrouplist() probably because the 3rd argyument is NULL.
> >
> >/* get number of groups user is member of into ngroups */
> >getgrouplist(identifier, gid, NULL, &ngroups);
> >
> >BSD man page does not indicate that NULL args are OK.
> >
> > int
> > getgrouplist(const char *name, int basegid, int *groups, int *ngroups);
> >
> > The resulting group list is returned in the integer array pointed to by
> > groups. The caller specifies the size of the groups array in the integer
> > pointed to by ngroups; the actual number of groups found is returned in
> > ngroups.
>
>
> See if this fixes the getgrouplist() problem:
>
It does fix the core dump. Our IMAP users are not in any Unix group
so I fully can't test that part.
> --- auth_unix.c.~1.46.~ 2007-09-27 16:02:45.0 -0400
> +++ auth_unix.c 2007-10-25 23:02:15.0 -0400
> @@ -225,7 +225,7 @@
> struct group *grp;
> #ifdef HAVE_GETGROUPLIST
> gid_t gid, *groupids = NULL;
> -int ret, ngroups = 0;
> +int ret, ngroups = 10;
> #else
> char **mem;
> #endif
> @@ -248,10 +248,7 @@
> #ifdef HAVE_GETGROUPLIST
> gid = pwd ? pwd->pw_gid : (gid_t) -1;
>
> -/* get number of groups user is member of into ngroups */
> -getgrouplist(identifier, gid, NULL, &ngroups);
> -
> -/* get the actual group ids */
> +/* get the group ids */
> do {
> groupids = (gid_t *)xrealloc((gid_t *)groupids,
>ngroups * sizeof(gid_t));
>
> --
> Kenneth Murchison
> Systems Programmer
> Project Cyrus Developer/Maintainer
> Carnegie Mellon University
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
imapd:Loading hard-coded DH parameters
Am attempting to get secure imap connection working optimally. I do not need server verification. I am getting these in my logs. Do you know what it means or, more importantly, if I need to worry? Nov 3 08:51:43 srv imaps[9301]: imapd:Loading hard-coded DH parameters Nov 3 08:52:33 srv sieve[9260]: imapd:Loading hard-coded DH parameters In my imapd.conf, I have tls_cert_file: /etc/cyrus-ssl/my.crt tls_key_file: /etc/cyrus-ssl/my.key tls_ca_file: /etc/cyrus-ssl/cacert.crt The key has been signed by www.cacert.org -- Sincerely, John Thomas 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: LARGE single-system Cyrus installs?
On Fri, 2007-11-09 at 19:10 +0100, Jure Pečar wrote: > I'm still on linux and was thinking a lot about trying out solaris 10, > but > stories like yours will make me think again about that ... Agreed -- with the things I see from the Solaris (and zfs) and Sparc hardware in general, my money's still on Linux/LVM/Reiser/ext3. 250,000 mailboxes, 1,000 concurrent users, 60 million emails, 500k deliveries/day. For us, backups are the worst thing, followed by reiserfs's use of BLK, followed by the need to use a ton of disks to keep up with the i/o. John -- John Madden Sr. UNIX Systems Engineer Ivy Tech Community College of Indiana [EMAIL PROTECTED] 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: LARGE single-system Cyrus installs?
> > Would'nt it be nice to have a configuration option to completely > turn off > > fsync() in Cyrus? If you want, with a BIG WARNING in the doc stating > NOT TO > > USE IT unless you know what you doing. :) > > Its already in imapd.conf(8): > > skiplist_unsafe I see most of our writes going to the spool filesystems, not so much the meta filesystem, so I'd prefer to see something where we can keep the main databases fsnyc()ing properly but allow the individual mailboxes to just rely on filesystem journaling. Is there a cacheandindexfile_unsafe? :) John -- John Madden Sr. UNIX Systems Engineer Ivy Tech Community College of Indiana [EMAIL PROTECTED] 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
imapd signal 11 blues
t;imaps" prefork=0
pop3 cmd="pop3d" listen="pop3" prefork=0
pop3s cmd="pop3d -s -C /usr/local/etc/imapd-ssl.conf"
listen="pop3s" prefork=0
sieve cmd="timsieved" listen="sieve" prefork=0
lmtpunix cmd="lmtpd" listen="/var/imap/socket/lmtp" prefork=0
}
EVENTS {
checkpointcmd="ctl_cyrusdb -c" period=30
delprune cmd="cyr_expire -E 3" at=0400
tlsprune cmd="tls_prune" at=0400
squatter cmd="squatter -sr user" at=0400
}
%cat /usr/local/lib/sasl2/Cyrus.conf
pwcheck_method: saslauthd
I installed cyrus-imap23 from FreeBSD ports, config.log shows
$ ./configure --sysconfdir=/usr/local/etc
--with-cyrus-prefix=/usr/local/cyrus --with-cyrus-user=cyrus
--with-cyrus-group=cyrus --with-sasl=/usr/local --with-bdb=db41
--with-com_err=/usr
--with-openssl=/usr/local --with-perl=/usr/local/bin/perl5.8.8
--with-bdb-incdir=/usr/local/include/db41
--with-bdb-libdir=/usr/local/lib --with-snmp=no --prefix=/usr/local
--mandir=/usr/local/man
--infodir=/usr/local/info/ i386-portbld-freebsd6.2
I had the same problems with cyrus-imap 2.2 in testing.
Suggestions leading to understanding are welcome. I see
some of the keywords in online searches of the archives,
but I have I'm missing the issue in my understanding.
Any helpful comments are welcome.
Thank you,
John
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 signal 11 blues
asl2/libplain.so.2...(no
debugging symbols found)...done.
Loaded symbols for /usr/local/lib/sasl2/libplain.so.2
Reading symbols from /lib/libcrypt.so.3...(no debugging symbols found)...done.
Loaded symbols for /lib/libcrypt.so.3
Reading symbols from /usr/local/lib/sasl2/libanonymous.so.2...(no
debugging symbols found)...done.
Loaded symbols for /usr/local/lib/sasl2/libanonymous.so.2
Reading symbols from /usr/local/lib/sasl2/liblogin.so.2...(no
debugging symbols found)...done.
Loaded symbols for /usr/local/lib/sasl2/liblogin.so.2
Reading symbols from /usr/local/lib/sasl2/libntlm.so.2...(no
debugging symbols found)...done.
Loaded symbols for /usr/local/lib/sasl2/libntlm.so.2
Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols
found)...done.
Loaded symbols for /libexec/ld-elf.so.1
#0 0x08163533 in ?? ()
(gdb) bt
#0 0x08163533 in ?? ()
Cannot access memory at address 0xbfbfcb18
Does this provide any first clues? I've room for skills development
in these things.
thanks,
John
At 02:28 AM 12/18/2007, Torsten Schlabach wrote:
>Hi John!
>
>I had just the identical problem last night, but I was able to trace it
>down to a bug in the ldapdb auxprop module. You are not using that
>module, so that can't be it.
>
>How would one do an strace on imapd to find out in what function call it
>dies? That might be an indication.
>
>Regards,
>Torsten
>
>John Crawford schrieb:
> > Hi.
> > I'm working on a freebsd test server (within vmware server),
> > and am having some difficulty. imapd processes terminate abnormally.
> >
> > imtest -m login -v -a cyradm -u cyradm localhost
> > S: * OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID AUTH=LOGIN AUTH=PLAIN
> > SASL-IR] virtualmail2.domain.edu Cyrus IMAP4 v2.3.11 server ready
> > C: C01 CAPABILITY
> > S: * CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID AUTH=LOGIN AUTH=PLAIN SASL-IR
> > ACL RIGHTS=kxte QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME
> > UNSELECT CHILDREN MULTIAPPEND BINARY SORT SORT=MODSEQ
> > THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE CATENATE CONDSTORE
> > IDLE URLAUTH
> > S: C01 OK Completed
> > Please enter your password:
> > C: L01 LOGIN cyradm {13}
> > S: + go ahead
> > C:
> > failure: prot layer failure
> >
> > The saslauthd part is going fine. Seems to not want to talk nice to the
> > imap server.
> > # /usr/local/sbin/saslauthd -a pam -d
> > saslauthd[14961] :main: num_procs : 5
> > saslauthd[14961] :main: mech_option: NULL
> > saslauthd[14961] :main: run_path : /var/run/saslauthd
> > saslauthd[14961] :main: auth_mech : pam
> > saslauthd[14961] :ipc_init: using accept lock file:
> > /var/run/saslauthd/mux.accept
> > saslauthd[14961] :detach_tty : master pid is: 0
> > saslauthd[14961] :ipc_init: listening on socket:
> > /var/run/saslauthd/mux
> > saslauthd[14961] :main: using process model
> > saslauthd[14961] :have_baby : forked child: 14962
> > saslauthd[14962] :get_accept_lock : acquired accept lock
> > saslauthd[14961] :have_baby : forked child: 14963
> > saslauthd[14961] :have_baby : forked child: 14964
> > saslauthd[14961] :have_baby : forked child: 14965
> > saslauthd[14961] :get_accept_lock : acquired accept lock
> > saslauthd[14962] :rel_accept_lock : released accept lock
> > saslauthd[14962] :do_auth : auth success: [user=cyradm]
> > [service=imap] [realm=] [mech=pam]
> > saslauthd[14962] :do_request : response: OK
> >
> > I have similar problems with invoking cyradm, with the pam mechanism
> > working but
> > imap kicking it out.
> >
> > # su cyrus
> > %cyradm -u cyradm -auth plain localhost
> > Password:
> > IMAP Password: at
> > /usr/local/lib/perl5/site_perl/5.8.8/mach/Cyrus/IMAP/Admin.pm line 119
> > cyradm: cannot authenticate to server with plain as cyradm
> > %cyradm -u cyradm -auth login localhost
> > IMAP Password: at
> > /usr/local/lib/perl5/site_perl/5.8.8/mach/Cyrus/IMAP/Admin.pm line 119
> > cyradm: cannot authenticate to server with login as cyradm
> >
> > newer syntax, both plain and login mechanisms
> > %cyradm --user cyradm --auth plain localhost
> > Password:
> > IMAP Password: at
> > /usr/local/lib/perl5/site_perl/5.8.8/mach/Cyrus/IMAP/Admin.pm line 119
> > cyradm: cannot authenticate to server with plain as cyradm
> >
> > %cyradm --user cyradm --auth login localhost
> > IMAP Password: at
> > /usr/local/lib/perl5/site_perl/5.8.8/mach/Cyrus/IMAP/Admin.pm line 119
> > cyradm: cannot authenticate to server wit
Re: Migrate all to skiplist?
> Reading through many posts, is there any reason to not use skiplist for > all the databases? Although I have 200 users, at any given time, only > half are actively using their account. Our traffic is light for the most > part. With only 200 users, I see no reason to not use skiplist. John -- John Madden Sr. UNIX Systems Engineer Ivy Tech Community College of Indiana [EMAIL PROTECTED] 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: Problems with load balancing cluster on GFS
> > Current size of my Imap Server is 2500 users and currently 250 GByte of > > Mailboxes used (growing and growing). > Well, we will be talking about something in the range of above 50k > mailboxes, so a single machine is just out of question. And some sort > of standby will be needed. I didn't do the concept for this system, > though, I'm just the one who has to implement it ;) A single machine is not out of the question for that number of mailboxes, but is perhaps for the amount of traffic driven by your user behavior -- that's what you need to determine. We happily run 350k mailboxes on a single system with the determining factor being I/O contention during mail delivery. Depending on your storage, you won't necessarily be able to fix that contention by running multiple machines. I wouldn't count out a single machine with lots of (relatively small) storage pools to build performance. John -- John Madden Sr. UNIX Systems Engineer Ivy Tech Community College of Indiana [EMAIL PROTECTED] 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: Pruning Duplicates
Jorey Bump wrote: > I've been asked to remove the duplicates. Can anyone recommend a safe > and simple method for doing so? I have had success with this Thunderbird extension https://addons.mozilla.org/en-US/thunderbird/addon/956 YMMV, have backups. -- Sincerely, John Thomas 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: Planning for load balancing
> Can anyone advice what could help? Increase your connection count to something more than 400? -- John Madden Sr. UNIX Systems Engineer Ivy Tech Community College of Indiana [EMAIL PROTECTED] 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: Archiving emails with Cyrus
On Monday 24 November 2008 08:56:35 am Alexandros Gougousoudis wrote: > There must be a process in cyrus, which copies these emails into a > (zip)-file and/or into a database, to have them somehow accessable. > Cyrus must do this with the administrator account, because the imap > credentials of all the users are of course not known to us. Or we > install an "archive"-useraccount which has access to all mailboxes. Here's an idea I've been toying with for an upcoming implementation... Let's say you create everyone's Inbox/Drafts/etc mailboxes on your reasonably fast (expensive/small?) storage with a relatively low mailbox quota. You then create user.username.archive on a separate Cyrus partition, perhaps residing on SATA with a relatively high mailbox quota. Inform your users that to store mail and keep their Inbox available they should move it there. You can then use Cyrus' built-in search mechanisms (squat) and have to change very little. John -- John Madden Sr. UNIX Systems Engineer Ivy Tech Community College of Indiana [EMAIL PROTECTED] 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
> Once, there was a bad shutdown corrupting ext3fs and we spent 6 hours on an > fsck. > Next we discovered that our backup system was going slower and slower. We > just pointed out that it was due to fragmentation, and guess what, there's > no online defrag tool for ext3. Sure it isn't due to the number of files on those filesystems? File-level backups will slow down linearly as the filesystems grow, of course. I "solve" this by adding more spools (up to 8 at the moment with about 350k mailboxes) so they can be backed up in parallel. All on ext3. John -- John Madden Sr. UNIX Systems Engineer Ivy Tech Community College of Indiana jmad...@ivytech.edu 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
> Now from our experience, I can tell you that ext3 really does poorly on > this workload compared to reiserfs. We had two exact same servers, one all > reiserfs and one all ext3. The ext3 one started out ok, but over the course > of a few weeks/months, it started getting worse and worse and was > eventually being completely crushed by IO load. The machine running > reiserfs had no problems at all even though it had more users on it as well > and was growing at the same rate as the other machine. Now see, I've had almost exactly the opposite experience. Reiserfs seemed to start out well and work consistently until the filesystem reached a certain size (around 160GB, ~30m files) at which point backing it up would start to take too long and at around 180GB would take nearly a week. This forced us to move to ext3 and it doesn't seem to be degrade that way. We did, however, also move from a single partition to 8 of them, so that obviously has some effect as well. John -- John Madden Sr. UNIX Systems Engineer Ivy Tech Community College of Indiana jmad...@ivytech.edu 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
