>>>>> On Fri, 16 Feb 2001 11:51:50 -0500,
>>>>> John C Amodeo <[EMAIL PROTECTED]> (jca) writes:
jca> It would make sense to be able to use 1 Cyrus server (properly partitioned) to
serve
jca> multiple Departments, where user 'Smith' may be 2 distinct users from 2 contexts;
jca> i.e. Linux Server1 will serve users email for ou=Department1 and ou=Department2.
With Cyrus 2.0.11 you can bind each of the services in cyrus.conf to
a specific address:port:
... listen="serv1.dept1.dom:lmtp" ...
I was eager for this so that the lmtpd could be bound to an address
on a private network. However, it also seemed to me this would be
necessary for multi-domain support as well.
While perhaps not very elegant, seems to me the simplest way to
finish up *some* kind of multi-domain support would be the ability
to supply master with a '-C config_file_dir' option. This would not
only specify a specific directory for the cyrus.conf, but also the
imapd.conf. In these domain-specific configuration files you'd
specify which addresses that set of services should bind to, as well
as the authentication service to use. (Perhaps a 'servicename'
setting would be needed in imapd.conf that would be used for PAM
lookups????)
One thing I really dislike is the business of users having to login
with their fully-qualified address. This does not give the
impression that the folks of a particular domain have their own
little private server. The fact that more than one domain may
physically reside on the same machine is not something the users
need to be aware of or worry about. It seems like the simplest way
to achieve this would be to have multiple masters, each with a
different configuration.
While having multiple masters would be somewhat wasteful
process-wise, it would at least make it trivial to lift out an
entire domain if at some point it became necessary to scale out
horizontally. Besides, being able to specify a config_file_dir
wouldn't necessarily preclude later evolving master to have builtin
support for multiple domains, if so desired.
The trickiest thing would be that master would have to relay this
config_file_dir to all the services, likely thru an environment
variable.
--
Amos
