J.Purchase@cs.ucl.ac.uk (Jan Purchase) (06/18/91)
A colleague and I have been trying to setup a uucp connection between our A/UX (2.0.1) systems and are having serious and unexpected problems. I know that many people out there have got A/UX UUCP to work and I would really appreciate some tips. We have followed all the instructions in the A/UX manual and have achieved successful file transfers using uuto and uucp. However, we seem unable to persuade uux, remote email, or indeed any function which relies on uuxqt, to work at all. In all cases, uuxqt refuses to execute the command as if the originator of the command were not authorized. All commands whether they are listed in /usr/lib/uucp/L.cmds or not are refused. The same error message occurs even if a rubbish command (i.e. zzzzzz) is requested by uux. In each case the /usr/spool/uucp/LOGFILE is something like: ------------------------------- mickey!uucp (6/16-16:46:31) (C,21296,0) OK (startup) mickey!uucp (6/16-16:46:33) (C,21296,0) REQUESTED (S D.heimdaBC0039 D.heimdaBC0039 jpearce) mickey!jpearce (6/16-16:46:33) (C,21296,0) temp file created (/usr/spool/uucp/TM.21296.000) mickey!jpearce (6/16-16:46:33) (C,21296,0) Temp file stored (/usr/spool/uucp/TM.21296.000) mickey!uucp (6/16-16:46:40) (C,21296,1) REQUESTED (S D.mickeyXA0039 X.mickeyXA0039 jpearce) mickey!jpearce (6/16-16:46:40) (C,21296,1) temp file created (/usr/spool/uucp/TM.21296.001) mickey!jpearce (6/16-16:46:40) (C,21296,1) Temp file stored (/usr/spool/uucp/TM.21296.001) mickey!uucp (6/16-16:46:45) (C,21296,2) C.mickey (bldfl) mickey!uucp (6/16-16:46:45) (C,21296,2) C.mickey (bldfl) mickey!uucp (6/16-16:46:45) (C,21296,2) REQUEST (S D.heimdaXA0039 X.heimdaXA0039 uucp) mickey!uucp (6/16-16:46:45) (C,21296,2) REQUEST (S D.heimdaXA0039 X.heimdaXA0039 uucp - D.heimdaXA0039 0666) mickey!uucp (6/16-16:46:47) (C,21296,3) file removed in cntrl.c (D.heimdaXA0039) mickey!uucp (6/16-16:46:50) (C,21296,3) C.mickey (bldfl) mickey!uucp (6/16-16:46:51) (C,21296,3) OK (conversation complete tty0 32) mickey!uucp (6/16-16:46:54) (Q,21303,0) jpearce XQT DENIED (rmail purchase ) mickey!Umickey (6/16-16:47:01) (X,21310,0) XQT QUE'D (rmail jpearce ) ------------------------------- i.e. the file transfer succeeds, but remote commands (rmail, who, ps) fail. Debugging output from uuxqt is always something like: ------------------------------- ** START ** User - uucp process file - . file - .. file - .XQTDIR file - LOGDEL file - LCK..tty1 file - SYSLOG file - LCK.XQT file - AUDIT file - Log-WEEK file - LOGFILE file - D.heimdaBC0036 file - X.mickeyXA0036 Z U jpearce mickey F D.heimdaBC0036 I D.heimdaBC0036 C rmail pearce xfile - X.mickeyXA0036 chkpth failure - u=0 badfile - in: /usr/spool/uucp/D.heimdaBC0036 fin - /usr/spool/uucp/D.heimdaBC0036, fout - /dev/null, sysout - heimdall, user - jpearce cmd - rmail pearce cmd = rmail bad command ------------------------------- Could someone explain what chkpth failure is? Or badfile and bad command? Experiments have shown us that the chkpath failure is the real problem. When trivial commands are queued with uux (i.e. uux mickey!who ) uuxqt behaves normally. However if an attempt is made to redirect the output of who to a file; uuxqt again reports a chkpth failure. Hearing of uuxqt's problems with PATH and TZ, I wrote a wrapper shell script to set these environment variables up properly for the command - but it makes no difference. uuxqt is not interested in executing any command involving files, whether it is in L.cmds or not and it always fails as shown above. I have checked that all the uucp configuration files exist, have the correct permissions and contain the required information. FWDFILE and ORIGFILE both contain the name of the remote system (mickey), USERFILE has the line: Umickey,mickey /usr/spool/uucppublic Any ideas where we are going wrong? We could really use some help on this one. Cheers Jan.
alexis@panix.uucp (Alexis Rosen) (06/20/91)
J.Purchase@cs.ucl.ac.uk (Jan Purchase) writes: >A colleague and I have been trying to setup a uucp connection between >our A/UX (2.0.1) systems and are having serious and unexpected >problems. I know that many people out there have got A/UX UUCP to work >and I would really appreciate some tips. > >We have followed all the instructions in the A/UX manual and have >achieved successful file transfers using uuto and uucp. However, we >seem unable to persuade uux, remote email, or indeed any function which >relies on uuxqt, to work at all. In all cases, uuxqt refuses to execute >the command as if the originator of the command were not authorized. >All commands whether they are listed in /usr/lib/uucp/L.cmds or not >are refused. The same error message occurs even if a rubbish command >(i.e. zzzzzz) is requested by uux. >[etc.] > >I have checked that all the uucp configuration files exist, have the >correct permissions and contain the required information. FWDFILE and >ORIGFILE both contain the name of the remote system (mickey), USERFILE >has the line: > > Umickey,mickey /usr/spool/uucppublic > >Any ideas where we are going wrong? We could really use some help on this one. Well, I answered this by mail, but I'm not sure I got through. Also, I had another idea. First, what I wrote by mail: I believe you want something like this in front of the rest of your USERFILE: uucp, /usr/spool/uucppublic , /usr/spool/uucppublic ....to be honest, I'm not sure that USERFILE works exactly the way it should. But we've managed to make things work here. And what I wrote above is standard (as much as any UUCP-related thing is standard). I also seem to recall something about having a line at the beginning of your L.cmds which specifies permissible paths. Something like: PATH=/bin:/usr/bin:/usr/local/bin but that certainly isn't necessary. And it may not work in A/UX. We don't have it in our setup (which I built over a long time by trial and error). -- In addition to that, it occurs to me that if L.cmds were protected so that uucp didn't have read access to it, the symptoms described might happen. --- Alexis Rosen Owner/Sysadmin, PANIX Public Access Unix, NY alexis@panix.com {cmcl2,apple}!panix!alexis
J.Purchase@cs.ucl.ac.uk (Jan Purchase) (06/22/91)
Alexis, Thanks for your reply. > ...to be honest, I'm not sure that USERFILE works exactly the way it should. Agreed! I think there is something very screwy with /usr/lib/uucp/USERFILE and the documentation related to it; the Network admin guide implies that for my setup the file should contain: umickey,mickey /usr/spool/uucppublic but as I explained, uuxqt was refusing to remotely execute *any* command which had a standard input or output (as specified by the I and O x-file directives) other than /dev/null. Eventually, I discovered that this was because the USERFILE syntax should have been: umickey , mickey /usr/spool/uucppublic by introducing two spaces in the USERFILE, I fixed the problem! The network admin manual was wrong! It is also wrong about the format of the conversation count file /usr/lib/uucp/SQFILE. Setting it up as suggested (both machines put each others names into an otherwise blank SQFILE) does not work, uucico transactions fail with BAD SEQ errors. For example: 1 mickey!uucp (6/20-14:30:55) (C,26682,0) HANDSHAKE FAILED (BAD SEQ) Any idea what the correct setup for SQFILE is? Anyway - thanks again for your reply. > Alexis Rosen, long-suffering UUCP hack :-) ^^^^^^^^^^^^^^^^^^^^^^^^ my sympathies! Cheers Jan Purchase J.Purchase@cs.ucl.ac.uk
alexis@panix.uucp (Alexis Rosen) (06/23/91)
J.Pearce@cs.ucl.ac.uk (John Pearce) writes: > We have finally managed to track down the problem with uuxqt to > /usr/lib/uucp/USERFILE. We are using system specific uucp logins > and have found that the following entry in USERFILE solves the > problem. > > $ more USERFILE > uheimdall , heimdall /usr/spool/uucppublic > $ > > The spaces either side of the first comma that separates the login > name and system seem to be critical - without them you get the > problems my colleague reported in his earlier message. I'm _sure_ you've got this wrong. That's because neither we nor any other A/UX site I know of have to do this. I think the solution I sent you was correct, and that the reason that your entry works is that it doesn't say what you think it says. The whitespace before the comma means that the first field is finished. So there is _NO_ user name, just a system name. The comma and "heimdall" in that line are being taken as the second and third fields in the file, which are usually left blank. (They don't do anything, if I recall correctly, at least for those values, in A/UX.) I highly recommend the book "Managing uucp and Usenet", from Nutshell. If I'd had it, instead of the Pyramid UUCP man pages (Apple's _still_ don't exist), I'd have had a much easier time setting things up two years ago. > However, we have now struck another minor, but nevertheless annoying > problem. As an added security precaution we have tried to get the > conversation count feature to work. As stated in the A/UX manuals > we simply added the remote system name to the SQFILE. However, this > just results in bad sequence number messages at both ends. > [etc., more details] Well, I've never used them. But I just checked with my trusty Nutshell handbook, and it says that you've got things right here. But it also says that implemen- tations of SQFILE vary widely, and are often not implemented at all. Lastly, if you're running A/UX 2.0.0, your man pages are completely wrong anyway. They're for BSD UUCP. (Of course, Apple's "fix" for this in 2.0.1 was to replace the man pages, not the UUCP. Sigh.) I would skip the SQFILE, and stick with the individual-system logins as you have done. That's pretty good security. You could always implement callback if you're really paranoid (through USERFILE, if that works {I haven't tried it} or by writing a simple shell script to replace uushell). --- Alexis Rosen Owner/Sysadmin, PANIX Public Access Unix, NY alexis@panix.com {cmcl2,apple}!panix!alexis
mann@intacc.uucp (Jeff Mann) (06/25/91)
In article <1636@ucl-cs.uucp> J.Purchase@cs.ucl.ac.uk (Jan Purchase) writes: > >We have followed all the instructions in the A/UX manual and have >achieved successful file transfers using uuto and uucp. However, we >seem unable to persuade uux, remote email, or indeed any function which >relies on uuxqt, to work at all. In all cases, uuxqt refuses to execute >the command as if the originator of the command were not authorized. I had the same problem, with the same error reports from checkpth. I *think* uuxqt seems to have a problem with the username of the person who generated the uucico on the remote site not having an entry in the USERFILE. I don't think it should care; it should only care about the username of the uucp process that logs in. >ORIGFILE both contain the name of the remote system (mickey), USERFILE >has the line: > > Umickey,mickey /usr/spool/uucppublic > This is what I tracked it down to, although I'm not sure that I can explain it fully. To quote the UNIX Administration Guide for System V, (Thomas/Farrow, Prentice Hall): "...understanding the USERFILE is probably one of the most difficult parts about the UUCP system." In fact, I really don't want to understand it any more than I do right now, which isn't very much. All I know is that putting TWO "unknown" entries at the end of the USERFILE instead of one, seems to work. It's probably some kind of security risk, but who cares, it only gives people access to your public directory anyways. u_telly,telly /usr/spool/uucppublic uumnetor,mnetor /usr/spool/uucppublic nuucp, /usr/spool/uucppublic , /usr/spool/uucppublic , /usr/spool/uucppublic I'd really prefer to know what's going on, but I don't have the time to figure it out right now, and this method works for me. If someone else can post a better explanation or solution, please do. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Jeff Mann Inter/Access Artists' Computer Centre, Toronto [416] 535-8601 | | ...uunet!mnetor!intacc!mann intacc!mann@cs.toronto.edu mann@intacc.uucp | | The Matrix Artists' Computer Network BBS: [416] 535-7598 2400 8N1 | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
marcelo@deadzone.uucp (Marcelo Gallardo) (06/27/91)
mann@intacc.uucp (Jeff Mann) writes: >In article <1636@ucl-cs.uucp> J.Purchase@cs.ucl.ac.uk (Jan Purchase) writes: >> >u_telly,telly /usr/spool/uucppublic >uumnetor,mnetor /usr/spool/uucppublic >nuucp, /usr/spool/uucppublic >, /usr/spool/uucppublic >, /usr/spool/uucppublic >I'd really prefer to know what's going on, but I don't have the time to >figure it out right now, and this method works for me. If someone else >can post a better explanation or solution, please do. Let's see... In any given USERFILE, there must be one line that has an empty system name, and one that has an empty username. It does not matter where they are in the file relative to lines that have complete system name and username. The Line that has no system name is used by uucico in Slave role, after it has already searched the entire USERFILE and connot find a matching system name. The line that has no username is used by uucp, uux, and uucico in Master role only when it cannot find a matching username. In addition, the line without a system name is used by the uuxqt daemon. All of the above was taken from the NutShell handbook "Managing UUCP and Usenet". I highly recomend the NutShell handbooks, and I don't think I would have uucp running if it weren't for the books (and comp.unix.aux ;-]). Anyway, the book goes on a bit more in detail and gives a little better understanding of what actually happens, and how uucp uses the USERFILE. Like I always say, RTFNM (Read The FILL-IN-YOUR-OWN-WORD Nutshell Manual). -- Marcelo Gallardo marcelo%deadzone@princeton.edu Test and Evaluation Specialist ...!princeton!deadzone!marcelo Princeton University marcelo@sparcwood.princeton.edu Advanced Technologies and Applications (609) 258-5661