Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!ittc!fpb From: fpb@ittc.wec.com (Frank P. Bresz) Newsgroups: comp.unix.admin Subject: Re: Network-wide Mail Spool? Message-ID: Date: 2 Nov 90 03:23:08 GMT References: <924@iiasa.UUCP> <715@toshiba.tic.oz> Sender: news@ittc.wec.com Followup-To: comp.unix.admin Organization: Westinghouse, ITTC, Pgh, PA. Lines: 121 In-reply-to: rickg@toshiba.tic.oz's message of 1 Nov 90 23:57:08 GMT Distribution: FLAME ALERT FLAME ALERT FLAME ALERT FLAME ALERT In article <715@toshiba.tic.oz> rickg@toshiba.tic.oz (Rick Gunderson) writes: >In <924@iiasa.UUCP> wnp@iiasa.AT (wolf paul) writes: >>I would like some comments/advice on the feasibility of having a >>central mail spool directory for all users on a UNIX LAN, which >>would be cross-mounted to all machines. >>I have users who log in on different machines at different times, >>but expect to be notified by their shell or biff when new mail for >>them arrives, regardless of where they are logged in. >On Sun386i machines running SunOS 4.0.2, $USER can have her/his mail delivered >straight to their home directory (/home/$USER/mail/inbox). This means that no >matter where $USER logs into, he/she can read their mail because (at least >under SunOS) their home directories are always auto-mounted on the host on >which they login. Sure so long as they don't have an account that they want to use anywhere but a 386i. >The /bin/mail program in SunOS 4.0.2 consults a yellow pages map called >``policies'' that (among other things) determines if mail should be delivered >to /home/$USER/mail/inbox to the (usual) /usr/spool/mail/$USER file on the >machine that exports the /home/$USER directory (I'll call this machine the >``homehost''). Yes this was when Sun thought YP would save humanity from themselves so they created more maps than they knew what to do with, and the wonderful group who brought you the 386i which just can't seem to make it on it's own without YP (what a MAJOR lose), added even more. Mounting /{var,usr}/spool/mail on Sun's or on other machines has been shown to work fairly well. I used it as far back as Sun 3.X. I just had to be careful about my aliases file. But hey I am a big boy I can handle the trauma of a few mail files showing up in the wrong place owned by 'nobody'. But when the designers of the (wonderful) Sun386i charged off they had no concern at all about what they were doing in respect to the rest of their very own company. The Sun386i has not anywhere near the look and feel of a Sun3/4. It is a brain damaged piece of trash, I wish we didn't own. I have since neutered all of the 386i's under my influence and made them behave themselves by having them NIS (Sun was apparently sued big for using YP a trademark owned by British Telecomm) served by a 4/490 running 4.1_PSR_A. And yes I did HAVE to create this incredibly bogus policies file. But you better believe I set it to spool delivery. (Actually I hacked the aliases files so that everything is always routed the server anyway) This was yet another case of Sun breaking a great many things because (excuse the slur) some grad student thought it would be cool to have mail delivered to your home directory. (I just can't break the fealing that Sun hired a bunch of grad students and said "hey we need an intel prouct please build us one"), Oh by the way ever notice that using finger to tell if someone has read their mail on one of these stupid machines is utterly useless. The finger program was never told about the wonders of YP and the policies MAP. The Sun 386i is a brain damaged piece of dead weight. It is so brain damaged that the default login files produced by that wonderful tool 'SNAP' (blech) have setenv MAIL all through them. No other machine I know requires the MAIL env to be set for things to work properly, but on the 386i you must (hey it's user friendly). >Unfortunately, on non-Sun386i Sun workstations, the /bin/mail program is "dumb" >and always delivers to /usr/spool/mail/$USER on the homehost machine (which >causes the hassle that you are trying to avoid) :-(. >Why Sun didn't supply the Sun386i-style of /bin/mail with their other >workstations is anybodies guess. Because they woke up to the grave error they made after they were thrashed verbally by many users of the brain damaged Sun386i. This machine was a complete and utter disaster from start to finish. :-) Can you guess I just can't stand the Sun386i. But hey Ford built the Edsel. >>... We are currently using >>sendmail, but are thinking about switching to smail3. >One suggestion would be (since you say you are running sendmail) to fix your >sendmail.cf file so that _local_ mail deliveries are not handled by /bin/mail >but are handled by a program that you write called (say) homemail. >The homemail program could then deliver mail sent to $USER in >/home/$USER/mail/inbox rather than to the /usr/spool/mail/$USER that /bin/mail >always delivers to. >Another suggestion would be to simply export the /usr/spool/mail/$USER file >so and mount it on every machine that $USER logs in on. Mail delivery would >still always be done on the homehost of $USER (via sendmail) and $USER could >read his/her mail file on any machine on which it is mounted. Well Sun now uses /var/spool/mail not /usr/spool/mail. Which it marginally supports via the OR switch in sendmail.cf. If you mount /var/spool/mail everything automagically gets routed to the server. But hey watch out if you mount /usr/spool/mail because that's what you're used to it won't route. Why, sendmail looks in the mount tables and if it doesn't see /var/spool/mail it assumes you don't have a mounted mail partition (what a hack) Also this would also result in multiple NFS mounts in an already superbly overmounted world. Instead of just 1 mount of the entire /var/spool/mail from another machine. I think delivering mail anywhere but the spool directory is a big GIANT lose for a great many reasons too numerous to list. I absolute abhore any suggestion to do so. WE NOW RETURN TO YOUR REGULAR COOL HEADED NEWSGROUP. -- | () () () | Frank P. Bresz | Westinghouse Electric Corporation | \ /\ / | fpb@ittc.wec.com | ITTC Simulators Department | \/ \/ | uunet!ittc!fpb | Those who can, do. Those who can't, simulate. | ---------- | +1 412 733 6749 | My opinions are mine, WEC don't want 'em.