alexis@panix.uucp (Alexis Rosen) (03/11/91)
A few days ago I mentioned some scripts I had written to make life with A/UX's
UUCP more bearable. As I got over a dozen requests, I'm posting both scripts
here.
The first one, uupoll, will call the named system up to a specified number of
times. One key feature is that it will call again if the first connection
fails before it's done. The other feature is that it permits two-way use of
serial lines. In other words, you can use one serial port for both dial-in
and dial-out.
There is another minor bug in A/UX UUCP which will occasionally cause uupoll
to call one extra time. The bug is that UUCP writes a connection failed type
of line into the log file after a successful connection. The giveaway is that
the system it logs as failed will be named something like TM.12345.234, which
is really the name of a temporary UUCP file. (Cute, huh?) If this bug really
bothers you it's simple enough to work around. Changing the "tail -1" to
"tail -2" should do it (though I've never tried it).
Uupoll has one feature specific to my system which can safely be ignored by
most of you. I have a telebit on ttya0, which has the DCD line cut. So that
line doesn't need any of the stty modem stuff to work bidirectionally. I test
for this in my script. You can either ignore this entirely (if you don't have
a ttya0, or don't use it for UUCP), delete the "if [ line != a0 ]" line and
the corresponding "fi", or make use of it if you have a similar setup.
I have also included a second script, "uupoll.cmcl2", which I derived from the
first. Cmcl2 is our main feed, and they have several phone numbers which don't
hunt to each other, so if one number is busy, we don't get a connection. This
script employs a very ugly hack to work around that. I have four different
L.sys files, one for each cmcl2 phone number, and it simply copies each one
onto L.sys in sequence, trying each one. This works well, so I haven't bothered
to change it, but it's an awful and ugly hack. I wrote it one morning about
3AM...
If you don't like the inelegance, or you modify your L.sys frequently, try
something a little different. Put a placeholder in the L.sys where you put
the target system's phone number, and then use sed to rebuild the L.sys just
before you call. You'd need another file containing alternate phone numbers,
and so on, so I haven't bothered to rewrite it. (After all, it does what I
need...)
Note that since I call cmcl2 on my ttya0, I don't do the styy modem stuff.
Most of you will need this, and should just pull it from the uupoll script.
Once you have one or both of these scripts, you'll want them in your
/usr/lib/uucp directory, owned/grouped to uucp, and mode 554 or 550.
Set up an entry in uucp's crontab (_NOT_ root's!) to invoke them as
appropriate. You may also want to add the following lines to the uudemon.day
script, right before the uusub line near the end:
mv Poll-Log.o Poll-Log.oo
mv Poll-Log Poll-Log.o
>Poll-Log
chmod +r Poll-Log
mailx -s "Today's polling information" uucp <Poll-Log.o
I'd really appreciate it if someone would take this and put it someplace
FTPable. If you do, keep the whole message together, and let me know.
---
Alexis Rosen
Owner/Sysadmin, PANIX Public Access Unix, NY
{cmcl2,apple}!panix!alexis
If you can't reach uucp sites: rosen@nyu.edu
---------------------------------UUPOLL------------------------------------
#!/bin/sh
# uupoll for A/UX by Alexis Rosen written 11/7/90
# Modified 3/6/91 by Alexis- cleaned up for release.
# Takes two arguments, a system name and a retry count. If the count isn't
# specified, don't retry.
# Send comments and bug reports to panix!alexis, or rosen@nyu.edu
if [ $# = 0 ] ; then echo uupoll: no system name specified ; exit 1 ; fi
PATH=/usr/lib/uucp:/bin:/usr/bin
cd /usr/lib/uucp
if egrep "^$1" L.sys >/dev/null # look for poll system
then : # found it, so proceed
else echo "uupoll: no system named $1 in /usr/lib/uucp/L.sys" ; exit 2
fi
# Get the tty id for this system. It can be one of two characters.
# This scripts assumes a valid tty designator, and will fail otherwise.
line=`awk '$1=="'$1'" {print substr($3,4,2)}' L.sys`
retry=${2-0} # retry count is second arg, or zero if none
LOGNAME=uucp ; export LOGNAME
TZ=EST5EDT ; export TZ # without this uucico dies in various strange ways.
while : ; do
# kill the system status file- we're smarter than uucp is...
rm -f /usr/spool/uucp/STST.$1
# check to see if we're calling on ttya0. If we are, we don't
# have to worry about a getty. If not, we need to handle the
# getty by doing a stty -modem.
if [ $line != a0 ] ; then
# check to see if the line is in use. If not, use stty to
# turn off 'modem', thereby allowing uucico to grab the line.
# It is critical that there be a trap to turn it back on,
# since otherwise logins on that line will be disabled.
if [ ! -f /usr/spool/uucp/LCK..tty$line ] ; then
trap "stty -n /dev/tty$line modem" 0 1 2 3 15
stty -n /dev/tty$line -modem
fi # if the LCK file exists, uucico won't even try to run.
fi
# invoke uucico and get its process number. Then wait for the
# uucico to exit.
uucico -s$1 -r1 & uuproc=$! ; wait
# undo the stty right away, if we didn't use ttya0. The trap
# will do this for us but this frees the line for logins faster.
stty -n /dev/tty$line modem
# look through the last few lines of LOGFILE for entries from
# our uucico. See if the last line indicates successful
# completion of a conversation.
tail -40 /usr/spool/uucp/LOGFILE | grep "(C,$uuproc" | tail -1 |
grep "OK (conversation complete" >/dev/null
# if we succeeded, break out of this loop
if [ $? = 0 ] ; then break ; fi
# if there's already a uucico talking to this system, don't
# bother looping. This has to go here (after the first uucico)
# so that uucico checks for a stale lock file for us.
if [ -f /usr/spool/uucp/LCK..$1 ] ; then break ; fi
# if we've retried enough, quit
if [ $retry -eq 0 ] ; then
echo "`date '+%a %D %T'`: could not connect with $1 after ${2-0} retries" >>/usr/spool/uucp/Poll-Log ; break
fi
retry=`expr $retry - 1`
sleep 600 # wait a while
done
uulog # make sure any LTMP.$$ files get appended to the LOGFILE
---------------------------------UUPOLL.CMCL2------------------------------
#!/bin/sh
# uupoll.cmcl2- variant on uupoll written specially for cmcl2 1/30/91 by Alexis
PATH=/usr/lib/uucp:/bin:/usr/bin
cd /usr/lib/uucp
LOGNAME=uucp ; export LOGNAME
TZ=EST5EDT ; export TZ
finish=false
for xxx in 1 1 1 1 ; do
for sysfile in L.sys.? ; do
# kill the system status file- we're smarter than uucp is...
rm -f /usr/spool/uucp/STST.cmcl2
# copy appropriate L.sys.? file to L.sys
cp $sysfile L.sys
# invoke uucico and get it's process number. Then wait for the
# uucico to exit.
uucico -scmcl2 -r1 & uuproc=$! ; wait
# look through the last few lines of LOGFILE for entries from
# our uucico. See if the last line indicates successful
# completion of a conversation.
tail -40 /usr/spool/uucp/LOGFILE | grep "(C,$uuproc" | tail -1 |
grep "OK (conversation complete" >/dev/null
# if we succeeded, break out of this loop
if [ $? = 0 ] ; then
echo "`date '+%a %D %T'`: Cmcl2 succeeded with $sysfile" >>/usr/spool/uucp/Poll-Log ; finish=true ; break
fi
# if there's already a uucico talking to this system, don't
# bother looping. This has to go here (after the first uucico)
# so that uucico checks for a stale lock file for us.
if [ -f /usr/spool/uucp/LCK..cmcl2 ] ; then
echo "`date '+%a %D %T'`: already connected to cmcl2" >>/usr/spool/uucp/Poll-Log ; finish=true ; break
fi
sleep 60 # wait a while
done
if [ $finish = true ] ; then break ; fi
sleep 600
done
if [ $finish = false ] ; then
echo "`date '+%a %D %T'`: failed to connect to cmcl2" >>/usr/spool/uucp/Poll-Log
fi
uulog # make sure any LTMP.$$ files get appended to the LOGFILEunger@mitem (Tom Unger) (03/13/91)
In article <1991Mar10.194813.10357@panix.uucp> alexis@panix.uucp (Alexis Rosen) writes: >A few days ago I mentioned some scripts I had written to make life with A/UX's >UUCP more bearable. As I got over a dozen requests, I'm posting both scripts >here. > >The first one, uupoll, will call the named system up to a specified number of >times. One key feature is that it will call again if the first connection I too wrote a uupoll program when setting up uucp. Mine is a bit simpler, all it does is write a dummy control file to the spool directory. Next time uucico is run it will attempt to call any systems that have control files. uucico will retry (every hour by default) until it gets through. I run uucico every 15 minutes and don't mind the backoff and retry strategy that uucico uses. I also have a uugetty that allows both dial in and dial out on the same line. I don't know if it is the best solution but has been working OK for me. ------------------------------------------- #!/bin/sh # # poll # case $# in 0) # poll the defualt list. for i in cdp do touch /usr/spool/uucp/C.${i}CCPOLL done;; *) # poll the command line list. for i in $* do touch /usr/spool/uucp/C.${i}CCPOLL done;; esac
henry@chinet.chi.il.us (Henry C. Schmitt) (03/15/91)
In article <1991Mar12.170918.29890@mitem> unger@mitem (Tom Unger) writes: >I also have a uugetty that allows both dial in and dial out on the same >line. I don't know if it is the best solution but has been working OK >for me. Please point us to a place to get this uugetty. I'm using a program called uutty which is a real hack (gotos hidden in #define macros!!) and would like to find something more maintainable. If there's enough interest or it's small, please condsider posting it. Thanx. -- H3nry C. Schmitt | CompuServe: 72275,1456 (Rarely) | GEnie: H.Schmitt (Occasionally) Royal Inn of Yoruba | UUCP: Henry@chinet.chi.il.us (Best Bet)
alexis@panix.uucp (Alexis Rosen) (03/17/91)
In article <1991Mar12.170918.29890@mitem> unger@mitem (Tom Unger) writes: [ in response to my uupoll script ] >I too wrote a uupoll program when setting up uucp. Mine is a bit >simpler, all it does is write a dummy control file to the spool >directory. Next time uucico is run it will attempt to call any systems >that have control files. uucico will retry (every hour by default) >until it gets through. I run uucico every 15 minutes and don't mind >the backoff and retry strategy that uucico uses. This is OK for systems that don't have a high load. The problem is, with heavily loaded systems, you can get so many SEND/SLAVE MODE failures that if you don't retry for an hour, you may jam the queue for half a day. You can make this workable, though, even in heavy-usage situations. Put a ",10" after the times-to-call field in the L.sys file. But even this has its drawbacks. If the target system is down, or the lines are _really_ bad, you'll wind up calling a gazillion times, possibly running up one hell of a phone bill. You can solve _that_ problem by not calling so often... but then you're back to problem number one, jamming the UUCP queue. In general, I'd say your solution is quite elegant, for a low-load system. I don't think it will work under high-volume conditions. On the other hand, there may not be many A/UX systems with what I consider to be high load conditions... >I also have a uugetty that allows both dial in and dial out on the same >line. I don't know if it is the best solution but has been working OK >for me. I chose to use a script rather than replace A/UX's getty, since the getty now understands UUCP lock files. But it's six of one, half a dozen of the other. --- Alexis Rosen Owner/Sysadmin, PANIX Public Access Unix, NY {cmcl2,apple}!panix!alexis
alexis@panix.uucp (Alexis Rosen) (03/17/91)
henry@chinet.chi.il.us (Henry C. Schmitt) writes: >In article <1991Mar12.170918.29890@mitem> unger@mitem (Tom Unger) writes: >>I also have a uugetty that allows both dial in and dial out on the same >>line. I don't know if it is the best solution but has been working OK >>for me. > >Please point us to a place to get this uugetty. I'm using a program >called uutty which is a real hack (gotos hidden in #define macros!!) >and would like to find something more maintainable. > >If there's enough interest or it's small, please condsider posting >it. While this is a matter of personal preference, I wouldn't replace the getty. If you're resistant to using the uupoll I posted, you can simply alter Apple's uudemon a bit. Use the code in uupoll to switch the line before uucico'ing, and switch it back later. As for why I prefer not messing with getty- the side effects are greater, that's all. --- Alexis Rosen Owner/Sysadmin, PANIX Public Access Unix, NY {cmcl2,apple}!panix!alexis
rmtodd@servalan.uucp (Richard Todd) (03/18/91)
alexis@panix.uucp (Alexis Rosen) writes: >While this is a matter of personal preference, I wouldn't replace the getty. >If you're resistant to using the uupoll I posted, you can simply alter Apple's >uudemon a bit. Use the code in uupoll to switch the line before uucico'ing, >and switch it back later. >As for why I prefer not messing with getty- the side effects are greater, >that's all. Ah, but the program we're all talking about (uugetty, ringback, tgetty, whatever you call it) doesn't replace the getty; it just waits for an incoming call and *then* exec's the real getty. It also does other nice things, like resets the modem every time it starts up with a user-defined sequence, and optionally keeping nice logs of just what it's doing. Besides, I never did get the alleged "new improved" getty to work at all on dialins without a "front-end" like tgetty active. -- Richard Todd rmtodd@uokmax.ecn.uoknor.edu rmtodd@chinet.chi.il.us rmtodd@servalan.uucp "Try looking in the Yellow Pages under 'Psychotics'." -- Michael Santana
paul@taniwha.UUCP (Paul Campbell) (03/18/91)
In article <1991Mar12.170918.29890@mitem> unger@mitem (Tom Unger) writes: > >In article <1991Mar10.194813.10357@panix.uucp> alexis@panix.uucp (Alexis Rosen) writes: >>The first one, uupoll, will call the named system up to a specified number of >I too wrote a uupoll program when setting up uucp. Mine is a bit Yeah so did I - compile this, install it as /usr/bin/uupoll and make it setuid uucp (if you want anyone to be able to run it) Paul - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - #include <stdio.h> main(argc, argv) char ** argv; { char buff[100]; int id, i; if (argc == 2) { sprintf(buff, "-s%s", argv[1]); if ((id = fork()) == 0) { for (i = 0; i < _NFILE; i++) close(i); execl("/usr/lib/uucp/uucico", "uucico", "-r1", buff, NULL); } else if (id > 0) { exit(0); } } fprintf(stderr, "%s: invalid parameter\n", argv[0]); exit(2); } - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- Paul Campbell UUCP: ..!mtxinu!taniwha!paul AppleLink: CAMPBELL.P "But don't we all deserve. More than a kinder and gentler fuck" - Two Nice Girls, "For the Inauguration"
mann@intacc.uucp (Jeff Mann) (03/27/91)
In article <1991Mar10.194813.10357@panix.uucp> alexis@panix.uucp (Alexis Rosen) writes: >A few days ago I mentioned some scripts I had written to make life with A/UX's >UUCP more bearable. As I got over a dozen requests, I'm posting both scripts >here. > >The first one, uupoll, will call the named system up to a specified number of >times. One key feature is that it will call again if the first connection >fails before it's done. The other feature is that it permits two-way use of >serial lines. In other words, you can use one serial port for both dial-in >and dial-out. [excerpt from the uupoll script:] > # check to see if we're calling on ttya0. If we are, we don't > # have to worry about a getty. If not, we need to handle the > # getty by doing a stty -modem. > if [ $line != a0 ] ; then > # check to see if the line is in use. If not, use stty to > # turn off 'modem', thereby allowing uucico to grab the line. > # It is critical that there be a trap to turn it back on, > # since otherwise logins on that line will be disabled. > if [ ! -f /usr/spool/uucp/LCK..tty$line ] ; then > trap "stty -n /dev/tty$line modem" 0 1 2 3 15 > stty -n /dev/tty$line -modem > fi # if the LCK file exists, uucico won't even try to run. > fi > # invoke uucico and get its process number. Then wait for the > # uucico to exit. > uucico -s$1 -r1 & uuproc=$! ; wait > # undo the stty right away, if we didn't use ttya0. The trap > # will do this for us but this frees the line for logins faster. > stty -n /dev/tty$line modem I don't know if you've done something else to get around this, or what, but on my system uucico will die if there is a getty on the line, regardless of whether you do an stty -modem. In other words, your > # have to worry about a getty. If not, we need to handle the > # getty by doing a stty -modem. doesn't work for me. I have had to use the old method of specifiying run levels which getty can exist in, and using init to turn the getty on or off. Am I missing something? Anyone else with the same problem? I'm planning to post my code which handles this, but part of it runs suid root to handle the init, and if there's another way around it... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Jeff Mann Inter/Access Artists' Computer Centre, Toronto [416] 535-8601 | | intacc!mann@cs.toronto.edu Matrix Artists' BBS: [416] 535-7598 2400 8N1 | | ...uunet!mnetor!intacc!mann mann@intacc.uucp [416] 535-1443 Telebit 8N1 | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
dumais@mauxci.uucp (Paul Dumais) (03/28/91)
In article <1991Mar27.014105.5418@intacc.uucp> mann@intacc.uucp (Jeff Mann) writes: >In article <1991Mar10.194813.10357@panix.uucp> alexis@panix.uucp (Alexis Rosen) writes: >>A few days ago I mentioned some scripts I had written to make life with A/UX's >>UUCP more bearable. As I got over a dozen requests, I'm posting both scripts >>here. [stuff deleted] >I don't know if you've done something else to get around this, or what, >but on my system uucico will die if there is a getty on the line, >regardless of whether you do an stty -modem. In other words, your >> # have to worry about a getty. If not, we need to handle the >> # getty by doing a stty -modem. >doesn't work for me. I have had to use the old method of specifiying >run levels which getty can exist in, and using init to turn the getty >on or off. Am I missing something? Anyone else with the same problem? >I'm planning to post my code which handles this, but part of it runs >suid root to handle the init, and if there's another way around it... > I admit that I'm not pleased with the UUCP delivered with A/UX but it has been fixed quite a bit in A/UX 2.0.1. Thank you Vicki et al. And..... I have UUCP working just fine for both dial-in and dial-out on mauxci.UUCP. There is NO REASON to play with run levels. Alexis <alexis@panix.uucp> has written some code to enhance the administration of UUCP but he is not mucking around with gettys or run levels. Here are my settings on mauxci: (Macintosh IIfx, 8MbRAM, 500Mb, A/UX 2.0.1, TrailBlazer Plus) -- GETTYDEFS -- pd_2400# B2400 # B2400 HUPCL SANE2 TAB3 # ~MODEM ~DTR ~FLOW #login: #pd_1200 [stuff deleted] BL_19200# B19200 HUPCL OPOST ONLCR TAB3 BRKINT IGNPAR ISTRIP IXON IXANY ECHO ECHOE ECHOK ICANON ISIG CS8 CREAD # B19200 HUPCL OPOST ONLCR TAB3 BRKINT IGNPAR ISTRIP IXON IXANY ECHO ECHOE ECHOK ICANON ISIG CS8 CREAD # FLOW ~DTR ~MODEM #Apple Canada, Inc. (mauxci) \r\n\nlogin: #BL_19200 Note: I only use the 19200 line for my TrailBlazer so it points back to itself. The modem does the baud adjusting. I am using Hardware flow control. -- INITTAB -- [stuff deleted] co::respawn:/etc/loginrc # System Console Window 00:2:off:/etc/getty tty0 pd_2400 # Modem Pool (Out only) 01:2:respawn:/etc/getty tty1 BL_19200 # TrailBlazer Plus (In/Out) -- CABLE -- Here are the pinouts for Modem -> Mac cable that supports HW Flow control: DB-25 DIN-8 4--+------------1 | 20-+ 5---------------2 2---------------3 7------------+--4 | +--8 3---------------5 n/c ---6 n/c ---7 ============================================================================= -- . . . . . . . . . . . . Paul E. Dumais A/UX Specialist Apple Canada, Inc. . . Internet: dumais@apple.com 7495 Birchmount Rd. .
alexis@panix.uucp (Alexis Rosen) (03/28/91)
mann@intacc.uucp (Jeff Mann) writes: > [I, Alexis Rosen, wrote:] >>A few days ago I mentioned some scripts I had written to make life with A/UX's >>UUCP more bearable. As I got over a dozen requests, I'm posting both scripts >>here. > [large excert from the uupoll script was here] > >I don't know if you've done something else to get around this, or what, >but on my system uucico will die if there is a getty on the line, >regardless of whether you do an stty -modem. In other words, your >> # have to worry about a getty. If not, we need to handle the >> # getty by doing a stty -modem. >doesn't work for me. I have had to use the old method of specifiying >run levels which getty can exist in, and using init to turn the getty >on or off. Am I missing something? Anyone else with the same problem? >I'm planning to post my code which handles this, but part of it runs >suid root to handle the init, and if there's another way around it... You must be running either A/UX 1.1.x, or be running A/UX 2.x with getty taken from 1.1, or... well, I don't know what. But I do know that I'm doing nothing unusual. I'm running with plain-vanilla A/UX and getty. If you look at the man page for getty, you'll see that this behavior is documented. I discovered this one day when I was playing with 2.0.0b3. It was one of my favorite features in 2.0.0. Actually, there is one faint possibility. If Apple's built-in serial port drivers are broken, maybe that could explain what you're seeing. I dial out on CommCard serial ports, although they have always behaved identically to the built-ins, as far as I know. Certainly, the behavior is _supposed_ to be identical. Has anyone else tried this yet? --- Alexis Rosen Owner/Sysadmin, PANIX Public Access Unix, NY {cmcl2,apple}!panix!alexis
mann@intacc.uucp (Jeff Mann) (04/02/91)
In article <1991Mar28.003019.1764@mauxci.uucp> dumais@mauxci.UUCP (Paul Dumais) writes: >In article <1991Mar27.014105.5418@intacc.uucp> mann@intacc.uucp (Jeff Mann) writes: >>I don't know if you've done something else to get around this, or what, >>but on my system uucico will die if there is a getty on the line, >>regardless of whether you do an stty -modem. In other words, your >>> # have to worry about a getty. If not, we need to handle the >>> # getty by doing a stty -modem. >>doesn't work for me. I have had to use the old method of specifiying >>run levels which getty can exist in, and using init to turn the getty >>on or off. Am I missing something? Anyone else with the same problem? >>I'm planning to post my code which handles this, but part of it runs >>suid root to handle the init, and if there's another way around it... >> > >I have UUCP working just fine for both dial-in and dial-out on mauxci.UUCP. >There is NO REASON to play with run levels. Alexis <alexis@panix.uucp> has >written some code to enhance the administration of UUCP but he is not mucking >around with gettys or run levels. Just because it works for you, doesn't mean it works for me! :-) The fact is that getty and uucico don't co-exist peacefully on my system, even using the gettydefs that you posted (except for the flow control, which creates a SERIOUS SECURITY PROBLEM - see below). This is as far as I've got debugging uucico/getty: uucico opens and writes to the port ok. However, if anything is received from the modem before connecting (eg. the RRING message), the line is immediately lost. (Paul, this is different from what I told you in e-mail, if you got my e-mail...) If I turn off echo and result codes from the modem, the connection is made by uucico, but then my own /etc/issue and login prompt is written to the port by getty. This really screws things up as far as expect/send sequences go! However, I then receive a message from getty on the console that the line is locked by the uucico process, and getty does not respawn. Looks like getty is sending out /etc/issue and the login prompt BEFORE checking whether the line is locked. Same behaviour with cu. Admittedly, I could re-write all my expect-send sequences to take this into account, but that's just too ugly for me, so I have arranged for getty to be shut off before calling out. Here is the debugging output of uucico with getty turned on: # stty -n /dev/tty0 -modem # /usr/lib/uucp/uucico -r1 -x4 -sweb finds called getto called call: no. tty0 for sys web fixline - speed= 11 login called wanted "" got that wanted help): got ? wanted help): ______System name: web______ userid: (? for help):got that wanted ssword: ame: web______ userid: (? for help): ___-=-=-=-=-=-=-=-___=System name: web______ userid: (? for help): ___System name: web______ userid: (? for help): -=-=-=-=-=-=-=-=-=-=-=-____= Welcome to Matrix! If you have any =____- problems or questions, call the -____= Inter/Access office at 535-got ? exit code 0 # Apr 1 20:29:36 getty[195]: line tty0 locked by pid 192 Note my system's (intacc's) banner and login prompt (stuff about Matrix and Inter/Access) mixed in with the one from the remote system (web). I am able to call web with no problem when getty is turned off. This is the expected behaviour on many older uucp systems (getty must be turned off before calling out), and is also mentioned in some places in the A/UX documentation. Other users (Richard Todd?) have reported being unable to call out with getty active. > >Here are my settings on mauxci: >(Macintosh IIfx, 8MbRAM, 500Mb, A/UX 2.0.1, TrailBlazer Plus) > Mine: Macintosh IIci, 8mbram, 650mb, A/UX 2.0, Trailblazer t2500 Maybe the ci acts differently (unlikely, I think). Maybe you have a different version of getty. Mine is: -rwx------ 1 bin bin 26988 Apr 10 1990 /etc/getty Maybe you are using a serial port board in the NuBus which fixes the problem. I am using the built-in modem port. Maybe you have echo and result codes turned off when calling out, and haven't noticed that your /etc/issue and login prompt are being sent to the port. Maybe it has something to do with the phase of the moon :-) Now, about that flow control - I have already e-mailed Paul about this, but I wanted to make it known to the net: >-- >GETTYDEFS >-- >pd_2400# B2400 # B2400 HUPCL SANE2 TAB3 # ~MODEM ~DTR ~FLOW #login: #pd_1200 > >[stuff deleted] > >BL_19200# B19200 HUPCL OPOST ONLCR TAB3 BRKINT IGNPAR ISTRIP IXON IXANY ECHO ECHOE ECHOK ICANON ISIG CS8 CREAD # B19200 HUPCL OPOST ONLCR TAB3 BRKINT IGNPAR ISTRIP IXON IXANY ECHO ECHOE ECHOK ICANON ISIG CS8 CREAD # FLOW ~DTR ~MODEM #Apple Canada, Inc. (mauxci) \r\n\nlogin: #BL_19200 > >Note: I only use the 19200 line for my TrailBlazer so it points back to itself. >The modem does the baud adjusting. I am using Hardware flow control. > This is a SERIOUS security problem. In order to get the hardware flow control working, you are disabling modem control. Modem control is absolutely essential on an incoming dial-up line. The system MUST have access to the carrier detect line from the modem (which is clipped on Paul's cable diagram). Otherwise, it will be unable to detect when someone has hung up without properly logging out. Humans, at least, do this all the time. That means that the next caller will get the previous caller's shell, including all priveleges!! This setup can also cause several other less serious but potentially nasty problems. DON'T DO THIS!!! Summary: 1. A/UX (at least with built-in serial ports) doesn't support modem control and hardware flow control at the same time. 2. You MUST have modem control on an incoming line. 3. Therefore, you CAN'T use hardware flow control. Period. 4. Therefore, if you are using a Telebit, you can't use auto baud rate adjusting on incoming uucp calls. You must set S50=0 and use the normal method of sending breaks to cycle getty until the proper speed is attained. >. Paul E. Dumais A/UX Specialist Apple Canada, Inc. . >. Internet: dumais@apple.com 7495 Birchmount Rd. . =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Jeff Mann Inter/Access Artists' Computer Centre, Toronto [416] 535-8601 | | intacc!mann@cs.toronto.edu Matrix Artists' BBS: [416] 535-7598 2400 8N1 | | ...uunet!mnetor!intacc!mann mann@intacc.uucp [416] 535-1443 Telebit 8N1 | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
gandrews@netcom.COM (Greg Andrews) (04/04/91)
In article <1991Apr2.044623.299@intacc.uucp> mann@intacc.uucp (Jeff Mann) writes: > >4. Therefore, if you are using a Telebit, you can't use auto baud rate > adjusting on incoming uucp calls. You must set S50=0 and use the normal > method of sending breaks to cycle getty until the proper speed is > attained. > That should be S66=0 for unlocking the RS232 speed. (not S50) -- .------------------------------------------------------------------------. | Greg Andrews | UUCP: {apple,amdahl,claris}!netcom!gandrews | | | Internet: gandrews@netcom.COM | `------------------------------------------------------------------------'
urlichs@smurf.sub.org (Matthias Urlichs) (04/05/91)
In comp.unix.aux, article <1991Apr2.044623.299@intacc.uucp>,
mann@intacc.uucp (Jeff Mann) writes:
<
< 1. A/UX (at least with built-in serial ports) doesn't support modem
< control and hardware flow control at the same time.
< 2. You MUST have modem control on an incoming line.
< 3. Therefore, you CAN'T use hardware flow control. Period.
<
Actually, you could get by with incoming modem control only and rely on
special character sequences like +++ ATH to hang up the modem. The serial
ports even have two input lines. But no, the second isn't supported by A/UX.
:-( Therefore you're essentially correct.
< 4. Therefore, if you are using a Telebit, you can't use auto baud rate
< adjusting on incoming uucp calls. You must set S50=0 and use the normal
< method of sending breaks to cycle getty until the proper speed is
< attained.
<
??? Why?
UUCP defaults to using the g protocol. That protocol defaults to requiring
less than 256 unacknowledged bytes; both the modem and the A/UX buffers are
quite capable of storing that many unprocessed characters, therefore there
can't be any soft overruns, therefore no flow control is necessary.
My T2500 here has its interface speed locked to 19200 baud and UUCP-g works
perfectly with all callers (PEP,V.32,V.22bis). No problem.
Now if you want to use different UUCP protocols, you need hardware flow
control. Locking the speed won't really help -- what if your machine is busy
swapping UUCP in and out because you're compiling some big program?
--
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49-721-621127(0700-2330) \o)/unger@mitem.uucp (Tom Unger) (04/06/91)
In article <1991Mar27.014105.5418@intacc.uucp> mann@intacc.uucp (Jeff Mann) writes: >I don't know if you've done something else to get around this, or what, >but on my system uucico will die if there is a getty on the line, >regardless of whether you do an stty -modem. In other words, your >> # have to worry about a getty. If not, we need to handle the >> # getty by doing a stty -modem. >doesn't work for me. I have had to use the old method of specifiying >run levels which getty can exist in, and using init to turn the getty >on or off. Am I missing something? Anyone else with the same problem? >I'm planning to post my code which handles this, but part of it runs >suid root to handle the init, and if there's another way around it... I have a program called uugetty that lets one line be used for incomming and outgoing modem calls. uugetty does the following: 1) initializes modem 2) Listens for incomming calls on modem or other traffic on the port. 3) If a call arrives it execs the standard getty to log the user in. 4) If there is other traffic uugetty "gives up" the line until the outbound call is done. (it knows it is done when the lock file goes away). This all works very well for me. I would be glad to send it to anyone who requests it. I would post it here but the soure code is 14Kbytes. Tom Unger. MITEM
urlichs@smurf.sub.org (Matthias Urlichs) (04/07/91)
In comp.unix.aux, article <1991Apr6.052123.11234@mitem.uucp>,
unger@mitem.uucp (Tom Unger) writes:
<
< I have a program called uugetty that lets one line be used for incomming
< and outgoing modem calls. uugetty does the following:
<
< 1) initializes modem
< 2) Listens for incomming calls on modem or other traffic on
< the port.
< 3) If a call arrives it execs the standard getty to log the user in.
< 4) If there is other traffic uugetty "gives up" the line until
< the outbound call is done. (it knows it is done when the lock
< file goes away).
<
The standard getty should not initialise the modem. Why? The modem is reset
by DTR going down, and it won't accept calls until DTR comes up again.
(Disclaimer: Any reasonably configured modem ...)
It also shouldn't look at traffic. If the line can be opened, either there was
an incoming call or there's a lock file, i.e. an outgoing call. If the
latter, getty hangs until the lock file goes away and then dies, indirectly
reexecuting itself. (Cleaning up after opening a line that way is a lot of
hassle and definitely not worth the effort.)
There may be a problem because some uucico's first try to dial the phone and
then create a lock file, thus generating a race condition. I don't know if
the A/UX uucico has that bug.
It also seems that the A/UX getty first writes its login message out and
then looks for the lock, instead of the other way round. My uucico therefore
kills the current getty, and /etc/init spawns a small program that waits on
the lock before exec'ing /etc/getty.
NB: The above applies to A/UX 2.0. I haven't checked what, if anything, was
changed in 2.0.1 because the current setup works.
I'll package the UUCP binaries I have into something resembling usablility
and make them available for FTP. Sometime next week.
--
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49-721-621127(0700-2330) \o)/mann@intacc.uucp (Jeff Mann) (04/11/91)
In article <D7Q_!R@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: >In comp.unix.aux, article <1991Apr2.044623.299@intacc.uucp>, > mann@intacc.uucp (Jeff Mann) writes: >< 4. Therefore, if you are using a Telebit, you can't use auto baud rate >< adjusting on incoming uucp calls. >< >??? Why? > >UUCP defaults to using the g protocol. That protocol defaults to requiring >less than 256 unacknowledged bytes; both the modem and the A/UX buffers are >quite capable of storing that many unprocessed characters, therefore there >can't be any soft overruns, therefore no flow control is necessary. Ok, right. We have remote users logging in at 1200 baud for shell sessions, which needs the flow control (doesn't it?), so I was confused - if you are only taking uucp calls, then you can use the auto baud adjusting. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Jeff Mann Inter/Access Artists' Computer Centre, Toronto [416] 535-8601 | | intacc!mann@cs.toronto.edu Matrix Artists' BBS: [416] 535-7598 2400 8N1 | | ...uunet!mnetor!intacc!mann mann@intacc.uucp [416] 535-1443 Telebit 8N1 | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-