Hi,
On Sun, Jun 09, Christian Boltz wrote:
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?
We are already working on that ;)
https://github.com/parlt91/libeconf
/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.
https://github.com/thkukuk/atomic-updates_and_etc/blob/master/README.md#etc…
I created a PoC for this already. The glibc NSS plugin was easy, but
adjusting all tools to be able to change the password or other data
(chfn, chsh, ...) is pretty much work. And the worst is, it does not
even solve any of our problems on systems with transactional-updates.
You would still use an UID or GID twice.
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 ...
Correct.
- 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)
I'm not that sure. We did already some changes for MicroOS only
in the past (like moving from cron to systemd.timer, and suddenly
everybody was modifying his packages, too.
But yes, it will take a long time and I'm pretty sure some applications
will never be adjusted.
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 see a real problem with /etc/alternatives, it's in the end
user configuration. Yes, it's not strictly seperated into system defaults
and user changes, but in the end, that's defined by the database.
At least I haven't found yet update problems with it.
But a real problem with update-alternatives is /var
There, we really mixed up everything and this does currently not work
with transactional-updates (not even really with snapshots and rollback).
Thorsten
--
Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg)
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org