[no subject]

[nick]

After upgrading to 2.1.2 I can't get PAM_MYSQL to work. My /etc/imapd.conf as usually 
says:

sasl_pwcheck_method: pam

and the rest is configured properly. However it doesn't work anymore. Do I have to do 
that via saslauthd now? If so, won't it slow down the whole thing? Log files say:

Mar 18 00:44:21 giga imapd[7841]: badlogin: localhost.localdomain[127.0.0.1] plaintext 
root SASL(-4): no mechanism available: checkpass failed 
Mar 18 00:45:31 giga imapd[7841]: unknown password verifier pam 


Nick

researching cyrus + ldap usage

[Scott Russell]

Greets.

In the next few weeks I plan to start build a new cyrus 2.1.x imap server.
Ones of the things I would like to do is use our existing corporate ldap
directory for user authentication. Because it is a corporate ldap directory
changing the scheme is out of the question for me.

I think our ldap directory is a bit different from the norm. :) For one, the
userid is a persons email address. ([EMAIL PROTECTED], for example). So a
typical auth session with the ldap server is as expected:

1) Anonymous bind, filter on [EMAIL PROTECTED] to get DN
2) Authenticated bind using DN and user supplied passwd
3) Return results of bind.

My concerns revolve around the userid being an email address. I'm not sure
that cyrus 2.1.x will deal with this well. I'm also not very sure that
postifx will deal with it during lmtp delivery into cyrus either.

My initial thoughts are to have cyrus mailboxes named by employee number and
use some mapping in postfix to get the delivery right. Here's some example
data to work with:

  Email Address: [EMAIL PROTECTED] (This is where mail is sent)
  Cyrus Mailbox: user.123456837
  Cyrus Userid: [EMAIL PROTECTED] (No mail is delivered here!)

The big questions I have about using this setup would be on the cyrus /
sieve side of things. How do I setup the permissions so that the userid
"[EMAIL PROTECTED]" only has access to the "userid.123456837" mailbox?
What kinda trouble can I expect out of sieve vacation and such when it tries
to send email?

Is anyone in a similar situation? Any hints, tips, or revelations would be
welcome. As I said, I'm into the research phase of this project and just
looking to bounce ideas around on how to handle this situation. 

Thanks for the help.

-- 
Regards,
 Scott Russell ([EMAIL PROTECTED])
 Linux Technology Center, System Admin, RHCE.
 T/L 441-9289 / External 919-543-9289
 http://bzimage.raleigh.ibm.com/webcam

Yet another signalled to death by 11

[Earl R Shannon]

Hello,

I have a problem that may rapidly plunge me into a psychotic break.
This is on Solaris 7 running cyrus imap 2.1.1.

I've got the following mailer definitions in the sendmail.cf file
to deliver mail to the cyrus imap mail store.

##
###   Cyrus Mailer specification   ###
##

#  @(#)cyrus.m4 8.4 (Carnegie Mellon) 9/2/96  #

Mcyrus, P=/local/cyrus/bin/deliver, F=lsDFMnPqA5@, S=10,
R=20/40, T=X-Unix,
U=cyrus:mail,
A=deliver -m $h -- $u

Mcyrusbb,   P=/local/cyrus/bin/deliver, F=lsDFMnP, S=10, R=20/40,
T=X-Unix,
U=cyrus:mail,
A=deliver -m $u


However, I am getting this when delivery is attempted to a mailbox
on the server. This is logged by sendmail to syslog:

Mar 19 09:42:27 uni99map.unity.ncsu.edu sendmail[3715]: QAA01267:
SYSERR(root): mailer cyrus died with signal 11
Mar 19 09:42:27 uni99map.unity.ncsu.edu sendmail[3715]: QAA01267:
to=<[EMAIL PROTECTED]>, delay=16:47:48, xdelay=00:00:00,
mailer=cyrus, stat=Deferred


In this process of setting the server up I've had the signal 11 problem
before and
was able to resolve it by initializing the db files. Is this yet another
db to
create before the server will work? Or is there something else I have to
set up.
For those who might be interested, running deliver from the commandline
works,
ie, it puts a message into a mailbox.

Regards,
Earl Shannon
-- 
Systems Programmer, Computing Services, Information Technology
NC State University.
http://www4.ncsu.edu/~ershanno

RE: Signaled to Death by 11 - Again

[OCNS Consulting]

David:

I re-compiled LDAP without SASL support and re-linked pam_ldap with the new
LDAP libraries, as suggested. Restarted both LDAP and master; LDAP access
successful;
attempted IMAP access and as before Death by 11. Here's log file excerpt (SA
B4):

   Mar 19 10:50:11 mailsrv imapd[24376]: accepted connection
   Mar 19 10:50:11 mailsrv master[24388]: about to exec /usr/cyrus/bin/imapd
   Mar 19 10:50:11 mailsrv imap[24388]: executed
   Mar 19 10:50:11 mailsrv master[24347]: process 24376 exited, signaled to
death by 11

As per Ken Murchison's suggestion, I looked for a core file and found none.
Ken where
will the core file reside, if created? What trace back would you like to
view?

Also, I found Archive note -> 1394, which skirts this issue. The note
references a
message on the OpenLDAP site ->

http://www.openldap.org/lists/openldap-software/200108/msg00594.html

The above message addresses the re-entrant issue and provides a patch but,
only refers
to the SASL version 1.5.x library. Has anyone tried this patch on the SASL
version 2.0.x
library?

I look forward to your responses.

RB

multiple cyruses via SAN

[Konrads . Smelkovs]

Here is the idea:



CyrusBox1 CyrusBox2
  \   /
   `-\__/
SAN



The questions are:
1) Can it be done with out modifications to cyrus code?
2) if not, what has to be done
3) perhaps someone would like to do it for a reward in american presidents?

Freebsd 4.5 and cyrus-2.1.3

[arc]

I ran into this problem trying to build cyrus 2.1.3 on Freebsd-4.5 p2.
Anybody has anybody had any better success than I ?

arc@manta$ make all
### Making all in /usr/home/arc/cyrus-imapd-2.1.3/man
### Making all in /usr/home/arc/cyrus-imapd-2.1.3/sieve
gcc -c -I. -I.. -I. -I./../lib  -I/usr/local/include/db4  -I/usr/local/include 
-I/usr/bin/include -I/usr/local/lib/include -DHAVE_CONFIG_H -I. -I. -Wall -g -O2  
sieve.c
In file included from ../config.h:259,
 from sieve.y:30:
/usr/include/sys/socket.h:52: syntax error before `sa_family_t'
/usr/include/sys/socket.h:52: warning: data definition has no type or storage class
/usr/include/sys/socket.h:163: syntax error before `u_char'
/usr/include/sys/socket.h:174: syntax error before `u_short'
/usr/include/sys/socket.h:188: syntax error before `u_char'
/usr/include/sys/socket.h:190: `int64_t' undeclared here (not in a function)
/usr/include/sys/socket.h:190: `u_char' undeclared here (not in a function)
/usr/include/sys/socket.h:190: size of array `__ss_pad1' is too large
/usr/include/sys/socket.h:191: syntax error before `int64_t'
/usr/include/sys/socket.h:192: `u_char' undeclared here (not in a function)
/usr/include/sys/socket.h:192: `int64_t' undeclared here (not in a function)
/usr/include/sys/socket.h:192: `u_char' undeclared here (not in a function)
/usr/include/sys/socket.h:192: `int64_t' undeclared here (not in a function)
/usr/include/sys/socket.h:359: syntax error before `pid_t'
/usr/include/sys/socket.h:364: syntax error before `gid_t'
/usr/include/sys/socket.h:399: syntax error before `u_short'
/usr/include/sys/socket.h:407: syntax error before `caddr_t'
/usr/include/sys/socket.h:411: syntax error before `caddr_t'
/usr/include/sys/socket.h:444: syntax error before `recv'
/usr/include/sys/socket.h:444: warning: data definition has no type or storage class
/usr/include/sys/socket.h:445: syntax error before `recvfrom'
/usr/include/sys/socket.h:445: warning: data definition has no type or storage class
/usr/include/sys/socket.h:446: syntax error before `recvmsg'
/usr/include/sys/socket.h:446: warning: data definition has no type or storage class
/usr/include/sys/socket.h:447: syntax error before `send'
/usr/include/sys/socket.h:447: warning: data definition has no type or storage class
/usr/include/sys/socket.h:448: syntax error before `sendto'
/usr/include/sys/socket.h:449: warning: data definition has no type or storage class
/usr/include/sys/socket.h:450: syntax error before `sendmsg'
/usr/include/sys/socket.h:450: warning: data definition has no type or storage class
/usr/include/sys/socket.h:451: syntax error before `off_t'
*** Error code 1

Stop in /usr/home/arc/cyrus-imapd-2.1.3/sieve.
*** Error code 1

Stop in /usr/home/arc/cyrus-imapd-2.1.3.

Cheers:
-arc

Arley Carter[EMAIL PROTECTED]
Tradewinds Technologies, Inc.   www.twinds.com
Winston-Salem, NC USA   Network Engineering & Security
336-817-9554

Re: multiple cyruses via SAN

[Walter Wong]

--On Tuesday, March 19, 2002 6:29 PM +0200 [EMAIL PROTECTED] 
wrote:

> Here is the idea:
>
>
>
> CyrusBox1 CyrusBox2
>   \   /
>`-\__/
> SAN
>
>
>
> The questions are:
> 1) Can it be done with out modifications to cyrus code?

Sure if
a) You want the SAN to just be a disk store and CB1 and CB2 have 
independent stores. The benefit of the SAN would be that you can add 
additional partitions to CB1 and CB2 as the needs of each store increases.
b) Your SAN software provides Unix locking semantics between CB1/CB2 then 
you can have them both running.
c) Your SAN software provides heartbeat and/or other failover support then 
you can have CB1 fail over to CB2.

> 2) if not, what has to be done
> 3) perhaps someone would like to do it for a reward in american
> presidents?

The botton of  gives you 
an address to send the reward for providing the base IMAP server. :-) We 
may "soon" be able to accept credit cards too.

Walter

Re: multiple cyruses via SAN

[Konrads . Smelkovs]

Idea is that they share same mails/rules and acti simultaneously. A
loadbalancer will stand in front of those boxes.


|-+->
| |   Walter Wong <[EMAIL PROTECTED]> |
| |   Sent by:  |
| |   [EMAIL PROTECTED]|
| |   rew.cmu.edu   |
| | |
| | |
| |   2002.03.19 19:15  |
| | |
|-+->
  
>--|
  |
  |
  |   To:   [EMAIL PROTECTED]
  |
  |   cc:  
  |
  |   Subject:  Re: multiple cyruses via SAN   
  |
  
>--|






--On Tuesday, March 19, 2002 6:29 PM +0200 [EMAIL PROTECTED]
wrote:

> Here is the idea:
>
>
>
> CyrusBox1 CyrusBox2
>   \   /
>`\/
> SAN
>
>
>
> The questions are:
> 1) Can it be done with out modifications to cyrus code?

Sure if
 a) You want the SAN to just be a disk store and CB1 and CB2
have
independent stores. The benefit of the SAN would be that you can add
additional partitions to CB1 and CB2 as the needs of each store increases.
 b) Your SAN software provides Unix locking semantics between
CB1/CB2 then
you can have them both running.
 c) Your SAN software provides heartbeat and/or other failover
support then
you can have CB1 fail over to CB2.

> 2) if not, what has to be done
> 3) perhaps someone would like to do it for a reward in american
> presidents?

The botton of  gives you
an address to send the reward for providing the base IMAP server. :-) We
may "soon" be able to accept credit cards too.

Walter

Re: multiple cyruses via SAN

[Ken Murchison]

[EMAIL PROTECTED] wrote:
> 
> Here is the idea:
> 
> CyrusBox1 CyrusBox2
>   \   /
>`-\__/
> SAN
> 
> The questions are:
> 1) Can it be done with out modifications to cyrus code?
> 2) if not, what has to be done
> 3) perhaps someone would like to do it for a reward in american presidents?

What are you trying to accomplish with the SAN?  Are your trying to have
a shared filesystem, or just shared storage (each server has its own
partition on the array)?

If you're just looking for shared storage, than Cyrus _should_ work
as-is.

If you're looking for a shared filesystem, then I think you want to look
below the application layer to something like SGI's CXFS (Clustered XFS
filesystem).  

Which president in particular?  I'm partial to several Ben Franklins
myself ;-)

Ken
-- 
Kenneth Murchison Oceana Matrix Ltd.
Software Engineer 21 Princeton Place
716-662-8973 x26  Orchard Park, NY 14127
--PGP Public Key--http://www.oceana.com/~ken/ksm.pgp

Re: Signaled to Death by 11 - Again

[Ken Murchison]

OCNS Consulting wrote:
> 
> David:
> 
> I re-compiled LDAP without SASL support and re-linked pam_ldap with the new
> LDAP libraries, as suggested. Restarted both LDAP and master; LDAP access
> successful;
> attempted IMAP access and as before Death by 11. Here's log file excerpt (SA
> B4):
> 
>Mar 19 10:50:11 mailsrv imapd[24376]: accepted connection
>Mar 19 10:50:11 mailsrv master[24388]: about to exec /usr/cyrus/bin/imapd
>Mar 19 10:50:11 mailsrv imap[24388]: executed
>Mar 19 10:50:11 mailsrv master[24347]: process 24376 exited, signaled to
> death by 11
> 
> As per Ken Murchison's suggestion, I looked for a core file and found none.
> Ken where
> will the core file reside, if created? What trace back would you like to
> view?

Probably whichever directory master was started from (assuming the core
file size limit isn't 0).  On my Linux box, I do the following before
starting master in my startup script:

cd /var/imap/cores
ulimit -c unlimited

This set the core file size to unlimited and dumps any cores in
/var/imap/cores (make the directory first, with write access by
'cyrus').  Obviously, any old cores are overwritten, but I don't get
that many (usually only when I'm testing code changes) so its not a
problem.

If you get a core, just run it through a debugger and post a backtrace.

Ken
-- 
Kenneth Murchison Oceana Matrix Ltd.
Software Engineer 21 Princeton Place
716-662-8973 x26  Orchard Park, NY 14127
--PGP Public Key--http://www.oceana.com/~ken/ksm.pgp

undefined reference to ... on red hat 7.1

[ronen amity]

while trying to compile cyrus imap 2.1.3 on red hat 7.1 kernal 2.4.2-2smp,
i get this error


[amity@crow cyrus-imapd-2.1.3]# make all CFLAGS=-O
...
gcc -L/usr/local/lib -Wl,-rpath,/usr/local/lib -s -Wall -g -O2  -o master 
master.o masterconf.o cyrusMasterMIB.o -lucdagent -lucdmibs -lsnmp -lssl 
-lcrypto   -lfl  -ldb-3.1  -lresolv  -lcom_err
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libucdmibs.so: undefined 
reference to `smux_listen_sd'
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libucdmibs.so: undefined 
reference to `rpmdbClose'
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libucdmibs.so: undefined 
reference to `rpmdbGetIteratorOffset'
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libucdmibs.so: undefined 
reference to `headerLink'
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libucdmibs.so: undefined 
reference to `rpmdbOpen'
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libucdmibs.so: undefined 
reference to `rpmdbInitIterator'
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libucdmibs.so: undefined 
reference to `rpmGetPath'
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libucdmibs.so: undefined 
reference to `headerFree'
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libucdmibs.so: undefined 
reference to `XrpmdbNextIterator'
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libucdmibs.so: undefined 
reference to `rpmReadConfigFiles'
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libucdmibs.so: undefined 
reference to `headerGetEntry'
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libucdmibs.so: undefined 
reference to `rpmdbFreeIterator'
collect2: ld returned 1 exit status
make[1]: *** [master] Error 1
make[1]: Leaving directory `/usr/local/src/cyrus-imapd-2.1.3/master'
make: *** [all] Error 1


anyone have ideas ?

Re: multiple cyruses via SAN

[alex]

On Tue, 19 Mar 2002 [EMAIL PROTECTED] wrote:

> 
> Idea is that they share same mails/rules and acti simultaneously. A
> loadbalancer will stand in front of those boxes.
Its certainly something I wanted to try for a long time now. There has 
been many requests for this on the list, but I'm not aware of anyone who 
has it actually working.

Major problem is finding decent SAN solution with unix semantics. GFS was
supposed to be The Thing, but now, without available source, I'm not so
sure. OpenGFS is nowhere close to be usable. Polyserve is bit too
expensive. Veritas is just a ripoff :)

-alex

Re: multiple cyruses via SAN

[Earl R Shannon]

Hello,

We would like to use a shared filesystem. Will ALL the accounts on 
each server. Then we would use a load balancing package ( Resonate )
in front of the servers. Should one server fail the service would
continue.

Network
  /\
 /  \
/\
   /  \ 
ResonateMaster-ResonateSlave
|\  /|
| \/ |
|  \  /  |
|   \/   |
|\  /|
| \/ |
| /\ |
|/  \|
|   /\   |
|  /  \  |
| /\ |
|/  \|
 cyrusbox1   cyrusbox2
 \   /
  \ /
   \   /
\ /
 \   /
  \ /
  San ( shared filesystem)


More cyrusboxes can be added to access the San and be linked back to
the resonate boxes. This allows us to scale the service as necessary
and provide redundancy in the event of a failure. If an imap server
fails then the Resonate machines would not route ( bad choice of
words perhaps but thats basically what Resonate does ) requests to it.
So, each imap server must see the same filesystem and since one
connection can come from one server to a mailbox and another from
a different server some form of locking mechanism must be used to
garuantee mutual exclusion. The big question as already asked is,
Does a clustering file system that allows such file system sharing
provide sufficient protection or would the application
itself (in this case cyrus) need to be made aware that accesses to its
data could be made by processes running on a different machine?

We already do this with our web servers using AFS instead of a SAN.
But the web servers deliver static data so doing this is very simple
for them. No one's trying to write while the web servers are reading.




Ken Murchison wrote:
> 
> [EMAIL PROTECTED] wrote:
> >
> > Here is the idea:
> >
> > CyrusBox1 CyrusBox2
> >   \   /
> >`-\__/
> > SAN
> >
> > The questions are:
> > 1) Can it be done with out modifications to cyrus code?
> > 2) if not, what has to be done
> > 3) perhaps someone would like to do it for a reward in american presidents?
> 
> What are you trying to accomplish with the SAN?  Are your trying to have
> a shared filesystem, or just shared storage (each server has its own
> partition on the array)?
> 
> If you're just looking for shared storage, than Cyrus _should_ work
> as-is.
> 
> If you're looking for a shared filesystem, then I think you want to look
> below the application layer to something like SGI's CXFS (Clustered XFS
> filesystem).
> 
> Which president in particular?  I'm partial to several Ben Franklins
> myself ;-)
> 
> Ken
> --
> Kenneth Murchison Oceana Matrix Ltd.
> Software Engineer 21 Princeton Place
> 716-662-8973 x26  Orchard Park, NY 14127
> --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp

Re: Signaled to Death by 11 - Again

[Konrads . Smelkovs]

My idea about cyrus getting sig11'ed is because of berkeley DB.

Re: undefined reference to ... on red hat 7.1

[Ken Murchison]

ronen amity wrote:
> 
> while trying to compile cyrus imap 2.1.3 on red hat 7.1 kernal 2.4.2-2smp,
> i get this error
> 
> [amity@crow cyrus-imapd-2.1.3]# make all CFLAGS=-O
> ...
> gcc -L/usr/local/lib -Wl,-rpath,/usr/local/lib -s -Wall -g -O2  -o master
> master.o masterconf.o cyrusMasterMIB.o -lucdagent -lucdmibs -lsnmp -lssl
> -lcrypto   -lfl  -ldb-3.1  -lresolv  -lcom_err
> /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libucdmibs.so: undefined
> reference to `smux_listen_sd'
> /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libucdmibs.so: undefined
> reference to `rpmdbClose'
> /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libucdmibs.so: undefined
> reference to `rpmdbGetIteratorOffset'
> /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libucdmibs.so: undefined
> reference to `headerLink'
> /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libucdmibs.so: undefined
> reference to `rpmdbOpen'
> /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libucdmibs.so: undefined
> reference to `rpmdbInitIterator'
> /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libucdmibs.so: undefined
> reference to `rpmGetPath'
> /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libucdmibs.so: undefined
> reference to `headerFree'
> /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libucdmibs.so: undefined
> reference to `XrpmdbNextIterator'
> /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libucdmibs.so: undefined
> reference to `rpmReadConfigFiles'
> /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libucdmibs.so: undefined
> reference to `headerGetEntry'
> /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libucdmibs.so: undefined
> reference to `rpmdbFreeIterator'
> collect2: ld returned 1 exit status
> make[1]: *** [master] Error 1
> make[1]: Leaving directory `/usr/local/src/cyrus-imapd-2.1.3/master'
> make: *** [all] Error 1
> 
> anyone have ideas ?

Either update your UCS SNMP RPMS or, disable SNMP with the configure
option.

Ken
-- 
Kenneth Murchison Oceana Matrix Ltd.
Software Engineer 21 Princeton Place
716-662-8973 x26  Orchard Park, NY 14127
--PGP Public Key--http://www.oceana.com/~ken/ksm.pgp

Re: multiple cyruses via SAN

[Konrads . Smelkovs]

So you think if i simply had cxfs, it would work w/o problems?

Re: multiple cyruses via SAN

[Ken Murchison]

Earl R Shannon wrote:
> 
> Hello,
> 
> We would like to use a shared filesystem. Will ALL the accounts on
> each server. Then we would use a load balancing package ( Resonate )
> in front of the servers. Should one server fail the service would
> continue.
> 
> Network
>   /\
>  /  \
> /\
>/  \
> ResonateMaster-ResonateSlave
> |\  /|
> | \/ |
> |  \  /  |
> |   \/   |
> |\  /|
> | \/ |
> | /\ |
> |/  \|
> |   /\   |
> |  /  \  |
> | /\ |
> |/  \|
>  cyrusbox1   cyrusbox2
>  \   /
>   \ /
>\   /
> \ /
>  \   /
>   \ /
>   San ( shared filesystem)
> 
> More cyrusboxes can be added to access the San and be linked back to
> the resonate boxes. This allows us to scale the service as necessary
> and provide redundancy in the event of a failure. If an imap server
> fails then the Resonate machines would not route ( bad choice of
> words perhaps but thats basically what Resonate does ) requests to it.
> So, each imap server must see the same filesystem and since one
> connection can come from one server to a mailbox and another from
> a different server some form of locking mechanism must be used to
> garuantee mutual exclusion. The big question as already asked is,
> Does a clustering file system that allows such file system sharing
> provide sufficient protection or would the application
> itself (in this case cyrus) need to be made aware that accesses to its
> data could be made by processes running on a different machine?

The Cyrus code already handles the locking between multiple processes,
so an imapd running on a different box is a subtle (if any) difference,
provided that the shared filesystem handles read/write access from
multiple hosts and provides UNIX file locking semantics.

The only filesystem that I'm aware of that promises this (and delivers)
is SGI's CXFS.

Ken
-- 
Kenneth Murchison Oceana Matrix Ltd.
Software Engineer 21 Princeton Place
716-662-8973 x26  Orchard Park, NY 14127
--PGP Public Key--http://www.oceana.com/~ken/ksm.pgp

Re: multiple cyruses via SAN

[Ken Murchison]

[EMAIL PROTECTED] wrote:
> 
> So you think if i simply had cxfs, it would work w/o problems?

I _think_ so.  I've never tried it an make no guarantees.  Keep in mind
that CXFS is only available on IRIX and Solaris (and may require IRIX
servers).  SGI is supposedly working on Linux, Win32 and MacOS clients.

Ken
-- 
Kenneth Murchison Oceana Matrix Ltd.
Software Engineer 21 Princeton Place
716-662-8973 x26  Orchard Park, NY 14127
--PGP Public Key--http://www.oceana.com/~ken/ksm.pgp

Re: multiple cyruses via SAN

[Earl R Shannon]

Hello,

Actually, there is no SAN server. The SAN is to be implemented
with fiber channel devices. The imap servers will have a fiber
channel interface which is connected to a fiber channel switch.
Also connected to the fiber channel switches are the RAID units
with the actual storage.

As for the load balancing, we have been using it for a while and
are quite comfortable with what it does and how it works. And
why have partner IMAP servers replicating work when having one
machine do the work and the other see it immediately. In other
words, the shared file system implemented on top of the SAN
( shared file system does not equal SAN ) sorta does the replication.
In a very real sense you have one hard disk mounted on two machines.
Once one does the file system update the other can see it.
The trick is, and hence my question, how does one handle access to
prevent corruption. Is cyrus written so that what the shared
file system provides is sufficient, or does the application need
to be made aware of the possibility of two processes on two different
machines writing to the one disk?

And yes, we need to have more than one imap server. I drew the
picture below only showing two because that was easy in ASCII.
In reality we will probably have at least four. Each being managed
by the Resonate load balancing service and all connected to the
same shared file system.

Regards,
Earl Shannon
-- 
Systems Programmer, Computing Services, Information Technology
NC State University.
http://www4.ncsu.edu/~ershanno



Sean Witham wrote:
> 
> Earl R Shannon wrote:
> 
> > Hello,
> >
> > We would like to use a shared filesystem. Will ALL the accounts on
> > each server. Then we would use a load balancing package ( Resonate )
> > in front of the servers. Should one server fail the service would
> > continue.
> >
> > Network
> >   /\
> >  /  \
> > /\
> >/  \
> >   ResonateMaster-ResonateSlave
> > |\  /|
> > | \/ |
> > |  \  /  |
> > |   \/   |
> > |\  /|
> > | \/ |
> > | /\ |
> > |/  \|
> > |   /\   |
> > |  /  \  |
> > | /\ |
> > |/  \|
> >  cyrusbox1   cyrusbox2
> >  \   /
> >   \ /
> >\   /
> > \ /
> >  \   /
> >   \ /
> >   San ( shared filesystem)
> >
> >
> 
> When you look at that you have to ask if the San server and the load
> balancer are reliable enough to justify two cyrus servers or if you
> would be better off with just one cyrus server ? What you really want is
> a cyrus (or similar server) that can replicate updates between two
> partner servers. Or is you san really a virtual server that consists of
> a cluster of replicating units ?
> 
> --Sean
> 
> --Sean

-- 
Systems Programmer, Computing Services, Information Technology
NC State University.
http://www4.ncsu.edu/~ershanno

Re: multiple cyruses via SAN

[alex]

On Tue, 19 Mar 2002, Ken Murchison wrote:

> The Cyrus code already handles the locking between multiple processes,
> so an imapd running on a different box is a subtle (if any) difference,
> provided that the shared filesystem handles read/write access from
> multiple hosts and provides UNIX file locking semantics.
> 
> The only filesystem that I'm aware of that promises this (and delivers)
> is SGI's CXFS.
And GFS/OpenGFS, polyserve filesystem, and veritas clustered fs. Well, at 
least the above promise, don't have enough information to determine 
whether they deliver. ;)

-alex

Re: Freebsd 4.5 and cyrus-2.1.3

[Bob Finch]

> "Arley" == arc  <[EMAIL PROTECTED]> writes:

Arley> I ran into this problem trying to build cyrus 2.1.3 on
Arley> Freebsd-4.5 p2.  Anybody has anybody had any better success
Arley> than I ?

Here's the changes I made to get it to build on FreeBSD 4.5-RELEASE:

diff -c -r cyrus-imapd-2.1.3-orig/config.h.in cyrus-imapd-2.1.3/config.h.in
*** cyrus-imapd-2.1.3-orig/config.h.in  Thu Mar  7 12:08:39 2002
--- cyrus-imapd-2.1.3/config.h.in   Fri Mar 15 23:19:37 2002
***
*** 255,260 
--- 255,261 
  
  /* getaddrinfo things */
  #include 
+ #include 
  #include 
  
  #ifndef HAVE_GETADDRINFO
diff -c -r cyrus-imapd-2.1.3-orig/lib/cyrusdb_skiplist.c 
cyrus-imapd-2.1.3/lib/cyrusdb_skiplist.c
*** cyrus-imapd-2.1.3-orig/lib/cyrusdb_skiplist.c   Thu Feb 28 11:50:36 2002
--- cyrus-imapd-2.1.3/lib/cyrusdb_skiplist.cFri Mar 15 23:44:22 2002
***
*** 170,175 
--- 170,179 
  be_paranoid = 0
  };
  
+ #ifdef __FreeBSD__
+ #define fdatasync(fd) fsync(fd)
+ #endif
+ 
  #define FSYNC(fd) (do_fsync && fsync(fd))
  #define FDATASYNC(fd) ((do_fsync == 1 && fdatasync(fd)) || \
 (do_fsync == 2 && fsync(fd)))

-- Bob

Re: multiple cyruses via SAN

[Konrads . Smelkovs]

So, the only problem is filesystem? If cyrus is trained to handle multiple
imap processes and more important multiple lmtpd.


|-+>
| |   Gene Rackow  |
| |   <[EMAIL PROTECTED]|
| |   ov>  |
| ||
| |   2002.03.19 20:59 |
| ||
|-+>
  
>--|
  |
  |
  |   To:   [EMAIL PROTECTED] 
  |
  |   cc:  
  |
  |   Subject:  Re: multiple cyruses via SAN   
  |
  
>--|




Actually, it MAY just work, but I kind of doubt it.  Few things
are really designed to work with truely shared disk.

Also from what I have seen of the cxfs stuff, you'll have a whole bigger
set of problems in keeping your system up and running.   Don't go dow
that path without lots of testing.   There would be nothing like
getting your whole user community moved over to it only to have something
in the filesystem go south causing you to need to restore the world
(again).

--Gene


[EMAIL PROTECTED] made the following keystrokes:
 >
 >So you think if i simply had cxfs, it would work w/o problems?
 >

Re: multiple cyruses via SAN

[Gene Rackow]

I have no idea if it will or not.  My experience with shared
disk solutions is that very fwe packages or even operating
systems work well with them when you put them under load.
For anything critical, I would not use a shared disks solution.
I'm sorry if you took it to mean that it would work.  It may, but
I have not tested it to see.

-_Gene

[EMAIL PROTECTED] made the following keystrokes:
 >
 >So, the only problem is filesystem? If cyrus is trained to handle multiple
 >imap processes and more important multiple lmtpd.
 >
 >
 >|-+>
 >| |   Gene Rackow  |
 >| |   <[EMAIL PROTECTED]|
 >| |   ov>  |
 >| ||
 >| |   2002.03.19 20:59 |
 >| ||
 >|-+>
 >  >--
 >  |
 >  |  
 >  |
 >  |   To:   [EMAIL PROTECTED]   
 >  |
 >  |   cc:
 >  |
 >  |   Subject:  Re: multiple cyruses via SAN 
 >  |
 >  >--
 >  |
 >
 >
 >
 >
 >Actually, it MAY just work, but I kind of doubt it.  Few things
 >are really designed to work with truely shared disk.
 >
 >Also from what I have seen of the cxfs stuff, you'll have a whole bigger
 >set of problems in keeping your system up and running.   Don't go dow
 >that path without lots of testing.   There would be nothing like
 >getting your whole user community moved over to it only to have something
 >in the filesystem go south causing you to need to restore the world
 >(again).
 >
 >--Gene
 >
 >
 >[EMAIL PROTECTED] made the following keystrokes:
 > >
 > >So you think if i simply had cxfs, it would work w/o problems?
 > >
 >
 >
 >
 >

Re: multiple cyruses via SAN

[Chris Audley]

No, it will not work.  A shared file system with unix lock semantics is 
not enough, Berkeley DB will not work in this environment because it 
uses shared memory.  The system is single host bound.

Cheers
Chris

[EMAIL PROTECTED] wrote:

>So you think if i simply had cxfs, it would work w/o problems?
>

Re: multiple cyruses via SAN

[alex]

Hmm,

I think there's a way to persuade berkeleydb to work without shm. Not sure 
tho

-alex

On Tue, 19 Mar 2002, Chris Audley wrote:

> No, it will not work.  A shared file system with unix lock semantics is 
> not enough, Berkeley DB will not work in this environment because it 
> uses shared memory.  The system is single host bound.
> 
> Cheers
> Chris
> 
> [EMAIL PROTECTED] wrote:
> 
> >So you think if i simply had cxfs, it would work w/o problems?
> >
> 
> 

Re: multiple cyruses via SAN

[Ken Murchison]

Chris Audley wrote:
> 
> No, it will not work.  A shared file system with unix lock semantics is
> not enough, Berkeley DB will not work in this environment because it
> uses shared memory.  The system is single host bound.

Yup.  Good call.  This could be worked around or just use non-BDB
cyrusdb backends.

Ken
-- 
Kenneth Murchison Oceana Matrix Ltd.
Software Engineer 21 Princeton Place
716-662-8973 x26  Orchard Park, NY 14127
--PGP Public Key--http://www.oceana.com/~ken/ksm.pgp

Re: multiple cyruses via SAN

[Igor Brezac]

On Tue, 19 Mar 2002, Ken Murchison wrote:

>
>
> Chris Audley wrote:
> >
> > No, it will not work.  A shared file system with unix lock semantics is
> > not enough, Berkeley DB will not work in this environment because it
> > uses shared memory.  The system is single host bound.
>
> Yup.  Good call.  This could be worked around or just use non-BDB
> cyrusdb backends.
>

I do not see how this will work either.  You can potentially get some
undesired results if you have several different imapd's on different
machines updating cyrusdb backends at the same time.  Cyrus has no control
as to how will underlying SAN system update the file systems.

-Igor