Is there a way that any vpn app in portage can PROVIDE "vnet" (or some other) virtual, so that other init's can use the virtual for the depend function? I use openvpn on my wifi segment. My router only allows input on the openvpn port and no forwarding. I have openvpn redirecting all traffic through the vpn. I also use nfs over the openvpn link. If I have both openvpn and nfsmount in the same runlevel, nfsmount always tries to start first. I have to hack the init's and such to get it to work correctly. If there was a virtual provided by openvpn, the nfsmount init could have that in it's use line for the depend function. Therefore allowing for graceful nfs mounts/umounts depending on the state of the openvpn init. This is related to this bug report: http://bugs.gentoo.org/show_bug.cgi?id=97800 I already posted tp that bug, but I suspect it may be orphaned. Thanks.
not a baselayout issue, you'll need to get the vpn guys to update their init.d scripts
(In reply to comment #1) > not a baselayout issue, you'll need to get the vpn guys to update their init.d > scripts > Well, it currently is a baselayout issue as you could have >1 vpn client installed as afaik vpn software needs to be the same end to end. Also openvpn init script can be multiplexed like our net scripts for >1 vpn setup and our dependency system only allows us to provide "vpn" or "vpnnet" by one init script.
How about we allow conf.d/nfsmount to set RC_NEED="openvpn" and RC_USE="foo bar" ? Basically moving towards a system of user defined dependencies that overlay our init script dependencies.
Created attachment 92317 [details, diff] Allow RC_NEED and RC_USE to overlay init depends Patch should apply against baselayout-1.12.1 Reporter, please test and report back
Created attachment 92319 [details, diff] Allow RC_NEED and RC_USE to overlay init depends This one doesn't alter the config load order - heh.
Where does one set the RC_NEED and RC_USE overlay info? In /etc/conf.d/rc ? I also think this is not the way to go. The way openvpn init scripts work may break it. For each openvpn conf file one has, they make a link to /etc/init.d/openvpn.<filename in /etc/openvpn/> . For example, I use one openvpn conf file called /etc/openvpn/wan-cmpd1.conf. To control that connection i have a file called /etc/init.d/openvpn.wan-cmpd1 which is a symbolic link to /etc/init.d/openvpn. In my humble opinion we need something similar to the net init scripts. You have an option in /etc/conf.d/rc that makes it so vnet is not considered up until any vpn init in the current runlevel is started. Am I making any sense here? I will test the patch and report back. BrianW
(In reply to comment #6) > Where does one set the RC_NEED and RC_USE overlay info? In /etc/conf.d/rc ? I > also think this is not the way to go. The way openvpn init scripts work may > break it. For each openvpn conf file one has, they make a link to > /etc/init.d/openvpn.<filename in /etc/openvpn/> . For example, I use one > openvpn conf file called /etc/openvpn/wan-cmpd1.conf. To control that > connection i have a file called /etc/init.d/openvpn.wan-cmpd1 which is a > symbolic link to /etc/init.d/openvpn. So those settings would go in /etc/conf.d/wan-cmpd1.conf then. > In my humble opinion we need something similar to the net init scripts. You > have an option in /etc/conf.d/rc that makes it so vnet is not considered up > until any vpn init in the current runlevel is started. Am I making any sense > here? Not a good idea - for example a local dns resolver would need to depend on net and yet openvpn would depend on dns ..... But we do need something more flexible yes.
This is fixed in baselayout-1.12.4
Hey, I wanted do add that a vpn virtual does actually not make much sense. Because any sane person does not want to have any service start with just the net virtual, or change every net-requiring service to require vpn. I did it with a much better solution: I removed the “provide net” from *everything*, but added a “provide dmz” for net.eth0 (my use case). then I added a “provide net” to openvpn (or in my case: net.br0 which uses openvpn.vpn). tadaa, now i don’t have to change anything else, and it works as expected.