On 01/10/2020 14:10, Arne Schwabe wrote: > Am 22.11.17 um 17:58 schrieb Simon Matter: >> Hi, >> >> In our situation we have the requirement to run scripts before tun/tap is >> opened, not after. While this could be hacked into the init script, the >> proper way seems to add it to openvpn as --up-pre option. That's >> independent from any init scripts / systemd service file and works the >> same way as --down-pre, only for the up status. >> >> My initial feature wish, posted 5 years ago, was turned down as won't fix: >> https://community.openvpn.net/openvpn/ticket/284 >> >> But there are people who wish it and they have good reasons to wish it. >> Just yesterday someone asked again: >> https://community.openvpn.net/openvpn/ticket/284#comment:10 >> >> Without going into much details > > This patch currently misses a commit message anyway but a good commit > should explain why this change is a good one. > >> just one thing why --up + --up-pre is >> better than hacking around outside of openvpn: the command called with >> --up also gets additional run time information from openvpn by parameters >> and environmental variables. You don't get all those information when >> calling anything from outside of openvpn before openvpn actually starts. >> >> If you feel there are good reasons to still refuse this patch, please let >> me know. > > I am just looking at this patch since it is still in the review queue. > > - Missing documentation. > - pre-up flag is wrong in terms of scripts. If we add this, it needs to > be a different script because otherwise you will break use cases that > also need the --up script. > > Also having down and down-pre but then only not also up/up-pre but a up > with flag breaks the symmetry and is confusing. This patch has been lingering here on the list since 2017. And I still haven't changed my opinion about it, as I lack to see a proper use-case (or "user story", which is the appropriate term for the 2020s).
My stance is pretty well covered in the ticket [1], and the only potential use case which was provided does have, in my opinion, a better alternative by using --management and --management-hold. <https://community.openvpn.net/openvpn/ticket/284#comment:15> So consider this a NAK from my side. -- kind regards, David Sommerseth OpenVPN Inc
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel