How to prevent system-(over)writes to customized /etc/sysconfig/* files?

[ip15]

I've customized my '/etc/sysconfig/apache2' config file.

Apparetnly, after occassional package upgrades, the file gets written to, adding numerous comment lines:

## Type: ...
## Default: ...
## ServiceRestart: ...

How do I turn off this re-writing of the config file? Is there a pref file or setting to tweak?

The apache2 config is just an example ... this happens for multiple /etc/sysconfig/* files.

[LewsTherinTelemon]

While I don't know of any way to explicitly configure sysconfig files to not be modified, my two suggestions would be: 1) chattr +i to set them immutable - a bit drastic. Or 2) Use a simple version control tool like rcs to keep check in your current versions, and if needed easily recover them. (Or you could just put everything in sysconfig, or even /etc into a git repo, etc.)

Cheers,

[ip15]

Thanks.

Both options would certainly work. Agreed re: "a bit drastic". Not really workable for wider roll-out.

It's not ideal that *any* system action touches your config customizations at all. Most other apps/packages seem to 'know better'. Ideally, a 'flag' to prevent that -- as one can for example set IN /etc/sysconfig/bootloader so as to NOT touch/overwrite /boot/grub/menu.lst -- would work best.

[hcvv]

I do not know if I understand fully what you want. For Apache the configuration is in /etc/apache2. I use default-server.conf and files in conf.d there and never found them overwritten. But /etc/sysconfig/apache2 may be usefull for something different

Also other changes in e.g. /etc/sysconfig/network I do manualy or via YaST are normaly not written over by e.g. a security update.

Can you specify more precise when what is written over?

[ip15]

> Can you specify more precise when what is written over?

Once I modify a config file -- whether format/organization, comments, or settings -- I don't want it touched/modified/written/overwritten by anything, unless I explcitly give it permission to do so.

In this example, 'some' system action adds a whole bunch of comment lines,

## Type: ...
## Default: ...
## ServiceRestart: ...

repeatedly through my /etc/sysconfig/apache2 file.

It seems to add all three lines, repeatedly, for most (but not all) existing options in the file.

In doing so, it definitely screws up *my* formatting and comment, sometimes interleaving those comment lines with what I've written, resulting in garbage.

Doesn't really matter WHAT it writes to the file -- My point is simply that I'd like the option to NOT have ANYTHING written. (e.g., having the word "PROTECT" in line#1 of the file, or some such thing)

hth.

[nrickert]

It's not ideal that *any* system action touches your config customizations at all.

I agree with that sentiment. I find the way "/etc/csh.cshrc" and "/etc/bash.bashrc" are handled to be particularly annoying. In my way of looking at things, those files are local system admin files, and the distro should not touch them, other than perhaps provide a sample version on original install.

In any case, what I do is use "rcs" to keep track of changes. My "/etc/RCS" is actually a symlink to "/home/RCS.etc". That way, as long as I preserve the home partition, I can get to my revision history. Similarly, if I needed "/etc/sysconfig/RCS", I would make that a symlink to "/etc/RCS/RCS.sysconfig" (or, really, to "../RCS/RCS.sysconfig) so that the real RCS directories are all in the "/home/RCS.etc" tree.

[ip15]

> provide a sample version

Agreed. An up-to-date EXAMPLE config is always useful.

> use "rcs" to keep track of changes

Clear. For my own boxes, I use a combination of bzr and rsync backups to similar end.

Again, agreed that such files should be left alone.

[DenverD]

On 09/02/2011 11:06 PM, nrickert wrote:
>
> "/etc/bash.bashrc"

have you not discovered written within /etc/bash.bashrc:

# PLEASE DO NOT CHANGE /etc/bash.bashrc There are chances that your changes
# will be lost during system upgrades.  Instead use /etc/bash.bashrc.local
# for your local settings, favourite global aliases, VISUAL and EDITOR
# variables, etc ...

and, i _guess_ there are ways to protect all configs (i just keep a
backup) but you must realize that stuff changes in new releases and new
version....and, when it does the old config may no longer work....while
the one which come with the new app/system does....AND, if things are
done right the new mans will adequately explain _how_ to fit the new
requirements of the app into your system's configs..

the apache problem, i have no idea but guess what is being seen is NOT
normal...something is broken in the setup...(just a guess)

--
DD
Caveat

[ip15]

> you must realize that stuff changes in new releases

That's obvious. As you'd expect it to be for anyone purposefully editing/commenting their config files.

Which is why you practice the discipline to read man pages, changelogs, updated example-configs, etc.

In any case, that's not an legit argument for silently modifying config files that have been modified by the user.

Unless Opensuse policy IS to NOT modify /etc/sysconfig/* files. Possible that I missed that somewhere.

[nrickert]

have you not discovered written within /etc/bash.bashrc:

Yes, of course I have seen that.

I can only repeat that "/etc/bash.bashrc" is supposed to be a local system administrator's file. It should not be cluttered with all sorts of distro-related stuff.

but you must realize that stuff changes ...

Sure, stuff changes. The shell startup files are the wrong places to handle those changes.

If the desktop needs additional environment variables, then those should be defined in the desktop startup scripts, and not in the shell startup scripts.