Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!ut-sally!pyramid!decwrl!sun!guy From: guy@sun.uucp (Guy Harris) Newsgroups: net.unix-wizards Subject: Re: UUCP USERFILE Message-ID: <5599@sun.uucp> Date: Tue, 29-Jul-86 14:30:11 EDT Article-I.D.: sun.5599 Posted: Tue Jul 29 14:30:11 1986 Date-Received: Wed, 30-Jul-86 00:52:37 EDT References: <1759@brl-smoke.ARPA> <976@decuac.DEC.COM> <459@oracle.UUCP> <5431@topaz.RUTGERS.EDU> <5561@sun.uucp> <538@pyramid.UUCP> Organization: Sun Microsystems, Inc. Lines: 96 > But that is exactly what we do. We are currently shipping 4.3bsd UUCP in the > Berkeley universe, and SVR2 UUCP in the AT&T universe. In a future release > we'll be supporting three: Berkeley, AT&T SVR2, and HDB. I'm certain that keeps the developers busy. It also means more pain for tech support people; they have to ask which version of UUCP the customer has chosen to use. Are you *sure* this complication was worthwhile? > Most customers pick one of the three, and stick with it. Using more than one > at a time is difficult because they have different queueing conventions; > they also cannot share the same control files. But you can have the AT&T > uucico service requests issued by the AT&T uux and uucp, the Berkeley > uucico service requests from the Berkeley uux and uucp, etc. With careful > use of symbolic links you can also get them to use the same dialout modems. Exactly. You can't run them both at the same time, pretending that your system is all things to all people, without some pain (user A makes a request to send something across the country using one universe's UUCP, and then user B makes a request to send something across the country using the other universe's UUCP - you now have to make *two* phone calls where one would suffice). How much expertise is required to make this "careful use of symbolic links"? You've also increased the administrative hassles (the system administrator must now keep track of two - or three - UUCPs at once), and they have to be familiar with more than one version anyway. At this point, UUCP administration isn't a job for the timid *anyway*; it sounds like you'd have been better off picking one version and just having different versions of the user commands. > Yes and no. Yes we have two versions of init, one for Berkeley and one for > AT&T. And yes, they *both* know how to read both /etc/ttys and /etc/inittab, > and do them correctly. (Within limits. When setting the baud, for example, > the ucb init uses /etc/gettytab, and the att init uses /etc/inittab.) But > no, you can't use both simultaneously; you have to chose one or the other. Again, my point exactly. You don't have two universes; you have one universe (the one from which "init" comes) and part of another. Fortunately, the signal to tell "init" to read its control file happens to be the same in both versions of "init" (SIGHUP), but now any program that enables and disables ports either has to have its port in the file from the version it knows about (which means a program that knows about the other version can't use that port) or has to look at both files (in which case it has to be modified to know that there are two such files). The administrator would now have to know about this quirk. > Sounds like I'm doing it the wrong way, then; sorry about that (seriously). > I'm holding to the dual-port philosophy, which means both versions of UUCP > are available for the customer to chose which he prefers. I have had a few > customer requests for a hybrid uucico that understands both Berkeley and > SVR2 queueing, and for a super-uucp that did everything of both. But I > don't think it's worth the effort to write it, especially with HDB becoming > available. With HDB becoming available, the logical choice is to ditch both V7 UUCP descendants (although HDB is also arguably a descendant of the V7 version) and provide one version, possibly after putting in a few bits of #ifdeffed code so that you can build two versions of "uucp", "uux", etc. from *one* source that provide compatible supersets of the 4.2 and S5 commands. You now have only *one* queueing mechanism, *one* protection mechanism, etc. now, so you don't have to have courses for all three, and maintainers for all three, and tech support questions about which of the three you're using, etc.. Besides, which customer gets to choose? The individual user may or may not get a choice, depending on whether the administrator wants the headaches of managing more than one version in parallel (see above). The administrator gets to choose, but any UUCP administrator who can be trusted with managing the queues him- or herself can be trusted to adapt to whatever queueing mechanism you provide. > >> By the way, is the new Userfile a feature of SVr2, SVr3, or HoneyDanber > >> UUCP? > > > >HoneyDanber. > > Which USERFILE feature? I thought the original question was about the login > name check; it was added in SVR2. (HDB doesn't have USERFILE; it's > equivalent is "Permissions" and it bears no resemblance to USERFILE at all.) Since they said "new Userfile", I'd assumed they meant a new file format; they may have been thinking of the "Permissions" file. > The S5R3 HDB also has a new 'e' protocol that uses TLI on streams, a small > hack that is trumpted all over the SVR3 promotional literature. I'd be > curious to know who wrote it since it doesn't look like Peter & company's > work. Peter & company's "UUCP on top of a network" protocol *was* called the 'e' protocol, and like the S5R3 one it writes the file size as a printable ASCII string first. I suspect it is the original one, modified as necessary to use TLI. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)