9 Jun
2019
9 Jun
'19
1:25 p.m.
Hello,
(sorry for being late, the last week was completely busy/crazy here)
Am Montag, 3. Juni 2019, 13:50:55 CEST schrieb Thorsten Kukuk:
Application configuration files:
Do something similar to what systemd is already doing today (See
https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Exa
mples, "Overriding vendor settings"). Put the default, by a Linux
distributor shipped configuration files somewhere below /usr, and
/etc only contains the overwrite.
I like that idea, and if it means that more applications start to
support config file includes and whatever.d/* sniplets, I like it even
more ;-)
Even if implementing that config file handling probably isn't too hard -
would it make sense to develop a library to read all the config sniplets
and merge them?
Maybe it could be based on the systemd code, but should be a standalone
project to avoid another dependency on systemd, and to avoid that every
project has to re-invent this wheel. Oh, and in the end, systemd could
use that library ;-)
System databases:
This are files in /etc like rpc, services and protocols.
We can put them somewhere below /usr, and /etc/ only contains the
changes. A glibc NSS module could merge them automatcially, different
implementations do exist already today for this.
Sounds solvable with *.d/* files ;-)
/etc/passwd, /etc/group and /etc/shadow:
This is the big, open problem. We looked at many possible solutions,
but didn't found the real, generic one.
These could be done via passwd.d/* etc. - either one file per user with
username == filename (cleanest solution, but probably not the best idea
when it comes to performance) or sniplets with as many lines as make
sense for that file(name), with a "last one wins" policy.
Note: system users don't come with guaranteed static uids, so packages
will still need to run useradd in %post. Packaging a passwd.d/$username
file won't work.
Please avoid LDAP or other complex solutions. If a system is broken, you
really want to have something you can fix with $EDITOR from a recovery
system ;-)
So, what is the expected outcome of this mail?
1. We need to agree, if we want to solve the problem or not
In my opinion, there is no real choice, if we don't do it
coordinated as Linux distributor, this will happen in a chaotic
way.
Agreed, we should do this, and should coordinate it with all distros,
FHS and the upstream projects.
2. We need to agree on the goal, so for me, this would
be:
- short term: solve the problem for packages on openSUSE MicroOS
- mid term: solve the problem for openSUSE Tumbleweed
I'd sum this up as "moving the default config to /usr/ will be an
incremental and ongoing effort" (with a priority on packages included in
MicroOS), and ...
- long term: /etc/ only contains admin created
files, a Linux
Distribution does not install there anything
... this one is really a long term goal ;-) (years, not months)
3. We need to agree on a path below /usr for the
default configuration
files
I don't have a strong preference, but so far /usr/share/defaults/ and
maybe /usr/etc/ look best to me. (If existing applications already use
different directories for their default config files, they should move
to the standardized directory sooner or later.)
The layout inside /usr/share/defaults/ should exactly mirror the layout
in /etc/.
Your comments and feedback?
I like the idea :-)
Just in case you want to make your TODO list a bit bigger ;-) - I just
noticed that you didn't look at /etc/alternatives/ yet.
Currently we have several /usr/bin/whatever, /usr/share/man/whatever
symlinks pointing to /etc/alternatives/ - we'll need to find a solution
for that too.
(I don't have a good solution for that - symlinks don't support
fallbacks, and letting update-alternatives change the symlinks in /usr/
is also a bad idea. Nevertheless, I wanted to make sure you have this on
your radar.)
Regards,
Christian Boltz
--
It's hard to learn how to ride a bike on the road while watching
someone else do it from the sidewalk sitting on your trike :)
[David C. Rankin in opensuse-factory]
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org