Brian K. White said the following on 12/26/2011 06:42 PM:
Dynamically generated stuff doesn't matter. It is generated dynamically. ...you know...from configs, generally found in /etc.
Maybe it is, in some cases. But I don't think that is an assertion that can be universally applied.
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
I used the example of DNS. You may choose to put the information that is in the DNS in /etc/hosts as well and make your /etc/nsswitch look for files before using dns when resolving, but there are suppositions in that, most notably that everything in your DNS is in your hosts file. That may not be the case. It may be the case that you are acting as a secondary for another domain and that is updating the information in the chrooted area, /var/lib/named in my case, and that information is not, cannot be, derived from what's in my /etc/hosts. It may not even be in the /etc/hosts of the DNS server of the domain I'm acting as a secondary for. I realise that not everyone has arrangements for acting as a dns secondary, but it does illustrate my point. I'm sure that given time to dig I could come up with other examples where you need to backup other parts of the tree or where other parts of the tree have config that is not reconstructable from what's in /etc. And I think that just because there is a symlink from /etc/<somehwere> to the actual config data in /srv or /var doesn't validate your point.
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.
Some of that's your decision. My decision is to use KDE and KDM an that means I'm living with kdmrc in /usr/share. Can you tell me that there are no symlinks under /etc/ on any of your systems that lead to /var, /use or /svc? This is why I asked about your backup method.
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.
BTDT and I hate it and do what I can about it. Like when I back up /etc I make sure that I *AM* following symlinks. I also take dumps of the RPM database so I know what I have installed, but that database doesn't live in /etc does it? In an ideal world I could freeze /etc (and /bin and /sbin and more) by having the rootfs ro, and seperate /var, /svc, /home and swap fs. You can't do that with Windows because of the way the registry is implemented. And that's why some things that need to be dynamic are in /var. OK, so its impractical; how would I add users? Hosts? Well, there's LDAP, and guess where the LDAP database with the list of users lives? If not in /var then off on another machine :-)
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.
Ah, so what you're saying is that in the case of something like KDM, where I have to live with kdmrc being in /usr/share you would down load the source, change the source so that kdmrc now lives in /etc/, recompile and rebuild the package and run with this new package. Well that's one way of getting around the problem.
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.
No doubt you can do the reverse of what is in /etc right now. You can create the config in /etc and have a symlink from where the 3rd party software expects it to be back to the real file under /etc.
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?
Ah, many questions. Symlinking a directory is not good practice, its very inflexible. But one way of viewing it is yes, there are directories under /etc/systemd/system that contain nothing but symlinked files. Try running find -P /etc/systemd/system -type f -print to see what files are NOT symlinked. As for dedicated .. well the man page mentions Packages that want to install unit files shall place them in the directory returned by pkg-config systemd --variable=systemdsystemunitdir It also says Packages should alter the content of these directories only with the enable and disable commands of the systemctl(1) tool What directories? Well the one returned by the pkg-config command and ... Other directories checked are /usr/local/share/systemd/system and /usr/share/systemd/system. It then says, rather confusingly User configuration always takes precedence. The best I can make of that is that there is also /etc/systemd/user but nothing seems to be there. There is no /lib/systemd/user is there?
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.
The main problem I see people having with SystemD is not reading the man pages and not googling for what is written about it.
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.
I agree, but that doesn't mean you should create security exposures or fail to back up user generated and dynamic data. In the limiting case, one cold argue, that given the installation CD and what's in /etc, such as the list of repositories, you don't need to back up anything except /home and /srv. If you loose your system you can get a new one, a new disk, install from the CD, slap on the old /etc and /home and do a zypper update. Well jolly good luck to you. I'll take more complete backup and be "back up" in a fraction the time. Because for a lot of businesses, "time is money". Of course offloading services, DNS, DHCP, LDAP, database ... means you only have to backup elsewhere, and using the snapshot mechanism of LVM makes backups a lot easier. Snap! Now image that to a DVD. Easy. Fast.
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.
Um, this is the bit that does the login, so it simply cannot do anything with a specific user's home. Think about it.
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.
I can't comment on that; I only have RPM-based system, uses, fedora, mandriva. But on those systems, the kdmrc file defines what the login screen looks like, the background, position of the login prompts and more.
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.
A LOT about the configuration of the login process gets stored there! Go look, or google ... http://slackware.osuosl.org/slackware-10.0/source/kde/kdebase/config/kdmrc
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.
Take it from me or read the above; there's a lot in there. But yes, it could well be under /etc and on my fedora system there is a /etc/kde/kdm/kdmrc The irony is that there is a /usr/share version as well. And when I look at the binary, /usr/libexec/kde4/kdm_config, which is the part of kdm that reads the config, it references /usr/share/config/kdm/kdmrc and /var/lib/kdm. There is no mention of /etc. Previous user lives in /var/lib/kdm/kdmsts : :::::::::::::: [PrevUser] :0=anton So iyts a case of could be ... should be ... but isn't really.
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"
I didn't say that. I didn't say anything like that. I didn't say anything that implied that. At worst, I said "In an ideal world". I said that I have to live with a reality that isn't the ideal world. I never advocated such arbitrariness. I'd love to see all config in /etc and all chrooted stuff well documented. I could then write perl scripts to parse all that and automated more and more of sysadmin :-)
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.
Not all of us are able - or have the time out - to re-package and hack away. What we should do is put pressure on the developers to clean up their practices. -- The bitterness of poor quality lingers long after the sweetness of meeting schedules is forgotten. --Kathleen Byle, Sandia National Laboratories -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org