config files and how to have persistent Linux kernel Driver/File System configuration info saved

config files and how to have persistent Linux kernel Driver/File System configuration info saved

[Steve French]

Ronnie brought up an interesting point about the problems consistently
configuring file systems (or any Linux module for that matter) so that
reboot doesn't wipe away security or performance tuning changes.

Linux file systems typically allow configuration via various ways (I
may have left some out) for example:
- module load parameters (modprobe etc. e.g. for cachefs
"deferecreate" or "deferlookup" can be configured, as can various
parms in the nfs or cifs/smb3 modules)
- Settings via /proc/fs/ or /sys/fs (e.g. /sys/fs/ext4/features)
- Settings via mount parms

Other than /etc/fstab which is fairly limited,  AFAIK the only file
system that has persistent configuration in text files is nfs - which
allows a limited number of mount related settings to be set to
defaults via nfsmount.conf

Are there good examples of either text based configuration of Linux
kernel (preferably file system drivers) e.g. something vaguely like
/etc/btrfs or an /etc/xfs to set default security or performance
related parameters consistently over reboot of machine, or even better
something vaguely like Samba's "net conf" tools for setting
keyword=value for various types of settings in a somewhat safer way
(in a registry, which in Samba's case is cluster safe, and fairly
robust)

What is the recommended way to persist configuration settings for
Linux drivers across reboot?

-- 
Thanks,

Steve

Re: config files and how to have persistent Linux kernel Driver/File System configuration info saved

[Theodore Y. Ts'o]

On Thu, Jun 28, 2018 at 05:37:15PM -0500, Steve French wrote:
> Ronnie brought up an interesting point about the problems consistently
> configuring file systems (or any Linux module for that matter) so that
> reboot doesn't wipe away security or performance tuning changes.

In general it's considered best practice to make the file system
auto-tune itself as much as possible, because the sad fact is that
99.9999% of the customers aren't going to bother to add any tuning
parameters.  So there hasn't been a push to try to create something
more complex, because it's generally not needed.

Settings via /sys/fs/ext4 are generally for developers as they try to
understand how things work, so they can improve the file systems
defaults / auto-tuning algorithms.

						- Ted

Re: config files and how to have persistent Linux kernel Driver/File System configuration info saved

[ronnie sahlberg]

On Fri, Jun 29, 2018 at 8:58 AM, Theodore Y. Ts'o via samba-technical
<samba-technical@lists.samba.org> wrote:
> On Thu, Jun 28, 2018 at 05:37:15PM -0500, Steve French wrote:
>> Ronnie brought up an interesting point about the problems consistently
>> configuring file systems (or any Linux module for that matter) so that
>> reboot doesn't wipe away security or performance tuning changes.
>
> In general it's considered best practice to make the file system
> auto-tune itself as much as possible, because the sad fact is that
> 99.9999% of the customers aren't going to bother to add any tuning
> parameters.  So there hasn't been a push to try to create something
> more complex, because it's generally not needed.

True, but in these cases I think we are more looking at server or
mountpoint specific options than
actual fs tuning.

For example nfsmount.conf can be used to say "only use NFSv4 when
accessing server abc" etc.
For the case of CIFS I could imagine that an administrator might want
to set "disable smb1 protocol globally"
etc.

>
> Settings via /sys/fs/ext4 are generally for developers as they try to
> understand how things work, so they can improve the file systems
> defaults / auto-tuning algorithms.
>
>                                                 - Ted
>

Re: config files and how to have persistent Linux kernel Driver/File System configuration info saved

[Steve French]

On Thu, Jun 28, 2018 at 6:21 PM ronnie sahlberg
<ronniesahlberg@gmail.com> wrote:
>
> On Fri, Jun 29, 2018 at 8:58 AM, Theodore Y. Ts'o via samba-technical
> <samba-technical@lists.samba.org> wrote:
> > On Thu, Jun 28, 2018 at 05:37:15PM -0500, Steve French wrote:
> >> Ronnie brought up an interesting point about the problems consistently
> >> configuring file systems (or any Linux module for that matter) so that
> >> reboot doesn't wipe away security or performance tuning changes.
> >
> > In general it's considered best practice to make the file system
> > auto-tune itself as much as possible, because the sad fact is that
> > 99.9999% of the customers aren't going to bother to add any tuning
> > parameters.  So there hasn't been a push to try to create something
> > more complex, because it's generally not needed.
>
> True, but in these cases I think we are more looking at server or
> mountpoint specific options than
> actual fs tuning.
>
> For example nfsmount.conf can be used to say "only use NFSv4 when
> accessing server abc" etc.
> For the case of CIFS I could imagine that an administrator might want
> to set "disable smb1 protocol globally"

Or perhaps
  "disable smb1 on " ... various public networks but allow it on
private networks

-- 
Thanks,

Steve

Re: config files and how to have persistent Linux kernel Driver/File System configuration info saved

[Dave Chinner]

On Thu, Jun 28, 2018 at 06:24:59PM -0500, Steve French wrote:
> On Thu, Jun 28, 2018 at 6:21 PM ronnie sahlberg
> <ronniesahlberg@gmail.com> wrote:
> >
> > On Fri, Jun 29, 2018 at 8:58 AM, Theodore Y. Ts'o via samba-technical
> > <samba-technical@lists.samba.org> wrote:
> > > On Thu, Jun 28, 2018 at 05:37:15PM -0500, Steve French wrote:
> > >> Ronnie brought up an interesting point about the problems consistently
> > >> configuring file systems (or any Linux module for that matter) so that
> > >> reboot doesn't wipe away security or performance tuning changes.
> > >
> > > In general it's considered best practice to make the file system
> > > auto-tune itself as much as possible, because the sad fact is that
> > > 99.9999% of the customers aren't going to bother to add any tuning
> > > parameters.  So there hasn't been a push to try to create something
> > > more complex, because it's generally not needed.
> >
> > True, but in these cases I think we are more looking at server or
> > mountpoint specific options than
> > actual fs tuning.
> >
> > For example nfsmount.conf can be used to say "only use NFSv4 when
> > accessing server abc" etc.
> > For the case of CIFS I could imagine that an administrator might want
> > to set "disable smb1 protocol globally"
> 
> Or perhaps
>   "disable smb1 on " ... various public networks but allow it on
> private networks

The way the policy is configured depends on the mechanism used to
configure the policy. If it's a sysctl or a mount option, then we've
already got everything we need. If it's something dynamic in sysfs,
then I think you're on your own.

FYI, I have been looking at making sysctl be able to work on /sys
rather than just /proc/sys (I have a 10 line hack to enable it) so
we could re-use it with custom per-mount error config files in
/etc/xfs/ for XFS that we inject based on a uevent delivered to
udev. It works, but the fact is modifying sysctl in this way exposes
it to a whole bunch of stuff sysctl doesn't understand, shouldn't be
accessing and/or trying modify. i.e. sysctl is disturbingly dumb,
and it gets away with it because of it's restricted scope and API
presented by /proc/sys.

So, really, I'm probably just going roll our own sysfs config file
mechanism into xfs_spaceman (probably based on the new config file
parser we have for mkfs.xfs) and hide the mess with a nice, simple
xfs_admin interface for udev to call. i.e. roll our own :)

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: config files and how to have persistent Linux kernel Driver/File System configuration info saved

[Steve French]

On Thu, Jun 28, 2018 at 11:44 PM Dave Chinner <david@fromorbit.com> wrote:
>
> On Thu, Jun 28, 2018 at 06:24:59PM -0500, Steve French wrote:
> > On Thu, Jun 28, 2018 at 6:21 PM ronnie sahlberg
> > <ronniesahlberg@gmail.com> wrote:
> > >
> > > On Fri, Jun 29, 2018 at 8:58 AM, Theodore Y. Ts'o via samba-technical
> > > <samba-technical@lists.samba.org> wrote:
> > > > On Thu, Jun 28, 2018 at 05:37:15PM -0500, Steve French wrote:
> > > >> Ronnie brought up an interesting point about the problems consistently
> > > >> configuring file systems (or any Linux module for that matter) so that
> > > >> reboot doesn't wipe away security or performance tuning changes.
> > > >
> > > > In general it's considered best practice to make the file system
> > > > auto-tune itself as much as possible, because the sad fact is that
> > > > 99.9999% of the customers aren't going to bother to add any tuning
> > > > parameters.  So there hasn't been a push to try to create something
> > > > more complex, because it's generally not needed.
> > >
> > > True, but in these cases I think we are more looking at server or
> > > mountpoint specific options than
> > > actual fs tuning.
> > >
> > > For example nfsmount.conf can be used to say "only use NFSv4 when
> > > accessing server abc" etc.
> > > For the case of CIFS I could imagine that an administrator might want
> > > to set "disable smb1 protocol globally"
> >
> > Or perhaps
> >   "disable smb1 on " ... various public networks but allow it on
> > private networks
>
> The way the policy is configured depends on the mechanism used to
> configure the policy. If it's a sysctl or a mount option, then we've
> already got everything we need. If it's something dynamic in sysfs,
> then I think you're on your own.
>
> FYI, I have been looking at making sysctl be able to work on /sys
> rather than just /proc/sys (I have a 10 line hack to enable it) so
> we could re-use it with custom per-mount ...
<snip>
> So, really, I'm probably just going roll our own sysfs config file
> mechanism into xfs_spaceman (probably based on the new config file
> parser we have for mkfs.xfs) and hide the mess with a nice, simple
> xfs_admin interface for udev to call. i.e. roll our own :)

Since we don't really have a registry, or equivalent (unless Samba is
installed),
probably will have to do something like that for other file systems too :)
Am now thinking that we need an "smb3_admin" (or "cifs_admin") tool,
ala Samba's "net" (especially "net  conf setparm <section> <parameter> <value>")
because it makes it possible to configure the ultra-confusing /etc config files
and /proc and /sys config pseudo files more sanely and less error prone.



-- 
Thanks,

Steve