Mailinglist Archive: opensuse (1698 mails)

< Previous Next >
Re: [opensuse] Re: starting the virtualbox virtual machines automatically
Brian K. White said the following on 12/26/2011 06:42 PM:

Dynamically generated stuff doesn't matter. It is generated dynamically. 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

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

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

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
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

I can't comment on that; I only have RPM-based system, uses, fedora,

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 ...

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

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

Previous user lives in /var/lib/kdm/kdmsts :

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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups