I think I understand the immediate goal here, but I am still confused.
What is the objective of achieving this "boot with empty /etc"? What
does it accomplish? What problem does it solve? Is it a solution for a
small use case such as containers or something else? What problem does
it solve for me - a sysadmin with a few servers and some workstations?
If the answer is in one of the early bits of this thread, could you
point me to it please?
Thanks!
--
*********************************************************
David P. Both, RHCE
He/Him/His
*********************************************************
www.both.org - My personal web site
www.Linux-Databook.info - Home of the DataBook for Linux
DataBook is a Registered Trademark of David Both
*********************************************************
The value of any software lies in its usefulness
not in its price.
— Linus Torvalds
*********************************************************
On Mon, 11 Dec 2023, Zbigniew Jędrzejewski-Szmek wrote:
Date: Mon, 11 Dec 2023 08:35:08
From: Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx>
Reply-To: Development discussions related to Fedora
<devel@xxxxxxxxxxxxxxxxxxxxxxx>
To: Florian Weimer <fweimer@xxxxxxxxxx>
Cc: Development discussions related to Fedora <devel@xxxxxxxxxxxxxxxxxxxxxxx>
Subject: ####SPAM#### (302.2) Re: goal: booting with an empty /etc
On Mon, Dec 11, 2023 at 09:58:04AM +0100, Florian Weimer wrote:
* Zbigniew Jędrzejewski-Szmek:
No, it would be the other way round. We might have a
/usr/share/glibc/services which contains :include: /etc/services
somewhere in it.
Ah, OK. I understand how the format would look, but I don't understand
why you'd want to implement it rather than something simpler.
/etc/services is essentially a flat file that is scanned from top to
bottom until a matching entry is found. In the proposed syntax, it'd
need to have ':include: /etc/services' at the very top, so that the local
config in /etc/services has higher priority.
Consider the following alternative: each of [/etc/services,
/usr/etc/services] is scanned in order, if the file exists. This is
simpler to implement and allows either of the files to exist
independently of the other. A stanza like ':include:' also opens the
door for additional complications like different paths on different
distros and include loops. It is _possible_, but the simpler scheme
has the properties that we want.
I want to replace nss_wrapper with a simple set of environment
variables. Once we have a multi-file search path, it's no longer so
simple because it's not clear if the default search path is amended or
replaced when the environment variable is set.
nss_wrapper currently fully overrides the system config. I think it'd
be reasonable to keep that behaviour. But anyway: having to make that
choice here is not a great argument against having multiple files, we
just have to remember about the issue and implement and document one
of the possibilities, whatever makes the most sense.
Loop detection on traditional file systems wouldn't be very difficult to
implement, except that we increasingly have file systems which have
dev_t/ino_t values that are not unique. But that impacts any form of
loop detection, so I'm not overly concerned.
Yes, it certainly _can_ be done…
The systemd-style drop-in mechanism works well and is at this point widely
documented and understood. We also have cases where alternative mechanisms based
on 'include' were implemented, and, at least in my opinion, they have proven to
work less well. (E.g. sshd, sudo).
Anyway, I think that at this point the technical arguments have been laid out,
and we're down to questions of style. I _like_ the proposal with a fixed set of
file paths better, but I'd be happy to take the version with include directives
too, if it means we move some files out of /etc.
Zbyszek
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
