Created attachment 395020 [details, diff] netmount init.d script patch History: ~2 years ago, netmount from openrc tried to handle mounting of nfs shares, but it couldn't properly handle it due to multiple other init scripts being needed to start first. At that time, is was decided to split nfs mounting out into an init script in the nfs-utils package which could handle the proper starting of the services. Fast forward to openrc-0.13. Openrc now (again) will try to mount nfs shares and fail, and nfs-utils has removed the nfsmount script. Current intention as I see it: OpenRC is a cross distro init system which should have no deps on anything outside of OpenRC. nfs-utils adds "nfsclient" init script which must be added to the same run level as netmount and things work smoothly. Issues: Scenario 1: new user, wants to mount nfs shares. Adds entries to /etc/fstab, but they fail because only netmount is in the default run level and "nfsclient" is required to start as well. User must google and hope they hit "http://wiki.gentoo.org/wiki/NFSv4#Client" to learn that you need to start two services for the mount to work properly. Scenario 2: (my personal scenario) user on a laptop, doesn't have network access all the time. users may choose to remove netmount from the default (since network access isn't always available) and start it only when needed. Once the user connects to a network where they would like to mount their nfs shares, the user starts netmount which will fail, and must use google and hope they hit "http://wiki.gentoo.org/wiki/NFSv4#Client" to learn that now they user must start two services for netmount to actually work. The problem here appears very very simple to me. If a user has nfs mounts, netmount alone cannot do the job, and if the user runs netmount, it will fail. There seems to be no reason why netmount has to fail, as openrc contains the super helpful tool "fstabinfo" which can determine if nfs shares are in /etc/fstab and cause netmount to start nfsclient first, so things do not fail. Right now, netmount tries to mount nfs share but it cannot do it by itself. In english, I would say that netmount "needs" nfsclient to mount nfs shares. In openrc, there is also a way of defining dependancy or "need", and in my patch I have added the ability to use fstabinfo to determine if nfs shares are being mounted and dynamically set this need appropriately and correctly. If this patch is accepted, a use flag may be added to openrc to properly pull in the dep on nfs-utils which is needed for openrc to mount nfs shares.
please note, current patch is a suggestion for the fix but not complete, in reality it is likely needed to check that the nfsclient script exists before mindlessly needing and and an error could be produced when it doesn't exist. additionally, "nfsclient" could be replaced in the code with a compile time option like "make nfsinitscript=nfsclient" so that other distros do not have to patch openrc if they use another name for the helper init script.
(In reply to Rick Farina (Zero_Chaos) from comment #0) > Created attachment 395020 [details, diff] [details, diff] > netmount init.d script patch > > History: > > ~2 years ago, netmount from openrc tried to handle mounting of nfs shares, > but it couldn't properly handle it due to multiple other init scripts being > needed to start first. At that time, is was decided to split nfs mounting > out into an init script in the nfs-utils package which could handle the > proper starting of the services. This was bug #427996. I was overly-aggressive in fixing that bug. The netmount script, before, tried to start the daemons for nfs directly. The error I made was, not only did I remove the code that tried to start the nfs daemons, but I went further and went out of my way to exclude mounting nfs file systems from netmount. This lead to bug #508574. > Fast forward to openrc-0.13. Openrc now (again) will try to mount nfs > shares and fail, and nfs-utils has removed the nfsmount script. The goal in openrc-0.13 was to mount the nfs file systems, but to give control of the nfs daemons to the nfs-utils package, which knows best which daemons to start. The nfs-utils package renamed nfsmount to nfsclient and added "before netmount" to the dependencies for nfsclient. The new version of nfs-utils also adds an ewarn instructing users to add nfsclient to the default runlevel. > Current intention as I see it: > > OpenRC is a cross distro init system which should have no deps on anything > outside of OpenRC. nfs-utils adds "nfsclient" init script which must be > added to the same run level as netmount and things work smoothly. > > Issues: > > Scenario 1: new user, wants to mount nfs shares. Adds entries to /etc/fstab, > but they fail because only netmount is in the default run level and > "nfsclient" is required to start as well. User must google and hope they > hit "http://wiki.gentoo.org/wiki/NFSv4#Client" to learn that you need to > start two services for the mount to work properly. I don't see this as an issue OpenRC needs to deal with. The nfs-utils package should point users to the documentation for setting it up if it doesn't already. > Scenario 2: (my personal scenario) user on a laptop, doesn't have network > access all the time. users may choose to remove netmount from the default > (since network access isn't always available) and start it only when needed. > Once the user connects to a network where they would like to mount their nfs > shares, the user starts netmount which will fail, and must use google and > hope they hit "http://wiki.gentoo.org/wiki/NFSv4#Client" to learn that now > they user must start two services for netmount to actually work. Again, I think this is a documentation issue. I would suggest that laptop users, or users who do not have full-time network connections to their nfs servers use nofail on their nfs file system mounts in fstab. Try adding "nofail" to the mount options for your nfs file systems then add netmount to default. If that works, this should probably be put in the wiki. > > The problem here appears very very simple to me. If a user has nfs mounts, > netmount alone cannot do the job, and if the user runs netmount, it will > fail. There seems to be no reason why netmount has to fail, as openrc > contains the super helpful tool "fstabinfo" which can determine if nfs > shares are in /etc/fstab and cause netmount to start nfsclient first, so > things do not fail. > > Right now, netmount tries to mount nfs share but it cannot do it by itself. > In english, I would say that netmount "needs" nfsclient to mount nfs shares. You can also say that nfsclient needs to run before netmount so that netmount can mount nfs shares. Since netmount mounts multiple kinds of shares, I can't make netmount "need nfsclient". If I do, and nfsclient fails, no network file systems get mounted, nfs or otherwise. So I believe the approach of running nfsclient before netmount is the safest way to handle this. > In openrc, there is also a way of defining dependancy or "need", and in my > patch I have added the ability to use fstabinfo to determine if nfs shares > are being mounted and dynamically set this need appropriately and correctly. > If this patch is accepted, a use flag may be added to openrc to properly > pull in the dep on nfs-utils which is needed for openrc to mount nfs shares. The use flag you are suggesting would be a qa violation, because it would pull in an optional runtime dependency which OpenRC doesn't link to [1], so this is not an option. I understand your issues, but I see them as nfs documentation issues rather than issues that OpenRC should deal with. [1] http://devmanual.gentoo.org/general-concepts/use-flags/index.html
(In reply to William Hubbs from comment #2) > > The problem here appears very very simple to me. If a user has nfs mounts, > > netmount alone cannot do the job, and if the user runs netmount, it will > > fail. There seems to be no reason why netmount has to fail, as openrc > > contains the super helpful tool "fstabinfo" which can determine if nfs > > shares are in /etc/fstab and cause netmount to start nfsclient first, so > > things do not fail. > > > > Right now, netmount tries to mount nfs share but it cannot do it by itself. > > In english, I would say that netmount "needs" nfsclient to mount nfs shares. > > You can also say that nfsclient needs to run before netmount so that > netmount can mount nfs shares. Since netmount mounts multiple kinds of > shares, I can't make netmount "need nfsclient". If I do, and nfsclient > fails, no network file systems get mounted, nfs or otherwise. > Here is where we disagree. nfsclient script does everything it was intended to do, nothing more, and nothing less, without any help at all from netmount. netmount *needs* nfsclient to mount any nfs shares. nfsclient in *no way* needs netmount, but netmount "does not work" without nfsclient. This is a direct strong dependency which is being ignored. I understand that you don't want openrc to have a dep on nfs-utils, but what you have here does in fact directly depends on nfs-utils and nfsclient to work. > So I believe the approach of running nfsclient before netmount is the safest > way to handle this. > I don't see how forcing a user to manually add additional scripts to a runlevel is the "safest way to handle this", personally, I think that a proper need like in my patch handles all of this automatically which seems a hell of a lot safer. > > In openrc, there is also a way of defining dependancy or "need", and in my > > patch I have added the ability to use fstabinfo to determine if nfs shares > > are being mounted and dynamically set this need appropriately and correctly. > > If this patch is accepted, a use flag may be added to openrc to properly > > pull in the dep on nfs-utils which is needed for openrc to mount nfs shares. > > The use flag you are suggesting would be a qa violation, because it would > pull in an optional runtime dependency which OpenRC doesn't link to [1], so > this is not an option. > > I understand your issues, but I see them as nfs documentation issues rather > than issues that OpenRC should deal with. > > [1] http://devmanual.gentoo.org/general-concepts/use-flags/index.html If you choose to see it this way, then I will choose not to argue, but again, I think that this rule hurts the users and directly violates the Gentoo Philosophy. I can easily amend my patch to check for /etc/init.d/nfsclient before adding it to need.
I see this as a documentation issue for nfs-utils, so I am assigning the bug there.
This is already well documented, there is no documentation failure. The failure is that netmount cannot possibly mount nfs shares without nfsclient starting first but refuses to do it automatically. QA team, is it okay for an init script to plan to fail like this just so that they can avoid listing depends properly? I personally do think this flies at all, let alone for a critical system function like mounting network shares.
I spoke with ulm, and I am willing to write a news item about this. One wasn't originally written, because the guidelines of when to write one are pretty loose. However, I am unwilling to accept this patch. It creates a dependency that could break any setup that has multiple kinds of network shares.
Someone pointed out this comment to me which I missed, so I will respond now. (In reply to Rick Farina (Zero_Chaos) from comment #3) > (In reply to William Hubbs from comment #2) > > > The problem here appears very very simple to me. If a user has nfs mounts, > > > netmount alone cannot do the job, and if the user runs netmount, it will > > > fail. There seems to be no reason why netmount has to fail, as openrc > > > contains the super helpful tool "fstabinfo" which can determine if nfs > > > shares are in /etc/fstab and cause netmount to start nfsclient first, so > > > things do not fail. > > > > > > Right now, netmount tries to mount nfs share but it cannot do it by itself. > > > In english, I would say that netmount "needs" nfsclient to mount nfs shares. > > > > You can also say that nfsclient needs to run before netmount so that > > netmount can mount nfs shares. Since netmount mounts multiple kinds of > > shares, I can't make netmount "need nfsclient". If I do, and nfsclient > > fails, no network file systems get mounted, nfs or otherwise. > > > Here is where we disagree. nfsclient script does everything it was intended > to do, nothing more, and nothing less, without any help at all from > netmount. netmount *needs* nfsclient to mount any nfs shares. nfsclient in > *no way* needs netmount, but netmount "does not work" without nfsclient. > This is a direct strong dependency which is being ignored. I understand > that you don't want openrc to have a dep on nfs-utils, but what you have > here does in fact directly depends on nfs-utils and nfsclient to work. Let's look at how a need dependency works. If I put "need fsclient" in netmount, that means that netmount will not run, regardless of what else it could mount, if nfsclient fails. Also, it means if you stop nfsclient, netmount will be brought down, which would unmount all network shares, nfs or otherwise. > > So I believe the approach of running nfsclient before netmount is the safest > > way to handle this. > > > I don't see how forcing a user to manually add additional scripts to a > runlevel is the "safest way to handle this", personally, I think that a > proper need like in my patch handles all of this automatically which seems a > hell of a lot safer. Again, I point to what I said above, the issue is that netmount is not for nfs file systems only, so your proposal breaks hard on a system with multiple types of network shares. Asking users to use rc-update to add services to a runlevel is not out of the ordinary; we do this all the time. > > > In openrc, there is also a way of defining dependancy or "need", and in my > > > patch I have added the ability to use fstabinfo to determine if nfs shares > > > are being mounted and dynamically set this need appropriately and correctly. > > > If this patch is accepted, a use flag may be added to openrc to properly > > > pull in the dep on nfs-utils which is needed for openrc to mount nfs shares. > > > > The use flag you are suggesting would be a qa violation, because it would > > pull in an optional runtime dependency which OpenRC doesn't link to [1], so > > this is not an option. > > > > I understand your issues, but I see them as nfs documentation issues rather > > than issues that OpenRC should deal with. > > > > [1] http://devmanual.gentoo.org/general-concepts/use-flags/index.html > > If you choose to see it this way, then I will choose not to argue, but > again, I think that this rule hurts the users and directly violates the > Gentoo Philosophy. I can easily amend my patch to check for > /etc/init.d/nfsclient before adding it to need. That still doesn't work, because of the issues I pointed out above. Like I said in the previous comment. I spoke to ulm, and I agree to write a newsitem, but that's it.
(In reply to William Hubbs from comment #7) > Let's look at how a need dependency works. > > If I put "need fsclient" in netmount, that means that netmount will not run, > regardless of what else it could mount, if nfsclient fails. > > Also, it means if you stop nfsclient, netmount will be brought down, which > would unmount all network shares, nfs or otherwise. > I agree, that sounds bad. > > > So I believe the approach of running nfsclient before netmount is the safest > > > way to handle this. > > > > > I don't see how forcing a user to manually add additional scripts to a > > runlevel is the "safest way to handle this", personally, I think that a > > proper need like in my patch handles all of this automatically which seems a > > hell of a lot safer. > > Again, I point to what I said above, the issue is that netmount is not for > nfs file systems only, so your proposal breaks hard on a system with > multiple types of network shares. Actually, my original proposal was to leave nfsmount alone because it worked and was sane. What I'm doing now it trying to band-aid fix your terrible idea. > > Asking users to use rc-update to add services to a runlevel is not out of > the ordinary; we do this all the time. Yes, but I don't know anywhere else that we need two init scripts to accomplish one task. > > > > > In openrc, there is also a way of defining dependancy or "need", and in my > > > > patch I have added the ability to use fstabinfo to determine if nfs shares > > > > are being mounted and dynamically set this need appropriately and correctly. > > > > If this patch is accepted, a use flag may be added to openrc to properly > > > > pull in the dep on nfs-utils which is needed for openrc to mount nfs shares. > > > > > > The use flag you are suggesting would be a qa violation, because it would > > > pull in an optional runtime dependency which OpenRC doesn't link to [1], so > > > this is not an option. > > > > > > I understand your issues, but I see them as nfs documentation issues rather > > > than issues that OpenRC should deal with. > > > > > > [1] http://devmanual.gentoo.org/general-concepts/use-flags/index.html > > > > If you choose to see it this way, then I will choose not to argue, but > > again, I think that this rule hurts the users and directly violates the > > Gentoo Philosophy. I can easily amend my patch to check for > > /etc/init.d/nfsclient before adding it to need. > > That still doesn't work, because of the issues I pointed out above. > > Like I said in the previous comment. I spoke to ulm, and I agree to write a > newsitem, but that's it. Writing a news item in no way fixes the fact that netmount simply isn't pulling in it's deps. To mount an nfs share, netmount needs help, and if it cannot handle this properly then it shouldn't be doing the task. nfsmount was working perfectly before, and now you have taken us back to the same broken setup you migrated us away from just two years ago. You know that bit about learning from history or being doomed to repeat it? It was YOU that moved us away from this broken setup, how can you forget that and go right back to making things worse?
(In reply to Rick Farina (Zero_Chaos) from comment #8) > (In reply to William Hubbs from comment #7) > > Let's look at how a need dependency works. > > > > If I put "need fsclient" in netmount, that means that netmount will not run, > > regardless of what else it could mount, if nfsclient fails. This part here means that your idea breaks hard on a system with multiple kinds of shares. > > Also, it means if you stop nfsclient, netmount will be brought down, which > > would unmount all network shares, nfs or otherwise. > > > I agree, that sounds bad. I just checked myself, and this piece is not right, but the piece above definitely is. > > > > So I believe the approach of running nfsclient before netmount is the safest > > > > way to handle this. > > > > > > > I don't see how forcing a user to manually add additional scripts to a > > > runlevel is the "safest way to handle this", personally, I think that a > > > proper need like in my patch handles all of this automatically which seems a > > > hell of a lot safer. > > > > Again, I point to what I said above, the issue is that netmount is not for > > nfs file systems only, so your proposal breaks hard on a system with > > multiple types of network shares. > > Actually, my original proposal was to leave nfsmount alone because it worked > and was sane. What I'm doing now it trying to band-aid fix your terrible > idea. > > > > Asking users to use rc-update to add services to a runlevel is not out of > > the ordinary; we do this all the time. > > Yes, but I don't know anywhere else that we need two init scripts to > accomplish one task. netmount is already in the default runlevel, so unless you took it out yourself, you are just adding one, so this is no different than having sshd or having the nfs server start automatically. All You have to do is rc-update add nfsclient default, and because it has "before netmount" in its dependencies, boom, it falls in place. > > > > > > > In openrc, there is also a way of defining dependancy or "need", and in my > > > > > patch I have added the ability to use fstabinfo to determine if nfs shares > > > > > are being mounted and dynamically set this need appropriately and correctly. > > > > > If this patch is accepted, a use flag may be added to openrc to properly > > > > > pull in the dep on nfs-utils which is needed for openrc to mount nfs shares. > > > > > > > > The use flag you are suggesting would be a qa violation, because it would > > > > pull in an optional runtime dependency which OpenRC doesn't link to [1], so > > > > this is not an option. > > > > > > > > I understand your issues, but I see them as nfs documentation issues rather > > > > than issues that OpenRC should deal with. > > > > > > > > [1] http://devmanual.gentoo.org/general-concepts/use-flags/index.html > > > > > > If you choose to see it this way, then I will choose not to argue, but > > > again, I think that this rule hurts the users and directly violates the > > > Gentoo Philosophy. I can easily amend my patch to check for > > > /etc/init.d/nfsclient before adding it to need. > > > > That still doesn't work, because of the issues I pointed out above. > > > > Like I said in the previous comment. I spoke to ulm, and I agree to write a > > newsitem, but that's it. > > Writing a news item in no way fixes the fact that netmount simply isn't > pulling in it's deps. To mount an nfs share, netmount needs help, and if it > cannot handle this properly then it shouldn't be doing the task. nfsmount > was working perfectly before, and now you have taken us back to the same > broken setup you migrated us away from just two years ago. You know that > bit about learning from history or being doomed to repeat it? It was YOU > that moved us away from this broken setup, how can you forget that and go > right back to making things worse? From what I recall, *I* caused nfsmount to come into existence with my broken fix to bug #427996, so *I* caused the broken setup to start happening two years ago. Now, I'm trying to clean up that breakage I caused. Have you attempted to test things as they are along with my suggestion in comment #2? You never responded to that suggestion. Specifically, put netmount back in your default runlevel, then in your fstab, put nofail in the mount options for your nfs mounts.
(In reply to William Hubbs from comment #9) > (In reply to Rick Farina (Zero_Chaos) from comment #8) > > (In reply to William Hubbs from comment #7) > > > Let's look at how a need dependency works. > > > > > > If I put "need fsclient" in netmount, that means that netmount will not run, > > > regardless of what else it could mount, if nfsclient fails. > > This part here means that your idea breaks hard on a system with multiple > kinds of shares. > > > > Also, it means if you stop nfsclient, netmount will be brought down, which > > > would unmount all network shares, nfs or otherwise. > > > > > I agree, that sounds bad. > > I just checked myself, and this piece is not right, but the piece above > definitely is. > > > > > > So I believe the approach of running nfsclient before netmount is the safest > > > > > way to handle this. > > > > > > > > > I don't see how forcing a user to manually add additional scripts to a > > > > runlevel is the "safest way to handle this", personally, I think that a > > > > proper need like in my patch handles all of this automatically which seems a > > > > hell of a lot safer. > > > > > > Again, I point to what I said above, the issue is that netmount is not for > > > nfs file systems only, so your proposal breaks hard on a system with > > > multiple types of network shares. > > > > Actually, my original proposal was to leave nfsmount alone because it worked > > and was sane. What I'm doing now it trying to band-aid fix your terrible > > idea. > > > > > > Asking users to use rc-update to add services to a runlevel is not out of > > > the ordinary; we do this all the time. > > > > Yes, but I don't know anywhere else that we need two init scripts to > > accomplish one task. > > netmount is already in the default runlevel, so unless you took it out > yourself, you are just adding one, so this is no different than having sshd > or having the nfs server start automatically. > > All You have to do is rc-update add nfsclient default, and because it has > "before netmount" in its dependencies, boom, it falls in place. > > > > > > > > > > In openrc, there is also a way of defining dependancy or "need", and in my > > > > > > patch I have added the ability to use fstabinfo to determine if nfs shares > > > > > > are being mounted and dynamically set this need appropriately and correctly. > > > > > > If this patch is accepted, a use flag may be added to openrc to properly > > > > > > pull in the dep on nfs-utils which is needed for openrc to mount nfs shares. > > > > > > > > > > The use flag you are suggesting would be a qa violation, because it would > > > > > pull in an optional runtime dependency which OpenRC doesn't link to [1], so > > > > > this is not an option. > > > > > > > > > > I understand your issues, but I see them as nfs documentation issues rather > > > > > than issues that OpenRC should deal with. > > > > > > > > > > [1] http://devmanual.gentoo.org/general-concepts/use-flags/index.html > > > > > > > > If you choose to see it this way, then I will choose not to argue, but > > > > again, I think that this rule hurts the users and directly violates the > > > > Gentoo Philosophy. I can easily amend my patch to check for > > > > /etc/init.d/nfsclient before adding it to need. > > > > > > That still doesn't work, because of the issues I pointed out above. > > > > > > Like I said in the previous comment. I spoke to ulm, and I agree to write a > > > newsitem, but that's it. > > > > Writing a news item in no way fixes the fact that netmount simply isn't > > pulling in it's deps. To mount an nfs share, netmount needs help, and if it > > cannot handle this properly then it shouldn't be doing the task. nfsmount > > was working perfectly before, and now you have taken us back to the same > > broken setup you migrated us away from just two years ago. You know that > > bit about learning from history or being doomed to repeat it? It was YOU > > that moved us away from this broken setup, how can you forget that and go > > right back to making things worse? > > From what I recall, *I* caused nfsmount to come into existence with my > broken fix to bug #427996, so *I* caused the broken setup to start happening > two years ago. Now, I'm trying to clean up that breakage I caused. Ok, I did not bring it into existence, but there wer changes made to it at the time of the original fix I referred to above. All I've done with the recent update is rename it to nfsclient since it now doesn't need to mount anything. > Have you attempted to test things as they are along with my suggestion in > comment #2? You never responded to that suggestion. > > Specifically, put netmount back in your default runlevel, then in your > fstab, put nofail in the mount options for your nfs mounts. This still applies. I want to know if it works this way, because that will be the closest to the default case. I know that netmount is installed by default on every OpenRC system out there, and I know the nofail mount option means that a mount will not fail. If you add back netmount, so you are in the default configuration, and put nofail on the nfs lines in your fstab, that should take care of things hanging.
Another alternative I thought of you could try is a stacked runlevel. # mkdir /etc/runlevels/netfs #rc-update add -s default netfs Now, move netmount and nfsclient to the netfs runlevel. Then, you can switch back and forth with something like: # openrc netfs # openrc default as root.
Another thing you can do if you want the need dependency is to add nfsclient to an rc_need line in /etc/conf.d/netmount, so something like this based on the defaults: rc_need="net nfsclient" Nothing I have said on this bug is a case of trying to tell you not to do something on your own system; I have just offered alternatives that I think will work better than your proposal and explained why I think your proposal is not good globally.
netmount is expected to mount network filesystems. netmount claims to support mounting nfs. netmount cannot mount nfs without nfs-utils installed (missing dep in the ebuild) and without nfsclient started (missing dep in the init script). I know you don't want openrc to have deps, but to do that, you need to actually not have deps, not just refuse to set the deps. This was much better handled when openrc admitted that it couldn't handle nfs properly and we simply had a netmount script. Users should not have to be reconfiguring their systems manually to handle the trend nueovo, things should just work. Either openrc/netmount should declare it's deps correctly, or it shouldn't be even trying to complete a task it is only failing at now. You have come up with a lot of reasons why you can't do it right, so my real question is, if you can't do it right, why are you doing it at all? Things were FAR better with nfsmount than they are now.
(In reply to Rick Farina (Zero_Chaos) from comment #13) >This was much > better handled when openrc admitted that it couldn't handle nfs properly and > we simply had a netmount script. typo, should read "we simply had a nfsmount script"
(In reply to Rick Farina (Zero_Chaos) from comment #13) > netmount is expected to mount network filesystems. netmount claims to > support mounting nfs. netmount cannot mount nfs without nfs-utils installed > (missing dep in the ebuild) and without nfsclient started (missing dep in > the init script). As I said in comment #2, the first part of this proposal (a use flag for OpenRC to pull in nfs-utils) would be a qa violation. I find it sadly ironic that a member of the qa team is escalating this bug demanding that I violate qa. > I know you don't want openrc to have deps, but to do that, you need to > actually not have deps, not just refuse to set the deps. This was much > better handled when openrc admitted that it couldn't handle nfs properly and > we simply had a netmount script. There are many external programs needed to mount certain types of file systems, regardless of whether the file systems are local or on the network. Both localmount and netmount do not force these things to start. Instead, they just try to mount the file systems and return success regardless of what happens. I see no valid reason for nfs to be an exception to this just because it is nfs. If we want failures, the way forward would be to make netmount and localmount both return failure if something doesn't mount. I would consider that, but it would be a pretty disruptive change, so it would have to go in OpenRC-1.0. > Users should not have to be reconfiguring their systems manually to handle > the trend nueovo, things should just work. Either openrc/netmount should > declare it's deps correctly, or it shouldn't be even trying to complete a > task it is only failing at now. You have come up with a lot of reasons why > you can't do it right, so my real question is, if you can't do it right, why > are you doing it at all? Things were FAR better with nfsmount than they are > now. This is not a new trend. it is making behavior related to nfs consistent with all other file systems. All a user has to do when they emerge nfs-utils, besides configuring fstab to handle the nfs mounts correctly, is make sure nfsclient and netmount are in the same runlevel. That is no different than a step a user would take to install any other service. Here is my bottom line: No, I will not add optional runtime dependencies to the OpenRC ebuild; those would be QA violations, plain and simple. I have considered your patch to the netmount init script, and I find it flawed in several ways which I have articulated very clearly on this bug, so it is also rejected. The way I see it, the only question left on this bug is whether we want to change netmount and localmount so that they fail if the mount command they use fails.
(In reply to William Hubbs from comment #15) > All a user has to do when they emerge nfs-utils, besides configuring fstab > to handle the nfs mounts correctly, is make sure nfsclient and netmount are > in the same runlevel. That is no different than a step a user would take to > install any other service. > > Here is my bottom line: > > No, I will not add optional runtime dependencies to the OpenRC ebuild; those > would be QA violations, plain and simple. > > I have considered your patch to the netmount init script, and I find it > flawed in several ways which I have articulated very clearly on this bug, so > it is also rejected. > > The way I see it, the only question left on this bug is whether we want to > change netmount and localmount so that they fail if the mount command they > use fails. You are still entirely missing the point. netmount DEPENDS on nfs-utils AND an already running nfsclient to mount nfs shares. Without both of these things in place, it cannot possibly do it's job. Your "solution" is entirely incomplete and causes additional work to be undertaken by the users for no valid reason. Wishing that netmount had not dependencies and it actually having none are two entirely different things.
(In reply to Rick Farina (Zero_Chaos) from comment #16) > You are still entirely missing the point. netmount DEPENDS on nfs-utils AND > an already running nfsclient to mount nfs shares. Without both of these > things in place, it cannot possibly do it's job. Your "solution" is > entirely incomplete and causes additional work to be undertaken by the users > for no valid reason. Wishing that netmount had not dependencies and it > actually having none are two entirely different things. Your solution is entirely flawed, because it does not consider the possibility of a system having multiple kinds of shares, and the ramifications of making netmount fail because one particular type of share's services fail. As far as I am concerned, your solution is rejected, and discussion between you and I on this bug is on hold until bug #538192 is resolved.
@QA: I have posted a newsitem to -dev as you requested in irc, which will go to the tree on 02-02-2015. Please let me know if there is something else you feel I should do. If there isn't, I would like to close this bug when that newsitem goes live.
*** Bug 537650 has been marked as a duplicate of this bug. ***
(In reply to Rick Farina (Zero_Chaos) from comment #0) > Scenario 2: (my personal scenario) user on a laptop, doesn't have network > access all the time. users may choose to remove netmount from the default > (since network access isn't always available) and start it only when needed. > Once the user connects to a network where they would like to mount their nfs > shares, the user starts netmount which will fail, and must use google and > hope they hit "http://wiki.gentoo.org/wiki/NFSv4#Client" to learn that now > they user must start two services for netmount to actually work. I think in this scenario a user would be better off leveraging something like autofs and add or leave nfsclient enabled in the default runlevel. This is exactly how I handle using nfs shares on laptops with transient connections. I see netmount as more of the solution for servers or other setups with more permanent and unchanging connections.
(In reply to Tim Harder from comment #20) > (In reply to Rick Farina (Zero_Chaos) from comment #0) > > Scenario 2: (my personal scenario) user on a laptop, doesn't have network > > access all the time. users may choose to remove netmount from the default > > (since network access isn't always available) and start it only when needed. > > Once the user connects to a network where they would like to mount their nfs > > shares, the user starts netmount which will fail, and must use google and > > hope they hit "http://wiki.gentoo.org/wiki/NFSv4#Client" to learn that now > > they user must start two services for netmount to actually work. > > I think in this scenario a user would be better off leveraging something > like autofs and add or leave nfsclient enabled in the default runlevel. This > is exactly how I handle using nfs shares on laptops with transient > connections. > > I see netmount as more of the solution for servers or other setups with more > permanent and unchanging connections. This sounds like a very good choice to me. I did not know about autofs, or I would have suggested it myself. Thanks a lot for the information. @QA: I will update the news item to mention autofs as a choice to use if the user is not on a permanent connection.
@zero_chaos: Based on the news item that will hit the tree around 13:00 UTC or a little after today, and on the availability of autofs, which is probably a better solution for a laptop that moves around like your scenario #2, I plan on closing this bug as resolved/fixed when the news item goes live.
(In reply to William Hubbs from comment #22) > @zero_chaos: > Based on the news item that will hit the tree around 13:00 UTC or a > little after today, and on the availability of autofs, which is probably > a better solution for a laptop that moves around like your scenario #2, > I plan on closing this bug as resolved/fixed when the news item goes > live. Considering that netmount is currently the script for mounting nfs shares, and it cannot mount nfs shares without nfsclient running, yet you refuse to add any sane deps to it, I'd prefer if QA officially took a stance before we close this bug. I will accept whatever QA chooses, per official QA policy, including but not limited to, the lead weighing in, the deputy lead weighing in, or a majority vote.
(In reply to Rick Farina (Zero_Chaos) from comment #23) > (In reply to William Hubbs from comment #22) > > @zero_chaos: > > Based on the news item that will hit the tree around 13:00 UTC or a > > little after today, and on the availability of autofs, which is probably > > a better solution for a laptop that moves around like your scenario #2, > > I plan on closing this bug as resolved/fixed when the news item goes > > live. > > Considering that netmount is currently the script for mounting nfs shares, > and it cannot mount nfs shares without nfsclient running, yet you refuse to > add any sane deps to it, I'd prefer if QA officially took a stance before we > close this bug. I will accept whatever QA chooses, per official QA policy, > including but not limited to, the lead weighing in, the deputy lead weighing > in, or a majority vote. @rick: Let me correct your understanding of what netmount does. The purpose of netmount is to mount the following types of shares, assuming that you have a permanent connection to the server(s): afs ceph cifs coda davfs fuse fuse.sshfs gfs glusterfs lustre ncpfs nfs nfs4 ocfs2 shfs smbfs PLUS any types of shares you define in EXTRA_NET_FS_LIST as well as any entries in fstab that have _netdev in their mount options. This is why your patch is flawed and cannot be accepted. Netmount can't have the type of dependencies you are talking about, because if a daemon to manage a specific share fails to start, no shares of any kind will be mounted. Also, as I said in comment #2, having optional runtime dependencies in the openrc ebuild pulled in by use flags is a blatant violation of Gentoo's qa policy, so I can't accept that suggestion either. Please see comment #20 for probably the best suggestion regarding your laptop situation. The newsitem is on the dev list, and will go out in a few hours, so I will not attach it here.
The newsitem has been added to the tree.
FYI, I have a made a bump of nfs-utils that brings back migration-path nfsmount script, that just depends on both nfsclient and netmount. It will cause inconsistencies if the user is starting init scripts manually (because they might have started netmount before it), but it will work fine if nfsmount is in your runlevels on boot.
<QA lead hat> Currently netmount script has this: use afc-client amd autofs openvpn I think adding nfsclient here just for the understandability is enough. And post link to wiki about NFS into elog of nfs-utils, to show users how to properly configure NFS mount points. @zerochaos: your problem is solved entirely by autofs, recommendation about it is mentioned in news items. By the way, personally i use it on regular desktop too - it's super easy to configure. I think, current state is fine and QA intervention is not needed anymore here. But thanks for your work, leaving this in unannounced state would lead to a massive amount of breakages. Adding net-fs@ to CC - guys, please add apropriate link on wiki to nfs-utils ebuilds about proper configuring NFS client. Reassigning back to openrc@, but leaving qa@ in CC just for monitoring of progress on this issue. </QA lead hat>
(In reply to Sergey Popov from comment #27) > <QA lead hat> > Currently netmount script has this: > use afc-client amd autofs openvpn > > I think adding nfsclient here just for the understandability is enough. This part is done in commit 3100114. Because of the way the nfsmount and nfsclient scripts are set up, I don't feel I need to release a new version of OpenRC just to add a use statement since a use statement on its own will do nothing once the users follow the instructions in the news item. @qa: If you disagree, let me know and I'll spin a new release.
updating per QA meeting.
@council: I was reviewing this bug in preparation to close it, but because of the way the qa meeting went [1], I don't feel like I can close it without appealing. In comment #27, the qa lead suggests adding "use nfsclient" to netmount. As shown in comment #28, this was done, even though it is not necessary. It is not necessary because nfsclient has "before netmount" in its dependencies as stated multiple times in the bug, so all you have to do is add nfsclient and netmount to the same runlevel. He also suggested, in comment #27, that autofs would solve the problem instead of netmount, so you can go that route -- remove netmount from the default runlevel and install and configure autofs. This is covered as well in the news item [2]. I do agree with Rick that the want dependency is a good feature to add at some point. However, I do not agree that it is necessary for closing this bug. Better solutions, such as autofs, exist for dealing with the issues he brings up. Unfortunately, Rick was able to convince the QA lead that the want dependency should be a necessity for closing this bug. I'm not sure what QA's scope is for a situation like this. I know QA has scope over the ebuilds in the portage tree, but I'm not sure they can mandate something like this, especially since two ways forward were provided and documented. If you followed the newsitem, things continue to work. If you didn't and things stop working, this is not a bug; you get to keep the pieces. I am asking Council for permission to close this bug per comment #28 and remove the dependency on the want feature. [1] https://projects.gentoo.org/qa/meeting-logs/20150218.txt [2] https://gitweb.gentoo.org/proj/gentoo-news.git/plain/2015/2015-02-02-nfs-service-changes/2015-02-02-nfs-service-changes.en.txt
After some general chat, I have decided to drop the council from this bug. Also, I have added a dependency on #426944. This will be discussed on the ml, but if we go this route, there will be no need for a "want" dependency for this issue because users could configure the need/use dependencies for their own file systems as they wish. I think it is a much cleaner solution than using a "want" dependency the way this bug suggests.
This should be taken care of in 0.20. Please re-open if it isn't. William
