Friday, 29 May 2020

Re: Adjusting what fstypes df displays

On Fri, May 29, 2020 at 10:54:40PM +0000, Seth Arnold wrote:
> On Thu, May 28, 2020 at 09:38:47PM -0700, Bryce Harrington wrote:
> > For Ubuntu, DF_EXCLUDE_FSTYPES could be set in the global profile (under
> > /etc/profile.d/ perhaps?) This would make it straightforward to add
> Many thanks for working on this, df output has been annoying me for quite
> some time (but I dislike shell aliases even more).
> Properly threading an environment variable into a given process is
> surprisingly difficult. /etc/profile.d/ is read by bash, and other
> shells that choose to use these startup files. /etc/environment is
> used by any PAM service that has pam_environment configured and
> systemd-environment-d-generator(8) for systemd user manager instances.
> These may not cover all instances where users would like it to. And,
> ironically, even though it doesn't cover everything, it would be in the
> memory of many processes that may never call df. It's not like it's a
> huge amount of memory, but it is something.
> Different tools like sudo, su, systemd-nspawn, lxc exec, etc may
> further complicate getting an environment variable through from where a
> human is interacting with the system to where df is executing.
> So, I'd like to propose using the typical systemd-style configuration file
> approach instead:
> Package defaults in:
> /lib/something/coreutils/df.conf or
> /usr/lib/something/coreutils/df.conf
> Sysadmin configuration in:
> /etc/something/coreutils/df.conf
> User configuration in:
> XDG_SOMETHING_CONFIG/coreutils/df.conf
> or
> /run/uid/something/coreutils/df.conf
> Yes, it's exhausting to implement the functionality for all this compared
> to the simplicity of a getenv() or secure_getenv(), but filesystem access
> is more predictable than environment variables from parents to children
> and will likely work closer to expectations across chroot, schroot, lxd,
> etc uses.
> If we ever want to change the package defaults, then any local admin
> choices already made could continue to be respected.
> Thanks

Thanks for the feedback Seth.

I haven't seen other examples of config file use elsewhere in coreutils,
which was one reason I went with an env var for this POC.

I'll bring your points forward when I present to upstream, and if they
also like the conf file approach better, I can reimplement it that way.
Is there another GNU package (in C) that implements a systemd-style
config file approach that you'd recommend to use for reference?


ubuntu-devel mailing list
Modify settings or unsubscribe at: