Very Computer

[I think this is a Linux rather than a UUCP question. :-)]

I have been "playing" the UUCP capability of LInux SLS 1.03 for the
past few days (and nights. :-)) I used /dev/modem which is softlinked
to /dev/cua1 (COM 2) with uugetty -r set for /dev/modem in
/etc/inittab.  Also I used Any in the relevent entries in the
/usr/lib/uucp/Systems file (just to test things out).

Here are several observations:

1) When SLS 1.03 is first installed, the system talks to the modem
   (but no dialing out) frequently and then after a while (like an hour
   or more), it leaves the modem alone.
2) Having done the necessary modifications to Devices, Dialers, and
   Systems in the /usr/lib/uucp directory and the paths and config
   files in the smail directory (don't remember the exact path
   anymore), I could test my UUCP link using the command:
       /usr/lib/uucico [-f] -x2 -s<hostname>
   Without the -x2 (or higher e.g. x3, x4) flag, Linux would not
   initiate a call otherwise uucico dials out with and without the -f
   or the -r flags set.
3) I use crontab to schedule dialouts with the -f and -x2 flag on (I
   want to make sure that the system dials out).  Everything works
   fine for a day or so and then
       /usr/lib/uucico -f -r1 -x2 -s<hostname>
   would do nothing except create the LCK..* and TMP...... files
   in /usr/spool/uucp.  The audit.local and other logs in the
   /usr/spool/uucp don't seem to get updated when this happens (i.e.,
   when uucico doesn't initiate a dialout).  Usually the logs will say
   something or explain why the dialout didn't occur and a couple of
   modem lights will flicker for a few seconds but in this case nothing.

Questions:
a) How tightly "hardcoded" is the uucp neighbor "quick" to SLS 1.03?
b) How fast does the C.* and D.* files get created in the
   /usr/spool/uucp/hostname directory?  I notice that sometimes those
   files (email addressed to hostname) get created as soon as I "send"
   them out of the mail program (Emacs rmail mode) but then there are times
   I notice that the files don't get created that quickly.
c) I haven't left my system alone long enough (e.g. for > 24 hours)
   to see if the UUCP link will "wake" up again.  Is the uucico's behavior
   described in 3 above expected?

Willie

part of it is...

Quote:>I have been "playing" the UUCP capability of LInux SLS 1.03 for the
>past few days (and nights. :-)) I used /dev/modem which is softlinked
>to /dev/cua1 (COM 2) with uugetty -r set for /dev/modem in
>/etc/inittab.  Also I used Any in the relevent entries in the
>/usr/lib/uucp/Systems file (just to test things out).
>Here are several observations:
>1) When SLS 1.03 is first installed, the system talks to the modem
>   (but no dialing out) frequently and then after a while (like an hour
>   or more), it leaves the modem alone.

That's not the case with SLS1.02 and uucp didn't change in SLS 1.03.
I'd suggest you turn uugetty off in inittab until you get outgoing calling
working, then add uugetty back.  If it breaks then, you have a uugetty
problem.

Quote:>2) Having done the necessary modifications to Devices, Dialers, and
>   Systems in the /usr/lib/uucp directory and the paths and config
>   files in the smail directory (don't remember the exact path
>   anymore), I could test my UUCP link using the command:
>       /usr/lib/uucico [-f] -x2 -s<hostname>
>   Without the -x2 (or higher e.g. x3, x4) flag, Linux would not
>   initiate a call otherwise uucico dials out with and without the -f
>   or the -r flags set.

Used to be that you needed -x4 for it to work but I think that's fixed
now.  I'm not certain what the minimum is with Taylor1.04 or if there
is one at all.

Quote:>3) I use crontab to schedule dialouts with the -f and -x2 flag on (I
>   want to make sure that the system dials out).  Everything works
>   fine for a day or so and then
>       /usr/lib/uucico -f -r1 -x2 -s<hostname>
>   would do nothing except create the LCK..* and TMP...... files
>   in /usr/spool/uucp.  The audit.local and other logs in the
>   /usr/spool/uucp don't seem to get updated when this happens (i.e.,
>   when uucico doesn't initiate a dialout).  Usually the logs will say
>   something or explain why the dialout didn't occur and a couple of
>   modem lights will flicker for a few seconds but in this case nothing.

Well if you don't show us the logs, we can't figure it out........

Quote:>Questions:
>a) How tightly "hardcoded" is the uucp neighbor "quick" to SLS 1.03?

it isn't.  Unless it's your real UUCP neighbor, it shouldn't be in there
at all.  Sigh...I can't understand how people keep making the mistake of
taking an example site-specific file and thinking it's valid for all sites
everywhere...

Quote:>b) How fast does the C.* and D.* files get created in the
>   /usr/spool/uucp/hostname directory?  I notice that sometimes those
>   files (email addressed to hostname) get created as soon as I "send"
>   them out of the mail program (Emacs rmail mode) but then there are times
>   I notice that the files don't get created that quickly.

takes a few seconds with sendmail or smail, I dunno with emacs.

Quote:>c) I haven't left my system alone long enough (e.g. for > 24 hours)
>   to see if the UUCP link will "wake" up again.  Is the uucico's behavior
>   described in 3 above expected?

no, it indicates you have something messed up on your end.
turn uugetty off and get uucp working first.
--

  It'll be great fun for the whole family...with a firearms orientation
                   - incredible adverti*t for local outdoors show.

It isn't, as far as I know...  I found though that the best idea was to
dump the HDB config files and use the Taylor config files instead.  For one
reason or another this got better results for me.  You could use uuconv
to create basic Taylor configs then place them in /usr/conf/uucp (the files
concerned should be port, dial and sys), then create a file called 'config'
which contains the line

  nodename <name of node>

Quote:>b) How fast does the C.* and D.* files get created in the
>   /usr/spool/uucp/hostname directory?  I notice that sometimes those
>   files (email addressed to hostname) get created as soon as I "send"
>   them out of the mail program (Emacs rmail mode) but then there are times
>   I notice that the files don't get created that quickly.

I find that this mostly just depends on how much else is going on at the time.
On my machine it takes about 30 seconds or so when it is being quick, but
then my machine is a little underpowered.

Quote:>c) I haven't left my system alone long enough (e.g. for > 24 hours)
>   to see if the UUCP link will "wake" up again.  Is the uucico's behavior
>   described in 3 above expected?

Not that I know of.  Although you could try changing the -s to -S.  That
*might* help, but I don't know if uucico creates a .LCK file everytime
it starts up or only when it actually does a dialout...

Matt
--
Matt McLeod
Bob-Fearing * Writer

After some experimenting I found out the root of my Linux UUCP
problem.  It seems that ownership of the UUCP files (in /usr/lib/uucp,
especially) has to be set to uid 11, the default uid set by Linux
during installation.  (Uid 11 is not in the installed passwd or group
files.)  I was setting the ownership to "uucp" (uid = 5, I think)
which should work but I think that I may have to set (haven't tried
this yet!) the ownership of several of the UUCp executables, (e.g. cu,
uuname, etc. in /usr/bin), from uid 11 to "uucp" too.  After setting
the ownership, I could uucico to download and upload mail to a remote
UUCP host via cron.  Smail mail conversion to C.* and D.* files works
like mint and so does uugetty for dial-outs.

However there are still some workarounds needed:
1) I have to use -x with a level of 2 and above to get uucico to
   actually dial out.  If I don't use -x or use -x1, the modem will
   not dial out even though two lights on Hayes Smartmodem (forgot the
   names for the lights but it is the 3rd and 4th lights from the
   right).  Interestingly they are the same set of lights that flicker
   a lot when I don't use the -r flag for getty or uugetty for the
   modem line (cua1).
2) I have to occassionally delete the audit.local file otherwise
   uucico will not dial out.  I don't know why.  Perhaps it has
   something to do with the file size???

Other than that UUCP mail works fine.  I'll try out the news
capability later.

Willie

After tinkering around with some settings, I got UUCP to work
properly!

Quote:Previously I wrote...

   ...It seems that ownership of the UUCP files (in /usr/lib/uucp,
   especially) has to be set to uid 11, the default uid set by Linux
   during installation.  (Uid 11 is not in the installed passwd or group
   files.)  I was setting the ownership to "uucp" (uid = 5, I think)
   which should work but I think that I may have to set (haven't tried
   this yet!) the ownership of several of the UUCp executables, (e.g. cu,
   uuname, etc. in /usr/bin), from uid 11 to "uucp" too.

I set the ownership of several files in /usr/bin to uucp (they were
originally set to uid 11).  These files are:

-r-sr-xr-x   1 uucp     root       123908 Mar 24 08:01 cu
-r-sr-xr-x   1 uucp     uucp        87044 Mar 24 08:01 uucp
-r-sr-xr-x   1 uucp     uucp        37892 Mar 24 08:01 uuname
-r-sr-xr-x   1 uucp     uucp        99332 Mar 24 08:01 uustat
-r-sr-xr-x   1 uucp     uucp        87044 Mar 24 08:01 uux

Then I set the ownership of all the files in /usr/lib/uucp to uucp
(from uid 11).  Similarly in /usr/spool/uucp, I change the ownership
of every file and directory with uid 11 to uucp.  Everything (except
dialin; I'm still working on that :-) works like mint now.  Thanks to
all for your comments, suggestions, and conjectures. :-)

   However there are still some workarounds needed:
   1) I have to use -x with a level of 2 and above to get uucico to
      actually dial out.  If I don't use -x or use -x1, the modem will
      not dial out even though two lights on Hayes Smartmodem (forgot the
      names for the lights but it is the 3rd and 4th lights from the
      right).  Interestingly they are the same set of lights that flicker
      a lot when I don't use the -r flag for getty or uugetty for the
      modem line (cua1).

This problem went away when I followed up on two person's suspicions
(including Ian Taylor's; thanks guys) that there may be some delay
problem.  The -x flag slows things down.  So I inserted a couple of
delay in the right entry of the /usr/lib/uucp/Devices file.  To be
safe I added an entry for wlimhayes in that file:

hayes      =,-, "" \dAT\r\c OK\r \EATDT\T\r\c CONNECT             # (original)
wlimhayes  =,-, "" \dAT\r\c\d OK\r \EATDT\T\r\c\d CONNECT         # (mine)
                            |                   |
                           delay               delay

I didn't play around to figure if I really need both delays or which
is the critical one.  Anyway, after that "uucico -f" and "uucico -r1"
work beautifully.

   2) I have to occassionally delete the audit.local file otherwise
      uucico will not dial out.  I don't know why.  Perhaps it has
      something to do with the file size???

This problem goes away once I avoided using the -x flag for uucico
since the audit.local files doesn't get created then.  For those who
asked, the last time I noticed the problem is when the file size for
audit.local was about 24k-25k. It went away when I deleted or moved
that file.

I hope this will help others to get their Linux uucp connection working.

Willie

: After tinkering around with some settings, I got UUCP to work
: properly!

Quote:: Previously I wrote...

:    ...It seems that ownership of the UUCP files (in /usr/lib/uucp,
:    especially) has to be set to uid 11, the default uid set by Linux
:    during installation.  (Uid 11 is not in the installed passwd or group
:    files.)  I was setting the ownership to "uucp" (uid = 5, I think)
:    which should work but I think that I may have to set (haven't tried
:    this yet!) the ownership of several of the UUCp executables, (e.g. cu,
:    uuname, etc. in /usr/bin), from uid 11 to "uucp" too.

: I set the ownership of several files in /usr/bin to uucp (they were
: originally set to uid 11).  These files are:

: -r-sr-xr-x   1 uucp     root       123908 Mar 24 08:01 cu
: -r-sr-xr-x   1 uucp     uucp        87044 Mar 24 08:01 uucp
: -r-sr-xr-x   1 uucp     uucp        37892 Mar 24 08:01 uuname
: -r-sr-xr-x   1 uucp     uucp        99332 Mar 24 08:01 uustat
: -r-sr-xr-x   1 uucp     uucp        87044 Mar 24 08:01 uux

: Then I set the ownership of all the files in /usr/lib/uucp to uucp
: (from uid 11).  Similarly in /usr/spool/uucp, I change the ownership
: of every file and directory with uid 11 to uucp.  Everything (except
: dialin; I'm still working on that :-) works like mint now.  Thanks to
: all for your comments, suggestions, and conjectures. :-)

:    However there are still some workarounds needed:
:    1) I have to use -x with a level of 2 and above to get uucico to
:       actually dial out.  If I don't use -x or use -x1, the modem will
:       not dial out even though two lights on Hayes Smartmodem (forgot the
:       names for the lights but it is the 3rd and 4th lights from the
:       right).  Interestingly they are the same set of lights that flicker
:       a lot when I don't use the -r flag for getty or uugetty for the
:       modem line (cua1).

: This problem went away when I followed up on two person's suspicions
: (including Ian Taylor's; thanks guys) that there may be some delay
: problem.  The -x flag slows things down.  So I inserted a couple of
: delay in the right entry of the /usr/lib/uucp/Devices file.  To be
: safe I added an entry for wlimhayes in that file:

: hayes    =,-, "" \dAT\r\c OK\r \EATDT\T\r\c CONNECT             # (original)
: wlimhayes  =,-,       "" \dAT\r\c\d OK\r \EATDT\T\r\c\d CONNECT         # (mine)
:                             |                   |
:                            delay               delay

: I didn't play around to figure if I really need both delays or which
: is the critical one.  Anyway, after that "uucico -f" and "uucico -r1"
: work beautifully.

:    2) I have to occassionally delete the audit.local file otherwise
:       uucico will not dial out.  I don't know why.  Perhaps it has
:       something to do with the file size???

: This problem goes away once I avoided using the -x flag for uucico
: since the audit.local files doesn't get created then.  For those who
: asked, the last time I noticed the problem is when the file size for
: audit.local was about 24k-25k. It went away when I deleted or moved
: that file.

: I hope this will help others to get their Linux uucp connection working.

I found the suggested ownerships, groups and permissions in the O'Reilly
book "Managing uucp and Usenet" to be very helpful.  Set up things like
it said and everything works beautifully.
-- Mark

: Willie