Re: lmtp connection throtling in 2.0.9 or where are the docs?
Jeremy Beker <[EMAIL PROTECTED]> writes: > Dec 27 07:34:51 blackops lmtpd[28232]: DBERROR db3: > /var/imap/db/__db.003: Too many open files in system > Dec 27 07:34:52 blackops lmtpd[28232]: DBERROR: dbenv->open > '/var/imap/db' failed: Too many open files in system What OS are you running? What is your file descriptor limit? Is /var/imap/db on a reasonably fast disk? > What I would like to do is limit the number of copies of deliver (and > hence lmtpd) that are running at any one time. If this number is > exceeded, I want it to refuse delivery, forcing the mail to be queued > up. Is this possible? You should be able to do the limiting via sendmail. CONNECTION_RATE_THROTTLE will probably do something useful. > And is there aby documentation for the /etc/cyrus.conf file available? There are some sample conf files with the src distribution but I suspect the best documention are found in the .c and .h files at this time... As always, we appreciate any help we can get, including with documentation. Naturally, we'd like it if someone would just send us the documentation but even getting some mail to [EMAIL PROTECTED] saying . The documentation wasn't clear about [something]. . I was confued about [something] but eventually figured it out by doing [something]. etc. is useful to us. Walter
Cyrus IMAP, support
Curious, has there been any movement out there regarding commercial support for Cyrus? (via consultant or whomever)
Re: Cyrus-imapd 2.0.9 all users accept the cyrus password & noothers!
Me too! I thought maybe I'd done something dumb, and haven't gone back to try this again. This happened to me with 2.0.7. Using PAM, I could only log in supplying the password for cyrus. I switched to sasldb and it worked fine. Still, I wonder if this is a bug or just a common misconfiguration... regards, David "Andy Hubbell, Jr." wrote: > > Help! > > Setting up cyrus-imapd 2.0.9 for pam authentication, and everybody fails > unless they use the cyrus users's password... > > Any pointers would be greatly appreciated! > > Thanks! > > Andy H. > --- > PGP public key fingerprint > FC3A FD71 8A43 E510 8797 6FD8 918C 1D54 17D9 9EC1 -- David L. Parsley Network Administrator Roanoke College
Re: 1. 2., etc., files in user. directory
in netscape I think the option is called something like 'compact folder' David Lang On Sun, 24 Dec 2000, William K. Hardeman wrote: > Date: Sun, 24 Dec 2000 02:31:21 -0500 > From: William K. Hardeman <[EMAIL PROTECTED]> > To: Brian Capouch <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Subject: Re: 1. 2., etc., files in user. directory > > Brian, > > Cool. Someone else that's using a Slackware system. Mine is > Slackware-current. :) > > It sounds to me as if Netscape isn't doing an expunge. From my > understanding of the IMAP protocol and how Cyrus implements it, no messages > are actually deleted until an expunge operation is requested by the client. > What happens is that the Delete flag is set, only. I think that both > Netscape and Pine aren't seeing them because the Delete flag has been set > in some prior session, but I could well be wrong. (If I am, I hope someone > will correct me.) > > I'm not sure what might be happening here, but one suggestion is to try > using a client that allows Deleted messages to be explicitely Expunged, and > see what happens to your mail store on disk, then. One such client is > Mulberry, which has Windows, Mac and Linux versions available. I don't > really know of any others, although I'm sure there are some. > > If the explicitely called Expunge works, then I'd say it's a client issue. > If the Expunge does not work, and the messages you expect to have been > deleted are still on your drive, then there might be some mis-configuration > or bug somewhere in your Cyrus install. I've not had any problems with mine > that I've noticed, so far. > > Hope this helps, > Will > William Hardeman > [EMAIL PROTECTED] > > --On Saturday, December 23, 2000 21:09:33 -0500 Brian Capouch > <[EMAIL PROTECTED]> wrote: > > > I just finished installing cyrus 2.0.9 on a Slackware Linux system. I > > had the same problems reported earlier today getting cyradm to install > > properly; I finally resorted to going to another machine running an > > earlier beta (2.0.7) and then manually copying files out of the ~/perl > > directory into the various perl5 system locations. Now it works like a > > charm. > > > > System, if it's germane to anyone, is Linux Slackware 7.0 running > > 2.4.0-test12. > > > > Now my question: I am the only user on this box for the time being. I > > want to make sure things are stable before moving any of my other users > > over. > > > > I seem to be able to receive messages just fine, and sieve is running > > (out of my home directory). However, I notice that the various messages > > I have received, then moved to the Trash and then later "emptied" out > > via Netscape, are still there in the cyrus user directory where they > > were initially delivered. Stated different, even though my IMAP client > > can't see them, *I* can if I manually go into the cyrus directory space > > and "ls" > > > > Is this to be expected? They don't show up when I look at my IMAP mail > > from either Netscape or Pine, and I'm hoping perhaps that they get > > purged by some other entity. > > > > But I don't think 2.0.7 did that. Can anyone tell me for sure? > > > > Thanks. > > > > B. > > > > > >
Re: cyrus 2.0.9 and cyradmin
[EMAIL PROTECTED]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <007e01c06f8f$e158e600$[EMAIL PROTECTED]>; from [EMAIL PROTECTED] o n Tue, Dec 26, 2000 at 06:02:11PM -0500 Is cyradm only available in Perl. Can we get a C version :) _F On Tue, Dec 26, 2000 at 06:02:11PM -0500, Ilya wrote: > got the cyradmin start problem solved - installed latest stable perl. > this appears way too often : > assertion "text->maxbuf > 0" failed: file "digestmd5.c", line 1423 > Abort trap (core dumped) > for example if I just run "cyradm localhost" > and than press enter twice generates a dump in 1.3gb size > giving > cyradm --user user --server localhost and entering the password does the > same thing > actually anything with --user, login, auth will create dump > > the only way to use cyradm without core dump is to run: cyradm localhost > and add current user to admin group of imap. > > (Freebsd 4.2, Summary of my perl5 (revision 5.0 version 6 subversion 0) > > any suggestions? >
Re: Cyrus-imapd 2.0.9 all users accept the cyrus password & noothers!
Date: Thu, 28 Dec 2000 14:45:22 -0500 From: Todd Nemanich <[EMAIL PROTECTED]> Organization: Bay Mountain, Inc. "David L. Parsley" wrote: > > Me too! I thought maybe I'd done something dumb, and haven't gone back > to try this again. This happened to me with 2.0.7. Using PAM, I could > only log in supplying the password for cyrus. I switched to sasldb and > it worked fine. > > Still, I wonder if this is a bug or just a common misconfiguration... > I'm not exactly sure if this is the reason, but PAM does not allow any user except root to check another user's password. Hence you would only be able to check against uid:Cyrus through PAM. Perhaps using the pwcheck daemon can solve this problem. This is exactly the problem. A future version of Cyrus SASL will probably discontinue the PAM password method is favor of forcing people to use pwcheck. Larry
Re: Cyrus-imapd 2.0.9 all users accept the cyrus password & noothers!
"David L. Parsley" wrote: > > Me too! I thought maybe I'd done something dumb, and haven't gone back > to try this again. This happened to me with 2.0.7. Using PAM, I could > only log in supplying the password for cyrus. I switched to sasldb and > it worked fine. > > Still, I wonder if this is a bug or just a common misconfiguration... > I'm not exactly sure if this is the reason, but PAM does not allow any user except root to check another user's password. Hence you would only be able to check against uid:Cyrus through PAM. Perhaps using the pwcheck daemon can solve this problem. -- Todd Nemanich [EMAIL PROTECTED] "Protecting the opulent and staging moral standard, They expect redemption of character and self growth" Bad Religion - Inner Logic
User password management
I have my 2.0.9 sendmail 8.11.1 test server up and running, and happily serving me my mail so far for about a week without problems. My cohorts have cold feet about moving our user database over there, though, because of the additional complexity of managing the SASL username/password pairs as "yet another place to have to keep that stuff in synch." We are running 1.6.24 currently for the bulk of our users, and authenticating out of the system /etc/passwd file. If I may ask those who have blazed the ground ahead of me, what would you recommend as a technology for us to manage ~1000 IMAP users? We currently allow users to change their passwords at their pleasure--is this something you other administrators out there do? Etc. etc. I want to adopt something that's scalable and manageable. There is zero enthusiasm for adding a sasldb management system onto the top of the system we use already, which consists of Unix passwords and the infernal mess of a password system that we use with Samba for our SMB users. Thanks. B.
Re: Cyrus-imapd 2.0.9 all users accept the cyrus password & noothers!
Lawrence Greenfield wrote: > >Date: Thu, 28 Dec 2000 14:45:22 -0500 >From: Todd Nemanich <[EMAIL PROTECTED]> >Organization: Bay Mountain, Inc. > >"David L. Parsley" wrote: >> >> Me too! I thought maybe I'd done something dumb, and haven't gone back >> to try this again. This happened to me with 2.0.7. Using PAM, I could >> only log in supplying the password for cyrus. I switched to sasldb and >> it worked fine. >> >> Still, I wonder if this is a bug or just a common misconfiguration... >> > >I'm not exactly sure if this is the reason, but PAM does not allow any >user except root to check another user's password. Hence you would only >be able to check against uid:Cyrus through PAM. Perhaps using the >pwcheck daemon can solve this problem. > > This is exactly the problem. A future version of Cyrus SASL will > probably discontinue the PAM password method is favor of forcing > people to use pwcheck. Huh? I've been using pam_smb (yeah, I know this is ugly!) for all of our users since Cyrus 1.6.22 without any problems. Every user uses their own password to authenticate to imapd/pop3d/timsieved. The only time I need to use the Cyrus user's password is when I run 'cyradm -u cyrus' I know there are lots of other people using PAM, and I for one would hate to see support for it taken out of SASL. Ken -- 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: Cyrus-imapd 2.0.9 all users accept the cyrus password & noothers!
Ken Murchison <[EMAIL PROTECTED]> writes: > I know there are lots of other people using PAM, and I for one would > hate to see support for it taken out of SASL. The idea is to simplify the case where you are given a plaintext password and need to authenticate with it. PAM support isn't really being discontinued. It is just being moved out of lib/checkpw.c and pushed into the equivalent of pwcheck. Walter
Re: User password management
We keep all our userid/passwords in a Mysql database and use PAM/pam_mysql to have Cyrus 1.6.24 authenticate against the MySql database. As for password changing we use IMP/Horde so I modified a script provided with IMP to allow users to change their passwords when they are logged into IMP. Brian Capouch wrote: > I have my 2.0.9 sendmail 8.11.1 test server up and running, and happily > serving me my mail so far for about a week without problems. > > My cohorts have cold feet about moving our user database over there, > though, because of the additional complexity of managing the SASL > username/password pairs as "yet another place to have to keep that stuff > in synch." > > We are running 1.6.24 currently for the bulk of our users, and > authenticating out of the system /etc/passwd file. > > If I may ask those who have blazed the ground ahead of me, what would > you recommend as a technology for us to manage ~1000 IMAP users? We > currently allow users to change their passwords at their pleasure--is > this something you other administrators out there do? Etc. etc. > > I want to adopt something that's scalable and manageable. There is zero > enthusiasm for adding a sasldb management system onto the top of the > system we use already, which consists of Unix passwords and the infernal > mess of a password system that we use with Samba for our SMB users. > > Thanks. > > B.
Re: Cyrus-imapd 2.0.9 all users accept the cyrus password & noothers!
I hope it will not. I am running cyrus 2.0.9 on FreeBSD with PAM and mysql db very succesfully at this point - no problems at all. pwcheck on the other hand is only capable to ise shadow file according to its README. - Original Message - From: "Lawrence Greenfield" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "Todd Nemanich" <[EMAIL PROTECTED]> Sent: Thursday, December 28, 2000 2:58 PM Subject: Re: Cyrus-imapd 2.0.9 all users accept the cyrus password & noothers! >Date: Thu, 28 Dec 2000 14:45:22 -0500 >From: Todd Nemanich <[EMAIL PROTECTED]> >Organization: Bay Mountain, Inc. > >"David L. Parsley" wrote: >> >> Me too! I thought maybe I'd done something dumb, and haven't gone back >> to try this again. This happened to me with 2.0.7. Using PAM, I could >> only log in supplying the password for cyrus. I switched to sasldb and >> it worked fine. >> >> Still, I wonder if this is a bug or just a common misconfiguration... >> > >I'm not exactly sure if this is the reason, but PAM does not allow any >user except root to check another user's password. Hence you would only >be able to check against uid:Cyrus through PAM. Perhaps using the >pwcheck daemon can solve this problem. > > This is exactly the problem. A future version of Cyrus SASL will > probably discontinue the PAM password method is favor of forcing > people to use pwcheck. > > Larry > > >
Re: Cyrus-imapd 2.0.9 all users accept the cyrus password & noothers!
> On Thu, 28 Dec 2000 14:58:58 -0500, > Lawrence Greenfield <[EMAIL PROTECTED]> (lg) writes: lg> This is exactly the problem. A future version of Cyrus SASL will lg> probably discontinue the PAM password method is favor of forcing lg> people to use pwcheck. Then what about things you could have in PAM, such as pam_ldap? Wouldn't it be a bit extreme to throw out the PAM support just because of this one case? Perhaps if configure enables PAM support, it could print a warning message that for local passwd/shadow access, pwcheck should be used? -- Amos
Re: Cyrus-imapd 2.0.9 all users accept the cyrus password & noothers!
Amos Gouaux writes: > >Perhaps if configure enables PAM support, it could print a warning >message that for local passwd/shadow access, pwcheck should be used? It's a little more complicated than that. I don't know if this is part of the design of PAM, but most programs that do authentication through PAM run as root. Many of the PAM authentication methods only work for root, either because a file is readable only by root, or because they must bind to a privileged socket. Cyrus is the exception in this regard, which is why PAM often won't work for Cyrus. Linux PAM has an annoying feature, by the way, where it authenticates the invoking user rather than the requested user, when invoked by a non- root user. Solaris PAM will always fail to authenticate in this case. In general, authentication of users always requires some privileges, to protect against password guessing attempts. Root is the easiest way to provide this privilege, although in some cases it can also be provided by making the shadow file readable by the Cyrus user. So, you can't expect an authentication function within Cyrus to function without some way to increase privileges. PAM is a standardized way to do user authentication on Unix, and it should be supported as widely as possible to gain its benefits. As others have said, please keep PAM in Cyrus. Doing it via pwcheck seems to be the way to go. Hmm, I seem to be agreeing with you. -- -Gary Mills--Unix Support--U of M Academic Computing and Networking-
RE: building 2.0.9 on Solaris 8
Whoops, dblib should be dbdir , but same result
-Original Message-
From: Tony Johnson [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 28, 2000 10:19 PM
To: Cyrus Info Mailingliste
Subject: building 2.0.9 on Solaris 8
bash-2.04$
./configure --with-auth=krb4 --with-krb=/usr/local --with-sasl=/usr/local/li
b/sasl/ --with-dblib=/usr/local/BerkeleyDB.3.1/
creating cache ./config.cache
checking host system type... i386-pc-solaris2.8
checking for makedepend... makedepend
checking for gcc... gcc
checking whether the C compiler (gcc ) works... yes
checking whether the C compiler (gcc ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking for ranlib... ranlib
checking whether make sets ${MAKE}... yes
checking for a BSD compatible install... /usr/local/bin/install -c
checking how to run the C preprocessor... gcc -E
checking for AIX... no
checking for POSIXized ISC... no
checking for mawk... mawk
checking for working const... yes
checking for long file names... yes
checking for runpath switch... -R
checking for unistd.h... yes
checking for sys/select.h... yes
checking for sys/param.h... yes
checking for memmove... yes
checking for strcasecmp... yes
checking for ftruncate... yes
checking for strerror... yes
checking for dirent.h that defines DIR... yes
checking for opendir in -ldir... no
checking whether struct tm is in sys/time.h or time.h... time.h
checking for tm_zone in struct tm... no
checking for tzname... yes
checking for vprintf... yes
checking for db_create in -ldb-3... no
checking for db_create in -ldb... no
configure: error: this version requires Berkeley DB 3.x.
(Get it from http://www.sleepycat.com/.)
hmmm...
bash-2.04$ ls /usr/local/BerkeleyDB.3.1/include
db.h db_185.h db_cxx.h
bash-2.04$ ls /usr/local/BerkeleyDB.3.1/lib
libdb-3.1.la libdb_cxx-3.1.so libdb_java-3.1_g.so libdb_tcl-3.so
libdb-3.1.so libdb_cxx-3.so libdb_java-3.so libdb_tcl.so
libdb-3.solibdb_cxx.so libdb_java.so
libdb.so libdb_java-3.1.la libdb_tcl-3.1.la
libdb_cxx-3.1.la libdb_java-3.1.so libdb_tcl-3.1.so
It's there but...
RE: Cyrus-imapd 2.0.9 all users accept the cyrus password & noothers!
I would hate to have PAM support abandoned also. I have using Novell's corporate directory for Linux (pam_nds) very successfully with Cyrus to let our users have one password for LAN and e-mail access. --Moby -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Ken Murchison Sent: Thursday, December 28, 2000 2:35 PM To: Lawrence Greenfield Cc: [EMAIL PROTECTED] Subject: Re: Cyrus-imapd 2.0.9 all users accept the cyrus password & noothers! Lawrence Greenfield wrote: > >Date: Thu, 28 Dec 2000 14:45:22 -0500 >From: Todd Nemanich <[EMAIL PROTECTED]> >Organization: Bay Mountain, Inc. > >"David L. Parsley" wrote: >> >> Me too! I thought maybe I'd done something dumb, and haven't gone back >> to try this again. This happened to me with 2.0.7. Using PAM, I could >> only log in supplying the password for cyrus. I switched to sasldb and >> it worked fine. >> >> Still, I wonder if this is a bug or just a common misconfiguration... >> > >I'm not exactly sure if this is the reason, but PAM does not allow any >user except root to check another user's password. Hence you would only >be able to check against uid:Cyrus through PAM. Perhaps using the >pwcheck daemon can solve this problem. > > This is exactly the problem. A future version of Cyrus SASL will > probably discontinue the PAM password method is favor of forcing > people to use pwcheck. Huh? I've been using pam_smb (yeah, I know this is ugly!) for all of our users since Cyrus 1.6.22 without any problems. Every user uses their own password to authenticate to imapd/pop3d/timsieved. The only time I need to use the Cyrus user's password is when I run 'cyradm -u cyrus' I know there are lots of other people using PAM, and I for one would hate to see support for it taken out of SASL. Ken -- 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
building 2.0.9 on Solaris 8
bash-2.04$
./configure --with-auth=krb4 --with-krb=/usr/local --with-sasl=/usr/local/li
b/sasl/ --with-dblib=/usr/local/BerkeleyDB.3.1/
creating cache ./config.cache
checking host system type... i386-pc-solaris2.8
checking for makedepend... makedepend
checking for gcc... gcc
checking whether the C compiler (gcc ) works... yes
checking whether the C compiler (gcc ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking for ranlib... ranlib
checking whether make sets ${MAKE}... yes
checking for a BSD compatible install... /usr/local/bin/install -c
checking how to run the C preprocessor... gcc -E
checking for AIX... no
checking for POSIXized ISC... no
checking for mawk... mawk
checking for working const... yes
checking for long file names... yes
checking for runpath switch... -R
checking for unistd.h... yes
checking for sys/select.h... yes
checking for sys/param.h... yes
checking for memmove... yes
checking for strcasecmp... yes
checking for ftruncate... yes
checking for strerror... yes
checking for dirent.h that defines DIR... yes
checking for opendir in -ldir... no
checking whether struct tm is in sys/time.h or time.h... time.h
checking for tm_zone in struct tm... no
checking for tzname... yes
checking for vprintf... yes
checking for db_create in -ldb-3... no
checking for db_create in -ldb... no
configure: error: this version requires Berkeley DB 3.x.
(Get it from http://www.sleepycat.com/.)
hmmm...
bash-2.04$ ls /usr/local/BerkeleyDB.3.1/include
db.h db_185.h db_cxx.h
bash-2.04$ ls /usr/local/BerkeleyDB.3.1/lib
libdb-3.1.la libdb_cxx-3.1.so libdb_java-3.1_g.so libdb_tcl-3.so
libdb-3.1.so libdb_cxx-3.so libdb_java-3.so libdb_tcl.so
libdb-3.solibdb_cxx.so libdb_java.so
libdb.so libdb_java-3.1.la libdb_tcl-3.1.la
libdb_cxx-3.1.la libdb_java-3.1.so libdb_tcl-3.1.so
It's there but...
