one user folder appears under all accounts
Hi, I'm not super experienced with cyrus options, so I may need a pointer on what's up. We have 2 distinct cyrus servers which exhibit a problem. On each server, there is a folder, which is the name of a user's mailbox, which all accounts have rights to. We don't see anything in that folder. In one case that is because the mailbox no longer exists on cyrus, and in the other case there is no mail in it (two different user names appear on these). Deleting and recreating the mailbox didn't impact this issue in the second case where the mailbox exists. For regular imap clients, this doesn't seem to become an issue, but for webmail users, (using Horde/IMP), they can see the folder and people ask why it is there. Are there any suggestions how we can clean this shared folder (or whatever it is) up? Regards, --Donald 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: one user folder appears under all accounts
I found that these are accounts which were created in error. Usually the accounts are named user.XXX , while in these cases it was a typo - one without the leading user. and the other with usr. Using cyradm I could set the acl on one of them so cyrus could delete, and I deleted it. That is one instance resolved. In the other case, I get back an error: lam usr.760401c anyone lrs sam usr.760401c cyrus lrswipcda setaclmailbox: cyrus: lrswipcda: System I/O error The same error is shown from cyrdel, a perl script using IMAP::Admin to delete a mailbox. reconstruct isn't recognized on this server, and renaming to the conventional name fails. Does anyone have a sugegstion on how to get rid of this cruft? --Donald On 6/7/07, D G Teed <[EMAIL PROTECTED]> wrote: Hi, I'm not super experienced with cyrus options, so I may need a pointer on what's up. We have 2 distinct cyrus servers which exhibit a problem. On each server, there is a folder, which is the name of a user's mailbox, which all accounts have rights to. We don't see anything in that folder. In one case that is because the mailbox no longer exists on cyrus, and in the other case there is no mail in it (two different user names appear on these). Deleting and recreating the mailbox didn't impact this issue in the second case where the mailbox exists. For regular imap clients, this doesn't seem to become an issue, but for webmail users, (using Horde/IMP), they can see the folder and people ask why it is there. Are there any suggestions how we can clean this shared folder (or whatever it is) up? Regards, --Donald 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: one user folder appears under all accounts
Ah ha! Found another reference to the System I/O error on running sam which was a big hint. File system didn't jive with mailbox definition. I found where the mailbox was on the file system (under another account?) I've made the usr/760401c directory where user/ is, and then sam worked, and I could delete the mailbox. Problem solved. On 6/7/07, D G Teed <[EMAIL PROTECTED]> wrote: I found that these are accounts which were created in error. Usually the accounts are named user.XXX , while in these cases it was a typo - one without the leading user. and the other with usr. Using cyradm I could set the acl on one of them so cyrus could delete, and I deleted it. That is one instance resolved. In the other case, I get back an error: > lam usr.760401c anyone lrs > sam usr.760401c cyrus lrswipcda setaclmailbox: cyrus: lrswipcda: System I/O error The same error is shown from cyrdel, a perl script using IMAP::Admin to delete a mailbox. reconstruct isn't recognized on this server, and renaming to the conventional name fails. Does anyone have a sugegstion on how to get rid of this cruft? --Donald On 6/7/07, D G Teed <[EMAIL PROTECTED]> wrote: > > Hi, > > I'm not super experienced with cyrus options, so I may need a pointer on > what's up. > > We have 2 distinct cyrus servers which exhibit a problem. On each > server, > there is a folder, which is the name of a user's mailbox, which all > accounts have rights to. > > We don't see anything in that folder. In one case that is because the > mailbox no longer > exists on cyrus, and in the other case there is no mail in it (two > different user names > appear on these). > > Deleting and recreating the mailbox didn't impact this issue in the > second case where > the mailbox exists. > > For regular imap clients, this doesn't seem to become an issue, but for > webmail users, > (using Horde/IMP), they can see the folder and people ask why it is > there. > > Are there any suggestions how we can clean this shared folder (or > whatever it is) up? > > Regards, > > --Donald > > 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
Control over account expiry within cyrus
I see discussions of expiring messages, and expiring on the authentication system but nothing regarding expiring the mailbox access from POP/IMAP within cyrus itself. We have a couple of authentication systems and use pam to allow either. One is LDAP from our student registration system, and it allows students to start using email here as soon as they are accepted. However that database and LDAP account never expire - students have rights to login to the student portal to get marks, register, etc. We are not setting up local Unix accounts. The big advantage of cyrus is to not have to do that. Unless there is a better way, I can only see managing student access to their email by deleting mail accounts in cyrus after a certain expiry date has passed. In our previous cyrus system there was local authentication, and so use of Solaris account expiry permitted us to expire without deleting, which allows for quick recovery in case there was a mistake in the data of what accounts to delete. Are there any suggestions from what others have done to manage account expiry? Regards, --Donald Teed 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
Best install path for Redhat Enterprise 5
I'm looking at the various guides I see from google and from that deposited by Redhat's RPM for cyrus-imapd. Nothing appears to be really current. Most guides refer to building cyrus from source. I usually avoid doing that as it is a hassle to maintain packages that way, but then again Redhat has not updated their build in the last 2 years so perhaps it doesn't matter. I have a problem starting cyrus from the Redhat package and the init script. I can start /usr/lib/cyrus-imapd/cyrus-master as root and it works OK. I can login as cyrus with imtest. If I run the cyrus-impad init, which works fine on another Redhat install, I get errors: Feb 3 16:20:34 navi master[13825]: process started Feb 3 16:20:34 navi master[13827]: about to exec /usr/lib/cyrus-imapd/ctl_cyrusdb Feb 3 16:20:34 navi ctl_cyrusdb[13827]: DBERROR db4: /cyrus/imap/db: Permission denied Feb 3 16:20:34 navi ctl_cyrusdb[13827]: DBERROR db4: /cyrus/imap/db/__db.001: Permission denied Feb 3 16:20:34 navi ctl_cyrusdb[13827]: DBERROR: dbenv->open '/cyrus/imap/db' failed: Permission denied Feb 3 16:20:34 navi ctl_cyrusdb[13827]: DBERROR: init() on berkeley Feb 3 16:20:34 navi ctl_cyrusdb[13827]: DBERROR: writing /cyrus/imap/db/skipstamp: Permission denied Feb 3 16:20:34 navi ctl_cyrusdb[13827]: DBERROR: init() on skiplist Feb 3 16:20:34 navi ctl_cyrusdb[13827]: recovering cyrus databases Feb 3 16:20:34 navi ctl_cyrusdb[13827]: IOERROR: opening /cyrus/imap/mailboxes.db: Permission denied Feb 3 16:20:34 navi ctl_cyrusdb[13827]: DBERROR: opening /cyrus/imap/mailboxes.db: cyrusdb error Feb 3 16:20:34 navi master[13825]: process 13827 exited, status 75 Feb 3 16:20:34 navi master[13828]: about to exec /usr/lib/cyrus-imapd/idled Feb 3 16:20:34 navi idled[13828]: DBERROR: dbenv->open '/cyrus/imap/db' failed: Permission denied Feb 3 16:20:34 navi idled[13828]: DBERROR: init() on berkeley Feb 3 16:20:34 navi idled[13828]: DBERROR: reading /cyrus/imap/db/skipstamp, assuming the worst: Permission denied And it goes on until I stop the service. The files and directories are owned by cyrus, so the permissions issue seems odd. E..g. ls -l /cyrus/imap/ total 100 -rw--- 1 cyrus mail 144 Feb 3 16:15 annotations.db drwx-- 2 cyrus mail 4096 Feb 3 16:20 db drwx-- 2 cyrus mail 4096 Feb 3 16:15 db.backup1 -rw--- 1 cyrus mail 8192 Feb 3 16:15 deliver.db drwx-- 2 cyrus mail 4096 Feb 3 13:40 log -rw--- 1 cyrus mail 144 Feb 3 16:15 mailboxes.db drwx-- 2 cyrus mail 4096 Feb 3 13:40 msg drwx-- 2 cyrus mail 4096 Feb 3 16:17 proc drwx-- 2 cyrus mail 4096 Feb 3 13:40 ptclient drwx-- 2 cyrus mail 4096 Feb 3 16:20 rpm drwxr-x--- 2 cyrus mail 4096 Feb 3 16:15 socket drwx-- 2 cyrus mail 4096 Feb 3 13:40 sync I have one other Redhat server running this OK, but I don't know what the difference is. For this reason, I'd rather not fix the problem by building from source and having different styles of cyrus running. Does anyone have a pointer? --Donald 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: Best install path for Redhat Enterprise 5
On Tue, Feb 3, 2009 at 4:31 PM, Patrick Boutilier wrote: > > What does the following commands output? > > ls -ld /cyrus > ls -ld /cyrus/imap > Hey, another Bluenoser on the list. Cool. # ls -ld /cyrus/ drwxr-xr-x 5 cyrus root 4096 Feb 3 13:40 /cyrus/ # ls -ld /cyrus/imap/ drwx-- 11 cyrus mail 4096 Feb 3 16:20 /cyrus/imap/ That probably isn't as tidy as I'd leave it, but this is the current state, after trying several angles and running out of the office with the storm coming on heavy today. --Donald 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: Best install path for Redhat Enterprise 5
On Tue, Feb 3, 2009 at 10:59 PM, John Thomas wrote: > D G Teed wrote: > > I'm looking at the various guides I see from google and from > > that deposited by Redhat's RPM for cyrus-imapd. Nothing > > appears to be really current. > > Perhaps rebuilding Simon's rpm will ease your pain: > http://www.invoca.ch/pub/packages/cyrus-imapd/ > Thanks. That would be useful for working from the latest or at least more current sources. I found the problem. SELinux ! On Redhat 5.3 (Enterprise), with a minimal OS install, there is no Redhat installer question asking what level of SELinux we want. By default it is enabled and Enforcing. This is what caused the permissions errors accessing the DB files in their non-default location. I disabled SELinux, rebooted and now the init for cyrus-imapd runs as expected. --Donald 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
Authentication problems since Redhat 5.5 updates
We had a nice trouble free cyrus running until it was updated with updates from Redhat today. I've tested with testsaslauthd (no service name given) and it works OK, so I'd think things are fine on the pam, AD and ldap end. In the cyrus server's maillog I'm seeing messages like this from attempts to connect from the remote webmail: Jul 2 13:54:22 navi imap[4073]: badlogin: webmail.example.com[XXX.YYY.ZZZ.111] CRAM-MD5 [SASL(-13): user not found: no secret in database] Logins from some other IMAP, like my thunderbird, using a secure IMAP port, work OK. cyradm can connect, but scripts we have, using IMAP::Admin have stopped working. # cyrsetquota dteed 100 IMAP::Admin [ initialize ]: try NO Login failed: authentication failure This is cyrus 2.3.7 from Redhat, identifying as: name : Cyrus IMAPD version: v2.3.7-Invoca-RPM-2.3.7-7.el5_4.3 2006/07/10 13:46:20 vendor : Project Cyrus support-url: http://asg.web.cmu.edu/cyrus os : Linux os-version : 2.6.18-194.8.1.el5 environment: Built w/Cyrus SASL 2.1.22 Running w/Cyrus SASL 2.1.22 Built w/Sleepycat Software: Berkeley DB 4.3.29: (February 19, 2009) Running w/Sleepycat Software: Berkeley DB 4.3.29: (February 19, 2009) Built w/OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008 Running w/OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008 CMU Sieve 2.3 TCP Wrappers NET-SNMP mmap = shared lock = fcntl nonblock = fcntl idle = idled These packages were updated by Redhat related to sasl: Jul 02 10:36:41 Updated: cyrus-sasl-lib-2.1.22-5.el5_4.3.i386 Jul 02 10:37:11 Updated: cyrus-sasl-plain-2.1.22-5.el5_4.3.i386 Jul 02 10:37:44 Installed: cyrus-sasl-md5-2.1.22-5.el5_4.3.i386 Jul 02 10:38:01 Updated: cyrus-sasl-2.1.22-5.el5_4.3.i386 I tried removing cyrus-sasl-md5 and restarting saslauthd but it did not help. There has to be something silly getting in the way but what? --Donald 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: Benachrichtung zum Übermittlungsstatus (Fehlges chlagen)
2010/7/2 D G Teed > > > Subject: Authentication problems since Redhat 5.5 updates >> >> We had a nice trouble free cyrus running until it was updated >> with updates from Redhat today. >> >> I've tested with testsaslauthd (no service name given) and it works OK, >> so I'd think things are fine on the pam, AD and ldap end. >> >> In the cyrus server's maillog I'm seeing messages like this >> from attempts to connect from the remote webmail: >> >> Jul 2 13:54:22 navi imap[4073]: badlogin: >> webmail.example.com[XXX.YYY.ZZZ.111] CRAM-MD5 [SASL(-13): user not found: no >> secret in >> database] >> >> Logins from some other IMAP, like my thunderbird, using a secure IMAP >> port, work OK. >> >> cyradm can connect, but scripts we have, using IMAP::Admin have stopped >> working. >> >> # cyrsetquota dteed 100 >> IMAP::Admin [ initialize ]: try NO Login failed: authentication failure >> >> This is cyrus 2.3.7 from Redhat, identifying as: >> >> name : Cyrus IMAPD >> version: v2.3.7-Invoca-RPM-2.3.7-7.el5_4.3 2006/07/10 13:46:20 >> vendor : Project Cyrus >> support-url: http://asg.web.cmu.edu/cyrus >> os : Linux >> os-version : 2.6.18-194.8.1.el5 >> environment: Built w/Cyrus SASL 2.1.22 >> Running w/Cyrus SASL 2.1.22 >> Built w/Sleepycat Software: Berkeley DB 4.3.29: (February 19, >> 2009) >> Running w/Sleepycat Software: Berkeley DB 4.3.29: (February >> 19, 2009) >> Built w/OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008 >> Running w/OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008 >> CMU Sieve 2.3 >> TCP Wrappers >> NET-SNMP >> mmap = shared >> lock = fcntl >> nonblock = fcntl >> idle = idled >> >> These packages were updated by Redhat related to sasl: >> >> Jul 02 10:36:41 Updated: cyrus-sasl-lib-2.1.22-5.el5_4.3.i386 >> Jul 02 10:37:11 Updated: cyrus-sasl-plain-2.1.22-5.el5_4.3.i386 >> Jul 02 10:37:44 Installed: cyrus-sasl-md5-2.1.22-5.el5_4.3.i386 >> Jul 02 10:38:01 Updated: cyrus-sasl-2.1.22-5.el5_4.3.i386 >> >> I tried removing cyrus-sasl-md5 and restarting saslauthd but it did not >> help. >> >> There has to be something silly getting in the way but what? >> >> --Donald >> > I have things working again. I had disabled Unix authentication in pam temporarily to try troubleshooting with my account. That had the side effect of disabling the cyrus user from authentication. So that explains the scripts using IMAP::Admin breaking. I also removed the package cyrus-sasl-md5 and I believe this has an impact on the issue I was facing with "CRAM-MD5". Any tips on how to co-exist with that package are welcomed. --Donald 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: Benachrichtung zum Übermittlungsstatus (Fehlges chlagen)
2010/7/2 Dan White > On 02/07/10 14:43 -0300, D G Teed wrote: > >> 2010/7/2 D G Teed >> >>> Subject: Authentication problems since Redhat 5.5 updates >>> >>>> >>>> We had a nice trouble free cyrus running until it was updated with >>>> updates from Redhat today. >>>> >>>> I've tested with testsaslauthd (no service name given) and it works OK, >>>> so I'd think things are fine on the pam, AD and ldap end. >>>> >>>> In the cyrus server's maillog I'm seeing messages like this from >>>> attempts to connect from the remote webmail: >>>> >>>> Jul 2 13:54:22 navi imap[4073]: badlogin: >>>> webmail.example.com[XXX.YYY.ZZZ.111] CRAM-MD5 [SASL(-13): user not >>>> found: no secret in database] >>>> >>>> >> I have things working again. I had disabled Unix authentication in pam >> temporarily to try troubleshooting with my account. That had the side >> effect of disabling the cyrus user from authentication. So that explains >> the scripts using IMAP::Admin breaking. >> >> I also removed the package cyrus-sasl-md5 and I believe this has an impact >> on the issue I was facing with "CRAM-MD5". >> >> Any tips on how to co-exist with that package are welcomed. >> > > Cyrus imap will offer all available and initializable SASL authentication > plugins it can find (see pluginviewer for that list). In the case where you > have a plugin installed that you don't wish to offer, you can restrict the > list of mechanisms with the sasl_mech_list option. > > If you're depending on saslauthd for authentication, you shouldn't be > offering anything other than plain and login: > > sasl_mech_list: PLAIN LOGIN > > Right, I had more in my list. And since I didn't have the cyrus-sasl-md5 package before, the mentioning of MD5 mech types in the sasl_mech_list didn't matter. I have read some comments that suggest the MD5 mech options only work with sasl_pwcheck_method of auxprop, and won't work with pam via saslauthd. Is that true? That seems to be what you are saying as well. If not the case, I don't understand what would have been needed to enable the MD5 types of auth mechanism. Any pointers to where the MD5 types of mech are documented for configuration? For some reason, IMAP connections using TLS were not impacted by the change. I'm not sure of all of the ways it was broken because I wanted to get the service back up ASAP, but I do know Horde webmail was unable to connect using IMAP and notls. --Donald 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: Benachrichtung zum Übermittlungsstatus (Fehlges chlagen)
2010/7/4 Dan White > > Cyrus SASL requires that shared secrets be stored within an auxprop store, > such as sasldb. Regardless of what your sasl_pwcheck_method configuration > is, sasl will always use your auxprop plugin(s) to service the DIGEST-MD5 > plugin. To use DIGEST-MD5, you could use saslpasswd2 to store user > credentials within /etc/sasldb2. > > saslauthd, and pam, cannot perform the required handshaking that DIGEST-MD5 > requires, since the neither have knowledge of what the shared secret > (password) is. Thanks for the explanation. When I think about it, it makes sense that MD5 cannot work when it has to pass it on to another auth service. > More than likely you were dealing with clients that failed the DIGEST-MD5 > authentication and then fell back to PLAIN or pre-sasl login. > > If 'allowplaintext' is disabled in your imapd.conf, then PLAIN, LOGIN, and > pre-sasl login can only be achieved in the presence of TLS or some other > encryption. 'allowplaintext: 0' will prevent a clear text password from > being sniffed over the wire. > Yes. I don't know why one type of connection tries the next method while non-TLS only did CRAM-MD5 and then failed. I'll fix it to not reference the MD5 mech types. In our case the webmail and cyrus are on the same subnet used only in the data centre, so we are not concerned with access of data over the wire. With a few thousand people accessing webmail, I would be more concerned about the load of encrypting all that traffic between Cyrus and Horde. We do use TLS on the Horde login screen. --Donald 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: Scripting admin stuff?
Hi,
(I'm top posting as the previous posters have set in motion...)
I came across this old posting on the Cyrus mailing list. It is very close
to what
I want to do, simply extracting a list of mailboxes from within Perl.
For some reason our use of IMAP::Admin on Redhat 6 has stopped
working for the old script I've used before. Most calls work, but
@mailboxlist = $client->list( "*" ) returns an empty list, and
no errors can be forced to appear.
So I'm trying out Cyrus::IMAP::Admin, and rewriting the connection stuff.
In my case I need to specify the authentication info. I found an old web
page
which said I need to call it like this:
$client = Cyrus::IMAP::Admin->new( "$server" );
$auth = {
-mechanism => 'login',
-service => 'imap',
-authz => $uid,
-user => $uid,
-minssf => 0,
-maxssf => 1,
-password => $pwd,
};
$client->authenticate($auth);
When I use this, I get an error:
Error: Please login first
Finding docs and examples on Cyrus::IMAP::Admin is rather thin
on some details. Does anyone have a sample script which does
authentication/login?
--Donald
On Thu, Mar 26, 2009 at 1:37 PM, Jeff Blaine wrote:
> Thanks. I shortened it to the following. For those
> using this, it needs to run as cyrus (or whatever your
> cyrus user is).
>
> #!/linus/mail/cyrus/bin/perl
>
> $default_quota = 40;
>
> use Cyrus::IMAP::Admin;
> use Cyrus::IMAP;
>
> my $client = Cyrus::IMAP::Admin->new("YOUR_SERVER",143);
>
> $client->authenticate;
>
> @mailboxes = $client->list('%', 'user.');
>
> foreach $mbx ( @mailboxes ) {
> @m = @$mbx;
>
> $client->setquota($m[0],"STORAGE",$default_quota);
> }
>
>
> Paul M Fleming wrote:
> > Save you the work -- had to do the same thing myself.
> >
> > Modify as needed - for example, i use this with Kerberos auth so no
> > username / password is used.
> >
> >
> > #!/usr/bin/perl
> >
> > use Cyrus::IMAP::Admin;
> > use Cyrus::IMAP;
> > $default_quota = 20;
> >
> > my $client = Cyrus::IMAP::Admin->new("server",143);
> > $client->authenticate;
> > @mailboxes = $client->list('%', 'user.');
> > foreach $mbx ( @mailboxes )
> > {
> >
> > @m = @$mbx;
> >
> > ($root, %quota) = $client->quotaroot($m[0]);
> >
> > $cur_usage = $quota{"STORAGE"}[0];
> > $cur_quota = $quota{"STORAGE"}[1];
> >
> > if ( defined $cur_quota )
> > {
> > # quota defined
> > if ( $cur_quota < $default_quota )
> > {
> > print "$m[0] : below default increasing\n";
> >
> $client->setquota($m[0],"STORAGE",$default_quota);
> > }
> > if ( $cur_quota > $default_quota )
> > {
> > print "$m[0] : over default: $cur_quota
> > ($cur_usage / $cur_quota)\n";
> > }
> > }
> > else
> > {
> > print "$m[0] : NO QUOTA $cur_usage\n";
> > }
> >
> >
> >
> > }
> >
> >
> > On 3/26/2009 11:03 AM, Jeff Blaine wrote:
> >> In 2000, I wrote a simple script that was fed to cyradm
> >> to set all users quota to some value.
> >>
> >> It appears today that the only option to do something like
> >> this is to learn the Cyrus::* Perl modules.
> >>
> >> Is that correct?
> >>
> >> 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
>
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Script to list mailboxes, useful for PAM auth
I didn't see many living examples of how to do this, so I thought
it might be useful to share.
In our system, we have an LDAP auth backend which can be broader
than the mailboxes on a system. We didn't have any luck with
using pam_groupdn in pam_ldap.conf, so it is useful to use the PAM
module listfile. In pam.d/imap (same for pop or sieve) we would include:
authrequired pam_listfile.so onerr=fail item=user sense=allow
file=/cyrus/mailmgmt/mysystemlist
If you are not in this file list of users, but you have
authenticated against the backend OK, you won't get in.
Keeping that list of mailbox users updated is done by
a cron running the perl script following:
#!/usr/bin/perl -w
# Maintain a list of valid mailboxes on mysystem for pam authentication
purposes
use strict;
use Fcntl ':flock';
# Global variables for filenames, etc.
my( $basedir );
$basedir = "/cyrus/mailmgmt";
my( $PWD ) = $ENV{'PWD'};
chdir ( $basedir );
# Other global variables
my( %mysystemboxes, $now);
# Get the mailbox list from mysystem
%mysystemboxes = &get_mysystem_mailboxes( );
chdir( $PWD ) if ( $PWD );
exit 0;
#
# It's all subroutines from here on out
#
#
#
# Subroutine to get the mailbox list from mysystem.
#
sub get_mysystem_mailboxes( ) {
my( @mysystemboxes );
# Get the list of mailboxes from mysystem.example.com
@mysystemboxes = &get_mailbox_list( "localhost", "cyrusadm", "mypassword"
);
if( grep { /^IMAP error:/ } @mysystemboxes ) {
die "Error retrieving mailbox list from mysystem.\n@mysystemboxes\n";
}
# Dump the mailbox list to a file
open( SYSTEMBOXES, "> $basedir/mysystemlist " ) or die "Couldn't open
file: $!\n";
foreach( @mysystemboxes ) { print SYSTEMBOXES "$_\n"; }
print SYSTEMBOXES "cyrusadm\n";
close( SYSTEMBOXES ) or die "Couldn't close file: $!\n";
return %{ { map { $_ => 1 } @mysystemboxes } };
}
#
#
# Subroutine for an IMAP connection to get a mailbox list from a server
#
sub get_mailbox_list( $$$ ) {
use IMAP::Admin;
my( $server, $uid, $pwd ) = @_;
my( $client, $mailbox, @mailboxlist, @usernames, $username );
$client = IMAP::Admin->new( 'Server'=> "$server",
'Login' => "$uid",
'Password' => "$pwd",
'CRAM' => 0
) or
return "Couldn't create IMAP connection: $!\n";
@mailboxlist = $client->list( "user.*" ) or
return "IMAP error: \n\t" . $client->error . "\n";
$client->close;
foreach $mailbox ( @mailboxlist ) {
push @usernames, ${ [ split( /\./, $mailbox ) ] }[1];
}
@usernames = keys %{ { map { $_ => 1 } @usernames } };
return( @usernames );
}
It would need some adjustment for different type of authentication or
separator.
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
