Bug#1834: kubla@goofy.zdv.Uni-Mainz.de: /etc/profile on Debian Linux]
Ian Murdock writes:
> A little complicated, perhaps, but he does have good suggestions.
Try. I'd like to take issue with a few of the bits, though:
> # /etc/profile - sh(1) initialization file for Linux-based systems.
> # Copyright (C) 1993-1995 by Dominik Kubla, <Dominik Kubla@Uni-Mainz.DE>
...
> # Set the umask:
> # umask 000 # -rwxrwxrwx Insane - "Calm down, the doctor's here."
> # umask 002 # -rwxrwxr-x Innocent - "Gee, i hear Santa coming!"
> umask 022 # -rwxr-xr-x Standard - "Just plain old number 22."
> # umask 027 # -rwxr-x--- Cautious - "Who are you and can you prove it?"
> # umask 077 # -rwx------ Paranoid - "The martians are after me ..."
This would interwork badly with user private groups and our scheme for
ensuring that people's umask is right. The default default umask, so
to speak, is 002 and isn't "innocent" :-).
> # Set core file size to 0, if a user wants cores, he will have to enable them.
> ulimit -c 0
This makes handling bug reports a lot harder.
> # Some login programs export LOGNAME, some USER. Make that consistent.
> if [ -z "$USER" ]; then
> USER=$LOGNAME
> export USER
> elif [ -z "$LOGNAME" ]; then
> LOGNAME=$USER
> export LOGNAME
> fi
This is the business of login, which we control, not of the
/etc/profile.
> [ environment settings for ARCH, TZ, HOSTNAME, DOMAIN,
> MAIL, PATH, WWW_HOME, NNTPSERVER, NLSPATH &c ]
Yuk.
An ARCH variable is a site-specific thing, and the FSSTND people are
thinking of withdrawing arch (which isn't available everywhere) in
favour of uname (which is).
TZ, MAIL, WWW_HOME, NNTPSERVER, NLSPATH should not be set. If they
need to be then the program that is trying to use them is broken.
HOSTNAME and DOMAIN are local policy and not particularly helpful.
The usual way to do this is to use `hostname' in whatever script in
question.
Setting the PATH is plausible, but we should set it to one specific
thing, rather than having lots of conditionals.
> [ fortune, calendar, &c ]
This doesn't belong in the global /etc/profile, because then users
can't disable it.
Most of this belongs in /etc/skel/.profile if anywhere.
Note that the more stuff we put in /etc/skel/.profile or /etc/profile
the more we will have to edit it, and the more work sysadmins (who
will have to edit them too) will have to do because of conffiles
prompts relating to these files.
Ian.
Reply to: