Re: Need advice on deployment of campus-wide mail system

[Matti Aarnio <mea@utu.fi>]

> Hello!  For the next semester, we are planning to have our student 
> population using Unix-Pine.  We are going to have a couple of "login 
> servers" with Pine clients, and a couple of "IMAP servers."  The latter 
> will be SPARCstation 1000 machines running Solaris 2.3.
> 
> One option we have considered is as follows:
> 
> Have the IMAP servers share a dual-ported RAID package.  Each IMAP server 
> would have half of the RAID disks locally-mounted and half NFS-mounted.  
> Then, each user would have an account on each IMAP server, but this would 
> be transparent to him.  He could simply point to IMAP.ASU.EDU, which 
> would resolved to IMAPa.ASU.EDU or IMAPb.ASU.EDU, depending on the load.  
> Another advantage would be that, if one of the machines went down, we 
> could transfer the disks to the other one.  
> 
> Has anyone out there implemented such a system?  Does anyone see a 
> significant problem with this?

	Don't know, but that may well be possible, as there exists
	a dual-port IPI-disk data availability facility on some models
	of Sun4/690:es very least.

	The question is not that much on being able to access the data,
	but rather to be able to keep the filesystems coherent with two
	active writters...

	Ask your vendor, they propably have a solution.

> Another question is whether we should use ZMailer or sendmail V8.  We 
> already have a modified mail.local which delivers to home directories.  
> (This was a hand-me-down.)  Is it involved to get ZMailer to deliver to 
> home directories and take quotas into account?

	No, quite elementary.  (But I haven't written explicite hooks
	for it.)

	A snafu is Solaris:es  maillock(3X), which may force you
	to adopt alternate approaches, like using automount to
	map:
		/var/mail/username	-> ~username/.mail/incoming
		/var/mail/username.lock -> ~username/.mail/incoming.lock

	for all users..

	Hmm..  Though propably the lock can resize where it is now without
	any significant problems -- assuming your machines share also the
	/var/mail/ -directory!

> We don't need a very smart mailer, since it would simply send all outgoing 
> mail to our "Post Office."  However, ZMailer supports posting to 
> newsgroups, which we'll want in the future.

	That support is mostly just a inews-driver and a lookup of
	news system "active" file to see the list of newsgroups.

	Same support for a large set of address lookup databases can be
	implemented via  sendmail  aliases as well.  (Some script producing
	actively used true aliases from a bunch of sources every now and then,
	like twice a day..)

> Would running 2 copies of sendmail against the same (NFS-shared) file space 
> be a problem?  We could have a higher-priority MX record for one of the 
> IMAP servers, but the mailer on the other one could potentially be 
> started if the first mailer were busy?  Would ZMailer be a better choice 
> in this regard, since it can be installed in "client-server" mode?

	Actually the problem falls back on file locking (and reliability
	of it) on the local delivery.  It seems to work quite nicely, though.

> Back to the IMAP servers, another option would be to divide our users
> between them.  Then we wouldn't have to worry about NFS idiosyncrasies,
> but would be hard-pressed to balance the load and tell users which IMAP
> server to point to. 
> 
> Yes another approach would be to start filling the first IMAP server, and 
> once we're done with it, start using the next one.

	One of the principal IMAP developing sites told recently
	their story on IMAP4 list about how they distributed their
	users.  Essentially it was:

		1 - Populate first server
		2 - wait until server load becomes "too high"
		3 - add a new server
		4 - move most active 10% of all users to the new server,
		    and move their emails to there too (aliasing, or
		    what ever)
		5 - "go to 2".

	The problem is, of course how to teach users that they are
	expected to change the server at a whim of the administrators..

> Any comments will be greatly appreciated.
> 
> Sincerely,
> 
>   Shahjehan Khatri
> 
> 
>