Hello,
I'm planning the installation of the school's Mail Server. This is the first time I get in administration. I've been reading about postfix, cyrus and the first page in the guide of HughesJR.com[2] about installing postfix-cyrus, but due my low hardware resources, I ask for suggestions to see If what I need can be done (and|or) stable.
Hardware: Pentium III 1.4Ghz 256 RAM 40 GB HD-IDE
Soft: CentOS 4.2 Postfix Cyrus-IMAPd MailScanner Spanassassin
Partitioning(in MB)[1]: / 1.000 /boot/ 100 /home/ 15.000 /swap/ 512 /tmp/ 500 /usr/ 1.000 /var/ 5.000 /var/log/ 2.000 /var/spool/mail/ 14.800
The server will serve around 2000 students, but only 80(maybe 100) concurrent at time. I would like to make a very basic installation, 'cause as you can see, I am with a very low hardware resources. This host will be mail dedicated.
In the near future the hard would be upgraded(maybe a nu computer). Now, I need something to show in a working environment.
I'll appreciate any suggestion.
I've never been involved in this. I used to program with php, but now, it has been delegated :| to me (chosen between other tasks).
Some orientation (and|or) readings will be great too, even while, I'll continue reading about partitioning[3] (think my first step).
thanks in advanced for your time.
[1] http://www.linuxsa.org.au/tips/disk-partitioning.html [2] http://www.hughesjr.com/content/view/9/30/Guides [3] http://www.tldp.org/HOWTO/Partition/intro.html
On Mon, 2005-12-05 at 21:26 -0500, Alain Reguera wrote:
Hello,
I'm planning the installation of the school's Mail Server. This is the first time I get in administration. I've been reading about postfix, cyrus and the first page in the guide of HughesJR.com[2] about installing postfix-cyrus, but due my low hardware resources, I ask for suggestions to see If what I need can be done (and|or) stable.
Hardware: Pentium III 1.4Ghz 256 RAM 40 GB HD-IDE
Soft: CentOS 4.2 Postfix Cyrus-IMAPd MailScanner Spanassassin
Partitioning(in MB)[1]: / 1.000 /boot/ 100 /home/ 15.000 /swap/ 512 /tmp/ 500 /usr/ 1.000 /var/ 5.000 /var/log/ 2.000 /var/spool/mail/ 14.800
The server will serve around 2000 students, but only 80(maybe 100) concurrent at time. I would like to make a very basic installation, 'cause as you can see, I am with a very low hardware resources. This host will be mail dedicated.
In the near future the hard would be upgraded(maybe a nu computer). Now, I need something to show in a working environment.
I'll appreciate any suggestion.
I've never been involved in this. I used to program with php, but now, it has been delegated :| to me (chosen between other tasks).
Some orientation (and|or) readings will be great too, even while, I'll continue reading about partitioning[3] (think my first step).
thanks in advanced for your time.
[1] http://www.linuxsa.org.au/tips/disk-partitioning.html [2] http://www.hughesjr.com/content/view/9/30/Guides [3] http://www.tldp.org/HOWTO/Partition/intro.html
---- looks good but /usr is way too small. /usr is gonna need probably more like 3.5 Gigabytes
Suggest you consider having separate partitions for /boot /home /tmp /var/spool/imap # cyrus would default to this swap and combine the rest in / which allows fluctuation for /usr and /var usage - perhaps maybe 8 gigabytes.
Craig
Alain Reguera wrote:
Hello,
I'm planning the installation of the school's Mail Server. This is the first time I get in administration. I've been reading about postfix, cyrus and the first page in the guide of HughesJR.com[2] about installing postfix-cyrus, but due my low hardware resources, I ask for suggestions to see If what I need can be done (and|or) stable.
Hardware: Pentium III 1.4Ghz 256 RAM 40 GB HD-IDE
Soft: CentOS 4.2 Postfix Cyrus-IMAPd MailScanner Spanassassin
Partitioning(in MB)[1]: / 1.000 /boot/ 100 /home/ 15.000 /swap/ 512 /tmp/ 500 /usr/ 1.000 /var/ 5.000 /var/log/ 2.000 /var/spool/mail/ 14.800
The server will serve around 2000 students, but only 80(maybe 100) concurrent at time. I would like to make a very basic installation, 'cause as you can see, I am with a very low hardware resources. This host will be mail dedicated.
In the near future the hard would be upgraded(maybe a nu computer). Now, I need something to show in a working environment.
That is PLENTY fast enough to run the mail server that Johnny talks about in his web pages as long as people have relatively small mailbox quotas. One change would be to add more memory to the machine if you can (memory is cheap these days so that might not even be an issue). I'd suggest a gig of RAM and a gig of swap. IDE disks are also cheap so it might be better to upgrade it to something like a 300 or 400gig drive now than to wait until you run out of space in the very near future.
Cheers,
Chris Mauritz wrote:
Alain Reguera wrote:
Hello,
I'm planning the installation of the school's Mail Server. This is the first time I get in administration. I've been reading about postfix, cyrus and the first page in the guide of HughesJR.com[2] about installing postfix-cyrus, but due my low hardware resources, I ask for suggestions to see If what I need can be done (and|or) stable.
Hardware: Pentium III 1.4Ghz 256 RAM 40 GB HD-IDE
Soft: CentOS 4.2 Postfix Cyrus-IMAPd MailScanner Spanassassin
Partitioning(in MB)[1]: / 1.000 /boot/ 100 /home/ 15.000 /swap/ 512 /tmp/ 500 /usr/ 1.000 /var/ 5.000 /var/log/ 2.000 /var/spool/mail/ 14.800
The server will serve around 2000 students, but only 80(maybe 100) concurrent at time. I would like to make a very basic installation, 'cause as you can see, I am with a very low hardware resources. This host will be mail dedicated.
In the near future the hard would be upgraded(maybe a nu computer). Now, I need something to show in a working environment.
That is PLENTY fast enough to run the mail server that Johnny talks about in his web pages as long as people have relatively small mailbox quotas. One change would be to add more memory to the machine if you can (memory is cheap these days so that might not even be an issue). I'd suggest a gig of RAM and a gig of swap. IDE disks are also cheap so it might be better to upgrade it to something like a 300 or 400gig drive now than to wait until you run out of space in the very near future.
Cheers,
If you could afford *1* extra HDD (NewEgg, 250 GB EIDE 133 Samsung, ~$104.00 shipped), you could put /home there, & use the 40 GB as your system disk only, with:
/boot 100 MB /var 10 GB swap 2 GB / the rest
or even
/var 10 GB swap 2 GB / the rest
for a no-virtual-partition (nomenclature ?) solution.
soft-link /tmp to /var/tmp & you're off to the races .... $0.02 only, no more, no less :-).
Chris Mauritz wrote:
I'd suggest a gig of RAM and a gig of swap. IDE disks are also cheap so it might be better to upgrade it to something like a 300 or 400gig drive now than to wait until you run out of space in the very near future.
Speaking of future disk expansions. It might be smart move to place all file systems (or at least /var/spool/imap) under LVM. That way he can simply add new disks into volume group, assign additional space to logical volume where /var/spool/imap file system resides, and resize file system to the new size of logical volume. The only downtime would be to physically attach new disk(s). Everything after that can be performed while the system is up and running (and users are using it).
On Tue, 6 Dec 2005, Aleksandar Milivojevic wrote:
Chris Mauritz wrote:
I'd suggest a gig of RAM and a gig of swap. IDE disks are also cheap so it might be better to upgrade it to something like a 300 or 400gig drive now than to wait until you run out of space in the very near future.
Speaking of future disk expansions. It might be smart move to place all file systems (or at least /var/spool/imap) under LVM. That way he can simply add new disks into volume group, assign additional space to logical volume where /var/spool/imap file system resides, and resize file system to the new size of logical volume. The only downtime would be to physically attach new disk(s). Everything after that can be performed while the system is up and running (and users are using it).
I agree. I would use openfiler and have two front end servers mounting the disk over NFS. This means you will have to run courier imap.
It is much easier to work with a cluster of NFS mail servers rather than dealing with the complexity of a murder of cyrus servers.
On Tue, 2005-12-06 at 22:37, Robin Mordasiewicz wrote:
Speaking of future disk expansions. It might be smart move to place all file systems (or at least /var/spool/imap) under LVM. That way he can simply add new disks into volume group, assign additional space to logical volume where /var/spool/imap file system resides, and resize file system to the new size of logical volume. The only downtime would be to physically attach new disk(s). Everything after that can be performed while the system is up and running (and users are using it).
I agree. I would use openfiler and have two front end servers mounting the disk over NFS. This means you will have to run courier imap.
No, it just means you need to use maildir format which qmail uses natively and the other transports can do via procmail. Dovecot can use it on the imap side.
I agree. I would use openfiler and have two front end servers mounting the disk over NFS. This means you will have to run courier imap.
No, it just means you need to use maildir format which qmail uses natively and the other transports can do via procmail. Dovecot can use it on the imap side.
or maildrop :P
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, Dec 05, 2005 at 09:26:04PM -0500, Alain Reguera wrote:
Hello,
I'm planning the installation of the school's Mail Server. This is the first time I get in administration. I've been reading about postfix, cyrus and the first page in the guide of HughesJR.com[2] about installing postfix-cyrus, but due my low hardware resources, I ask for suggestions to see If what I need can be done (and|or) stable.
Hardware: Pentium III 1.4Ghz 256 RAM 40 GB HD-IDE
Soft: CentOS 4.2 Postfix Cyrus-IMAPd MailScanner Spanassassin
First off, dump either antivirus or antispam on that machine. You don't have enough memory to keep both happy.
A P3 1.4GHz is more than up to the task, so you will have no problem there.
You might also want to change Cyrus-imapd to something simpler, like wu-imapd, since it should take less resources from the machine. Then again, I have very little experience with cyrus, since I either use wu or courrier.
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On Tue, 2005-12-06 at 00:53 -0200, Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, Dec 05, 2005 at 09:26:04PM -0500, Alain Reguera wrote:
Hello,
I'm planning the installation of the school's Mail Server. This is the first time I get in administration. I've been reading about postfix, cyrus and the first page in the guide of HughesJR.com[2] about installing postfix-cyrus, but due my low hardware resources, I ask for suggestions to see If what I need can be done (and|or) stable.
Hardware: Pentium III 1.4Ghz 256 RAM 40 GB HD-IDE
Soft: CentOS 4.2 Postfix Cyrus-IMAPd MailScanner Spanassassin
First off, dump either antivirus or antispam on that machine. You don't have enough memory to keep both happy.
A P3 1.4GHz is more than up to the task, so you will have no problem there.
You might also want to change Cyrus-imapd to something simpler, like wu-imapd, since it should take less resources from the machine. Then again, I have very little experience with cyrus, since I either use wu or courrier.
Probably replace cyrus-imapd with dovecot
Rodrigo Barbosa wrote:
I'm planning the installation of the school's Mail Server. This is the first time I get in administration. I've been reading about postfix, cyrus and the first page in the guide of HughesJR.com[2] about installing postfix-cyrus, but due my low hardware resources, I ask for suggestions to see If what I need can be done (and|or) stable.
Hardware: Pentium III 1.4Ghz 256 RAM 40 GB HD-IDE
Soft: CentOS 4.2 Postfix Cyrus-IMAPd MailScanner Spanassassin
First off, dump either antivirus or antispam on that machine. You don't have enough memory to keep both happy.
How about using MailScanner ? and wrap that around clamav + spamassassin, you can run it with 2 - 4 threads on a machine with 256megs of ram, and since spamassassin runs via its perl interface locally ( and not via spamd ), it uses up no resources while its not running.
MailScanner might slow your inbound mail queue processing by a few seconds, but would allow you to better manage the resources you have on the machine ( and also implement any policy based email rules you might want to have )
A P3 1.4GHz is more than up to the task, so you will have no problem there.
You might also want to change Cyrus-imapd to something simpler, like wu-imapd, since it should take less resources from the machine. Then again, I have very little experience with cyrus, since I either use wu or courrier.
With 2000 users and 80+ concurrent users, you will find Cyrus performs faster with lower system resources than Wu-imap or Dovecot!
Also, on a machine with that setup, I'd have a Gig of Swap. And that 40GB hdd, i wonder how fast that runs :) might end up being the bottle neck in the equation.
- K
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, Dec 06, 2005 at 03:56:50AM +0000, Karanbir Singh wrote:
First off, dump either antivirus or antispam on that machine. You don't have enough memory to keep both happy.
How about using MailScanner ? and wrap that around clamav + spamassassin, you can run it with 2 - 4 threads on a machine with 256megs of ram, and since spamassassin runs via its perl interface locally ( and not via spamd ), it uses up no resources while its not running.
Yeah, that will work for a month or 2. After than, the bayesian database will start to get huge, and spamassassin will take a lot of time to start and use a lot of memory.
MailScanner might slow your inbound mail queue processing by a few seconds, but would allow you to better manage the resources you have on the machine ( and also implement any policy based email rules you might want to have )
After 2 months, on a 256M machine, spamassassin alone can slow a single e-mail by up to 2 minutes. Which can lead to a nice snowball issue.
A P3 1.4GHz is more than up to the task, so you will have no problem there.
You might also want to change Cyrus-imapd to something simpler, like wu-imapd, since it should take less resources from the machine. Then again, I have very little experience with cyrus, since I either use wu or courrier.
With 2000 users and 80+ concurrent users, you will find Cyrus performs faster with lower system resources than Wu-imap or Dovecot!
Also, on a machine with that setup, I'd have a Gig of Swap. And that 40GB hdd, i wonder how fast that runs :) might end up being the bottle neck in the equation.
The main tip would be to have the swap partition close to the middle of the disk, so you can reduce the disk head seek time. At least in theory, considering there is no sector realocation due to bad blocks.
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Rodrigo Barbosa wrote:
First off, dump either antivirus or antispam on that machine. You don't have enough memory to keep both happy.
How about using MailScanner ? and wrap that around clamav + spamassassin, you can run it with 2 - 4 threads on a machine with 256megs of ram, and since spamassassin runs via its perl interface locally ( and not via spamd ), it uses up no resources while its not running.
Yeah, that will work for a month or 2. After than, the bayesian database will start to get huge, and spamassassin will take a lot of time to start and use a lot of memory.
for a 2k user density, it would be a good idea to cycle bayes db every so often, only on a site with 2 - 5 people would you really expect the bayes db to have data that is months and months old :) too much poison in the wild these days.
another option is to turn off bayes completely, and just use URIBL's like surbl.org - in most cases the final result is almost as good as with bayes - with the advantage of near zero false positives.
MailScanner might slow your inbound mail queue processing by a few seconds, but would allow you to better manage the resources you have on the machine ( and also implement any policy based email rules you might want to have )
After 2 months, on a 256M machine, spamassassin alone can slow a single e-mail by up to 2 minutes. Which can lead to a nice snowball issue.
I setup mailscanning services for a network that has 1500 users, ( no storage, just inbound smtp, scan and forward ) with MailScanner, spamassassin, clamav, fprot and bitdeffender - on a P-3 1.4ghz with 196MB ram and a 120gig hdd. The machine handles the traffic just fine. Last time I checked, it was doing 17k - 21k emails per day.
Also, on a machine with that setup, I'd have a Gig of Swap. And that 40GB hdd, i wonder how fast that runs :) might end up being the bottle neck in the equation.
The main tip would be to have the swap partition close to the middle of the disk, so you can reduce the disk head seek time. At least in theory, considering there is no sector realocation due to bad blocks.
Thats an interesting point. Would help, I am sure.
- K
On 12/6/05, Karanbir Singh mail-lists@karan.org wrote:
Rodrigo Barbosa wrote:
The main tip would be to have the swap partition close to the middle of the disk, so you can reduce the disk head seek time. At least in theory, considering there is no sector realocation due to bad blocks.
Thats an interesting point. Would help, I am sure.
There is an old, well maybe ancient recommendation for keeping your swap on your least used drive, as far as data goes.
-- Leonard Isham, CISSP Ostendo non ostento.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, Dec 06, 2005 at 08:05:33AM -0500, Leonard Isham wrote:
The main tip would be to have the swap partition close to the middle of the disk, so you can reduce the disk head seek time. At least in theory, considering there is no sector realocation due to bad blocks.
Thats an interesting point. Would help, I am sure.
There is an old, well maybe ancient recommendation for keeping your swap on your least used drive, as far as data goes.
I know the rationalization behind that idea, of course, but I have to strongly disagree with it.
Disk head seek time is the real bad guy. Keeping the more often accessed areas at the center of the disk will give you performance improvements, specially with new disks.
Yes, putting the swap on the least used drive/area will potentialy increase the longevity of the disk media, but can cause the mechanical part of the disk (hello Maxtor!) to break earlier. In any case, disks on servers should be replaced each 2 years.
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On Mon, 2005-12-05 at 23:16, Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, Dec 06, 2005 at 03:56:50AM +0000, Karanbir Singh wrote:
First off, dump either antivirus or antispam on that machine. You don't have enough memory to keep both happy.
How about using MailScanner ? and wrap that around clamav + spamassassin, you can run it with 2 - 4 threads on a machine with 256megs of ram, and since spamassassin runs via its perl interface locally ( and not via spamd ), it uses up no resources while its not running.
Yeah, that will work for a month or 2. After than, the bayesian database will start to get huge, and spamassassin will take a lot of time to start and use a lot of memory.
So implement greylisting. Had one server that was getting swamped during particularly heavy spam storms. Setup greylisting and the box has not broken a sweat since.
You should be able to find greylisting options for most MTAs. I used milter-greylist with sendmail. Still kept spamassassin in the mix, it caught the few spam that got past greylisting.
Went from about 8000 spam a day down to 8 or 10 spam a day after implementing greylisting.
On Tue, 2005-12-06 at 07:56, Scot L. Harris wrote:
Yeah, that will work for a month or 2. After than, the bayesian database will start to get huge, and spamassassin will take a lot of time to start and use a lot of memory.
So implement greylisting. Had one server that was getting swamped during particularly heavy spam storms. Setup greylisting and the box has not broken a sweat since.
Also note that clamav runs faster than spamassassin, so run it first and discard viruses (don't reject - the sender is virtually always forged and you will just confuse some innocent party).
guys thanks for the fast replays
Then, restructuring the mail-box:
Hardware: Pentium III 1.4Ghz 256 RAM 40 GB HD-IDE
Soft: CentOS 4.2 Postfix (Cyrus-IMAPd|wu-imapd|courrier) MailScanner [moved] \ [1] Spanassassin [moved] /
Partitioning(in MB): / 8.000 /boot/ 100 swap 512 /home/ 14.888 /tmp/ 500 /var/spool/imap/ 2.000 # This could be as a Cyrus Swap, moreover of System Swap? /var/spool/mail/ 14.000
[1] To somewhere else where the mail box connect before sending and receiving mails to check for, or maybe another tricky configuration?. :)
A P3 1.4GHz is more than up to the task, so you will have no problem there. That is PLENTY fast enough to run the mail server that Johnny talks about in his web pages
very nice.. news :)
as long as people have relatively small mailbox quotas.
sure, I've read that cyrus implement this very well(I'll see the other ones). In this list recommend me to install it. So I continue with you guys.
One change would be to add more memory to the machine if you can (memory is cheap these days so that might not even be an issue).
yes. but I only have one dim slot on the motherboard, my knowledge about hardware make me feel the burning smelt of the other, when trying to set a 256mb memory. Now I care a lot the other one that is alive. :). I'll request for a 512mb ram to it.
Suggestions ------------------------------- - Increase RAM (preferly 1GB) - Increase HD (preferly 300 or 400gb) - Implement Quota (on IMAP Server) [2]
Please, any other suggestion (and|or) modification in the partitioning, will be welcome.
[2] http://lists.centos.org/pipermail/centos/2005-November/015538.html http://lists.centos.org/pipermail/centos/2005-November/015542.html http://lists.centos.org/pipermail/centos/2005-November/015548.html http://lists.centos.org/pipermail/centos/2005-November/015555.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, Dec 05, 2005 at 11:05:34PM -0500, Alain Reguera wrote:
(Cyrus-IMAPd|wu-imapd|courrier)
No courrier on that setup, please :)
MailScanner [moved] \ [1] Spanassassin [moved] /
Partitioning(in MB): / 8.000 /boot/ 100 swap 512 /home/ 14.888 /tmp/ 500 /var/spool/imap/ 2.000 # This could be as a Cyrus Swap, moreover of System Swap? /var/spool/mail/ 14.000
[1] To somewhere else where the mail box connect before sending and receiving mails to check for, or maybe another tricky configuration?. :)
Should not be that much of a problem. I would recomend keeping and av on the same machine. It should not give you that much trouble. Spamassassin, otoh, will start eating your resources in 1 to 2 months.
A P3 1.4GHz is more than up to the task, so you will have no problem there. That is PLENTY fast enough to run the mail server that Johnny talks about in his web pages
very nice.. news :)
Actually, for network servers, processing power is rarely an issue.
One change would be to add more memory to the machine if you can (memory is cheap these days so that might not even be an issue).
yes. but I only have one dim slot on the motherboard, my knowledge about hardware make me feel the burning smelt of the other, when trying to set a 256mb memory. Now I care a lot the other one that is alive. :). I'll request for a 512mb ram to it.
512mb should enable you to run without much trouble. 1G is an even better option since you plan on running spamassassin.
Suggestions
- Increase RAM (preferly 1GB)
- Increase HD (preferly 300 or 400gb)
- Implement Quota (on IMAP Server) [2]
Hummm, RAID-1 ? A backup unit ? Disable Imap and only keep pop3 ?
If you run courrier on maildir mode, you can use incremental backups, so a DLT tape (120G) should do the trick.
Please, any other suggestion (and|or) modification in the partitioning, will be welcome.
Try to keep the swap partition on the middle of the disk. It won't do you any harm, and can give you a nice edge by reducing seek time.
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Alain Reguera wrote:
/var/spool/imap/ 2.000 # This could be as a Cyrus Swap, moreover of System Swap? /var/spool/mail/ 14.000
Nope, you got that part wrong. Remove /var/spool/mail completely. Cyrus does not use it at all (it's going to be empty). Alocate those 14 gigs to /var/spool/imap file system (it's not a swap space, it is file system where the mailboxes will be stored).
Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, Dec 05, 2005 at 09:26:04PM -0500, Alain Reguera wrote:
Hello,
I'm planning the installation of the school's Mail Server. This is the first time I get in administration. I've been reading about postfix, cyrus and the first page in the guide of HughesJR.com[2] about installing postfix-cyrus, but due my low hardware resources, I ask for suggestions to see If what I need can be done (and|or) stable.
Hardware: Pentium III 1.4Ghz 256 RAM 40 GB HD-IDE
Soft: CentOS 4.2 Postfix Cyrus-IMAPd MailScanner Spanassassin
First off, dump either antivirus or antispam on that machine. You don't have enough memory to keep both happy.
I must agree... 256 MB for a MailScanner+SA setup is rather low. What you could do is subscribe to a service like LastSpam (www.lastspam.com) (they are MailScanner-SA (with custom code)) to filter junk, if you can't get better hardware (especially memory).
A P3 1.4GHz is more than up to the task, so you will have no problem there.
You might also want to change Cyrus-imapd to something simpler, like wu-imapd, since it should take less resources from the machine. Then again, I have very little experience with cyrus, since I either use wu or courrier.
[]s
Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDlP0bpdyWzQ5b5ckRAvp2AJ0ftuexQJkNE9qcbfxe2rxbBQ2GGgCeL6HO egorOgW0i5B6iwSeYidQK5I= =5+y2 -----END PGP SIGNATURE-----
I'm getting a little involved now, thanks for replaying guys
Disable Imap and only keep pop3 ?
but how can I grant students' mobility around labs, keeping their Inbox's messages available from one workstation to another?
The suggestions about memory is very useful. I'll put spanassassin and mailscanner but only after a hardware upgrade.
by now I consider: cyrus and postfix
The suggestions have been very important. I'll continue reading in this direction. Any last comments are also welcome :)
I'll keep the last partitioning, passed 8 hours I'll install, now need a rest :) zZZZ
I would like to keep this topic open, for any new suggestion on a different and new setup on Planning Mail Server (with low resources).
Thanks guys for all your help and time, this is a very nice and active place.
On Tue, 2005-12-06 at 04:24, Alain Reguera wrote:
I'm getting a little involved now, thanks for replaying guys
Disable Imap and only keep pop3 ?
but how can I grant students' mobility around labs, keeping their Inbox's messages available from one workstation to another?
Does this have to live on the same box? Used hardware is really cheap these days and you can use an MX record to direct your inbound mail through a screening box.
The suggestions have been very important. I'll continue reading in this direction. Any last comments are also welcome :)
The best thing you could do for that box is max it out with RAM, followed by transplanting a SCSI controller and drive for the most active partitions. Ironically, new RAM for old machines is pretty expensive but if you have a scrap bin, dig through it.
Software-wise, I'd recommend sendmail with MimeDefang unless the postfix/mailscanner combo has a way to avoid starting a new copy of the scanners for each message.
Les Mikesell wrote:
On Tue, 2005-12-06 at 04:24, Alain Reguera wrote:
I'm getting a little involved now, thanks for replaying guys
Disable Imap and only keep pop3 ?
but how can I grant students' mobility around labs, keeping their Inbox's messages available from one workstation to another?
Does this have to live on the same box? Used hardware is really cheap these days and you can use an MX record to direct your inbound mail through a screening box.
The suggestions have been very important. I'll continue reading in this direction. Any last comments are also welcome :)
The best thing you could do for that box is max it out with RAM, followed by transplanting a SCSI controller and drive for the most active partitions. Ironically, new RAM for old machines is pretty expensive but if you have a scrap bin, dig through it.
Software-wise, I'd recommend sendmail with MimeDefang unless the postfix/mailscanner combo has a way to avoid starting a new copy of the scanners for each message.
MailScanner starts one copy of the scanners by batch of messages.
On Tue, 2005-12-06 at 08:29, Ugo Bellavance wrote:
Software-wise, I'd recommend sendmail with MimeDefang unless the postfix/mailscanner combo has a way to avoid starting a new copy of the scanners for each message.
MailScanner starts one copy of the scanners by batch of messages.
What does 'batch of messages' mean to a mail server? Or more relevant to performance, what kind of ratio of program starts to messages do you expect and can you sort-circuit the startups as soon as you know you are going to discard a virus?
MimeDefang runs as a sendmail milter that is always running and doesn't need to restart for each message so it is particularly efficient although spamassassin takes a certain amount of CPU to run anyway.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, Dec 06, 2005 at 05:24:27AM -0500, Alain Reguera wrote:
I'm getting a little involved now, thanks for replaying guys
Disable Imap and only keep pop3 ?
but how can I grant students' mobility around labs, keeping their Inbox's messages available from one workstation to another?
Pendrives ? Smartcards ?
Trust me, you don't want to keep those students inboxes on the server. Without quota, you will never have enough disk. With quota, you will never have a second of peace.
by now I consider: cyrus and postfix
I'm more of an exim guy, but postfix is much easier to configure and maintain.
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Rodrigo Barbosa wrote:
Pendrives ? Smartcards ?
Trust me, you don't want to keep those students inboxes on the server. Without quota, you will never have enough disk. With quota, you will never have a second of peace.
Pendrives? As in USB memory sticks? You must be joking here, right? At $50 per stick and 2,000 students, that's investment of $100,000. Local retailers would sure love him (and you for suggesting something like that). I don't think his budget is anywhere near that amount. Even if it was, for the price of a single stick, he could buy tens of gigabytes of disk space. For a price of 2000 sticks, he could buy so much storage that he could support tens (hundreds?) thousands of user without quotas. Memory sticks are probably the single most expensive storage device. Not to mention that configuring email clients to use sticks would be real support nightmare.
IMAP and centralized mail storage is solution for his problem. And the most inexpensive too. Period.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Dec 07, 2005 at 01:13:16AM -0600, Aleksandar Milivojevic wrote:
IMAP and centralized mail storage is solution for his problem. And the most inexpensive too. Period.
And how do you plan on backuping that ? An array of DLT units ?
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Rodrigo Barbosa wrote:
On Wed, Dec 07, 2005 at 01:13:16AM -0600, Aleksandar Milivojevic wrote:
IMAP and centralized mail storage is solution for his problem. And the most inexpensive too. Period.
And how do you plan on backuping that ? An array of DLT units ?
Can we stop Trolling here ?
Rodrigo, how many DLT tapes do you think he needs to backup the 40gig HDD he has in there ?
- K
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Dec 07, 2005 at 02:17:11PM +0000, Karanbir Singh wrote:
IMAP and centralized mail storage is solution for his problem. And the most inexpensive too. Period.
And how do you plan on backuping that ? An array of DLT units ?
Can we stop Trolling here ?
Who the heck is trolling ? I'm asking a valid question, for a problem that concerns me. I run several e-mail servers, and the main problem I have with those is backup.
Rodrigo, how many DLT tapes do you think he needs to backup the 40gig HDD he has in there ?
Okey, you lost me here.
Is 40gig enough for 2000 users imap accounts ?
If that is the case, you don't even need DLT, a simple DAT72 unit would be enough.
I have a corporate server here for 400 accounts, and it is already at 37GIG.
On the other hand, I know it was mentioned he would be implementing quota. And it IS for students, but I really think anything less than 100M/user (allocated) for Imap is not enough.
So, please show me the flaw in my thinking. Even tho you think I'm trolling, this stuff IS an issue for me and the servers I run. If you can point me to the flaws in my reasoning, I will be very greatful, since you will be saving me money.
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Rodrigo Barbosa wrote:
IMAP and centralized mail storage is solution for his problem. And the most inexpensive too. Period.
And how do you plan on backuping that ? An array of DLT units ?
Can we stop Trolling here ?
Who the heck is trolling ? I'm asking a valid question, for a problem that concerns me. I run several e-mail servers, and the main problem I have with those is backup.
You forgot to mention all these details in your last email, the one you replied to with no details of this sort - were a response to the original posters querry - and the system config there was based on a 40 Gig drive.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Dec 07, 2005 at 03:20:24PM +0000, Karanbir Singh wrote:
Rodrigo Barbosa wrote:
IMAP and centralized mail storage is solution for his problem. And the most inexpensive too. Period.
And how do you plan on backuping that ? An array of DLT units ?
Can we stop Trolling here ?
Who the heck is trolling ? I'm asking a valid question, for a problem that concerns me. I run several e-mail servers, and the main problem I have with those is backup.
You forgot to mention all these details in your last email, the one you replied to with no details of this sort - were a response to the original posters querry - and the system config there was based on a 40 Gig drive.
"Mea culpa", then. I did reply without noticing you said it was the solution to _his_ problem, and just took it as a general recomendation. My bad on that one.
In any case, one of the things we (I?) noticed on this whole issue is that it escalated to much more than the original's poster questions. Lots of people suggested he needs more HD space, more e-mail (me included) and such.
At least to me it proves that e-mail servers are giving people more headaches than they are supposed to. Of course we all face the standard problems regarding spam and virus, but the problems seem to be more pervasive than that. I, for one, am surprised. Then again, maybe I'm just naive.
On the other hand, this is first time I see a thread such as this where no religious wars started. Usually people will defend their MTA of choice, and not even consider the others. Everyone here has an MTA of choice, of course, but everyone also pointed to the advantages of the other MTAs.
I think the greater proof that this issue is causing all of us headache is that we have diverted a lot from the original topic, and still people are not complaining. Which, I hope, shows that this whole issue is interesting to at least a number of subscribers. I know I am.
I don't like IMAP. Never did. Maybe this is because of the number of bugs we had in the past for all imap implementations. Maybe because of the wasted disk space on workstations. I know the backup issue is a big problem for me, and users complaining their quota is never enough really gets on my nerves. So I try to avoid imap as often as I can for everything except webmail.
Best regards,
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On Wed, 2005-12-07 at 13:35 -0200, Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Dec 07, 2005 at 03:20:24PM +0000, Karanbir Singh wrote:
Rodrigo Barbosa wrote:
IMAP and centralized mail storage is solution for his problem. And the most inexpensive too. Period.
And how do you plan on backuping that ? An array of DLT units ?
Can we stop Trolling here ?
Who the heck is trolling ? I'm asking a valid question, for a problem that concerns me. I run several e-mail servers, and the main problem I have with those is backup.
You forgot to mention all these details in your last email, the one you replied to with no details of this sort - were a response to the original posters querry - and the system config there was based on a 40 Gig drive.
"Mea culpa", then. I did reply without noticing you said it was the solution to _his_ problem, and just took it as a general recomendation. My bad on that one.
In any case, one of the things we (I?) noticed on this whole issue is that it escalated to much more than the original's poster questions. Lots of people suggested he needs more HD space, more e-mail (me included) and such.
At least to me it proves that e-mail servers are giving people more headaches than they are supposed to. Of course we all face the standard problems regarding spam and virus, but the problems seem to be more pervasive than that. I, for one, am surprised. Then again, maybe I'm just naive.
On the other hand, this is first time I see a thread such as this where no religious wars started. Usually people will defend their MTA of choice, and not even consider the others. Everyone here has an MTA of choice, of course, but everyone also pointed to the advantages of the other MTAs.
I think the greater proof that this issue is causing all of us headache is that we have diverted a lot from the original topic, and still people are not complaining. Which, I hope, shows that this whole issue is interesting to at least a number of subscribers. I know I am.
I don't like IMAP. Never did. Maybe this is because of the number of bugs we had in the past for all imap implementations. Maybe because of the wasted disk space on workstations. I know the backup issue is a big problem for me, and users complaining their quota is never enough really gets on my nerves. So I try to avoid imap as often as I can for everything except webmail.
---- I think that a lot of people's issues are caused by running daemons that they don't take the time to understand. They get past the initial setup and then forget about it and when things go awry, they get panicked, frustrated, desperate.
I can work with sendmail but every time that I wanted to add features, I felt like I was getting a tooth pulled and postfix seemed more comprehensible. Learning on Red Hat meant how to survive with wu-imapd and when I found that future versions of Red Hat (hence CentOS) and Fedora were using cyrus-imapd, I learned to embrace it and was pleased that it accommodated my ventures into LDAP as well as gave me the incredible array of features.
It's not that I couldn't use courier or X-mail or vpopmail or whatever but the out of band projects aren't logical choices for someone that doesn't want to commit to maintaining their own upgrades - especially when considering that the RH packagers have provided reasonable enough alternatives.
The OP obviously did some research and planning and rather thoughtfully offered his conclusions for review.
I'm less than certain that the OP was well served by suggestions of out of band alternatives. Just using one of the daemons supplied in CentOS and used by a fair cross-section of users on this list provides a comfort level that most out of band packages could never deliver.
Craig
It's not that I couldn't use courier or X-mail or vpopmail or whatever but the out of band projects aren't logical choices for someone that doesn't want to commit to maintaining their own upgrades - especially when considering that the RH packagers have provided reasonable enough alternatives.
I'd just like to say that some, if not most, of the 'out of band' solutions don't need upgrading.
The OP obviously did some research and planning and rather thoughtfully offered his conclusions for review.
I'm less than certain that the OP was well served by suggestions of out of band alternatives. Just using one of the daemons supplied in CentOS and used by a fair cross-section of users on this list provides a comfort level that most out of band packages could never deliver.
There is a reason why many large sites use 'out of band' packages.
Redhat has geared its offerings for those who don't have a lot of time on their hands which is the case for most SME's I'd say. Beyond that, the bundled packages are not up to special environments.
Quoting Feizhou feizhou@graffiti.net:
I'd just like to say that some, if not most, of the 'out of band' solutions don't need upgrading.
"Out of band" solutions need upgrading about the same as the solutions already packaged in the distribution. The only difference, there's nobody to track what was fixed and how important it is if you use something outside of distribution. For each update of Cyrus package, there'll be an errata explaining how important the update is and what might happen if you don't apply it. For Courier, you'll have to parse through ChangLog file and attempt to figure out if that "file descriptor leak" that was fixed on November 21 is just a minor issue, something that will make your server stop working after couple of weeks, a possibility of DoS attack against your server, will somebody be able to break into your machine if you don't fix it, and so on, and so forth.
I've nothing against Courier. It is a nice piece of software. Cyrus too is a nice piece of software.
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Aleksandar Milivojevic wrote:
Quoting Feizhou feizhou@graffiti.net:
I'd just like to say that some, if not most, of the 'out of band' solutions don't need upgrading.
"Out of band" solutions need upgrading about the same as the solutions already packaged in the distribution. The only difference, there's nobody to track what was fixed and how important it is if you use something outside of distribution. For each update of Cyrus package, there'll be an errata explaining how important the update is and what might happen if you don't apply it. For Courier, you'll have to parse through ChangLog file and attempt to figure out if that "file descriptor leak" that was fixed on November 21 is just a minor issue, something that will make your server stop working after couple of weeks, a possibility of DoS attack against your server, will somebody be able to break into your machine if you don't fix it, and so on, and so forth.
qmail does not. period. ok, postfix does. fine.
I've nothing against Courier. It is a nice piece of software. Cyrus too is a nice piece of software.
Oh goodie. what happened to dovecot?
On Wed, 2005-12-07 at 09:00, Rodrigo Barbosa wrote:
And how do you plan on backuping that ? An array of DLT units ?
Can we stop Trolling here ?
Who the heck is trolling ? I'm asking a valid question, for a problem that concerns me. I run several e-mail servers, and the main problem I have with those is backup.
An rsync based backup scheme works nicely against maildir format although you may have to break it up into several runs since rsync has some per-file memory overhead.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Dec 07, 2005 at 11:51:02AM -0600, Les Mikesell wrote:
On Wed, 2005-12-07 at 09:00, Rodrigo Barbosa wrote:
And how do you plan on backuping that ? An array of DLT units ?
Can we stop Trolling here ?
Who the heck is trolling ? I'm asking a valid question, for a problem that concerns me. I run several e-mail servers, and the main problem I have with those is backup.
An rsync based backup scheme works nicely against maildir format although you may have to break it up into several runs since rsync has some per-file memory overhead.
I know this may sound old fashioned, but what is wrong with rdump for that ? I think that for this particular case, dump/rdump would be a better option (backup).
I like and use rsync for a lot of other stuff, so I have nothing against it.
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On Wed, 2005-12-07 at 13:44, Rodrigo Barbosa wrote:
Who the heck is trolling ? I'm asking a valid question, for a problem that concerns me. I run several e-mail servers, and the main problem I have with those is backup.
An rsync based backup scheme works nicely against maildir format although you may have to break it up into several runs since rsync has some per-file memory overhead.
I know this may sound old fashioned, but what is wrong with rdump for that ? I think that for this particular case, dump/rdump would be a better option (backup).
If you are doing archival copies tar/dump/rdump make sense. If you want a close-to-current disk copy that you can mount instantly or a warm-spare host that can take over with a small data loss with a IP change along with the ability to copy back something deleted since the last run, rsync will do it and know enough not to copy files that are already there. If you want snapshot-like backups over a certain amount of time, backuppc can do it using rsync for the transport and keep daily snapshots for a week in less space than the source data (depending on compression and rate of change, of course...) or if you give up compression, rsync can keep a current tree and one containing old versions by itself.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Dec 07, 2005 at 01:57:48PM -0600, Les Mikesell wrote:
I know this may sound old fashioned, but what is wrong with rdump for that ? I think that for this particular case, dump/rdump would be a better option (backup).
If you are doing archival copies tar/dump/rdump make sense. If you want a close-to-current disk copy that you can mount instantly or a warm-spare host (...)
Point taken. Tkx.
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Karanbir Singh mail-lists@karan.org wrote:
Can we stop Trolling here ? Rodrigo, how many DLT tapes do you think he needs to backup the 40gig HDD he has in there ?
As I mentioned before, LTO is faster and cheaper these days.
And if you're going to spend $2+K on a backup drive, you might as well go for the gold and spend $3-4K to get a new LTO-3 that holds 400GB natively, and backs up at a 80MBps rate (double each for typical 2:1 hardware compression).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Dec 07, 2005 at 10:57:23AM -0800, Bryan J. Smith wrote:
Karanbir Singh mail-lists@karan.org wrote:
Can we stop Trolling here ? Rodrigo, how many DLT tapes do you think he needs to backup the 40gig HDD he has in there ?
As I mentioned before, LTO is faster and cheaper these days.
And if you're going to spend $2+K on a backup drive, you might as well go for the gold and spend $3-4K to get a new LTO-3 that holds 400GB natively, and backs up at a 80MBps rate (double each for typical 2:1 hardware compression).
It is hard enough to find DLT units and tapes around here, Bryan, that I don't even want to think about getting LTO stuff.
How easy is to get LTO units and tapes in USA and other countries ? How open is it (meaning: how many companies make it) ?
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On Wednesday 07 December 2005 13:51, Rodrigo Barbosa wrote:
On Wed, Dec 07, 2005 at 10:57:23AM -0800, Bryan J. Smith wrote:
Karanbir Singh mail-lists@karan.org wrote:
Can we stop Trolling here ? Rodrigo, how many DLT tapes do you think he needs to backup the 40gig HDD he has in there ?
As I mentioned before, LTO is faster and cheaper these days.
And if you're going to spend $2+K on a backup drive, you might as well go for the gold and spend $3-4K to get a new LTO-3 that holds 400GB natively, and backs up at a 80MBps rate (double each for typical 2:1 hardware compression).
It is hard enough to find DLT units and tapes around here, Bryan, that I don't even want to think about getting LTO stuff.
How easy is to get LTO units and tapes in USA and other countries ? How open is it (meaning: how many companies make it) ?
[]s
I use LTO1 they are in plentiful supply and the tapes are much cheaper than DLT. i get tapes for about USD$28 each, they hold 100GB natively the tapes are readily available form many companies. IBM, HP, Sony, fuji, Imation, TDK to name a few. LTO is an open standard. and is supported by every tape vendor out there. this is the reason that prices are much better. its a more even playing field. you are not dependent on 1 or 2 vendors for all supplies.
Dennis
Dennis Gilmore dennis@ausil.us wrote:
I use LTO1 they are in plentiful supply and the tapes are much cheaper than DLT. i get tapes for about USD$28 each, they hold 100GB natively the tapes are readily available form many companies.
Damn, I didn't realize LTO-1 was now that affordable. I also just looked and the drives have now dropped to under $1K. _Ignore_ my previous recommendation to go AIT-2 or VXA-2 for 100GB or so, LTO-1 is _definitely_ the solution there.
Thanx for pointing out how far the tape cartridges have fallen in price. It's been a good year, maybe 18 months, since I priced LTO-1 cartridges.
IBM, HP, Sony, fuji, Imation, TDK to name a few. LTO is an open standard.
3 drive vendors, virtually _every_ media vendor.
and is supported by every tape vendor out there. this is
the
reason that prices are much better. its a more even
playing
field. you are not dependent on 1 or 2 vendors for all supplies.
Exactomundo.
Unless you have legacy AIT or DLT, LTO is the way to go.
Rodrigo Barbosa rodrigob@suespammers.org wrote:
It is hard enough to find DLT units and tapes around here, Bryan, that I don't even want to think about getting LTO
stuff.
Call up your local HP VAR! You can't be the only one with enterprise requirements. In fact, lack of availability of enterprise products is a _poor_ excuse to use commodity components with much, much higher failure rates.
How easy is to get LTO units and tapes in USA and other countries ? How open is it (meaning: how many companies
make
it) ?
LTO is a 3 vendor standard. LTO media is available from just about everyone.
It has been the standard with the highest adoption rate the past 3-4 years -- roughly 40-50%.
Bryan J. Smith wrote:
Karanbir Singh mail-lists@karan.org wrote:
Can we stop Trolling here ? Rodrigo, how many DLT tapes do you think he needs to backup the 40gig HDD he has in there ?
As I mentioned before, LTO is faster and cheaper these days.
And if you're going to spend $2+K on a backup drive, you might as well go for the gold and spend $3-4K to get a new LTO-3 that holds 400GB natively, and backs up at a 80MBps rate (double each for typical 2:1 hardware compression).
hi Bryan,
the target data is only 40 GB, not 400 GB. There might be an upgrade down the road - but aparently, the system has access to only a single 40 gig drive.
I seriously doubt that given the circumstances, there is even an option to spend the $2K+ on a backup drive.
- K
Karanbir Singh mail-lists@karan.org wrote:
hi Bryan, the target data is only 40 GB, not 400 GB. There might be an upgrade down the road - but aparently, the system has access to only a single 40 gig drive. I seriously doubt that given the circumstances, there is even an option to spend the $2K+ on a backup drive.
I understand that. People are bouncing all over the place and I'm trying to address them all. Again, I'm going to put of a set of "scenarios" on my blog.
In his case, I'd use a couple 80GB 2.5" drives with high G tolerances. Or if he wants a tape, maybe a VXA-1.
My point is that once you start talking 100GB of backup -- beyond sub-$1K AIT-2 or VXA-2 -- where people start looking at DLT, don't get anything "mid-capacity." Go for the latest LTO revision, currently LTO-3, because the cost per GB goes down _substantially_!
That's my point.
Quoting Rodrigo Barbosa rodrigob@suespammers.org:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Dec 07, 2005 at 01:13:16AM -0600, Aleksandar Milivojevic wrote:
IMAP and centralized mail storage is solution for his problem. And the most inexpensive too. Period.
And how do you plan on backuping that ? An array of DLT units ?
I'd probably back it up to disk. Pair of 200-300GB drives (in RAID-1). Very inexpensive.
Would be interesting to hear how did you envision to backup 2000 USB sticks that users are carrying around (and loosing them on regular basis)...
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Would be interesting to hear how did you envision to backup 2000 USB sticks that users are carrying around (and loosing them on regular basis)...
ROTFL
Anyway, as for loosing...that's simple. They get to pay, in hard cash, for losing University property. I'd imagine they rather not risk losing one.
Of course this does not address the issue of making backups of data in the USB sticks.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, Dec 08, 2005 at 12:32:17AM +0800, Feizhou wrote:
Would be interesting to hear how did you envision to backup 2000 USB sticks that users are carrying around (and loosing them on regular basis)...
ROTFL
Anyway, as for loosing...that's simple. They get to pay, in hard cash, for losing University property. I'd imagine they rather not risk losing one.
Of course this does not address the issue of making backups of data in the USB sticks.
It does, if you use the same idea.
It is the user responsibility to keep the USB safe. It is his responsibility to back it up. Thats the beaulty of it.
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, Dec 08, 2005 at 12:32:17AM +0800, Feizhou wrote:
Would be interesting to hear how did you envision to backup 2000 USB sticks that users are carrying around (and loosing them on regular basis)...
ROTFL
Anyway, as for loosing...that's simple. They get to pay, in hard cash, for losing University property. I'd imagine they rather not risk losing one.
Of course this does not address the issue of making backups of data in the USB sticks.
It does, if you use the same idea.
It is the user responsibility to keep the USB safe. It is his responsibility to back it up. Thats the beaulty of it.
That's true ain't it? I got sidetracked by the 'loosing' er losing part =D
On Wed, 2005-12-07 at 10:49, Rodrigo Barbosa wrote:
Of course this does not address the issue of making backups of data in the USB sticks.
It does, if you use the same idea.
It is the user responsibility to keep the USB safe. It is his responsibility to back it up. Thats the beaulty of it.
Making thousands of people do extra work that is easily automated in one spot isn't my idea of beauty.
On the other hand, that 40 gig drive really isn't going to cut it.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Dec 07, 2005 at 11:19:01AM -0600, Les Mikesell wrote:
On Wed, 2005-12-07 at 10:49, Rodrigo Barbosa wrote:
Of course this does not address the issue of making backups of data in the USB sticks.
It does, if you use the same idea.
It is the user responsibility to keep the USB safe. It is his responsibility to back it up. Thats the beaulty of it.
Making thousands of people do extra work that is easily automated in one spot isn't my idea of beauty.
Either you do that, or you get them to sign a very big Terms of Service agreement, where you state clearly WHAT services will be provided and under which exact conditions.
Otherwise, you will have people annoying you all the time about e-mails they acidentaly deleted and stuff like that.
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Dec 07, 2005 at 10:26:42AM -0600, Aleksandar Milivojevic wrote:
IMAP and centralized mail storage is solution for his problem. And the most inexpensive too. Period.
And how do you plan on backuping that ? An array of DLT units ?
I'd probably back it up to disk. Pair of 200-300GB drives (in RAID-1). Very inexpensive.
The problem with that setup is that you can't get historical data. If that is not an issue, then I agree RAID-1 is enough.
Would be interesting to hear how did you envision to backup 2000 USB sticks that users are carrying around (and loosing them on regular basis)...
You are shifting the responsibility for the backup. The user can backup it on any machine, including his home computer. But it is no longer the institution (school) responsibility to handle the backup.
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Quoting Rodrigo Barbosa rodrigob@suespammers.org:
On Wed, Dec 07, 2005 at 10:26:42AM -0600, Aleksandar Milivojevic wrote:
I'd probably back it up to disk. Pair of 200-300GB drives (in RAID-1). Very inexpensive.
The problem with that setup is that you can't get historical data. If that is not an issue, then I agree RAID-1 is enough.
Not true. You can do backup on disk exactly the same way you do them to tape. With tape, you calculate how big your backups are, and for how long you want to keep them. Then you go out and by that many tapes. With disk, you do the same thing and buy disk(s) of appropriate size. If you run out of tapes, you buy more tapes. If you run out of disk space for backup, you buy more disks. Same thing. Anyhow, cost of single SDLT tape is comparable to cost of disk drive of same capacity.
Would be interesting to hear how did you envision to backup 2000 USB sticks that users are carrying around (and loosing them on regular basis)...
You are shifting the responsibility for the backup. The user can backup it on any machine, including his home computer. But it is no longer the institution (school) responsibility to handle the backup.
The user is not going to bother to backup. He'll just blaim you for loosing his email (no matter who's responsibility it was on paper). Anyhow, as I said previously, for $100,000 (which would be price of USB sticks) you can buy really fancy storage with really fancy backup solution. Anyhow, I always hated people that are shifting responsibility they are paid to handle to somebody who is not supposed to have that responsibility in the first place.
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Dec 07, 2005 at 11:24:42AM -0600, Aleksandar Milivojevic wrote:
I'd probably back it up to disk. Pair of 200-300GB drives (in RAID-1). Very inexpensive.
The problem with that setup is that you can't get historical data. If that is not an issue, then I agree RAID-1 is enough.
Not true. You can do backup on disk exactly the same way you do them to tape. With tape, you calculate how big your backups are, and for how long you want to keep them. Then you go out and by that many tapes. With disk, you do the same thing and buy disk(s) of appropriate size. If you run out of tapes, you buy more tapes. If you run out of disk space for backup, you buy more disks. Same thing. Anyhow, cost of single SDLT tape is comparable to cost of disk drive of same capacity.
At least around here, a 120G DLT tape costs less than half the price of an HD of the same capacity.
Not to mention that tapes are much more reliable, since you can store them on appropriate containers/safes.
They also don't have mechanical parts built in, so the they are less likely to fail. Of course, I mean good tapes, not the el-cheapo ones.
HDs are not a reliable backup media, and never were.
Anyhow, I always hated people that are shifting responsibility they are paid to handle to somebody who is not supposed to have that responsibility in the first place.
This is enough to show me it would be a waste of time to show the flaws on your thinking. If you are looking at it emotionaly, it is useless to explain anything to you.
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Quoting Rodrigo Barbosa rodrigob@suespammers.org:
At least around here, a 120G DLT tape costs less than half the price of an HD of the same capacity.
Not to mention that tapes are much more reliable, since you can store them on appropriate containers/safes.
They also don't have mechanical parts built in, so the they are less likely to fail. Of course, I mean good tapes, not the el-cheapo ones.
HDs are not a reliable backup media, and never were.
(Almost) everything I wrote in this thread was from perspective of getting something done inexpensively. That is what OP asked in the first place. Suggesting a tape drive that costs several thousands of dollars (not to mention prices of autoloaders), and then $50-100 for each tape clearly is not what he can afford. There are cheaper drives and tapes (such as 8mm and 4mm), but those are so unreliable (and not really archival) it is not worth even considering them.
Clearly, tapes (good tapes such as (S)DLT and LTO) are better for long term archival storage. The question is, does OT needs that? If all he needs is couple of weeks (or months) worth of backup, and no archiving, RAID-1 or RAID-10 disk based solution would be way cheaper and easier to maintain.
It does no good to OP if you throw at him solutions fortune 500 company can afford. Those are way out of reach for him. If he wrote "hey, I have this smoking cluster of brand new dual core Xeons with terrabytes of SAN based storage". Sure, I'd suggest some nice backup system. Remember, he has an older PIII with 40 gig drive, and obviously no budget for any upgrades of that system. I assume when time comes for him to think about backing it up, his budget ain't gonna be much better (and even if he gets a lot of $$$ for backup, does he really need an expensive smoking tape drive, or will couple of cheap reduntant hard drives fit the bill). Well, actually, the time to think about backing up his email server is right now, before there are any users on it. So that's way I suggested couple of cheap(er) ways to do it.
Anyhow, I always hated people that are shifting responsibility they are paid to handle to somebody who is not supposed to have that responsibility in the first place.
This is enough to show me it would be a waste of time to show the flaws on your thinking. If you are looking at it emotionaly, it is useless to explain anything to you.
It's not emotional. It is just what I think about people who choose to take the "screw the users" route. Nothing emotional about it. Just bussiness. You are there for the users and because of users. If there were no users, there wouldn't be you. I'm sure not the one suggesting to spend $100,000 (as opposed to $200 and a bit of time to initially setup backup system), for what really? Not to have to do something as basic and simple as elementary backup?
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Quick answer not to bother ther other subscribers too much.
On Wed, Dec 07, 2005 at 03:17:51PM -0600, Aleksandar Milivojevic wrote:
Quoting Rodrigo Barbosa rodrigob@suespammers.org:
(Almost) everything I wrote in this thread was from perspective of getting something done inexpensively. That is what OP asked in the first place.
As you might have noticed, this thread already drifted very far from the OP. That is why it did split into 3 different thread (so far).
Anyhow, I always hated people that are shifting responsibility they are paid to handle to somebody who is not supposed to have that responsibility in the first place.
This is enough to show me it would be a waste of time to show the flaws on your thinking. If you are looking at it emotionaly, it is useless to explain anything to you.
It's not emotional. It is just what I think about people who choose to take the "screw the users" route. Nothing emotional about it. Just bussiness. You are there for the users and because of users. If there were no users, there wouldn't be you. I'm sure not the one suggesting to spend $100,000 (as opposed to $200 and a bit of time to initially setup backup system), for what really? Not to have to do something as basic and simple as elementary backup?
Who is saying "screw the users" ? Shifting responsibility is a far different beast.
I'm sure you already implemented systems on this scale, but I can't be sure (you never mentioned) if you ever administered on like this.
It is VERY easy to reach 100K on maintenance costs for a year. How much a single tech costs (plus taxes, benefits etc etc) ?
If you plan to do everything for the users, fine, but make sure you have a very detailed "Terms of Service" agreement, and that you get the users to sign it. If you don't, even time they delete one e-mail by mistake, they will come running to you asking for you to recover it. And on a 2K users base, you can bet it will happen at least once a day. If you consider that it can take you up to 4 hours to restore it, it will cost you big.
Screw the users is what administrators usually say when users delete their e-mails. "You deleted, your problem".
Shifting responsibility is not "screw the users". It is making things clear for them.
Pendrives are not the only possible solution. You can have distributed filesystems using multiple desktop computers, you can have smartcards, SAN, or even paperwork and lectures. Each of those solutions (and others) have different setup costs, and different TCOs, and both (and not only setup costs) should be considered.
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On Wed, 2005-12-07 at 16:15, Rodrigo Barbosa wrote:
Screw the users is what administrators usually say when users delete their e-mails. "You deleted, your problem".
That's very different from: "the hard drive crashed, everyone's problem".
Shifting responsibility is not "screw the users". It is making things clear for them.
I'm not sure the scope of services is clear for this machine. It is supposed to handle students, but maybe it also serves the administration where losing internal communications might cause a problem for yourself.
Rodrigo Barbosa wrote:
I'm sure you already implemented systems on this scale, but I can't be sure (you never mentioned) if you ever administered on like this.
I've worked and have setup mail and all other kinds of systems from very small shops with couple of users to relatively large ISPs with hundreds of thousands of users. From University settings to totally private profit-is-everything settings.
As far as responsibility to restore email from backup, there should be a way to recover from "not really a users mistake" scenarios. Like his USB stick gets stolen or fried or whatever. As for restoring individual email that was deleted by the user, sure that is something that, depending on the environment, might or might not be responsibility of system administrator. Even if it wasn't, it is user friendly to help the user if time and resources allow it.
I want to thank you all for the suggestions and time involved.
Now I feel a little more oriented to assume the issue of installing a mail server with this low resources.
This 142 threads had been decisive to me.
Thank you guys.
Aleksandar Milivojevic alex@milivojevic.org wrote:
(Almost) everything I wrote in this thread was from perspective of getting something done inexpensively. That is what OP asked in the first place. Suggesting a tape drive that costs several thousands of dollars (not to mention prices of autoloaders),
If you visit the site every weekday, autoloaders for older drives are _useless_. I.e., it's better to go with an LTO-3 than buy an LTO-1 with an autoloader.
Remember, leverage _on-line/near-line_ fixed disk with _off-line_ tape. That means for sub-100GB, you are only sending 1-2 tapes/month off-site _maximum_.
Now given the price of LTO-1 drives and media, it's really a $1.2K entry point for a drive and 8 tapes that will give you 1-2 years of _off-line_ rotation. The problem is that too many people use tape for _everything_. _Only_ use tape for off-lining data.
If you're only backing up 40GB, then consider a few 80GB 2.5" notebook hard drives instead. They are far more tolerant of Gs and off-line period than commodity 3.5" disks.
and then $50-100 for each tape clearly is not what he can afford.
Depends on his tape rotation.
Again, I hadn't realized that 100GB (200GB 2:1) LTO-1 was now approaching $25.
There are cheaper drives and tapes (such as 8mm and 4mm),
Sorry, 8mm is pretty vendor splittered. You've got AIT and VXA (IIRC). Going back a bit, you then have Exabyte 8mm and Mammoth. In any case, not worth it.
Yes, 4mm DAT is multi-vendor, but it's really aged and _slow_. By the time you pay $500 for a 36GB (72GB 2:1) DAT72 drive, you're half-way to an AIT-2, VXA-2 or -- now that I re-educated myself -- LTO-1 drive (definitely go LTO-1 over AIT or VXA for the same price).
but those are so unreliable (and not really archival) it is not worth even considering them.
Unreliable by who's standard? 4mm DAT is pretty damn small and stores very well. But yes, 4mm and 8mm aren't as good as DLT and LTO.
Clearly, tapes (good tapes such as (S)DLT and LTO) are better for long term archival storage. The question is, does OT needs that? If all he needs is couple of weeks (or months) worth of backup, and no archiving, RAID-1 or RAID-10 disk based solution would be way cheaper and easier to maintain.
A disk separate from the running/on-line data. Again, I'd use some 2.5" drives.
It does no good to OP if you throw at him solutions fortune 500 company can afford.
I don't think I was. I was talking in reference to _other_ comments.
I said AIT-2 or VXA-2 for smaller, single servers that don't off-line more than 100GB. Had I known 100GB LTO-1 was now under $1K with tapes approaching $25, I wouldn't have even mentioned AIT-2 or VXA-2.
Those are way out of reach for him.
"Out-of-reach" is relative. You should realize that 40% of your server budget _is_ disaster recovery. If you don't, then you're one of the people in the 90% statistic when a disaster hits. ;->
If he wrote "hey, I have this smoking cluster of brand new dual core Xeons with terrabytes of SAN based storage".
Sure,
I'd suggest some nice backup system.
Hey, remember the _context_ of _each_ response. Thank you. ;->
Remember, he has an older PIII with 40 gig drive, and
obviously
no budget for any upgrades of that system.
Then use a couple of 2.5" drives.
I assume when time comes for him to think about backing it
up,
his budget ain't gonna be much better (and even if he gets
a
lot of $$$ for backup, does he really need an expensive
smoking
tape drive, or will couple of cheap reduntant hard drives
fit
the bill).
3.5" hard drives are _never_ a good idea because of the G issues. Yes, rotating them in every few weeks helps the off-line issue, but there's still the G issue that will creep into bad sectors.
Well, actually, the time to think about backing up his
server is right now, before there are any users on it. So that's way I suggested couple of cheap(er) ways to do it.
I think everything needs to be taken in the context they were presented. A lot of tangents were thrown off by many people.
Rodrigo Barbosa rodrigob@suespammers.org wrote:
At least around here, a 120G DLT tape costs less than half the price of an HD of the same capacity.
Reality ...
When you're talking 100GB, most of the higher capacity, leading-edge technologies are $50-100/cartridge, _regardless_ of the capacity. So you're better off going with the latest/fastest/biggest capacity when you're going to spend 4 figures.
Right now, that's multi-vendor LTO revision 3 -- 400GB (800GB) at 80MBps (160MBps) native (2:1 hardware). DLT is slower and largely uni-vendor, HP, and even HP does LTO (and they do it better than DLT). DLT should only be considered for legacy media compatibility.
More commodity 8mm AIT-2 and VXA-2 drives are just under $1,000, and are under 100GB, but then the tapes are still costly. So you have to consider where your "break even" point is when it comes to cost. For a single server, or a single backup server, that will only putting less than 100GB (so only 1 tape) maybe 1-2 times/month, you're okay.
But if you need to off-site more than 100GB from multiple servers, make the $7-8K investment in TBs of disk storage on a dedicated backup server with a dedicated LTO-3 drive. Especially if you're putting 1+TB off-site, so it's 6+ tapes/month, possible dozens. The cost per GB per cartridge is well worth the LTO-3 initial cost.
Not to mention that tapes are much more reliable, since you can store them on appropriate containers/safes.
Yes, the whole reason for Removable Rigid Disk (RRD). 3.5" fixed disk cannot only not take the Gs, but it is _not_ designed to be off-line for weeks or months -- especially not after being rattled around.
Now 2.5" fixed disks are getting better G tolerances, and are an interesting option. 80GB 2.5" disks go for under $100, so they are an option for smaller companies. I might recommend them in limited cases over going with extra on-line/near-line disk and a VXA-2 or AIT-2 drive.
They also don't have mechanical parts built in, so the they are less likely to fail.
Well, there _are_ still moving parts, just no mechanics. Some of the new 1" hard drives are less fragile, taking even 800Gs.
Of course, I mean good tapes, not the el-cheapo ones.
By "el-cheapo" you mean?
4mm (DAT), QIC (?), 8mm (AIT, VXA), HIC (LTO?), [F]IC (DLT) -- there's a number that share the same moving part design.
HDs are not a reliable backup media, and never were.
Commodity 3.5" fixed disk is designed for regular operation and limited G-forces, even with heads parked.
This is enough to show me it would be a waste of time to show the flaws on your thinking. If you are looking at it emotionaly, it is useless to explain anything to you.
Disk and tape are not a versus, they are a complement.
That's why I wrote the 2005 September Sys Admin article on VTLs, they are the evolution of _complete_ backup.
I guess I need to follow up with a blog entry on "scenarios."
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Dec 07, 2005 at 02:20:08PM -0800, Bryan J. Smith wrote:
Rodrigo Barbosa rodrigob@suespammers.org wrote:
At least around here, a 120G DLT tape costs less than half the price of an HD of the same capacity.
Reality ...
When you're talking 100GB, most of the higher capacity, leading-edge technologies are $50-100/cartridge, _regardless_ of the capacity. So you're better off going with the latest/fastest/biggest capacity when you're going to spend 4 figures.
Right now, that's multi-vendor LTO revision 3 -- 400GB (800GB) at 80MBps (160MBps) native (2:1 hardware). DLT is slower and largely uni-vendor, HP, and even HP does LTO (and they do it better than DLT). DLT should only be considered for legacy media compatibility.
I'm already sold for LTO-3 after this thread.
I just need to find some good supliers.
They also don't have mechanical parts built in, so the they are less likely to fail.
Well, there _are_ still moving parts, just no mechanics. Some of the new 1" hard drives are less fragile, taking even 800Gs.
Never used a 1" hard drive, so I can't really comment on that one.
Of course, I mean good tapes, not the el-cheapo ones.
By "el-cheapo" you mean?
Actually, I was talking about brand/vendors.
This is enough to show me it would be a waste of time to show the flaws on your thinking. If you are looking at it emotionaly, it is useless to explain anything to you.
Disk and tape are not a versus, they are a complement.
That's why I wrote the 2005 September Sys Admin article on VTLs, they are the evolution of _complete_ backup.
I guess I need to follow up with a blog entry on "scenarios."
Disks are good for (partial or full) HA, not backup. Some people call RAID a backup solution, and that is where mistakes happen.
For backups, use tapes.
I see now your line of thinking, but I don't agree with your terminology.
Yes, I think tapes and disks are complementary for an avaliability (contingency, if you will) solution.
Your solution for a centralized backup server is one I would recomend too, and have even implemented it on the past.
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Rodrigo Barbosa rodrigob@suespammers.org wrote:
I'm already sold for LTO-3 after this thread. I just need to find some good supliers.
It depends on your network.
For a server or two with less than 200GB to go off-site maybe a few times a month, and no more than 12 tapes/year, then LTO-1 is just fine. I didn't realize the drives had dropped to under $1K and the tapes to just over $25.
If you have a larger network and want to move several TBs off-site per month -- especially if you're already spending $2-3K just for the on-line backup server with TBs of disk, then definitely add an LTO-3. You'll thank me. ;->
In either case, it's clear that if you're going to do tape, LTO is now the only viable solution. Unless you have legacy AIT, DLT or something else, go LTO -- faster, cheaper, better.
Never used a 1" hard drive, so I can't really comment on that one.
I have a 5GB Seagate CFlash. It's much faster and last a lot longer (write-wise) than a traditional CFlash EEPROM. I always put in a FDD+9-in-1 reader in any system I assemble.
Actually, I was talking about brand/vendors.
Like?
Disks are good for (partial or full) HA, not backup.
I totally disagree.
Fixed disk is _ideal_ for near-line backup. That means the disks stay in one place and they are either always managed, or at least powered regularly. You should _always_ backup from the end-nodes to disk over a network, _never_ directly from end-node to remote tape. You'd do this by sync'ing differences of the end-nodes against the local store of the last backup. I.e., it's an "always diff" backup method. The best near-line disk backup maintains several recent volumes.
Tape is _ideal_ for off-line backup. Ideally this means being fed from an near-line disk backup that is local to the tape drive. That way you can drive it 24x7x365, and generate *0* network traffic. And you typically only do an "always full" backup when it comes to off-line tape. In an enterprise environment with a half-dozen plus servers or more, there is little reason to have more than one tape drive. You're money would be better spent on a dedicated on-line/near-line disk backup solution with one tape drive.
Some people call RAID a backup solution, and that is where mistakes happen.
Or even snapshots for that matter.
RAID and snapshots are on-line. Fixed disk is near-line. Tape is off-line.
In reality, you need _all_ 3.
People dismiss tape because they don't realize that it's just _not_ good for near-line. People dismiss disk because they don't realize it's just _not_ good for off-line. The combination is not only necessary, but _complementary_.
For backups, use tapes.
For _off-line_ backups, use tape cartridge. For _near-line_ backups, use fixed disk. For _on-line_ backup, at least use RAID, if not snapshots.
I see now your line of thinking, but I don't agree with your terminology. Yes, I think tapes and disks are complementary for an avaliability (contingency, if you will) solution.
Fixed disk is ideal for near-line recovery.
Fixed disk allows you to do "always differential" network backup.
Fixed disk is also ideal for feeding as well as verifying or restoring tape cartridge.
Tape is ideal for off-lining data only when you need to.
Tape should be an "always full" backup, and _only_ done locally to where the data is at -- _never_ over the network.
There is a great symbios between near-line and off-line that people don't see.
They get caught up in the fixed disk v. tape -- either people who don't realize that they only hate tape because it sucks at near-line and people who are too focused on disaster recovery from off-line that they fail to see how much better fixed disk is for near-line recovery.
Your solution for a centralized backup server is one I would recomend too, and have even implemented it on the
past.
But how?
Are you streaming from end-node to end-tape over the network during the limited backup window?
Are you at least buffering the process, although that still has some backup window constraints?
Or are you only sending diffs to entire stores on fixed disk, and then only sending full backups to tape only when you need to off-line it?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Dec 07, 2005 at 03:38:21PM -0800, Bryan J. Smith wrote:
Actually, I was talking about brand/vendors.
Like?
Like DDS-4 tapes from HP. I have had about 5% tape failures with those so far, while Sony tapes failures are bellow 1% (for me).
Your solution for a centralized backup server is one I would recomend too, and have even implemented it on the
past.
But how?
Are you streaming from end-node to end-tape over the network during the limited backup window?
Are you at least buffering the process, although that still has some backup window constraints?
Or are you only sending diffs to entire stores on fixed disk, and then only sending full backups to tape only when you need to off-line it?
Replying on this one should answer for all the others, while saving space.
Yes, what I do is use the disk array on the backup server to aggregate all the information that needs to be backed up, and then I put it on the tape. I thus consider the disk array as a aggregation space for the data.
That aggregation, of course, is implemented in different ways depending on the specific requirements and characteristics of each network. Something the aggregation will happen asyncronously during all day, sometimes in a fixed time windows.
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Aleksandar Milivojevic alex@milivojevic.org wrote:
Not true. You can do backup on disk exactly the same way you do them to tape. With tape, you calculate how big your backups are, and for how long you want to keep them. Then you go out and by that many tapes. With disk, you do the same thing and buy disk(s) of appropriate size. If you run out of tapes, you buy more tapes. If you run out of disk space for backup, you buy more disks. Same thing.
No, not the same thing.
Tape is removable and has higher G tolerances than 3.5" fixed disks. It is more portable _and_, unlike commodity disk, it doesn't need to be spindled regularly. 3.5" fixed disk is _not_ viable for storage.
That's why Removable Rigid Disk (RRD) was introduced. It increases shock tolerance, solves the other portability issues, and is designed sit on the shelf. Unfortunately, other than being cheaper than tape in initial cost, it's more costly in media and slower.
That's why the combination of fix disk and tape is _ideal_. You use fixed disk -- recommended "enterprise" 1.0M hour MTBF "near-line" tolerance tested commodity fixed disk -- in a 24x7 backup server. You then take select back-ups from that server and put them to tape -- anything you're going to off-line or take off-site.
Putting everything to tape means you're at the mercy of successful tape backup. That has proven to be a major issue for everyone. Putting everything to disk means you're at the mercy of that disk, and 3.5" commodity disk does _not_ handle G or off-line storage (even just a couple of weeks sometimes) nearly as well.
[ SIDE NOTE: In the worst case, I'd use 2.5" disks that can take higher G tolerances. They even have 5.25" bays that hold six (6) 2.5" hot-swap SATA drives now. ]
Anyhow, cost of single SDLT tape is comparable to cost of disk drive of same capacity.
400GB LTO-3 tape is under $100 by the dozens. The smartest thing I can recommend to companies that have a few servers is build a single backup server with TBs of storage, and then put one (1) LTO-3 tape drive on it.
You sync backups to the disks on that backup server during the nightly backup window. Then you commit select backups to tape whenever you need to off-line something, such as a weekly off-site tape. Use disk for the immediate backup and restores. Use tape for the off-site or when you want to off-line something for retention later.
With a single server, just get extra disk to keep redundancy on disks off-list. Then use a DVD-R and a minimal tape drive (maybe an entry-level VXA) to off-site select itmes.
The user is not going to bother to backup. He'll just blaim you for loosing his email (no matter who's responsibility it was on paper).
There is something to be said about making users responsible, at least in a campus environment of students.
Anyhow, as I said previously, for $100,000 (which would be price of USB sticks) you can buy really fancy storage with really fancy backup solution.
Agreed. Consider something like a Copan Revolution series: http://www.copansys.com/products/index.htm
It's a FalconStor VTL system, which almost everyone uses. It run on Red Hat Linux 7.3. Even Microsoft has one. ;->
Alain Reguera wrote:
I'm getting a little involved now, thanks for replaying guys
Disable Imap and only keep pop3 ?
but how can I grant students' mobility around labs, keeping their Inbox's messages available from one workstation to another?
The suggestions about memory is very useful. I'll put spanassassin and mailscanner but only after a hardware upgrade.
by now I consider: cyrus and postfix
Lose cyrus. That beast has some fancy indexing that can be corrupted.
Forget mailscanner. Use postfix with clamsmtpd and clamav for AV. As for spam, the best defence is NOT to accept spams in the first place. Making good use of RBLs like the SBL, XBL, SORBS RBLs and the other suggestion of using SURBL in spamassassin should keep the spam problem to a minimum and this again is mostly postfix related except for spamassassin.
The suggestions have been very important. I'll continue reading in this direction. Any last comments are also welcome :)
I'll keep the last partitioning, passed 8 hours I'll install, now need a rest :) zZZZ
I would suggest otherwise. Your huge /var/spool/mail suggests that you plan to use the mbox format for storing mails. I suggest that you switch to maildir and therefore trash /var/spool/mail and allocate that lot to /home and use maildir to store your mails.
I would like to keep this topic open, for any new suggestion on a different and new setup on Planning Mail Server (with low resources).
Yes. I suggest running two queues. postfix + clamsmtpd + clamav, first line of defence (RBLs and other gateway blocking). Mails that get through should then be delivered to a qmail queue which will give you very low resource taking processes and a maildir delivery system with the most versatile local delivery agent possible. dovecot can be used as the imap server.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, Dec 06, 2005 at 10:27:24PM +0800, Feizhou wrote:
Forget mailscanner. Use postfix with clamsmtpd and clamav for AV. As for spam, the best defence is NOT to accept spams in the first place. Making good use of RBLs like the SBL, XBL, SORBS RBLs and the other suggestion of using SURBL in spamassassin should keep the spam problem to a minimum and this again is mostly postfix related except for spamassassin.
That depends on how you see it. If you are thinking about the spam ratio, yes, you are correct. RBLs can filter up to 90% of all the spam (in my experience). On the other hand, if you are being targeted by 1000's of spams daily, you will still get a fair number of them.
I would suggest otherwise. Your huge /var/spool/mail suggests that you plan to use the mbox format for storing mails. I suggest that you switch to maildir and therefore trash /var/spool/mail and allocate that lot to /home and use maildir to store your mails.
As I stated before, one of the best things about maildir is that you can use incremental backup procedures. So I second that idea, no matter if you are keeping the maildirs on /home or /var/spool/mail.
Yes. I suggest running two queues. postfix + clamsmtpd + clamav, first line of defence (RBLs and other gateway blocking). Mails that get through should then be delivered to a qmail queue which will give you very low resource taking processes and a maildir delivery system with the most versatile local delivery agent possible. dovecot can be used as the imap server.
Is it really recomended (cost/benefit) to mix two different MTA's ? I never tried that. I just start on the idea that it would simply add too much complexity. Then again, I might be misinformed, and the benefits be enough to make it worth. Care you elaborate a little more on that one, please ?
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, Dec 06, 2005 at 10:27:24PM +0800, Feizhou wrote:
Forget mailscanner. Use postfix with clamsmtpd and clamav for AV. As for spam, the best defence is NOT to accept spams in the first place. Making good use of RBLs like the SBL, XBL, SORBS RBLs and the other suggestion of using SURBL in spamassassin should keep the spam problem to a minimum and this again is mostly postfix related except for spamassassin.
That depends on how you see it. If you are thinking about the spam ratio, yes, you are correct. RBLs can filter up to 90% of all the spam (in my experience). On the other hand, if you are being targeted by 1000's of spams daily, you will still get a fair number of them.
More than 90% is possible in mine :) and it is also a case of being targeted...
Content filtering for spam is one of the worst things to do.
I would suggest otherwise. Your huge /var/spool/mail suggests that you plan to use the mbox format for storing mails. I suggest that you switch to maildir and therefore trash /var/spool/mail and allocate that lot to /home and use maildir to store your mails.
As I stated before, one of the best things about maildir is that you can use incremental backup procedures. So I second that idea, no matter if you are keeping the maildirs on /home or /var/spool/mail.
Keeping them under /home would seem the best. Everything is there. Need to delete? Bye bye /home/goner. But we have forgotten the 2k user part. It appears that this is best implemented using a virtual user/domain/whatever system.
Yes. I suggest running two queues. postfix + clamsmtpd + clamav, first line of defence (RBLs and other gateway blocking). Mails that get through should then be delivered to a qmail queue which will give you very low resource taking processes and a maildir delivery system with the most versatile local delivery agent possible. dovecot can be used as the imap server.
Is it really recomended (cost/benefit) to mix two different MTA's ? I never tried that. I just start on the idea that it would simply add too much complexity. Then again, I might be misinformed, and the benefits be enough to make it worth. Care you elaborate a little more on that one, please ?
It is a case of trying to get the best from both MTAs. A qmail system requires almost zero maintenance. There have been cases of people who install qmail, some without help while others requiring some help, and then forgetting how to do it after a couple or a few years of not even touching it. The only reason for these ones to install qmail again was because of a server replacement. This is for those who do not have to deal with a lot of spam.
qmail is simple, efficient and has a small footprint and can be maintenance free and comes with the best local delivery system available. For these same reasons, it is also the least best for dealing with spam unless you heavily modify it like Yahoo!, the least convenient if you have to deal with mail in the mail queue and is so simple that it lacks what others would consider essential items like smtp-auth and what not. Although it is possible to get these other essential items, it involves choosing from a substantial list of patches and then getting those to apply without breaking one another so it can be a quite an uphill thing for a newcomer.
postfix on the other hand has plenty of features or essential items builtin, is not too hard to configure and also has a very convenient way of handling the queue.
Both come from security experts and those self-same men have got into the mta side of things. Why not put them together? The irony of course is that both men probably hate each other to bits.
The other benefit from this (not necessary to run two different mtas of course) is that you get two queues which means you can separate incoming and outgoing traffic. incoming traffic ends up in qmail and outgoing traffic stay in the postfix queue.
Just telling postfix to send all incoming mails to the qmail queue should not be complex. Then you can manage the two on their own.
On Tue, 2005-12-06 at 10:18, Feizhou wrote:
Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, Dec 06, 2005 at 10:27:24PM +0800, Feizhou wrote:
That depends on how you see it. If you are thinking about the spam ratio, yes, you are correct. RBLs can filter up to 90% of all the spam (in my experience). On the other hand, if you are being targeted by 1000's of spams daily, you will still get a fair number of them.
More than 90% is possible in mine :) and it is also a case of being targeted...
Content filtering for spam is one of the worst things to do.
That is why I like greylisting. Very little resources required and in my experience it blocks 98% or better of the spam I see. Prior to that there would be days when a spam storm would hit and backup email for several hours. Spamassassin did a good job of sorting it out but it took all of the systems resources to handle it.
And with greylisting you are not dependent on someone else's RBL lists or connectivity to a system somewhere on the Internet. Once setup it has required little if any additional admin work to keep it running. It actually allowed me to pretty much get out of the business of fighting spam which had started to consume a large amount of my time.
And with the combination of greylisting and spamassassin it is rare that any spam gets through to an end user.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, Dec 06, 2005 at 10:36:12AM -0500, Scot L. Harris wrote:
That depends on how you see it. If you are thinking about the spam ratio, yes, you are correct. RBLs can filter up to 90% of all the spam (in my experience). On the other hand, if you are being targeted by 1000's of spams daily, you will still get a fair number of them.
More than 90% is possible in mine :) and it is also a case of being targeted...
Content filtering for spam is one of the worst things to do.
That is why I like greylisting. Very little resources required and in my experience it blocks 98% or better of the spam I see. Prior to that there would be days when a spam storm would hit and backup email for several hours. Spamassassin did a good job of sorting it out but it took all of the systems resources to handle it.
And with greylisting you are not dependent on someone else's RBL lists or connectivity to a system somewhere on the Internet. Once setup it has required little if any additional admin work to keep it running. It actually allowed me to pretty much get out of the business of fighting spam which had started to consume a large amount of my time.
And with the combination of greylisting and spamassassin it is rare that any spam gets through to an end user.
There are many definitions of graylisting. But since the "click here to validate your e-mail" is the most common on the mind of the people I have contact with, I'll assume that is the (main) one you are reffering to. Please correct me if I'm wrong.
When I send e-mail and I get back a message like that, 90% of the time I'll simply ignore it. The other 10% is when there is some money for me relatated to the e-mail I'm sending.
A secondary problem is that practice will for users to click on links on e-mails, which is not something I want my users doing without thinking about. Good habits are to be cultivated, and bad habits are to be avoided at all costs (says the guy who smokes 2 packs a day :)).
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Rodrigo Barbosa wrote:
There are many definitions of graylisting. But since the "click here to validate your e-mail" is the most common on the mind of the people I have contact with, I'll assume that is the (main) one you are reffering to. Please correct me if I'm wrong.
That's not greylisting.
The only definition I've seen is at http://greylisting.org/
-- Rex
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, Dec 06, 2005 at 10:10:17AM -0600, Rex Dieter wrote:
There are many definitions of graylisting. But since the "click here to validate your e-mail" is the most common on the mind of the people I have contact with, I'll assume that is the (main) one you are reffering to. Please correct me if I'm wrong.
That's not greylisting.
The only definition I've seen is at http://greylisting.org/
Oh, I see.
I would not call that greylisting, but it is a nice idea.
Tkx for the link.
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Rodrigo Barbosa wrote:
On Tue, Dec 06, 2005 at 10:10:17AM -0600, Rex Dieter wrote:
That's not greylisting.
The only definition I've seen is at http://greylisting.org/
Oh, I see.
I would not call that greylisting, but it is a nice idea.
The explanation at above link is exactly what greylisting is. The thing you described (where confirmation from sender is needed) is not greylisting.
On Tue, 2005-12-06 at 10:50, Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, Dec 06, 2005 at 10:36:12AM -0500, Scot L. Harris wrote:
That is why I like greylisting. Very little resources required and in my experience it blocks 98% or better of the spam I see. Prior to that there would be days when a spam storm would hit and backup email for several hours. Spamassassin did a good job of sorting it out but it took all of the systems resources to handle it.
And with greylisting you are not dependent on someone else's RBL lists or connectivity to a system somewhere on the Internet. Once setup it has required little if any additional admin work to keep it running. It actually allowed me to pretty much get out of the business of fighting spam which had started to consume a large amount of my time.
And with the combination of greylisting and spamassassin it is rare that any spam gets through to an end user.
There are many definitions of graylisting. But since the "click here to validate your e-mail" is the most common on the mind of the people I have contact with, I'll assume that is the (main) one you are reffering to. Please correct me if I'm wrong.
When I send e-mail and I get back a message like that, 90% of the time I'll simply ignore it. The other 10% is when there is some money for me relatated to the e-mail I'm sending.
A secondary problem is that practice will for users to click on links on e-mails, which is not something I want my users doing without thinking about. Good habits are to be cultivated, and bad habits are to be avoided at all costs (says the guy who smokes 2 packs a day :)).
No no no! That is not the greylisting I am talking about. You implement greylisting on your MTA using something like milter-greylist. This uses standard RFC compliant behavior documented for MTAs to block most zombie systems which send spam from send to your MTA. The way it works is when a server connects to your system to deliver email your system sends a temporary failure notice. Prior to sending the temp fail it stores the IP address of the server, the sender, and the recipient of the message (a tuple). This tuple is stored and a timer is set. I used 2 minutes, the default is normally 30 minutes. I found 2 minutes worked just as well. That 2 minute timer is a delay imposed before your MTA will accept that message from the remote server. The remote server may retry very quickly or retry in 30 minutes. Eventually a proper MTA will retry the message. Once the delay period has expired your MTA will accept and deliver the message.
The way this blocks 98% or more of the spam out there is zombie machines spewing spam do not abide by the standard MTA rules. They generally dump and run and do not retry messages. I was amazed at how effective this method is.
You benefit by not having to read the body of the message or incur the overhead of processing those messages through spamassassin or other spam filter or additional network traffic by querying RBL lists.
You can also put specific IPs or addresses in a whitelist so those will not have to go through the greylist process. The time an entry is auto whitelisted can be adjusted as well. I usually have this set to 48 hours. Any additional messages for that same tuple in that 48 hour period won't be delayed again.
The combination of greylisting and spamassassin provide about as close to 100% spam elimination as any other method I have seen.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, Dec 06, 2005 at 12:00:15PM -0500, Scot L. Harris wrote:
No no no! That is not the greylisting I am talking about.
I saw the link to http://www.greylisting.org/. Looks interesting. I'll give it a thought of implementing later this week. All Exim based implementations listed are very flawed. Looks like I'll have to cook one myself :)
The combination of greylisting and spamassassin provide about as close to 100% spam elimination as any other method I have seen.
Looks like it. Will have to give it a try :)
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, Dec 06, 2005 at 11:18:41PM +0800, Feizhou wrote:
I would suggest otherwise. Your huge /var/spool/mail suggests that you plan to use the mbox format for storing mails. I suggest that you switch to maildir and therefore trash /var/spool/mail and allocate that lot to /home and use maildir to store your mails.
As I stated before, one of the best things about maildir is that you can use incremental backup procedures. So I second that idea, no matter if you are keeping the maildirs on /home or /var/spool/mail.
Keeping them under /home would seem the best. Everything is there. Need to delete? Bye bye /home/goner. But we have forgotten the 2k user part. It appears that this is best implemented using a virtual user/domain/whatever system.
I implemented that once using exim + Mysql + Courrier. Yes, it is MUCH easier to maintain once you have it all up and running. Adding and removing users (simply PHP webpage) was a nobrainer.
Is it really recomended (cost/benefit) to mix two different MTA's ? I never tried that. I just start on the idea that it would simply add too much complexity. Then again, I might be misinformed, and the benefits be enough to make it worth. Care you elaborate a little more on that one, please ?
It is a case of trying to get the best from both MTAs. A qmail system requires almost zero maintenance. There have been cases of people who install qmail, some without help while others requiring some help, and then forgetting how to do it after a couple or a few years of not even touching it. The only reason for these ones to install qmail again was because of a server replacement. This is for those who do not have to deal with a lot of spam.
I find it a liability to just leave an e-mail server like that. Putting asside the "qmail is 100% secure idea", which I really won't debate, you have to agree that qmail needs a lot of 3rd party software to work on an environment like that (vpopmail etc etc). And those require maintenance, not to mention the database backend.
Performancewise, I consider (from the tests I ran for Conectiva back in 2000) qmail the second fastest non-commercial MTA. The fastests being exim. Commercial solutions like S/MAIL will beat them all to the ground, and S/MAIL is the basis of Exim just like QMail is the basis for Postfix.
Let me make it plain once again: I'm not recomending exim for his e-mail server. Learning to get exim running "just right" is not easy. Exim 4 is very complex these days, specially if you add ACL to the mix. I used to edit sendmail.cf using VI (not vim), so I can recognize complexity when I see it :) The old saying goes that you can only consider yourself a network administrator if you ever edited sendmail.cf by hand once. If you did it twice, you are not a network admnistrator, you are a lunatic, and should be commited to a mental institution :)
Anyway, I think your solution, even tho it does have many merits, will add unneeded complexity to Alain's setup.
Let me also mention that I do think a multiple server solution is best, specially if you can, as you mentioned, separate incoming from outgoing queues.
qmail is simple, efficient and has a small footprint (...)
I won't argue about efficent and small footprint, specially the later, but simple it isn't.
The most simple (as in straightforward) MTA I've seen so far is postfix. And no, I never use it.
maintenance free and
comes with the best local delivery system available.
<flamewar invitation> Procmail ? Sure it does. But so does every other MTA :) </flamewar>
postfix on the other hand has plenty of features or essential items builtin, is not too hard to configure and also has a very convenient way of handling the queue.
We agree on more than we disagree.
Postfix is all that. It is not the best solution, but it is the one I recomend for non-experienced MTA admins.
Both come from security experts and those self-same men have got into the mta side of things. Why not put them together? The irony of course is that both men probably hate each other to bits.
Hating DJB is more common than not :)
Just telling postfix to send all incoming mails to the qmail queue should not be complex. Then you can manage the two on their own.
Despite the merits of qmail or the configuration you are proposing, I don't think it is the best solution for this particular user on this particular environment.
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Rodrigo Barbosa wrote:
Performancewise, I consider (from the tests I ran for Conectiva back in 2000) qmail the second fastest non-commercial MTA. The fastests being exim. Commercial solutions like S/MAIL will beat them all to the ground, and S/MAIL is the basis of Exim just like QMail is the basis for Postfix.
Actually, postfix was written from scratch by Wietse Venema (developer of TCP Wrappers) and has nothing at all to do with Qmail. As a matter of fact, Dan and Wietse don't seem to enjoy good relations (Dan is a pain in the ass to deal with if you ask me). I wouldn't recommend qmail to anyone, and certainly not a beginner. Postfix comes with CentOS and will be a lot easier to integrate and maintain.
Cheers,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, Dec 06, 2005 at 11:11:47AM -0500, Chris Mauritz wrote:
Performancewise, I consider (from the tests I ran for Conectiva back in 2000) qmail the second fastest non-commercial MTA. The fastests being exim. Commercial solutions like S/MAIL will beat them all to the ground, and S/MAIL is the basis of Exim just like QMail is the basis for Postfix.
Actually, postfix was written from scratch by Wietse Venema (developer of TCP Wrappers) and has nothing at all to do with Qmail. As a matter of fact, Dan and Wietse don't seem to enjoy good relations (Dan is a pain in the ass to deal with if you ask me). I wouldn't recommend qmail to anyone, and certainly not a beginner. Postfix comes with CentOS and will be a lot easier to integrate and maintain.
You are both right and wrong.
Qmail is the basis of postfix, as I said, but Qmail source is not used on Postfix, the same way S/Mail source is not used on exim.
The main reason Wietse started working on Postfix was because there were lots of important features (I agree with him) that DJB would not accept on qmail, not to mention licensing problems. Wietse used to develop qmail patches before starting postfix.
So yes, you are right, Postfix was developed from scratch. But you are wrong when you say qmail was not the basis for postfix.
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
IMHO, I'd go with XMail (http://www.xmailserver.org). It's the easy'est to setup and maintain. all virtual accounts. and it's all contained in 1 directory for easy backup/restore and portability (it can also run under windows).
I've used : Postfix (although simple to setup with system accounts, I found it to be more complicated then it needed to be.). Qmail (as long as you take the qtoaster route it's a simple thing to setup. as long you do what the guides tell you. And using with tools like qmailadmin it's the simplest to maintain) Sendmail (well this dog of a mail server it just over complicated all the way around.) XMail (by far the simplest, smallest, and most versatile gpl mail system out there).
and as far as imap / pop3 server go I always use dovecot. really for the same reason I use Xmail, it's simple,small and fast !
On Tue, 2005-12-06 at 10:33, Rodrigo Barbosa wrote:
So yes, you are right, Postfix was developed from scratch. But you are wrong when you say qmail was not the basis for postfix.
I think a better description of the history would be to say that qmail was so bad that Wietse started from scratch to write something useful. And meanwhile, the problems with sendmail that they both set out to fix were solved anyway.
Les Mikesell wrote:
On Tue, 2005-12-06 at 10:33, Rodrigo Barbosa wrote:
So yes, you are right, Postfix was developed from scratch. But you are wrong when you say qmail was not the basis for postfix.
I think a better description of the history would be to say that qmail was so bad that Wietse started from scratch to write something useful. And meanwhile, the problems with sendmail that they both set out to fix were solved anyway.
Have you tried sendmail X then?
On Tue, 2005-12-06 at 12:31, Feizhou wrote:
Les Mikesell wrote:
On Tue, 2005-12-06 at 10:33, Rodrigo Barbosa wrote:
So yes, you are right, Postfix was developed from scratch. But you are wrong when you say qmail was not the basis for postfix.
I think a better description of the history would be to say that qmail was so bad that Wietse started from scratch to write something useful. And meanwhile, the problems with sendmail that they both set out to fix were solved anyway.
Have you tried sendmail X then?
No, but I don't have a problem with stock sendmail now that it runs mostly as a non-root user, always splits the reception and delivery steps, and has the milter interface to chat with other even less-privileged programs during the SMTP conversation.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Dec 07, 2005 at 02:31:08AM +0800, Feizhou wrote:
Les Mikesell wrote:
On Tue, 2005-12-06 at 10:33, Rodrigo Barbosa wrote:
So yes, you are right, Postfix was developed from scratch. But you are wrong when you say qmail was not the basis for postfix.
I think a better description of the history would be to say that qmail was so bad that Wietse started from scratch to write something useful. And meanwhile, the problems with sendmail that they both set out to fix were solved anyway.
Have you tried sendmail X then?
I did.
Still slow as hell (about 1/3 of delivery speed you get with postfix).
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Les Mikesell wrote:
On Tue, 2005-12-06 at 10:33, Rodrigo Barbosa wrote:
So yes, you are right, Postfix was developed from scratch. But you are wrong when you say qmail was not the basis for postfix.
I think a better description of the history would be to say that qmail was so bad that Wietse started from scratch to write something useful. And meanwhile, the problems with sendmail that they both set out to fix were solved anyway.
Heh. Sendmail really was awful back then (mid-late '90's). It's gotten a lot better, but it is still comparatively slow and resource hungry.
Cheers,
On Tue, 2005-12-06 at 17:16, Chris Mauritz wrote:
I think a better description of the history would be to say that qmail was so bad that Wietse started from scratch to write something useful. And meanwhile, the problems with sendmail that they both set out to fix were solved anyway.
Heh. Sendmail really was awful back then (mid-late '90's). It's gotten a lot better, but it is still comparatively slow and resource hungry.
Sendmail should always be waiting for network or disk i/o anyway and the only thing really wrong is if your outbound queue becomes huge it can be slow to search. If your setup is on that scale you can make it use multiple queues. Anyway it is silly to even think about the resource consumption of the MTA itself if you are planning to run spamassassin.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, Dec 06, 2005 at 12:12:07PM -0600, Les Mikesell wrote:
On Tue, 2005-12-06 at 10:33, Rodrigo Barbosa wrote:
So yes, you are right, Postfix was developed from scratch. But you are wrong when you say qmail was not the basis for postfix.
I think a better description of the history would be to say that qmail was so bad that Wietse started from scratch to write something useful. And meanwhile, the problems with sendmail that they both set out to fix were solved anyway.
Wietse didn't write postfix because of qmail, but because of DJB.
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On Tue, 6 Dec 2005, Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, Dec 06, 2005 at 12:12:07PM -0600, Les Mikesell wrote:
On Tue, 2005-12-06 at 10:33, Rodrigo Barbosa wrote:
So yes, you are right, Postfix was developed from scratch. But you are wrong when you say qmail was not the basis for postfix.
I think a better description of the history would be to say that qmail was so bad that Wietse started from scratch to write something useful. And meanwhile, the problems with sendmail that they both set out to fix were solved anyway.
Wietse didn't write postfix because of qmail, but because of DJB.
What does any of this have to do with centos? PLEASE stop the useless history lesson. The s/n ratio on this list has been extreamly poor during the last few weeks. Can we please get back to meaningful discussions or in the absence of that have some quiet?
Regards,
Tom
Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, Dec 06, 2005 at 11:11:47AM -0500, Chris Mauritz wrote:
Performancewise, I consider (from the tests I ran for Conectiva back in 2000) qmail the second fastest non-commercial MTA. The fastests being exim. Commercial solutions like S/MAIL will beat them all to the ground, and S/MAIL is the basis of Exim just like QMail is the basis for Postfix.
Actually, postfix was written from scratch by Wietse Venema (developer of TCP Wrappers) and has nothing at all to do with Qmail. As a matter of fact, Dan and Wietse don't seem to enjoy good relations (Dan is a pain in the ass to deal with if you ask me). I wouldn't recommend qmail to anyone, and certainly not a beginner. Postfix comes with CentOS and will be a lot easier to integrate and maintain.
You are both right and wrong.
Qmail is the basis of postfix, as I said, but Qmail source is not used on Postfix, the same way S/Mail source is not used on exim.
The main reason Wietse started working on Postfix was because there were lots of important features (I agree with him) that DJB would not accept on qmail, not to mention licensing problems. Wietse used to develop qmail patches before starting postfix.
So yes, you are right, Postfix was developed from scratch. But you are wrong when you say qmail was not the basis for postfix.
I suspect Wietse would take issue with your definition of "comes from." That's like saying "Mr. X started out writing device driver patches for the linux kernel...so any subsequent software he writes must come from Linux." Postfix is VERY different than qmail. My biggest problem with qmail, other than djb's bad attitude is that you're forced to install a lot of other utilities to make it work. Also, if you want to keep your CentOS system updated with a simple "yum update" that's not going to be an option for you if you want to use non-standard tools like qmail.
Cheers,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, Dec 06, 2005 at 06:08:20PM -0500, Chris Mauritz wrote:
So yes, you are right, Postfix was developed from scratch. But you are wrong when you say qmail was not the basis for postfix.
I suspect Wietse would take issue with your definition of "comes from."
I hope he would. That is why I didn't say "comes from", which would mean it was derived from qmail. It was not.
That's like saying "Mr. X started out writing device driver patches for the linux kernel...so any subsequent software he writes must come from Linux."
That is not what I said, as I'm sure you know, since you read it.
Postfix is VERY different than qmail.
Care to compare Exim with S/Mail ? They are VERY different. Never the less, S/Mail was the basis of Exim.
Just check pre-1.0 versions of both (Postfix and Exim) and you will see what I mean.
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
I find it a liability to just leave an e-mail server like that. Putting asside the "qmail is 100% secure idea", which I really won't debate, you have to agree that qmail needs a lot of 3rd party software to work on an environment like that (vpopmail etc etc). And those require maintenance, not to mention the database backend.
vpopmail does not require maintenance. add a domain in his case would be like once in a blue moon, ditto remove. mysql is one of the most easy to maintain...the thing usually keeps running even after a crash.
Performancewise, I consider (from the tests I ran for Conectiva back in 2000) qmail the second fastest non-commercial MTA. The fastests being exim. Commercial solutions like S/MAIL will beat them all to the ground, and S/MAIL is the basis of Exim just like QMail is the basis for Postfix.
sendmail led to qmail led to postfix
I am sure exim fits somewhere :D
Let me make it plain once again: I'm not recomending exim for his e-mail server. Learning to get exim running "just right" is not easy. Exim 4 is very complex these days, specially if you add ACL to the mix. I used to edit sendmail.cf using VI (not vim), so I can recognize complexity when I see it :) The old saying goes that you can only consider yourself a network administrator if you ever edited sendmail.cf by hand once. If you did it twice, you are not a network admnistrator, you are a lunatic, and should be commited to a mental institution :)
Hear hear. Glad I got sendmail chucked out...we had a mysql enabled version.
Anyway, I think your solution, even tho it does have many merits, will add unneeded complexity to Alain's setup.
He still needs a virtual backend. Either learn to use someone else's tools or make your own...
Let me also mention that I do think a multiple server solution is best, specially if you can, as you mentioned, separate incoming from outgoing queues.
agreed.
qmail is simple, efficient and has a small footprint (...)
I won't argue about efficent and small footprint, specially the later, but simple it isn't.
Simple it is. There is absolutely NOTHING to do after initial installation and configuration. Oh, you meant the setup? Well, some manage with help, others won't get anywhere without.
The most simple (as in straightforward) MTA I've seen so far is postfix. And no, I never use it.
Sorry, I use both and sendmail too and I do not agree. qmail is by far the most simple.
maintenance free and
comes with the best local delivery system available.
<flamewar invitation> Procmail ? Sure it does. But so does every other MTA :) </flamewar>
AH, we have a slight misunderstanding here. procmail don't handle .forward files I believe. procmail is a filtering program. Its competitor/comparison would be maildrop for which I'd vouch for given procmail's cpu hogging properties.
.forward simply does not match .qmail
postfix on the other hand has plenty of features or essential items builtin, is not too hard to configure and also has a very convenient way of handling the queue.
We agree on more than we disagree.
Postfix is all that. It is not the best solution, but it is the one I recomend for non-experienced MTA admins.
Hear hear.
Both come from security experts and those self-same men have got into the mta side of things. Why not put them together? The irony of course is that both men probably hate each other to bits.
Hating DJB is more common than not :)
Haha
Just telling postfix to send all incoming mails to the qmail queue should not be complex. Then you can manage the two on their own.
Despite the merits of qmail or the configuration you are proposing, I don't think it is the best solution for this particular user on this particular environment.
Well he is better off not doing a system account = email account management system in my opinion.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Dec 07, 2005 at 12:17:45AM +0800, Feizhou wrote:
Performancewise, I consider (from the tests I ran for Conectiva back in 2000) qmail the second fastest non-commercial MTA. The fastests being exim. Commercial solutions like S/MAIL will beat them all to the ground, and S/MAIL is the basis of Exim just like QMail is the basis for Postfix.
sendmail led to qmail led to postfix
I am sure exim fits somewhere :D
Actually, exim somes from S/Mail :)
Anyway, I think your solution, even tho it does have many merits, will add unneeded complexity to Alain's setup.
He still needs a virtual backend. Either learn to use someone else's tools or make your own...
If he really opts for a virtual backend, and he doesn't have a problem with "blackbox" solutions, there are some nice ones based on qmail. I would never use it, but some people use and like it.
qmail is simple, efficient and has a small footprint (...)
I won't argue about efficent and small footprint, specially the later, but simple it isn't.
Simple it is. There is absolutely NOTHING to do after initial installation and configuration. Oh, you meant the setup? Well, some manage with help, others won't get anywhere without.
I have installed qmail twice. Trying to get any HA system in place with it was a nightmare.
The most simple (as in straightforward) MTA I've seen so far is postfix. And no, I never use it.
Sorry, I use both and sendmail too and I do not agree. qmail is by far the most simple.
You are entited to your opinion and maybe it really is the most simply for you. It will depend on many factors.
The more simple things are the things that make sense for us. Things that work the say we expect them to work, doing so in a way we find logical.
For me, the most simple MTA is Exim. But I don't repeat that often, cause I know that is not true for most people. For most people I ever talked to, postfix is the most simple one.
But I can symptize with you. I (me, myself) find postfix a pain to configure.
maintenance free and
comes with the best local delivery system available.
<flamewar invitation> Procmail ? Sure it does. But so does every other MTA :) </flamewar>
AH, we have a slight misunderstanding here. procmail don't handle .forward files I believe. procmail is a filtering program. Its competitor/comparison would be maildrop for which I'd vouch for given procmail's cpu hogging properties.
.forward simply does not match .qmail
Oh. .forward has nothing to do with "local delivery". You are correct in comparing procmail with maildrop. Those are the one we can classify as "local delivery system".
But yes, if you are comparing ".forward" with ".qmail", you are correct. Myself, I like ".procmailrc" better :) Or .exim_filter, which can be configured, but I really don't recomend. Exim filters are so "powerful" that I tend to consider them more of a security problem than a feature. I'm just happy they are not enabled by default, and even take a little doing to get running.
postfix on the other hand has plenty of features or essential items builtin, is not too hard to configure and also has a very convenient way of handling the queue.
We agree on more than we disagree.
Postfix is all that. It is not the best solution, but it is the one I recomend for non-experienced MTA admins.
Hear hear.
Both come from security experts and those self-same men have got into the mta side of things. Why not put them together? The irony of course is that both men probably hate each other to bits.
Hating DJB is more common than not :)
Haha
I'm pretty sure if he knew me, he would hate me too. I'm very easy to hate, as I trust you already found out :)
Just telling postfix to send all incoming mails to the qmail queue should not be complex. Then you can manage the two on their own.
Despite the merits of qmail or the configuration you are proposing, I don't think it is the best solution for this particular user on this particular environment.
Well he is better off not doing a system account = email account management system in my opinion.
I agree with you. "system account = email account" is only good for very small systems (up to 20 mailboxes or so).
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Dec 07, 2005 at 12:17:45AM +0800, Feizhou wrote:
Performancewise, I consider (from the tests I ran for Conectiva back in 2000) qmail the second fastest non-commercial MTA. The fastests being exim. Commercial solutions like S/MAIL will beat them all to the ground, and S/MAIL is the basis of Exim just like QMail is the basis for Postfix.
sendmail led to qmail led to postfix
I am sure exim fits somewhere :D
Actually, exim somes from S/Mail :)
From smail's page: Smail-3 was written as a Sendmail replacement for 'normal' people
normal was italized. I remembered there was a connection some where :D
Anyway, I think your solution, even tho it does have many merits, will add unneeded complexity to Alain's setup.
He still needs a virtual backend. Either learn to use someone else's tools or make your own...
If he really opts for a virtual backend, and he doesn't have a problem with "blackbox" solutions, there are some nice ones based on qmail. I would never use it, but some people use and like it.
Well, it probably just that I have not seen one for postfix yet, not that i looked....
qmail is simple, efficient and has a small footprint (...)
I won't argue about efficent and small footprint, specially the later, but simple it isn't.
Simple it is. There is absolutely NOTHING to do after initial installation and configuration. Oh, you meant the setup? Well, some manage with help, others won't get anywhere without.
I have installed qmail twice. Trying to get any HA system in place with it was a nightmare.
HA? No way with any other MTA unless you have some form of centralized delivery information for the mta to a SAN/FC/NFS (ack!)/some form of shared storage.
The most simple (as in straightforward) MTA I've seen so far is postfix. And no, I never use it.
Sorry, I use both and sendmail too and I do not agree. qmail is by far the most simple.
You are entited to your opinion and maybe it really is the most simply for you. It will depend on many factors.
The more simple things are the things that make sense for us. Things that work the say we expect them to work, doing so in a way we find logical.
For me, the most simple MTA is Exim. But I don't repeat that often, cause I know that is not true for most people. For most people I ever talked to, postfix is the most simple one.
But I can symptize with you. I (me, myself) find postfix a pain to configure.
I don't find postfix a pain to configure...besides Devdas and one of my managers, there is no other postfix guy where i work. We do have an exim guy :D. postfix requires more reading to maintain and configure. It gets an unfair advantage by being preinstalled and preconfigured for system account delivery and thereby making it appear simple.
maintenance free and
comes with the best local delivery system available.
<flamewar invitation> Procmail ? Sure it does. But so does every other MTA :) </flamewar>
AH, we have a slight misunderstanding here. procmail don't handle .forward files I believe. procmail is a filtering program. Its competitor/comparison would be maildrop for which I'd vouch for given procmail's cpu hogging properties.
.forward simply does not match .qmail
Oh. .forward has nothing to do with "local delivery". You are correct in comparing procmail with maildrop. Those are the one we can classify as "local delivery system".
how can you say that? .forward provides delivery instructions for locally delivered mails so how come you say that it has nothing to do with "local delivery"?
But yes, if you are comparing ".forward" with ".qmail", you are correct. Myself, I like ".procmailrc" better :) Or .exim_filter, which can be configured, but I really don't recomend. Exim filters are so "powerful" that I tend to consider them more of a security problem than a feature. I'm just happy they are not enabled by default, and even take a little doing to get running.
So exim has its own filtering agent too? I must look at exim one day.
Hmm...probably time to take this offlist if we continue :P
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Dec 07, 2005 at 01:06:39AM +0800, Feizhou wrote:
sendmail led to qmail led to postfix
I am sure exim fits somewhere :D
Actually, exim somes from S/Mail :)
From smail's page: Smail-3 was written as a Sendmail replacement for 'normal' people normal was italized. I remembered there was a connection some where :D
:)
Anyway, I think your solution, even tho it does have many merits, will add unneeded complexity to Alain's setup.
He still needs a virtual backend. Either learn to use someone else's tools or make your own...
If he really opts for a virtual backend, and he doesn't have a problem with "blackbox" solutions, there are some nice ones based on qmail. I would never use it, but some people use and like it.
Well, it probably just that I have not seen one for postfix yet, not that i looked....
Me neither. I have been running e-mail server for so long, that I really don't care about these "blackbox" solutions. They are more trouble than they are worth.
Simple it is. There is absolutely NOTHING to do after initial installation and configuration. Oh, you meant the setup? Well, some manage with help, others won't get anywhere without.
I have installed qmail twice. Trying to get any HA system in place with it was a nightmare.
HA? No way with any other MTA unless you have some form of centralized delivery information for the mta to a SAN/FC/NFS (ack!)/some form of shared storage.
EMC storage if you have the cash. AFS if you don't.
NFS is as unreliable as it gets.
But I can symptize with you. I (me, myself) find postfix a pain to configure.
I don't find postfix a pain to configure...besides Devdas and one of my managers, there is no other postfix guy where i work. We do have an exim guy :D. postfix requires more reading to maintain and configure. It gets an unfair advantage by being preinstalled and preconfigured for system account delivery and thereby making it appear simple.
Yeah, the bastards :)
Actually, as long as you have a sound base system (qmail, exim, postfix, even zmailer), and someone with a few years experience, you can always get a good system.
AH, we have a slight misunderstanding here. procmail don't handle .forward files I believe. procmail is a filtering program. Its competitor/comparison would be maildrop for which I'd vouch for given procmail's cpu hogging properties.
.forward simply does not match .qmail
Oh. .forward has nothing to do with "local delivery". You are correct in comparing procmail with maildrop. Those are the one we can classify as "local delivery system".
how can you say that? .forward provides delivery instructions for locally delivered mails so how come you say that it has nothing to do with "local delivery"?
Actually, .forward provides intra-MTA routing instructions, not delivery instructions :)
I agree "nothing to do" was a little strong worded, since everything has to do with local delivery. That is, after all, what the whole e-mail system is about.
But yes, if you are comparing ".forward" with ".qmail", you are correct. Myself, I like ".procmailrc" better :) Or .exim_filter, which can be configured, but I really don't recomend. Exim filters are so "powerful" that I tend to consider them more of a security problem than a feature. I'm just happy they are not enabled by default, and even take a little doing to get running.
So exim has its own filtering agent too? I must look at exim one day.
Yup. You can even use it to do most things people usually do with amavis. I have a server where I implemented individual message size limiting, so each group of uses will have a different limit, entirely based on exim filters.
Of course, exim is monolitic, so I would not say it has its own filtering agent. It has a filtering system :)
Actually, you can do almost everything you get from procmail with exim filters. I'm just used to write procmail rules, and have a huge database of those, so I keep using it for the sake of simplicity (and not reinventing the weel).
Hmm...probably time to take this offlist if we continue :P
Nah. No one started screaming yet, or even compared us to Bryan. So we still have some room :)
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Me neither. I have been running e-mail server for so long, that I really don't care about these "blackbox" solutions. They are more trouble than they are worth.
Except when they are well done. vpopmail, vmailmgr...don't exim also have something written for it to manage virtual mailboxes?
I don't find postfix a pain to configure...besides Devdas and one of my managers, there is no other postfix guy where i work. We do have an exim guy :D. postfix requires more reading to maintain and configure. It gets an unfair advantage by being preinstalled and preconfigured for system account delivery and thereby making it appear simple.
Yeah, the bastards :)
Actually, as long as you have a sound base system (qmail, exim, postfix, even zmailer), and someone with a few years experience, you can always get a good system.
where did sendmail go? =)
Oh. .forward has nothing to do with "local delivery". You are correct in comparing procmail with maildrop. Those are the one we can classify as "local delivery system".
how can you say that? .forward provides delivery instructions for locally delivered mails so how come you say that it has nothing to do with "local delivery"?
Actually, .forward provides intra-MTA routing instructions, not delivery instructions :)
Please stop muddling things for newbies. A line with a pipe in the .forward file means deliver mail to program through a pipe. A line with a path means deliver a copy to this mailbox and a line with an email address means forward a copy to the email address.
You are mixing up 'mailertables' on sendmail, 'transports' on postfix and 'smtproutes' on qmail with .forward/.qmail local delivery instruction files.
I agree "nothing to do" was a little strong worded, since everything has to do with local delivery. That is, after all, what the whole e-mail system is about.
-_-. "intra-MTA routing" has nothing to do with local delivery...
Hmm...probably time to take this offlist if we continue :P
Nah. No one started screaming yet, or even compared us to Bryan. So we still have some room :)
Anyway, nice to see that Bryan is still on the list.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Dec 07, 2005 at 01:52:18AM +0800, Feizhou wrote:
Me neither. I have been running e-mail server for so long, that I really don't care about these "blackbox" solutions. They are more trouble than they are worth.
Except when they are well done. vpopmail, vmailmgr...don't exim also have something written for it to manage virtual mailboxes?
Exim itself does that.
And vpopmail is not a blackbox solution :)
Actually, as long as you have a sound base system (qmail, exim, postfix, even zmailer), and someone with a few years experience, you can always get a good system.
where did sendmail go? =)
Got lost on the "sound base system" part :)
Actually, .forward provides intra-MTA routing instructions, not delivery instructions :)
Please stop muddling things for newbies. A line with a pipe in the .forward file means deliver mail to program through a pipe. A line with a path means deliver a copy to this mailbox and a line with an email address means forward a copy to the email address.
You are mixing up 'mailertables' on sendmail, 'transports' on postfix and 'smtproutes' on qmail with .forward/.qmail local delivery instruction files.
No, I'm not. .forward/.qmail will provide instructions for the MTA. They don't do delivery, so they are not a "local delivery system".
I agree "nothing to do" was a little strong worded, since everything has to do with local delivery. That is, after all, what the whole e-mail system is about.
-_-. "intra-MTA routing" has nothing to do with local delivery...
Depend on the final routing target, which can be local delivery.
Hmm...probably time to take this offlist if we continue :P
Nah. No one started screaming yet, or even compared us to Bryan. So we still have some room :)
Anyway, nice to see that Bryan is still on the list.
LOL.
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Dec 07, 2005 at 01:52:18AM +0800, Feizhou wrote:
Me neither. I have been running e-mail server for so long, that I really don't care about these "blackbox" solutions. They are more trouble than they are worth.
Except when they are well done. vpopmail, vmailmgr...don't exim also have something written for it to manage virtual mailboxes?
Exim itself does that.
And vpopmail is not a blackbox solution :)
Ah, i wondered what you meant.
Actually, .forward provides intra-MTA routing instructions, not delivery instructions :)
Please stop muddling things for newbies. A line with a pipe in the .forward file means deliver mail to program through a pipe. A line with a path means deliver a copy to this mailbox and a line with an email address means forward a copy to the email address.
You are mixing up 'mailertables' on sendmail, 'transports' on postfix and 'smtproutes' on qmail with .forward/.qmail local delivery instruction files.
No, I'm not. .forward/.qmail will provide instructions for the MTA. They don't do delivery, so they are not a "local delivery system".
Hmm...ok. dot-whatever != local delivery agent. I guess I should say it boils down to what qmail-local and its dot-qmail mechanism does compared with the pairing of sendmail's local mailer and its dot-forward mechanism and postfix's local (that is what its LDA is called) support of sendmail's dot-forward.
I agree "nothing to do" was a little strong worded, since everything has to do with local delivery. That is, after all, what the whole e-mail system is about.
-_-. "intra-MTA routing" has nothing to do with local delivery...
Depend on the final routing target, which can be local delivery.
=D. Got me there. The only exception being qmail...once a message is queued, its routing has been set whereas you can still change that if it were postfix, sendmail and I guess exim.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Dec 07, 2005 at 12:22:39PM +0800, Feizhou wrote:
Me neither. I have been running e-mail server for so long, that I really don't care about these "blackbox" solutions. They are more trouble than they are worth.
Except when they are well done. vpopmail, vmailmgr...don't exim also have something written for it to manage virtual mailboxes?
Exim itself does that.
And vpopmail is not a blackbox solution :)
Ah, i wondered what you meant.
I mean those "install this package/use this script" solutions that set everything up for you, configure, start services and so on.
No, I'm not. .forward/.qmail will provide instructions for the MTA. They don't do delivery, so they are not a "local delivery system".
Hmm...ok. dot-whatever != local delivery agent. I guess I should say it boils down to what qmail-local and its dot-qmail mechanism does compared with the pairing of sendmail's local mailer and its dot-forward mechanism and postfix's local (that is what its LDA is called) support of sendmail's dot-forward.
Perfect.
I didn't even remember qmail-local. From what I remember (obviously wrong) local delivered was done by maildrop.
I agree "nothing to do" was a little strong worded, since everything has to do with local delivery. That is, after all, what the whole e-mail system is about.
-_-. "intra-MTA routing" has nothing to do with local delivery...
Depend on the final routing target, which can be local delivery.
=D. Got me there. The only exception being qmail...once a message is queued, its routing has been set whereas you can still change that if it were postfix, sendmail and I guess exim.
Actually, exim gives you fine grain control over the whole process, which actually helps you to understand who it works behind the scenes (and sometimes makes configuration a hair-pulling experience).
I can't really say how the whole transport-routing process works for qmail. I tried to understand how it worked once, and gave up after about 20 minutes.
And I guess here I reach the limit of tolerance the other members have shown me on this issue, so I'll start replying off-list :)
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Restructuring setup --------------------------------- Hardware: Pentium III 1.4Ghz 256 RAM 40 GB HD-IDE
Soft: CentOS 4.2 Postfix Cyrus-IMAPd
Partitioning(in MB): / 8.000 /boot/ 100 swap 512 /home/ 15.888 /tmp/ 500 /var/spool/imap/ 15.000
would be this a candidate setup?
I'm planning use quota (as suggested in this list) on cyrus level, giving the students the possibility of free their inbox when it is over quota, and let the messages that are in queue (recently) get into the inbox when the space is freed.
In the future, think the possibility of use postgresql (and some php application) to manage users accounts.
Like the beginning, it'll be appreciated any suggestion about.
Alain Reguera wrote:
Restructuring setup
Hardware: Pentium III 1.4Ghz 256 RAM 40 GB HD-IDE
Soft: CentOS 4.2 Postfix Cyrus-IMAPd
Partitioning(in MB): / 8.000 /boot/ 100 swap 512 /home/ 15.888 /tmp/ 500 /var/spool/imap/ 15.000
would be this a candidate setup?
Again, the only nasty problem I see here is the amount of memory. There were a lot of other good suggestions made about how to configure the server, but adding memory is almost a requirement regardless of what else you do. If you don't, the performance is going to be rather bad. With 512mb-1gb of RAM, the system above should be just fine for your intended purpose (although it could benefit from more disk space too).
Cheers,
Alain Reguera wrote:
Restructuring setup
Hardware: Pentium III 1.4Ghz 256 RAM 40 GB HD-IDE
Soft: CentOS 4.2 Postfix Cyrus-IMAPd
Partitioning(in MB): / 8.000 /boot/ 100 swap 512 /home/ 15.888 /tmp/ 500 /var/spool/imap/ 15.000
would be this a candidate setup?
NO.
1) Minor: Why do you want a large /home?
Is this email only or do you plan to let users create their own webpage or something?
2) Major: No /var partition which means it comes under /. I suggest separating /var from / since /var will hold your mail queue. If possible, get / to the state where it is mounted read only.
I'm planning use quota (as suggested in this list) on cyrus level, giving the students the possibility of free their inbox when it is over quota, and let the messages that are in queue (recently) get into the inbox when the space is freed.
Remember to make overquota a temp/soft failure then if that is what you want.
In the future, think the possibility of use postgresql (and some php application) to manage users accounts.
I'd suggest doing that now. Migrating mailboxes to a new system is not fun.
Like the beginning, it'll be appreciated any suggestion about.
Get another disk if the mails are important to you.
<snip>
If possible, get / to the state where it is mounted read only. </snip>
Feizhou,
If you wouldn't mind, could you expand on this a little...i.e. how would you set this up? Consequences for doing so?
Thanks,
Ed
Ed Morrison wrote:
<snip>
If possible, get / to the state where it is mounted read only.
</snip>
Feizhou,
If you wouldn't mind, could you expand on this a little...i.e. how would you set this up? Consequences for doing so?
It really is getting /usr, /var and /tmp out of the way (them tmp directories) and then getting to a state where system wide configuration (/etc) is infrequent. The consequences will be the need to remount / to be writable for any system changes like adding a user or changing a config and then remounting read-only again.
Moving non boot services and their configs off / would help in this regard.
Feizhou wrote:
Ed Morrison wrote:
<snip>
If possible, get / to the state where it is mounted read only.
</snip>
Feizhou,
If you wouldn't mind, could you expand on this a little...i.e. how would you set this up? Consequences for doing so?
It really is getting /usr, /var and /tmp out of the way (them tmp directories) and then getting to a state where system wide configuration (/etc) is infrequent. The consequences will be the need to remount / to be writable for any system changes like adding a user or changing a config and then remounting read-only again.
Moving non boot services and their configs off / would help in this regard. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Awesome. Is there any documentation you could point me to on this?
Thanks,
Ed
Awesome. Is there any documentation you could point me to on this?
Feizhou wrote:
Awesome. Is there any documentation you could point me to on this?
try http://gentoo-wiki.com/HOWTO_Read-only_root_filesystem _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Thanks Feizhou. I appreciate it.
Ed
Thanks Feizhou. I appreciate it.
You are welcome. I hope it was useful.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Dec 07, 2005 at 09:31:02PM +0800, Feizhou wrote:
- Major: No /var partition which means it comes under /. I suggest
separating /var from / since /var will hold your mail queue. If possible, get / to the state where it is mounted read only.
Having /etc readonly is kind of tricky. Are you sure that is a good idea ?
In the future, think the possibility of use postgresql (and some php application) to manage users accounts.
I'd suggest doing that now. Migrating mailboxes to a new system is not fun.
Agreed.
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Dec 07, 2005 at 09:31:02PM +0800, Feizhou wrote:
- Major: No /var partition which means it comes under /. I suggest
separating /var from / since /var will hold your mail queue. If possible, get / to the state where it is mounted read only.
Having /etc readonly is kind of tricky. Are you sure that is a good idea ?
Well, i guess if the system disk goes, there is not much point...
To avoid filesystem errors on / however makes it worthwhile I hope...a read-only / (etc, bin, sbin, lib) would never suffer from filesystem errors due to a crash...disk errors yes but then that can be handled by RAID.
Rodrigo Barbosa rodrigob@suespammers.org wrote:
Having /etc readonly is kind of tricky. Are you sure that is a good idea ?
That was my exact thought as well. You can separate out everything except /etc, which really needs to be on /.
Ideally any programs/services should not be automatically writing to /etc (but /var or /srv instead), but that's hardly the reality.
Bryan J. Smith wrote:
Rodrigo Barbosa rodrigob@suespammers.org wrote:
Having /etc readonly is kind of tricky. Are you sure that is a good idea ?
That was my exact thought as well. You can separate out everything except /etc, which really needs to be on /.
Ideally any programs/services should not be automatically writing to /etc (but /var or /srv instead), but that's hardly the reality.
It is not impossible. Debian is very near to being able to do this and it is possible on Gentoo with some simple modifications.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Dec 07, 2005 at 10:55:42AM -0800, Bryan J. Smith wrote:
Rodrigo Barbosa rodrigob@suespammers.org wrote:
Having /etc readonly is kind of tricky. Are you sure that is a good idea ?
That was my exact thought as well. You can separate out everything except /etc, which really needs to be on /.
Ideally any programs/services should not be automatically writing to /etc (but /var or /srv instead), but that's hardly the reality.
Maybe I'm just used to the old SysV systems, but every time I see /etc/mtab as a link to something on /var I want to scream.
We also have to remember that historicaly the homedir for root was /. Even these days we still see it as /root. I'm sure you remember all the reasons for it not being on /home, so I won't get into that.
Anyway, I agree that ideally the changeable areas should be restricted, or at least grouped, to simplify management.
It is, of course, theoreticaly possible to have / mounted ro. Will take a good bunch of symlinks, tho, so I would not recomend it to anyone.
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
- Minor: Why do you want a large /home?
To let the users organise their mails in folders (using squirrelmail or maybe another webmail client). If there are other ways of do this I would be very pleased to know them.
Remember to make overquota a temp/soft failure then if that is what you want.
sorry about my ignorance, but what does it (temp/soft failure) mean.
Restructuring setup ---------------------------------- Hardware: Pentium III 1.4Ghz 256 RAM 40 GB HD-IDE
Soft: CentOS 4.2 Postfix Cyrus-IMAPd
Partitioning(in MB): / 1.000 /boot/ 100 swap 512 /home/ 15.888 /tmp/ 500 /var/ 7.000 /var/spool/imap/ 15.000
What do you think 'bout this?
I agree with you that is needed more memory, and more disk space, I'll work to upgrade the hardware.
Would be recommended to separate /var/logs/ and /var/spool/mqueue/ in different partitions too? or is enough with separate only /var/.
Alain Reguera wrote:
- Minor: Why do you want a large /home?
To let the users organise their mails in folders (using squirrelmail or maybe another webmail client). If there are other ways of do this I would be very pleased to know them.
Oh. Their mail folders will be organized through IMAP and therefore through cyrus-imap. If that is all, then don't make a separate /home. Users will create their folders through cyrus in /var/spool/imap.
Remember to make overquota a temp/soft failure then if that is what you want.
sorry about my ignorance, but what does it (temp/soft failure) mean.
Sorry, temp = temporary or soft and hard means permanent failure. Soft fail means try again. Hard fail means don't bother trying.
Restructuring setup
Hardware: Pentium III 1.4Ghz 256 RAM 40 GB HD-IDE
Soft: CentOS 4.2 Postfix Cyrus-IMAPd
Partitioning(in MB): / 1.000 /boot/ 100 swap 512 /home/ 15.888 /tmp/ 500 /var/ 7.000 /var/spool/imap/ 15.000
What do you think 'bout this?
Given above, I suggest 10.000 for /var and a 5.000 /usr and what is left from /home going to /var/spool/imap.
I agree with you that is needed more memory, and more disk space, I'll work to upgrade the hardware.
Memory, I don't know...from what I have gathered, 256MB should be ok.
Disks, I would suggest at least two disks and running them mirrored so that you don't lose everything if a disk should die.
Would be recommended to separate /var/logs/ and /var/spool/mqueue/ in different partitions too? or is enough with separate only /var/.
I think a 10GB /var should be sufficient. With 2k users, you should not get large compressed logs.
Thank for clean my doubt about cyrus' storing folders.
Restructuring setup ---------------------------------- Hardware: Pentium III 1.4Ghz 256 RAM 40 GB HD-IDE
Soft: CentOS 4.2 Postfix Cyrus-IMAPd
Partitioning(in MB): / 1.000 /boot/ 100 swap 512 /tmp/ 500 /usr/ 5.000 /var/ 10.000 /var/spool/imap/ 22.888
Seems to be pretty organized this. What do you think?
Alain Reguera wrote:
Thank for clean my doubt about cyrus' storing folders.
Restructuring setup
Hardware: Pentium III 1.4Ghz 256 RAM 40 GB HD-IDE
Soft: CentOS 4.2 Postfix Cyrus-IMAPd
Partitioning(in MB): / 1.000 /boot/ 100 swap 512 /tmp/ 500 /usr/ 5.000 /var/ 10.000 /var/spool/imap/ 22.888
Seems to be pretty organized this. What do you think?
Looks good. Does any of you chums who have experience running cyrus have any thing to say about /var/imap (I assume the centos rpm puts configuration here) as laid out here: http://asg.web.cmu.edu/cyrus/download/imapd/install-perf.html
Alain, postfix's mail queue is /var/spool/postfix fyi.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Dec 07, 2005 at 02:58:20PM -0500, Alain Reguera wrote:
Thank for clean my doubt about cyrus' storing folders.
Partitioning(in MB): / 1.000 /boot/ 100 swap 512 /tmp/ 500 /usr/ 5.000 /var/ 10.000 /var/spool/imap/ 22.888
You still want to have /home on a separated filesystem. You just don't need it to be big.
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Dec 07, 2005 at 02:58:20PM -0500, Alain Reguera wrote:
Thank for clean my doubt about cyrus' storing folders.
Partitioning(in MB): / 1.000 /boot/ 100 swap 512 /tmp/ 500 /usr/ 5.000 /var/ 10.000 /var/spool/imap/ 22.888
You still want to have /home on a separated filesystem. You just don't need it to be big.
If he wants system users. In his case where this box sole use is mail (Alain please confirm) I don't really see a need for a separate /home if there is nobody to use it.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, Dec 08, 2005 at 04:16:57AM +0800, Feizhou wrote:
Thank for clean my doubt about cyrus' storing folders.
Partitioning(in MB): / 1.000 /boot/ 100 swap 512 /tmp/ 500 /usr/ 5.000 /var/ 10.000 /var/spool/imap/ 22.888
You still want to have /home on a separated filesystem. You just don't need it to be big.
If he wants system users. In his case where this box sole use is mail (Alain please confirm) I don't really see a need for a separate /home if there is nobody to use it.
Yes, but you really think it is safe to have no /home ? One eventually might want to create users for a number of reasons on a machine, and leaving /home on / is kind of dangerous.
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
If he wants system users. In his case where this box sole use is mail (Alain please confirm) I don't really see a need for a separate /home if there is nobody to use it.
I just need make the students send, receive and check their mails (trough the web) in this server, nothing more.
Well, if you consider I should add something more to reach this goal... I'm pleased of hear it.
I forgot, that pop3 would be implemented too, in order to permit the students (who want it) use it.
agree with you about the need of connecting through ssh with no root user so with a normal user.
Restructuring setup ---------------------------------- Hardware: Pentium III 1.4Ghz 256 RAM 40 GB HD-IDE
Soft: CentOS 4.2 Postfix Cyrus-IMAPd
Partitioning(in MB): / 1.000 /boot/ 100 /home/ 50 swap 512 /tmp/ 500 /usr/ 5.000 /var/ 10.000 /var/spool/imap/ 22.838
Alain Reguera wrote:
agree with you about the need of connecting through ssh with no root user so with a normal user.
Restructuring setup
Hardware: Pentium III 1.4Ghz 256 RAM 40 GB HD-IDE
Soft: CentOS 4.2 Postfix Cyrus-IMAPd
Partitioning(in MB): / 1.000 /boot/ 100 /home/ 50 swap 512 /tmp/ 500 /usr/ 5.000 /var/ 10.000 /var/spool/imap/ 22.838
You dont need a /home partition - drop that and stick with a 1 Gig / if and when you need it, its easy to later drop in another hard disk and use that for the purpose.
Cyrus will not store any user data in /home - everything, including mail filters, vacation messages etc are stored within the imap/ directories
- K
On Wed, 2005-12-07 at 14:37, Alain Reguera wrote:
agree with you about the need of connecting through ssh with no root user so with a normal user.
Did you already mention whether or not there is a network authentication system available with the users or are you planning to maintain all the logins and passwords yourself on this machine?
Did you already mention whether or not there is a network authentication system available with the users or are you planning to maintain all the logins and passwords yourself on this machine?
By now, due my little experience in this topic, I plan to maintain it manually, but if there is a method of doing this more professional and organized I'll be pleased to hear it.
Don't know if totally possible but I am working the idea of make some kind of integration between the secretary department and the mails account, some way that automatically the student is registered and without a person interaction the account be created with a combination of the speciality, name, and year of the student, that is enter in the register form of the student when it arrives the school.
Planning use postgresql and some php application.
When the student reach the end of the speciality, with the register year I would delete the account automatically, so the process will be a little automated, getting so a little more of time to study :).
Don't know until where this would be possible and this integration could be. So, again your suggestions will be the key for me. :)
Quoting Alain Reguera alain.reguera@gmail.com:
By now, due my little experience in this topic, I plan to maintain it manually, but if there is a method of doing this more professional and organized I'll be pleased to hear it.
Well, it all depends how computer accounts are handled at your school.
For example, if you use NIS or Kerberos, and all students get account there, you might point saslauthd to authenticate against it.
If there is LDAP directory with list of all students, you can use that for authentication (you'd add userPassword attribute to each user, and configure saslauthd to check passwords against LDAP).
If you have Active Directory (Windows) domain, and all students get an account there, saslauthd can authenticate against it too. Actually, Windows Active Directory uses Kerberos for authentication, so basically you'd just configure saslauthd to use Kerberos against Active Directory server. However, there's couple of steps needed to be done on Windows side in order for this to work. I've did it at several sites that are mostly Windows based (but use Cyrus on Linux for email), and it works great.
In this cases, when you don't create accounts, you might want to add autocreatequota option to imapd.conf. If value of option is nonzero, mailbox for the user will be automatically created when user connects to the Cyrus server for the first time. So if you set it to "-1" (or any other negative value), the mailbox will be created with no quota. If you set it to positive value, mailbox will be created and quota set to specified value.
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
----- Original Message ----- From: "Feizhou" feizhou@graffiti.net
On Wed, Dec 07, 2005 at 02:58:20PM -0500, Alain Reguera wrote:
Thank for clean my doubt about cyrus' storing folders.
Partitioning(in MB): / 1.000 /boot/ 100 swap 512 /tmp/ 500 /usr/ 5.000 /var/ 10.000 /var/spool/imap/ 22.888
You still want to have /home on a separated filesystem. You just don't need it to be big.
If he wants system users. In his case where this box sole use is mail (Alain please confirm) I don't really see a need for a separate /home if there is nobody to use it.
If he's going to set this up for IMAP, then certainly putting /home onto a separate drive, not just a separate partition, will be very beneficial. This can enable him to do some pretty cool things, like using spamassassin and procmail to automatically filter out spam into seperate folders.
On my admittedly small setup, I also have scripts run that look for any messages in the user's home maildir "Missed Spam" folder and "Not Spam" folder. In the "Missed Spam" folder, I have it automatically rescore the messages using sa-learn. In the "Not Spam" folder, it's a bit trickier, but using formail along with spamassassin, I can reprocess false positives, strip the headers, and redeliver them appropriately.
Bill
Bill Diamond wrote:
You still want to have /home on a separated filesystem. You just don't need it to be big.
If he wants system users. In his case where this box sole use is mail (Alain please confirm) I don't really see a need for a separate /home if there is nobody to use it.
If he's going to set this up for IMAP, then certainly putting /home onto a separate drive, not just a separate partition, will be very beneficial. This can enable him to do some pretty cool things, like using spamassassin and procmail to automatically filter out spam into seperate folders.
On my admittedly small setup, I also have scripts run that look for any messages in the user's home maildir "Missed Spam" folder and "Not Spam" folder. In the "Missed Spam" folder, I have it automatically rescore the messages using sa-learn. In the "Not Spam" folder, it's a bit trickier, but using formail along with spamassassin, I can reprocess false positives, strip the headers, and redeliver them appropriately.
Please re-read thread before posting. Its usually considered a good idea if what you haveto say has not already been discussed to death before.
his spam markup / handing / processing is on a different box, as was already mentioned.
also, he has decided to use Cyrus, which does not ( as has already been pointed out in this thread ) use anything in /home - please read up on the software before posting.
Also, has been repeatedly pointed out that he does not have and will not use another drive at this time.
Thank you for your attention. Now we return you to the regular programming.
On Wed, 2005-12-07 at 19:20 -0500, Bill Diamond wrote:
----- Original Message ----- From: "Feizhou" feizhou@graffiti.net
On Wed, Dec 07, 2005 at 02:58:20PM -0500, Alain Reguera wrote:
Thank for clean my doubt about cyrus' storing folders.
Partitioning(in MB): / 1.000 /boot/ 100 swap 512 /tmp/ 500 /usr/ 5.000 /var/ 10.000 /var/spool/imap/ 22.888
You still want to have /home on a separated filesystem. You just don't need it to be big.
If he wants system users. In his case where this box sole use is mail (Alain please confirm) I don't really see a need for a separate /home if there is nobody to use it.
If he's going to set this up for IMAP, then certainly putting /home onto a separate drive, not just a separate partition, will be very beneficial. This can enable him to do some pretty cool things, like using spamassassin and procmail to automatically filter out spam into seperate folders.
On my admittedly small setup, I also have scripts run that look for any messages in the user's home maildir "Missed Spam" folder and "Not Spam" folder. In the "Missed Spam" folder, I have it automatically rescore the messages using sa-learn. In the "Not Spam" folder, it's a bit trickier, but using formail along with spamassassin, I can reprocess false positives, strip the headers, and redeliver them appropriately.
----- you must have been sound asleep through all of the discussion where he is using cyrus-imapd which doesn't do maildir, uses it's own method of delivery (not procmail), it's own filtering (sieve) and doesn't do home folders and thus your comments - though well intended have already been considered to be not germane to his setup.
Craig
On Wed, 2005-12-07 at 19:20 -0500, Bill Diamond wrote:
----- Original Message ----- From: "Feizhou" feizhou@graffiti.net
On Wed, Dec 07, 2005 at 02:58:20PM -0500, Alain Reguera wrote:
Thank for clean my doubt about cyrus' storing folders.
Partitioning(in MB): / 1.000 /boot/ 100 swap 512 /tmp/ 500 /usr/ 5.000 /var/ 10.000 /var/spool/imap/ 22.888
You still want to have /home on a separated filesystem. You just don't need it to be big.
If he wants system users. In his case where this box sole use is mail (Alain please confirm) I don't really see a need for a separate /home if there is nobody to use it.
If he's going to set this up for IMAP, then certainly putting /home onto a separate drive, not just a separate partition, will be very beneficial. This can enable him to do some pretty cool things, like using spamassassin and procmail to automatically filter out spam into seperate folders.
On my admittedly small setup, I also have scripts run that look for any messages in the user's home maildir "Missed Spam" folder and "Not Spam" folder. In the "Missed Spam" folder, I have it automatically rescore the messages using sa-learn. In the "Not Spam" folder, it's a bit trickier, but using formail along with spamassassin, I can reprocess false positives, strip the headers, and redeliver them appropriately.
you must have been sound asleep through all of the discussion where he is using cyrus-imapd which doesn't do maildir, uses it's own method of delivery (not procmail), it's own filtering (sieve) and doesn't do home folders and thus your comments - though well intended have already been considered to be not germane to his setup.
So sorry to have inconvenienced you. Gee. Are you always this cranky?
Never mind. I'll just unsubscribe rather than put up with your crap.
Bill
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Dec 07, 2005 at 03:17:58PM -0500, Alain Reguera wrote:
You still want to have /home on a separated filesystem. You just don't need it to be big.
what would be the use of /home/ in this enviroments?
If you plan on accessing this machine remotely (ssh et al), you should have at least 1 user. Remote login as root is really not recomended.
You also might want to create local users in the future for a number of reasons.
I safe bet would be to have a 50M /home. It should not impact you overmuch, and gives you a measure of safety for the future.
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Dec 07, 2005 at 03:17:58PM -0500, Alain Reguera wrote:
You still want to have /home on a separated filesystem. You just don't need it to be big.
what would be the use of /home/ in this enviroments?
Alain, you dont need /home to be sitting on a seperate partition.
If you plan on accessing this machine remotely (ssh et al), you should have at least 1 user. Remote login as root is really not recomended.
You also might want to create local users in the future for a number of reasons.
You do realise that a /home will be created under / if there is no seperate partition for /home dont you ?
- K
thank for your patience with me, and the free teaching :)
You do realise that a /home will be created under / if there is no seperate partition for /home dont you ?
yes, your right :)
Restructuring setup ---------------------------------- Hardware: Pentium III 1.4Ghz 256 RAM 40 GB HD-IDE
Soft: CentOS 4.2 Postfix Cyrus-IMAPd
Partitioning(in MB): / 1.000 /boot/ 100 swap 512 /tmp/ 500 /usr/ 5.000 /var/ 10.000 /var/spool/imap/ 22.888
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Dec 07, 2005 at 08:41:31PM +0000, Karanbir Singh wrote:
Rodrigo Barbosa wrote:
You do realise that a /home will be created under / if there is no seperate partition for /home dont you ?
And that is exactly what I think should be avoided.
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On Wed, 2005-12-07 at 14:58 -0500, Alain Reguera wrote:
Thank for clean my doubt about cyrus' storing folders.
Restructuring setup
Hardware: Pentium III 1.4Ghz 256 RAM 40 GB HD-IDE
Soft: CentOS 4.2 Postfix Cyrus-IMAPd
Partitioning(in MB): / 1.000 /boot/ 100 swap 512 /tmp/ 500 /usr/ 5.000 /var/ 10.000 /var/spool/imap/ 22.888
Seems to be pretty organized this. What do you think?
---- since /home is now part of /
I would probably make it larger...perhaps 2.5G (allowing for inevitable things like perhaps user based spamassassin db's, stuff that you may want to put into /opt)
Craig
Quoting Alain Reguera alain.reguera@gmail.com:
- Minor: Why do you want a large /home?
To let the users organise their mails in folders (using squirrelmail or maybe another webmail client). If there are other ways of do this I would be very pleased to know them.
With Cyrus, everything is stored under /var/spool/imap. Including the folders that users create. The filtering rules (called Sieve scripts, something comparable to procmailrc files) are also stored inside Cyrus system, not in user's home directory. Just give all that space to /var/spool/imap (so you'd get almost 30 gig there). User's don't even have to have home directories (or accounts for that matter) on the system.
In short, Cyrus does not use system accounts (from /etc/passwd). You create mailbox for a user (which would be physically stored in /var/spool/imap). This is the INBOX folder. When user's create new folders, they become subfolders of INBOX, and those folders are also stored in /var/spool/imap. The creation of Cyrus mailbox is completely separate process from creation of system account.
User with system account and no mailbox, will not be able to use Cyrus (and Cyrus will not receive email for him). User with mailbox and no system account will be able to use Cyrus. However, then you can't use default configuration that uses system accounts for authentication (Cyrus will accept email for the user, but user will not be able to access it since he doesn't have system account).
The thing that uses (by default) system accounts is saslauthd. Default configuration for Cyrus IMAPD on CentOS is to use saslauthd for authentication (password checking). In turn, saslauthd is by default configured to use system accounts (/etc/passwd and /etc/shadow files). If you change saslauthd configuration to use LDAP or Kerberos (controlled from /etc/sysconfig/saslauthd file, see also manual page for saslauthd), you can completely remove all user accounts from /etc/passwd. This is the way majority of sites that use Cyrus are operating. Users should not have system accounts on mail server.
Sounds complicated? Not really, you'll see when you start to use it.
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Yes. I suggest running two queues. postfix + clamsmtpd + clamav, first line of defence (RBLs and other gateway blocking). Mails that get through should then be delivered to a qmail queue which will give you very low resource taking processes and a maildir delivery system with the most versatile local delivery agent possible. dovecot can be used as the imap server.
Oops, I have totally forgotten one thing.
For 2000 students and faculty (well, I guess faculty may or may not be hosted on the same box but even if it is a different domain, it is not hard) and the constant yearly addition and possibly removal of accounts, I would suggest a system where the user information are stored in a database (mysql) and virtual mail storage (only one system account is used for all email account mailboxes).
This is possible with postfix alone, you just have to work out the database schema yourself and build the interfaces needed for addition/removal of email accounts otherwise you will or whoever will have to do all that manual by running sql statements.
With qmail, you can add vpopmail and vqadmin which does all the above with the additional plus of having spamassassin support for mysql vpopmail.
Feizhou wrote:
For 2000 students and faculty (well, I guess faculty may or may not be hosted on the same box but even if it is a different domain, it is not hard) and the constant yearly addition and possibly removal of accounts, I would suggest a system where the user information are stored in a database (mysql) and virtual mail storage (only one system account is used for all email account mailboxes).
This is possible with postfix alone, you just have to work out the database schema yourself and build the interfaces needed for addition/removal of email accounts otherwise you will or whoever will have to do all that manual by running sql statements.
Sounds like a classic case where postfix and CyrusIMAPD are going to be the best solution for this person - postfix with mysql is hosted in CentOSPlus, so you dont need to go "work out the schema" yourself, use Cyrus + Web-cyradmin + pam_mysql, and you are done.
Btw, we've spoken about the merits and demerits of various mail app's many times on this mailing list - lets not go there again.
- K
Sounds like a classic case where postfix and CyrusIMAPD are going to be the best solution for this person - postfix with mysql is hosted in CentOSPlus, so you dont need to go "work out the schema" yourself, use Cyrus + Web-cyradmin + pam_mysql, and you are done.
What does one do when the indexes for a mailbox gets hosed? I know of one person who used cyrus and when it got hosed, he came running to me to get him a mail system up and running pronto.
On Wed, 2005-12-07 at 00:25 +0800, Feizhou wrote:
Sounds like a classic case where postfix and CyrusIMAPD are going to be the best solution for this person - postfix with mysql is hosted in CentOSPlus, so you dont need to go "work out the schema" yourself, use Cyrus + Web-cyradmin + pam_mysql, and you are done.
What does one do when the indexes for a mailbox gets hosed? I know of one person who used cyrus and when it got hosed, he came running to me to get him a mail system up and running pronto.
---- generally - I would use...
su - cyrus -c '/usr/lib/cyrus-imapd/reconstruct -fr user.USERNAME'
Craig
Craig White wrote:
On Wed, 2005-12-07 at 00:25 +0800, Feizhou wrote:
Sounds like a classic case where postfix and CyrusIMAPD are going to be the best solution for this person - postfix with mysql is hosted in CentOSPlus, so you dont need to go "work out the schema" yourself, use Cyrus + Web-cyradmin + pam_mysql, and you are done.
What does one do when the indexes for a mailbox gets hosed? I know of one person who used cyrus and when it got hosed, he came running to me to get him a mail system up and running pronto.
generally - I would use...
su - cyrus -c '/usr/lib/cyrus-imapd/reconstruct -fr user.USERNAME'
ah. I guess that person had another problem then...probably this one mentioned in the docs...
sorry, i have not used cyrus yet. thanks for the information craig.
----------------------------------- Mailboxes File The mailboxes file in the configuration directory is the most critical file in the entire Cyrus IMAP system. It contains a sorted list of each mailbox on the server, along with the mailboxes quota root and ACL. Because the ACL is security-critical information that cannot be reconstructed from information stored elsewhere, there is no program to recover from a damaged mailboxes file.
To protect the contents of the mailboxes, we suggest making frequent, even hourly backups of the mailboxes file to some other part of the disk.
------------------------------------
On Wed, 2005-12-07 at 00:37 +0800, Feizhou wrote:
Craig White wrote:
On Wed, 2005-12-07 at 00:25 +0800, Feizhou wrote:
Sounds like a classic case where postfix and CyrusIMAPD are going to be the best solution for this person - postfix with mysql is hosted in CentOSPlus, so you dont need to go "work out the schema" yourself, use Cyrus + Web-cyradmin + pam_mysql, and you are done.
What does one do when the indexes for a mailbox gets hosed? I know of one person who used cyrus and when it got hosed, he came running to me to get him a mail system up and running pronto.
generally - I would use...
su - cyrus -c '/usr/lib/cyrus-imapd/reconstruct -fr user.USERNAME'
ah. I guess that person had another problem then...probably this one mentioned in the docs...
sorry, i have not used cyrus yet. thanks for the information craig.
Mailboxes File The mailboxes file in the configuration directory is the most critical file in the entire Cyrus IMAP system. It contains a sorted list of each mailbox on the server, along with the mailboxes quota root and ACL. Because the ACL is security-critical information that cannot be reconstructed from information stored elsewhere, there is no program to recover from a damaged mailboxes file.
To protect the contents of the mailboxes, we suggest making frequent, even hourly backups of the mailboxes file to some other part of the disk.
---- depends upon configuration - default invoca.ch rpm's would have (and thus RHEL/CentOS) distribution would have...
]# ls -l /var/lib/imap/db.backup1 total 9408 -rw------- 1 cyrus mail 144 Dec 6 09:20 annotations.db -rw------- 1 cyrus mail 9573343 Dec 6 09:20 log.0000000005 -rw------- 1 cyrus mail 21336 Dec 6 09:20 mailboxes.db
# ls -l /var/lib/imap/db.backup2 total 9336 -rw------- 1 cyrus mail 144 Dec 6 08:50 annotations.db -rw------- 1 cyrus mail 9500591 Dec 6 08:50 log.0000000005 -rw------- 1 cyrus mail 21336 Dec 6 08:50 mailboxes.db
thus there should be at least 2 backups of the mailboxes.db automatically. Of course this doesn't supplant a decent backup implementation.
Craig
depends upon configuration - default invoca.ch rpm's would have (and thus RHEL/CentOS) distribution would have...
]# ls -l /var/lib/imap/db.backup1 total 9408 -rw------- 1 cyrus mail 144 Dec 6 09:20 annotations.db -rw------- 1 cyrus mail 9573343 Dec 6 09:20 log.0000000005 -rw------- 1 cyrus mail 21336 Dec 6 09:20 mailboxes.db
# ls -l /var/lib/imap/db.backup2 total 9336 -rw------- 1 cyrus mail 144 Dec 6 08:50 annotations.db -rw------- 1 cyrus mail 9500591 Dec 6 08:50 log.0000000005 -rw------- 1 cyrus mail 21336 Dec 6 08:50 mailboxes.db
thus there should be at least 2 backups of the mailboxes.db automatically. Of course this doesn't supplant a decent backup implementation.
I take it then that adding/removing mailboxes are the only times this file gets updated?
On Wed, 2005-12-07 at 01:09 +0800, Feizhou wrote:
depends upon configuration - default invoca.ch rpm's would have (and thus RHEL/CentOS) distribution would have...
]# ls -l /var/lib/imap/db.backup1 total 9408 -rw------- 1 cyrus mail 144 Dec 6 09:20 annotations.db -rw------- 1 cyrus mail 9573343 Dec 6 09:20 log.0000000005 -rw------- 1 cyrus mail 21336 Dec 6 09:20 mailboxes.db
# ls -l /var/lib/imap/db.backup2 total 9336 -rw------- 1 cyrus mail 144 Dec 6 08:50 annotations.db -rw------- 1 cyrus mail 9500591 Dec 6 08:50 log.0000000005 -rw------- 1 cyrus mail 21336 Dec 6 08:50 mailboxes.db
thus there should be at least 2 backups of the mailboxes.db automatically. Of course this doesn't supplant a decent backup implementation.
I take it then that adding/removing mailboxes are the only times this file gets updated?
---- no - db is checkpointed (cyrus.conf)
EVENTS { # this is required checkpoint cmd="ctl_cyrusdb -c" period=30
cyrus is very sophisticated
Craig
On 12/6/05, Feizhou feizhou@graffiti.net wrote:
cyrus is very sophisticated
cool, a beast.
Is it correct that to rebuild databse you have to first stop cyrus? Or can you rebuild while service is running?
-- Sudev Barar Learning Linux
Sudev Barar wrote:
On 12/6/05, Feizhou feizhou@graffiti.net wrote:
cyrus is very sophisticated
cool, a beast.
Is it correct that to rebuild databse you have to first stop cyrus? Or can you rebuild while service is running?
craig? somebody?
On Wed, 7 Dec 2005, Feizhou wrote:
Sudev Barar wrote:
On 12/6/05, Feizhou feizhou@graffiti.net wrote:
cyrus is very sophisticated
cool, a beast.
Is it correct that to rebuild databse you have to first stop cyrus? Or can you rebuild while service is running?
craig? somebody?
cyrus is such a pain, and requires more horsepower on a single box. It is better to run five really crappy cheap servers using courier over NFS
if you are not a really experienced email admin, then stay away from cyrus, but on the other hand, if you are an experienced email admin you might like cyrus.
Cyrus is nice when you have a couple servers with lots of horsepower IMHO, courier is better for lots of crappy servers.
Robin Mordasiewicz wrote:
cyrus is such a pain, and requires more horsepower on a single box. It is better to run five really crappy cheap servers using courier over NFS
if you are not a really experienced email admin, then stay away from cyrus, but on the other hand, if you are an experienced email admin you might like cyrus.
Cyrus is nice when you have a couple servers with lots of horsepower IMHO, courier is better for lots of crappy servers.
FUD
On Wed, 7 Dec 2005, Karanbir Singh wrote:
Robin Mordasiewicz wrote:
cyrus is such a pain, and requires more horsepower on a single box. It is better to run five really crappy cheap servers using courier over NFS
if you are not a really experienced email admin, then stay away from cyrus, but on the other hand, if you are an experienced email admin you might like cyrus.
Cyrus is nice when you have a couple servers with lots of horsepower IMHO, courier is better for lots of crappy servers.
FUD
speaking from experience. I have used both extensively, and both are excellent, but I would not leave a cyrus installation in the hands of a newbie, whereas courier is alot easier to support for people who do not specialize in mail servers. I dont think its FUD to say that cyrus is something that an advanced admin may prefer, and a nice thing about courier is that if you find an old spare machine laying around it is very easy to integrate into your mail cluster. And a failed courier box does not affect the rest of the cluster. When a cyrus box fails, there is no doubt downtime, and you need to know how to fix it as opposed to just reinstalling another courier box and copying the config files.
cyrus is such a pain, and requires more horsepower on a single box. It is better to run five really crappy cheap servers using courier over NFS
speaking from experience. I have used both extensively, and both are excellent, but I would not leave a cyrus installation in the hands of a newbie, whereas courier is alot easier to support for people who do not specialize in mail servers. I dont think its FUD to say that cyrus is something that an advanced admin may prefer, and a nice thing about courier is that if you find an old spare machine laying around it is very easy to integrate into your mail cluster. And a failed courier box does not affect the rest of the cluster. When a cyrus box fails, there is no doubt downtime, and you need to know how to fix it as opposed to just reinstalling another courier box and copying the config files.
You left out the horsepower bit.
Have you ever ran courier-imap with IDLE support in conjunction with fam? and done the same with cyrus?
On Wed, 7 Dec 2005, Feizhou wrote:
cyrus is such a pain, and requires more horsepower on a single box. It is better to run five really crappy cheap servers using courier over NFS
speaking from experience. I have used both extensively, and both are excellent, but I would not leave a cyrus installation in the hands of a newbie, whereas courier is alot easier to support for people who do not specialize in mail servers. I dont think its FUD to say that cyrus is something that an advanced admin may prefer, and a nice thing about courier is that if you find an old spare machine laying around it is very easy to integrate into your mail cluster. And a failed courier box does not affect the rest of the cluster. When a cyrus box fails, there is no doubt downtime, and you need to know how to fix it as opposed to just reinstalling another courier box and copying the config files.
You left out the horsepower bit.
Have you ever ran courier-imap with IDLE support in conjunction with fam? and done the same with cyrus?
my point about horsepower is that it is really easy to add a spare machine to a courier cluster. If my boss said heres an old pentium, can you throw it into the cyrus server pool it would not really help. Wheras throwing an old server into a courier pool is very easy and the extra horsepower gained is helpful.
If I only had one machine I would use cyrus. It is more efficient, but if I ever had the option of recycling secretaries computers for mail servers I would use courier.
my point about horsepower is that it is really easy to add a spare machine to a courier cluster. If my boss said heres an old pentium, can you throw it into the cyrus server pool it would not really help. Wheras throwing an old server into a courier pool is very easy and the extra horsepower gained is helpful.
If I only had one machine I would use cyrus. It is more efficient, but if I ever had the option of recycling secretaries computers for mail servers I would use courier.
ok...so...cyrus don't have a bunch of authdaemons, a tcp server that accepts connections and then forks a handler?
it is less resource intensive perhaps due to less IMAP features?
On Wed, 7 Dec 2005, Feizhou wrote:
to a courier cluster. If my boss said heres an old pentium, can you throw it into the cyrus server pool it would not really help. Wheras throwing an old server into a courier pool is very easy and the extra horsepower gained is helpful.
If I only had one machine I would use cyrus. It is more efficient, but if I ever had the option of recycling secretaries computers for mail servers I would use courier.
ok...so...cyrus don't have a bunch of authdaemons, a tcp server that accepts connections and then forks a handler?
it is less resource intensive perhaps due to less IMAP features?
less resource intensive becuase of the indexes, which are small databases which contain information about the users mail. Don't make your choice base on this alone, becuase it is not very easy to cluster cyrus servers. If you only have one server then choose cyrus, but if you possibly are able to accumulate older servers to cluster them, then choose courier.
Robin Mordasiewicz wrote:
less resource intensive becuase of the indexes, which are small databases which contain information about the users mail. Don't make your choice base on this alone, becuase it is not very easy to cluster cyrus servers.
I don't have it in production, but it wasn't too hard to set up an imap murder scenario. And adding additional backend servers to that is a piece of cake.
If you only have one server then choose cyrus, but if you possibly are able to accumulate older servers to cluster them, then choose courier.
I don't see the "hardship" in clustering cyrus imap boxes. And I don't see the ease in clustering courier servers, but I've never done that, so I'm probably not the person to judge about that.
Ralph
less resource intensive becuase of the indexes, which are small databases which contain information about the users mail. Don't make your choice base on this alone, becuase it is not very easy to cluster cyrus servers. If you only have one server then choose cyrus, but if you possibly are able to accumulate older servers to cluster them, then choose courier.
So memory footprint and cpu consumption are not significantly different?
I gather then that to cluster cyrus, you need to not only share the actual mailboxes but also /var/imap?
Feizhou wrote:
I gather then that to cluster cyrus, you need to not only share the actual mailboxes but also /var/imap?
No.
http://asg.web.cmu.edu/cyrus/ag.html is a very interesting read on clustering cyrus servers.
Ralph
Ralph Angenendt wrote:
Feizhou wrote:
I gather then that to cluster cyrus, you need to not only share the actual mailboxes but also /var/imap?
No.
http://asg.web.cmu.edu/cyrus/ag.html is a very interesting read on clustering cyrus servers.
This solution does not appear to support HA. If one backend server goes down, all its mailboxes go with it.
a courier-imap/dovecot box would only just have to access a SAN and that is all there is to clustering. Multiple courier-imap/dovecot boxes hitting a database for user info and mailbox location and then hitting the san for the files. simple.
Quoting Feizhou feizhou@graffiti.net:
a courier-imap/dovecot box would only just have to access a SAN and that is all there is to clustering. Multiple courier-imap/dovecot boxes hitting a database for user info and mailbox location and then hitting the san for the files. simple.
I think SAN is way out of reach of somebody who is left to build mail server for 2000 users with only 40GB drive.
Anyhow, what if your SAN storage or NFS server goes down? Your mailboxes go down with it. Hm, not much difference there. You are just replacing one component that might fail, with another component that might equally fail. This is a rahter complicated issue, and there is no single way to implement it. Courier works for some folks. Cyrus works for some folks. They are both good. You choose one and after some time learn to live with its limitations.
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Aleksandar Milivojevic wrote:
Quoting Feizhou feizhou@graffiti.net:
a courier-imap/dovecot box would only just have to access a SAN and that is all there is to clustering. Multiple courier-imap/dovecot boxes hitting a database for user info and mailbox location and then hitting the san for the files. simple.
I think SAN is way out of reach of somebody who is left to build mail server for 2000 users with only 40GB drive.
Whoa, we were on the topic of clustering...this thread is not quite all about the guy with 2k users anymore...
Anyhow, what if your SAN storage or NFS server goes down? Your mailboxes go down with it. Hm, not much difference there. You are just replacing one component that might fail, with another component that might equally fail. This is a rahter complicated issue, and there is no single way to implement it.
SAN != NFS. SAN's provide multiple paths to the data where data is mirrored across different disks and accessible through more than on channel.
Courier works for some folks. Cyrus works for some folks. They are both good. You choose one and after some time learn to live with its limitations.
I am out to find out those limitations and their environments.
Quoting Feizhou feizhou@graffiti.net:
SAN != NFS. SAN's provide multiple paths to the data where data is mirrored across different disks and accessible through more than on channel.
I know what is SAN. I wrote 'SAN or NFS' since you also mentioned both solutions as posibility. Anyhow, SAN does not mean data mirroring (you can have things like JBOD or RAID-0 on SAN too, but not common configuration). Accessibility through multiple paths is optional feature that adds to complexity and costs additional $$$.
Typing this, what does this have with the topic of using Cyrus? It's the storage. Cyrus will work with SAN as happy as it will work with local drives.
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Typing this, what does this have with the topic of using Cyrus? It's the storage. Cyrus will work with SAN as happy as it will work with local drives.
Not in a cluster it won't. That's the point. Two cyrus boxes sharing a SAN = nightmare. If they don't recommend NFS, they won't recommend a SAN either. Hence their murder scheme which will not provide HA of all mailboxes.
On Thu, 2005-12-08 at 01:42 +0800, Feizhou wrote:
Typing this, what does this have with the topic of using Cyrus? It's the storage. Cyrus will work with SAN as happy as it will work with local drives.
Not in a cluster it won't. That's the point. Two cyrus boxes sharing a SAN = nightmare. If they don't recommend NFS, they won't recommend a SAN either. Hence their murder scheme which will not provide HA of all mailboxes.
---- this has gone so far afield it isn't relevant to much of anything.
If you are going for HA and tying it all to a single SAN server, then where is your single point of breakage?
This doesn't relate to but a very tiny percentage of users on this list and those that are choosing SAN are making careful evaluations of all of the software that they use.
Craig
Craig White wrote:
On Thu, 2005-12-08 at 01:42 +0800, Feizhou wrote:
Typing this, what does this have with the topic of using Cyrus? It's the storage. Cyrus will work with SAN as happy as it will work with local drives.
Not in a cluster it won't. That's the point. Two cyrus boxes sharing a SAN = nightmare. If they don't recommend NFS, they won't recommend a SAN either. Hence their murder scheme which will not provide HA of all mailboxes.
this has gone so far afield it isn't relevant to much of anything.
Oh yeah?
If you are going for HA and tying it all to a single SAN server, then where is your single point of breakage?
I never said SAN server. I said SAN.
This doesn't relate to but a very tiny percentage of users on this list and those that are choosing SAN are making careful evaluations of all of the software that they use.
Like I said, I am out to find out what limitations there are of different mail-related software. Things have come down this route because somebody pointed out MURDER to me in response to a question I had about how one would run cyrus in a cluster.
It looks like I am done given the way things are heading.
Feizhou wrote:
Aleksandar Milivojevic wrote:
Quoting Feizhou feizhou@graffiti.net:
a courier-imap/dovecot box would only just have to access a SAN and that is all there is to clustering. Multiple courier-imap/dovecot boxes hitting a database for user info and mailbox location and then hitting the san for the files. simple.
I think SAN is way out of reach of somebody who is left to build mail server for 2000 users with only 40GB drive.
Actually... I'm left wondering if this mailserver is really meant to be an IMAP only mailserver or just an IMAP capable mailserver? Most users like to use POP and keep their mail locally but have the option to use a Webmail program when away. If that is the case, there are a lot of things talked about that really are pretty outlandish. Heck, a lot of ISPs still have a 5meg quota on their users! Yup, one of the larger ones in this area defaults to that.. a phone call is all it takes to get it raised, but I can see their point. If you give them 100megs it'll get filled up. Many users don't even use email except on hotmail or yahoo. Spammers' dictionaries are constantly finding non-mail user accounts on my boxes. Mother Nature abhors an unfilled harddisk.
Also, if the school can only afford to use an old machine like this, how much 'time' can they afford to put into a highly customized system? There's the learning curve..... and as well, many times the 'person responsible' changes frequently in a college setting. Having something which someone else can take over is an important issue. "Simple" is relative... once you've done it five or so times.. yeah, it's simple. :)
Many of us have to know something about a LOT, and simply don't have the time to know a LOT about something. Like having a good grasp of everything from setting up webservers, DNS, email, to building sites/pages understanding some of the programming languages to doing tech calls for folks whose "Outlook is stuck", who many times don't know the difference between Outlook and MSIE! This is said just to point out the idea of thinking about the 'level' of the posters inquiry and situation.
I think we could easily handle AOL's, MSN's and Yahoo's email with what has been discussed... but it might take more that a 40G drive... ;)
John Hinton
Actually... I'm left wondering if this mailserver is really meant to be an IMAP only mailserver or just an IMAP capable mailserver? Most users like to use POP and keep their mail locally but have the option to use a Webmail program when away. If that is the case, there are a lot of things talked about that really are pretty outlandish. Heck, a lot of ISPs still have a 5meg quota on their users! Yup, one of the larger ones in this area defaults to that.. a phone call is all it takes to get it raised, but I can see their point. If you give them 100megs it'll get filled up. Many users don't even use email except on hotmail or yahoo. Spammers' dictionaries are constantly finding non-mail user accounts on my boxes. Mother Nature abhors an unfilled harddisk.
The OP said IMAP only.
Also, if the school can only afford to use an old machine like this, how much 'time' can they afford to put into a highly customized system? There's the learning curve..... and as well, many times the 'person responsible' changes frequently in a college setting. Having something which someone else can take over is an important issue. "Simple" is relative... once you've done it five or so times.. yeah, it's simple. :)
Yes, that's why I don't buy a use what's bundled line of thinking unless of course it fits the bill.
Many of us have to know something about a LOT, and simply don't have the time to know a LOT about something. Like having a good grasp of everything from setting up webservers, DNS, email, to building sites/pages understanding some of the programming languages to doing tech calls for folks whose "Outlook is stuck", who many times don't know the difference between Outlook and MSIE! This is said just to point out the idea of thinking about the 'level' of the posters inquiry and situation.
I think we could easily handle AOL's, MSN's and Yahoo's email with what has been discussed... but it might take more that a 40G drive... ;)
Nope, what has been discussed will not go anywhere near handling AOL/MSN/Yahoo.
No one has yet touched on email account existence check. With vpopmail and mysql-enabled postfix, that's set. I believe Karanbir mentioned something about cyrus + Web-cyradmin + pam_mysql but that did not touch on postfix doing the existence check which depends on the table schema used.
Large site does not have to be a frigging monster site...what about multiple office enterprises? How would you handle those? Running a mail store takes a fair bit of work to get a problem free (save hardware problems) setup.
Feizhou feizhou@graffiti.net wrote:
This solution does not appear to support HA. If one backend server goes down, all its mailboxes go with it.
Oh, yes, if you want HA, then you want to use NFS clustering.
But be sure to use a server that uses Maildir format, and not mbox format, or your performance will absolutely suck due to locking.
cyrus is such a pain, and requires more horsepower on a single box. It is better to run five really crappy cheap servers using courier over NFS
and I suppose you can somehow show how some NFS setup can be better than one with local disk storage
Cyrus is nice when you have a couple servers with lots of horsepower IMHO, courier is better for lots of crappy servers.
and what happened to dovecot?
Feizhou feizhou@graffiti.net wrote:
and I suppose you can somehow show how some NFS setup can be better than one with local disk storage
NFS locking is _hell_ on mbox files. Maildir helps, but it's still _not_ recommended for e-mail storage.
and what happened to dovecot?
I haven't used it as of late. As of late FC2 / early FC3, it was still mega-buggy, so I stuck with WU-IMAP 2004 or Cyrus when I needed the features. But many now say Dovecot is far more stable.
Bryan J. Smith wrote:
Feizhou feizhou@graffiti.net wrote:
and I suppose you can somehow show how some NFS setup can be better than one with local disk storage
NFS locking is _hell_ on mbox files. Maildir helps, but it's still _not_ recommended for e-mail storage.
Heh, not to mention the network overhead. That's why it promptly became a cyrus good for single box with local storage but you should use courier for mail storage on NFS by Robin.
and what happened to dovecot?
I haven't used it as of late. As of late FC2 / early FC3, it was still mega-buggy, so I stuck with WU-IMAP 2004 or Cyrus when I needed the features. But many now say Dovecot is far more stable.
Mega-buggy?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Dec 07, 2005 at 10:59:20AM -0800, Bryan J. Smith wrote:
Feizhou feizhou@graffiti.net wrote:
and I suppose you can somehow show how some NFS setup can be better than one with local disk storage
NFS locking is _hell_ on mbox files. Maildir helps, but it's still _not_ recommended for e-mail storage.
Is NFS recomended for anything (except temporary mounts) these days ? What options we have besides SMB/CIFS (no comments) and AFS (high overhead) ?
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Feizhou feizhou@graffiti.net wrote:
GFS + GNBD/iscsi/FC :P
GFS _might_ be an option with just a few servers. You don't want to be serving out the same data any other way though, only via the IMAP service.
Sudev Barar wrote:
On 12/6/05, Feizhou feizhou@graffiti.net wrote:
cyrus is very sophisticated
cool, a beast.
Is it correct that to rebuild databse you have to first stop cyrus? Or can you rebuild while service is running?
on one machine I am responsible for - 14.83 million emails later, I've not had to rerun the db creation or index collection in the last 2 years 8 months 17 days - as yet.
However, should you need to do so - yes, you would need to stop Cyrus.
- K
Feizhou wrote:
What does one do when the indexes for a mailbox gets hosed? I know of one person who used cyrus and when it got hosed, he came running to me to get him a mail system up and running pronto.
You reconstruct them. There's command that does that, you know. I'd suggest reading man reconstruct.
While we are at it, it might be good practice to change all *db options in /etc/imapd.conf from Berkely DB to skiplist prior to starting Cyrus for the first time. Something like:
annotation_db: skiplist duplicate_db: skiplist mboxlist_db: skiplist ptscache_db: skiplist quota_db: skiplist seenstate_db: skiplist subscription_db: skiplist tlscache_db: skiplist
Hi Alex,
Aleksandar Milivojevic wrote:
Feizhou wrote:
What does one do when the indexes for a mailbox gets hosed? I know of one person who used cyrus and when it got hosed, he came running to me to get him a mail system up and running pronto.
You reconstruct them. There's command that does that, you know. I'd suggest reading man reconstruct.
I don't run cyrus nor have I ever ran it. The guy that came running to me did try reconstruct to no avail so I suspect that that was a case of the mailboxes database going bust or something. I really have no idea though for this was over three years ago.
While we are at it, it might be good practice to change all *db options in /etc/imapd.conf from Berkely DB to skiplist prior to starting Cyrus for the first time. Something like:
annotation_db: skiplist duplicate_db: skiplist mboxlist_db: skiplist ptscache_db: skiplist quota_db: skiplist seenstate_db: skiplist subscription_db: skiplist tlscache_db: skiplist
I don't mean to turn this into a cyrus tutorial thread but since cyrus is what is bundled...
What does this do?
Quoting Feizhou feizhou@graffiti.net:
Aleksandar Milivojevic wrote:
Feizhou wrote:
annotation_db: skiplist duplicate_db: skiplist mboxlist_db: skiplist ptscache_db: skiplist quota_db: skiplist seenstate_db: skiplist subscription_db: skiplist tlscache_db: skiplist
I don't mean to turn this into a cyrus tutorial thread but since cyrus is what is bundled...
What does this do?
The above is list of various indexes/databases cyrus keeps. Berkeley DB format proved to be troublesome in the past. My guess is that your friend used Berkeley DB for mboxlist_db. Default in CentOS is to use skiplist for some of them, Berkeley DB for others, and flat files for the rest. The above simply instructs Cyrus to use skiplist for all of them.
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On Wed, 7 Dec 2005, Aleksandar Milivojevic wrote:
Feizhou wrote:
What does one do when the indexes for a mailbox gets hosed? I know of one person who used cyrus and when it got hosed, he came running to me to get him a mail system up and running pronto.
You reconstruct them. There's command that does that, you know. I'd suggest reading man reconstruct.
I'd like to point out here that you will not ever have this type of problem with courier. I really like cyrus, but I babysit cyrus all the time.
I'd like to point out here that you will not ever have this type of problem with courier. I really like cyrus, but I babysit cyrus all the time.
Now ain't that right?
I have never had to do any maintenance with courier-imap.
Robin Mordasiewicz wrote:
What does one do when the indexes for a mailbox gets hosed? I know of one person who used cyrus and when it got hosed, he came running to me to get him a mail system up and running pronto.
You reconstruct them. There's command that does that, you know. I'd suggest reading man reconstruct.
I'd like to point out here that you will not ever have this type of problem with courier. I really like cyrus, but I babysit cyrus all the time.
I would also like to point out that you had either a bad config or lack of understanding about any system. We've been over this issue of which imap and how and where - on this list, previously. I recommend you go back and read those posts.
And Feizhou, who seems to be towing your line, has already admitted he has no idea about Cyrus and has never used it.
And anyway, i dont understand the logic behind 'Courier is easier than a yum install cyrusimapd'. Specially since Courier is neither in the distro, nor provided by any stable maintained repository for EL4. So you are pretty much on your own 'aka LFS style'. Maybe on a different distro the story would be different - but on CentOS, I dont think so.
- K
And Feizhou, who seems to be towing your line, has already admitted he has no idea about Cyrus and has never used it.
Well, cyrus does add extra things to do according to its documentation. /var/imap needs to be infallable for cyrus to be trouble-free like the courier or dovecot. cyrus-imap adds this as a possible source of trouble whereas dovecot and courier-imap only have to worry about the actual mailboxes (assuming maildir, courier-imap only supports maildir) which are basically a structure of directories and files.
On Wed, 2005-12-07 at 09:27, Karanbir Singh wrote:
And anyway, i dont understand the logic behind 'Courier is easier than a yum install cyrusimapd'. Specially since Courier is neither in the distro, nor provided by any stable maintained repository for EL4. So you are pretty much on your own 'aka LFS style'. Maybe on a different distro the story would be different - but on CentOS, I dont think so.
On Centos the other reasonable choice would be to configure procmail to default to deliver in maildir format (should work for either sendmail or postfix) and Dovecot to expect that format, and use authconfig/pam to authenticate however you want. I think you'd have to create the home directories ahead of time though, and delete them when the account goes away.
On Wed, 7 Dec 2005, Les Mikesell wrote:
On Wed, 2005-12-07 at 09:27, Karanbir Singh wrote:
On Centos the other reasonable choice would be to configure procmail to default to deliver in maildir format (should work for either sendmail or postfix) and Dovecot to expect that format, and use authconfig/pam to authenticate however you want. I think you'd have to create the home directories ahead of time though, and delete them when the account goes away.
PAM can auto-create home directories via pam_mkhomedir.so, which is included with CentOS. Auto-creation is typically associated with login activity (/etc/pam.d/login), but I wouldn't be surprised if it could be associated with Dovecot IMAP/POP access. The README is available via CVS:
http://cvs.sourceforge.net/viewcvs.py/pam/Linux-PAM/modules/pam_mkhomedir/
On Wed, 2005-12-07 at 12:04, Paul Heinlein wrote:
On Centos the other reasonable choice would be to configure procmail to default to deliver in maildir format (should work for either sendmail or postfix) and Dovecot to expect that format, and use authconfig/pam to authenticate however you want. I think you'd have to create the home directories ahead of time though, and delete them when the account goes away.
PAM can auto-create home directories via pam_mkhomedir.so, which is included with CentOS. Auto-creation is typically associated with login activity (/etc/pam.d/login), but I wouldn't be surprised if it could be associated with Dovecot IMAP/POP access. The README is available via CVS:
http://cvs.sourceforge.net/viewcvs.py/pam/Linux-PAM/modules/pam_mkhomedir/
I know it can do it as you log in, but in this case the mail delivery may come first. I'd assume you'd add a user to the network authentication system and send off a welcome email. And I don't think procmail will auto-create a maildir even if the home directory was already there.
I know it can do it as you log in, but in this case the mail delivery may come first. I'd assume you'd add a user to the network authentication system and send off a welcome email. And I don't think procmail will auto-create a maildir even if the home directory was already there.
I don't see why the network authentication system cannot create the Maildir when the user is added.
On Wed, 2005-12-07 at 12:36, Feizhou wrote:
I know it can do it as you log in, but in this case the mail delivery may come first. I'd assume you'd add a user to the network authentication system and send off a welcome email. And I don't think procmail will auto-create a maildir even if the home directory was already there.
I don't see why the network authentication system cannot create the Maildir when the user is added.
Chances are good that there is already a usable network authentication system containing the users and passwords and fair that the person who manages it knows nothing about this mail server.
Les Mikesell wrote:
On Wed, 2005-12-07 at 12:36, Feizhou wrote:
I know it can do it as you log in, but in this case the mail delivery may come first. I'd assume you'd add a user to the network authentication system and send off a welcome email. And I don't think procmail will auto-create a maildir even if the home directory was already there.
I don't see why the network authentication system cannot create the Maildir when the user is added.
Chances are good that there is already a usable network authentication system containing the users and passwords and fair that the person who manages it knows nothing about this mail server.
Don't you love integration?
On Wed, 2005-12-07 at 13:07, Feizhou wrote:
I don't see why the network authentication system cannot create the Maildir when the user is added.
Chances are good that there is already a usable network authentication system containing the users and passwords and fair that the person who manages it knows nothing about this mail server.
Don't you love integration?
That's what standard network protocols are all about - so you can add new services without rebuilding what you had. For a few thousand users it would be reasonably practical to pull a full list every half hour or so in a script and make the needed changes.
On Wed, 7 Dec 2005, Les Mikesell wrote:
I know it can do it as you log in, but in this case the mail delivery may come first. I'd assume you'd add a user to the network authentication system and send off a welcome email. And I don't think procmail will auto-create a maildir even if the home directory was already there.
It's pretty simple to add a maildir directory to /etc/skel. :-)
Rodrigo Barbosa wrote:
You might also want to change Cyrus-imapd to something simpler, like wu-imapd, since it should take less resources from the machine. Then again, I have very little experience with cyrus, since I either use wu or courrier.
Cyrus needs less resources than wu-imapd. Each time you open mailbox, wu-imapd needs to read it from beggining to the end from the disk, and alocate possibly large chunks of memory as long as you keep connection open. Cyrus will simply consult its internal database. Huge difference in speed and load on machine. So, the slower/older your hardware is, the more inclined you should be to run cyrus.
I disagree on slower/older hardware I'd be more inclinded to use dovecot due to it's extreme indexing and caching of message parts, logins, etc. (which it all 100% tunable though it's simple conf file)
Side note: Really if your looking for a drop in solution that simple to setup, maintain, uses 100% virutal users, and has countless & simple ways to addon anti-virus,spam, etc. I highly recommend XMail as the SMTP server.
-- Chris L. Franklin --
----- Original Message ----- From: "Aleksandar Milivojevic" alex@milivojevic.org To: "CentOS mailing list" centos@centos.org Sent: Wednesday, December 07, 2005 12:33 AM Subject: Re: [CentOS] Planning Mail Server (with low resources)
Rodrigo Barbosa wrote:
You might also want to change Cyrus-imapd to something simpler, like wu-imapd, since it should take less resources from the machine. Then again, I have very little experience with cyrus, since I either use wu or courrier.
Cyrus needs less resources than wu-imapd. Each time you open mailbox, wu-imapd needs to read it from beggining to the end from the disk, and alocate possibly large chunks of memory as long as you keep connection open. Cyrus will simply consult its internal database. Huge difference in speed and load on machine. So, the slower/older your hardware is, the more inclined you should be to run cyrus. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
________________________________________________________________________
This email was scanned by the server at NomadCF.com, And has been deemed clean of invaild and or dangerous email attachment type and virus'.
Although this is by no means a guarantee.
________________________________________________________________________
Aleksandar Milivojevic wrote:
Rodrigo Barbosa wrote:
You might also want to change Cyrus-imapd to something simpler, like wu-imapd, since it should take less resources from the machine. Then again, I have very little experience with cyrus, since I either use wu or courrier.
Cyrus needs less resources than wu-imapd. Each time you open mailbox, wu-imapd needs to read it from beggining to the end from the disk, and alocate possibly large chunks of memory as long as you keep connection open. Cyrus will simply consult its internal database. Huge difference in speed and load on machine. So, the slower/older your hardware is, the more inclined you should be to run cyrus.
So less disk overhead. That was a certain plus I gathered from its use of indexes.
How does it run though? Threaded? single master daemon with preforked children? children disappear after handling one connection/session?
Feizhou wrote:
So less disk overhead. That was a certain plus I gathered from its use of indexes.
How does it run though? Threaded? single master daemon with preforked children? children disappear after handling one connection/session?
perhaps the Cyrus List at http://asg.web.cmu.edu/cyrus/mailing-list.html might be a better place to handle such a topic ? you are also more likely to get a more authoritative response there... And for any followup that might be generated from there.
- K
Karanbir Singh wrote:
Feizhou wrote:
So less disk overhead. That was a certain plus I gathered from its use of indexes.
How does it run though? Threaded? single master daemon with preforked children? children disappear after handling one connection/session?
perhaps the Cyrus List at http://asg.web.cmu.edu/cyrus/mailing-list.html might be a better place to handle such a topic ? you are also more likely to get a more authoritative response there... And for any followup that might be generated from there.
yeah i guess so.
On Tue, 6 Dec 2005, Aleksandar Milivojevic wrote:
Rodrigo Barbosa wrote:
You might also want to change Cyrus-imapd to something simpler, like wu-imapd, since it should take less resources from the machine. Then again, I have very little experience with cyrus, since I either use wu or courrier.
Cyrus needs less resources than wu-imapd. Each time you open mailbox, wu-imapd needs to read it from beggining to the end from the disk, and alocate possibly large chunks of memory as long as you keep connection open. Cyrus will simply consult its internal database. Huge difference in speed and load on machine. So, the slower/older your hardware is, the more inclined you should be to run cyrus.
but it is much easier to add older machines to a pool of imap servers using courier than cyrus
Alain Reguera wrote:
Hello,
I'm planning the installation of the school's Mail Server. This is the first time I get in administration. I've been reading about postfix, cyrus and the first page in the guide of HughesJR.com[2] about installing postfix-cyrus, but due my low hardware resources, I ask for suggestions to see If what I need can be done (and|or) stable.
Hardware: Pentium III 1.4Ghz 256 RAM 40 GB HD-IDE
I'm running something similar (sendmail vs. postfix, mimedefang vs. mailscanner) on much slower machine (but also, with much less users).
/var/spool/mail/ 14.800
Cyrus uses /var/spool/imap for mail storage. So you might want to change the above to /var/spool/imap.
The server will serve around 2000 students, but only 80(maybe 100) concurrent at time. I would like to make a very basic installation, 'cause as you can see, I am with a very low hardware resources. This host will be mail dedicated.
For the number of users, you'd probably want to consider dual-CPU system. Also, unless you impose mailbox quotas (trivial to do with cyrus), you'll run out of disk space relatively fast (for that number of users). Remember, with IMAP, mail is stored on the server. Disk is cheap nowdays, get yourself two 250MB drives ($150-200 investment) and make software RAID-1. You'll get both capacity and redundancy.
-
Alain Reguera -
Aleksandar Milivojevic -
Bill Diamond -
Bryan J. Smith -
Chris L. Franklin -
Chris Mauritz -
Craig White -
Dennis Gilmore -
Ed Morrison -
Feizhou -
John Hinton -
Johnny Hughes -
Karanbir Singh -
Leonard Isham -
Les Mikesell -
Paul Heinlein -
Ralph Angenendt -
Rex Dieter -
Robin Mordasiewicz -
Rodrigo Barbosa -
Scot L. Harris -
Sudev Barar -
Tom Diehl -
Ugo Bellavance -
William A. Mahaffey III