Created attachment 12217 [details] Updated ebuild. Here is the updated ebuild. I removed the patches that is used for vtun 2.5. It looks like the makefile patch were accepted upstream (except for the INSTALL_OWNER), it has been replaced by a simple sed line in the new ebuild. I have also changed the echo >>> to ewarn in the pkg_postinst. - chuck
vtun's init script doesn't seem to be able to deal with starting a server and a client. The code LOOKs like it should be able to, since it executes one process for every non commented line in /etc/vtund-start.conf, but subsequent lines never seem to actually execute. I'm trying to figure out a way to get arond this problem... but I don't fully understand how start-stop-daemon tracks things yet.
Fixed in cvs, thanks for the bug report.
Created attachment 22196 [details] /etc/init.d/vtun This is a simplified version of the vtun init script that fixes the inability to launch vtun clients properly. This error appears as an invalid host error. The error is due to the end of options '--' erroneously passed to vtund before the options and connection parameters. I also simplified and corrected the whole looping to read parameters and unnecessarilly grouping of commands in the start script. The for loop was unintendedly breaking up the grouping of options by line and the IFS trick was just creating obfuscation layers on top of the underlying missing line breaks problem by fix the symptom and not the underlying incorrect approach. Removing the for loop and putting a while around the read where it belongs fixes all of these problems. I am not meaning to come off condescending. This is the third time I have tried to solve this same problem over the last few months. This is not only the most elegant solution that I have come up with but also the first one that solves all the problems. (I hope/Works fine here). I actually really like the killall service stop solution n the originally fixed script as I tried to go the start-stop-daemon route in frustration and bewilderment myself before I understood the elegance of the killall solution. In fact I think the effort I have put forward for this script has has not only made me question the wisdom of a lot of 'kill' scripts that don't use killall but has also increased my understanding of practical bash scripting exponentially from the already able skills at bash scripting I previously possessed. All in all a very rewarding experience for such a short piece of script. Now if only the status and start scripts could be fleshed out to deal properly with some tunnels failing but with others already started without having to manually kill all the running tunnels manually.
