Casper.Dik at Sun.COM 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.
>
> Correct. And that is where we have a difference of opinion; I believe
> that it is wrong for us to force changes upon existing users.
You already do that if you deploy new versions of the same software...
> I, for one,
> would be *extremely* unhappy if someone messed with my default path, TMPDIR
> and PAGER settings. But it is fine to change that for new users and
> new accounts.
But we will never get rid of the contents in ~/.profile, ~/.bashrc and
~/.kshrc. These files are close to be an ultimate nightmare for the
admins. I am now doing several years some admin job and we still have
problems with old accounts using these files and can't get rid of them
without writing xx@@@!!-emails do each single xx@@@!!-user. Imagine how
"funny" such a problem is...
> >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.
>
> Well, such sites may choose to implement reasonable site specific changes
> to the /etc files.
>
> How happy do you think the admin of a site of 80000 users will be if
> the new settings in /etc/profile broke their existing customized
> login and .shellrc scripts?
If this causes problems the admins can edit the machine-/site-wide
files. Even in the worst case this is much better than sending lots of
emails to grouchy users. At least the admins get the _choice_.
> I don't buy the argument that a site with 8000 users is helped by us
> changing the settings in /etc/profile and ilk; perhaps your site because
> the default closely match what your site wants. But I don't see this
> mapping in the same way to other sites.
>
> Part of the argument is changing the usability for *new* users; but
> this proposal has nothing to do with *new* users at all; it inflicts
> change upon the 100,000s of users already using Solaris.
>
> My /etc/skel counter proposal is aimed squarely at those new users.
And how will the /etc/skel/-propsal handle the case if we fix ksh93's
"multiline" editor option and then enable it by default in
/etc/ksh.kshrc ? Old users won't get it.
> I have no argument with changing man to be more intelligent in
> searching for manual pages, BTW.
Ok... but that's a different ARC case... ;-/
> >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).
>
> And I strong disagree, unless the proposal also leaves all of the
> /etc files UNCHANGED.
Erm, /etc/bash.bashrc and /etc/bash.bash_logout are _new_ files, only
/etc/ksh.kshrc will be changed to set PS1 if not set yet.
[snip]
> I have little problems with new defaults for ksh93 or any shells, but I
> would like to keep the paths in sync.
Erm, what do you mean with "keeping the paths in sync" ?
> But anything which requires users to make changes to their .* files to
> undo Solaris inflicted change is wrong, IMO.
>
> And don't give me any argument based on law; apart from being incorrect,
> as there is no problem in drawing up a policy which allows the administrator
> to edit those files, there is still nothing which prevents you from
> changing these files yourself.
I doubt anyone would give the univesity admins such a permission. Maybe
I wasn't clear about how serious the issue is: Violating data privacy is
- at least in germany - a _fireable_ _offense_ and drawing up a policy
will likely not work since the data protection commissioner will start
ranting (unless you try to hide the change from him/her) and the public
outcry would force the officials to withdraw such a permission. We have
enougth precedent for that here in germany, ranging from the current
bickering about privacy issues with the electronic health card to up
privacy issues with the Linux migrations in some local parliaments.
> "But we don't want to do that" is not a valid argument; it gives rise
> to the ridiculous notion that these defaults are the only ones anyone
> would want.
>
> As it is, there are other problems which need to be addressed regardless
> of the outcome of the discussion:
>
> - the upgrade process currently makes some edits to the
> "skel" and /etc/* files
>
> this mechanism does not seem to be suited to the wholesale set
> of changes proposed here (also because any changes by the
> administrator to the files to revert the new defaults may be
> then later undone)
>
> Options:
> Punt
> (edit only those things which are actual bugs and don't bother
> ever updating the files after a system is installed)
>
> Overwrite
> (copy the new file in place, regardless of the old content)
3rd option: Rename old, put new one in it's location and send the admin
an email.
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
