Re: Bug#150514: Uer maodifications _must_ bre preserved, even is a co-admin said otherwise a few releases ago
On Mon, Jun 24, 2002 at 04:18:42PM -0500, Steve Greenland wrote:
> On 24-Jun-02, 14:53 (CDT), Gordon Russell <email@example.com> wrote:
> > On Mon, Jun 24, 2002 at 01:57:36PM -0500, firstname.lastname@example.org wrote:
> Wrong. Regardless of your opinion of other people's administration
> procedures, if you overwrite a user modified file under /etc/ without
> asking you are in violation of policy, and it is basically unacceptable.
> I'll offer one exception: if the file is very clearly marked as being overwritable, and is offers a clear, easy way to remove the possibility of being automatically modified, then I think that's a generally accepted procedure:
Your exception is not in the Policy document. I draw a distinction between
modifying a user's file and modifying a package's file, but this distinction
is only in my head of course. setserial manages
this file for the system, and if a system administrator wants to play with
this file he should stop setserial from managing it. You appear to argue for
a system that can guess if it is to manage a file automatically or not. Editing
the file does not necessarially mean that the administrator wants to manage it.
> It's not just a matter of admins not talking to each other. If I install
> stable, and then a year later modify /etc/foo.conf, and then a year after
> that upgrade to the new stable version, I am unlikely to remember that
> 2 years ago I said "okay" to your debconf question.
Hopefully you read the manual and discover that to protect your changes you
need to check the configuration. Actually the file also says that
it is automatically generated on the first line as help information to
the administrator. Again you argue that I must support people who do not know
how to edit this file properly , where properly is defined (only by me) as
following the instructions.
> I don't want a debconf question every time. I don't want you to
> overwrite my files, either. Debconf is a way to get original
> configuration information on the initial install, but editing the config
> file by hand must take precedence.
If I do not ask the question, how do I know I can change it? It can change
hundreds of times in a single uptime, as the serial.o module is loaded
and unloaded in a system which unloads unused modules. If a user requests
this functionality, you argue that I must mind-read to know if the admin
has changed their mind yet. In addition when the system shuts down the
configuration of the serial ports can be remembered for the next reboot.
Does this need a question too or just a configuration via debconf?
> Really? You mean I can't copy around my /etc/resolv.conf? Or
> /etc/ntp.conf? Or /etc/printcap? It will break the system? Gee, I didn't
> know that. I suspect it will be news to a lot of sysadmins.
You must copy each file with some care. Some are pretty common and others
highly specific. /etc/hostname for instance should not be copied to all
machines. If this is news to sys admins then they are in trouble. Sorry,
but this "Gee I didn't know that" does not add anything useful to this
honestly asked discussion.
> Because you're not supposed to fsck with an admins changes without
> asking. That's what policy says, and that's what a great many of expect,
> and the ability to rely on such behaviour is why a great many of us
> prefer Debian to Redhat.
And this crappy attitude of criticism without help or advice is why I
often consider giving up Debian. If you want to suggest something then
I am happy to discuss this with you, provided I actually receive discussions
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org