That way the mix folders would be local without
having to worry about creating a separate secondary set of local/non-NFS
home directories for all of the users just for use on the email server.
I fail to see the savings. You have the same number of directories
either way, only now you have to have multiple algorithms to identify
a user's space.
The way that you get into trouble is when you try to get one box to
assume multiple roles: an IMAP server doing tasks that are not
IMAP-related, an NFS server providing both file and IMAP backend
services, etc.
Separate your services onto separate hardware! That's how you
eliminate single points of failure.
I think we're on the same page...but the home directory issue
deserves some clarification. It's more of an administration issue than
a technical issue. The primary home directories are distributed via
NFS and there's significant effort that goes into maintaining a home
directory environment (.login, .cshrc, etc...) that works well across
all of the application servers for all users and all applications.
Making the home directories local to the email server would mean
creating a new secondary/local/non-NFS home directory for all of
the users (home directory creation and permission maintenance).
Also having to maintain a second set of dot files separate from the
primary NFS home directory in use by the rest of the application
servers. In short, that's additional administrative overhead that isn't
really necessary. If imapd can do that all by itself, that would work,
but I think most would agree that it isn't imapd's job to create users'
home directories or to automatically set up their shell environment.
Pine is a good example of where this comes into play. The
users still need their path set and their terminal type set properly,
etc, so it's not as simple as just creating an empty home directory
on the email server to use instead of their primary NFS home
directory (and even that step shouldn't really be necessary). Since
imapd is the application that requires the mail folders to be local
(not the norm, where a majority of other applications work fine
through NFS), it seems that imapd should make allowances to
store the folders in a new imap specific location that doesn't conflict
with existing infrastructure. That way imapd compliments sites with
a distributed NFS home directory architecture, not conflict with it.
I'm willing to accept that the email folders need to be local, but not
at the cost of replicating the entire user environment. Since /var is
where that sort of local/machine specific/application specific/
dynamically changing user data would logically be stored, that
would be my suggestion. If it isn't something of general interest,
I'm still willing to take a shot at it in order to resolve our particular
situation and be able to give mix format a try.
Anyway, my original reasoning for interjecting into this thread was
to help answer the question - why sites attempt to use imapd
over NFS when they're both different methods of going about
the same thing. To answer - it might not be that NFS is actually
required or even desired, it's just that imapd's usage of home
directories can inadvertently put admins into that situation without
any other readily apparent solution.
-Brian
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
