UUCP USERFILE

[Carl S. Gutekunst]

[In a previous followup to one of Guy's postings (ranlib on a Pyramid), I made
an utter fool of myself; in my personal apology to Guy I mentioned that he
should give me some UUCP questions 'cause those I can handle. Thanks Guy! :-)]

Just some points of information, more for other netters than for Guy or Chuck
(since they already know most of this stuff):

>>  Pyramid, which you mention, is of
>> course the last place you would expect to find a System V UUCP mixed into a
>> 4.2 system.  They maintain separate 4.2 and System V universes.  Thus they
>> have two separate UUCP's.
>
>I very sincerely doubt that.  Maintaining two different versions of "uucico"
>would be ridiculous.

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. 

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. 

>(Does Pyramid have two versions of "init", for
>instance?  You can't do that.  You have to choose one or the other, or have
>a hybrid that reads "/etc/ttys" *and* "/etc/inittab" - if that's even
>possible.)

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. 

>They may have two versions of the "uucp", "uux", etc. commands -
>however, if it's possible to have versions that are a compatible superset
>of both, *that* would be the correct thing to do, not provide a version that
>can do A but not B and a version that can do B but not A.

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. 

>> 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.)

This new feature also wasn't documented anywhere. The explanation I got from
AT&T was that M.E. Lesk's original V7 document states that listing of all UUCP
logins in USERFILE is mandatory, and that all AT&T was doing was implementing
what the specification had required all along. The kicker, though, was that up
through SVR1 USERFILE was limited to 20 entries; very few sites could have
listed all of their logins! Now they've limited it to 100, which is still
probably not enough.... 

>I think HoneyDanber is now the standard version of UUCP in S5R3. 

Correct. The current 3B release of SVR2 also includes HDB as standard. (Both
are woefully lacking in transition tools. *SIGH*) 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. (It's obvious from the labels that
the 'e' originally meant Ethernet.... :-)) 

<csg>