On Wed, May 09, 2007 at 08:49:38AM -0400, James Carlson wrote: > Roland Mainz writes: > > Casper.Dik at Sun.COM wrote: > > > So we're going down that path some; I'm not sure we should go down > > > that path even further, especially when there are reasonable alternatives. > > > > I strongly think that putting any new defaults into /etc/skel/ files is > > the wrong solution. I am still suffering from the mistakes done by my > > predecessor six years ago and other sites are in a similar situation. > > I think it's possible to achieve a balance here. > > If the /etc/skel/.profile were to source a file elsewhere in /etc > (such as /etc/default), then almost all of the constraints would be > satisfied:
Er, how about a slight variation (what I'd actually read when I wrote this was "nice"): Ship /etc/profile that by default just sources /etc/default/profile or some such (and ship that too) -- the former is customer editable and never modified on update/patch, the latter is Sun editable and potentially replaced on update/patch. Sysadmins can always replace /etc/profile with a version that doesn't source /etc/default/profile. > - Existing users would not see any change as a result of this > project. - Existing users would see changes only to defaults they'd not set before. > - Newly-created users would see the default environment. Check. > - The default environment would be centrally-located and could be > updated in the future without having to visit each user's local > home directory. Check. > You could even make that two separate files -- one for defaults > delivered by the OS distribution, and another for defaults set by the > local administrator. (One type 'f' in packaging, the other > intentionally not delivered at all.) Check.
