wesommer@athena.mit.edu (William Sommerfeld) (09/26/89)
Why aren't there more people using remote file systems of one sort or another? Because some sites don't trust client kernels to be secure. The critical thing is the invariants which have to be maintained across the various news databases (/usr/spool/news/*, and the history and active files). Reading news across a distributed filesystem isn't a problem; posting is, because the posting site has to be trusted to correctly maintain the invariants. The site andrew.cmu.edu is using software known as the "andrew message system", where reading is done over the Andrew distributed filesystem; however, posting is done by inserting the article into an append-only queue directory which is periodically scanned by a daemon which does have write access to the news databases. --
pleasant@porthos.rutgers.edu (Mel Pleasant) (09/26/89)
In article <WESOMMER.89Sep25144628@anubis.athena.mit.edu> wesommer@athena.mit.edu (William Sommerfeld) writes: > Why aren't more people using remote file systems of one sort or another? This question really surprises me. B news has had the code in it since patch 14 to provide this sort of configuration. Note that the code has only been tested with nntp and NFS - but it is known to work. Client systems read the news directly through remote file access (NFS). Posting is done through nntpxmit. The client never writes into either /usr/spool/news nor /usr/lib/news. -- Mel Pleasant {backbone}!rutgers!pleasant pleasant@rutgers.edu mpleasant@zodiac.bitnet
peter@ficc.uu.net (Peter da Silva) (09/26/89)
I said: > Why aren't there more people using remote file systems > of one sort or another? [to read news] In article <WESOMMER.89Sep25144628@anubis.athena.mit.edu>, wesommer@athena.mit.edu (William Sommerfeld) writes: > Because some sites don't trust client kernels to be secure. This is an administrative problem, then... you don't trust the folks on your client workstations to not have hacked them? > The critical thing is the invariants which have to be maintained > across the various news databases (/usr/spool/news/*, and the history > and active files). I'm having a bit of a problem with your terminology here. You're saying that you have to give each site a copy, no? Under OpenNET at Ferranti, at least, there is only one copy of the news databases. Administratively all the systems are treated as a single lump. At a commercial site, at least, it's a lot less of a headache. I guess things might be different in academia. It kind of reduces the value of a distibuted filesystem, though. > [at CMU] posting is done by inserting the article into an append-only > queue directory which is periodically scanned by a daemon which does > have write access to the news databases. That's like how we handle incoming news, but only because we don't want to overload the uucp machine with news unbatching. We actually use 'rexec', a command that executes programs on a remote machine. -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "That is not the Usenet tradition, but it's a solidly-entrenched U delusion now." -- brian@ucsd.Edu (Brian Kantor)
peter@ficc.uu.net (Peter da Silva) (09/26/89)
Actually, I said: > Why aren't more people using remote file systems of one sort or another? In article <Sep.25.15.42.20.1989.2945@porthos.rutgers.edu>, pleasant@porthos.rutgers.edu (Mel Pleasant) writes: > This question really surprises me. B news has had the code in it > since patch 14 to provide this sort of configuration. Hmmm. We've been doing it since patch 13. The NNTP client stuff? I never bothered to look at it. Our network is not based on TCP/IP. It's pretty close to OSI, actually. Anyway, that code obviously would not work in our environment. I just set up localize.sh to get everything pointing to files on the newsserver, and OpenNET took care of the rest. No problems at all with clients writing right into //xds13/usr/lib/news. -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "That is not the Usenet tradition, but it's a solidly-entrenched U delusion now." -- brian@ucsd.Edu (Brian Kantor)
henry@garp.mit.edu (Henry Mensch) (09/27/89)
pleasant@porthos.rutgers.edu (Mel Pleasant) wrote:
->In article <WESOMMER.89Sep25144628@anubis.athena.mit.edu> wesommer@athena.mit.edu (William Sommerfeld) writes:
->
->> Why aren't more people using remote file systems of one sort or another?
->
->This question really surprises me.
i don't believe this was bill's question (it was someone else's
question).
i also don't believe that we are particularly interested in
NFS-mounting /usr/spool/news on one thousand clients (and yes, the
order of magnitude here is correct).
# Henry Mensch / <henry@garp.mit.edu> / E40-379 MIT, Cambridge, MA
# <hmensch@uk.ac.nsfnet-relay> / <henry@tts.lth.se> / <mensch@munnari.oz.au>karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (09/27/89)
henry@garp.mit.edu writes:
i also don't believe that we are particularly interested in
NFS-mounting /usr/spool/news on one thousand clients (and yes, the
order of magnitude here is correct).
I don't think you'd find it to be that much of a problem. We do this
with ~300 clients, and it works quite well; we anticipate no scaling
problems as we continue to add more machines. We NFS-mount /usr/{lib,
spool}/news from the server (tut.cis.ohio-state.edu) and use the
miniature NNTP inews for posting. All newsreaders are configured to
think they've got a local spool area to read. We play some kinky
symlink games to get the right inews for each machine architecture.
--Karlwesommer@athena.mit.edu (William Sommerfeld) (09/27/89)
I bet your server has more horsepower than ours; Bloom-beacon is a Microvax II, which is a 1 "MIP" CPU; on a good day, it gets about 70KB/s out of its disks; the disk bandwidth is the limiting factor, not CPU horsepower. Given that NFS doesn't do flow control or adaptive retransmission, I think that we'd see a protocol meltdown *on our hardware* fairly quickly. NNTP works and adjusts to load rather gracefully. Fortunately, the MicroVAX II doesn't have the multiple process performance knee common to Sun systems. - Bill [I did hack up a single-process, multi-threaded NNTP daemon a couple of months ago, but haven't put it under a lot of load yet, so I don't know how robust it is. The source isn't in any shape worth redistributing, so don't bother asking me for it. Someday, maybe... ] --
wesommer@athena.mit.edu (William Sommerfeld) (09/27/89)
In article <6307@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: This is an administrative problem, then... you don't trust the folks on your client workstations to not have hacked them? They aren't "our" client workstations, in the sense that we don't control them, we just share a network with them. Pretty much anyone, on any system within MIT on the campus network can read and post news using our service. We provide a recommended set of sources and binaries for people to run to read news, but we don't require that they use them. > The critical thing is the invariants which have to be maintained > across the various news databases (/usr/spool/news/*, and the history > and active files). [ response indicating that I wasn't clear enough the first time ] I was hoping to save bandwith by assuming that the following was common knowledge, but I guess I was wrong. There's one copy of all this information, located on bloom-beacon.mit.edu . It is distributed across several files (/usr/lib/news/history, /usr/lib/news/active, and the tree under /usr/spool/news). There are a number of invariants which must be maintained by a program wishing to modify this database; some of these include: 0) Each directory under /usr/spool/news must have an associated line in /usr/lib/news/active, which lists the minimum and maximum article numbers in that group; the minimum article number must be less than or equal to the maximum article number. 1) Any file in a directory under /usr/spool/news must be in the proper format (defined in RFC???), containing at least a Message-ID: field; the last component of the name must consist entirely of decimal digits, with a value not more than the maximum article number nor less than the minimum article number for the group. 2) Each message-ID must appear on a line in /usr/lib/news/history, along with the names of the file that it corresponds to. 3) No more than one file under /usr/spool/news may use a given Message-ID string listed in /usr/lib/news/history. If any of these invariants are broken then news will malfunction to some lesser or greater degree. In order to maintain these invariants, the news administrator must have control over all software which modifies the underlying representation of the news database. One way to do this is to be the system administrator for all systems which may access the news database; this is not practical at a large site. Another way is to provide a high-level, abstract interface to the news database that controls and protects the underlying database; that is what NNTP provides. - Bill --
karl@godiva.cis.ohio-state.edu (Karl Kleinpaste) (09/27/89)
wesommer@athena.mit.edu writes:
I bet your server has more horsepower than ours; Bloom-beacon is a
Microvax II,
Um, yeah, you might say that a Pyramid 98x has a bit more horsepower
than a Microvax.
which is a 1 "MIP" CPU; on a good day, it gets about
70KB/s out of its disks; the disk bandwidth is the limiting factor,
not CPU horsepower.
Certainly true. Point conceded, that one must stipulate the
conditions under which NFS is acceptable. It's acceptable if the
server is up to it; ours is. Our biggest problem with NNTP reading is
that the granularity with which one can define limited-access
newsgroups (by chmod'ing the spool directory) is only per-machine
instead of per-newsgroup, as we have with NFS.eckert@immd4.informatik.uni-erlangen.de (Toerless Eckert) (09/28/89)
From article <KARL.89Sep26232743@godiva.cis.ohio-state.edu>, by karl@godiva.cis.ohio-state.edu (Karl Kleinpaste): > Our biggest problem with NNTP reading is > that the granularity with which one can define limited-access > newsgroups (by chmod'ing the spool directory) is only per-machine > instead of per-newsgroup, as we have with NFS. This is not true. You can define access to a newsgroup per-machine, and per-newsgroup. default read xfer ,!secret trusted read xfer Which will restrict access to the secrat.all hierachy to machines on the <trusted> network (or machine trusted, whatever trusted is a name for). What you cannot do with NNTP is restrict access per-user, but given that user mapping with NFS is usually consistent only over a small set of machines, and you want to use your server for a larger set of machines, this is really not a point for NFS (I am not talking about athena or the like). Also restricting access per user works correctly only with B-news 3.0. Toerless Eckert X.400: <S=eckert;OU=informatik;P=uni-erlangen;A=dbp;C=de> RFC822: eckert@informatik.uni-erlangen.de UUCP: {pyramid,unido}!fauern!eckert BITNET: tte@derrze0
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (09/29/89)
I wrote, in error: > Our biggest problem with NNTP reading is > that the granularity with which one can define limited-access > newsgroups (by chmod'ing the spool directory) is only per-machine > instead of per-newsgroup, as we have with NFS. eckert@immd4.informatik.uni-erlangen.de writes: This is not true. You can define access to a newsgroup per-machine, and per-newsgroup. ... Which will restrict access to the secrat.all hierachy to machines on the <trusted> network (or machine trusted, whatever trusted is a name for). What I had intended to say was that NNTP will allow me to restrict newsgroups on a per-machine basis, but we need to give users general access to machines with restricted access to newsgroups. NNTP can't do that, because it authenticates the machine instead of the user. What you cannot do with NNTP is restrict access per-user, but given that user mapping with NFS is usually consistent only over a small set of machines, and you want to use your server for a larger set of machines, this is really not a point for NFS (I am not talking about athena or the like). We have a single news server providing NFS news access to ~300 machines, that is, our entire department. User access to all machines is consistent, at least to the point of usernames and numeric IDs. (We do have restrictions on who can get at what machines, e.g., undergrads do not in general have any access to the news sever or its cousins. This is done by a somewhat baroque method involving fake shells for users who are not formally permitted on the system.) Also restricting access per user works correctly only with B-news 3.0. We are running 2.11.17 and find that chgrp'ing and chmod'ing the spool directories works just fine as a restriction method. We define a new group, e.g., "faculty," which owns the spool directory for cis.faculty. All faculty are members of that group. The directory is then chmod'd 0750. Only faculty can get at the newsgroup; others are informed by rn that "this newsgroup is unavailable." --Karl
brian@ucsd.Edu (Brian Kantor) (09/29/89)
We are discussing several extensions to the NNTP spec, among which are user, security, measurement, other options which would allow you to restrict access by newsgroup/user/hatsize and lots of other things. Just no solid proposals yet. Meet me in the bar at InterOp if you'd like to chat about it. - Brian