UUCP USERFILE

[Guy Harris]

> 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 at sun.com (or guy at sun.arpa)