I’ve customized my ‘/etc/sysconfig/apache2’ config file.
Apparetnly, after occassional package upgrades, the file gets written to, adding numerous comment lines:
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.
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,
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.
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?
> 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,
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.
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.
> 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.
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
> 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.
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.
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.
On 09/03/2011 01:56 AM, nrickert wrote:
> 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.
ok, now i understand (i think) that the question in the subject (how to
prevent overwrite) is about this distribution’s philosophy of how
config files are designed for use vs the way other distro’s use
their /etc/config (and therefore ‘prevent overwrite’)…
ok2, you know how to preserve local admin desired stuff in
/etc/bash.bashrc.local but you want the same feature for all configs
in /etc, or some other philosophical change in how 1) the system and
2) the administrator customize those files during use
so, as i see it you have a few courses of action to choose from:
try to change this distro’s basic philosophy on how configs in /etc
are used–and, you can not do that here because you must interact with
the developers, and they are NOT here…this is a help forum of users
helping users and NOT a place where developers and system design
decision makers hang out; they are easy to find on IRC and/or mail list,
see here http://en.opensuse.org/openSUSE:Communication_channels
alternatively you could ask for a new feature be implemented (like
maybe a /etc/sysconfig/apache2.local), that too needs to get to the
devs–in this distro’s universe that is done via FATE, here:
https://features.opensuse.org/
you could use what works for you…that is, you don’t like the
current (and afaik, long standing) openSUSE way of doing this, so use
the distro which works for you…and if you still want to try to change
this distro’s way, go ahead and do that, but not in this help
forum…if you impact the design philosophy you can come back, if not:
it is a big ocean of distributions and enough variance to make most
anyone happy…
finally, i’ll say again: the apache problem [seen by ip15], i have no
idea but guess what is being seen is NOT normal…something is broken
in the setup…(just a guess)…and suggest if you want to try to fix
that then lets focus on that here, and you can try to change the distro
with the devs, and not here…
–
DD
Caveat
Yes, you can disable SuSEconfig completely :
From Yast , System, /etc/sysconfig Editor:
→ System
--------> SuSEconfig
------------------> ENABLE_SUSECONFIG: no.
Be sure you read the warning and understand the implications of disabling SuSEconfig:
Some people don’t want SuSEconfig to modify the system. With this
entry you can disable SuSEconfig completely.
Please don’t contact our support if you have trouble configuring your
system after having disabled SuSEconfig. (yes/no)
I modify this file too to select the Apache modules to be started.
# diff /etc/sysconfig/apache2.orig /etc/sysconfig/apache2
103c103
< APACHE_MODULES="actions alias auth_basic authn_file authz_host authz_groupfile authz_default authz_user autoindex cgi dir env expires include log_config mime negotiation setenvif ssl userdir php5"
---
> APACHE_MODULES="actions alias auth_basic authn_file authz_host authz_groupfile authz_default authz_user authn_dbm autoindex cgi dir env expires include log_config mime negotiation setenvif ssl suexec userdir php5 info asis status imagemap"
One more word to post #12. !
I do NOT recommend (nor did I suggest) to disable SuSEconfig! I just answered the question about the pref file or setting to tweak.
Thanks for the clarification.
Perhaps I am missing something here, but is part of this issue that Suse (perhaps) sometimes employs .rpmnew and .rpmsave files when updating packages, but is not uniform in this? Or that the /etc/sysconfig/apache2 file is incorrectly not associated with the apache2 package?
Running this on my system:
find /etc/ -print | egrep "rpmnew$|rpmsave$"
Shows the following config files (including one in /sysconfig) have .rpmnew or .rpmsave files from previous updates:
/etc/ssh/ssh_config.rpmnew
/etc/postfix/main.cf.rpmnew
/etc/rsyslog.conf.rpmnew
/etc/pam.d/login.rpmnew
/etc/tomcat6/tomcat-users.xml.rpmsave
/etc/cups/cupsd.conf.rpmnew
/etc/issue.rpmnew
/etc/bash.bashrc.rpmsave
/etc/modprobe.d/50-ipv6.conf.rpmsave
/etc/fonts/suse-hinting.conf.rpmsave
/etc/sysconfig/SuSEfirewall2.rpmnew
/etc/sane.d/dll.conf.rpmnew
/etc/papersize.rpmnew
Could this really just be a case of the Apache packages not creating .rpmnew files when updating? If so, the package maintainer could be contacted and asked to not to clobber the /sysconfig (and other) files?
Also, I find this a bit odd:
rpm -qf /etc/sysconfig/apache2
file /etc/sysconfig/apache2 is not owned by any package
Why is this not associated with the Apache2 rpm? If it were, and were later updated, the old version (should) be kept in place and the new version installed as /etc/sysconfig/apache2.rpmnew (provided it were specified so in the package)?
On 09/06/2011 08:26 PM, LewsTherinTelemon wrote:
>
> is part of this issue that
> Suse (perhaps) sometimes employs .rpmnew and .rpmsave files when
> updating packages, but is not uniform in this?
i guess that question as well as this whole thread should all go to the
developers/pagkagers, i gave the how-to talk to them in post #11.
–
DD
Caveat
openSUSE®, the “German Automobiles” of operating systems
Hi
It’s all done by rpm post/postun macro’s and whether or not the
packager has defined either as a %config file and/or added (noreplace)
https://build.opensuse.org/package/view_file?file=apache2.spec&package=apache2&project=openSUSE%3A11.4&srcmd5=3b8ed7ec2d301f1152ef8750707eafab
–
Cheers Malcolm °¿° (Linux Counter #276890)
openSUSE 11.4 (x86_64) Kernel 2.6.37.6-0.7-desktop
up 19:35, 3 users, load average: 0.03, 0.09, 0.11
GPU GeForce 8600 GTS Silent - Driver Version: 280.13
On 2011-09-06 20:26, LewsTherinTelemon wrote:
> Running this on my system:
>
>
> Code:
> --------------------
> find /etc/ -print | egrep “rpmnew$|rpmsave$”
> --------------------
>
>
> Shows the following config files (including one in /sysconfig) have
> rpmnew or .rpmsave files from previous updates:
Run “rcrpmconfigcheck” instead.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)
On 2011-09-02 22:06, ip15 wrote:
> 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)
Not possible, as it is happening by design.
You can, however, write a bugzilla, giving the exact file before and after
the update of which exact rpm.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)