Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site down.FUN Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!down!honey From: honey@down.FUN (code 101) Newsgroups: net.bugs.uucp Subject: Re: System V introduces yet another inconsistency Message-ID: <464@down.FUN> Date: Thu, 7-Mar-85 07:47:32 EST Article-I.D.: down.464 Posted: Thu Mar 7 07:47:32 1985 Date-Received: Fri, 8-Mar-85 03:46:40 EST References: <454@lsuc.UUCP> <530@rlgvax.UUCP> <27@axiom.UUCP> Organization: Princeton University, EECS Lines: 33 steve claims certain benefits of having different logins for each neighbor machine. this is impractical. i have published princeton's uucp dope many times: i want as many people as possible to call me, even though i won't call them back if they're too far away. (pathalias solves the reply problem.) i'm not about to add thousands of /etc/passwd entries. what \is/ practical is to break the universe into equivalence classes of capabilities/permissions. in my case, i use four uucp logins: login write read commands ----- ----- ---- -------- uucp PUBDIR nil rmail nuucp PUBDIR nil rmail, rnews, unbatch, cunbatch tuucp PUBDIR PUBDIR ditto + uusend, uucp luucp all all all i protect the passwds on all but the first (by giving them to people i trust), and by using the VALIDATE option in the Permissions file. instead of using who to see if a call is active, i ls /usr/spool/locks (or i run uustat -p). and since honey danber produces separate logs for each host, it's easy to gauge the frequency and reliability of a connection. besides, the honey danber conn() is perfect, and doesn't demand the TLC we are all used to providing. peter ps: here's my Systems (was L.sys) data. call me anytime. princeton Any ACU 1200 trenton4522906 "" "" in:--in: uucp word uuprince princeton Any ACU 1200 trenton4528678 "" "" in:--in: uucp word uuprince princeton Any ACU 1200 trenton6831286 "" "" in:--in: uucp word uuprince