| Message ID | 1552943809-6367-1-git-send-email-selva.nair@gmail.com |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | [Openvpn-devel] Improve the documentation for --dhcp-option | expand |
Hi, this situation has been hanging around for so long is this brief note really enough? Considering that the manual has numerous other URLs why not include this URL here: https://community.openvpn.net/openvpn/wiki/Pushing-DNS-to-clients We already have this: https://community.openvpn.net/openvpn/wiki/SWEET32 Please consider adding it. Thanks tct On 18/03/2019 21:16, selva.nair@gmail.com wrote: > From: Selva Nair <selva.nair@gmail.com> > > Make clear that --dhcp-option is not processed on > non-Windows clients and the user is expected to handle > it using an --up script. > > Signed-off-by: Selva Nair <selva.nair@gmail.com> > --- > doc/openvpn.8 | 18 +++++++++++++----- > 1 file changed, 13 insertions(+), 5 deletions(-) > > diff --git a/doc/openvpn.8 b/doc/openvpn.8 > index ce44044..993c8bd 100644 > --- a/doc/openvpn.8 > +++ b/doc/openvpn.8 > @@ -6026,13 +6026,21 @@ scope IDs. The Scope ID becomes a part of the NetBIOS name, making the name uniq > .B DISABLE\-NBT \-\- > Disable Netbios\-over\-TCP/IP. > > -Note that if > +Note that > +.B \-\-dhcp\-option > +is processed only on Windows clients. If > .B \-\-dhcp\-option > -is pushed via > +is used directly on or pushed via > .B \-\-push > -to a non\-windows client, the option will be saved in the client's > -environment before the up script is called, under > -the name "foreign_option_{n}". > +to a non\-windows client, the option is > +.B only > +saved in the client's > +environment before the > +.B \-\-up > +script is called, under the name "foreign_option_{n}". > +The user has to arrange an > +.B \-\-up > +script to pick up those parameters and act on them as required. > .\"********************************************************* > .TP > .B \-\-tap\-sleep n >
Hi, On 18/03/2019 22:30, tincanteksup wrote: > Hi, > > this situation has been hanging around for so long is this brief note > really enough? Considering that the manual has numerous other URLs why > not include this URL here: > https://community.openvpn.net/openvpn/wiki/Pushing-DNS-to-clients > > We already have this: > https://community.openvpn.net/openvpn/wiki/SWEET32 > the problem with URLs is that they become obsolete and we need to re-patch the manual in order to update them (or ensure the URL always work/redirect to something). However, I was thinking that a WARNING in the log when parsing a dhcp-option without any script configured (on non-windows platform) may also be beneficial. Not many people will read it, but at least it will be there to be seen at the first attempt of understanding what's wrong. What do you think? This said, the warning could/should be implemented as a separate patch. Regards,
Hi, On Wed, Mar 20, 2019 at 4:02 AM Antonio Quartulli <a@unstable.cc> wrote: > > Hi, > > On 18/03/2019 22:30, tincanteksup wrote: > > Hi, > > > > this situation has been hanging around for so long is this brief note > > really enough? Considering that the manual has numerous other URLs why > > not include this URL here: > > https://community.openvpn.net/openvpn/wiki/Pushing-DNS-to-clients > > > > We already have this: > > https://community.openvpn.net/openvpn/wiki/SWEET32 > > > > the problem with URLs is that they become obsolete and we need to > re-patch the manual in order to update them (or ensure the URL always > work/redirect to something). I have the same opinion about URLs. On top of that the wiki description is inadequate and inaccurate. But that's a different topic. The patch was meant to remove the ambiguity in the current wording. We could add a line saying many distributions include such scripts and front-ends such as network manager, tunnelblick, OpenVPN for Android etc. also handle some dhcp-options. (I don't use any of them, so guessing here..) > > > However, I was thinking that a WARNING in the log when parsing a > dhcp-option without any script configured (on non-windows platform) may > also be beneficial. This would catch some obvious cases but not when a script is being used for some other purpose. Still, sounds useful. Selva
Am 20.03.19 um 14:25 schrieb Selva Nair: > Hi, > > On Wed, Mar 20, 2019 at 4:02 AM Antonio Quartulli <a@unstable.cc> wrote: >> >> Hi, >> >> On 18/03/2019 22:30, tincanteksup wrote: >>> Hi, >>> >>> this situation has been hanging around for so long is this brief note >>> really enough? Considering that the manual has numerous other URLs why >>> not include this URL here: >>> https://community.openvpn.net/openvpn/wiki/Pushing-DNS-to-clients >>> >>> We already have this: >>> https://community.openvpn.net/openvpn/wiki/SWEET32 >>> >> >> the problem with URLs is that they become obsolete and we need to >> re-patch the manual in order to update them (or ensure the URL always >> work/redirect to something). > > > I have the same opinion about URLs. On top of that the wiki > description is inadequate and inaccurate. But that's a different > topic. > > The patch was meant to remove the ambiguity in the current > wording. We could add a line saying many distributions include > such scripts and front-ends such as network manager, tunnelblick, > OpenVPN for Android etc. also handle some dhcp-options. (I don't use > any of them, so guessing here..) > Yes. Most platforms and client interpret this option. Only OpenVPN itself only interprets it only Windows and Android. It should probably changed to reflect reality. Arne
On 20/03/2019 13:25, Selva Nair wrote: > Hi, > > On Wed, Mar 20, 2019 at 4:02 AM Antonio Quartulli <a@unstable.cc> wrote: >> >> Hi, >> >> On 18/03/2019 22:30, tincanteksup wrote: >>> Hi, >>> >>> this situation has been hanging around for so long is this brief note >>> really enough? Considering that the manual has numerous other URLs why >>> not include this URL here: >>> https://community.openvpn.net/openvpn/wiki/Pushing-DNS-to-clients >>> >>> We already have this: >>> https://community.openvpn.net/openvpn/wiki/SWEET32 >>> >> >> the problem with URLs is that they become obsolete and we need to >> re-patch the manual in order to update them (or ensure the URL always >> work/redirect to something). > > > I have the same opinion about URLs. On top of that the wiki > description is inadequate and inaccurate. But that's a different > topic. Inadequate: Compared to NOTHING, the page is at least a step toward documentation. Inaccurate: Please expand ..
Hi, On Wed, Mar 20, 2019 at 9:45 AM Arne Schwabe <arne@rfc2549.org> wrote: > > Am 20.03.19 um 14:25 schrieb Selva Nair: > > Hi, > > > > On Wed, Mar 20, 2019 at 4:02 AM Antonio Quartulli <a@unstable.cc> wrote: > >> > >> Hi, > >> > >> On 18/03/2019 22:30, tincanteksup wrote: > >>> Hi, > >>> > >>> this situation has been hanging around for so long is this brief note > >>> really enough? Considering that the manual has numerous other URLs why > >>> not include this URL here: > >>> https://community.openvpn.net/openvpn/wiki/Pushing-DNS-to-clients > >>> > >>> We already have this: > >>> https://community.openvpn.net/openvpn/wiki/SWEET32 > >>> > >> > >> the problem with URLs is that they become obsolete and we need to > >> re-patch the manual in order to update them (or ensure the URL always > >> work/redirect to something). > > > > > > I have the same opinion about URLs. On top of that the wiki > > description is inadequate and inaccurate. But that's a different > > topic. > > > > The patch was meant to remove the ambiguity in the current > > wording. We could add a line saying many distributions include > > such scripts and front-ends such as network manager, tunnelblick, > > OpenVPN for Android etc. also handle some dhcp-options. (I don't use > > any of them, so guessing here..) > > > > Yes. Most platforms and client interpret this option. Only OpenVPN > itself only interprets it only Windows and Android. It should probably > changed to reflect reality. In case of Android, its only sent to the management, right? As the man page is about OpenVPN core, I would say the current statement that the option is handled only on Windows is correct. But its useful to expand on the usage on other platforms. I can add a line about scripts in OS distributions and front-ends/UI like Android that can transparently handle it. Selva
On Wed, Mar 20, 2019 at 10:52 AM tincanteksup <tincanteksup@gmail.com> wrote: > > > > On 20/03/2019 13:25, Selva Nair wrote: > > Hi, > > > > On Wed, Mar 20, 2019 at 4:02 AM Antonio Quartulli <a@unstable.cc> wrote: > >> > >> Hi, > >> > >> On 18/03/2019 22:30, tincanteksup wrote: > >>> Hi, > >>> > >>> this situation has been hanging around for so long is this brief note > >>> really enough? Considering that the manual has numerous other URLs why > >>> not include this URL here: > >>> https://community.openvpn.net/openvpn/wiki/Pushing-DNS-to-clients > >>> > >>> We already have this: > >>> https://community.openvpn.net/openvpn/wiki/SWEET32 > >>> > >> > >> the problem with URLs is that they become obsolete and we need to > >> re-patch the manual in order to update them (or ensure the URL always > >> work/redirect to something). > > > > > > I have the same opinion about URLs. On top of that the wiki > > description is inadequate and inaccurate. But that's a different > > topic. > > Inadequate: > Compared to NOTHING, the page is at least a step toward documentation. > > Inaccurate: > Please expand .. The wiki states that on Windows using version 2.4, OpenVPN-GUI+interactive service required for processing this option. Not so. Just as in 2.3, it works if run as admin. In fact, several setups run OpenVPN on boot using OpenVPNService, and --dhcp-option does work for them. With 2.4, it also works as limited user if started using the interactive service (for example, using OpenVPN-GUI). In both 2.3 and 2.4, the critical piece is not overriding --ipwin32 method (adaptive or dynamic is required and the latter is the default). Selva On Wed, Mar 20, 2019 at 10:52 AM tincanteksup <tincanteksup@gmail.com> wrote: > > > On 20/03/2019 13:25, Selva Nair wrote: > > Hi, > > > > On Wed, Mar 20, 2019 at 4:02 AM Antonio Quartulli <a@unstable.cc> wrote: > >> > >> Hi, > >> > >> On 18/03/2019 22:30, tincanteksup wrote: > >>> Hi, > >>> > >>> this situation has been hanging around for so long is this brief note > >>> really enough? Considering that the manual has numerous other URLs why > >>> not include this URL here: > >>> https://community.openvpn.net/openvpn/wiki/Pushing-DNS-to-clients > >>> > >>> We already have this: > >>> https://community.openvpn.net/openvpn/wiki/SWEET32 > >>> > >> > >> the problem with URLs is that they become obsolete and we need to > >> re-patch the manual in order to update them (or ensure the URL always > >> work/redirect to something). > > > > > > I have the same opinion about URLs. On top of that the wiki > > description is inadequate and inaccurate. But that's a different > > topic. > > Inadequate: > Compared to NOTHING, the page is at least a step toward documentation. > > Inaccurate: > Please expand .. > > <div dir="ltr">On Wed, Mar 20, 2019 at 10:52 AM tincanteksup <<a href="mailto:tincanteksup@gmail.com">tincanteksup@gmail.com</a>> wrote:<br>><br>><br>><br>> On 20/03/2019 13:25, Selva Nair wrote:<br>> > Hi,<br>> ><br>> > On Wed, Mar 20, 2019 at 4:02 AM Antonio Quartulli <a@unstable.cc> wrote:<br>> >><br>> >> Hi,<br>> >><br>> >> On 18/03/2019 22:30, tincanteksup wrote:<br>> >>> Hi,<br>> >>><br>> >>> this situation has been hanging around for so long is this brief note<br>> >>> really enough? Considering that the manual has numerous other URLs why<br>> >>> not include this URL here:<br>> >>> <a href="https://community.openvpn.net/openvpn/wiki/Pushing-DNS-to-clients">https://community.openvpn.net/openvpn/wiki/Pushing-DNS-to-clients</a><br>> >>><br>> >>> We already have this:<br>> >>> <a href="https://community.openvpn.net/openvpn/wiki/SWEET32">https://community.openvpn.net/openvpn/wiki/SWEET32</a><br>> >>><br>> >><br>> >> the problem with URLs is that they become obsolete and we need to<br>> >> re-patch the manual in order to update them (or ensure the URL always<br>> >> work/redirect to something).<br>> ><br>> ><br>> > I have the same opinion about URLs. On top of that the wiki<br>> > description is inadequate and inaccurate. But that's a different<br>> > topic.<br>><br>> Inadequate:<br>> Compared to NOTHING, the page is at least a step toward documentation.<br>><br>> Inaccurate:<br>> Please expand ..<br><br>The wiki states that on Windows using version 2.4, OpenVPN-GUI+interactive service required for processing this option. Not so.<br>Just as in 2.3, it works if run as admin. In fact, several setups run OpenVPN on boot using OpenVPNService, and --dhcp-option does work for them. With 2.4, it also works as limited user if started using the interactive service (for example, using OpenVPN-GUI).<br><br>In both 2.3 and 2.4, the critical piece is not overriding --ipwin32 method (adaptive or dynamic is required and the latter is the<br>default).<br><br>Selva</div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 20, 2019 at 10:52 AM tincanteksup <<a href="mailto:tincanteksup@gmail.com">tincanteksup@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br> <br> On 20/03/2019 13:25, Selva Nair wrote:<br> > Hi,<br> > <br> > On Wed, Mar 20, 2019 at 4:02 AM Antonio Quartulli <a@unstable.cc> wrote:<br> >><br> >> Hi,<br> >><br> >> On 18/03/2019 22:30, tincanteksup wrote:<br> >>> Hi,<br> >>><br> >>> this situation has been hanging around for so long is this brief note<br> >>> really enough? Considering that the manual has numerous other URLs why<br> >>> not include this URL here:<br> >>> <a href="https://community.openvpn.net/openvpn/wiki/Pushing-DNS-to-clients" rel="noreferrer" target="_blank">https://community.openvpn.net/openvpn/wiki/Pushing-DNS-to-clients</a><br> >>><br> >>> We already have this:<br> >>> <a href="https://community.openvpn.net/openvpn/wiki/SWEET32" rel="noreferrer" target="_blank">https://community.openvpn.net/openvpn/wiki/SWEET32</a><br> >>><br> >><br> >> the problem with URLs is that they become obsolete and we need to<br> >> re-patch the manual in order to update them (or ensure the URL always<br> >> work/redirect to something).<br> > <br> > <br> > I have the same opinion about URLs. On top of that the wiki<br> > description is inadequate and inaccurate. But that's a different<br> > topic.<br> <br> Inadequate:<br> Compared to NOTHING, the page is at least a step toward documentation.<br> <br> Inaccurate:<br> Please expand ..<br> <br> </blockquote></div>
> > In case of Android, its only sent to the management, right? As the man > page is about > OpenVPN core, I would say the current statement that the option is > handled only on > Windows is correct. Well everything is just to managment on Android, even opening the tun device. But Android and Win32 are the two platforms on which the core parses the DNS option and explicity calls functions to set a DNS server. Arne
bonjour On 20/03/2019 17:25, Selva Nair wrote: > On Wed, Mar 20, 2019 at 10:52 AM tincanteksup <tincanteksup@gmail.com> > wrote: >> >> >> >> On 20/03/2019 13:25, Selva Nair wrote: >>> Hi, >>> >>> On Wed, Mar 20, 2019 at 4:02 AM Antonio Quartulli <a@unstable.cc> wrote: >>>> >>>> Hi, >>>> >>>> On 18/03/2019 22:30, tincanteksup wrote: >>>>> Hi, >>>>> >>>>> this situation has been hanging around for so long is this brief note >>>>> really enough? Considering that the manual has numerous other URLs why >>>>> not include this URL here: >>>>> https://community.openvpn.net/openvpn/wiki/Pushing-DNS-to-clients >>>>> >>>>> We already have this: >>>>> https://community.openvpn.net/openvpn/wiki/SWEET32 >>>>> >>>> >>>> the problem with URLs is that they become obsolete and we need to >>>> re-patch the manual in order to update them (or ensure the URL always >>>> work/redirect to something). >>> >>> >>> I have the same opinion about URLs. On top of that the wiki >>> description is inadequate and inaccurate. But that's a different >>> topic. >> >> Inadequate: >> Compared to NOTHING, the page is at least a step toward documentation. >> >> Inaccurate: >> Please expand .. > > The wiki states that on Windows using version 2.4, OpenVPN-GUI+interactive > service required for processing this option. Not so. I am actively promoting 2.4 use, I am not re-writing the manual. > Just as in 2.3, it works if run as admin. In fact, several setups run > OpenVPN on boot using OpenVPNService, and --dhcp-option does work for them. > With 2.4, it also works as limited user if started using the interactive > service (for example, using OpenVPN-GUI). I am actively demoting 2.3 use, I am not re-writing the manual. > In both 2.3 and 2.4, the critical piece is not overriding --ipwin32 method > (adaptive or dynamic is required and the latter is the > default). > I am actively promoting the use of the Interactive Service. I am not rewriting the manual .. If a problem arises from using Openvpn as the page describes then, depending on the cause, a resolution can be pursued .. thanks tct
bonjour On 20/03/2019 08:00, Antonio Quartulli wrote: > Hi, > > On 18/03/2019 22:30, tincanteksup wrote: >> Hi, >> >> this situation has been hanging around for so long is this brief note >> really enough? Considering that the manual has numerous other URLs why >> not include this URL here: >> https://community.openvpn.net/openvpn/wiki/Pushing-DNS-to-clients >> >> We already have this: >> https://community.openvpn.net/openvpn/wiki/SWEET32 >> Reinserted from my original post: >> Please consider adding it. > > the problem with URLs is that they become obsolete and we need to > re-patch the manual in order to update them (or ensure the URL always > work/redirect to something). > > > However, I was thinking that a WARNING in the log when parsing a > dhcp-option without any script configured (on non-windows platform) may > also be beneficial. > > Not many people will read it, but at least it will be there to be seen > at the first attempt of understanding what's wrong. > > What do you think? The argument against using URLs in the Manual has these facts to refute: * URLs are already in use in the manual * I cited another example of using a URL in the manual. * Some URLS in use in the manual are external to openvpn.net * Using URLs in online documentation is The standard practice. * There are even URLs in the Openvpn log files .. It is easier to maintain linked documentation than it is to have to patch the source so, given that the link is under the openvpn.net wing, this seems perfectly reasonable to me. Adding a warning for this problem in the log file is unsuitable: * When the situation changes the source will have to be maintained. * The situation will change. * It is easier to maintain linked documentation to account for change. * Log files are for diagnosing problems and should not have any URLs.. (Except for one URL to ${help}.openvpn, a URL which is unlikely to change and can therefore be easily maintained by OpenVPN Inc and remove that burden from the FOSS Openvpn development team) my2c thanks tct > > This said, the warning could/should be implemented as a separate patch. > > Regards, >
On 20/03/2019 18:12, tincanteksup wrote: > bonjour > > On 20/03/2019 17:25, Selva Nair wrote: >> On Wed, Mar 20, 2019 at 10:52 AM tincanteksup <tincanteksup@gmail.com> >> wrote: >>> >>> >>> >>> On 20/03/2019 13:25, Selva Nair wrote: >>>> Hi, >>>> >>>> On Wed, Mar 20, 2019 at 4:02 AM Antonio Quartulli <a@unstable.cc> >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> On 18/03/2019 22:30, tincanteksup wrote: >>>>>> Hi, >>>>>> >>>>>> this situation has been hanging around for so long is this brief note >>>>>> really enough? Considering that the manual has numerous other URLs >>>>>> why >>>>>> not include this URL here: >>>>>> https://community.openvpn.net/openvpn/wiki/Pushing-DNS-to-clients >>>>>> >>>>>> We already have this: >>>>>> https://community.openvpn.net/openvpn/wiki/SWEET32 >>>>>> >>>>> >>>>> the problem with URLs is that they become obsolete and we need to >>>>> re-patch the manual in order to update them (or ensure the URL always >>>>> work/redirect to something). >>>> >>>> >>>> I have the same opinion about URLs. On top of that the wiki >>>> description is inadequate and inaccurate. But that's a different >>>> topic. >>> >>> Inadequate: >>> Compared to NOTHING, the page is at least a step toward documentation. >>> >>> Inaccurate: >>> Please expand .. >> >> The wiki states that on Windows using version 2.4, >> OpenVPN-GUI+interactive >> service required for processing this option. Not so. > > I am actively promoting 2.4 use, I am not re-writing the manual. > >> Just as in 2.3, it works if run as admin. In fact, several setups run >> OpenVPN on boot using OpenVPNService, and --dhcp-option does work for >> them. >> With 2.4, it also works as limited user if started using the interactive >> service (for example, using OpenVPN-GUI). > > I am actively demoting 2.3 use, I am not re-writing the manual. > >> In both 2.3 and 2.4, the critical piece is not overriding --ipwin32 >> method >> (adaptive or dynamic is required and the latter is the >> default). >> > > I am actively promoting the use of the Interactive Service. > I am not rewriting the manual .. > > If a problem arises from using Openvpn as the page describes then, > depending on the cause, a resolution can be pursued .. > > thanks > tct > This thread was _initially_ about pushing DNS to Linux clients.
Correcion >From: Selva Nair <selva.nair@gmail.com> > >Make clear that --dhcp-option is not processed on >non-Windows clients > This thread was _initially_ about pushing DNS to Linux clients. I mean "non-windows" clients.
Hi, On Mon, Mar 18, 2019 at 05:16:49PM -0400, selva.nair@gmail.com wrote: > From: Selva Nair <selva.nair@gmail.com> > > Make clear that --dhcp-option is not processed on > non-Windows clients and the user is expected to handle > it using an --up script. I'm going through "lost" patches in patchwork - and this one is still relevant, I think, but the documentation looks much different now (.rst). Could you re-send? gert
diff --git a/doc/openvpn.8 b/doc/openvpn.8 index ce44044..993c8bd 100644 --- a/doc/openvpn.8 +++ b/doc/openvpn.8 @@ -6026,13 +6026,21 @@ scope IDs. The Scope ID becomes a part of the NetBIOS name, making the name uniq .B DISABLE\-NBT \-\- Disable Netbios\-over\-TCP/IP. -Note that if +Note that +.B \-\-dhcp\-option +is processed only on Windows clients. If .B \-\-dhcp\-option -is pushed via +is used directly on or pushed via .B \-\-push -to a non\-windows client, the option will be saved in the client's -environment before the up script is called, under -the name "foreign_option_{n}". +to a non\-windows client, the option is +.B only +saved in the client's +environment before the +.B \-\-up +script is called, under the name "foreign_option_{n}". +The user has to arrange an +.B \-\-up +script to pick up those parameters and act on them as required. .\"********************************************************* .TP .B \-\-tap\-sleep n