Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!pyramid!csg From: csg@pyramid.UUCP (Carl S. Gutekunst) Newsgroups: net.unix-wizards Subject: Re: UUCP USERFILE Message-ID: <538@pyramid.UUCP> Date: Tue, 29-Jul-86 04:25:43 EDT Article-I.D.: pyramid.538 Posted: Tue Jul 29 04:25:43 1986 Date-Received: Tue, 29-Jul-86 18:57:47 EDT References: <1759@brl-smoke.ARPA> <976@decuac.DEC.COM> <459@oracle.UUCP> <5431@topaz.RUTGERS.EDU> <5561@sun.uucp> Reply-To: csg@pyramid.UUCP (Carl S. Gutekunst) Organization: Pyramid Technology Corp., Mountain View, CA Lines: 76 [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.... :-))