Brian K. White said the following on 12/26/2011 03:01 PM:
On 12/26/2011 8:16 AM, Anton Aylward wrote:
jdd said the following on 12/26/2011 06:57 AM:
I feel very bad writing anything myself in /lib! (let alone for backup purpose).
But I see a "/etc/systemd/system" folder.
And? How come you feel bad about putting something in /lib (or presumably /bin) and not in /etc?
How about /usr/lib or /usr/bin?
If its supposed to go in /lib then its supposed to go in /lib because that's where the software (systemd) will look for it.
My point here is really that yes, if you don't know what you're doing than doing things as root can screw up your system, but you can screw it up just as well by putting an init function in /etc/systemd/ as in /lib/system. Or for that matter under SysVInit putting it in /etc/rc.d/rc5.d.
Don't listen jdd. Your point was perfectly clear to normal people and your guess was correct.
https://wiki.archlinux.org/index.php/Systemd#How_do_I_make_a_custom_unit_fil...
Its all very well to say "The unit files in /etc/systemd/system take precedence over the ones in /lib/systemd/system", but go look. The files in /etc/systemd/system/ are symlinks to ones in /lib/systemd/system/ So its possible that at some future time you do a restore of the backup of the /etc/ tree and something in that is a symlink to a /lib/systemd/system/ file that no longer exists. How will the SystemD process like that?
And contrary to his later post, configs _that matter_ are not "all over the place". They are in very few and well known places, and most everything that isn't either in /etc or /home are dynamically generated from, or reading, something that IS.
With a few exceptions (see below) that's true, but misses the point. The point is that for better or worse there *IS* dynamically generated stuff in other places. I'll grant you that new, virgin, out of the box system doesn't have a lot of what I'm talking about, but a mature, multi-user system does. A poster-boy example here is Named. Its not needed on a passive workstation once /etc/resolv.conf has been filled in to point to a DNS server. But if the host is serving dns requests, that is it is running named and named ha been securely configured - aka chrooted - then its actually elsewhere. Yes that elsewhere could be /etc/chroot/named but for some reason most systems I've used put it under /var/lib/named/. Come to think of it, there's a lot of dynamically generated stuff under /var/lib that I'd back up: the spamassassin database files, rpm and zypper stuff and more. Its not quite the static config you expect in /etc, but it *is* config in that it determines the state of the machine as a working entity, how it differs from baseline install. Yes, it you have custom fonts and stuff, they can end up under $HOME, that's if you have a single use machine. But if you have a server and the /use/share, for example, is shared via NFS so that all the workstations can benefits from additional features (such as fonts, icons and so forth), then the changes over and above the installation baseline should go there rather that in ~/.fonts/ or ~/.icons/ So yes, Brian, you are right in the specialized case.
And those few things that qualify as host-specific manual (won't happen automatically) configuration that may exist outside of /etc or /home on a poorly managed system, do not justify abandoning the best practices that always strive towards sane organization.
John Barth has a great line in one of his works: "Reality is a nice place to visit, but I wouldn’t want to live there". Many of us don't have the choice.
/srv is content not config. You already know to back up all data dirs,
I sincerely hope you do backup /srv - or wherever. There's config in that content. Take a look at what's under /etc/httpd/ More symlinks? When I installed some applications the config appeared under /etc/httpd/config.d/ but in reality that was a symlink to the real files under /srv How does your backup work? Is it a tree-walker based on find? Does it follow symlinks? Or does it take snapshots of file systems?
/usr/share may have hand-installed stuff, but if so that's just sloppy thoughtless administration,
No, it may be good administration, with /usr/share on the file server to make sure all the workstations receive the benefit of things there, as I described above.
or evidence of a package that needs improvement so that it will install it's own things in /usr/share but also look in /usr/local, /home, etc for user-supplied stuff.
Or KDM that is stupid in that it puts the config file kdmrc in. /usr/share/kde4/config/kdm/kdmrc So what else is in /usr/share/kde4/config/ ? They seem like templates to me, but kdmrc is not something to be copied to ~/.kde4/ since it is used by the system before login. Yes it should be in /etc/<something> but it isn't and any changes you make, customization[1] are there in /usr/share/ Reality bites. [1] e.g. restricted access warnings in accordance with corporate policy and legal advice. See http://www.unifiedcompliance.com/matrices/live/01742.html -- "...there is no reason anyone would want a computer in their home." Ken Olson, President, Chairman, and Founder of DEC, 1977 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org