----- Original Message ----- > From: "Steve French" <smfrench@xxxxxxxxx> > To: "Ronnie Sahlberg" <lsahlber@xxxxxxxxxx> > Cc: "Kenneth Dsouza" <kdsouza@xxxxxxxxxx>, "CIFS" <linux-cifs@xxxxxxxxxxxxxxx> > Sent: Friday, 29 June, 2018 3:04:08 PM > Subject: Re: Can we have cifsmount.conf? > > Some interesting points you make about hypothetical things that could > be included, and I hadn't thought about your point: > > > For module arguments, such as disable smb1 completely we already have > > /etc/modprobe.d > > but how would you persist settings for /proc/fs/cifs/* For those things that makes sense to persist we can have a policy that there must be a module option with the same name. Then if you want to make it persistent then you set foobar in /etc/modprobe.d/cifs.conf and it applies everytime you (re)load the module. If you just want to do some changes at runtime then you change them via /proc/fs/cifs/foobar ? > On Thu, Jun 28, 2018 at 11:59 PM Ronnie Sahlberg <lsahlber@xxxxxxxxxx> wrote: > > > > Are we mixing module arguments and mount options in the same mechanism, and > > should we? > > > > > > Module arguments are global in the sense that we only have a single > > instance of the module loaded into the kernel > > and its settings apply to all client connections and mounts. > > > > For module arguments, such as disable smb1 completely we already have > > /etc/modprobe.d and it should be sufficient? > > It is already persistent and it controls the arguments for loading the > > module. > > > > > > > > I see a hypothetical /etc/cifsmount.conf as orthogonal to this. This should > > not be about module arguments but rather > > mount options. Either global mount options or mount options that > > automatically apply (and override the user command line) > > on a per server or mountpoint basis. > > > > It could be used to say things like : > > * only allow SMB2+ mounts... (even if the module itself allows smb1) > > * use smb1 and posix for servers a/b/c... > > ... > > > > and mount.cifs would parse this file and add the arguments that were > > missing automatically. > > > > > > regards > > ronnie sahlberg > > > > > > ----- Original Message ----- > > From: "Steve French" <smfrench@xxxxxxxxx> > > To: "Kenneth Dsouza" <kdsouza@xxxxxxxxxx> > > Cc: "CIFS" <linux-cifs@xxxxxxxxxxxxxxx> > > Sent: Friday, 29 June, 2018 1:46:35 PM > > Subject: Re: Can we have cifsmount.conf? > > > > since there are only about 20 of the 90 cifs mount options that are > > needed for 99% of the cases this tool may not be that bad to create - > > and of course for extra-credit/bonus-points a GUI mount tool which > > exposes the smallest sane subset of mount options might be useful to > > some - and could also be added to cifs-utils > > On Thu, Jun 28, 2018 at 10:44 PM Kenneth Dsouza <kdsouza@xxxxxxxxxx> wrote: > > > > > > Thanks, I will take a look at the pre-existing code for > > > reference(nfs-utils and other). > > > > > > On Fri, Jun 29, 2018 at 8:12 AM, Steve French <smfrench@xxxxxxxxx> wrote: > > > > I think this is a reasonable idea - and nfs-utils's parsing for this > > > > config file (in mount.nfs e.g.) may be similar enough to smb3 > > > > requirements in some cases - but don't rule out the idea of seeing if > > > > anything is shareable/reuseable with Samba (to allow e.g. smbcacls or > > > > small client utilities to benefit from cifs.ko configuration and vice > > > > versa). In addition don't rule out the idea of writing small > > > > cifs-utils that allow sane setting of the text configuration file (ala > > > > "net conf <section> <keyword> <value>" or equivalent. One of the > > > > curses of many text config files is difficulty figuring out > > > > options/syntax etc. and making spelling mistakes so in a perfect world > > > > the user could set the config file values with an easy to use > > > > cifs-util tool (vaguely similar to "net conf ..." perhaps) > > > > > > > > If we allow setting the 5-10 module install parms and then the things > > > > configurable in /proc/fs/cifs/* ... we would need some way to load > > > > them on reboot. > > > > > > > > The nfs example may be useful but it is more focused on mount parms it > > > > seems rather than other config values. > > > > > > > > But if you want to pursue this it seems promising to investigate > > > > nfsmount.conf and whether there is something vaguely similar we could > > > > do for smb3 but ... I would prefer if along with that we had an easy > > > > to use tool to set the values and provide help on the valid options > > > > etc. (there may be a lot we can also learn by the way from other fs > > > > tools as models - e.g. "iostat" and "nfsiostat" if looking at these > > > > tools for other file systems) > > > > On Thu, Jun 28, 2018 at 9:35 PM Kenneth Dsouza <kdsouza@xxxxxxxxxx> > > > > wrote: > > > >> > > > > > > I agree we can have a cifs-conf command for example. This command > > > will help us retrieve mount settings and make changes directly to the > > > /etc/cifsmount.conf. > > > This will help us to only add valid options and avoid typos. > > > > > > >> > > > >> I was just wondering why we don't have a /etc/cifsmount.conf just like > > > >> /etc/nfsmount.conf for mount options. I would like to work on it, if > > > >> we can add this functionality. > > > >> Using this we can easily disable smb1. > > > >> > > > >> Regards, > > > >> Kenneth D'souza > > > > > > > > > > > > > > > > -- > > > > Thanks, > > > > > > > > Steve > > > > > > > > -- > > Thanks, > > > > Steve > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-cifs" in > > the body of a message to majordomo@xxxxxxxxxxxxxxx > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > -- > Thanks, > > Steve > -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
