On 11/25/2013 4:15 AM, Andreas Schwab wrote:
"Brian K. White"
writes: If the real info is stored somewhere under /etc, and only a copy is generated on the fly in a jail somewhere else, that is fine.
That won't work if the service is able to change its config files on the fly.
Andreas.
If the service needs to do that, then the start script needs to capture and replicate those changes back in /etc. What service does that anyways where the changes are actually supposed to survive restart? I know isc-dhcpd stores leases which are run-time changes that are preserved across stop-start of the service. But they don't actually matter, it's just a cache and a mild convenience for the clients. If I back up /etc and restore it on a new machine, the chroot dhcpd works exactly as I had previously configured even though it had to repopulate /var/run on the fly on the new machine. The only config file I ever manually edit is in /etc. The config file the daemon reads is in /var/run but it is copied and updated automatically. Same for vsftpd. The real config files are in /etc and /etc is the only thing I ever edit, and when I back up /etc I get everything that matters for a new machine. To be clear, I'm not saying I blindly restore an entire /etc on a new machine. I might if I knew the new machine was the exact same version of suse and had the exact same package list installed, but no I manually pull the important files that I know I need. You need to be able to back up /etc and know that you actually got everything that matters. And backing up the entire server is impractical. Consider the case of, instead of a simple copy backup, you have cvs/svn/git version control your /etc so you can roll back or examine any prior state in history. You can do that easily for /etc, which is supposed to hold mostly just a lot of config data and scripts, and not a lot of binary data, databases, executables, images*. It's fast and efficient, and very valuable, to keep a full version control history of that forever, but not the entire server. * On a normal desktop system there IS these days a fair amount of fat in /etc but I'm not saying /etc actually attains the ideal, merely saying what the ideal is we should be aiming for and why. In fact it used to attain that ideal pretty well, it has regressed over the years but not intolerably. On servers with no gnome or kde installed it's still pretty good. # du -sh /etc 8.8M /etc # tar cj /etc >/tmp/x # du -h /tmp/x 1.5M /tmp/x -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org