Re: [iproute2 00/22] Support for stateless configuration (read from /etc and /usr)

[Petr Machata <petrm@nvidia.com>]

Gioele Barabucci <gioele@svario.it> writes:

> On 19/07/23 23:36, Stephen Hemminger wrote:
>> On Wed, 19 Jul 2023 20:50:44 +0200
>> Gioele Barabucci <gioele@svario.it> wrote:
>> 
>>> this patch series adds support for the so called "stateless" configuration
>>> pattern, i.e. reading the default configuration from /usr while allowing
>>> overriding it in /etc, giving system administrators a way to define local
>>> configuration without changing any distro-provided files.
>>>
>>> In practice this means that each configuration file FOO is loaded
>>> from /usr/lib/iproute2/FOO unless /etc/iproute2/FOO exists.
>> I don't understand the motivation for the change.
>
> The main, but not the only, motivation for stateless systems is explained in
>
> https://clearlinux.org/features/stateless
> https://fedoraproject.org/wiki/StatelessLinux
> https://summit.debconf.org/debconf15/meeting/276/stateless-cloud-friendly-debian/
>
> In a nutshell: to better support factory resets, shared read-only base systems, containers & Co, all
> software should work even without /etc.
>
> A nice side effect of adopting stateless-style configuration (read from /etc, fallback to /usr) is
> that it allows for distro-provided files to be strictly read-only, avoiding a bunch of common
> failures during updates and upgrades (Debian spends a huge amount of resources to correctly handle
> these so called "conffiles". The fewer, the better.)
>
>> Is /etc going away in some future version of systemd?
> This is unrelated to systemd, although systemd is probably the most well known software that uses
> this pattern.
>
>> Perhaps just using an an environment variable instead of hard coding
>> /etc/iproute2 directory.
>
> Build-time or run-time env variable?
>
> I'd say that run-time env variables (a là XDG Base Directory) are kind of hard to deal with in a
> command like `ip` that is often invoked via `sudo` (that filters and changes env in complex ways).
>
> BTW, I strongly suggest to just go with this common pattern that is now known to all sysadmins
> instead of inventing an ad-hoc way to move the default configuration away from /etc.
>
>> I do like the conslidation of the initialize_dir code though.
>
> Thanks. :)
>
> Regards,

OK, I looked at a couple bits, and the code looks reasonable overall.
I'll wait for resolution of this discussion before doing full formal
review, so as not to waste effort unnecessarily.