On 11/13/2016 07:40 AM, Jeff Layton wrote: > On Fri, 2016-11-11 at 09:17 +1100, NeilBrown wrote: >> On Fri, Nov 11 2016, Jeff Layton wrote: >> >>> On Thu, 2016-11-10 at 15:58 +1100, NeilBrown wrote: >>>> As nfsdcltrack is normally run directly from the kernel >>>> there is no opportunity to change the default >>>> storage directory. This can be useful in a cluster to >>>> locate the "storage directory" on shared storage. >>>> >>>> The easiest alternative is to allow configuration to be read from a >>>> file, particularly as nfs-utils already has code for parsing a config file. >>>> >>>> So read the config file "/etc/nfs.conf" (or as set by ./configure) and >>>> look for "storagedir" and "debug" in the "nfsdcltrack" section. >>>> These values can still be over-ridden by command line options. >>>> >>>> A generic name (nfs.conf) was changes for the config file so that >>>> other daemons can be enhanced to read configuration from there. >>>> This may be easier than passing command line arguments through systemd. >>>> >>> I like the basic idea, but I'm not so sure we want to use a generic >>> config file like this. What else do you envision using this file? >> See https://lwn.net/Articles/584373/ and surrounds (included where I >> said that I wouldn't be providing patches:-). Yeah the systemd folks have been asking for something like this for a while. >> >> I'm not happy with current mechanisms for passing configuration from a >> configurator gui, through systemd, to various daemons. Having a common >> config file, rather having to stitch together command-line args, feels >> like it might be a step in the right direction. Given that I was adding >> a config file, I thought that leaving it open-ended might be a good >> idea. I agree... A configuration file is better than command line arguments.. >> >> We already have /etc/nfsmount.conf and /etc/idmapd.conf. >> How many more do we want? >> I note that that idmapd.conf contains Pipefs-Directory. Various >> other daemons need to know where that is. Wouldn't it be nice if they >> all read the one config file? Yes. Having one file to configure both sides wold be nice. And having a common way to change/edit that file would be good too... IMHO.. >> >> I haven't resolved in my mind where the "impedance matching" should >> happen. To explain: >> Different distros put their configuration in different places >> (/etc/sysconfig/nfs /etc/defaults/nfs) and use different names for the >> same value. These files are all "name=val" files, without the [section] >> headings of conf files. >> What is the best way to get the config from there to the local variables >> inside the various programs? >> >> Currently a systemd service runs a script which reads the configuration >> file and writes out an environment file for systemd to read, which >> provides command-line args for each daemon. I'd rather something more >> direct. >> >> If the parsing of /etc/nfs.conf allowed >> name=$var >> to extract 'var' from the environment, then (almost) each distro >> could have a static /etc/nfs.conf which listed which configuration >> variables affected which settings. Then systemd could read the >> original configuration file to set up the environment, then each tool >> would read /etc/nfs.conf to extract the desired parts of the environment. +1 >> >> Except that wouldn't work for nfsdcltrack as we cannot easily control >> it's environment. And there would probably be other things that didn't >> quite work right. > That could be remedied though it would take code changes in nfsdcltrack. A lot of daemons would need this kind of updates. > >> Maybe the best thing is for the configurator-gui to be required to run >> some post-processing thing which creates /etc/nfs.conf. >> Then of course, it could just create systemd drop-in files which >> created all the required arguments - then tells systemd to re-read those >> files. So maybe this is only useful for programs that aren't run via >> systemd. This first thing I thought of as well. Have GUI based configuration create the file but i think the first step is have a static file for now... >> >> I'm as yet far from certain as to what I want, but keeping things >> extensible seems like a generally good principle. >> > Agreed. ditto > >>> >>> That said, if we are going to do this, we should probably make it clear >>> that it's for server-side configuration. Maybe "nfsd.conf" or >>> "nfs-server.conf" would be a better name? >> Why only server-side? rpc-gssd needs configuration too. It and >> svcgssd (where used) are needed on both server and client (for >> NFSv4.0). >> > I was thinking that we already had nfsmount.conf, so making this about > server-side configuration would be more intuitive for users. You do have > a good point about rpc.gssd though. I think having a single configuration file for both side is the way we should go... > > Regardless, I do applaud the idea making the setup of NFS clients and > servers less "fiddly". Once you get beyond a very basic setup, > administering NFS as a service (client or server) is rather difficult > today. > > Transitioning to a more unified configuration scheme seems like it would > be good. Maybe we could even come up with a way to subsume nfsmount.conf > as well? > Exactly... Or those files could be generated from the one configuration file... A couple concerns: - Precedence, will command argument still override what is in he configuration file? With nfsmount.conf the precedence is command line overrides config file which overrides the defaults - Migration, how did we make it know that the variables in one file are no longer used or will be over written by another file? - a common and safe way to edit the file?? steved. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
