Mailinglist Archive: opensuse-factory (602 mails)

< Previous Next >
Re: [opensuse-factory] [PLEASE SPEAK UP] Disabling legacy file systems by default?
On Thu, 2019-01-31 at 15:50 -0800, Mark Yen wrote:

Apologies for butting in, but I think this can be slightly simpler.

If the blacklist entries are in /lib/modprobe.d instead, then the
overrides can just be matching files in /etc/modprobe.d (symlink to
/dev/null is fine). This way, the blacklists can be shipped as-is in
the rpm, with the %post script dropping in new symlinks for things
that
are in use (if they don't already exist). Future updates will not
need
to worry about overwriting things (because we never care about
modifications to files in /etc).

If an admin wants to re-blacklist a module that was automatically
un-blacklisted, they can copy the file from /lib to /etc (or
symlink).

This is basically the same mechanism that udev and systemd uses,
according to what looks like the commit that added this
functionality¹.

Thanks for your thoughts. I've considered this, and actually started
out this way. It's "cleaner", because distribution-installed files
belong in /lib, not /etc. We would have done it this way if we didn't
consider automatic un-blacklisting of loaded filesystem modules (IOW,
if we didn't take the responsibility to try and avoid making systems
unbootable).

However, _with_ the automatic un-blacklisting in %post, it doesn't go
together well. Here's why:

As you already noted, an empty file or symlink to /dev/null is
sufficient to override a file from /lib/ in /etc/. Therefore we can't
include the /etc/ files in the RPM package, not even as %ghost files
(which would result in 0-byte files, overriding all blackisting). Thus,
the /etc/modprobe.d files would be orphans in the file system, and if
suse-module-tools was ever uninstalled, they'd continue to lurk in
/etc/modprobe.d. No big harm done, but highly unclean. It'd be
acceptable for user-generated overrides, but for files generated in a
%post script, I find it untolerable. The only way to make this work
would have been to _always_ generate the files under /etc, with
"blacklist xyzfs" either commented out (for loaded modules) or not (for
everything else). But if we do that, having the same files under /lib
once more would be utterly pointless (*).

This is how I arrived at the conclusion that it's better to install the
files under /etc, and modify them in place. The logic is similar to
what we do with the "unsupported modules" flag in SLES. It has the
additional benefit that "rpm -V suse-module-tools" quickly shows which
files have been un-blacklisted (only approximately if the user also
changes stuff, but still useful).

Regards
Martin

(*) Actually user-unfriendly, because users might think that simply
removing the blacklist file under /etc/modprobe.d would un-blacklist a
module, which is false if another blacklist file exists under /lib.

--
Dr. Martin Wilck <mwilck@xxxxxxxx>, Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)


--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >