On Wed, 2004-03-17 at 08:56 +0200, Panu Matilainen wrote: > > I don't really disagree with you but OTOH it's just a question of usage: > you *can* safely turn a service off with "chkconfig <service> off" and > that's the intended way to turn of services, not by removing them from > chkconfig management alltogether. > > This isn't all that different from what happens if you decide some > permissions are unsafe and do "chmod go-x /some/path" - now when the > package which owns /some/path gets upgraded those permissions are resetted > to whatever the package wants, overriding an action administrator > purposefully made. > > - Panu - file permissions is I believe an issue because of limitation of rpm. Does rpm change permissions on a file that is marked %config if a sysadmin has modified it? I don't believe it does - not if it's flagged %noreplace. btw - file permissions is another issue - I has a user that I use to build stuff in /usr/local/src (shouldn't build as root) so I chgrp admin /usr/local/src && chmod 775 /usr/local/src - and some rpm (not sure which one - filesystem?) undid that as well. But that's minor. But rpm has the facilities to not change a config file that has been changed (%noreplace) and has facilities to only run parts (or all) the % post script on a clean install opposed to upgrade. So while there really is no way to stop rpm from changing permissions on a file that rpm owns when upgrading, there are facilities to stop it from re-adding a service to chkconfig that has been removed from chkconfig management. I'm not fond of situations where an administrator is forced to use a bolton to sysV because of the way that the distro writes the spec files. _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
