becker@ziebmef.uucp (Bruce Becker) (06/28/88)
I've been having a problem with my 7300/3b1, in that it won't receive uucp logins from anyone at all (BAD LOGIN/MACHINE NAME), but I can connect to any machine by dial-out... I don't understand why... If any 3b1 users have had this problem, please email some suggestions to me... Thanks, Bruce Becker UUCP: ...!unicus!becker!bdb, ...!lsuc!humvax!becker, ...!ncrcan!ziebmef!becker BitNet: BECKER@HUMBER.BITNET
jeff@cjsa.UUCP (C. Jeffery Small) (06/30/88)
In article <1988Jun27.202651.9458@ziebmef.uucp>, becker@ziebmef.uucp (Bruce Becker) writes: > I've been having a problem with my 7300/3b1, in that it won't > receive uucp logins from anyone at all (BAD LOGIN/MACHINE NAME), but I > can connect to any machine by dial-out... I don't understand why... > If any 3b1 users have had this problem, please email some suggestions > to me... I had this very problem when I first set up USENET software. I believe the problem has to do with the way uucp, nuucp, etc. entries appear and are parsed in the passwd file. I believe that your problem will go away (and your security increased) if you make seperate password entries with unique uids for each machine that you wish to allow to dial in. I hope this helps. -- Jeffery Small (203) 776-2000 UUCP: uunet!---\ C. Jeffery Small and Associates ihnp4!--- hsi!cjsa!jeff 123 York Street, New Haven, CT 06511 hao!noao!---/
brant@manta.UUCP (Brant Cheikes) (07/03/88)
In article <103@cjsa.UUCP> jeff@cjsa.UUCP (C. Jeffery Small) writes: >In article <1988Jun27.202651.9458@ziebmef.uucp>, becker@ziebmef.uucp writes: >> I've been having a problem with my 7300/3b1, in that it won't >> receive uucp logins from anyone at all (BAD LOGIN/MACHINE NAME), but I >> can connect to any machine by dial-out... I don't understand why... [...] >I had this very problem when I first set up USENET software. I believe >the problem has to do with the way uucp, nuucp, etc. entries appear and >are parsed in the passwd file. My suggestion would be to check the /etc/inittab file for an entry that attaches a getty (or uugetty) to the modem port. You must have a line of the form: ph1:2:respawn:/usr/lib/uucp/uugetty -r -t60 ph1 1200 (leading space essential) This puts a uugetty on the phone line waiting for an incoming connection. I believe the getty initializes the port to answer incoming calls. You may need to replace /usr/lib/uucp/uugetty above with /etc/getty. Without a getty, your machine won't answer. -- Brant Cheikes University of Pennsylvania Department of Computer and Information Science Internet: manta!brant@bpa.bell-atl.com, UUCP: {bpa,drexel}!manta!brant
mhm@cbterra.ATT.COM (Mike H. Moran) (07/04/88)
In article <382@manta.UUCP>, brant@manta.UUCP (Brant Cheikes) writes: > In article <103@cjsa.UUCP> jeff@cjsa.UUCP (C. Jeffery Small) writes: > >In article <1988Jun27.202651.9458@ziebmef.uucp>, becker@ziebmef.uucp writes: [ much stuff about inittab enteries, etc ....] > This puts a uugetty on the phone line waiting for an incoming > connection. I believe the getty initializes the port to answer > incoming calls. You may need to replace /usr/lib/uucp/uugetty above > with /etc/getty. Without a getty, your machine won't answer. Not quite true, uugetty is supposed to be intelligent :-) in that it will answer incomming calls as well as allow out going calls on the same port without need of inittab modfication. Mike Moran Contracted to AT&T-BL UUCP: att!cbosgd!mhm Columbus, Ohio mhm@cbosgd.att.com
jcs@tarkus.UUCP (John C. Sucilla) (07/05/88)
In article <382@manta.UUCP> brant@manta.UUCP (Brant Cheikes) writes: >In article <103@cjsa.UUCP> jeff@cjsa.UUCP (C. Jeffery Small) writes: >>In article <1988Jun27.202651.9458@ziebmef.uucp>, becker@ziebmef.uucp writes: >>> I've been having a problem with my 7300/3b1, in that it won't >>> receive uucp logins from anyone at all (BAD LOGIN/MACHINE NAME), but I >>I had this very problem when I first set up USENET software. I believe >>the problem has to do with the way uucp, nuucp, etc. entries appear and >>are parsed in the passwd file. >My suggestion would be to check the /etc/inittab file for an entry >that attaches a getty (or uugetty) to the modem port. You must have a >line of the form: The fact that he's getting a bad login/machine name in his log files are proof that he has a getty of some kind running on the port. I'd say that /usr/lib/uucp/Permissions is the problem. Try temporarily setting it to the lowest possible level of security and see what happens. This ought work: MACHINE=OTHER REQUEST=yes READ=/ WRITE=/ SENDFILES=yes COMMANDS=rmail:rnews:uux Later, if you find that the Permissions file (I think this was the users file in pre-HoneyDanber uucp) was to blame you can start getting fancy with it by creating seperate entries for each machine you talk to. -- John "C". Sucilla, A silicon based life form. {ihnp4,chinet,ddsw1}!tarkus!jcs You have a better idea? Now's the time..
cks@ziebmef.uucp (Chris Siebenmann) (07/05/88)
Bruce and I managed to track down and solve (sort of) this problem;
it was apparently a bad USERFILE. However, I looked at it and it
looked fine, and very similar to the one I use here. Are there any
known limitations of the 3.51 USERFILE?
Also, are there any guides to 'troubleshooting UUCP connections'?
I've got quite good at finding problems (having stubbed my toes on
most of them by now :-(), but there are undoubtedly other traps just
lurking out there just waiting for me. I have the Nutshell handbook
_Managing UUCP and USENET_ and have found it quite valuable; is there
anything else people would recommend? Better yet, is there some
documentation on the bugs ... ahem, idiosyncracies of the stock 3B1
uucp?
While I'm here ... Hint #38: Have an external modem you need to dial
with a chat script (to, say, dial something with pulse and then switch
to tone-dialing to get through a PBX), but don't want to always assert
CD on the modem (uucico requires DCD before it will go into the chat
script on a direct connection)? Just define a really dumb modem that
does nothing in modemcap, and point the appropriate L-devices entry at
it. Unfortunately, this means you have to dial via chat scripts for
all connections over that modem at that speed, but it's better than
nothing...
--
You're a prisoner of the dark sky/The propeller blades are still
And the evil eye of the hurricane's/Coming in for the kill
Chris Siebenmann uunet!utgpu!{ontmoh!moore,ncrcan}!ziebmef!cks
cks@ziebmef.UUCP or .....!utgpu!{,ontmoh!,ncrcan!brambo!}ckscks@ziebmef.uucp (Chris Siebenmann) (07/05/88)
In article <103@cjsa.UUCP> jeff@cjsa.UUCP (C. Jeffery Small) writes: ... >I had this very problem when I first set up USENET software. I believe >the problem has to do with the way uucp, nuucp, etc. entries appear and >are parsed in the passwd file. I believe that your problem will go away >(and your security increased) if you make seperate password entries with >unique uids for each machine that you wish to allow to dial in. Actually, all uucp dialins have to share the same UID as 'uucp'. If they don't, connections fail with a very obscure error message (I believe 'BAD LOGIN/MACHINE NAME' again) -- I got bitten by this when I first set up the uucp logins on ziebmef. In hindsight, this makes sense; it means that people can't just invoke uucico from their own accounts and pretend to be some random machine. Instead you somehow have to set your uid to the 'uucp' UID. Could have been worse, I suppose; they could have hardcoded the uucp UID into uucico instead of looking it up in /etc/passwd. -- You're a prisoner of the dark sky/The propeller blades are still And the evil eye of the hurricane's/Coming in for the kill Chris Siebenmann uunet!utgpu!{ontmoh!moore,ncrcan}!ziebmef!cks cks@ziebmef.UUCP or .....!utgpu!{,ontmoh!,ncrcan!brambo!}cks
jeff@cjsa.UUCP (C. Jeffery Small) (07/06/88)
In article <1988Jul4.173733.7088@ziebmef.uucp>, cks@ziebmef.uucp (Chris Siebenmann) writes: > > Actually, all uucp dialins have to share the same UID as 'uucp'. If > they don't, connections fail with a very obscure error message (I > believe 'BAD LOGIN/MACHINE NAME' again) -- I got bitten by this when I > first set up the uucp logins on ziebmef. > > In hindsight, this makes sense; it means that people can't just > invoke uucico from their own accounts and pretend to be some random > machine. Instead you somehow have to set your uid to the 'uucp' UID. > Could have been worse, I suppose; they could have hardcoded the uucp > UID into uucico instead of looking it up in /etc/passwd. This is certainly not true here. I have fifteen or so accounts set up for uucico login - all with different UIDs. However, they each share the uucp (ie. mail) group ID. Since uucico doesn't run setgid, this doesn't seem to matter one way or the other. Possibly someone with source could take a look and see just what sequence of events occur when a uucico session starts up. I would be interested in being enlightened further. -- Jeffery Small (203) 776-2000 UUCP: uunet!---\ C. Jeffery Small and Associates ihnp4!--- hsi!cjsa!jeff 123 York Street, New Haven, CT 06511 hao!noao!---/
becker@ziebmef.uucp (Bruce Becker) (07/07/88)
In article <3915@cbterra.ATT.COM> mhm@cbterra.ATT.COM (Mike H. Moran) writes: >In article <382@manta.UUCP>, brant@manta.UUCP (Brant Cheikes) writes: >> In article <103@cjsa.UUCP> jeff@cjsa.UUCP (C. Jeffery Small) writes: >> >In article <1988Jun27.202651.9458@ziebmef.uucp>, becker@ziebmef.uucp writes: > >[ much stuff about inittab enteries, etc ....] > >>[ much stuff about uugetty, etc ....] > >Not quite true, uugetty is supposed to be intelligent :-) in that it >will answer incomming calls as well as allow out going calls on the >same port without need of inittab modfication. So where can I get a copy of uugetty for the 3b1? Cheers, Bruce Becker UUCP: ...!unicus!becker!bdb, ...!lsuc!humvx!becker, ...!ncrcan!ziebmef!becker BitNet: BECKER@HUMBER.BITNET
rjg@sialis.mn.org (Robert J. Granvin) (07/08/88)
> Bruce and I managed to track down and solve (sort of) this problem; >it was apparently a bad USERFILE. However, I looked at it and it >looked fine, and very similar to the one I use here. Are there any >known limitations of the 3.51 USERFILE? One. If you add your 101st entry, it'll "die." Oh, it's even better than that. No system will ever be able to make a UUCP connection with your machine until you bring to to 100 entries or under. Neat? > Also, are there any guides to 'troubleshooting UUCP connections'? >I've got quite good at finding problems (having stubbed my toes on >most of them by now :-(), but there are undoubtedly other traps just >lurking out there just waiting for me. I have the Nutshell handbook >_Managing UUCP and USENET_ and have found it quite valuable; is there >anything else people would recommend? Better yet, is there some >documentation on the bugs ... ahem, idiosyncracies of the stock 3B1 >uucp? The 3b1 has a goofy OBM. (Also, please refer to some immediately previous replies to other messages). Asides from handshaking an OBM connection and then not knowing what to do from there, it's also something that is apparently out of spec from certain areas. Some modems, including Telebit's under certain connections will always hang up after attempting to establish a connection with the given carrier. The "unusual" thing about it also, is that if you dial _out_ using the OBM into one of these modems, the same connection will be rejected as well. Otherwise, the 3b1 generally operates similarly or as well as other System V machines/implementations (not taking the bug list into account, of course :-) -- "I've been trying for some time to Robert J. Granvin develop a life-style that doesn't National Information Systems, Inc. require my presence." rjg@sialis.mn.org -Garry Trudeau ...{{amdahl,hpda}!bungia,rosevax}!sialis!rjg
james@bigtex.uucp (James Van Artsdalen) (07/16/88)
IN article <1988Jul4.173733.7088@ziebmef.uucp>, cks@ziebmef.UUCP (Chris Siebenmann) wrote: > Actually, all uucp dialins have to share the same UID as 'uucp'. If uucico should be suid to the uucp user. uucico doesn't care what the real uid is. It does use the login name to reference the Permissions file (assuming we're talking HDB uucp). > In hindsight, this makes sense; it means that people can't just > invoke uucico from their own accounts and pretend to be some random > machine. Instead you somehow have to set your uid to the 'uucp' UID. > Could have been worse, I suppose; they could have hardcoded the uucp Actually, I understand that the uucp uid is indeed a configurable constant in the uucp package. I can't imagine what it's used for though: if someone forgets to make uucico suid, that will be obvious soon enough, and file read/write permissions are based on the Permissions file and whether or not the file is readable/writable by "other". The security measures to prevent someone from spoofing uucp this way revolve around the use of the Permissions file and the VALIDATE keyword (if you don't use VALIDATE, do so). When uucico is started in master mode, the transfer permissions are granted based on the machine name. But when uucico is started in slave mode (as it would be if a user ran it), permissions are granted based on the login name, *not* the machine name. This is why VALIDATE is so important. Note that uucico takes the login name from /etc/utmp to prevent spoofing (or at least it should). -- James R. Van Artsdalen ...!ut-sally!utastro!bigtex!james "Live Free or Die" Home: 512-346-2444 Work: 328-0282; 110 Wild Basin Rd. Ste #230, Austin TX 78746