Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!sri-spam!ames!ucbcad!ucbvax!decvax!decwrl!pyramid!prls!philabs!micomvax!musocs!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP
Newsgroups: comp.sources.wanted,comp.unix.wizards,comp.unix.questions
Subject: Re: UUCP Port Turnaround
Message-ID: <622@mcgill-vision.UUCP>
Date: Mon, 2-Feb-87 02:34:50 EST
Article-I.D.: mcgill-v.622
Posted: Mon Feb  2 02:34:50 1987
Date-Received: Wed, 4-Feb-87 03:33:32 EST
References: <171@ndmath.UUCP> <4090@nsc.nsc.com>
Organization: McGill University, Montreal
Lines: 27
Keywords: uucp
Xref: watmath comp.sources.wanted:424 comp.unix.wizards:797 comp.unix.questions:891

In article <4090@nsc.nsc.com>, jon@nsc.nsc.com (Jon Ryshpan) writes:
> Does anyone know a simple method to "turn a port around" so as to
> make an outgoing call on a port which is usually used for incoming
> connections?

What we did was to put a special getty on the line, one which just
waits for either (a) input from the port, in which case it execs login,
or (b) a SIGTERM, in which case it releases the port for uucp's use but
does not exit (so init doesn't fork another).  Then the uucp job runs
as root (ok since uucico runs setuid uucp) and sends the getty a
SIGTERM before and SIGKILL after running uucico.  Note that the fake
getty can be very simple since it doesn't need to read a username and
it never needs to take the port back after letting it go (it's killed
and init forks another one).

> How do you handle problems, if any, with the modem?  (We are
> currently using Hayes Smartmodems.)

We use Racal-Vadic modems and they don't cause us any grief with this
scheme.

					der Mouse

USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!mcgill-vision!mouse
     think!mosart!mcgill-vision!mouse
Europe: mcvax!decvax!utcsri!mcgill-vision!mouse
ARPAnet: think!mosart!mcgill-vision!mouse@harvard.harvard.edu