unsub
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
Trouble restoring BDB databases on new OS... confused
SUMMARY: Attempting to upgrade Ubuntu results in 100% CPU tight-loops, not in a system call, maybe somewhere in Berkeley DB. Blowing away the db dir works, and I don't think there was anything important there, but what happened? DETAILS: I've just upgraded from Ubuntu Dapper Drake 32-bit to Ubuntu Gutsy Gibbon 64-bit. I *think* I was running a source-built Cyrus IMAPD 2.2.13. I had repointed my /var/lib/imap to /mail/imap, and was using BerkeleyDB 4.3 for anything that still used BDB. I do know that checkpointing hasn't run for a very, very long time, because when I switched from the packaged version to the source-built one, I forgot to update the path for ctl_cyrusdb in cyrusd.conf. Oops. So, back on Gutsy: I installed Cyrus from the Ubuntu packages; it says it's 2.2.13-11ubuntu1. I also installed libdb4.3. Started up cyrus, and "ctl_cyrusdb -r" is looping at 100% CPU, and has to be kill -9. db_recover, db_verify, etc. all had the same symptoms (but see below). According to strace, ctl_cyrusdb was not opening *any* of the .db files; it's looking at: 1. itself 2. some libraries 3. imapd.conf 4. /mail/imap/DB_CONFIG (doesn't exist) 5. /var/tmp 6. /mail/imap/db/__db.001 When I look in /mail/imap/db, I see: 2006-09-25 13:14 log.50.old 2006-09-26 18:01 skipstamp -- 2006-09-26 18:01 __db.001 through 2006-09-26 18:01 __db.005 -- 2007-06-17 12:16 log.60 through 2008-03-05 13:49 log.76 So as I understand it, this isn't "the" database; it's BDB transactions and/or log files for ALL of the various databases: /mail/imap# file *.db annotations.db: Cyrus skiplist DB deliver.db: Berkeley DB (Btree, version 8, native byte-order) mailboxes.db:Cyrus skiplist DB tls_sessions.db: Berkeley DB (Btree, version 8, native byte-order) Not understanding that, I was trying to db4.3_recover the db/ directory itself, and saw the same symptoms: db_recover would open and mmap the __db.001 file, and then completely hang and need a kill -9 to go away. Same for db_stat, db_verify, db_dump, db_printlog. (Hey, maybe that's a clue: Is it trying to open a 32-bit shared-memory region on a 64-bit OS, or something like that?) Figuring that the db/ directory would contain nothing but deliver.db and tls_sessions.db data, and that (from what I read) neither are important state info for a one-user mail system, I just blew away the db/ directory and deliver.db. (I didn't think to blow away tls_sessions.db but it seems happy enough now.) So everything *seems* to be working OK now, but I don't quite understand what happened, and what I was supposed to do to "fix" it more properly (other than having run checkpointing in the first place). If I go back to a freshly-restored backup, understanding what the different DBs are now, I still see weird behavior: /tmp/berkeley-recover# ls annotations.db db/ deliver.db log.01 mailboxes.db tls_sessions.db /tmp/berkeley-recover# db4.3_recover [returns instantly] /tmp/berkeley-recover# db4.3_verify deliver.db db_verify: Page 239: incorrect next_pgno 244 found in leaf chain (should be 60) db_verify: Page 60: incorrect prev_pgno 44 found in leaf chain (should be 239) ... [many more linking errors] ... db_verify: Page 0: page 250 encountered a second time on free list db_verify: deliver.db: DB_VERIFY_BAD: Database verification failed /tmp/berkeley-recover# db4.3_recover -c [returns instantly] /tmp/berkeley-recover# db4.3_verify -N deliver.db [same results as before] Can anyone give me more insights into what I'm seeing, so I know better next time? 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
Commerical Cyrus IMAPD support?
I've been wrestling with IMAPD/SASL problems for a few days, trying to get a formerly-working sasldb setup onto a new (Ubuntu) server. I'm at a dead end; I get "no secret in database" no matter what I try. I imagine I could build SASL and IMAPD with symbols and step through with gdb, but that's painful. I also imagine that someone who works with this every day finds this easy, and I'd love to pay someone to Just Fix It. Anyone know of a commercial provider for Cyrus support? Ken Murchison offered that a few years ago but, now that he works for CMU, that's a bit of a conflict of interest. Ideally, I'm looking for per-incident or per-hour support; I have but a single mailbox on the system and wouldn't have much use for an ongoing contract. Jay Levitt 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: More NTLM headaches with OE6
> > How have others dealt with this problem (aside from switching clients)? > > IMAP over SSL on port 993 Yeah, that's the direction I'm leaning in as well. Does performance suffer at all from the encryption? I'm in the process of setting up OpenSSL but haven't got very far yet. That's my one big concern. Ideally, I'd like to set an "allowplaintextnotincludingjayshomenetworkwhichofcourseissecurefrompacketsni fferssincehelivesalone: no" option in imapd.conf. Jay
Re: Fw: PATCH: have lmtpd report sieve script file errors
By the way.. just noticed a bug in the RPM's version of imapd.conf. It sets "sieveuserhomedir" to no. The actual imapd.conf variable is "sieveusehomedir" (use, not user). It doesn't matter, because the default is no, but should probably be fixed anyway, lest someone get confused when they try to set it to yes! Jay - Original Message - From: "Luca Olivetti" <[EMAIL PROTECTED]> To: "Jay Levitt" <[EMAIL PROTECTED]> Cc: "info-cyrus" <[EMAIL PROTECTED]> Sent: Sunday, February 23, 2003 10:19 AM Subject: Re: Fw: PATCH: have lmtpd report sieve script file errors > Jay Levitt wrote: > > I forgot to CC you on this question... > > Strange, I didn't see this message on info-cyrus, anyway: > > >>Also, the reason I discovered this is that Mandrake's "msec" > >>security-auditing process automatically chowns /usr/sieve to root.root > >>several times a day. Luca, do you think this is something that the RPMs > >>should override in /etc/security/perm.local to cyrus.mail, either > >>automatically or (if such a thing is possible) after prompting? I'm of > > The RPM uses /var/lib/imap/sieve by default, and that isn't affected by > msec, at least it isn't on my two systems, one 8.2 and the other 9.0, > both with security level 3 (implying CHECK_PERMS=yes). > I've checked the perm configuration files for all levels and none of > them touches anything under /var/lib. > > Bye > -- > Luca Olivetti > >
PATCH: have lmtpd report sieve script file errors
Right now, lmtpd assumes that if fopen() fails on the sieve script, it must be because the file isn't there, which is a valid condition, so no error is logged. Since two people this week had permissions problems, seems like something that ought to be logged. This simple patch does it. Jay Levitt lmtpd.report-sieve-err.diff Description: Binary data
Sieve isn't sieving
I'm trying to set up Sieve for the first time on Cyrus IMAPD 2.1.12. I'm delivering via sendmail 8.12.6, using LMTP. Sieve is reading the script; I can see the atime change, and if I try to "fileinto" a nonexistent mailbox I get a sieve runtime error in syslog. However, nothing in the script has any effect. I've tried simple one-line scripts that should refile all mail in another folder or reject all mail, and it all lands right in my inbox. My mail does have the "X-Sieve: CMU Sieve 2.2" header. What could be going wrong, and how can I troubleshoot? Jay Levitt
Sendmail LUSER_RELAY w/Cyrus: Default mailbox?
Using Cyrus 2.1.12 and sendmail 8.12.6, I would like mail for all unknown users to be delivered to a specific mailbox. I've tried setting LUSER_RELAY, but since sendmail hands off all local mail to Cyrus, the LUSER_RELAY is ignored. I do have confLOCAL_MAILER defined as cyrusv2. I found a very old message here suggesting a trick with rulesets and a text file containing a list of all IMAP users. I also found a patch from Carsten Hoeger this past August (which was never incorporated into the main sources) that adds an lmtp_luser_relay option to imapd.conf. Are these still the only way, or is there a more correct way to do this? If not, any chance that this patch could be incorporated into Cyrus?
IDLED doesn't notify
I'm using Outlook Express 6 with Cyrus 2.1.12. When I send an e-mail to myself, IDLED notifies the "user.jay.Sent Items" mailbox, but not the "user.jay.Inbox" mailbox. I verified that there is an open, IDLEing IMAP connection with Inbox SELECTed at the time. I tried to step through idle_update() myself, but because of the way OE opens frequent new sockets, it's very difficult to debug this; I'm never attached to the right process. Any ideas what might be going wrong? Any tips on how to debug? Jay Levitt
Re: Outlook 2002 vs. Cyrus 2.1.12
> I just did some testing myself with Outlook 2000 and Outlook Express 6. > I couldn't get either client to hang after doing APPENDs (with IDLE > enabled). OE does close the connection after calling IDLE after the > final APPEND however. FWIW, and not that it matters in this case, OE and Outlook Express share very little (if any) code. They're developed in two different divisions. The name similarity is a marketing thing.
Re: quick and dirty patch for flushing seen state
"John A. Tamplin" <[EMAIL PROTECTED]> wrote: > Here is a quick and dirty patch for flushing the seen state whenever it > changes, relative to 2.1.11. Works great for me on Outlook Express 6. Jay Levitt
Re: issues with conversion from UW Imap
> how much of a performance hit would be taken to just add code like this at the end of cmd_fetch You are my hero! Gonna try this out. > One OE 6.0 user reported seeing really strange behavior where occasionally messages would > show as deleted in OE (never having been read), and when she tried to view the message it gave > an error saying the message no longer existed. Other mail clients accessing the same mailbox > while this was happening saw the messages with no difficulties, and deleting the account and > recreating it in OE made them visible again. I haven't seen this on Cyrus yet, but it happens all the time to me on UW imapd. It seems to be a bug in OE related to error handling. UW imapd (using mbox format) gets very confused when OE opens multiple sockets on the same folder, and usually drops one of them. Sometimes, when that happens, OE thinks the message has been deleted from the server. It can also happen if you try to read a message after OE has fetched the headers but before it's actually fetched the body. You don't have to delete and recreate the account to work around the problem; simply drag the offending message to another folder and back, then purge deleted messages in both folders. Jay
Re: Huge Inbox
Wander writes: > Some of our users really doesn´t have much time to decrease the INBOX, neither > distributing messages across subfolders or deleting it as fast as could be > necessary and as consequence, theirs INBOX are growing and growing and making > things very slow... Are you using skiplist for your mboxlist? I have over 7000 messages in my inbox and it's zippy as can be... Jay Levitt
Re: Updating /seen from concurrent sessions
> I have no plans on changing how seen state is currently cached. We haven't > had any complaints from our users and (now that we found the cyrusdb_flat > problem) it doesn't seem like it is that huge an uissue for most other > sites, either. Interesting. Can you tell me the semantics of the caching offhand, or point me to where in the code I might look? I wonder if this is something that manifests itself more on smaller systems; in my case, I'm the only user. If I mark a message as seen using OE6, then refresh, the message becomes unseen, every time. Only switching folders (which probably closes the IMAP connection) makes things stay seen. It sounded from the earlier discussion like the caching wouldn't be affected by multiple users, only by how quickly the client closes the connection, but if nobody else is running into this, maybe it is affected by simultaneous users as well? Jay
Re: Updating /seen from concurrent sessions
> I believe I've fixed this bug in CVS (did it a few days ago, actually) > and it'll be in the next release. If I understand correctly, this fixes the flat-file seen implementation, but not the underlying problem, which is that updates to seen are deferred until the connection is closed. Am I following? If so, is there any chance of updating more frequently in a future release? OE is certainly a popular client, and it sounds like Mozilla has the same problem. I can duplicate this at will in OE with a skiplist seen db. Jay Levitt
Backing up db directory
Am I correct in assuming that the "db" directory doesn't need to be backed up - in fact should not be backed up - and I should instead be backing up the db.backup1 and db.backup2 dirs and using reconstruct to recreate db itself? Jay Levitt
Re: Newbie help: Domain names as part of user names/mailboxes/etc?
> Try using saslauthd and see if that works for you.Put > > sasl_pwcheck_method: saslauthd > sasl_mech_list: PLAIN > > in /etc/imapd.conf and start saslauthd Yep, that worked.. > You should then be able to log in using your unix system name and > password. That should let you verify that cyrus imap is working properly > and that you can get email. > > If that works I would delete /etc/sasldb2, recreate it and start fresh > with one user name. I don't know why you could be having this problem > unless you used the -u DOM option in saslpasswd2. That also worked. I don't get it, but it worked. sasldblistusers2 output looks exactly the same, but it worked. Thanks. When in doubt, delete everything and try the exact same thing again to see if it works the second time. Nevermind definitions of insanity! > > Harris > > > On Tue, 2002-11-26 at 14:06, Jay Levitt wrote: > > > At least on my server, it doesn't matter. Even though sasldblistusers2 > > > shows me as [EMAIL PROTECTED], I still sign in from Outlook > > > and Evolution as harrisl and my mailboxes which were created with cyradm > > > are in the form user.harrisl.inbox etc. Remember you still have to > > > create user jay in cyradm even though you already created a password for > > > user jay in saslpassword2. The username that you set up in cyradm is > > > what the imap server will know you as. Sasl will be used for > > > authentication if you use auxprops in your config and you don't supply > > > your domain when signing in. Try signing in with imtest -m login as jay > > > after creating a password for jay with saslpassword2 and you will see > > > that it works. > > > > Not on my server... :( That's how I started digging into the whole mess in > > the first place. When sasldblistusers2 shows [EMAIL PROTECTED], I > > cannot login with imtest (or a real client) as just "jay", only as > > [EMAIL PROTECTED] Maybe there is something wrong with my imapd.conf? > > > > Jay > -- > Harris Landgarten <[EMAIL PROTECTED]> >
Re: Newbie help: Domain names as part of user names/mailboxes/etc?
> At least on my server, it doesn't matter. Even though sasldblistusers2 > shows me as [EMAIL PROTECTED], I still sign in from Outlook > and Evolution as harrisl and my mailboxes which were created with cyradm > are in the form user.harrisl.inbox etc. Remember you still have to > create user jay in cyradm even though you already created a password for > user jay in saslpassword2. The username that you set up in cyradm is > what the imap server will know you as. Sasl will be used for > authentication if you use auxprops in your config and you don't supply > your domain when signing in. Try signing in with imtest -m login as jay > after creating a password for jay with saslpassword2 and you will see > that it works. Not on my server... :( That's how I started digging into the whole mess in the first place. When sasldblistusers2 shows [EMAIL PROTECTED], I cannot login with imtest (or a real client) as just "jay", only as [EMAIL PROTECTED] Maybe there is something wrong with my imapd.conf? Jay
Re: Newbie help: Domain names as part of user names/mailboxes/etc?
> Why don't you just use jay as your sasldb2 username. Log in for mail > using jay and your sasldb2 password. Set your MTA masquerade as jay.fm > when you send mail outside your house. That's what I do in my house. That's what I was trying to do, but saslpasswd2 automatically appends the FQDN of the machine if I don't supply a domain name. How do I get it not to do that? Jay
Newbie help: Domain names as part of user names/mailboxes/etc?
Hi.. can anyone shed light on this? -- I'm setting up a simple server for home use. The server is running on the cleverly-named machine linux.home.jay.fm, and will be serving mail for jay.fm. I am, for starters, using auxprop with sasldb to keep things simple. I'm running imapd 2.1.10 and SASL 2.1.9. I am creating exactly one mailbox for [EMAIL PROTECTED] There seems to be a built-in contradiction in the way Cyrus understands users and mailbox names. saslpasswd2 appends the FQDN of the server, so that saslpasswd2 -c jay creates a mailbox "[EMAIL PROTECTED]". If I explicitly supply a domain name, like saslpasswd2 -c [EMAIL PROTECTED] the mailbox is created as [EMAIL PROTECTED] So far so good. But imapd, by default, uses dots as separators. So I can't just do: createmailbox [EMAIL PROTECTED] because that ends up looking like mailbox jay@jay with sub-mailbox fm. And I can't just: createmailbox jay because I must authenticate as "[EMAIL PROTECTED]" and not just "jay". I realize that I could use unixhierarchysep, and I probably will end up doing so anyway, but I suspect that there is a simpler answer I'm not seeing. I've tried setting loginrealms: jay.fm in imapd.conf, but that doesn't do it. What is the correct way to handle this? Is there some way to create SASLDB users that have no domain name appended? I presume every installation has to deal with this in some form or another.
Relationship between realm, mailbox and SASL user
I'm setting up a simple server for home use. The server is running on the cleverly-named machine linux.home.jay.fm, and will be serving mail for jay.fm. I am, for starters, using auxprop with sasldb to keep things simple. I'm running imapd 2.1.10 and SASL 2.1.9. I am creating exactly one mailbox for [EMAIL PROTECTED] There seems to be a built-in contradiction in the way Cyrus understands users and mailbox names. saslpasswd2 appends the FQDN of the server, so that saslpasswd2 -c jay creates a mailbox "[EMAIL PROTECTED]". If I explicitly supply a domain name, like saslpasswd2 -c [EMAIL PROTECTED] the mailbox is created as [EMAIL PROTECTED] So far so good. But imapd, by default, uses dots as separators. So I can't just do: createmailbox [EMAIL PROTECTED] because that ends up looking like mailbox jay@jay with sub-mailbox fm. And I can't just: createmailbox jay because I must authenticate as "[EMAIL PROTECTED]" and not just "jay". I realize that I could use unixhierarchysep, and I probably will end up doing so anyway, but I suspect that there is a simpler answer I'm not seeing. I've tried setting loginrealms: jay.fm in imapd.conf, but that doesn't do it. What is the correct way to handle this? I presume every installation has to deal with this in some form or another.
Re: Best way to backup cyrus system
- Original Message - From: "Rob Siemborski" <[EMAIL PROTECTED]> To: "Alessandro Oliveira" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, November 21, 2002 3:28 PM Subject: Re: Best way to backup cyrus system > On Thu, 21 Nov 2002, Alessandro Oliveira wrote: > > > I'm planning to code a database backend (postgres/mysql/oracle) in the > > future to handle the storage, but this will take time and money, but I > > think it is the way to go. > > > > What do you think about this ? > > I'm not convinced this will be even close to easy to do, since it will > require a lot of thought as to how to optimize the SQL queries for IMAP. That is an understatement. The AOL mail system back end, while predating IMAP, actually has a similar structure, and it essentially sits on top of databases. For the AOL client, that's no problem, but because of the huge flexibility that IMAP gives a client in structuring queries, it's next to impossible to make a truly efficient database back end for it. When we added minimal IMAP client support for CompuServe users, we had to make all sorts of special tweaks and assumptions and limitations and caching kludges. It's unbelievably tricky. Expect to spend a few years on it. Jay Levitt
Re: Thoughts on the age-old cyradm thingie
- Original Message - From: "Luca Olivetti" <[EMAIL PROTECTED]> To: "Jay Levitt" <[EMAIL PROTECTED]> Cc: "Simon Matter" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, November 21, 2002 3:07 AM Subject: Re: Thoughts on the age-old cyradm thingie > Jay Levitt wrote: > > Interesting. That patch just installs Shell.pm into vendor_perl instead of > > site_perl. But when I ran the stock Cyrus configure on MDK 9.0, I had no > > problem with it running in site_perl; the problem I had was just that > > site_perl is not actually under PREFIX, and Makefile.PL passes PREFIX > > explicitly. What problems did you have under 9.0? > > site_perl isn't used by default in mdk 9.0 (or perl 5.8.0, look at the > changelog for perl-base, search vendor_perl), so it would generate bogus > dependencies when creating the rpm (files under site_perl would depend > on perl-base >= 5.800 --which doesn't exist, rendering the resulting rpm > impossible to install-- while files under vendor_perl depend on > perl-base >= 2:5.8.0). OIC (sorta).. so it's an RPM problem more than a perl problem. That explains why it worked for me when I just built from source - it seems that site_perl actually IS part of @INC, but it sounds like you're saying rpm doesn't think so. I haven't learned much about rpms yet, but I'll take your word... > > Conversely, it doesn't seem like your RPM changes PREFIX, so do you know > in the build part the %configure macro will automatically call configure > --prefix=/usr (and other standard parameters) while in the install part > make install is called with PREFIX=/current/build/root Ah, ok.. I was just looking at the spec file, didn't realize rpm added its own configure parameters. I looked at rpm --showrc, I get it now. I actually wonder if, since this isn't a Mandrake-supplied RPM, it wouldn't be better to install to /usr/local instead of /usr, but it's not a big deal. Of course, that'd require fixing the perl problem in the first place :) > BTW: my message won't reach you directly since your ISP, in a misguided > attempt to block spam, will bounce my messages. Yeah, apparently a hacker tried to get in via an OpenSSL vulnerability that Sun didn't patch, and while he wasn't completely successful, he screwed up their portsentry, which was then blocking stuff that oughtn't be blocked. I don't follow what happened exactly, but it just makes me that much more anxious to get this up and running so I can run my own mail server. Should be fixed now, though. Jay
Re: Thoughts on the age-old cyradm thingie
Interesting. That patch just installs Shell.pm into vendor_perl instead of site_perl. But when I ran the stock Cyrus configure on MDK 9.0, I had no problem with it running in site_perl; the problem I had was just that site_perl is not actually under PREFIX, and Makefile.PL passes PREFIX explicitly. What problems did you have under 9.0? Conversely, it doesn't seem like your RPM changes PREFIX, so do you know offhand how Shell.pm ends up getting installed properly in /usr/lib instead of /usr/local? Thinking further about this, I no longer like my idea of a separate --perl-prefix configure option, because if I do "configure --prefix=/home/jay", I should reasonably expect that nothing is being installed into sitewide libraries. So now I'm back to thinking that if --prefix is not explicitly set, we shouldn't pass it to MakeMaker, which is, after all, supposed to be in charge of knowing where perl libraries are supposed to go. Are there systems where NOT passing PREFIX to MakeMaker does the wrong thing? - Original Message - From: "Luca Olivetti" <[EMAIL PROTECTED]> To: "Simon Matter" <[EMAIL PROTECTED]> Cc: "Jay Levitt" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, November 19, 2002 4:05 AM Subject: Re: Thoughts on the age-old cyradm thingie > Simon Matter wrote: > > part of their distributions in the past. I looked at so many Perl source > > RPMs from RedHat but was unable to do the same with Cyrus. So, if there > > is really something broken in the perl part of Cyrus and could be fixed, > > I'd be happy to see it. > > I've been luckier: I just had to look at a single source rpm (but that's > because I asked and someone told me which one was the right one ;-) > Attached is the patch that I had to apply to build under mandrake 9.0 > but *not* under 8.2 (the former comes with perl 5.8.0 while the latter > uses 5.6.1). OTOH on 8.2 I have to manually install the perl manpages in > the spec file. I'm not sure the patch should go upstream since it's > distribution policy (or is it perl policy since 5.8.0? I don't know) > If you look at the spec file, posted at > http://perso.wanadoo.es/olivetti/cyrus/cyrus-imapd.spec, you'll see that > there are other hacks to build with gcc 3.2 (mainly to remove > /usr/local/include in order to avoide configure failures). > > Bye > -- > Luca Olivetti > Wetron Automatización S.A. http://www.wetron.es/ > Tel. +34 93 5883004 Fax +34 93 5883007 >
Re: Thoughts on the age-old cyradm thingie
Thanks! That's very helpful, especially given the notes from Henrique about patches - sounds like I don't want to be running a stock imapd on Linux. Still, it'd be good to fix this in the source distribution as well. After thinking about it, I suspect adding --perl-prefix to configure is probably the right way to do it; if it's not specified, leaving it blank would then let MakeMaker put it in the right place. What do people think? I'm happy to try my hand at a patch; I've been meaning to learn autoconf for a few years now, and I even bought the dead-tree version of the book. Jay - Original Message - From: "Luca Olivetti" <[EMAIL PROTECTED]> To: "Jay Levitt" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, November 18, 2002 3:12 AM Subject: Re: Thoughts on the age-old cyradm thingie > Jay Levitt wrote: > > I'm new to Cyrus imapd - and, for that matter, to autoconf, perl, Linux, > > younameit. Building cyrus-imapd-2.1.10 on Mandrake 9.0, I ran into a > > > http://perso.wanadoo.es/olivetti/cyrus/ > > > -- > Luca Olivetti > Wetron Automatización S.A. http://www.wetron.es/ > Tel. +34 93 5883004 Fax +34 93 5883007 >
Thoughts on the age-old cyradm thingie
I'm new to Cyrus imapd - and, for that matter, to autoconf, perl, Linux, younameit. Building cyrus-imapd-2.1.10 on Mandrake 9.0, I ran into a problem that people have been running into for years: perl wants to find modules like Shell.pm under /usr/lib/perl5, but Shell.pm is actually getting installed under /usr/local/lib/perl5. It turns out that line 83 of perl/Makefile.in is set to pass @prefix@ to perl/imap/Makefile.PL, the MakeMaker, er, maker. Reading the resulting perl/imap/Makefile, I get the impression that on most platforms, variables like INSTALLSITELIB are hardcoded to /usr/..., but on Mandrake, they are set to $PREFIX/... instead. Manually running Makefile.PL with no arguments fixes the problem; MakeMaker seems to know the "right" place to put things by default. A quick fix might be for perl/Makefile to only pass @prefix@ to perl/imap/Makefile.PL if it is not equal to $ac_default_prefix from configure. That way, default installs work, and explicit installs to different places work too. (Or at least they work to the extent they work today, which assumes that whatever your --prefix is, there are some site_perl directories in your @INC@ path. I have no idea how valid an assumption that really is, or if it's worth having configure warn you if you change your prefix.) An alternate fix would be for configure to go find perl, see where it's installed, add a new --perl-prefix argument that defaults here, and then pass THAT to Makefile.PL instead. Cyrus folks, what do you think? I don't have the background to know which of these two ideas is actually more portable or correct, but this problem seems to pop up fairly consistently on info-cyrus and on newsgroups.. sure would be nice to fix it. Jay Levitt
