Roland Mainz wrote:
> And how can we update those files in the user accounts ? At least in
> europe there are issues with data privacy and many sites explicitly
> disallow any channges of per-user data by admins without the explicit
> permission of the users. Anything delivered to the users ${HOME} is
> "fixed in stone" and cannot easily be changed anymore once it is
> delivered to the user.
> Imagine larger university sites with something like ~~80000 accounts. If
> you put the "wrong" things into ~/.profile, ~/.bashrc and/or ~/.kshrc
> this will result in a horror for the admins.
> That's why this case explicitly says that the matching files in
> /etc/skel/ should be delivered _empty_ except comments that admins
> should edit the machine-wide files (e.g. /etc/profile, /etc/bash.bashrc
> and /etc/ksh.kshrc for side-/machine-wide defaults).The way that Sun deals with this (and has done for quite some time) internally is something like this, IIRC something very similar was deployed at Glasgow Uni when I was a student there: The skeleton .profile/.cshrc/.kshrc that is placed in the users home dir when the account is created looks for a site wide profile (which is actually held in an automounted filesystem (/usr/dist/share/cue - CUE is Common User Environment)) and sources that in. Thats all it does, the comments in users .profile tell them not to modify the file at all but instead to add their changes into .profile.user (.cshrc.user). The default .profile.user that each user has is empty but has instructions for customisation. There are some CUE_ environment variables that can be set to change so defaults one of these is CUE_USERLEVEL which has values like "novice" or "advanced". I also noticed that some systems (Sun Ray servers in particular) have a modified /etc/profile that sources in /etc/profile.d/*.sh - the only file in there on the host I looked on was for setting ..... $TMPDIR :-) This solves the problem of site specific defaults and later update of site policy without changing user files. However that is only one motivation for change the default environment, the other is making Solaris more approachable to new Solaris users. I think thats a noble goal, but as Casper pointed out changes to the system files rather than the /etc/skel ones can lead to unexpected changes in the existing users environment when they do an upgrade - but worse it also applies if they login to a machine that was freshly installed. This is a hard balance to get unfortunately. One of the things that has occurred to me in sponsoring this case is that these are exactly the types of things that each OpenSolaris distribution could be doing differently. So is this really an OpenSolaris case or a case for changing Sun's OpenSolaris distribution ? -- Darren J Moffat
