workarounds for TCP/IP & mail problems (SCO)

[Lyle Seaman]

Background:
because MMDF (as shipped) is broken, I chose to use Sendmail.
Sendmail is activated by doing a "mkdev sendmail-init" which internally
runs a script to generate a configuration file.  This script can be
invoked by "mkdev cf".  The "mkdev sendmail-init" also modifies the 
/etc/tcp script so that sendmail is run when TCP/IP is started up.


The mkdev cf idea is a good one, and I'd be pretty happy if it worked. 
Unfortunately, it's broken, so the sendmail.cf file it generates is
unuseable.  To work around this, you will have to get more involved in
sendmail rewriting rules than you want to.  If you already know sendmail,
then you know what you'll have to do.  I've hacked up the .cf file pretty
badly, but it works OK for me now.  

The "mkdev sendmail-init" adds sendmail to the /etc/tcp script so that
sendmail is started automatically when the system is booted.  Unfortunately,
sendmail will not deliver mail in that case, it only queues mail.  Every 
attempt to deliver mail results in a failure of either "Host Name Lookup
Failed" or "can't exec /bin/lmail".  This doesn't occur when sendmail is
started manually by killing the sendmail process in the background and
resubmitting it.  It also doesn't occur if you do "tcp stop; tcp start".
It only occurs when tcp is started at boot time.

Unfortunately, if you do a "tcp stop; tcp start" manually, no one can
rlogin, telnet, or rcmd to your machine, or rcp (or ftp) to or from it:
they will receive an error "Bad login user id".  The only way that you
can restart TCP/IP while permitting those functions is to reboot.  But
that prevents sendmail from working.

The solution is to edit your /etc/tcp script and change the startup
of sendmail from:
/usr/lib/sendmail -bd -q1h
to:
su root -c '/usr/lib/sendmail -bd -q1h'

This works around the Obscurware LUID hack, and permits sendmail to work
properly when the system is booted.  Of course, you still are forced to
reboot to restart TCP/IP; there's no way to restart it while allowing 
the above-listed functions to work without mucking with kmem.

-- 
Lyle                      Wang             lws at comm.wang.com
508 967 2322         Lowell, MA, USA       uunet!comm.wang.com!lws
             The scum always rises to the top.