tjc@ecs.soton.ac.uk (Tim Chown) (01/04/91)
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? Tim
jpr@jpradley.jpr.com (Jean-Pierre Radley) (01/06/91)
In article <6153@ecs.soton.ac.uk> tjc@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? To my knowledge, /etc/cshrc is sourced by all occurences of csh. Jean-Pierre Radley NYC Public Unix jpr@jpr.com CIS: 72160,1341
spotter@eve.wright.edu (Sh'r'ldana) (01/06/91)
In article <6153@ecs.soton.ac.uk> tjc@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? > >Tim The system that has been implemented here was to write a shellscript to run the commands, and put it in place of the default login-shell field. Ours is only to allow the user to log in and change the password from the default we give them to something they want, and then log out, but it should be expandable, possible with 'exec {whatevershell}'. Steve -- anagram@desire.wright.edu | "Tough times demand tough hearts, demand tough spotter@eve.wright.edu | thoughts, demand tough songs, | Demand!" -Rush <Std.Dsc> WSU doesn't approve of anything I do, but that hasn't stopped me yet.
guy@auspex.auspex.com (Guy Harris) (01/08/91)
>To my knowledge, /etc/cshrc is sourced by all occurences of csh.
Your knowledge is incomplete. It turns out he's running SunOS, and the
SunOS "csh" doesn't source "/etc/cshrc"; neither does the 4.3BSD "csh"
from which it's derived. Some versions of "csh" may have such a file -
or an "/etc/login"-like file, sourced only by login shells - but with a
different name. jc@minya.UUCP (John Chambers) (01/08/91)
In article <6153@ecs.soton.ac.uk>, tjc@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
alex@am.sublink.org (Alex Martelli) (01/11/91)
jc@minya.UUCP (John Chambers) writes:
[discussion of using a script as shell for a pseudo-user]
: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
Just kludge up a way to disable motd-checking - simplest scheme I can
think of, offhand, is to add something like:
egrep "^$LOGNAME:.*NOMOTD" /etc/passwd >/dev/null && exit
just before the cat /etc/motd in /etc/profile, then add the NOMOTD
keyword somewhere in the /etc/passwd line of the pseudo-user (e.g. in
the gcos field, or just use it as a part of the filename of the pseudo
shell script for the pseudo-user).
: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;
Fancy that, I'd count this as one NASTY thing about csh!-)
: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
One day I'll tell you about the getty which catted /etc/issue, which
contained something about "AT&T" which the somewhat-Hayes-compatible
modem took as a request to ENTER SELF-TEST-MODE...
: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.
On this general subject, I can agree wholeheartedly. I particularly
detest such useless feechures as automatical sourcing of .logout on
shell termination, when trapping on a 0 signal (to . .logout, or to
whatever one wants) is so clearly right! They pander to semieducated
users, and semieducated system administrators, and meanwhile make it
all more complex for all of us.
--
Alex Martelli - (home snailmail:) v. Barontini 27, 40138 Bologna, ITALIA
Email: (work:) staff@cadlab.sublink.org, (home:) alex@am.sublink.org
Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434;
Fax: ++39 (51) 366964 (work only), Fidonet: 332/401.3 (home only).jc@minya.UUCP (John Chambers) (01/14/91)
> :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; > > Fancy that, I'd count this as one NASTY thing about csh!-) Not really. The benefit to making .login and .logout local to each user's home directory, and using no global files at all, is that you can give each new user a default version that does nice things like "cat /etc/motd" and "mail -e" and so on, but they can be emptied or deleted for users that need (or want) other behavior. It's true that using a single global file is an initial convenience for administrators, but only until they stumble across the problems it causes with packages that use pseudo-users for some purpose. Then the convenience evaporates. It's a bit of a task initially, but it's not hard to write a little program that generates the names of the .login files of all "real" users, and feeds this list to a for loop that appends a new line. In my experience, users don't often complain about the admin doing such a thing, at least if the new action is generally useful, and they can delete it if they're unhappy. > One day I'll tell you about the getty which catted /etc/issue, which > contained something about "AT&T" which the somewhat-Hayes-compatible > modem took as a request to ENTER SELF-TEST-MODE... No, don't tell me about it; I can easily imagine the fun you had! > On this general subject, I can agree wholeheartedly. I particularly > detest such useless feechures as automatical sourcing of .logout on > shell termination, when trapping on a 0 signal (to . .logout, or to > whatever one wants) is so clearly right! They pander to semieducated > users, and semieducated system administrators, and meanwhile make it > all more complex for all of us. Actually, I've found the .logout to be a minor convenience. You don't have to use it, and it's a cleaner way of dealing with closing actions (like forcing a modem to hang up) than surrounding the program with yet another background shell that sits there idle, using system resources. It's conceptually much easier to use (and debug) than the Bourne shell's trap feature. And I've never made any sense at all of the C-shell's way of dealing with signals. (I mean, I've read TFM, but it doesn't do what I want it to; I guess I'm just an idiot, so I'l use the thing that idiots like me can understand. ;-) -- 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
jfh@rpp386.cactus.org (John F Haugh II) (01/14/91)
In article <1991Jan10.191546.268@am.sublink.org> alex@am.sublink.org (Alex Martelli) writes: >Just kludge up a way to disable motd-checking - simplest scheme I can >think of, offhand, is to add something like: > egrep "^$LOGNAME:.*NOMOTD" /etc/passwd >/dev/null && exit >just before the cat /etc/motd in /etc/profile, then add the NOMOTD >keyword somewhere in the /etc/passwd line of the pseudo-user (e.g. in >the gcos field, or just use it as a part of the filename of the pseudo >shell script for the pseudo-user). If you are going to "Just kludge up a way" you might as well use the way that exists already. if [ ! -f $HOME/.hushlogin ]; then cat /etc/motd fi This is how BSD login handles the problem. -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org "While you are here, your wives and girlfriends are dating handsome American movie and TV stars. Stars like Tom Selleck, Bruce Willis, and Bart Simpson."
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (01/14/91)
As quoted from <1991Jan10.191546.268@am.sublink.org> by alex@am.sublink.org (Alex Martelli): +--------------- | jc@minya.UUCP (John Chambers) writes: | [discussion of using a script as shell for a pseudo-user] | :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 | | Just kludge up a way to disable motd-checking - simplest scheme I can | think of, offhand, is to add something like: | egrep "^$LOGNAME:.*NOMOTD" /etc/passwd >/dev/null && exit +--------------- $ sed -n 6,10p /etc/profile if test ! -f $HOME/.hushlogin; then if newer-than /etc/motd $HOME/.enoughalready; then cat /etc/motd touch $HOME/.enoughalready fi fi $ cat newer-than.c #include <stdio.h> #include <sys/types.h> #include <sys/stat.h> main(argc, argv) int argc; char **argv; { struct stat f1, f2; if (argc != 3) { fprintf(stderr, "usage: newer-than file1 file2\n"); exit(2); } if (stat(argv[1], &f1) == -1) { perror(argv[1]); exit(2); } if (stat(argv[2], &f2) == -1) { perror(argv[2]); exit(2); } return (f1.st_mtime <= f2.st_mtime); } $ # those with "test file1 -nt file2" can use that instead $ _ ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
andy@research.canon.oz.au (Andy Newman) (01/14/91)
We used to have a common start up script for csh users that would eventually exec csh for them but ran into problems with rsh. We changed over to having everyone run sh (which does run /etc/profile on Sun's) and exec'ing csh if needed. -- Andrew Newman, Software Engineer. | Net: andy@research.canon.oz.au Canon Information Systems Research Australia | Phone: +1 61 2 805 2914 P.O. Box 313 North Ryde, NSW, Australia 2113 | Fax: +1 61 2 805 2929
boyd@necisa.ho.necisa.oz.au (Boyd Roberts) (01/15/91)
In article <1991Jan13.231048.25341@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR) writes: > >$ sed -n 6,10p /etc/profile >if test ! -f $HOME/.hushlogin; then > if newer-than /etc/motd $HOME/.enoughalready; then > cat /etc/motd > touch $HOME/.enoughalready > fi >fi But Brandon, where's the test on: "$HOME/.i-really-don't-want-to-see-the-motd-ever!" I just don't think you've got enough complexity in your solution. Boyd Roberts boyd@necisa.ho.necisa.oz.au ``When the going gets wierd, the weird turn pro...''
fitz@wang.com (Tom Fitzgerald) (01/15/91)
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) writes: > $ sed -n 6,10p /etc/profile > if test ! -f $HOME/.hushlogin; then > if newer-than /etc/motd $HOME/.enoughalready; then > cat /etc/motd > touch $HOME/.enoughalready > fi > fi > $ cat newer-than.c > #include <stdio.h> > #include <sys/types.h> [...] Why write C code? I think this is portable (though, admittedly, ugly): if test ! -f $HOME/.hushlogin; then /bin/find /etc/motd -newer $HOME/.enoughalready -exec cat {} \; 2>/dev/null touch $HOME/.enoughalready fi --- Tom Fitzgerald Wang Labs fitz@wang.com 1-508-967-5278 Lowell MA, USA ...!uunet!wang!fitz
mta@lehtori.tut.fi (J{rvinen Markku) (01/15/91)
Tom> Why write C code? I think this is portable (though, admittedly, ugly):
I agree, no one-use programs to my bin.
Tom> if test ! -f $HOME/.hushlogin; then
Tom> /bin/find /etc/motd -newer $HOME/.enoughalready -exec cat {} \; 2>/dev/null
Tom> touch $HOME/.enoughalready
Tom> fi
Well I have allways liked my own solution, just have (looooonngg line)
find /etc/motd -newer ${HOME}/.hushlogin -exec cat {} \; -exec touch ${HOME}/.hushlogin \; -o ! -newer ${HOME}/.hushlogin -exec head -1 {} \;
in your .login, just one find which shows /etc/motd or first line of it
depending have you seen it already.
Tom> Tom Fitzgerald Wang Labs fitz@wang.com
- mta
--
Quote: UNIX systems always run in one state or another.
- RISC/os (UMIPS) System Administrator's Guide
Markku Jarvinen, last a with two dots over it | Tampere University of Tecnology
address: mta@{cc.,}tut.fi or ..!mcsun!tut!mta | Tampere, Finland
--
Quote: UNIX systems always run in one state or another.
- RISC/os (UMIPS) System Administrator's Guide
Markku Jarvinen, last a with two dots over it | Tampere University of Tecnology
address: mta@{cc.,}tut.fi or ..!mcsun!tut!mta | Tampere, Finlandprc@erbe.se (Robert Claeson) (01/15/91)
In article <449@minya.UUCP>, jc@minya.UUCP (John Chambers) writes: |> Not really. The benefit to making .login and .logout local to each |> user's home directory, and using no global files at all, is that you |> can give each new user a default version that does nice things like |> "cat /etc/motd" and "mail -e" and so on, but they can be emptied or |> deleted for users that need (or want) other behavior. It's true that |> using a single global file is an initial convenience for administrators, |> but only until they stumble across the problems it causes with packages |> that use pseudo-users for some purpose. Then the convenience evaporates. Tell me about it. We have been using /etc/profile for common setups for quite some time now and find it a major convenience. We have several software packages that needs special pseudo users, and haven't had any problems with them. Exactly what problems could one expect, and for what packages? |> It's a bit of a task initially, but it's not hard to write a little |> program that generates the names of the .login files of all "real" |> users, and feeds this list to a for loop that appends a new line. |> In my experience, users don't often complain about the admin doing |> such a thing, at least if the new action is generally useful, and |> they can delete it if they're unhappy. Here, all "default" setup is done in /etc/profile. The files .profile and .kshrc are never touched by the administrators. They are solely for the user's own private use, to add definitions or override setup done by the administrator. If a user wants a shell other than ksh (Korn shell), he can easily add an "exec /bin/csh" to his/her .profile. Here's a sample /etc/profile: -------- snippety-snap ---------- #!/bin/sh # # Name: # /etc/profile # # Description: # Common, system-wide user login initialization file for # Bourne and Korn shell users. # # # Defaults. # DEFAULT_TERMTYPE=vt320 # # Function: # select_termtype # # Purpose: # Select the terminal type. # # Returns: # The terminal type in the TERM variable. # select_termtype() { if [ "$TERM" = "" -a -x /usr/bin/tput ]; then if [ -f $HOME/.defaults/defterm ]; then chmod u+r $HOME/.defaults/defterm defterm=`cat $HOME/.defaults/defterm` else defterm="$DEFAULT_TERMTYPE" fi found=0 badtry=1 while [ $found -ne 1 ]; do if [ $badtry -ne 1 ]; then echo "The terminal type does not exist." echo "Please try again." fi badtry=0 echo "Terminal type (${defterm}): \c" read selection junk if [ -n "$selection" ]; then TERM=$selection; export TERM else TERM=$defterm; export TERM fi tput gn >/dev/null 2>&1 test $? != 3 && found=1 done unset defterm selection junk found badtry fi if [ -f $HOME/.defaults/defterm ]; then chmod u=rw $HOME/.defaults/defterm fi echo "$TERM" > $HOME/.defaults/defterm chmod u=r,go-rwx $HOME/.defaults/defterm } # # Function: # init_terminal # # Purpose: # Initialize the line characteristics and the terminal. # init_terminal() { stty -parenb cs8 -istrip echo echoe echok kill '^u' intr '^c' erase "^h" if [ -x /usr/bin/tput ]; then /usr/bin/tput init /usr/bin/tput kbs >/dev/null 2>&1 if [ $? = 0 ]; then stty erase "`/usr/bin/tput kbs`" fi fi } # # Function: # init_mnls # # Purpose: # Initialize language and character set variables. # # Preconditions: # The terminal type must be initialized. # init_mnls() { # # In lack of other ways to do it, set language and # character set based on the terminal type. # case "$TERM" in vt2??*|vt3??*|vdu2??*|wy185*|wyse185*|xterm*) LANGUAGE=swedish.8859; export LANGUAGE CHRCLASS=iso_8859_1; export CHRCLASS LC_CTYPE=iso_8859_1; export LC_CTYPE ;; *) LANGUAGE=swedish.646; export LANGUAGE CHRCLASS=iso_646_se; export CHRCLASS LC_CTYPE=iso_646_se; export LC_CTYPE ;; esac } # # Function: # init_packages # # Purpose: # Initialize software packages variables and the search path. # init_packages() { # # Standard directories and features. # PATH=.:/bin:/usr/bin:/usr/lbin:/usr/ucb; export PATH EDITOR=/usr/bin/vi; export EDITOR MAILCHECK=30; export MAILCHECK MAILPATH=/usr/mail/"$LOGNAME"?"E-mail has arrived."; export MAILPATH ENV=$HOME/.kshrc; export ENV # # Local utilities. # PATH=$PATH:/usr/local/bin # # X11: # PATH=$PATH:/usr/bin/X11:/usr/local/bin/X11 # # Verdix VADS. # PATH=$PATH:/usr/local/vads/bin # # INFORMIX. # PATH=$PATH:/usr/local/informix/bin INFORMIXDIR=/usr/local/informix; export INFORMIXDIR DBDATE=Y4MD-; export DBDATE DBEDIT=$EDITOR; export DBEDIT DBMONEY=", kr"; export DBMONEY DBPATH=$INFORMIXDIR/db/address; export DBPATH # # Micro Focus COBOL. # PATH=$PATH:/usr/local/cobol/bin COBDIR=/usr/local/cobol/lib; export COBDIR # # Adobe Transcript. # PATH=$PATH:/usr/local/transcript/bin # # FrameMaker 1.3X. # PATH=$PATH:/usr/local/frame1.3/bin FMHOME=/usr/local/frame1.3; export FMHOME # # News. # NEWSBOX=$HOME/News; export NEWSBOX NEWSARCHIVE=$NEWSBOX/sent; export NEWSARCHIVE AUTHORCOPY=$NEWSARCHIVE; export AUTHORCOPY # # Rn. # SAVENAME="%C"; export SAVENAME SAVEDIR="%p"; export SAVEDIR MBOXSAVER='%X/mbox.saver %A %P %c %a %B %C "%b" "From %T `LANGUAGE= date`"'; export MBOXSAVER # # WordPerfec 4.2. # PATH=$PATH:/usr/local/wp/bin # # Ingres. # II_SYSTEM=/usr/local; export II_SYSTEM PATH=$PATH:$II_SYSTEM/ingres/bin VEC=$II_SYSTEM/ingres/vec; export VEC # # FACE. # VMSYS=/usr/vmsys; export VMSYS OASYS=/usr/oasys; export OASYS PATH=$PATH:$VMSYS } # # Function: # display_messages # # Purpose: # Display common login messages. # display_messages() { # # Display the message-of-the-day. # if [ "$LOGNAME" != "root" ]; then case "$0" in -*) if [ -f /etc/motd -a -r /etc/motd -a ! -f $HOME/.hushlogin ] then cat -s /etc/motd else echo "\033#6No system messages." fi ;; esac fi # # Check for mail. # if [ -x /usr/local/bin/messages ]; then /usr/local/bin/messages > /dev/null 2>&1 MSGS=$? if [ $MSGS -gt 0 ]; then echo "\033#6\033[1mYou have $MSGS messages.\033[m" fi elif [ n16 -a -x /bin/SYSVmail ]; then # UMAX V /bin/SYSVmail -e && echo "\033#6\033[1mYou have mail.\033[m" elif [ `uname` = dgux -a -x /usr/bin/mail ]; then # DG/UX /usr/bin/mail -e && echo "\033#6\033[1mYou have mail.\033[m" elif [ -x /bin/mail ]; then # Others /bin/mail -e && echo "\033#6\033[1mYou have mail.\033[m" fi } # # Function: # main # # Purpose: # Main routine. # # # Disable signals. # trap "" 2 3 # # Set current timezone. # if [ -f /etc/TIMEZONE ]; then . /etc/TIMEZONE fi # # Put username into environment. # export LOGNAME # # Set default file protection mask (umask). # umask 022 # # Create directory for user defaults. # # Note: this seemingly rude approach was implemented on user requests. # if [ ! -d $HOME/.defaults ]; then mkdir $HOME/.defaults > /dev/null 2>&1 fi chmod u=rwx,go-rwx $HOME/.defaults > /dev/null 2>&1 # # Set terminal type. We do this early since the init may destroy the # contents of the screen. # TERMINFO=/usr/share/local/lib/terminfo; export TERMINFO select_termtype # # Initialize the terminal. # init_terminal # # Select language and character set. # init_mnls # # Initialize packages and set search path. # init_packages # # Display messages to the user. # display_messages # # Enable signals. # trap 2 3 ---------------------------- -- Robert Claeson |Reasonable mailers: rclaeson@erbe.se ERBE DATA AB | Dumb mailers: rclaeson%erbe.se@sunet.se Jakobsberg, Sweden | Perverse mailers: rclaeson%erbe.se@encore.com Any opinions expressed herein definitely belongs to me and not to my employer.
mohta@necom830.cc.titech.ac.jp (Masataka Ohta) (01/16/91)
In article <1991Jan16.000012.26467@lokkur.dexter.mi.us> scs@lokkur.dexter.mi.us (Steve Simmons) writes: >A global .cshrc/.login is a much better >solution. A much much better solution is to change login shells of related users to /usr/local/bin/csh_with_global_cshrc_and_login. If you don't have source, try 'source /dev/tty'. Masataka Ohta
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (01/18/91)
As quoted from <1991@necisa.ho.necisa.oz.au> by boyd@necisa.ho.necisa.oz.au (Boyd Roberts): +--------------- | In article <1991Jan13.231048.25341@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR) writes: | >if test ! -f $HOME/.hushlogin; then | > if newer-than /etc/motd $HOME/.enoughalready; then | > cat /etc/motd | > touch $HOME/.enoughalready | > fi | >fi | | But Brandon, where's the test on: | "$HOME/.i-really-don't-want-to-see-the-motd-ever!" +--------------- Xenix, remember. In any case, that's .hushlogin. ;-) .enoughalready was added after the owner of ncoast put a 3-page ad in /etc/motd and everyone had to read it every time they logged in for a week. It was actually a quick hack; I added "newer-than" afterward. BTW, there *is* a bug in the above: I didn't test for the existence of .enoughalready, so it spits out a spurious error message the first time anyone logs in. The actual code in use here is a bit more bizarre, as there are *three* /etc/motd files (/etc/motd, /etc/motd.real, /etc/motd.motd; don't ask me why Rich did this) with different levels of blocking for them. ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
dave@galaxia.Newport.RI.US (David H. Brierley) (01/18/91)
I took a slightly different approach to this problem. I modified the login program so that when it got done validating the password and doing whatever else it wanted, instead of execing the users shell it execed a program that I had written called 'sh_init'. The sh_init program then took care of all of the global stuff that needed to be done including displaying the motd file, setting a bunch of variables in the environment, and asking the user what 'charge number' they would be using for this session. The program also has hooks for running a machine-specific init file. Admittedly, this approach requires that you have source to the login program but there are enough PD login programs floating around that this should not be a real problem. -- David H. Brierley Home: dave@galaxia.Newport.RI.US Work: dhb@quahog.ssd.ray.com Can I be excused, my brain is full.
rsalz@bbn.com (Rich Salz) (01/19/91)
Cshell
cmp -s /etc/motd $HOME/.hushlogin
if ( $status ) tee $HOME/.hushlogin </etc/motd
Real shell
cmp -s /etc/motd $HOME/.hushlogin || tee $HOME/.hushlogin </etc/motd
This has tickled bugs on some shells, including early Bash, I think,
so you have to use the more ugly:
if cmp -s /etc/motd $HOME/.hushlogin ; then
:
else
tee $HOME/.hushlogin </etc/motd
fi
--
Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.
Use a domain-based address or give alternate paths, or you may lose out.tjc@ecs.soton.ac.uk (Tim Chown) (01/21/91)
In <3220@litchi.bbn.com> rsalz@bbn.com (Rich Salz) writes: >Cshell > cmp -s /etc/motd $HOME/.hushlogin > if ( $status ) tee $HOME/.hushlogin </etc/motd I am very grateful for all the replies to my original question about forcing actions. We now have users "controlled" as desired on login (setting paths, MANPATHs, global messages and some process renicing), but I would like to ask what can be done for connections where a login per se is not run. The particular example I'm interested in is an X-session under SunOS4. In this context it appears that only the user's .cshrc is inspected; Sun seem to have no global .cshrc or .profile scheme. Is there anything I can do here? Cheers, Tim.
sjg@melb.bull.oz.au (Simon J Gerraty) (01/22/91)
In <1991Jan16.000012.26467@lokkur.dexter.mi.us> scs@lokkur.dexter.mi.us (Steve Simmons) writes: >Different sites have different needs. There's many a time I've >*desperately* needed to set something for *all* users *all* the time >(Hi Bill!). Without a global setup file the only solution is to modify I agree. Of course you don't have to slash your wrists if your vendor did not build global init file support into your c-shell. I just create global files /etc/csh.{login,cshrc} and source these in the default .login,.cshrc files that users are provided with. Eg. # .cshrc 1.1 # pick up the standard environment source /etc/csh.cshrc # place personal commands here Of course this approach does not _force_ the use of /etc/csh.cshrc since users can always remove the source line. In practice however they do not - after all, I only put useful things in the global files anyway :-) -- Simon J. Gerraty <sjg@melb.bull.oz.au> #include <disclaimer,_witty_comment>
cornutt@freedom.msfc.nasa.gov (David Cornutt) (01/23/91)
Here's an off-the-top-of-my-head suggestion; I haven't actually tried this. Create a directory (call it /usr/everyone) which is designated as the home directory in the passwd entries. Make it owned by root (or other privileged uid) and writable to no one except the owner. Put a .login and a .cshrc in there containing the things that you want everyone to have. Then, have the .login, as the last thing that it does, source a script which looks up the user's *real* home directory in a list somewhere, cd's to it and sets the HOME variable to it, and then sources the user's .login and .cshrc (if you want). This way, the users can still have their personalized logins if you want to let them do that, and you don't have to cut off their write access to their own home directories. Possible problems with this approach: (1) Having never actually tried this, I don't know if changing HOME is sufficient to alter csh's notion of what the home directory is, or what the possible side effects might be. (2) Subshells will still execute the user's .cshrc instead of the one in /usr/everyone. (3) Extra force would be required to be able to admin this over YP (create a new map for the home directory list, write a script to extract entries from it, etc.), or to integrate it into an automated account maintenance tool. Possible benefits: (1) Users can exercise control over their home directories. (2) You only have to maintain one copy of the mandatory .login and .cshrc, in /usr/everyone. (3) Other wierdities that you get when users can't create files in their home directories go away (.lastlogin works, for instance). -- David Cornutt, New Technology Inc., Huntsville, AL (205) 461-6457 (cornutt@freedom.msfc.nasa.gov; some insane route applies) "The opinions expressed herein are not necessarily those of my employer, not necessarily mine, and probably not necessary."
bush@prg.ox.ac.uk (Mark Bush) (01/23/91)
In article <1991Jan22.185016.15252@freedom.msfc.nasa.gov> cornutt@freedom.msfc.nasa.gov (David Cornutt) writes: > sets the HOME variable to it, and then sources the user's .login > and .cshrc (if you want). This way, the users can still have their > personalized logins if you want to let them do that, and you don't > > Possible problems with this approach: > [ problems (1) to (3) deleted ] (4) The user may not necessarily have/want csh as their shell. If a user wants the Bourne shell (for example) as their shell and your `global' account has the C-shell, then you can't just source their .profile. Execing the user's real shell after setting HOME ought to work, though. Another solution, of course, is to replace /bin/login with something which does all the normal jobs and also checks for the existance of some file to execute before starting up the user's shell. Mark
hansm@cs.kun.nl (Hans Mulder) (01/23/91)
In article <1991Jan22.185016.15252@freedom.msfc.nasa.gov> cornutt@freedom.msfc.nasa.gov (David Cornutt) writes: >Here's an off-the-top-of-my-head suggestion; I haven't actually >tried this. Create a directory (call it /usr/everyone) which is >designated as the home directory in the passwd entries. Make it >owned by root (or other privileged uid) and writable to no one >except the owner. Put a .login and a .cshrc in there containing >the things that you want everyone to have. [ etc. ] You really should try these things before posting them. It won't work on most systems, as the C shell ignores .cshrc and .login files not owned by the effective uid, for security reasons. I'll admit that the version of Csh that comes with SunOS 4.1.1 gets this wrong. I guess the straightforward method of including # Do not remove these lines, unless you know what you are doing source /etc/login in everybody's .login file (or something similar in .profile) works best. Any tactic to force unwilling users is likely to break things. Have a nice day, Hans Mulder hansm@cs.kun.nl
cornutt@freedom.msfc.nasa.gov (David Cornutt) (01/24/91)
.nl> hansm@cs.kun.nl (Hans Mulder) writes: [replying to my entry in the Stupid Login Tricks contest] >It won't work on most systems, as the C shell ignores .cshrc and >.login files not owned by the effective uid, for security reasons. I have not encountered this. If it's true, then the other suggestion (of having everyone's .login/.cshrc owned by root) won't work either. You're correct in that there isn't a good way to prevent the ambitious users from modifying their shell setup somehow, short of totally locking them into a captive environment where they never see a prompt. -- David Cornutt, New Technology Inc., Huntsville, AL (205) 461-6457 (cornutt@freedom.msfc.nasa.gov; some insane route applies) "The opinions expressed herein are not necessarily those of my employer, not necessarily mine, and probably not necessary."
rickert@mp.cs.niu.edu (Neil Rickert) (01/24/91)
In article <2679@wn1.sci.kun.nl> hansm@cs.kun.nl (Hans Mulder) writes: > >You really should try these things before posting them. > >It won't work on most systems, as the C shell ignores .cshrc and >.login files not owned by the effective uid, for security reasons. > You really should try these things before posting them. Many versions of C shell will execute a .login file owned by root, even if root is not the effective ID. The real problem of giving everyone the home directory of /everyone is that standard methods of finding the real home directory will no longer work. For example files such as '.forward' which are examined when you are not logged in will be shared by all users. What you have to do is give everyone a different shell. That different shell changes the value of $HOME to the /everyone directory, cd's to that directory, redefines $SHELL to the real csh or sh, then exec's this shell. The shell then will execute the .login or whatever, reset the $HOME to its correct value, and you go on from there. Note that by changing the value of $SHELL, only your first interface (be it login, rsh etc) goes through this processing, but subsequently invoked shell use the user specified processing. You also have to carefully control what 'chsh' is allowed to change the shell to. Whether all this is really worth the trouble is quite questionable. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
terryl@sail.LABS.TEK.COM (01/24/91)
In article <1991Jan23.191016.20988@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: >In article <2679@wn1.sci.kun.nl> hansm@cs.kun.nl (Hans Mulder) writes: >> >>You really should try these things before posting them. >> >>It won't work on most systems, as the C shell ignores .cshrc and >>.login files not owned by the effective uid, for security reasons. >> > >You really should try these things before posting them. > > Many versions of C shell will execute a .login file owned by root, even if >root is not the effective ID. You both should look at the code before posting guesses as to what REALLY is happening. As a matter of fact, you both can be right (but not at the same time); the source is set up so a compile time option decides whether or not a user's .cshrc (and .login) is source'd automagically upon shell invocation, if that .cshrc (and .login) is owned by another user (or group; i.e. if the groupership is the same, but ownership isn't, the file will be source'd regard- less of the compile time option). __________________________________________________________ Terry Laskodi "There's a permanent crease of in your right and wrong." Tektronix Sly and the Family Stone, "Stand!" __________________________________________________________
dik@cwi.nl (Dik T. Winter) (01/24/91)
In article <1991Jan23.191016.20988@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: > Whether all this is really worth the trouble is quite questionable. > Depends. When you need it for accounting the trouble is worthwile. For all other situations you should not force users to go through some predefined actions. I have seen many solutions, one of them provided a system wide profile that asked for terminal type. That is gross, unless it is possible to overrule it. Consider a section of my 500+ lines profile (where TERM has just been read, or has been gotten through the network): if grep "$TERM" $HOME/lib/termcap >/dev/null 2>&1 then TERMCAP=$HOME/lib/termcap fi if test -f $HOME/lib/terminfo/*/$TERM then TERMINFO=$HOME/lib/terminfo fi export TERMCAP TERMINFO eval `tset - -Q -s` Yes, I like my own personalized terminal descriptions, but sometimes I want the standard ones, but that depends on the way I got onto the machine (telnet, direct, rlogin etc.). Also, on some machines I have access to, /etc/profile is executed twice when I login. Once when my login shell is started (/bin/sh on those machines). The shell soon executes the command 'exec -myshell' which starts my own shell. This one dutifully reexecutes /etc/profile. So I get twice /etc/motd while zero times is enough in my opinion. Further, why does /etc/profile check for mail in SysV UNIX? I read my mail on one machine only, but the mailbox is NFS mounted on all machines. I do not want to see that message any time I login to some random machine. Luckily our system administrator could be convinced to do it conditional on .hushlogin (it did not need much convincing). Summary: you should only force something on the user if it is related to accounting; nothing else. You should never force a particular PATH; you may give him some functions/aliases that can make life simple. But he should be able to redefine/undefine them. -- dik t. winter, cwi, amsterdam, nederland dik@cwi.nl
hansm@cs.kun.nl (Hans Mulder) (01/24/91)
In article <8834@sail.LABS.TEK.COM> terryl@sail.LABS.TEK.COM writes: >In article <1991Jan23.191016.20988@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: >>In article <2679@wn1.sci.kun.nl> hansm@cs.kun.nl (Hans Mulder) writes: >>> >>>You really should try these things before posting them. >>> >>>It won't work on most systems, as the C shell ignores .cshrc and >>>.login files not owned by the effective uid, for security reasons. >>> >> >>You really should try these things before posting them. >> >> Many versions of C shell will execute a .login file owned by root, even if >>root is not the effective ID. > > You both should look at the code before posting guesses as to what REALLY >is happening. [ Explanation of what is really happening deleted. ] I disagree. One should not have to look at the source, it's the vendor's responsibility to make the source match the man page, especially if he is selling a binary-only distribution. In the case, the source should be changed to do what the man page says. Neil, you are telling to me to try things out before posting, and you didn't include the paragraph in my posting where I mentioned that Sun got in wrong in SunOS 4.1.1. How, exactly, do you think I found out? Have a nice day, hans Mulder hansm@cs.kun.nl
jim@tiamat.fsc.com (Jim O'Connor) (01/25/91)
In article <1135@galaxia.Newport.RI.US>, dave@galaxia.Newport.RI.US (David H. Brierley) writes: > > Admittedly, this approach requires that you have source to the login program > but there are enough PD login programs floating around that this should not > be a real problem. Is there a PD login program that works correctly with rlogind (i.e. it reads the info being passed to it about remote user name, term type, etc)? Thanks. --jim ------------- James B. O'Connor jim@tiamat.fsc.com Ahlstrom Filtration, Inc. 615/821-4022 x. 651
prc@erbe.se (Robert Claeson) (02/07/91)
In article <1991Jan28.232740.26815@ida.liu.se> d89peter@odalix.ida.liu.se (Peter Eriksson) writes: >Why go thru all these throubles (and CPU-eating things)? >The most easy thing to do must be to get the sources >to the login program off uunet.uu.net and add what you >need there?! Will it work, without major modifications, on a SVR3.2-SVR4.0 system? -- Robert Claeson |Reasonable mailers: rclaeson@erbe.se ERBE DATA AB | Dumb mailers: rclaeson%erbe.se@sunet.se Jakobsberg, Sweden | Perverse mailers: rclaeson%erbe.se@encore.com Any opinions expressed herein definitely belongs to me and not to my employer.
guy@auspex.auspex.com (Guy Harris) (02/11/91)
>Will it work, without major modifications, on a SVR3.2-SVR4.0 system?
Dunno, but *if* the actions to be forced need only occur on accounts with
the Bourne, C, or Korn shells as login shells, the Bourne and Korn
shells have supported "/etc/profile" since S5"R1" and the C shell in
S5R4 also supports an equivalent (I don't remember what its name is, and
I think they forgot to document it). ("Bash" also supports
"/etc/profile".)allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (02/15/91)
As quoted from <5852@auspex.auspex.com> by guy@auspex.auspex.com (Guy Harris): +--------------- | Dunno, but *if* the actions to be forced need only occur on accounts with | the Bourne, C, or Korn shells as login shells, the Bourne and Korn | shells have supported "/etc/profile" since S5"R1" and the C shell in +--------------- System III, no? The old Plexus that was once ncoast has /etc/profile. (And no, we never upgraded it to System V.) ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
yedidya@bimacs.BITNET (Yedidya Israel) (02/17/91)
In article <1991Jan22.185016.15252@freedom.msfc.nasa.gov> cornutt@freedom.msfc.nasa.gov (David Cornutt) writes: >Heres an off-the-top-of-my-head suggestion; I havent actually >tried this. Create a directory (call it /usr/everyone) which is >designated as the home directory in the passwd entries. Make it >owned by root (or other privileged uid) and writable to no one >except the owner. Put a .login and a .cshrc in there containing >the things that you want everyone to have. Then, have the .login, >as the last thing that it does, source a script which looks up >the users *real* home directory in a list somewhere, cds to it and >sets the HOME variable to it, and then sources the users .login >and .cshrc (if you want). This way, the users can still have their >personalized logins if you want to let them do that, and you dont >have to cut off their write access to their own home directories. > >Possible problems with this approach: [three of them deleted] Add this one 4) "cd ~someone" will change directory to /usr/everyone (or what else you call it). -- | Israel Yedidya, Math & CS Department, Bar-Ilan U, Ramat-Gan, ISRAEL. | +----------------------------------------------------------------------+ | Internet: yedidya@bimacs.biu.ac.il Bitnet: yedidya@bimacs | | Uucp: ...!uunet!mcvax!humus!bimacs!yedidya | \----------------------------------------------------------------------/ \--- If someone proves there is no God, I'll stop being religious ---/ --------------------------------------------------------------------