Hi all
I'm looking for a working HOWTO / Tutorial / sample setup of setting up a clustered email server. I know I can setup a CentOS cluster with Heartbeat & drbd, but I'm not 100% convinced it will work for the email as well.
Ideally, I'd like to use an open source groupware server, like say open exchange, php groupware, Scalix (free / community version), etc. So, if anyone can please point me in the right direction?
I've already setup a heartbeat cluster, and use rsync to sync files for Samba, Apache & NFS, and also setup a Master-Master MySQL replication, but don't yet know how to setup the email server,
Rudi Ahlers wrote:
I'm looking for a working HOWTO / Tutorial / sample setup of setting up a clustered email server. I know I can setup a CentOS cluster with Heartbeat & drbd, but I'm not 100% convinced it will work for the email as well.
What problem are you trying to solve ? Cyrus-imapd has native replication for example.
- KB
Karanbir Singh wrote:
Rudi Ahlers wrote:
I'm looking for a working HOWTO / Tutorial / sample setup of setting up a clustered email server. I know I can setup a CentOS cluster with Heartbeat & drbd, but I'm not 100% convinced it will work for the email as well.
What problem are you trying to solve ? Cyrus-imapd has native replication for example.
- KB
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I don't have a problem to solve, but I don't know which mail server to use either. But, like I said, ideally I'd like to use one of the groupware type mailserver (POP3, SMTP, IMAP, calendar, address book, etc)
Rudi Ahlers wrote:
I'm looking for a working HOWTO / Tutorial / sample setup of setting up a clustered email server. I know I can setup a CentOS cluster with
I don't have a problem to solve, but I don't know which mail server to use either. But, like I said, ideally I'd like to use one of the groupware type mailserver (POP3, SMTP, IMAP, calendar, address book, etc)
Well, I am sure you have some reason to setup a cluster. Is it for failover / redundancy ? or is it for higher performance ? or is it to distribute load geographically ? distribute load by service ?
You need to first work out what you want to do. What setup and howto set it up will depend on what you are trying to achieve ( = what problem you are trying to solve ). However, keep in mind that anything more than small to small medium setups for mail storage usually end at Cyrus.
- KB
PS: try trimming your replies to remove unneeded content
Karanbir Singh wrote:
Rudi Ahlers wrote:
I'm looking for a working HOWTO / Tutorial / sample setup of setting up a clustered email server. I know I can setup a CentOS cluster with
I don't have a problem to solve, but I don't know which mail server to use either. But, like I said, ideally I'd like to use one of the groupware type mailserver (POP3, SMTP, IMAP, calendar, address book, etc)
Well, I am sure you have some reason to setup a cluster. Is it for failover / redundancy ? or is it for higher performance ? or is it to distribute load geographically ? distribute load by service ?
You need to first work out what you want to do. What setup and howto set it up will depend on what you are trying to achieve ( = what problem you are trying to solve ). However, keep in mind that anything more than small to small medium setups for mail storage usually end at Cyrus.
- KB
PS: try trimming your replies to remove unneeded content
Hey Karanbir
I'm trying to achieve a simple fail over solution, for a small rural clinic, about 700KM's away, which we have sponsored, so there's no money involved and I can't afford / justify exchange (don't want to go the MS route in anycase), Zimbra or any of those.
For fail over on the webserver & samba, the heartbeat + rsync works well, but I don't know where to look for the email stuff. I don't need anything fancy, but a shared calendar & address book would be great. It's a 10 user network
Rudi Ahlers wrote:
For fail over on the webserver & samba, the heartbeat + rsync works well, but I don't know where to look for the email stuff. I don't need anything fancy, but a shared calendar & address book would be great. It's a 10 user network
email is essentially an on-disk setup, so just setup any software you want ( I recommend roundcube over squirrelmail as a nice web interface - basic, but usable ).
Just put the email storage on the drbd mounted drive and you should be ok.
Karanbir Singh wrote:
email is essentially an on-disk setup, so just setup any software you want ( I recommend roundcube over squirrelmail as a nice web interface
- basic, but usable ).
Just put the email storage on the drbd mounted drive and you should be ok.
drbd is asynchronous replication, isn't it? so if the active 'master' fails just as its written and acknowledged an incoming message, that message could be lost if the replication hasn't completed by the time of failure ?
John R Pierce wrote:
drbd is asynchronous replication, isn't it? so if the active 'master' fails just as its written and acknowledged an incoming message, that message could be lost if the replication hasn't completed by the time of failure ?
I believe you can run DRBD so primary writes dont return till the secondary write also completes. No idea how that impacts performance :D
On Sat, 17 May 2008 20:09:50 +0100 Karanbir Singh mail-lists@karan.org wrote:
I believe you can run DRBD so primary writes dont return till the secondary write also completes. No idea how that impacts performance :D
Default mode of drbd operation is synchronous as you mention and its performance is purely dependant of underlying block device. Having a gig of battery backed write cache on each side helps :) Asynchronous mode of operation is actually a special case for drbd and is primarily meant for geographically distributed setups that replicate data over wan.
But as the opening poster said he has a small number of users, drbd with standard sata disks should be fast enough.
John R Pierce wrote:
Karanbir Singh wrote:
email is essentially an on-disk setup, so just setup any software you want ( I recommend roundcube over squirrelmail as a nice web interface - basic, but usable ).
Just put the email storage on the drbd mounted drive and you should be ok.
drbd is asynchronous replication, isn't it? so if the active 'master' fails just as its written and acknowledged an incoming message, that message could be lost if the replication hasn't completed by the time of failure ?
Well, that's one of the problems I foresee, but also the fact that each email has a unique message ID, so I don't know if the backup server will pickup the changed messages ID's or not? I have been thinking of running a MySQL backed mail server, but have a feeling it will have a heavy impact on performance
Rudi Ahlers wrote:
Well, that's one of the problems I foresee, but also the fact that each email has a unique message ID, so I don't know if the backup server will pickup the changed messages ID's or not? I have been thinking of running a MySQL backed mail server, but have a feeling it will have a heavy impact on performance
umm. message-ID's are added at mail origin time ( or the first time they come in contact with a non brain dead mta ).
me thinks you need to read up a bit on what email is and how it works. the RFC's are a good place to start ( and mostly readable ).
Karanbir Singh wrote:
Rudi Ahlers wrote:
Well, that's one of the problems I foresee, but also the fact that each email has a unique message ID, so I don't know if the backup server will pickup the changed messages ID's or not? I have been thinking of running a MySQL backed mail server, but have a feeling it will have a heavy impact on performance
umm. message-ID's are added at mail origin time ( or the first time they come in contact with a non brain dead mta ).
me thinks you need to read up a bit on what email is and how it works. the RFC's are a good place to start ( and mostly readable ).
I'm referring to the way qmail stores emails (if each email is a different file). AFAIK, this is a known problem with clustered mails servers.
Rudi Ahlers wrote:
Karanbir Singh wrote:
Rudi Ahlers wrote:
Well, that's one of the problems I foresee, but also the fact that each email has a unique message ID, so I don't know if the backup server will pickup the changed messages ID's or not? I have been thinking of running a MySQL backed mail server, but have a feeling it will have a heavy impact on performance
I'm referring to the way qmail stores emails (if each email is a different file). AFAIK, this is a known problem with clustered mails servers.
Maildir is in use by almost all MTAs available on Unix/Linux or can be supported by available LDA's such as procmail/maildrop. Keeping the mail store in sync with the backup server whether by rsync or instantly by using a distributed filesystem will solve whatever problem you are thinking of in this respect.
Rudi Ahlers wrote:
Karanbir Singh wrote:
Rudi Ahlers wrote:
Well, that's one of the problems I foresee, but also the fact that each email has a unique message ID, so I don't know if the backup server will pickup the changed messages ID's or not? I have been thinking of running a MySQL backed mail server, but have a feeling it will have a heavy impact on performance
DRBD is a block device ... there is no difference in a database or files. I database in the shared partition is JUST a file anyway :D
umm. message-ID's are added at mail origin time ( or the first time they come in contact with a non brain dead mta ).
me thinks you need to read up a bit on what email is and how it works. the RFC's are a good place to start ( and mostly readable ).
I'm referring to the way qmail stores emails (if each email is a different file). AFAIK, this is a known problem with clustered mails servers.
DRBD is not really clustered in that since, at least not the normal setup.
DRBD is BASICALLY raid1 for specific hard drive partition. It does not copy files, it copies underlying bits directly as a block device.
I use DRBD effectively on Domain Controllers / File Servers and on e-mail servers. I have MySQL databases and LDAP databases and Qmailtoaster in the box on these with no problems whatsoever.
There is a way to setup a Primary-Primary type on a clustered file system like GFS or OCFS2, however that is not the main purpose of DRBD. The main purpose is to replicate a partition and fail it over to another machine when the first one fails.
Both partitions in a DRBD group are not mounted at the same time (much like RAID1) and you only access what is know as the secondary device when it becomes primary, unless you use the Primary-Primary setup. But there are much better ways (IMHO) to achieve Primary-Primary effect with other clustering technologies like LVS or RHCS/RHGFS.
Thanks, Johnny Hughes
I don't have a problem to solve, but I don't know which mail server to use either. But, like I said, ideally I'd like to use one of the groupware type mailserver (POP3, SMTP, IMAP, calendar, address book, etc)
What you want is a centralised and yet distributed user information database whether mysql, postgresql, ldap and centralised but yet distributed mail storage. Just about any MTA that can be installed on Centos will support the first be it qmail, sendmail, postfix or exim. IMAP/POP3 wise, dovecot or courier-imap can also support the first. The second is best to hide from the application layer by implementing it at the file system level with say GFS. Address book can be plain old ldap. Calendar...sorry that is even more integrating. You might want to try JES (Java Enterprise System) besides the others that you have mentioned. Thunderbird has calendar support. Oh, happy integrating and interface buliding/modifying for this lot.
If you are looking for a server solution for outlook, please just go and either get Exchange or go trouble the guys running OX and so on because Centos has zero solutions that support Outlook with all its features in force.
Christopher Chan wrote:
I don't have a problem to solve, but I don't know which mail server to use either. But, like I said, ideally I'd like to use one of the groupware type mailserver (POP3, SMTP, IMAP, calendar, address book, etc)
What you want is a centralised and yet distributed user information database whether mysql, postgresql, ldap and centralised but yet distributed mail storage. Just about any MTA that can be installed on Centos will support the first be it qmail, sendmail, postfix or exim. IMAP/POP3 wise, dovecot or courier-imap can also support the first. The second is best to hide from the application layer by implementing it at the file system level with say GFS. Address book can be plain old ldap. Calendar...sorry that is even more integrating. You might want to try JES (Java Enterprise System) besides the others that you have mentioned. Thunderbird has calendar support. Oh, happy integrating and interface buliding/modifying for this lot.
If you are looking for a server solution for outlook, please just go and either get Exchange or go trouble the guys running OX and so on because Centos has zero solutions that support Outlook with all its features in force. _______________________________________________
Thank you for your input. I can't justify exchange (and don't want MS) for 10 users. I do want IMAP though, and the calendar & address book would be nice. This IMO has nothing todo with CentOS though, but at the same time it shouldn't be limited to which Linux distro I'm using. As you have said I may need to look at file system clustering instead, but have never attempted it, so I don't know where to begin even. I know a lot of MTA's can support a central user DB, but that won't sync the emails. And this won't be a commercial installation either, it's for a for a project in a rural community about 700km's from me, so it's more a matter of if 1 server dies / crashes / packes up, and I can only get to it 5 days later, the mail server still works :)
Thank you for your input. I can't justify exchange (and don't want MS) for 10 users. I do want IMAP though, and the calendar & address book would be nice. This IMO has nothing todo with CentOS though, but at the same time it shouldn't be limited to which Linux distro I'm using. As you have said I may need to look at file system clustering instead, but have never attempted it, so I don't know where to begin even. I know a lot of MTA's can support a central user DB, but that won't sync the emails. And this won't be a commercial installation either, it's for a for a project in a rural community about 700km's from me, so it's more a matter of if 1 server dies / crashes / packes up, and I can only get to it 5 days later, the mail server still works :)
I don't know how cyrus does its clustering. You can check to see if it supports deliveries to all members of the cluster or whether it is only to a master.
No MTA out there cares about managing mail storage or making it available although some do provide pop/imap or both for a total solution. You can try dual deliveries. One to main box and another to the backup but there is simply no guarantee of the mail stores being kept in sync. If you can get GFS setup, that would be best but then that also involves a few boxes from what I understand...that is storage boxes and then combination smtp/imap boxes which will act as clients to the storage boxes. You could try installing opensolaris on the storage boxes such as the new Indiana release and use zfs to export the disk space as iscsi targets for GFS on the combination smtp/imap boxes. You could put smtp and imap on the same webserver/samba boxes too and put all your data on the opensolaris boxes...but I take it you already have those up and running.
On Sat, 2008-05-17 at 10:30 +0200, Rudi Ahlers wrote:
Thank you for your input. I can't justify exchange (and don't want MS) for 10 users. I do want IMAP though, and the calendar & address book would be nice. This IMO has nothing todo with CentOS though, but at the same time it shouldn't be limited to which Linux distro I'm using. As you have said I may need to look at file system clustering instead, but have never attempted it, so I don't know where to begin even. I know a lot of MTA's can support a central user DB, but that won't sync the emails. And this won't be a commercial installation either, it's for a for a project in a rural community about 700km's from me, so it's more a matter of if 1 server dies / crashes / packes up, and I can only get to it 5 days later, the mail server still works :)
You might take a look at SquirrelMail. It integrates well with cyrus imap.
Dave
David G. Mackay wrote:
You might take a look at SquirrelMail. It integrates well with cyrus imap.
I've started liking roundcube a bit more than squirrelmail. but roundcube is very basic. SquirrelMail has a *LOT* of plugins and can be made to do almost anything these days. And the community around squirrelmail is much larger than roundcube.
Another candidate is Horde+IMP ( which Johnny maintains in the centos repos )
Karanbir Singh wrote:
David G. Mackay wrote:
You might take a look at SquirrelMail. It integrates well with cyrus imap.
I've started liking roundcube a bit more than squirrelmail. but roundcube is very basic. SquirrelMail has a *LOT* of plugins and can be made to do almost anything these days. And the community around squirrelmail is much larger than roundcube.
Another candidate is Horde+IMP ( which Johnny maintains in the centos repos )
Sorry guys, I want to stick with a SMTP / IMAP / POP3 server, not webmail. I'll be using Horde for webmail as well though
Rudi Ahlers wrote:
Sorry guys, I want to stick with a SMTP / IMAP / POP3 server, not webmail. I'll be using Horde for webmail as well though
there are two general classes of clustered systems, high availability, and high performance.
HA clusters are usually active/standby, and might use stuff like heartbeat, drbd, etc.
HP clusters are either load balanced, or active/active... Things that demand ACID (Atomicity, Consistency, Isolation, Durability) like databases, mail servers are very complex to cluster this way on a active/active (aka multimaster) environment while maintaining the integrity and a reasonable performance. just implementing load balancing does not by itself provide any redundancy in case of component failure. A simple load balancing scenario for a mail server might be having one server to handle all internet mail incoming and outgoing, while another server handles local users reading their mail (eg, pop or imap)
its best to define your requirements and expectations before diving into these waters, as clusters can be far more complex and intricate to configure and administrate than discrete systems.
re: mail servers specifically, there are two seperate classes of storage that would need replication... One is the mail spools and queues as used by the MTA (postfix, sendmail, etc), and the other are the user mail folder(s) as used by the local delivery agent (procmail or whattever), and read by the mail client (pop, imap).
re: mail servers specifically, there are two seperate classes of storage that would need replication... One is the mail spools and queues as used by the MTA (postfix, sendmail, etc), and the other are the user mail folder(s) as used by the local delivery agent (procmail or whattever), and read by the mail client (pop, imap).
No, mail spools/queues do not need replication. Stuff in the queue are usually deleted in a second and such dynamic change is not worth replicating. If you do put the queue on a distributed filesystem, in most cases you cannot have more than one instance running save for sendmail.
The only thing that the MTA needs is the user information database and that is what needs replicating both for the MTA and the pop/imap server software, not the queues.
Then the mail store, including configuration files for the local delivery agent in use, needs replication.
Christopher Chan wrote:
re: mail servers specifically, there are two seperate classes of storage that would need replication... One is the mail spools and queues as used by the MTA (postfix, sendmail, etc), and the other are the user mail folder(s) as used by the local delivery agent (procmail or whattever), and read by the mail client (pop, imap).
No, mail spools/queues do not need replication. Stuff in the queue are usually deleted in a second and such dynamic change is not worth replicating. If you do put the queue on a distributed filesystem, in most cases you cannot have more than one instance running save for sendmail.
outbound mail can sit in queues retrying for hours negotiating their way into the greylists of the likes of Yahoo. I guess if you don't mind the possibility of messages getting lost around a server failure event, then its no big deal, for sure.
John R Pierce wrote:
Christopher Chan wrote:
re: mail servers specifically, there are two seperate classes of storage that would need replication... One is the mail spools and queues as used by the MTA (postfix, sendmail, etc), and the other are the user mail folder(s) as used by the local delivery agent (procmail or whattever), and read by the mail client (pop, imap).
No, mail spools/queues do not need replication. Stuff in the queue are usually deleted in a second and such dynamic change is not worth replicating. If you do put the queue on a distributed filesystem, in most cases you cannot have more than one instance running save for sendmail.
outbound mail can sit in queues retrying for hours negotiating their way into the greylists of the likes of Yahoo. I guess if you don't mind the possibility of messages getting lost around a server failure event, then its no big deal, for sure.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
No, I'm not concerned about outbound mail. Chances are if the server's HDD has crashed, the email will either still be on the user's PC, or on the 2nd server. Or if it's not the HDD, then the email will be sent once the server is back online again.
I'm concerned about mail storage, since the server & USB HDD is the only backups. The users PC's isn't being backed up, everything on the LAN resides on the two servers, and one of the two servers backup to a USB HDD every night
No, mail spools/queues do not need replication. Stuff in the queue are usually deleted in a second and such dynamic change is not worth replicating. If you do put the queue on a distributed filesystem, in most cases you cannot have more than one instance running save for sendmail.
outbound mail can sit in queues retrying for hours negotiating their way into the greylists of the likes of Yahoo. I guess if you don't mind the possibility of messages getting lost around a server failure event, then its no big deal, for sure.
That only leaves putting the queue on a distributed filesystem. Replication will not be a complete solution to that and qmail queues cannot be replicated.
Then there is the question of whether to leave a message in the queue for more than 4 hours given the expectation of email to be more or less instantaneous.
Christopher Chan wrote:
No, mail spools/queues do not need replication. Stuff in the queue are usually deleted in a second and such dynamic change is not worth replicating. If you do put the queue on a distributed filesystem, in most cases you cannot have more than one instance running save for sendmail.
I think your statement here is flawed, in that if there is even a single bit of the process you dont replicate - you've already lost the HA game.
Besides, as John already pointed out, emails in the spools can hang around for days. I believe most MTA's only discard completely after 7days of non delivery.
the OP is taking about DRBD in a primary-> secondary setup, in which case, there wont be a clustered filesystem on the block device, and there will only really be one instance of the real app running.
Karanbir Singh wrote:
Christopher Chan wrote:
No, mail spools/queues do not need replication. Stuff in the queue are usually deleted in a second and such dynamic change is not worth replicating. If you do put the queue on a distributed filesystem, in most cases you cannot have more than one instance running save for sendmail.
I think your statement here is flawed, in that if there is even a single bit of the process you dont replicate - you've already lost the HA game.
I am sorry but I do not share that view for incoming mail. The latency in getting the mail replicated probably is longer than it takes to do the actually delivery to the mail store.
Besides, as John already pointed out, emails in the spools can hang around for days. I believe most MTA's only discard completely after 7days of non delivery.
That default setting is no longer applicable today. Users will scream if they find out that their mails have been sitting in the queue for a day. For today's businesses, one day can make or break a deal and so email, being a much faster form of communication than snail mail, has come to be seen as the preferred choice. People start calling when they know they are supposed to get an email in a minute or so when it does materialize.
the OP is taking about DRBD in a primary-> secondary setup, in which case, there wont be a clustered filesystem on the block device, and there will only really be one instance of the real app running.
He is welcome to replicate the queue. His traffic levels will be so low that it really does not affect things but if he is using qmail I hope that the filesystem is completely identical on the secondary.
Christopher Chan wrote:
No, mail spools/queues do not need replication. Stuff in the queue are usually deleted in a second and such dynamic change is not worth replicating. If you do put the queue on a distributed filesystem, in most cases you cannot have more than one instance running save for sendmail.
I think your statement here is flawed, in that if there is even a single bit of the process you dont replicate - you've already lost the HA game.
I am sorry but I do not share that view for incoming mail. The latency in getting the mail replicated probably is longer than it takes to do the actually delivery to the mail store.
DRBD works approximately like raid1 mirroring. Unless something breaks it shouldn't add much latency since the duplicate disk will run at approximately the same speed as the master.
Christopher Chan wrote:
I am sorry but I do not share that view for incoming mail. The latency in getting the mail replicated probably is longer than it takes to do the actually delivery to the mail store.
I am not sure what you mean by the word 'replication' but in most cases the user mail stores are on the same shared block device. And I've worked with an ISP recently that deliver between 12 to 16 million emails per day and dont have this problem of 'latency in replication'. Using exim and cyrus-imapd over 2 user facing nodes.
Besides, as John already pointed out, emails in the spools can hang around for days. I believe most MTA's only discard completely after 7days of non delivery.
That default setting is no longer applicable today. Users will scream if they find out that their mails have been sitting in the queue for a day.
Mail will wait with a delay if there is a problem with the remote end receiving the emails. Users will screan much more if they find that their emails are just going into /dev/null and they are having to work the retry mechanism by hand rather than their email server. Besides, if I send an email at 2am and there was a network outage at the remote end, its nice to know that
For today's businesses, one day can make or break a deal and so email, being a much faster form of communication than snail mail, has come to be seen as the preferred choice. People start calling when they know they are supposed to get an email in a minute or so when it does materialize.
Your point is well made, however - email does normally go in a single stream. Its when there is a problem and a retry mechanism hasto kick in that there is a problem. Its only the crazy goons who develop MS Exchange who havent got their head around this problem, something solved by the general internet users about 25 years back.
He is welcome to replicate the queue. His traffic levels will be so low that it really does not affect things but if he is using qmail I hope that the filesystem is completely identical on the secondary.
I personally hate qmail, its place is back in the 1990's - perhaps in the 1980's. But that is a pure personal opinion. I know there are plenty of people, some whom I even respect technically, who still use it :/
Also, you seem confused about the filesystem on the secondary. Its not a different filesystem - its the same shared block device exposed to both machines. if the primary fails, its the same system that the secondy see's when its made live. the DRBD packages are included in CentOS - you should give it a try. One easy way to do this is setup 2 VM's and have a play there. its quite cool.
Karanbir Singh wrote:
Christopher Chan wrote:
I am sorry but I do not share that view for incoming mail. The latency in getting the mail replicated probably is longer than it takes to do the actually delivery to the mail store.
I am not sure what you mean by the word 'replication' but in most cases the user mail stores are on the same shared block device. And I've worked with an ISP recently that deliver between 12 to 16 million emails per day and dont have this problem of 'latency in replication'. Using exim and cyrus-imapd over 2 user facing nodes.
I thought we were talking about the queues? I agree and did say that the mail store should be on a distributed filesystem.
Besides, as John already pointed out, emails in the spools can hang around for days. I believe most MTA's only discard completely after 7days of non delivery.
That default setting is no longer applicable today. Users will scream if they find out that their mails have been sitting in the queue for a day.
Mail will wait with a delay if there is a problem with the remote end receiving the emails. Users will screan much more if they find that their emails are just going into /dev/null and they are having to work the retry mechanism by hand rather than their email server. Besides, if I send an email at 2am and there was a network outage at the remote end, its nice to know that
Some people would rather be informed that their email was not delivered within the hour and I do not see how not putting the queue on a shared network block device would lead to emails going into /dev/null. Obviously I would recommend at least raid1 for the local block device.
For today's businesses, one day can make or break a deal and so email, being a much faster form of communication than snail mail, has come to be seen as the preferred choice. People start calling when they know they are supposed to get an email in a minute or so when it does materialize.
Your point is well made, however - email does normally go in a single stream. Its when there is a problem and a retry mechanism hasto kick in that there is a problem. Its only the crazy goons who develop MS Exchange who havent got their head around this problem, something solved by the general internet users about 25 years back.
You have lost me here. Besides the shoddy implementation of Exchange, especially in earlier versions, what about Exchange and its retry mechanism?
He is welcome to replicate the queue. His traffic levels will be so low that it really does not affect things but if he is using qmail I hope that the filesystem is completely identical on the secondary.
I personally hate qmail, its place is back in the 1990's - perhaps in the 1980's. But that is a pure personal opinion. I know there are plenty of people, some whom I even respect technically, who still use it :/
Yeah, I would not put an unpatched qmail on a MX nor do I feel like patching one. I use postfix with vpopmail instead notwithstanding vpopmailś deep links with qmail.
Also, you seem confused about the filesystem on the secondary. Its not a different filesystem - its the same shared block device exposed to both machines. if the primary fails, its the same system that the secondy see's when its made live. the DRBD packages are included in CentOS - you should give it a try. One easy way to do this is setup 2 VM's and have a play there. its quite cool.
Okay, Les helped me with that one. RAID1 on the network. So you would have to use GFS or something like that with it and have the service down on the secondary unless it was sendmail you were running. Pretty much what I said except that I was not too sure with how DRBD works since I have heard about stuff like this that replicated on the hour or something.
Christopher Chan wrote:
Okay, Les helped me with that one. RAID1 on the network. So you would have to use GFS or something like that with it and have the service down on the secondary unless it was sendmail you were running.
No and yes. You can just use ext3 on both nodes as you normally only have the one on the primary node mounted - the other one is not accessed by anything. And yes, with heartbeat you "just" failover to the second node, if the first one is dead. That will start the needed services on the second node.
Ralph
Ralph Angenendt wrote:
Christopher Chan wrote:
Okay, Les helped me with that one. RAID1 on the network. So you would have to use GFS or something like that with it and have the service down on the secondary unless it was sendmail you were running.
No and yes. You can just use ext3 on both nodes as you normally only have the one on the primary node mounted - the other one is not accessed by anything. And yes, with heartbeat you "just" failover to the second node, if the first one is dead. That will start the needed services on the second node.
Are you positive that you can put ext3 on it and have it mounted on the secondary while the primary is happily hammering away without any ill effects? Have you done it?
Christopher Chan wrote:
Ralph Angenendt wrote:
Christopher Chan wrote:
Okay, Les helped me with that one. RAID1 on the network. So you would have to use GFS or something like that with it and have the service down on the secondary unless it was sendmail you were running.
No and yes. You can just use ext3 on both nodes as you normally only have the one on the primary node mounted - the other one is not accessed by anything. And yes, with heartbeat you "just" failover to the second node, if the first one is dead. That will start the needed services on the second node.
Are you positive that you can put ext3 on it and have it mounted on the secondary while the primary is happily hammering away without any ill effects? Have you done it?
Sorry, I did not read your mail through properly. Not mounted on the secondary, okay. Anyway, quite a fair bit off complexity there in making sure the network block device does not get mounted by both boxes at the same time.
Is it really worth the complexity when you can have both servers online running off their own disks for the mail queue without having to worry about the other guy? If the primary is so badly whatever that a queue on mirrored disks cannot be brought back online with a simple reboot, what chances are there that the network block device won't be a victim of the whatever and mess up the queue so that the secondary cannot use it?
Christopher Chan wrote:
Sorry, I did not read your mail through properly. Not mounted on the secondary, okay. Anyway, quite a fair bit off complexity there in making sure the network block device does not get mounted by both boxes at the same time.
Is it really worth the complexity when you can have both servers online running off their own disks for the mail queue without having to worry about the other guy? If the primary is so badly whatever that a queue on mirrored disks cannot be brought back online with a simple reboot, what chances are there that the network block device won't be a victim of the whatever and mess up the queue so that the secondary cannot use it?
That's generally my reasoning in thinking that simple raid1 mirrors on the primary with swappable disks and a spare powered-off chassis are probably more robust. You do need someone on-site capable of swapping the disks if you have a motherboard/power supply failure but with server-class equipment and a good UPS those are pretty rare. You also need additional backups, since an operator or software error could take out your online filesystem including the mirrored side.
Christopher Chan wrote:
Ralph Angenendt wrote:
No and yes. You can just use ext3 on both nodes as you normally only have the one on the primary node mounted - the other one is not accessed by anything. And yes, with heartbeat you "just" failover to the second node, if the first one is dead. That will start the needed services on the second node.
Are you positive that you can put ext3 on it and have it mounted on the secondary while the primary is happily hammering away without any ill effects? Have you done it?
No, you do *not* mount it on the secondary while the primary is happily hammering away. heartbeat takes care of mounting and of the secondary becoming primary in case of a failover.
There are primary/primary setups possible with drbd and gfs if you need both nodes to be exported at the same time - but that's not needed nor recommended in a failover situation.
Ralph
Ralph Angenendt wrote:
Christopher Chan wrote:
Ralph Angenendt wrote:
No and yes. You can just use ext3 on both nodes as you normally only have the one on the primary node mounted - the other one is not accessed by anything. And yes, with heartbeat you "just" failover to the second node, if the first one is dead. That will start the needed services on the second node.
Are you positive that you can put ext3 on it and have it mounted on the secondary while the primary is happily hammering away without any ill effects? Have you done it?
No, you do *not* mount it on the secondary while the primary is happily hammering away. heartbeat takes care of mounting and of the secondary becoming primary in case of a failover.
Yes, I am sorry, I did not read your mail through. Heartbeat takes care of the mounting eh?
There are primary/primary setups possible with drbd and gfs if you need both nodes to be exported at the same time - but that's not needed nor recommended in a failover situation.
Why would it not be recommended for a failover situation?
Christopher Chan wrote:
Ralph Angenendt wrote:
There are primary/primary setups possible with drbd and gfs if you need both nodes to be exported at the same time - but that's not needed nor recommended in a failover situation.
Why would it not be recommended for a failover situation?
Because it would be shooting cannons at birds in this particular case. If you need to expose both nodes "to the public" all the time, you probably also run the software on both nodes - which would be more of a cluster than a failover setup >:)
Cheers,
Ralph
Ralph Angenendt wrote:
Christopher Chan wrote:
Ralph Angenendt wrote:
There are primary/primary setups possible with drbd and gfs if you need both nodes to be exported at the same time - but that's not needed nor recommended in a failover situation.
Why would it not be recommended for a failover situation?
Because it would be shooting cannons at birds in this particular case. If you need to expose both nodes "to the public" all the time, you probably also run the software on both nodes - which would be more of a cluster than a failover setup >:)
Cheers,
Ralph
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
But, a cluster in itself is fail over :) If either node is dead, the cluster is still up
Rudi Ahlers wrote:
Ralph Angenendt wrote:
Because it would be shooting cannons at birds in this particular case. If you need to expose both nodes "to the public" all the time, you probably also run the software on both nodes - which would be more of a cluster than a failover setup >:)
But, a cluster in itself is fail over :) If either node is dead, the cluster is still up
I really wouldn't always count on that >:)
Cheers,
Ralph
On Sun, 2008-05-18 at 23:50 +0100, Karanbir Singh wrote:
Christopher Chan wrote:
<snip>
Besides, as John already pointed out, emails in the spools can hang around for days. I believe most MTA's only discard completely after 7days of non delivery.
That default setting is no longer applicable today. Users will scream if they find out that their mails have been sitting in the queue for a day.
Mail will wait with a delay if there is a problem with the remote end receiving the emails. Users will screan much more if they find that their emails are just going into /dev/null and they are having to work the retry mechanism by hand rather than their email server. Besides, if I send an email at 2am and there was a network outage at the remote end, its nice to know that
For today's businesses, one day can make or break a deal and so email, being a much faster form of communication than snail mail, has come to be seen as the preferred choice. People start calling when they know they are supposed to get an email in a minute or so when it does materialize.
Your point is well made, however - email does normally go in a single stream. Its when there is a problem and a retry mechanism hasto kick in that there is a problem. Its only the crazy goons who develop MS Exchange who havent got their head around this problem, something solved by the general internet users about 25 years back.
Only as a bit of interesting (to me) FYI: actually when we were using uucp for mail prior to the widespread deployment of the internet, this was solved in the same way it is now. I worked for Western Electric at the time and made a presentation to DARPA down at the U of Georgia demonstrating how interactive terminal-to-terminal communication and inter-node mail could be facilitated using UNIX (R).
Needless to say, there were some very bright folks there. We began hearing about something called "internet" that would be coming on the scene. First application was for defense. Then it spread to colleges and universities.
I must have shipped out 200-300 UNIX (R) distributions on tape (the big ones) to colleges and government organizations in the next year. And volume kept growing.
Anyway, the point is that the problem was solved in the 1978 - 1979 time frame. So its at least 30 years.
<snip>
Christopher Chan wrote:
That default setting is no longer applicable today. Users will scream if they find out that their mails have been sitting in the queue for a day. For today's businesses, one day can make or break a deal and so email, being a much faster form of communication than snail mail, has come to be seen as the preferred choice. People start calling when they know they are supposed to get an email in a minute or so when it does materialize.
So you never send any email to anyone using greylisting? thats odd, as its very common nowdays. greylisting servers will auto-reject the first attempt at sending an email, then accept it on a later retry (typically 10 or 15 minutes is the default retry interval for most mail servers). This /guarantees/ email will sit in your outbound queue for at least one retry interval.
I frequently run into outbound mail that sits in my queues for several hours, the destination servers may be too busy, or they may be offline for maintenance, many reasons. There's a k12 school district up in Chico CA who's mail server seems to be down as often as its up, and there are several folks on that server who subscribe to various email lists I host. the mail gets through eventually.
Email is /NOT/ IM. If your users expect it to function like Instant Messaging, maybe you should suggest they use IM when they want immediate response with feedback.
John R Pierce wrote:
Christopher Chan wrote:
That default setting is no longer applicable today. Users will scream if they find out that their mails have been sitting in the queue for a day. For today's businesses, one day can make or break a deal and so email, being a much faster form of communication than snail mail, has come to be seen as the preferred choice. People start calling when they know they are supposed to get an email in a minute or so when it does materialize.
So you never send any email to anyone using greylisting? thats odd, as its very common nowdays. greylisting servers will auto-reject the first attempt at sending an email, then accept it on a later retry (typically 10 or 15 minutes is the default retry interval for most mail servers). This /guarantees/ email will sit in your outbound queue for at least one retry interval.
Yes, so I get to tell the users, sorry, Yahoo is up to its antics again. Maybe it will go through in an hour. What advantage would I have in putting the queue on a distributed filesystem if I have to ensure that the MTAs do not try to both access the queue if they are not sendmail versus the simplicity of a local mirrored disk setup for the queue?
I frequently run into outbound mail that sits in my queues for several hours, the destination servers may be too busy, or they may be offline for maintenance, many reasons. There's a k12 school district up in Chico CA who's mail server seems to be down as often as its up, and there are several folks on that server who subscribe to various email lists I host. the mail gets through eventually.
Do you put your outbound mail queue on a distributed filesystem?
Email is /NOT/ IM. If your users expect it to function like Instant Messaging, maybe you should suggest they use IM when they want immediate response with feedback.
I am not going to make an issue of their expectations and make them use something that is not necessarily available or allowed. Email + attachments is not quite the same as IM + File Transfers
John R Pierce wrote:
Rudi Ahlers wrote:
Sorry guys, I want to stick with a SMTP / IMAP / POP3 server, not webmail. I'll be using Horde for webmail as well though
there are two general classes of clustered systems, high availability, and high performance.
HA clusters are usually active/standby, and might use stuff like heartbeat, drbd, etc.
HP clusters are either load balanced, or active/active... Things that demand ACID (Atomicity, Consistency, Isolation, Durability) like databases, mail servers are very complex to cluster this way on a active/active (aka multimaster) environment while maintaining the integrity and a reasonable performance. just implementing load balancing does not by itself provide any redundancy in case of component failure. A simple load balancing scenario for a mail server might be having one server to handle all internet mail incoming and outgoing, while another server handles local users reading their mail (eg, pop or imap)
its best to define your requirements and expectations before diving into these waters, as clusters can be far more complex and intricate to configure and administrate than discrete systems.
re: mail servers specifically, there are two seperate classes of storage that would need replication... One is the mail spools and queues as used by the MTA (postfix, sendmail, etc), and the other are the user mail folder(s) as used by the local delivery agent (procmail or whattever), and read by the mail client (pop, imap).
Ok, I see where you're going, and a bit of clarification is needed :)
I need a simple failover type cluster, where any 1 of the 2 machines currently in the "cluster" can handle anything. The client (a small rural clinic) is 700KM's away, and they do have frequent power failures, so bad that even the UPS' lifespan has shorten. This is a donated project, so funds (and hence equipment / reliable equipment) is limited. We currently have 2servers with Dual Core PIV + 2GB RAM + 2x 160GB HDD's each. The HDD's is setup on RAID1, and the two servers replicate MySQL on an active/active (Master - Master) replication. The intranet site & file server data is being replicated via rsync. This all works well, but I need a mail server.
The main server will store all the emails (like an exchange server does), the users will use IMAP (so, a) it's backed up & b) they can always access their email from any workstation) & SMTP, with the ability to use POP3 from home / on the road. It would be nice to have a shared calendar & address book as well, so something like phpgroupware / open exchange / etc would be nice.
But, I don't need load balancing, just high availability
Rudi Ahlers wrote:
You might take a look at SquirrelMail. It integrates well with cyrus imap.
I've started liking roundcube a bit more than squirrelmail. but roundcube is very basic. SquirrelMail has a *LOT* of plugins and can be made to do almost anything these days. And the community around squirrelmail is much larger than roundcube.
Another candidate is Horde+IMP ( which Johnny maintains in the centos repos )
Sorry guys, I want to stick with a SMTP / IMAP / POP3 server, not webmail. I'll be using Horde for webmail as well though
Webmail normally just uses the underlying smtp/imap access to the underlying server anyway. If you want something that comes up running with samba, web/ftp services and email with optional web interface you might like SME server (http://www.contribs.org) which has Centos packages plus a simple web administration interface. I'm not sure if it can be set up with drbd/failover but I've always had pretty good luck running software RAID on swappable disks that can be moved to a different chassis in the event of a motherboard or power supply failure.
Les Mikesell wrote:
Rudi Ahlers wrote:
You might take a look at SquirrelMail. It integrates well with cyrus imap.
I've started liking roundcube a bit more than squirrelmail. but roundcube is very basic. SquirrelMail has a *LOT* of plugins and can be made to do almost anything these days. And the community around squirrelmail is much larger than roundcube.
Another candidate is Horde+IMP ( which Johnny maintains in the centos repos )
Sorry guys, I want to stick with a SMTP / IMAP / POP3 server, not webmail. I'll be using Horde for webmail as well though
Webmail normally just uses the underlying smtp/imap access to the underlying server anyway. If you want something that comes up running with samba, web/ftp services and email with optional web interface you might like SME server (http://www.contribs.org) which has Centos packages plus a simple web administration interface. I'm not sure if it can be set up with drbd/failover but I've always had pretty good luck running software RAID on swappable disks that can be moved to a different chassis in the event of a motherboard or power supply failure.
We do use SME 7.3 already, and they have done a great job in getting all the common network services (SQL, Apache, FTP, Samba, POP3, SMTP, IMAP, VPN, etc) working out-of-the-box, but it doesn't support fail-over / clustering, and it's very "proprietary" - a lot of things can't just be changed the way a standard Linux server can be, without affecting the upgrades.
On Sat, 2008-05-17 at 19:23 +0100, Karanbir Singh wrote:
I've started liking roundcube a bit more than squirrelmail. but roundcube is very basic. SquirrelMail has a *LOT* of plugins and can be made to do almost anything these days. And the community around squirrelmail is much larger than roundcube.
I recently started using RoundCube, and I like it primarily because it has an awesome interface (compared to other web mail options in F/OSS world).
I agree that SquirrelMail is still much more functional. With so many plugins, users and better support, it's just about always the best option.
Having said that, I'm going to stick with RoundCube. If SquirrelMail ever gets a total interface overhaul, I'll most likely go back to it.
Regards,
Ranbir
David G. Mackay wrote:
On Sat, 2008-05-17 at 10:30 +0200, Rudi Ahlers wrote:
Thank you for your input. I can't justify exchange (and don't want MS) for 10 users. I do want IMAP though, and the calendar & address book would be nice. This IMO has nothing todo with CentOS though, but at the same time it shouldn't be limited to which Linux distro I'm using. As you have said I may need to look at file system clustering instead, but have never attempted it, so I don't know where to begin even. I know a lot of MTA's can support a central user DB, but that won't sync the emails. And this won't be a commercial installation either, it's for a for a project in a rural community about 700km's from me, so it's more a matter of if 1 server dies / crashes / packes up, and I can only get to it 5 days later, the mail server still works :)
You might take a look at SquirrelMail. It integrates well with cyrus imap.
Dave
I'm not sure why nobody has asked this yet, but why not try hosted GMail instead? It's free and you can use it with your domain name. We currently run a linux based mail server, but are thinking of migrating over to hosted GMail, and have one so for a few clients already with no problems.
Russ
Ruslan Sivak wrote:
David G. Mackay wrote:
On Sat, 2008-05-17 at 10:30 +0200, Rudi Ahlers wrote:
Thank you for your input. I can't justify exchange (and don't want MS) for 10 users. I do want IMAP though, and the calendar & address book would be nice. This IMO has nothing todo with CentOS though, but at the same time it shouldn't be limited to which Linux distro I'm using. As you have said I may need to look at file system clustering instead, but have never attempted it, so I don't know where to begin even. I know a lot of MTA's can support a central user DB, but that won't sync the emails. And this won't be a commercial installation either, it's for a for a project in a rural community about 700km's from me, so it's more a matter of if 1 server dies / crashes / packes up, and I can only get to it 5 days later, the mail server still works :)
You might take a look at SquirrelMail. It integrates well with cyrus imap.
Dave
I'm not sure why nobody has asked this yet, but why not try hosted GMail instead? It's free and you can use it with your domain name. We currently run a linux based mail server, but are thinking of migrating over to hosted GMail, and have one so for a few clients already with no problems.
Russ _______________________________________________
Simple, you need to be connected to the internet 24/7 to use something like hosted gmail :) Not everyone has 24/7 broadband internet
Rudi Ahlers wrote:
Simple, you need to be connected to the internet 24/7 to use something like hosted gmail :) Not everyone has 24/7 broadband internet
your mail server would need to be connected 24/7 to recieve mail anyways.
and, you can use gmail with POP or IMAP, and with many IMAP clients you can have local copies of your imap folders that synchronize on connect (and of course all POP clients do this anyways)
Ruslan Sivak wrote:
David G. Mackay wrote: I'm not sure why nobody has asked this yet, but why not try hosted GMail instead? It's free and you can use it with your domain name. We currently run a linux based mail server, but are thinking of migrating over to hosted GMail, and have one so for a few clients already with no problems.
Russ
Well, i just hope you don't have anything secret or sensitive... With their "search power", it's very easy to automate the info harvesting!
I'm not saying they do it, but they surely have the technology.
Guy Boisvert, ing. IngTegration inc.
On Sun, 18 May 2008, Guy Boisvert wrote:
Ruslan Sivak wrote:
David G. Mackay wrote: I'm not sure why nobody has asked this yet, but why not try hosted GMail instead? It's free and you can use it with your domain name. We currently run a linux based mail server, but are thinking of migrating over to hosted GMail, and have one so for a few clients already with no problems.
Russ
Well, i just hope you don't have anything secret or sensitive... With their "search power", it's very easy to automate the info harvesting!
If you are sending secret or sensitive information via unencrypted email you already have a bigger problem then weather or not google is harvesting info. Email by design is insecure. Why anyone would believe otherwise is unclear to me. If you are encrypting it than I would argue that it does not matter if google tries to harvest information from it.
Regards,
Tom Diehl tdiehl@rogueind.com Spamtrap address mtd123@rogueind.com
Tom Diehl wrote:
On Sun, 18 May 2008, Guy Boisvert wrote:
Well, i just hope you don't have anything secret or sensitive... With their "search power", it's very easy to automate the info harvesting!
If you are sending secret or sensitive information via unencrypted email you already have a bigger problem then weather or not google is harvesting info. Email by design is insecure. Why anyone would believe otherwise is unclear to me. If you are encrypting it than I would argue that it does not matter if google tries to harvest information from it.
Regards,
Tom Diehl tdiehl@rogueind.com Spamtrap address
Good point. Does Google supports encryption?
On top of that, "Echelon" is listening... As for unencrypted emails, it's child play.
Guy Boisvert, ing. IngTegration inc.
Guy Boisvert wrote:
Good point. Does Google supports encryption?
On top of that, "Echelon" is listening... As for unencrypted emails, it's child play.
Guy Boisvert, ing. IngTegration inc.
They have pretty good information available on the various versions you can use.
http://www.google.com/a/help/intl/en/var_1a.html
But of course, if you want all the bells and whistles to go along with it, you have to purchase the premier edition.
-Ross-
On Mon, May 19, 2008 at 1:15 AM, Guy Boisvert boisvert.guy@videotron.ca wrote:
Good point. Does Google supports encryption?
On top of that, "Echelon" is listening... As for unencrypted emails, it's child play.
A couple of points.
1) Regardless of whether or not Google can look into people's emails, it should be pointed out that the same could be said of so can many ISPs and specialised email hosting providers from whom people have their email hosted. I understand that Google deploys some form of encrypted filesystem for Gmail's store, but couldn't tell you much beyond that.
You want your mail store to be secure - host it yourself and apply whatever encryption methods you see fit.
2) There is a plug-in for Firefox which will give your GPG capabilities with Gmail:
http://www.instructables.com/id/Encrypt-your-Gmail-Email/
On Sun, 18 May 2008, Tom Diehl wrote:
If you are sending secret or sensitive information via unencrypted email you already have a bigger problem then weather or not google is harvesting info. Email by design is insecure. Why anyone would believe otherwise is unclear to me. If you are encrypting it than I would argue that it does not matter if google tries to harvest information from it.
There's data and then there's metadata. The former, as you note, can be protected via standard encryption techniques. The latter -- e.g., who sent messages to whom and when -- might be just as important, and it's not possible to encrypt.
on 5-18-2008 3:17 PM Tom Diehl spake the following:
On Sun, 18 May 2008, Guy Boisvert wrote:
Ruslan Sivak wrote:
David G. Mackay wrote: I'm not sure why nobody has asked this yet, but why not try hosted GMail instead? It's free and you can use it with your domain name. We currently run a linux based mail server, but are thinking of migrating over to hosted GMail, and have one so for a few clients already with no problems.
Russ
Well, i just hope you don't have anything secret or sensitive... With their "search power", it's very easy to automate the info harvesting!
If you are sending secret or sensitive information via unencrypted email you already have a bigger problem then weather or not google is harvesting info. Email by design is insecure. Why anyone would believe otherwise is unclear to me. If you are encrypting it than I would argue that it does not matter if google tries to harvest information from it.
I think I would be more afraid of them selling my contact list to spammers along with every one else's. If the profits get low enough, almost any corporation could stoop this low to make the stockholders happy.
It works fine with Dovecot also.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of David G. Mackay Sent: Saturday, May 17, 2008 10:05 AM To: CentOS mailing list Subject: Re: [CentOS] clustered mail server?
On Sat, 2008-05-17 at 10:30 +0200, Rudi Ahlers wrote:
Thank you for your input. I can't justify exchange (and don't want MS) for 10 users. I do want IMAP though, and the calendar & address book would be nice. This IMO has nothing todo with CentOS though, but at the same time it shouldn't be limited to which Linux distro I'm using. As you have said I may need to look at file system clustering instead, but have never attempted it, so I don't know where to begin even. I know a lot of MTA's can support a central user DB, but that won't sync the emails. And this won't be a commercial installation either, it's for a for a project in a rural community about 700km's from me, so it's more a matter of if 1 server dies / crashes / packes up, and I can only get to it 5 days later, the mail server still works :)
You might take a look at SquirrelMail. It integrates well with cyrus imap.
Dave
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-
Christopher Chan -
David G. Mackay -
Guy Boisvert -
John R Pierce -
Johnny Hughes -
Jure Pečar -
Kanwar Ranbir Sandhu -
Karanbir Singh -
Les Mikesell -
Martyn Drake -
Michael Peterson -
Paul Heinlein -
Ralph Angenendt -
Ross Cavanagh -
Rudi Ahlers -
Ruslan Sivak -
Scott Silva -
Tom Diehl -
William L. Maltby