frank@rsoft.UUCP (Frank I. Reiter) (12/12/88)
SCO Xenix 2.2.x allows cu, uucico etc, to call out on a line enabled for
dialin access by running ungetty before and after the outgoing call.
We run an 8 line bulletin board service on !rsoft and use an init/getty like
procedure to answer incomming calls. I would like to modify our code so that
we can use these same 8 lines for outgoing calls when they are not in use.
It would not be difficult to write our own version of ungetty to work with
our own version of init, but for the sake of compatibility etc. it would be
much nicer if we could have the standard unix communications commands able
to suspend and restart our getty-like processes.
Can anybody tell me how ungetty interacts with getty or point me at a good
source of information?
--
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
Frank I. Reiter \ / UUCP: {uunet,ubc-cs}!van-bc!rsoft!frank
Langley, British Columbia / \ BBS: Mind Link @ (604)533-2312
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*sandy@turnkey.TCC.COM (Sanford 'Sandy' Zelkovitz) (12/12/88)
In article <6@rsoft.UUCP>, frank@rsoft.UUCP (Frank I. Reiter) writes: > SCO Xenix 2.2.x allows cu, uucico etc, to call out on a line enabled for > dialin access by running ungetty before and after the outgoing call. > > We run an 8 line bulletin board service on !rsoft and use an init/getty like > procedure to answer incomming calls. I would like to modify our code so that > we can use these same 8 lines for outgoing calls when they are not in use. > > It would not be difficult to write our own version of ungetty to work with > our own version of init, but for the sake of compatibility etc. it would be > much nicer if we could have the standard unix communications commands able > to suspend and restart our getty-like processes. > > Can anybody tell me how ungetty interacts with getty or point me at a good > source of information? > > -- > *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* > Frank I. Reiter \ / UUCP: {uunet,ubc-cs}!van-bc!rsoft!frank > Langley, British Columbia / \ BBS: Mind Link @ (604)533-2312 > *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* Ungetty basically uses SIGUSR1 and SIGUSR2 to communicate with getty. What happens is that when ungetty is called, it sends a SIGUSR1 to getty <kill -16> and then the following steps are performed: 1) getty closes 0, 1, and 2 2) getty does an fclose on stdin, stderr, and stdout 3) getty changes the appropriate entry in utmp 4) getty goes to sleep When ungetty is called again to awaken getty by using SIGUSR2, getty simply terminates which causes init to spawn a new getty. In my version of getty, I also update wtmp in addition to utmp so that I have a record of outgoing calls. This addition causes absolutely no problems in the operation and really should have been included by SCO. The following code is what I used: int ungetty_call() { register in ownpid; register struct utmp *u; extern struct utmp *getutent(), *pututline(); register FILE *fp; if(ungetty_flag) return; /* You want to disallow ungetty calls when getty is in transition between the user entering his name and login being execed */ fclose(stdin); fclose(stdout); fclose(stderr); close(1); close(2); close(3); delock(Line); /* Look in utmp file for our own entry and change it to LOGIN */ ownpid = getpid(); while ((u=getutent()) != NULL ) { if( u->ut_type == LOGIN_PROCESS && u->ut_pid == ownpid) { strncpy(u->ut_line, Line, sizeof(u->ut_line)); strncpy(u-ut_user,"DIALOUT", sizeof(u->ut_user)); u->ut_type = USER_PROCESS; pututline(u); break; } } if( u!= NULL && (fp=fopen(WTMP_FILE, "r+")) != NULL) { fseek(fp,0L, 2); fwrite(u, sizeof(*u), 1, fp); fclose(fp); } endutent(); /* pause until ungetty says that it is ok */ (void)pause; exit(0); } ------------------------- Additions required for uugetty_call() ------------- Before your main(), add the following code: int ungetty_flag; char Line[20]; Somewhere in your code, do a strcpy of the line name to Line. The first exectuable instruction in your main, add the following code: if(signal(SIGUSR1, ungetty_call) == (int(*)())-1) { printout and error message exit(1); } I hope that this helps!!!! Sanford <sandy> Zelkovitz XBBS 714-898-8634 -- Sanford <sandy> Zelkovitz XBBS 714-898-8634 UUCP: ....att!hermix!alphacm!sandy ....trwrb!ucla-an!alphacm!sandy ....uunet!turnkey!alphacm!sandy ....ucbvax!ucivax!icnvax!alphacm!sandy DATA: 714-898-8634 VOICE: 714-894-7898
chip@vector.UUCP (Chip Rosenthal) (12/13/88)
In article <6@rsoft.UUCP> frank@rsoft.UUCP (Frank I. Reiter) writes: >Can anybody tell me how ungetty interacts with getty or point me at a good >source of information? As far as I know, the interface is undocumented. But, I believe signals SIGUSR1 and SIGUSR2 are used to communicate between /usr/lib/uucp/ungetty and /etc/getty. Reading between the lines, when you call ungetty with a tty device, it looks in /etc/utmp for the PID of the getty on that line, and then does a kill() to signal the getty to either suspend or resume. Note that ungetty is a setuid program, which is required for the kill() to work. -- Chip Rosenthal chip@vector.UUCP | Choke me in the shallow water Dallas Semiconductor 214-450-5337 | before I get too deep.
frank@rsoft.UUCP (Frank I. Reiter) (12/15/88)
Thanks to those who replied to my ungetty question. Using Sandy's example I
was able to modify our getty equivalents to respond to ungetty in the same way
that getty does. Along the way I discovered a little more that will be useful
to anyone else who tries to do this: It is necessary that your getty-like
program enter it's name in utmp as LOGIN and equally necessary that it change it
to DIALOUT when signaled by ungetty.
While poking around I discovered that getty calls itself LOGIN to begin with
but can change this to LOGIN1 or LOGIN2. I think LOGIN1 indicates that a login
is in progress and LOGIN2 indicates an unsuccessful attemp, but I haven't
tested that (yet). Does anyone already know?
Thanks again for the speedy replies!
--
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
Frank I. Reiter \ / UUCP: {uunet,ubc-cs}!van-bc!rsoft!frank
Langley, British Columbia / \ BBS: Mind Link @ (604)533-2312
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*root@chief.UUCP (Lance Ellinghouse) (12/16/88)
In article <660@vector.UUCP>, chip@vector.UUCP (Chip Rosenthal) writes: > In article <6@rsoft.UUCP> frank@rsoft.UUCP (Frank I. Reiter) writes: > >Can anybody tell me how ungetty interacts with getty or point me at a good > >source of information? > > As far as I know, the interface is undocumented. But, I believe signals > SIGUSR1 and SIGUSR2 are used to communicate between /usr/lib/uucp/ungetty > and /etc/getty. Reading between the lines, when you call ungetty with a > tty device, it looks in /etc/utmp for the PID of the getty on that line, > and then does a kill() to signal the getty to either suspend or resume. > Note that ungetty is a setuid program, which is required for the kill() > to work. > -- > Chip Rosenthal chip@vector.UUCP | Choke me in the shallow water > Dallas Semiconductor 214-450-5337 | before I get too deep. ungetty signals getty with a SIGUSR1 to halt the getty. The getty then closes all it's files so that they will not interfere with any other program that wants to use the line. It then does a pause(), and this suspends the activity untill it gets another signal. when you want to use the line again, you call ungetty with a -r argument. ungetty then sends a SIGUSR1 again, thus waking up getty. It then ends and init spawns another getty. This is what I could figure out by playing around a little. if you want to suspend getty for any reason, all you have to do it send a SIGUSR1 to it and it will stop. Any program can do this. Just MAKE sure you send it another SIGUSR1, so that it can startup again. Otherwise you will NOT be able to spawn a new getty on that line! -- Lance Ellinghouse Chief Numismatics, Inc UUCP: ...!{hermix|srhqla|ucla-an|alphacm}!chief!lance ARPA: ucla-an!hermix!chief!lance@ee.UCLA.EDU