Forcing actions at login

[John Chambers]

In article <6153 at ecs.soton.ac.uk>, tjc at ecs.soton.ac.uk (Tim Chown) writes:
> I would like to know the neatest way of forcing certain actions to
> be taken when a user logs in to the system.  For example, I would
> like to ensure everyone sees the global message of the day, or 
> perhaps get reniced if they're not a priority user on machine X.
> 
> Is the recommended way to simply put the name of a script in the
> passwd file instead of /bin/csh (or whatever)?  I can't see any
> other alternative as the user has to own .login, but are there
> any ill side-effects from this action?

Lots of others will answer this, so I'll stick to explaining why you
might not want to do it to literally "all" users.  The word "all" by
implication includes all the pseudo-user accounts, such as those used
by UUCP, SLIP, and other packages that do networking via serial ports.

If you force these "users" to receive things like /etc/motd, you may 
find that you've disabled them entirely.  The reason is that they work
by logging in (required because serial ports are usually guarded by
getty or uugetty or such and you have to get them to open the door
for you), and then doing a handshake.  The programs normally won't
wait forever for the receiving end to initiate a handshake; if you
stuff /etc/motd out the port, the programs will likely see it as
garbage, and exit.  UUCP and SLIP normally have limits of about 256
bytes (though sometimes it is 1K); /etc/motd often grows larger than
this.

Of course, you observe, such packages usually don't use /bin/sh or
/bin/csh as login shells; they use their own daemons.  But it is
quite common to "wrap" these daemons in a shell script.  One reason
for doing this is that the daemon doesn't know how to tell your modem
to hang up (or correct some other obscure problem caused by your
vendor's brain-damaged idea of how serial ports should work). But 
you have a program that does it, so you move uucico to uucico.real, 
and write a 2-line login script that runs uucico.real and then your 
hangup program.  If you use csh, you don't need to do any renaming; 
you just have .login run uucico and .logout run your program.

It turns out to be a bad idea to use /bin/sh as the login shell for
such a script.  Why?  Well, /bin/sh insists on running /etc/profile
for all users; there's no (documented ;-) way to suppress this.  If 
your /etc/profile does "cat /etc/motd" (and most do), it is just a 
matter of time until some helpful soul (probably you) puts a whole 
screen of good stuff into /etc/motd, and uucp no longer works, usenet 
is down, and you can't even ask the helpful folks here for help.

One nice thing about csh is that it doesn't have such a mandatory
global startup file.  It only runs $HOME/.login and/or $HOME/.cshrc;
for pseudo-users, you can strip these down to a minimum, and not
interfere with their handshakes.

On the other hand, just a few weeks ago, I ran across a sytem with
a very clever getty that dumps /etc/motd to the port itself.  The
owners had installed both UUCP and SLIP, they were working fine, 
and one day both of them totally stopped.  Luckily they had my version
of SLIP (;-) which has a detailed logfile; when I looked at it, it
showed me the English text; I asked if they recognized it; they said
"Sure, that's the Message of the Day"; and I said "Aha!!!"  We fixed
it by trimming the /etc/motd.  Then a week later, it happened again;
one guess as to why.  I replaced getty with a login daemon of my own, 
and the problem went away.  (At least until someone sees the funny 
line in /etc/ttys and "corrects" it.)  Now if I could only delete 
that "feature" from their getty.

Why is it that, as commercial Unix systems get more and more "user
friendly", they get harder and harder to keep working right.  Maybe
we should start hollering about "admin friendly" features.

-- 
All opinions Copyright (c) 1991 by John Chambers.  Inquire for licensing at:
Home: 1-617-484-6393 
Work: 1-508-486-5475
Uucp: ...!{bu.edu,harvard.edu,ima.com,eddie.mit.edu,ora.com}!minya!jc