My system mounts a part of it's filesystem with NFS (the /etc/init.d/nfsmount script of net-fs/nfs-utils). But this is mounted from a system that is only reachable on a openVPN network (net-misc/openvpn). By default /etc/init.d/nfsmount is started before /etc/init.d/openvpn , so /etc/init.d/nfsmount fails because the openVPN link is down. I suggest to let /etc/init.d/nfsmount start after /etc/init.d/openvpn. The advantage is that /etc/init.d/nfsmount will not fail. Only people that mount /etc/openvpn with nfs will have a problem, but i don't think anybody does that. People that mount /etc, /usr/sbin or /usr (also needed by openVPN) over NFS won't have a problem because files in these dirs are also needed by NFS, so it's impossible to mount those over NFS. Sorry for my English, Nederlands spreken is eenvoudiger Reproducible: Always Steps to Reproduce: 1 emerge and configure net-fs/nfs-utils 2 emerge and configure net-misc/openvpn 3 tell /etc/fstab to mount something with nfs on a host only reachable with openvpn 4 reboot Actual Results: /etc/init.d/nfsmount fails Expected Results: /etc/init.d/nfsmount should work
The fix is simple, add the dependecy into your /etc/init.d/nfsmount file. But the question is, should it be done globally for every gentoo user.
> The fix is simple, add the dependecy into your /etc/init.d/nfsmount file. Indeed, I placed "use openvpn" in /etc/init.d/nfsmount. It seemed the best solution. > But the question is, should it be done globally for every gentoo user. I say yes, the large problem will be replaced by a very, very small one. I never heard of anyone that mounts /etc/openvpn with nfs, it seems rather useless because when you do this you will have keys travelling the network in cleartext. So actually we are solving a large problem AND a security problem by placing "use openvpn" in /etc/init.d/nfsmount WITHOUT creating a other problem.
Indeed, this is more related to net-fs imho.
why should this be in nfsmount instead of openvpn ? imo, the openvpn script should be updated to have 'before nfsmount' in it
> why should this be in nfsmount instead of openvpn ? > imo, the openvpn script should be updated to have 'before nfsmount' in it I don't think that's a good solution. If you would use 'before nfsmount' and stop openvpn then the nfs-filesystem mounted over ovenvpn will be unreachable. But if you would 'use openvpn' then nfsmount will automagicly stop and the filesystem will be safely unmounted.
fair enough, but i'm not exactly inclined to keep updating nfsmount for every vpn init.d script we have
> fair enough, but i'm not exactly inclined to keep updating nfsmount for every > vpn init.d script we have We can use "provide". If we let every VPN initscript provide (for example) "virtualnetwork" then we would only need "use virtualnetwork" is nfsmount. And "virtualnetwork" can also (probably) be used by something else.
Created attachment 63080 [details, diff] patch for nfsmount to let it use (not need) all virtualnetworks Here is a patch for net-fs/nfs-utils-1.0.7-r1 to let it use "virtualnetwork" which should be provided by all packages that can create a virtual network and that have a initscript. Should I open other bugs or should I place patches for these packages here (at the moment I only have one for openvpn because this is the only one I use)
I have this same problem. I have a wireless adapter on my Gentoo router. On my wireless client, I use openvpn for encryption/auth. I want to make sure nfsmount uses openvpn. Does the current openvpn provide "virtualnet" ? If not, is there a patch available?
this is a good case i think for adding a new keyword like 'use-before' that way openvpn could just do 'use-before netmount' ...
It's a problem for me when shutting down (for the reasons hinted at in Comment 5). My system stalls for a very long time if I don't manually unmount my NFS filesystems - all of which are facilitated by OpenVPN - before doing so. So, can a consensus be reached on how to handle this without requiring manual intervention on the part of the operator?
openvpn allows multiple scripts to exist. In fact, I don't even use the default "openvpn" script, I have all my openvpn connections explicitly named (i.e. openvpn.home, openvpn.office, openvpn.office2) so "use openvpn" wouldn't work for me at all. "provide virtualnetwork" wouldn't work either since my NFS mount could be on my office network but my home network might come up first there by satisfying "virtualnetwork" however it's not readily available. Reading this entire bug it sounds like this is going to be a special situation which is going to be specific to each user requiring proper configuration, which leads back to configuring your system properly. /etc/conf.d/nfsmount in my case contains rc_need="openvpn.officeq" For more info man -s 8 runscript
Yes, and then there's the issue of arbitrarily deciding that there is a relationship between the need for a given nfs mount and openvpn at all. Just an idea ... the only 'correct' way I can think of to automagically handle this is for the nfsmount init.d script to determine whether a given NFS export is provided by a host which falls within the scope of a VPN-provided subnet, and to append the relevant openvpn.* init.d scripts to ${myneed} as appropriate (I'm speaking in terms of baselayout-1* here). For example, it could collect network information from the "ifconfig" statements and "route" statements in OpenVPN's configuration files and compare this with the information in fstab and/or the current /etc/mtab file. For this to be even remotely sane, it would perhaps make sense for this information to be conveyed by a helper script which is the responsibility of the OpenVPN package maintainer, or for there to be an abstracted method of conveying such information whose scope could extend beyond OpenVPN alone. Of course, such a solution would increase complexity (touche). At the very least, I think the openvpn package could use some kind of post-install einfo/ewarn so as to render the user aware of this caveat and to offer some guidance.
i think at this point, we agree that this isn't necessarily a sane default if your system needs this, you can update your nfsmount/netmount/whatever to depend on whichever openvpn script you're utilizing
