On 12/26/2011 4:19 PM, Anton Aylward wrote:
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.
Dynamically generated stuff doesn't matter. It is generated dynamically. ...you know...from configs, generally found in /etc. Various chroot-able services create and maintain/update the chroot environment under /var because that is exactly what /var is for. That stuff is generated and updated automatically and on-the-fly from data in /etc Mature multiuser? Uptime doesn't matter. I have 6 or 7 year old boxes that have been actually UP for over 3 years, that have over 200 login shell interactive users. Not just narrow focus specialized web servers but application servers running several main software apps as well as web/ftp/mail/fax serving all as part of the main app. And they have just about nothing that is host-specific that isn't in /etc, /home, srv, and a few application-specific data directories of our own. Everything else can get flushed with a new install or upgrade. I don't even put things in /usr/local any more except disposable stuff like using /usr/local/src for local osc builds for maintaining packages in obs. It's a simple matter to have been bitten by upgrades a few times way back when you had your first unix box, and then after that you just avoid shooting yourself in the foot. Any time something comes up that would otherwise involve writing some custom file into any system directory, I simply don't do it. I create or modify a package and install that package, and/or I figure out how to relocate the custom part to someplace sane, and usually there is already some means to do that and all I have to do is bother to use it. I haven't yet found anything that can't be made generic and portable even if it's crappy 3rd party commercial software that was not organized sanely to begin with. I don't see what the issue is with systemd. Any files that are provided in /etc in the form of symlinks to files in /usr, are simply files you shoulld elect not to customize. You write new ones in /etc. What's the problem? Or are you saying whole directories are symlinked and they are directories that you are supposed to write new user created files into because there is no other dedicated directory for that? If the systemd package really has some glaring failing like that, well there are no shortage of problems with systemd as it's a new package and still half baked. So that would just be one more example of why it's still a poor package even if it's a good idea in the long run. Sysv init works the other way, where the real script is in /etc/init.d and the /etc/rc3.d and /usr/sbin/rcfoo are just symlinks, so that when you back up /etc, you actually get the stuff that matters. You don't want to blindly restore all that onto a new box any more than you want to blindly restore the rest of /etc, but that's not the point. It might be nice but the real important thing is the data needed to recreate the system is not lost. Again, just because there is crap software out there that doesn't provide full seperation and organization, doesn't justify not even trying wherever else you can. If I didn't try, sure, my systems would be plain unmanageable. I'd have crap all over the place and I could never migrate or update anything without it being an all day project just for one little box. But luckily, although I am still stupid in many ways, I'm at least less stupid about this because when I back up just /etc, /srv, 3 other directories particular to us, and /home (and really I don't even need /home but I'll grant that most people that have users, have user content in /home) that's it. That's all I need. Everything else is provided by packages and/or dynamically generated when various services and apps run. And that was _mostly_ because of the way the system was already designed, not because I hacked mine to be super portable & manageable. All I did was make use of the facilities and schemes that are already there just for this purpose. The things I had to hack were only 3rd party commercial software that barely supports linux at all let alone any particular distribution. So they come with install directions that are so crude as to not even work if you actually tried to follow them verbatim. But even they were just a matter of doctoring up installer, wrapper and start scripts. There are things like that kdmrc script that could be customized, but, "don't do that". Do it elsewhere. That script, or whatever reads it, probably already tries to source in something from elsewhere (/home, /etc) along the way, go edit that instead. That script is probably mostly for system level customization, ie, suse tweaks theirs different than ubuntu tweaks theirs, and neither is related to how a user tweaks theirs. If any user changable settings end up getting stored there, it's probably nothing that matters, no sticky notes or bookmarks, just last selected desktop, last login name used etc. I don't use kdm so it's possible it does store something that isn't utterly transient and insignificant there, but even in that unlikely case, it just means that's a candidate for improvement. It does not mean "There are configs and user files all over the place anyways so it's fine to write your own hand made files in /lib/foo" Reality does bite, but for every 1000 times reality might bite, 990 of theme are avoidable. So in reality, reality mostly only only bites when you let it. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org