Brian May <bam@debian.org> [2003-01-01 10:27:36 +1100]: > On Tue, Dec 31, 2002 at 02:37:55AM -0700, Bob Proulx wrote: > > Yet another, "Excuse me?" When would any sendmail files ever be > > shared? That does not fit any workable model in my head. Being local > > to the machine the local uid will override the NIS uid and everything > > works fine. Or if adduser detects the NIS uid it won't add a local > > one and therefore you will get the NIS one. > > Diskless NFS systems with no local harddisk, where all directories are > stored on a server. When I am thinking of mail and spool directories I am thinking of two different directories. /var/spool/ which hosts the systems mail queue and /var/mail/ which hosts the user end delivery mailboxes. I say this just to keep us on the same track. The /var/spool area would hold system uids. The /var/mail area would hold non-system uids. There have been many schemes in the historical record to share /var/mail across NFS. Usually so that diskless clients can allow non-system users to read their mail by accessing /var/mail in the normal way as if it were a local filesystem. That has had different degrees of success depending upon many things. The local mail client MUA needs to know nothing. Except that if they really don't know it is over NFS then locking is problematic. Most people stick their head in the sand and ignore the problem and claim ignorance when a user complains about random mailbox corruption. Procmail specifically deals with it directly. Probably a better answer in that case is to support IMAP to the mail server. That avoids the problem of NFS mailboxes entirely. It avoids some NFS issues in general. > No, I don't know if storing sendmail queues on NFS is a good idea, it > probably isn't; another package might be more appropriate. A diskless mail server that uses an NFS /var/spool directory. Please spare me that sight! I am sure someone will post the need to use a NFS network appliance for all disk purposes. It does not mean I have to like it. That would not be my idea of a highly available, high performance mail server. In the case of an NFS mounted /var/spool for an individual host and not shared with any other host things should work regardless of uid overlap. It would be confusing perhaps. Security is always an issue but if you operate in a locked room lan perhaps not germane for for that implementation. But as long as the uids are consistent between each host and its associated /var/spool directory then different hosts can have different 'maildrop' ids in different NFS non-shared directories and it would be fine. > No, the directories aren't "shared", but you don't want UIDs to > be different on the client and the server, not only could it create > security issues, but also cause much confusion too. Agreed. But if this is the case then the admin is definitely operating in a very special case situation and would need to handle the special case needs on their own. It should not be a recommended case. It is certainly fraught with subtle problems. It is clearly dependent upon the particular mail software running in that shared directory. I don't think Debian needs to go to extreme measures to support it, just to allow it. The paradigm of easy things being easy and hard things being possible. I don't know of any MTA that is written with the idea that it will operate with multiple hosts sharing a /var/spool directory. It is certainly possible that someone will write one or adapt one. I would not recommend it, however. > This also raises a number of other issues like "should postfix running > on the server really be able to access the spool directory of each of > NFS client?", but I don't want to get into that right now; SE-Linux > might be the complete answer, eg. only allow the NFS server process > access to these files on the server. [The words used here lead me to believe you are suggesting a central mail server writing to /var/mail on the remote clients.] That is a new twist on things. In that case wouldn't using the MTA to MTA protocol be safer? Bob
Attachment:
pgpzx_crdquJO.pgp
Description: PGP signature