Re: resolvconf update script failure leads to forgotten device
Tobias, Thanks for getting this done. I'd like to try it out the changes, but my system is Ubuntu 14.04. Will you be backporting the changes for it? If not, will it be available for a later Ubuntu release? Thanks! Corey On Mon, Jun 13, 2016 at 12:50 AM, Tobias Brunner wrote: > Hi Corey, > > FYI, I pushed a couple of commits ([1], [2]) that address this to master > so they will be included in our next release. > > Regards, > Tobias > > [1] https://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=f4a20b74 > [2] https://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=f1064ca5 > > -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: resolvconf update script failure leads to forgotten device
Hi Corey, FYI, I pushed a couple of commits ([1], [2]) that address this to master so they will be included in our next release. Regards, Tobias [1] https://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=f4a20b74 [2] https://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=f1064ca5 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: resolvconf update script failure leads to forgotten device
Hi Tobias: Thank you for your quick and thoughtful response! On Fri, May 6, 2016 at 6:03 AM, Tobias Brunner wrote: > Hi Corey, > > > 1. Call "resolvconf --disable-updates" > > 2. Call resolvconf the way it is currently in > > invoke_resolveconf(). This has the effect of installing or > > deleting the interface without running the update script, and > > the exit code returned by "pclose()" will tell you whether the > > resolvconf install succeeded. > > 3. Call "resolvconf --enable-updates" which will cause the > > postponed update scripts to be run, and the errors here can be > > ignored or logged with "DBG1()". > > 4. Return the pclose() return value from ste > > Not sure if that's such a good idea. Don't failed update scripts > indicate a serious problem? Actually, resolvconf does not seem to do much besides some basic checks and writing the passed data to an > interface file before running the update scripts, of which update.d/libc > seems to do the main work of actually "installing" the DNS server by > writing resolv.conf. Good point. It's not wise to continue as if nothing has gone wrong, when, as far as we know, it could be the "installing" done within update.d/libc itself that went wrong, even though, in my case, that part succeeded, while it was one of the sub-scripts under update-libc.d which failed. So, it's better and simpler to always return failure. Also, in order to enhance the debuggability for the case where update scripts failed, I'd recommend trying to capture stderr of the resolvconf calls, and sending it to the ike debug log. From my testing, I can see that the 'run-parts' program (which is called by /sbin/resolvconf in order to run the update scripts) does a good job of telling you which scripts exited non-zero, and this would be useful to see in the log alongside the "[IKE] adding DNS server failed" message, if possible. > So perhaps we could just recursively call > invoke_resolvconf(FALSE) if pclose() indicates the command failed. That > way the interface file is at least removed again. > > This seems to be a very good solution. This would definitely fix my case, where the "install" part in update.d/libc actually succeeded (and the part that failed was one of the sub-scripts under update-libc.d), since the follow-up, recursive invoke_resolvconf(FALSE) call would not only delete the interface file, but also trigger a successful "uninstall" operation performed by update.d/libc (even though my failing sub-script in update-libc.d would still, thereafter, fail, but, if, as mentioned above, stderr is captured, that would be easily debugged). > Regards > Tobias > Let me know if you need help with anything... Thanks! Corey -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: resolvconf update script failure leads to forgotten device
Hi Corey, > 1. Call "resolvconf --disable-updates" > 2. Call resolvconf the way it is currently in > invoke_resolveconf(). This has the effect of installing or > deleting the interface without running the update script, and > the exit code returned by "pclose()" will tell you whether the > resolvconf install succeeded. > 3. Call "resolvconf --enable-updates" which will cause the > postponed update scripts to be run, and the errors here can be > ignored or logged with "DBG1()". > 4. Return the pclose() return value from step 2. Not sure if that's such a good idea. Don't failed update scripts indicate a serious problem? Actually, resolvconf does not seem to do much besides some basic checks and writing the passed data to an interface file before running the update scripts, of which update.d/libc seems to do the main work of actually "installing" the DNS server by writing resolv.conf. So perhaps we could just recursively call invoke_resolvconf(FALSE) if pclose() indicates the command failed. That way the interface file is at least removed again. Regards, Tobias -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: resolvconf update script failure leads to forgotten device
Tobias and Yves-Alexis: I would appreciate it if you could take at look at the below. Thanks! Corey Kasten On Thu, May 5, 2016 at 10:21 AM, corey kasten wrote: > Hi! > > I'm using strongswan 5.1.2-0ubuntu2.4 on ubuntu 14.04, and I noticed a > scenario where resolvconf is run which correctly adds the interface, but > when the triggered update scripts run, one of them fails, and resolvconf > exits non-zero, which causes invoke_resolvconf() (in > src/libhydra/plugins/resolve/resolve_handler.c) to report a failure, which > in turn makes strongswan think the name server line failed to get > installed. This, in turn, makes strongswan forget about the installed > interface, and "ipsec down" does not remove the interface. See here for the > current patch implementation: > https://bugs.debian.org/cgi-bin/bugreport.cgi?filename=0001-Added-support-for-the-resolvconf-framework-in-resolv.patch;att=1;msg=20;bug=664873 > > I suggest to change the code in invoke_resolvconf() to do the following: > > 1. Call "resolvconf --disable-updates" > 2. Call resolvconf the way it is currently in invoke_resolveconf(). This > has the effect of installing or deleting the interface without running the > update script, and the exit code returned by "pclose()" will tell you > whether the resolvconf install succeeded. > 3. Call "resolvconf --enable-updates" which will cause the postponed > update scripts to be run, and the errors here can be ignored or logged with > "DBG1()". > > 4. Return the pclose() return value from step 2. > > This way, strongswan will correctly register whether the interface has > been installed, and if it was installed, correctly remove it on "ipsec > down" even though one of the update scripts had failed. > > Does this seem sensible? > > Best Regards, > Corey Kasten > -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
resolvconf update script failure leads to forgotten device
Hi! I'm using strongswan 5.1.2-0ubuntu2.4 on ubuntu 14.04, and I noticed a scenario where resolvconf is run which correctly adds the interface, but when the triggered update scripts run, one of them fails, and resolvconf exits non-zero, which causes invoke_resolvconf() (in src/libhydra/plugins/resolve/resolve_handler.c) to report a failure, which in turn makes strongswan think the name server line failed to get installed. This, in turn, makes strongswan forget about the installed interface, and "ipsec down" does not remove the interface. See here for the current patch implementation: https://bugs.debian.org/cgi-bin/bugreport.cgi?filename=0001-Added-support-for-the-resolvconf-framework-in-resolv.patch;att=1;msg=20;bug=664873 I suggest to change the code in invoke_resolvconf() to do the following: 1. Call "resolvconf --disable-updates" 2. Call resolvconf the way it is currently in invoke_resolveconf(). This has the effect of installing or deleting the interface without running the update script, and the exit code returned by "pclose()" will tell you whether the resolvconf install succeeded. 3. Call "resolvconf --enable-updates" which will cause the postponed update scripts to be run, and the errors here can be ignored or logged with " DBG1()". 4. Return the pclose() return value from step 2. This way, strongswan will correctly register whether the interface has been installed, and if it was installed, correctly remove it on "ipsec down" even though one of the update scripts had failed. Does this seem sensible? Best Regards, Corey Kasten -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
