system@asuvax.UUCP (Marc Lesure) (09/26/88)
We want to develop a mail system server which will receive and store mail from remote systems. Users will be able to send, read, query their mail from any machine (regardless of OS) from a single point. Since most users here have 3-4 accounts on different machines, this will avoid having to check each system for mail. So we don't reinvent the wheel, is such a system already available? ----------------------------------------------------------------------- Marc Lesure / Arizona State University / Tempe, AZ "Between the world of men and make-believe, I can be found..." "False faces and meaningless chases, I travel alone..." "And where do you go when you come to the end of your dream?" UUCP: ...!ncar!noao!asuvax!lesure Internet/CSNET/ARPA: lesure@asuvax.asu.edu
andrew@cc.brunel.ac.uk (Andrew Findlay) (09/29/88)
In article <363@asuvax.UUCP> system@asuvax.UUCP (Marc Lesure) writes: >We want to develop a mail system server which will receive and store mail >from remote systems. Users will be able to send, read, query their mail >from any machine (regardless of OS) from a single point. Since most users >here have 3-4 accounts on different machines, this will avoid having to >check each system for mail. So we don't reinvent the wheel, is such a >system already available? Look at POP (Post Office Protocol), distributed as part of the MH Mail Handler and also used in other things (such as Sun's Lifeline Mail for PCs running PCNFS). Before starting a major project you should also think about the implications of X.400. This has the concept of a `message store' such as you propose. At Brunel we have a partial solution to the problem you describe: All networked machines use NFS so users only have a single home directory however many machines they might use. We put the mailbox in the home directory, so it is visible on all machines. Our case is perhaps simpler than most, as we only have to worry about Unix machines and PCs. Andrew -- --------------------------------------------------------------------- | From Andrew Findlay at Brunel University, Uxbridge, UB8 3PH, UK | | Andrew.Findlay@brunel.ac.uk phone: +44 895 74000 x2512 | ---------------------------------------------------------------------
page@swan.ulowell.edu (Bob Page) (10/04/88)
[I added comp.protocols.nfs to the newsgroups line, followups to comp.mail.misc] [The problem is how to make a user's mailbox available on any machine they log into] Andrew.Findlay@brunel.ac.uk (Andrew Findlay) wrote: >We put the mailbox in the [NFS] home directory, so it is visible >on all machines. How do you deal with record locking over NFS? We do something similar (we export /usr/spool/mail, a questionable practice in itself) but tell everyone to read mail from one host so their mail doesn't get clobbered. I'd like to find a better way. ..Bob -- Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page
cball@ishmael (10/04/88)
>/* Written 8:44 pm Oct 3, 1988 by page@ulowell.UUCP in ishmael:comp.mail.misc */ >... >Andrew.Findlay@brunel.ac.uk (Andrew Findlay) wrote: >>We put the mailbox in the [NFS] home directory, so it is visible >>on all machines. > >How do you deal with record locking over NFS? >... It's possible to avoid the record locking problem by automatically adjusting .forward files or aliases to match the host you are currently logged into. This can easily be done during login initialization. Charles Ball Intermetrics, Inc.
cochran@cadsun.DAB.GE.COM (Craig Cochran) (10/05/88)
In article <9449@swan.ulowell.edu> page@swan.ulowell.edu (Bob Page) writes: > >[The problem is how to make a user's mailbox available on any machine > they log into] > >Andrew.Findlay@brunel.ac.uk (Andrew Findlay) wrote: >>We put the mailbox in the [NFS] home directory, so it is visible >>on all machines. > >How do you deal with record locking over NFS? > >We do something similar (we export /usr/spool/mail, a questionable >practice in itself) but tell everyone to read mail from one host so >their mail doesn't get clobbered. > >I'd like to find a better way. > >..Bob >-- >Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page At GE, Daytona Beach, we have a network of over 100 Suns with a common set of mailboxes. We have the spool area in a commonly mounted area, with /usr/spool/mail as a link to this area on all machines. Then the sendmail.cf files are configured to let one system, the mail server, route all mail, so that only one system appends to anyone's mailbox. Any system may read the mail. This has worked fine with no problems, with users constantly reading their mail from different machines. -Craig -- Craig S. Cochran <cochran@ge-dab.GE.COM> General Electric Company UUCP: ...!mcnc!ge-rtp!ge-dab!cochran 1800 Volusia Ave, Rm 4112 Phone: (904) 239-3124 Daytona Beach, FL 32015
nowicki%rose@Sun.COM (Bill Nowicki) (10/07/88)
> Andrew.Findlay@brunel.ac.uk (Andrew Findlay) wrote: > >We put the mailbox in the [NFS] home directory, so it is visible > >on all machines. > How do you deal with record locking over NFS? The standard mail software does not use record locking, so it is not an issue. Note that in SunOS 4.0 the scheme using NFS to mount your mailbox (now /var/spool/mail) is fully supported. All you need to do is add the appropriate entry to /etc/fstab, and the rest should all work automagically. The standard sendmail.cf files route outgoing mail through the server, so that even the replies go to the server directly. We have been running here for quite some time with mail boxes on servers, and it works well (unbiased opinion :-). -- WIN
moore@cygnusx1.cs.utk.edu (Keith Moore) (10/07/88)
Someone asked (regarding mail delivery software on NFS systems): > How do you deal with record locking over NFS? To which Bill Nowicki <nowicki%rose@Sun.COM> replied: >The standard mail software does not use record locking, so it is not an >issue. Note that in SunOS 4.0 the scheme using NFS to mount your >mailbox (now /var/spool/mail) is fully supported. [...] This is fine if you happen to be using Suns and running SunOS 4.0. However, several other kinds of machines use NFS now and even some of us who use Suns have good reasons for not running SunOS 4.x. We would still like to be able to access our /{usr,var}/spool/mail files on a server from different machines. It would be even nicer if the method chosen were compatable with that used by SunOS 4.x. Perhaps the original question should have been: How does the mail software deal with *file* locking over NFS? Can anyone answer this one? Keith Moore UT Computer Science Dept. Internet/CSnet: moore@utkcs2.cs.utk.edu 107 Ayres Hall, UT Campus BITNET: moore@utkcs1 Knoxville Tennessee 37996-1301 Telephone: +1 615 974 0822
mike@ists (Mike Clarkson) (10/08/88)
In article <584@utkcs2.cs.utk.edu|, moore@cygnusx1.cs.utk.edu (Keith Moore) writes: | Someone asked (regarding mail delivery software on NFS systems): | | How do you deal with record locking over NFS? | | To which Bill Nowicki <nowicki%rose@Sun.COM| replied: | |The standard mail software does not use record locking, so it is not an | |issue. Note that in SunOS 4.0 the scheme using NFS to mount your | |mailbox (now /var/spool/mail) is fully supported. | | This is fine if you happen to be using Suns and running SunOS 4.0. However, | several other kinds of machines use NFS now and even some of us who use Suns | have good reasons for not running SunOS 4.x. ... | | How does the mail software deal with *file* locking over NFS? Before Sun OS 4.0, it doesn't. The mailer utilities had to be rewritten to use the network lock daemon. -- Mike Clarkson mike@ists.UUCP Institute for Space and Terrestrial Science mike@ists.yorku.ca York University, North York, Ontario, uunet!mnetor!yunexus!ists!mike CANADA M3J 1P3 +1 (416) 736-5611
honey@umix.cc.umich.edu (Peter Honeyman) (10/08/88)
i abandoned the flock/lockf/whatever approach for file system locks. i put my locks in /usr/spool/mail/.lock and use the atomic link trick. not high tech, i know, but i have suns, vaxen, and rt's nfs-ed together, and don't want to worry about who has a lock protocol that works. peter
meissner@xyzzy.UUCP (Usenet Administration) (10/09/88)
In article <584@utkcs2.cs.utk.edu> moore@cygnusx1.cs.utk.edu (Keith Moore) writes: | Perhaps the original question should have been: | | How does the mail software deal with *file* locking over NFS? The tradional way mail has handled locking is as follows: When some mail agent (/bin/rmail to deliver new mail, or any of mailx/Mail/mh/elm to delete old mail) wants to modify the mailbox for a user "joe", it creates a file in the spool directory with ".lock" tacked on (/usr/spool/mail/joe.lock for BSD systems, /usr/mail/joe.lock for system V), with options to open to fail if the file exists. If the file exists, it means that some process is updating the mailbox, and the process loops for some period of time trying to gain access to the mailbox. As soon as the mailbox is not being updated, the lock should be removed. For example, when you read the mail, your mail reader should lock the mailbox, read the mail file into a private spool file, and unlock it immediately, and then let you read, delete, file, etc. the mail at your leisure. At the end, it would do the lock again, do any changes, and unlock. The biggest downfall of this scheme is if the system or mail agent crashes, your mailbox is left locked. Another problem, though more minor, is that other programs attempting to lock the mailbox, are not notified when the mailbox is unlocked. Some schemes (system V) put the pid in the lockfile, and use kill(pid,0) to determine if the locker is still there, and if not break the lock. This generally can cause problems in an NFS environment, since pids are local to each system. There are two problems with using flock/lockf/fcntl to lock the mailboxes, 1) until recently NFS did not allow locking; and 2) all of the other programs that dealt with locking (such as elm) would have to change as well (this has been a problem for elm in the past). I hope I haven't bored the old-timers out there...... -- Michael Meissner, Data General. Uucp: ...!mcnc!rti!xyzzy!meissner Arpa: meissner@dg-rtp.DG.COM (or) meissner%dg-rtp.DG.COM@relay.cs.net
moore@cygnusx1.cs.utk.edu (Keith Moore) (10/09/88)
In article <4899@umix.cc.umich.edu> honey@citi.umich.edu (Peter Honeyman) writes: }i abandoned the flock/lockf/whatever approach for file system locks. i }put my locks in /usr/spool/mail/.lock and use the atomic link trick. } }not high tech, i know, but i have suns, vaxen, and rt's nfs-ed }together, and don't want to worry about who has a lock protocol that }works. } } peter 'Scuse me, but I thought that the 'atomic link trick' was broken across NFS mounted filesystems, due to NFS's lazy directory caching scheme. If the method of using lock files across NFS does indeed work, then why is that Sun claims that sharing the /usr/spool/mail directory doesn't work until SunOS 4.0? We are working on adapting all of our mail user agents to use lockf() (or is it flock()? I can't keep 'em straight) so we can share the spool directory. We are also looking into using POP. If there's an easier way that really works, we'd like to know about it. [Note: running SunOS 4.x is NOT the answer...it causes more problems than it solves, and we have other machines besides Suns.] Keith Moore UT Computer Science Dept. Internet/CSnet: moore@utkcs2.cs.utk.edu 107 Ayres Hall, UT Campus BITNET: moore@utkcs1 Knoxville Tennessee 37996-1301 Telephone: +1 615 974 0822
david@ms.uky.edu (David Herron -- One of the vertebrae) (10/10/88)
I'm (now) one of the coordinators of the MMDF sources and am currently
working on this problem ... in the context of MMDF.
For this place where I am now we have a wide mix of machines. Vaxen
of various shapes & sizes, a Sun server & some Sun workstations, a
Sequent Balance, and a student lab full of 3b2's & 3b1's. It was
felt that it would be 'nice' if, ignoring the 3b[21]'s, all our machines
could have shared access to mailboxes, either through some POP like
protocol or with NFS.
The project to develop the POP-like protocol got abandoned. So, later
I came up with a scheme to run under MMDF, which I am still testing
out. I use NFS to access the mailbox directory. For file locking I
have a directory (/usr/spool/mbxlckdir == MBXLCKDIR) into which I put
lock files. (I made a little simplification here, the only files for
which I'm providing this locking is the system mailboxes, the other
mailboxes use the normal locking meaning that the locks only work
within one particular system). There's some heuristics involved with
the lock files, in the lock file I put the system name and pid of the
owner, then later there are checks when someone else tries to acquire
the lock.
I went with this because 1) I was also wanting to support RFS with
the same type of thing and I didn't know if RFS did locks across
systems, 2) not all of our NFS's supported flock() anyway, and 3) for
some reason I don't 'trust' across-the-net flock()s.
Currently my heuristics don't work... I have to debug it, but I have
to get time to go back to it. Also NFS errors (timeouts and the like)
cause the mail readers to get confused. BUT, we are able to read
mail across NFS and have it usually work. Possibly ALWAYS work with
a little bit of effort put into the code. And it's really nice to
be able to read mail from anywhere.
It is possible that, for MMDF anyway, someone could fix up a copy
of libmmdf.a & mail reader such that someone on a PC running PC-NFS
(this could also be an Amiga with Ameristar TCP/IP/NFS) could send
& read mail from their PC. Mailbox access would be across the net,
and mail sending could be with either code that does SMTP or does
the user-agent-to-submit protocol that MMDF uses internally. Again,
across the network. I would be interested in seeing that capability,
but don't have the time to develop it myself.
--
<-- David Herron; an MMDF guy <david@ms.uky.edu>
<-- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<--
<-- "Smarter than the average pagan god ... "george@iguanodon.cis.ohio-state.edu (George M. Jones) (10/10/88)
meissner@xyzzy.UUCP (Michael Meissner) writes:
Some schemes (system V) put the pid in the lockfile, and use
kill(pid,0) to determine if the locker is still there, and if not
break the lock. This generally can cause problems in an NFS
environment, since pids are local to each system.
Hmmm. Seems like one way of extending this mechanisim is to put something
like "host.org.dom:pid" in the lockfile. This would allow machines that
share filesystems to use lock files and provide some means of being able
to find out if the process in question is still alive. Just some random
thoughts...now, actualy getting something like this implemented in all
existing mail programs, that is another matter all together.
---George Jones
-=-
OSU Computer & Inf. Science 2036 Neil Ave.,Columbus,Ohio 43210. 614-292-7325
george@cis.ohio-state.edu or ...!osu-cis!george
Quality of life can be measured as the inverse of lawyers per thousand.mike@ists (Mike Clarkson) (10/12/88)
In article <1431@xyzzy.UUCP>, meissner@xyzzy.UUCP (Usenet Administration) writes: > When some mail agent (/bin/rmail to deliver new mail, or any of > mailx/Mail/mh/elm to delete old mail) wants to modify the mailbox for > a user "joe", it creates a file in the spool directory with ".lock" > tacked on (/usr/spool/mail/joe.lock for BSD systems, > /usr/mail/joe.lock for system V), with options to open to fail if the > file exists. > > If the file exists, it means that some process is updating the > mailbox, and the process loops for some period of time trying to gain > access to the mailbox. As soon as the mailbox is not being updated, > the lock should be removed. For example, when you read the mail, your > mail reader should lock the mailbox, read the mail file into a private > spool file, and unlock it immediately, and then let you read, delete, > file, etc. the mail at your leisure. At the end, it would do the lock > again, do any changes, and unlock. Other big problem is that your local delivery agent has to be able to write into /usr/spool/mail to make the lock (or to send mail to someone for the first time). Either /usr/spool/mail is mode 777, a *very* nasty security hole, or your delivery agent is suid root. Same goes for you local mailbox reading programs (elm, movemail in gnu emacs, etc.) who have to lock the mailbox against /bin/mail when they are fetching the mail. But suid root breaks across NFS for security reasons: root becomes a no-priviledged user "nobody". The way we got around this was to make /usr/spool/mail group daemon writable, and made our delivery agents and fetchers sgid daemon. sgid daemon works across NFS, so everyone's happy. They all can fetch and release the lock, and /usr/spool/mail is still write-protected. > There are two problems with using flock/lockf/fcntl to lock the > mailboxes, 1) until recently NFS did not allow locking; and 2) all of > the other programs that dealt with locking (such as elm) would have > to change as well (this has been a problem for elm in the past). NFS supported file-locking with the lockd daemon (usually :-). The problem is that /bin/mail had to be rewritten to to use the new calls to the network locking. This was done in 4.0, and at the same time, the lockd bugs were alledgedly squashed. I say alledgedly because trashing unlocked mailboxes is a relatively rare occurence. It takes bad timing, and it may be a little while before we see if everything really works. Note also that elm will have to be re-written to take advantage of lockd. -- Mike Clarkson mike@ists.UUCP Institute for Space and Terrestrial Science mike@ists.yorku.ca York University, North York, Ontario, uunet!mnetor!yunexus!ists!mike CANADA M3J 1P3 +1 (416) 736-5611
jpd@etive.ed.ac.uk (Paul Dourish) (10/14/88)
In article <226@ists> mike@ists (Mike Clarkson) writes: >In article <1431@xyzzy.UUCP>, meissner@xyzzy.UUCP (Usenet Administration) writes: >> When some mail agent [...] wants to modify the mailbox for >> a user "joe", it creates a file in the spool directory with ".lock" >> tacked on [...] with options to open to fail if the >> file exists. > >NFS supported file-locking with the lockd daemon (usually :-). >The problem is that /bin/mail had to be rewritten to to use the >new calls to the network locking. This was done in 4.0, and at the >same time, the lockd bugs were alledgedly squashed. Actually, "correct" mailbox locking predates this -- 4.3BSD introduced a version of /bin/mail which actually used flock() to lock the mailbox. Imagine my surprise when I ported my mail user agent away from a 4.3BSD VAX and discovered that the mailbox locking didn't work in other places! Since 4.3, the flock() (or equivalent) call in other systems has filtered through slowly. I'm surprised it took until 4.0 to reach SunOS. -- Paul Dourish, JANET: jpd@uk.ac.ed.itspna Concurrent Supercomputer Project, ARPA: jpd%ed.itspna@nss.cs.ucl.ac.uk Edinburgh University Computing Service UUCP: ...!uunet!mcvax!ukc!itspna!jpd "Ain't they got no barbers where you come from, boy?"
mike@ists (Mike Clarkson) (10/21/88)
In article <844@etive.ed.ac.uk>, jpd@etive.ed.ac.uk (Paul Dourish) writes: > Since 4.3, the flock() (or equivalent) call in other systems has filtered > through slowly. I'm surprised it took until 4.0 to reach SunOS. I'm not: Look how long Sun's brain-dead uucp has survived. (No smiley face) Mike. -- Mike Clarkson mike@ists.UUCP Institute for Space and Terrestrial Science mike@ists.yorku.ca York University, North York, Ontario, uunet!mnetor!yunexus!ists!mike CANADA M3J 1P3 +1 (416) 736-5611
root@dutentb.UUCP (The System Administrator) (05/23/89)
The idea: we want to use one machine as the mail server in a cluster of machines. All machines (HP, Sun, Apollo) will mount the mail spool area, and sendmail will be the server. We want to hide the name of all the clients: we need sendmail config files and may be some extra software. The mail server has an uucp link with the outside world. We are looking for sendmail config files and/or some extra programs. Who as done this already, and can help us with some data? -- Delft University of Technology Phone: 3115 - 786234 Department of Electrical Engineering Telefax: 3115 - 783622 Mekelweg 4, Delft 2628 CD email: ..!mcvax!hp4nl!dutentb!root The Netherlands