UUCP on my 3b1
Mark H. Weber
mhw at lock60.UUCP
Fri Sep 15 09:48:59 AEST 1989
I got my 3b1 cheap, but with *no manuals*, so I've had to work things
out for myself, with hints from various net.persons (thanks again).
I do have some experience with various Unix systems, and even hacked
HDB onto a Charles Rivers UNOS system once, so I wasn't totally clueless.
Here is the way my current configuration evolved. I hope that it will
help other people get their systems configured. There may be other ways
(and better ones) to do this, but this is what works for me.
My machine is minimally configured, with only the one serial port and
the built-in modem. I wanted to use the serial port for a second terminal
and printer, so this meant that I needed to use the built-in modem for both
incoming (uucp and remote logins) and outgoing (uucp and cu) applications.
I have a second dedicated phone line into my house, so I don't use phtoggle
and use /dev/ph1 exclusively. I enabled a getty on the modem port, and
set up my uucp links having the other systems poll me. This worked, but
I really wanted outgoing uucp.
The first thing I did was to replace uucico with a shell script that would
"reverse" the line befor starting uucico. This worked fine from uutry, but
failed from uusched. After I found out that you can't exec() a shell
script in SYS V, I wrote a short C program to execute the script for me:
> #include <stdio.h>
> #include <errno.h>
>
> main(argc,argv)
> int argc;
> char *argv[];
> {
> char argstring[1000];
> int i;
>
> /* DEBUG */
> /* FILE *f1; */
> /* f1 = fopen("/tmp/uucicoprog.out","w"); */
>
> putenv ("SHELL=/bin/sh");
> strcpy(argstring,"/usr/lib/uucp/uucico.sh");
>
>
> for (i = 1; i < argc; i++)
> {
> strcat(argstring, " ");
> strcat(argstring, argv[i]);
> }
>
> fputs(argstring, f1);
> i=system(argstring);
>
> /* DEBUG */
> /* fprintf (f1, "\nsystem: return %d error %d\n", i, errno); */
>
> }
>
>
Not beautiful, but workable. Here's the original shell script:
> getoff.sh ph1
> /usr/lib/uucp/uucico.real $@
> geton.sh ph1
Where uucico.real is the original uucico, and my C program from above is
installed as uucico. So things were fine, both incoming and outgoing uucp
worked OK. Then one day when I was logged in remotely, the uusched kicked
off uucico. My login session was TRASHED. So I added a test for anyone logged
in via the modem port:
> who | grep ph1 > /tmp/uucico.test
> if test -s /tmp/uucico.test
> then exit
> fi
> getoff.sh ph1
> /usr/lib/uucp/uucico.real $@
> geton.sh ph1
Nice idea, worked fine for outgoing uucp, but it broke my incoming uucp,
because uucico would fail to start when it saw anybody (even the calling system)
logged in on /dev/ph1. So I changed my /etc/passwd file to execute the real
uucico rather than my C program:
> Ujoe:haLs2qen/E0R6:5:6:uucp:/usr/spool/uucppublic:/usr/lib/uucp/uucico.real
This caused all kinds of weird errors. Does uucico check to see if argv[0] is
"uucico"? So I tweaked this by moving the real uucico to a separate directory,
(/usr/lib/uucplib) and made the appropriate changes in my shell script and
passwd file. So everything was OK once again (incoming/outgoing uucp and
remote logins).
Not being content with this, I decided to add cu to the mix. It worked fine,
until the day that uusched tried to kick off uucico while I was running cu
(I had been running cu for more than 1 hour). My session to the remote
computer was TRASHED. So I added one more test:
> if test -f /usr/spool/uucp/LCK..ph1
> then exit
> fi
> who | grep ph1 > /tmp/uucico.test
> if test -s /tmp/uucico.test
> then exit
> fi
> getoff.sh ph1
> /usr/lib/uucplib/uucico $@
> geton.sh ph1
This test takes care of the problem where uucico doesn't honor lock files
that are more than one hour old. This may not be the best solution, as you
will need to manually delete the lock file if your uucico or cu crashes.
Maybe I'll come up with some more intelligent way of deciding whether to
honor the lock file or not. But for the moment, this works for me.
Mark
--
Mark H. Weber ( mhw at Lock60.LS.Com or mhw%lock60 at GVL.Unisys.COM or
uunet!lgnp1!lock60!mhw or gatech!psuvax1!burdvax!gvlv2!lock60!mhw )
More information about the Unix-pc.uucp
mailing list