unable to authenticate
Hello list,
I've installed cyrus-imapd 2.1.13 and cyrus-sasl 2.1.13, but I am having
trouble authenticathing.
I don't want to create unix users for every imap user so I'd like to use
the sasldb athentication.
I'm using Solaris 8 platform.
My sasldb is at /etc/sasldb2 and the cyrus user can read the /etc/sasldb2
file.
This is my /etc/imapd.conf file:
configdirectory: /var/imap
defaultpartition: default
partition-default: /var/spool/imap
admins: cyrus
sievedir: /usr/sieve
sendmail: /usr/lib/sendmail
sasl_pwcheck_method: auxprop
sasl_auxprop_plugin: sasldb
sasl_sasldb_path: /etc/sasldb2
tls_cert_file: /var/imap/server.pem
tls_key_file: /var/imap/server.pem
postmaster: ean
allowanonymouslogin: no
allowplaintext: yes
sasl_mech_list: PLAIN
servername: delius.upc.es
autocreatequota: 1
reject8bit: no
quotawarn: 90
timeout: 30
poptimeout: 10
dracinterval: 0
drachost: localhost
sieve_maxscriptsize: 32
sieve_maxscripts: 5
altnamespace: yes
duplicatesuppression: yes
hashimapspool: true
unixhierarchysep: yes
I've tried to create the cyrus user with saslpasswd2 and it seems to work.
The sasldblistusers2 shows:
[EMAIL PROTECTED]: userPassword
but this is the response when I try to connect using imtest:
imtest -a cyrus -m login localhost
S: * OK delius.upc.es Cyrus IMAP4 v2.1.13 server ready
C: C01 CAPABILITY
S: * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ MAILBOX-REFERRALS
NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND SORT
THREAD=ORDEREDSUBJECT THREAD=REFERENCES IDLE STARTTLS
S: C01 OK Completed
Please enter your password:
C: L01 LOGIN cyrus {7}
S: + go ahead
C: omitted
S: L01 NO Login failed: user not found
Authentication failed. generic failure
Security strength factor: 0
Am I missing something? Are there something wrong?
Any help would be much appreciated.
- ANNA -
RE: seen file corruption
Hi, I don't suppose that custom MySQL connector is 'available' is it? Regards, Gareth. On Thu, 2003-06-12 at 18:22, Brasseur Valry wrote: I use a custom mysql database connector for my mailboxes ! -Original Message- From: Rob Siemborski [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2003 7:22 PM To: Brasseur Valry Cc: [EMAIL PROTECTED] Subject: RE: seen file corruption On Thu, 12 Jun 2003, [iso-8859-1] Brasseur Valry wrote: just seen state You're hitting a bug then. Any chance you can convert your mboxlist to skiplist? -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper -- Gareth Bult - Frontier Internet Services Limited Tel: 02920 820 000 Fax: 02920 820 035 Email: [EMAIL PROTECTED] Web: www.bult.co.uk Statements made are at all times subject to Frontier's Terms and Conditions of Business, which are available upon request.
Re: notes on Sieve and cyrus-imapd-2.2a
Henrique de Moraes Holschuh wrote: On Thu, 12 Jun 2003, Ken Murchison wrote: I seem to recall this being fixed in CVS as well. IMHO CMU should package a 2.2alpha2. Too many fixes are already in CVS... enough that nobody should be using 2.2alpha anymore. That will probably happen soon. There are a few things that I want to get done first. -- 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
Trying to deliver to sub folder
Cyrus 2.1.13
According to the man page for deliver the cat ... command below should
put the message in the Junk folder however it goes directly into the INBOX.
Clip from 'man deliver:
-m mailbox
Deliver to mailbox. If any userids are specified,
attempts to
deliver to user.userid.mailbox for each userid. If the
ACL on
any such mailbox does not grant the sender the p
right or if
-m is not specified, then delivers to the INBOX for the
userid,
regardless of the ACL on the INBOX.
If no userids are specified, attempts to deliver to
mailbox. If
the ACL on mailbox does not grant the sender the p
right, the
delivery fails.
cyradm:
localhost lam user.boutilpj
boutilpj lrswipcda
cyrus lrswpa
localhost lam user.boutilpj.Junk
boutilpj lrswipcda
cyrus lrswpa
Any ideas?
cat mail.txt|strace -fF /usr/cyrus/bin/deliver -m Junk boutilpj
execve(/usr/cyrus/bin/deliver, [/usr/cyrus/bin/deliver, -m,
Junk, boutilpj], [/* 19 vars */]) = 0
uname({sys=Linux, node=student.ednet.ns.ca, ...}) = 0
brk(0) = 0x80766c0
open(/etc/ld.so.preload, O_RDONLY)= -1 ENOENT (No such file or
directory)
open(/usr/local/lib/i686/mmx/libsasl2.so.2, O_RDONLY) = -1 ENOENT (No
such file or directory)
stat64(/usr/local/lib/i686/mmx, 0xb250) = -1 ENOENT (No such file
or directory)
open(/usr/local/lib/i686/libsasl2.so.2, O_RDONLY) = -1 ENOENT (No such
file or directory)
stat64(/usr/local/lib/i686, 0xb250) = -1 ENOENT (No such file or
directory)
open(/usr/local/lib/mmx/libsasl2.so.2, O_RDONLY) = -1 ENOENT (No such
file or directory)
stat64(/usr/local/lib/mmx, 0xb250) = -1 ENOENT (No such file or
directory)
open(/usr/local/lib/libsasl2.so.2, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`/\0\000...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=371313, ...}) = 0
old_mmap(NULL, 72104, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40013000
old_mmap(0x40024000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED,
3, 0x1) = 0x40024000
close(3)= 0
open(/usr/local/lib/libssl.so.2, O_RDONLY) = -1 ENOENT (No such file
or directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=31245, ...}) = 0
old_mmap(NULL, 31245, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40025000
close(3)= 0
open(/lib/libssl.so.2, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360\220...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=224721, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x4002d000
old_mmap(NULL, 195076, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4002e000
old_mmap(0x4005b000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED,
3, 0x2d000) = 0x4005b000
close(3)= 0
open(/usr/local/lib/libcrypto.so.2, O_RDONLY) = -1 ENOENT (No such
file or directory)
open(/lib/libcrypto.so.2, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p9\2\000...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=995665, ...}) = 0
old_mmap(NULL, 875620, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4005e000
old_mmap(0x40125000, 49152, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED,
3, 0xc7000) = 0x40125000
old_mmap(0x40131000, 11364, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40131000
close(3)= 0
open(/usr/local/lib/libresolv.so.2, O_RDONLY) = -1 ENOENT (No such
file or directory)
open(/lib/libresolv.so.2, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\230\'\0...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=69443, ...}) = 0
old_mmap(NULL, 69444, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40134000
old_mmap(0x40142000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED,
3, 0xe000) = 0x40142000
old_mmap(0x40143000, 8004, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40143000
close(3)= 0
open(/usr/local/lib/libdb-4.0.so, O_RDONLY) = -1 ENOENT (No such file
or directory)
open(/lib/libdb-4.0.so, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\27...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0555, st_size=760175, ...}) = 0
old_mmap(NULL, 686348, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40145000
old_mmap(0x401eb000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED,
3, 0xa5000) = 0x401eb000
close(3)= 0
open(/usr/local/lib/libc.so.6, O_RDONLY) = -1 ENOENT (No such file or
directory)
open(/lib/libc.so.6, O_RDONLY)= 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\210U\1...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1377691, ...}) = 0
old_mmap(NULL, 1219172, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x401ed000
Re: Compiling Cyrus IMAPD on AMD Opteron
Compiling with the -fPIC fixes the problem. I had to do this for the following: imclient.c imparse.c xmalloc.c imapurl.c iptostring.c assert.c util.c libisieve.c prot.c Why does -fPIC fix this problem? [EMAIL PROTECTED] wrote: make[2]: Entering directory `/root/src/cyrus-imapd-2.1.13/perl/imap' rm -f blib/arch/auto/Cyrus/IMAP/IMAP.so LD_RUN_PATH=/usr/lib64 cc -shared -L/usr/local/lib64 IMAP.o -o blib/arch/auto/Cyrus/IMAP/IMAP.so ../../lib/libcyrus.a -lssl -lcrypto /usr/lib64/gcc-lib/x86_64-suse-linux/3.2.2/../../../../x86_64-suse-linux/bin/ld: ../../lib/libcyrus.a(imclient.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC ../../lib/libcyrus.a: could not read symbols: Bad value collect2: ld returned 1 exit status make[2]: *** [blib/arch/auto/Cyrus/IMAP/IMAP.so] Error 1 make[2]: Leaving directory `/root/src/cyrus-imapd-2.1.13/perl/imap' make[1]: *** [all] Error 1 make[1]: Leaving directory `/root/src/cyrus-imapd-2.1.13/perl' make: *** [all] Error 1 [snippet] Can anyone help me with it? I wanted to get it working to test out the performance of the system. What you need to look at is where imclient.c was compiled. Either it wasn't compiled with -shared, or the gcc port is not properly choosing the right flags for -shared. Run the cc command yourself in that directory, adding the -v flag and see if -fPIC gets passed to cc1. If not, you can fix the problem just by adding -fPIC yourself in the compile commands. If it is getting passed, then it looks like the machine definition is improperly choosing a particular addressing mode when generating PIC code and that will need to get fixed by whoever maintains the x86_64 machine description for gcc. -- John A. Tamplin Unix System Administrator Emory University, School of Public Health +1 404/727-9931 --- Curtis Robinson [EMAIL PROTECTED]
Re: notes on Sieve and cyrus-imapd-2.2a
On Fri, 13 Jun 2003, Henrique de Moraes Holschuh wrote: On Thu, 12 Jun 2003, Ken Murchison wrote: I seem to recall this being fixed in CVS as well. IMHO CMU should package a 2.2alpha2. Too many fixes are already in CVS... enough that nobody should be using 2.2alpha anymore. We're still working on some last minute things, and I'm doing other work at the moment. I'm anticipating doing a next 2.1 version of both SASL and Cyrus, and probably shortly thereafter a 2.2.1-ALPHA -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: notes on Sieve and cyrus-imapd-2.2a
On Fri, 13 Jun 2003, Rob Siemborski wrote: I'm anticipating doing a next 2.1 version of both SASL and Cyrus, and probably shortly thereafter a 2.2.1-ALPHA ...by early next month. ;) -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Trying to deliver to sub folder
If you're using deliver, the user that needs post access to the mailbox
is not cyrus, but anonymous. So sam user.boutilpj anonymous p (or
anyone p) is what you need. Should work after you do that.
Michael
--On Friday, June 13, 2003 9:35 AM -0300 Patrick Boutilier
[EMAIL PROTECTED] wrote:
Cyrus 2.1.13
According to the man page for deliver the cat ... command below should
put the message in the Junk folder however it goes directly into the
INBOX.
Clip from 'man deliver:
-m mailbox
Deliver to mailbox. If any userids are specified,
attempts todeliver to user.userid.mailbox for each
userid. If the ACL onany such mailbox does not grant
the sender the p right or if-m is not specified, then
delivers to the INBOX for the userid,regardless of the
ACL on the INBOX.
If no userids are specified, attempts to deliver to
mailbox. Ifthe ACL on mailbox does not grant the sender
the p right, thedelivery fails.
cyradm:
localhost lam user.boutilpj
boutilpj lrswipcda
cyrus lrswpa
localhost lam user.boutilpj.Junk
boutilpj lrswipcda
cyrus lrswpa
Any ideas?
cat mail.txt|strace -fF /usr/cyrus/bin/deliver -m Junk boutilpj
execve(/usr/cyrus/bin/deliver, [/usr/cyrus/bin/deliver, -m, Junk,
boutilpj], [/* 19 vars */]) = 0 uname({sys=Linux,
node=student.ednet.ns.ca, ...}) = 0
brk(0) = 0x80766c0
open(/etc/ld.so.preload, O_RDONLY)= -1 ENOENT (No such file or
directory) open(/usr/local/lib/i686/mmx/libsasl2.so.2, O_RDONLY) = -1
ENOENT (No such file or directory) stat64(/usr/local/lib/i686/mmx,
0xb250) = -1 ENOENT (No such file or directory)
open(/usr/local/lib/i686/libsasl2.so.2, O_RDONLY) = -1 ENOENT (No such
file or directory) stat64(/usr/local/lib/i686, 0xb250) = -1 ENOENT
(No such file or directory) open(/usr/local/lib/mmx/libsasl2.so.2,
O_RDONLY) = -1 ENOENT (No such file or directory)
stat64(/usr/local/lib/mmx, 0xb250) = -1 ENOENT (No such file or
directory) open(/usr/local/lib/libsasl2.so.2, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`/\0\000...,
512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=371313, ...}) = 0
old_mmap(NULL, 72104, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40013000
old_mmap(0x40024000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED,
3, 0x1) = 0x40024000 close(3)= 0
open(/usr/local/lib/libssl.so.2, O_RDONLY) = -1 ENOENT (No such file or
directory) open(/etc/ld.so.cache, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=31245, ...}) = 0
old_mmap(NULL, 31245, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40025000
close(3)= 0
open(/lib/libssl.so.2, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360\220...,
512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=224721, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x4002d000 old_mmap(NULL, 195076, PROT_READ|PROT_EXEC, MAP_PRIVATE,
3, 0) = 0x4002e000 old_mmap(0x4005b000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED, 3, 0x2d000) = 0x4005b000 close(3)
= 0
open(/usr/local/lib/libcrypto.so.2, O_RDONLY) = -1 ENOENT (No such file
or directory) open(/lib/libcrypto.so.2, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p9\2\000...,
512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=995665, ...}) = 0
old_mmap(NULL, 875620, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
0x4005e000 old_mmap(0x40125000, 49152, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED, 3, 0xc7000) = 0x40125000 old_mmap(0x40131000,
11364, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0)
= 0x40131000 close(3)= 0
open(/usr/local/lib/libresolv.so.2, O_RDONLY) = -1 ENOENT (No such file
or directory) open(/lib/libresolv.so.2, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\230\'\0...,
512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=69443, ...}) = 0
old_mmap(NULL, 69444, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40134000
old_mmap(0x40142000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED,
3, 0xe000) = 0x40142000 old_mmap(0x40143000, 8004, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40143000 close(3)
= 0
open(/usr/local/lib/libdb-4.0.so, O_RDONLY) = -1 ENOENT (No such file
or directory) open(/lib/libdb-4.0.so, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\27..., 512)
= 512 fstat64(3, {st_mode=S_IFREG|0555, st_size=760175, ...}) = 0
old_mmap(NULL, 686348, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
0x40145000 old_mmap(0x401eb000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED, 3, 0xa5000) = 0x401eb000 close(3)
= 0
open(/usr/local/lib/libc.so.6, O_RDONLY) = -1 ENOENT (No such file or
directory) open(/lib/libc.so.6, O_RDONLY)= 3
read(3,
Re: migrating from sendmail/shadow to sasl on new box
blast wrote: As far as I've been able to find, the only way to migrate use info from an old box running sendmail authenticating against shadow to a new system running postfix authenticating against sasldb2 is to use the auto_transition feature. Is this true, or is there perhaps a manual_transition feature that I might employ? If you have their clear-text password, or are willing to reset the passwords, it would be trivial to write a script to do it. Otherwise, you do not have sufficient information (shadow only stores a one-way hash of the password, using crypt or md5 depending on your OS and configuration) to regenerate the clear-text password that is required. -- John A. Tamplin Unix System Administrator Emory University, School of Public Health +1 404/727-9931
Re: Compiling Cyrus IMAPD on AMD Opteron
On Fri, 13 Jun 2003, [EMAIL PROTECTED] wrote: Compiling with the -fPIC fixes the problem. I had to do this for the following: imclient.c imparse.c xmalloc.c imapurl.c iptostring.c assert.c util.c libisieve.c prot.c Why does -fPIC fix this problem? Because of either: 1. AMD64 is unforgiving of non-PIC code mixed with PIC code where it shouldn't be (libraries) 2. Compiler bugs. Anything that goes inside a lib should be -fPIC. Really. I have done this in the Debian build (which runs OK in S/390, IA64, Alpha, MIPS, MIPS-EL...) ages ago. I don't know if these changes are in CMU Cyrus. I don't think the Cyrus build uses --shared, but I didn't check. ../../lib/libcyrus.a(imclient.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC Yep. Arch dislikes mixing PIC and non-PIC code inside a relocatable object. -- 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: Trying to deliver to sub folder
Michael, Thanks. Now to try and get Exim to deliver to subfolders using lmtp. :-) Anybody get that working corectly? Michael Bacon wrote: If you're using deliver, the user that needs post access to the mailbox is not cyrus, but anonymous. So sam user.boutilpj anonymous p (or anyone p) is what you need. Should work after you do that. Michael --On Friday, June 13, 2003 9:35 AM -0300 Patrick Boutilier [EMAIL PROTECTED] wrote: Cyrus 2.1.13 According to the man page for deliver the cat ... command below should put the message in the Junk folder however it goes directly into the INBOX. Clip from 'man deliver: -m mailbox Deliver to mailbox. If any userids are specified, attempts todeliver to user.userid.mailbox for each userid. If the ACL onany such mailbox does not grant the sender the p right or if-m is not specified, then delivers to the INBOX for the userid,regardless of the ACL on the INBOX. If no userids are specified, attempts to deliver to mailbox. Ifthe ACL on mailbox does not grant the sender the p right, thedelivery fails. cyradm: localhost lam user.boutilpj boutilpj lrswipcda cyrus lrswpa localhost lam user.boutilpj.Junk boutilpj lrswipcda cyrus lrswpa Any ideas? snip
Re: migrating from sendmail/shadow to sasl on new box
John Alton Tamplin wrote: blast wrote: As far as I've been able to find, the only way to migrate use info from an old box running sendmail authenticating against shadow to a new system running postfix authenticating against sasldb2 is to use the auto_transition feature. Is this true, or is there perhaps a manual_transition feature that I might employ? If you have their clear-text password, or are willing to reset the passwords, it would be trivial to write a script to do it. Otherwise, you do not have sufficient information (shadow only stores a one-way hash of the password, using crypt or md5 depending on your OS and configuration) to regenerate the clear-text password that is required. That is what I assumed initially as well. But after looking into things just to say I did, it occurred to me that since sasl can store passwords as md5, I might be able to cut-and-paste my md5 shadow hashes into sasldb2 somehow. Might you be able to explain why this won't work (not that I've been able to get it to work of course ;)? basem
Re: migrating from sendmail/shadow to sasl on new box
On Fri, 13 Jun 2003, John Alton Tamplin wrote: As far as I've been able to find, the only way to migrate use info from an old box running sendmail authenticating against shadow to a new system running postfix authenticating against sasldb2 is to use the auto_transition feature. Is this true, or is there perhaps a manual_transition feature that I might employ? If you have their clear-text password, or are willing to reset the passwords, it would be trivial to write a script to do it. Otherwise, you do not have sufficient information (shadow only stores a one-way hash of the password, using crypt or md5 depending on your OS and configuration) to regenerate the clear-text password that is required. To make matters worse, there is no good way to implement auto_transition in a database-independent way currently, so it isn't going to do what you want anyway. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Compiling Cyrus IMAPD on AMD Opteron
On Fri, 13 Jun 2003, Henrique de Moraes Holschuh wrote: On Fri, 13 Jun 2003, [EMAIL PROTECTED] wrote: Compiling with the -fPIC fixes the problem. I had to do this for the following: imclient.c imparse.c xmalloc.c imapurl.c iptostring.c assert.c util.c libisieve.c prot.c Why does -fPIC fix this problem? Because of either: 1. AMD64 is unforgiving of non-PIC code mixed with PIC code where it shouldn't be (libraries) 2. Compiler bugs. Anything that goes inside a lib should be -fPIC. Really. I have done this in the Debian build (which runs OK in S/390, IA64, Alpha, MIPS, MIPS-EL...) ages ago. I don't know if these changes are in CMU Cyrus. This in true only for shared libs unless you are trying to link an archive into a shared lib (which can be the case with perl modules). Position independent code adds some overhead. I think CMU folks like to build things static as much as possible for performance reasons. I don't think the Cyrus build uses --shared, but I didn't check. ../../lib/libcyrus.a(imclient.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC Yep. Arch dislikes mixing PIC and non-PIC code inside a relocatable object. Correct. On Solaris, I build lib/ and perl/sieve/lib with -fPIC just to build cyrus-imap perl stuff. -- Igor
Re: Compiling Cyrus IMAPD on AMD Opteron
On Fri, 13 Jun 2003, Igor Brezac wrote: Anything that goes inside a lib should be -fPIC. Really. I have done this in the Debian build (which runs OK in S/390, IA64, Alpha, MIPS, MIPS-EL...) ages ago. I don't know if these changes are in CMU Cyrus. This in true only for shared libs unless you are trying to link an archive into a shared lib (which can be the case with perl modules). Position independent code adds some overhead. I think CMU folks like to build things static as much as possible for performance reasons. Actually, we prefer shared libraries for maintainability reasons. However, the number of shared libraries our IMAPd links (once SASL is all done loading etc) is something up near 25-30. Since each of these shared libraries costs you a per-process jump table, this gets expensive in terms of memory usage really fast. So, we try to link staticly in this case. Yep. Arch dislikes mixing PIC and non-PIC code inside a relocatable object. Correct. On Solaris, I build lib/ and perl/sieve/lib with -fPIC just to build cyrus-imap perl stuff. H. We've never had to do this on solaris. I wonder if we could write a configure test to determine if this is necessary on a given platform. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
RE: seen file corruption
On Fri, 13 Jun 2003, Richard Houston wrote: It would be very cool to have the actual messages stored in database as well. The dbmail project is doing this in Mysql or Postgresql. Imagine the maturity of Cyrus with all the benefits of storage and backup in a database. Would be cool. Except that the benefits of Cyrus are lost, for the most part, if you change the mail store. The parser APIs that lie on top of the mail store are almost trivial to implement compared to the data storage (and retrieval) mechanisms themselves. Cyrus gets its high performance from clever indexing and caching of information in each mailbox. If you gut all this code and replace it with a database, you've removed the primary benefit! Additionally, you've probably lost some performance because the speed of Cyrus's store (optimized for IMAP) is going to be hard to beat with a generic database. Not impossible, but its really not something we're interested in doing for the foreseeable future. As it is, I have trouble understanding why anyone would want to make a cyrusdb out of a relational database. Cyrusdb provides simple key/value pairs, where a relational database is providing a lot more, and has more overhead. If you want to be able to access this data (internal to cyrus) from another application, you're asking for serious trouble. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
RE: seen file corruption
Hmmm I see your point. Maybe not such a good idea. Thanks for setting me straight. Rich On Fri, 2003-06-13 at 10:19, Rob Siemborski wrote: On Fri, 13 Jun 2003, Richard Houston wrote: It would be very cool to have the actual messages stored in database as well. The dbmail project is doing this in Mysql or Postgresql. Imagine the maturity of Cyrus with all the benefits of storage and backup in a database. Would be cool. Except that the benefits of Cyrus are lost, for the most part, if you change the mail store. The parser APIs that lie on top of the mail store are almost trivial to implement compared to the data storage (and retrieval) mechanisms themselves. Cyrus gets its high performance from clever indexing and caching of information in each mailbox. If you gut all this code and replace it with a database, you've removed the primary benefit! Additionally, you've probably lost some performance because the speed of Cyrus's store (optimized for IMAP) is going to be hard to beat with a generic database. Not impossible, but its really not something we're interested in doing for the foreseeable future. As it is, I have trouble understanding why anyone would want to make a cyrusdb out of a relational database. Cyrusdb provides simple key/value pairs, where a relational database is providing a lot more, and has more overhead. If you want to be able to access this data (internal to cyrus) from another application, you're asking for serious trouble. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper On Fri, 2003-06-13 at 10:19, Rob Siemborski wrote: On Fri, 13 Jun 2003, Richard Houston wrote: It would be very cool to have the actual messages stored in database as well. The dbmail project is doing this in Mysql or Postgresql. Imagine the maturity of Cyrus with all the benefits of storage and backup in a database. Would be cool. Except that the benefits of Cyrus are lost, for the most part, if you change the mail store. The parser APIs that lie on top of the mail store are almost trivial to implement compared to the data storage (and retrieval) mechanisms themselves. Cyrus gets its high performance from clever indexing and caching of information in each mailbox. If you gut all this code and replace it with a database, you've removed the primary benefit! Additionally, you've probably lost some performance because the speed of Cyrus's store (optimized for IMAP) is going to be hard to beat with a generic database. Not impossible, but its really not something we're interested in doing for the foreseeable future. As it is, I have trouble understanding why anyone would want to make a cyrusdb out of a relational database. Cyrusdb provides simple key/value pairs, where a relational database is providing a lot more, and has more overhead. If you want to be able to access this data (internal to cyrus) from another application, you're asking for serious trouble. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Compiling Cyrus IMAPD on AMD Opteron
Date: Fri, 13 Jun 2003 11:11:41 -0400 (EDT) From: Rob Siemborski [EMAIL PROTECTED] Yep. Arch dislikes mixing PIC and non-PIC code inside a relocatable object. Correct. On Solaris, I build lib/ and perl/sieve/lib with -fPIC just to build cyrus-imap perl stuff. H. We've never had to do this on solaris. Yeah, Solaris is one of the platforms that is tolerant of mixing non -fPIC into shared libraries. It poses a large memory hit (shared libraries with non -fPIC code aren't shared between processes). The major problem with trying to add -fPIC to the distribution is that isn't how it works on all compilers and all OS's. Thus the pain that is libtool. I've thought about making all of Cyrus build with libtool, and then I read some of the bug reports we get because of libsasl's use of libtool and start thinking better of it. I wonder if we could write a configure test to determine if this is necessary on a given platform. To do it in all generality requires duplicating libtool. Larry
Re: Compiling Cyrus IMAPD on AMD Opteron
On Fri, 13 Jun 2003, Rob Siemborski wrote: On Fri, 13 Jun 2003, Igor Brezac wrote: Anything that goes inside a lib should be -fPIC. Really. I have done this in the Debian build (which runs OK in S/390, IA64, Alpha, MIPS, MIPS-EL...) ages ago. I don't know if these changes are in CMU Cyrus. This in true only for shared libs unless you are trying to link an archive into a shared lib (which can be the case with perl modules). Position independent code adds some overhead. I think CMU folks like to build things static as much as possible for performance reasons. Actually, we prefer shared libraries for maintainability reasons. I stand corrected. ;) All this trouble of building static libsasl led me to think this way. However, the number of shared libraries our IMAPd links (once SASL is all done loading etc) is something up near 25-30. Since each of these shared libraries costs you a per-process jump table, this gets expensive in terms of memory usage really fast. So, we try to link staticly in this case. Yep. Arch dislikes mixing PIC and non-PIC code inside a relocatable object. Correct. On Solaris, I build lib/ and perl/sieve/lib with -fPIC just to build cyrus-imap perl stuff. H. We've never had to do this on solaris. I wonder if we could write a configure test to determine if this is necessary on a given platform. It depends on how perl is built and possibly type of compiler/linker flags used. Also, CFLAGS=-fPIC breaks 'make depend'. I am not sure what is the best way to deal with this, fix makedepend?. -- Igor
Re: Compiling Cyrus IMAPD on AMD Opteron
On Fri, 13 Jun 2003, Lawrence Greenfield wrote: Date: Fri, 13 Jun 2003 11:11:41 -0400 (EDT) From: Rob Siemborski [EMAIL PROTECTED] Yep. Arch dislikes mixing PIC and non-PIC code inside a relocatable object. Correct. On Solaris, I build lib/ and perl/sieve/lib with -fPIC just to build cyrus-imap perl stuff. H. We've never had to do this on solaris. Yeah, Solaris is one of the platforms that is tolerant of mixing non -fPIC into shared libraries. It poses a large memory hit (shared libraries with non -fPIC code aren't shared between processes). -zcombreloc linker flag make my installation require -fPIC. The major problem with trying to add -fPIC to the distribution is that isn't how it works on all compilers and all OS's. Thus the pain that is libtool. I've thought about making all of Cyrus build with libtool, and then I read some of the bug reports we get because of libsasl's use of libtool and start thinking better of it. I wonder if we could write a configure test to determine if this is necessary on a given platform. To do it in all generality requires duplicating libtool. Larry -- Igor
Re: Compiling Cyrus IMAPD on AMD Opteron
On 13 Jun 2003, Rob Siemborski said: On Fri, 13 Jun 2003, Igor Brezac wrote: Anything that goes inside a lib should be -fPIC. Really. I have done this in the Debian build (which runs OK in S/390, IA64, Alpha, MIPS, MIPS-EL...) ages ago. I don't know if these changes are in CMU Cyrus. This in true only for shared libs unless you are trying to link an archive into a shared lib (which can be the case with perl modules). Position independent code adds some overhead. I think CMU folks like to build things static as much as possible for performance reasons. Actually, we prefer shared libraries for maintainability reasons. However, the number of shared libraries our IMAPd links (once SASL is all done loading etc) is something up near 25-30. Since each of these shared libraries costs you a per-process jump table, this gets expensive in terms of memory usage really fast. So, we try to link staticly in this case. Yep. Arch dislikes mixing PIC and non-PIC code inside a relocatable object. Correct. On Solaris, I build lib/ and perl/sieve/lib with -fPIC just to build cyrus-imap perl stuff. H. We've never had to do this on solaris. I wonder if we could write a configure test to determine if this is necessary on a given platform. Isn't that what libtool is for? For the Perl stuff explicitly: [EMAIL PROTECTED]:46$ perl -V:cccdlflags cccdlflags='-fpic'; [EMAIL PROTECTED]:47$ -- Stephen L. Ulmer [EMAIL PROTECTED] Senior Systems Programmer http://www.ulmer.org/ Northeast Regional Data Center VOX: (352) 392-2061 University of Florida FAX: (352) 392-9440
Sendmail SASL Auth problem
Hi, I have a problem sending mail using sendmail SASL Authentication. I'm using saslauthd -a pam for authentication. pam module is pam-pgsql Users can login to Cyrus IMAPD and receive their mail using MS Outlook Express but they can't send mail. The accounts setup to authenticate to mail server using the same settings (username and password) as for incoming mail (Cyrus IMAPD). When I hit reseive button Authentication screen pops up, I enter valid user name and password and this record appers in the maillog: Jun 13 10:26:40 mail sm-mta[4930]: h5DGQd4D004930: win2k.intellinetinc.com [139.142.54.35] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA And if I run saslauthd -a pam -d saslauthd[4982] :main: num_procs : 5 saslauthd[4982] :main: mech_option: NULL saslauthd[4982] :main: run_path : /var/state/saslauthd saslauthd[4982] :main: auth_mech : pam saslauthd[4982] :ipc_init: using accept lock file: /var/state/saslauthd/mux.accept saslauthd[4982] :detach_tty : master pid is: 0 saslauthd[4982] :ipc_init: listening on socket: /var/state/saslauthd/mux saslauthd[4982] :main: using process model saslauthd[4982] :have_baby : forked child: 4983 saslauthd[4983] :get_accept_lock : acquired accept lock saslauthd[4982] :have_baby : forked child: 4984 saslauthd[4982] :have_baby : forked child: 4985 saslauthd[4982] :have_baby : forked child: 4986 saslauthd[4984] :get_accept_lock : acquired accept lock saslauthd[4983] :rel_accept_lock : released accept lock saslauthd[4983] :do_auth : auth failure: [user=dmitry] [service=smtp] [realm=] [mech=pam] saslauthd[4985] :get_accept_lock : acquired accept lock saslauthd[4984] :rel_accept_lock : released accept lock NOTICE: Adding missing FROM-clause entry for table domains NOTICE: Adding missing FROM-clause entry for table domains saslauthd[4984] :do_auth : auth success: [user=dmitry] [service=imap] [realm=] [mech=pam] saslauthd[4984] :do_request : response: OK saslauthd[4986] :get_accept_lock : acquired accept lock saslauthd[4985] :rel_accept_lock : released accept lock In my sendmail.mc I have: define(`confAUTH_MECHANISMS',`PLAIN LOGIN DIGEST-MD5 CRAM-MD5')dnl TRUST_AUTH_MECH(`PLAIN LOGIN DIGEST-MD5 CRAM-MD5')dnl Do I have to add something else to my sendmail.mc? Please help ASAP Thank you Dmitry
Re: Trying to deliver to sub folder
After more searching I just realized that the following will also work without the need for anonymous to have p rights. /usr/cyrus/bin/deliver -m Junk -a boutilpj boutilpj Michael Bacon wrote: If you're using deliver, the user that needs post access to the mailbox is not cyrus, but anonymous. So sam user.boutilpj anonymous p (or anyone p) is what you need. Should work after you do that. Michael --On Friday, June 13, 2003 9:35 AM -0300 Patrick Boutilier [EMAIL PROTECTED] wrote: Cyrus 2.1.13 According to the man page for deliver the cat ... command below should put the message in the Junk folder however it goes directly into the INBOX. Clip from 'man deliver: -m mailbox Deliver to mailbox. If any userids are specified, attempts todeliver to user.userid.mailbox for each userid. If the ACL onany such mailbox does not grant the sender the p right or if-m is not specified, then delivers to the INBOX for the userid,regardless of the ACL on the INBOX. If no userids are specified, attempts to deliver to mailbox. Ifthe ACL on mailbox does not grant the sender the p right, thedelivery fails. cyradm: localhost lam user.boutilpj boutilpj lrswipcda cyrus lrswpa localhost lam user.boutilpj.Junk boutilpj lrswipcda cyrus lrswpa Any ideas? cat mail.txt|strace -fF /usr/cyrus/bin/deliver -m Junk boutilpj
Re: Sendmail SASL Auth problem
Sorry guys, my fault :-) I forgot to put smtpauthrequiredpam_pgsql.sotry_first_pass smtpaccount requiredpam_pgsql.sotry_first_pass in my pam.conf file Dmitry
Cyrus Backup Strategy
My last thing to do prior to converting to production is a backup strategy. I have been doing this with tar something like: tar -C /var/lib-czf lib-date.tar.gzimap tar -C /var/spool -czf spool-date.tar.gz imap tar -cf cyrus-date.tar This is producing a pretty big file(s): lib-date.tar.gz- 2.2M spool-date.tar.gz - 11.0M and ultimately cyrus-date.tar - 13.5M and I was thinking maybe there is a better way that someone else has come up with. Anyone doing backups a different way?
Re: Cyrus Backup Strategy
pnelson wrote: My last thing to do prior to converting to production is a backup strategy. I have been doing this with tar something like: tar -C /var/lib-czf lib-date.tar.gzimap tar -C /var/spool -czf spool-date.tar.gz imap tar -cf cyrus-date.tar This is producing a pretty big file(s): lib-date.tar.gz- 2.2M spool-date.tar.gz - 11.0M and ultimately cyrus-date.tar - 13.5M and I was thinking maybe there is a better way that someone else has come up with. Anyone doing backups a different way? Are you then dumping these files to tape? Otherwise, just having another copy on disk doesn't protect against many potential causes of data loss. We just backup the mail files normally with Veritas Netbackup (be sure to disable true image restore with the millions of files), with the only custom bit being to dump a copy of the mailbox list to a text file before the backups run (this is a precaution since we are backing up structured database files without synchronization with the program writing them, so there is no guarantee the resulting backup is useful). Our full backup for all Cyrus files is 98G and 4.2M files, taking 5-8 hours depending on other data hitting the tape drives. Daily incremental backups average 1-3G and 10-30k files. -- John A. Tamplin Unix System Administrator Emory University, School of Public Health +1 404/727-9931
Re: Cyrus Backup Strategy
On Fri, 2003-06-13 at 11:29, John Alton Tamplin wrote: pnelson wrote: My last thing to do prior to converting to production is a backup strategy. I have been doing this with tar something like: tar -C /var/lib-czf lib-date.tar.gzimap tar -C /var/spool -czf spool-date.tar.gz imap tar -cf cyrus-date.tar This is producing a pretty big file(s): lib-date.tar.gz- 2.2M spool-date.tar.gz - 11.0M and ultimately cyrus-date.tar - 13.5M and I was thinking maybe there is a better way that someone else has come up with. Anyone doing backups a different way? Are you then dumping these files to tape? Otherwise, just having another copy on disk doesn't protect against many potential causes of data loss. Yes dumping to removable medium. We just backup the mail files normally with Veritas Netbackup (be sure to disable true image restore with the millions of files), with the only custom bit being to dump a copy of the mailbox list to a text file before the backups run (this is a precaution since we are backing up structured database files without synchronization with the program writing them, so there is no guarantee the resulting backup is useful). Our full backup for all Cyrus files is 98G and 4.2M files, taking 5-8 hours depending on other data hitting the tape drives. Daily incremental backups average 1-3G and 10-30k files. So a cyrus backup needs to contain: /var/spool/imap /var/lib/imap/mailboxes.db to be useful as a backup, right? With these to things I can recover... I'm making sure I understand this completely. How do you dump mailboxes to/from text? What is the restore process? Thanks
Re: Cyrus Backup Strategy
On Fri, 13 Jun 2003, pnelson wrote: On Fri, 2003-06-13 at 11:29, John Alton Tamplin wrote: pnelson wrote: My last thing to do prior to converting to production is a backup strategy. I have been doing this with tar something like: tar -C /var/lib-czf lib-date.tar.gzimap tar -C /var/spool -czf spool-date.tar.gz imap tar -cf cyrus-date.tar This is producing a pretty big file(s): lib-date.tar.gz- 2.2M spool-date.tar.gz - 11.0M and ultimately cyrus-date.tar - 13.5M and I was thinking maybe there is a better way that someone else has come up with. Anyone doing backups a different way? Are you then dumping these files to tape? Otherwise, just having another copy on disk doesn't protect against many potential causes of data loss. Yes dumping to removable medium. We just backup the mail files normally with Veritas Netbackup (be sure to disable true image restore with the millions of files), with the only custom bit being to dump a copy of the mailbox list to a text file before the backups run (this is a precaution since we are backing up structured database files without synchronization with the program writing them, so there is no guarantee the resulting backup is useful). Our full backup for all Cyrus files is 98G and 4.2M files, taking 5-8 hours depending on other data hitting the tape drives. Daily incremental backups average 1-3G and 10-30k files. So a cyrus backup needs to contain: /var/spool/imap /var/lib/imap/mailboxes.db to be useful as a backup, right? With these to things I can recover... I'm making sure I understand this completely. I am not sure what your directory structure looks like, but you need to make sure to backup sieve and quota directories. Your procedure may require hand recovery after restore before the mail store is usable. I recommend using filesystem snapshot (i assume you do not stop the mail server during backup) before performing backup. This will make your backup 'sane.' How do you dump mailboxes to/from text? What is the restore process? Thanks -- Igor
Re: Cyrus Backup Strategy
On Fri, 2003-06-13 at 12:11, Igor Brezac wrote: On Fri, 13 Jun 2003, pnelson wrote: On Fri, 2003-06-13 at 11:29, John Alton Tamplin wrote: pnelson wrote: My last thing to do prior to converting to production is a backup strategy. I have been doing this with tar something like: tar -C /var/lib-czf lib-date.tar.gzimap tar -C /var/spool -czf spool-date.tar.gz imap tar -cf cyrus-date.tar This is producing a pretty big file(s): lib-date.tar.gz- 2.2M spool-date.tar.gz - 11.0M and ultimately cyrus-date.tar - 13.5M and I was thinking maybe there is a better way that someone else has come up with. Anyone doing backups a different way? Are you then dumping these files to tape? Otherwise, just having another copy on disk doesn't protect against many potential causes of data loss. Yes dumping to removable medium. We just backup the mail files normally with Veritas Netbackup (be sure to disable true image restore with the millions of files), with the only custom bit being to dump a copy of the mailbox list to a text file before the backups run (this is a precaution since we are backing up structured database files without synchronization with the program writing them, so there is no guarantee the resulting backup is useful). Our full backup for all Cyrus files is 98G and 4.2M files, taking 5-8 hours depending on other data hitting the tape drives. Daily incremental backups average 1-3G and 10-30k files. So a cyrus backup needs to contain: /var/spool/imap /var/lib/imap/mailboxes.db to be useful as a backup, right? With these to things I can recover... I'm making sure I understand this completely. I am not sure what your directory structure looks like, but you need to make sure to backup sieve and quota directories. Your procedure may require hand recovery after restore before the mail store is usable. I recommend using filesystem snapshot (i assume you do not stop the mail server during backup) before performing backup. This will make your backup 'sane.' How do you dump mailboxes to/from text? What is the restore process? Good point. So the latest process would be: So a cyrus backup needs to contain: su cyrus -c ctl_mboxlist -d mailboxes-date.txt /var/spool/imap /var/lib/imap/quota /var/lib/imap/user /var/lib/imap/sieve Not sure how the filesystem snapshot works? No I do not want to stop the server.
Re: Cyrus Backup Strategy
On Fri, 13 Jun 2003, pnelson wrote: On Fri, 2003-06-13 at 12:11, Igor Brezac wrote: On Fri, 13 Jun 2003, pnelson wrote: On Fri, 2003-06-13 at 11:29, John Alton Tamplin wrote: pnelson wrote: My last thing to do prior to converting to production is a backup strategy. I have been doing this with tar something like: tar -C /var/lib-czf lib-date.tar.gzimap tar -C /var/spool -czf spool-date.tar.gz imap tar -cf cyrus-date.tar This is producing a pretty big file(s): lib-date.tar.gz- 2.2M spool-date.tar.gz - 11.0M and ultimately cyrus-date.tar - 13.5M and I was thinking maybe there is a better way that someone else has come up with. Anyone doing backups a different way? Are you then dumping these files to tape? Otherwise, just having another copy on disk doesn't protect against many potential causes of data loss. Yes dumping to removable medium. We just backup the mail files normally with Veritas Netbackup (be sure to disable true image restore with the millions of files), with the only custom bit being to dump a copy of the mailbox list to a text file before the backups run (this is a precaution since we are backing up structured database files without synchronization with the program writing them, so there is no guarantee the resulting backup is useful). Our full backup for all Cyrus files is 98G and 4.2M files, taking 5-8 hours depending on other data hitting the tape drives. Daily incremental backups average 1-3G and 10-30k files. So a cyrus backup needs to contain: /var/spool/imap /var/lib/imap/mailboxes.db to be useful as a backup, right? With these to things I can recover... I'm making sure I understand this completely. I am not sure what your directory structure looks like, but you need to make sure to backup sieve and quota directories. Your procedure may require hand recovery after restore before the mail store is usable. I recommend using filesystem snapshot (i assume you do not stop the mail server during backup) before performing backup. This will make your backup 'sane.' How do you dump mailboxes to/from text? What is the restore process? Good point. So the latest process would be: So a cyrus backup needs to contain: su cyrus -c ctl_mboxlist -d mailboxes-date.txt This is not neccassary, but not a bad idea. /var/spool/imap /var/lib/imap/quota /var/lib/imap/user /var/lib/imap/sieve Not sure how the filesystem snapshot works? On solaris do 'man fssnap'. veritas filesystem supports the snapshot feature as does Linux (at least the newer versions), I am not sure which filesystem. Basically, this feature provides a temporary stable and read-only view (snapshot) of a filesystem. The writes occur on a separate filesystem or device. -- Igor
Cant get sieve working
Have Cyrus-imap working great and can...
sieveshell -u pnelson -a pnelson localhost
then:
put test.siqeve
activate test.sieve
list
test.sieve - active script
The test.sieve is simply:
require fileinto;
if header :contains Subject test {
fileinto INBOX.test;
}
INBOX.test does exist. But when I send a manual message using telnet
with the correct subject line it doesn't appear to use the script.
The mail arrives in my inbox not my INBOX.test folder. Any ideas on how
to get this working or configured correctly?
problems using mailutil to move messages from Groupwise to Cyrus
Original Message
We've been happily running a cyrus mail server for several
years. Lately we've been attempting to migrate our Groupwise
users from the dark side over to our IMAP server. This seemed
straightforward enough. We're using imaputil to move the
Groupwise mailboxes over, but have run into some issues
(probably caused by the Groupwise IMAP server).
Cyrus 2.1.10 IMAP server
When we move the mailboxes with
mailutil transfer -debug {adngate.adn.uwrf.edu}
{biff.servers.uwrf.edu}INBOX.GW.
most of the mail messages move over fine, but some generate a
whole slug of errrors, and are not moved. As an example:
+ go ahead
IMAP protocol error: STORE 1 Command, State, or Parameter
STORE 1 Command, State, or Parameter
() 13-Jun-2003 08:48:41 -0500 {1851}
+ go ahead
IMAP protocol error: STORE 1 Command, State, or Parameter
STORE 1 Command, State, or Parameter
(\Seen) 13-Jun-2003 08:54:18 -0500 {2521}
+ go ahead
(\Seen) 13-Jun-2003 08:54:19 -0500 {2555}
+ go ahead
(\Seen) 13-Jun-2003 09:14:42 -0500 {2852}
+ go ahead
(\Seen) 13-Jun-2003 09:14:45 -0500 {2886}
+ go ahead
IMAP protocol error: STORE 1 Command, State, or Parameter
STORE 1 Command, State, or Parameter
() 13-Jun-2003 09:21:25 -0500 {5489}
+ go ahead
I'm not quite sure what I'm suppsed to divine from this - I
don't see anyting that jumps out at me here. What are the
numbers in the curly braces???
--
Steve Hanson
UW River Falls ITS
715-425-4357
Re: Cant get sieve working
On Fri, 2003-06-13 at 15:11, Carl P. Corliss wrote:
What version of Cyrus are you using?
On Friday 13 June 2003 03:55 pm, pnelson wrote:
Have Cyrus-imap working great and can...
sieveshell -u pnelson -a pnelson localhost
then:
put test.siqeve
activate test.sieve
list
test.sieve - active script
The test.sieve is simply:
require fileinto;
if header :contains Subject test {
fileinto INBOX.test;
}
INBOX.test does exist. But when I send a manual message using telnet
with the correct subject line it doesn't appear to use the script.
The mail arrives in my inbox not my INBOX.test folder. Any ideas on how
to get this working or configured correctly?
cyrus-imap v2.1.13
Re: Cant get sieve working
On Fri, 2003-06-13 at 14:55, pnelson wrote:
require fileinto;
if header :contains Subject test {
fileinto INBOX.test;
^ You probably want a '' here.
Wil
--
Wil Cooley [EMAIL PROTECTED]
Naked Ape Consultinghttp://nakedape.cc
* * * * Linux, UNIX, Networking and Security Solutions * * * *
* Tired of spam and viruses in your e-mail? Get the *
* Naked Ape Mail Defender! http://nakedape.cc/r/maildefender *
signature.asc
Description: This is a digitally signed message part
Re: Cant get sieve working
On Fri, 2003-06-13 at 15:38, Wil Cooley wrote:
On Fri, 2003-06-13 at 14:55, pnelson wrote:
require fileinto;
if header :contains Subject test {
fileinto INBOX.test;
^ You probably want a '' here.
Oops email typo... the script has it in there.
I am using unixhierarchysep so that names can handle the dot, maybe that
might be a problem? On my mailbox I don't have dots but others do.
Re: Cant get sieve working
pnelson wrote:
On Fri, 2003-06-13 at 15:38, Wil Cooley wrote:
On Fri, 2003-06-13 at 14:55, pnelson wrote:
require fileinto;
if header :contains Subject test {
fileinto INBOX.test;
^ You probably want a '' here.
Oops email typo... the script has it in there.
I am using unixhierarchysep so that names can handle the dot, maybe that
might be a problem? On my mailbox I don't have dots but others do.
If you're using unixhiersep, then you probably want INBOX/test
--
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: Cant get sieve working [SOLVED]
On Fri, 2003-06-13 at 16:03, Ken Murchison wrote:
pnelson wrote:
On Fri, 2003-06-13 at 15:38, Wil Cooley wrote:
On Fri, 2003-06-13 at 14:55, pnelson wrote:
require fileinto;
if header :contains Subject test {
fileinto INBOX.test;
^ You probably want a '' here.
Oops email typo... the script has it in there.
I am using unixhierarchysep so that names can handle the dot, maybe that
might be a problem? On my mailbox I don't have dots but others do.
If you're using unixhiersep, then you probably want INBOX/test
I had thought about unixhierarchysep, but didn't know how to get around
it. Thanks Ken... That did the trick and now it's working like a
charm.
Re: Linking imapd with db-4.1.25
QUESTION: Does the Berkeley 4.1.25 database not like the version of POSIX threads in Linux Mandrake 9.1, but is happy with the NGPT in Redhat 9.0? I ask because when I built Cyrus-IMAP 2.1.12 against the db4.1 libs on Mandrake 9.1, I ran into the problem described below: / On a Mandrkake 9.1 installation on a Athlon system, I configured Berkely db-4.1.25NC like so, all on one line: env LDFLAGS=-lpthread ../dist/configure --enable-posixmutexes --enable-cxx --enable-test --enable-rpc --enable-tcl -with-tcl=/usr/lib --prefix=/usr I noticed this in the output of configure, though: ./build_unix/config.log:configure:17731: result: POSIX/pthreads/private And subsequently, my build of cyrus-IMAP 2.1.13 linked against this db-4.1.25, yielded these messages in /var/log/syslog when I started: Jun 10 17:25:49 ns1 ctl_cyrusdb[10682]: recovering cyrus databases Jun 10 17:25:49 ns1 ctl_cyrusdb[10682]: DBERROR db4: Berkeley DB library configured to support only DB_PRIVATE environments Jun 10 17:25:49 ns1 ctl_cyrusdb[10682]: DBERROR: dbenv-open '/var/lib/imap/db' failed: Invalid argument Looking through the changelog for Berkeley DB 4.1.24, I found: 2. Support configuration of POSIX pthread mutexes on systems where the pthread mutexes do not support inter-process locks. [#4942] And then in the Berkeley DB Reference Guide, there is: DB_PRIVATE Specify that the environment will only be accessed by a single process (although that process may be multithreaded). This flag has two effects on the Berkeley DB environment. First, all underlying data structures are allocated from per-process memory instead of from shared memory that is potentially accessible to more than a single process. Second, mutexes are only configured to work between threads. This flag should not be specified if more than a single process is accessing the environment because it is likely to cause database corruption and unpredictable behavior. For example, if both a server application and the Berkeley DB utility db_stat are expected to access the environment, the DB_PRIVATE flag should not be specified. -- Scott Langley [EMAIL PROTECTED] Systems Administrator Rural Network Services
Re: Sieve help
On Fri, 2003-06-06 at 10:29, Ken Murchison wrote: Patrick Nelson wrote: Running Cyrus-imap 2.1.13 on RH9 and alls well. Moved the whole company off of exchange a week ago and so far not even a hickup. So, now I want to explore sieve, but I'm not sure where to begin. Is there any good docs you all would recommend. Or maybe highlight to me your course of knowledge on this? For writing scripts or configuring Cyrus to handle them? For authoring, this might be the best place to start. http://www.cyrusoft.com/sieve/ For setup, the Cyrus docs _should_ be enough to get you started. Have sieve working but the cyrusoft sites sieve docs are kind of lacking. Anyone else know of a good ole' howto on the syntax of sieve?
Re: Sieve help
pnelson wrote: On Fri, 2003-06-06 at 10:29, Ken Murchison wrote: Patrick Nelson wrote: Running Cyrus-imap 2.1.13 on RH9 and alls well. Moved the whole company off of exchange a week ago and so far not even a hickup. So, now I want to explore sieve, but I'm not sure where to begin. Is there any good docs you all would recommend. Or maybe highlight to me your course of knowledge on this? For writing scripts or configuring Cyrus to handle them? For authoring, this might be the best place to start. http://www.cyrusoft.com/sieve/ For setup, the Cyrus docs _should_ be enough to get you started. Have sieve working but the cyrusoft sites sieve docs are kind of lacking. Anyone else know of a good ole' howto on the syntax of sieve? There isn't much. The best docs are the RFCs and IDs themselves. They are all listed on the doc/specs.html page in the distro. -- 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
