Bug#943735: resolvconf maintenance
Hi there Andrej, Good to hear that you'd like to maintain resolvconf which has been suffering badly from my neglect. You have my best wishes. If you have any questions or need any help then I am happy to oblige. My TODO list for resolvconf, which is now a couple of years old, is in debian/NOTES Cheers, Thomas
Bug#847440: [Resolvconf-devel] Bug#847440: pending
I will orphan the package if I can't meet my self-imposed deadline. I'll also RFA it again, although that didn't attract any interest on previous occasions. Please feel free to do a QA NMU. Regards, Thomas Op vr 22 feb. 2019 08:58 schreef Bernhard Schmidt : > Hi Thomas, > > having no time or motivation to work on a package is not a shame, but > could you please properly orphan the package then (or give us the > permission to do so if you don't want to read up on the procedure)? I'd > like to at least do a QA upload for Buster with the git repository > migrated to Salsa and #847440 fixed. > > I don't want to maintain it either (barely using it), but having it > officially orphaned would lower the bar for NMUs. > > Best Regards, > Bernhard >
Bug#847440: [Resolvconf-devel] Bug#847440: pending
Hi there, I am still the maintainer, at least on paper. After my attempt to get through the new maintainer process failed (several years ago now) I tried to find someone to take over as maintainer of resolvconf but I was not successful. (Know anyone who might be interested?) As I felt it was my duty I carried on as maintainer with a sponsor, but not being a member of the project my interest in Debian gradually declined and releases became less and less frequent. The importance of the package has also declined, especially now that the package is no longer part of Ubuntu base. I use Ubuntu, not Debian. Doing a new release has been on my TODO list for many months but it didn't have a high enough priority to get executed. Sometimes, the longer one avoids a task, the more one avoids it. I still want to do a new release in order to close the open bugs, none of which is RC. Setting a deadline should help. I hereby set a deadline for myself of the end of March 2019. I realize that is too late for Buster. Cheers, Thomas Hood Op do 21 feb. 2019 13:09 schreef Michael Prokop : > * Bernhard Schmidt [Sun May 07, 2017 at 10:57:24PM +0200]: > > On Thu, Dec 15, 2016 at 11:18:47AM +0000, Thomas Hood wrote: > > > > package resolvconf > > > tags 847440 pending > > > stop > > > You set this to Pending almost five months ago, do you still plan to > > apply this for Stretch? > > I'm re-asking the same question for buster. :) > We have resolvconf 1.79 in stable, testing and unstable, > its upload dating back to 2016-05-30. > > Is someone still working on resolvconf? > > regards, > -mika- > ___ > Resolvconf-devel mailing list > resolvconf-de...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/resolvconf-devel
Bug#887176: [Resolvconf-devel] Bug#887176: resolvconf should depend on e2fsprogs explicitly
Hi there, Is there any special reason not to add e2fsprogs as a dependency? Cheers, Thomas On Sat, 20 Jan 2018 at 01:45 Andreas Henriksson wrote: > Hello, > > On Sun, Jan 14, 2018 at 08:10:44PM +0100, Helmut Grohne wrote: > > Package: resolvconf > [...] > > /usr/share/resolvconf/dump-debug-info contains lsattr. According to file > it is a POSIX shell script, ASCII text executable > > This one uses lsattr, but guards the execution with checking if it > exists first, so no strict dependency needed for this. Basing my > assumption on the file name a Suggests would likely be more warranted > than a Recommends. > > > DEBIAN/postinst contains chattr and lsattr. According to file it is a > POSIX shell script, ASCII text executable > [...] > > The postinst maintainerscript does indeed use both chattr and lsattr. > Both of them are guarded with the debconf variable > resolvconf/linkify-resolvconf having to be TRUE, which is the default. > A dependency is thus currently needed here! > > An alternative approach if there's a reason to consider avoiding adding > a strict dependency would be to refactor the debian/config to check > for chattr/lsattr existance and if they're not available force the > debconf variable resolvconf/linkify-resolvconf to false (likely together > with a debconf prompt stating that). I'm not sure if the extra > complexity is worth it and it would be great if maintainer(s) could > comment on this. > > My conclusion is that a e2fsprogs dependency is likely the best > solution. > > Regards, > Andreas Henriksson > > ___ > Resolvconf-devel mailing list > resolvconf-de...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/resolvconf-devel >
Bug#729665: [Resolvconf-devel] Bug#729665: Please implement an option that causes resolvconf to list VPN nameservers exclusively
Thanks for the suggestion. I'm going to read up on this. Cheers, Thomas Hood On Tue, Apr 18, 2017 at 7:57 PM Jason A. Donenfeld wrote: > This would be accomplished by the recommendation in #860564. > > ___ > Resolvconf-devel mailing list > resolvconf-de...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/resolvconf-devel >
Bug#856015: [Resolvconf-devel] Bug#856015: may be dnsmasq issue
package resolvconf severity 856015 normal retitle 856015 Fails in networks with non-equivalent nameservers reassign 856015 dnsmasq merge 856015 675319 stop Hi. This is a known behavior of dnsmasq. -- Thomas On Mon, Feb 27, 2017 at 11:45 AM Daniel Pocock wrote: > > > I ran tcpdump on both the host and the OpenWRT router until another one > of these failures occurred. > > The problem appears to be in the router, but as it is running dnsmasq as > well, just like resolvconf, resolvconf users could also be impacted by > the same issue depending on their configuration. > > The router was sending the query to 5 different servers. One of them is > not recursive and sends a response with the REFUSED error code. > > If that is the first response dnsmasq receives, it sends a refused error > response back to the client. It doesn't appear to wait for the other > responses or they didn't come quickly enough. > > dnsmasq version on the router is 2.73-1 > > dnsmasq version on the Debian host is 2.72-3+deb8u1 > > stretch appears to have 2.76-5 > > Upstream changelog for 2.76-5 doesn't mention the issue. > > Query sent on the dnsmasq mailing list > > http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2017q1/011261.html > > ___ > Resolvconf-devel mailing list > resolvconf-de...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/resolvconf-devel >
Bug#783596: resolvconf /e/n/i dns-* option only works in last of homonymous iface def'ns
Hi there, The change you suggested is at best only a partial solution: second and later records non-overwrite the first record only if they are completely empty. Furthermore an empty record is valid and possibly wanted in the corner case where there is a stale file in the database. As things stand you have to put DNS information in the last logical interface definition. That works, even if it's alas not what the user might expect. I have explained earlier why this is hard to change. The existing behavior should at least be documented. Can you supply a patch or text snippet for resolvconf(8)? Cheers -- Thomas
Bug#847440: [Resolvconf-devel] Bug#847440: resolvconf: run resolvconf service before any networking service
Hi and thanks for the patch. Did you test it in Debian? -- Thomas
Bug#776778: Still to do
Remaining to do to eliminate the incompatibility between dnssec-trigger and resolvconf * Change dnssec-trigger such that it does not touch /etc/resolv.conf directly when /sbin/resolvconf is present on the filesystem * Replace "Breaks: resolvconf" with "Breaks: resolvconf (<< 1.79)" and "Suggests: resolvconf (>= 1.79)" -- Thomas
Bug#776778: #777228 done
> I wrote: >> We can file a new bug report requesting that unbound include the file in question. > > I have filed bug report #777228. As of version 1.5.7-2 the unbound package includes the file in question; #777228 has been closed. -- Thomas
Bug#819498: [Resolvconf-devel] Bug#819498: /etc/resolvconf/update.d/resolvconf-update-bind called without CAP_CHOWN from n-m
Unless bind checks the ownership for some reason, it should be OK to just remove the chown. Will do for the next release, whose upload I have just requested from my faithful sponsor. -- Thomas On 30 March 2016 at 11:12, Marc Haber wrote: > On Wed, Mar 30, 2016 at 09:35:32AM +0200, Thomas Hood wrote: > > I am happy to remove the chown from the (example) script. But are you > sure > > that bind processes the file if the owner is not root:bind? > > Mine takes it happily with root:staff. I guess it won't if it can't > read the file, so the script should make sure to create the file world > readable, which might introduce a privacy problem iff private > information is in the file. > > Maybe take a look at the source file and spew an error if it isn't > world readable, so that the local admin can decide whether to make > the source file world readable or to add CAP_CHOWN to network-manager. > > I do not have an idea if a shell script can check for certain > capabilities, so the script might want to add error handling for the > chown like > > if ! stat --format="%A" "$TMP_FILE" | grep -q '...r..'; then > if ! chown "$TMP_FILE"; then > echo >&2 "Error: cannot chown $TMP_FILE, capability missing, see > #819498" > fi > fi > > (untested) > > Greetings > Marc > > -- > > - > Marc Haber | "I don't trust Computers. They | Mailadresse im Header > Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 > Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 >
Bug#819498: [Resolvconf-devel] Bug#819498: /etc/resolvconf/update.d/resolvconf-update-bind called without CAP_CHOWN from n-m
Hi and thanks for the bug report. I am happy to remove the chown from the (example) script. But are you sure that bind processes the file if the owner is not root:bind? -- Thomas
Bug#802845: /etc/resolvconf/update.d/dnsmasq
The offending script is in the dnsmasq package. I agree that RUN_DIR should be /run and not /var/run. -- Thomas Hood
Bug#797652: wontfix
package resolvconf tags 797652 wontfix stop Dear bug report submitter, First of all, thanks for the suggestion. In general services shouldn't implement their own enable/disable mechanisms; that's what init systems are for. Resolvconf isn't a typical service, however. It's really a bit of infrastructure — standard in Ubuntu, optional in Debian. If you don't want it then you should remove the "resolvconf" package. If you only want to disable resolvconf's management of /etc/resolv.conf then simply delete the symbolic link at /etc/resolv.conf. -- Thomas
Bug#791978: #181: Re: Bug#791978: interfaces-order is being ignored
On Jul 10, 2015 11:04 PM, "Stephen Crowley" wrote: > > I think I might know what the problem is... the proprietary f5 client > has some thread that sits in the background and monitors for changes > to resolv.conf and routing tables and "fixes" them. Ugh. Is there any way to switch off that feature? > I apologize for the > false bug report. No need to apologize, it's good to alert me and others to a package that doesn't play nicely with resolvconf. Let us know here if you find a good solution. -- Thomas
Bug#791978: interfaces-order is being ignored
> resolvconf is not putting the tun0 resolvers > below that of eth* even though tun* is supposed to take precedence I don't understand this. If tun* is supposed to take precedence over eth* then resolvconf *shouldn't* put the tun0 resolver addresses *below* those of eth* in resolv.conf; resolvconf should put the tun0 resolver addresses *above* those of eth*. And resolvconf does what it should do. According to interface-order, tun* is listed before eth*. The record /run/resolvconf/interface/tun0.f5 contains nameserver 192.168.1.1 nameserver 10.10.10.21 nameserver 10.10.10.20 search canaccord.com whereas the record /run/resolvconf/interface/eth0.f5 contains search canaccord.com nameserver 10.10.10.21 nameserver 10.10.10.20 and the record /run/resolvconf/interface/eth3.dhclient contains the following. nameserver 192.168.1.1 The information from tun0.f5 should take precedence. And that is what we see in resolv.conf. # Dynamic resolv.conf(5) file for glibc resolver(3) ... # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES ... nameserver 192.168.1.1 nameserver 10.10.10.21 nameserver 10.10.10.20 search canaccord.com If there is a problem then the problem is with the contents of the record /run/resolvconf/interface/tun0.f5 which comes from the program that calls resolvconf to create that record. Which interface configuration utility writes that record? What is "f5"? -- Thomas
Bug#791978: More info, pls
Hi and thanks for the report. Please run this command /usr/share/resolvconf/dump-debug-info when you are experiencing the problem and post the output here. -- Thomas Hood
Bug#787457: Cannot reproduce
package resolvconf severity 787457 minor stop Experiment reveals that running "update-rc.d test defaults" on wheezy does not result in a traditional default field of symlinks when the initscript has LSB headers that specify otherwise; update-rc.d obeys the LSB header spec. So the aforementioned dependency on sysv-rc is not needed to prevent the generation of a traditional default field of symlinks in wheezy. So this bug is low severity. -- Thomas
Bug#787457: Needs fixing
Experiment. I create a bogus rc symlink for resolvconf. ln -s ../init.d/resolvconf /etc/rc2.d/S01resolvconf Then I run update-rc.d with an unrelated initscript. update-rc.d alsa-utils defaults After this, the resolvconf symlink in rc2.d is still present but has been renumbered to S11resolvconf! Bad. I have added code to the postinst to do "update-rc.d resolvconf remove" if there are any S links for resolvconf in rc[1-5]. -- Thomas
Bug#787457: Resolvconf in Jessie missing dependency on sysv-rc
Package: resolvconf Version: 1.76.1 Severity: normal Control: found -1 1.76 Control: found -1 1.75 Versions 1.75 through 1.76.1 of resolvconf assume the use of a recent version of sysv-rc update-rc.d which does the right thing when "update-rc.d resolvconf defaults" is run. The right thing is to create only the following symlinks as instructed by the LSB header in the initscript. /etc/rc0.d/K??resolvconf /etc/rc6.d/K??resolvconf /etc/rcS.d/S??resolvconf The wrong thing is to create the traditional default field of symlinks in runlevels 1 through 5. /etc/rc1.d/S??resolvconf /etc/rc2.d/S??resolvconf etc. The wrong thing is bad because it causes "/etc/init.d/resolvconf start" to be done late in the boot process (at entry to the multi-user runlevel). That command clears resolvconf's database whereas the database should be cleared only *before* any network interfaces are brought up. I suspect that the dependency should be on sysv-rc 2.88dsf-42 or later. Presumably that means having a Breaks sysv-rc (<< 2.88dsf-42). Unfortunately, no dependency was declared on sysv-rc. So there is at the very least a formal bug. Although Jessie includes 2.88dsf-59, Wheezy includes only 2.88dsf-41+deb7u1 which allows for a scenario where resolvconf gets upgraded first and its postinst runs the old update-rc.d. Whether or not this results in the Wrong Thing being done requires investigation. -- Thomas Hood
Bug#783596: Not a bug
On 28 April 2015 at 16:28, Andrew Shadura wrote: > That isn't true: ifupdown calls all hook scripts for every entry that > many times as is the number of entries. Ah, sorry, I didn't know that. (I thought that ifupdown would combine the information and call the hook scripts only once.) > It's a bug in resolvconf's hook scripts, they shouldn't override > interface settings if no recognised option is specified. The hook scripts were written for a world in which ifupdown configures a "physical" interface as exactly one "logical" interface and calls each hook script exactly once, supplying it via environment variables with complete information about the configured physical interface. Then, in particular, if IF_DNS_NAMESERVER and IF_DNS_NAMESERVERS are empty then no nameserver addresses are specified for that interface. The world has changed so that sometimes ifupdown configures a physical interface simultaneously as two or more homonymous logical interfaces and calls each hook script that many times (i.e., once per logical interface). Thus it supplies each hook script process with only partial information about the configured physical interface. In particular, in the new world, IF_DNS_NAMESERVER and IF_DNS_NAMESERVERS being empty does not imply that no nameserver addresses are specified for the interface. I understand that the desired behavior is that one should be able to put dns-* options in any of the homonymous logical interface definitions. However, I don't immediately see an easy way to implement this. One way to implement it is for the resolvconf hook script to write out a distinct record for each logical interface. These records would get combined as usual. The difficulty is in naming this record. Distinct logical interfaces no longer have distinct names, so the logical interface name no longer suffices to distinguish the records. Perhaps the IP address could also be used? But is it not legal to have two logical interface definitions with the same name *and* IP address? The other way to implement it is for resolvconf to accumulate information in a single record across hook script runs. The difficulty then is in reliably distinguishing between (1) information left by one of the earlier hook script processes for this "run" (which should be preserved) and (2) stale information from an earlier run (which should be discarded). Any suggestions? -- Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#783596: Not a bug
reassign 783596 ifupdown retitle 783596 ifupdown elides info from all but last homonymous iface def'n stop OK, thanks for the reference. I didn't know that ifupdown had been enhanced in that way. ifupdown (0.7~alpha4) experimental; urgency=low [...] * Allow multiple interface definitions to ease work with multiple IP per interface. [...] -- Andrew O. Shadura Wed, 08 Jun 2011 12:10:14 +0300 The unexpected behavior you reported arises from a bug or limitation in ifupdown: when there are multiple logical interface definitions with the same name it only sends information from the last definition to hook scripts. If this gets fixed or changed then resolvconf will work the way you expected. -- Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#783596: Not a bug
Hi there and thanks very much for your report. > this does not work (/etc/resolv.conf only contains the header and no > nameservers): > > iface pan0 inet static > address 192.168.1.2 > netmask 255.255.255.0 > dns-nameservers 8.8.8.8 8.8.4.4 > > iface pan0 inet static > address 192.168.252.1 > netmask 255.255.255.0 It is, so far as I know, not intended that multiple logical interfaces be defined with the same name, as you do with the several logical interface definitions for "pan0". Each logical interface should have a distinct name. > I see that the method without aliases is preferred as the other one is called > "legacy" Where did you read this? -- Thomas Hood -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#777228: Bug report with paths corrected
Package: unbound
Version: 1.4.22-3
Severity: wishlist
Please add the hook script /usr/lib/resolvconf/dpkg-event.d/unbound.
The purpose of this script is to cause unbound to take notice of the
installation or removal of the resolvconf package. If resolvconf has
been installed then unbound should register its listen IP address with
resolvconf.
See below for an except from resolvconf's README file giving general
information about resolvconf packaging-event hook scripts.
For unbound, the following script should suffice. However, if there is
a more efficient way of causing unbound to register its listen address
with resolvconf then of course do it that way.
=== /usr/lib/resolvconf/dpkg-event.d/unbound ===
#!/bin/sh
# Resolvconf packaging event hook script for the unbound package
restart_unbound() {
if which invoke-rc.d >/dev/null 2>&1 ; then
invoke-rc.d unbound restart
elif [ -x /etc/init.d/unbound ] ; then
/etc/init.d/unbound restart
fi
}
case "$1" in
install) restart_unbound ;;
esac
=== Excerpt from resolvconf README ===
Any package, foo, that supports supplying information to resolvconf should
include a hook script /usr/lib/resolvconf/dpkg-event.d/foo which, when called
with the argument "install", takes whatever actions are necessary to cause the
program(s) in foo to supply their nameserver information to resolvconf; and
when called with the argument "remove" takes whatever actions are appropriate
given that the resolvconf package has been removed.
The hook script thus has the following form.
#!/bin/sh
#
# /usr/lib/resolvconf/dpkg-event.d/foo
#
# The resolvconf dpkg-event hook script for the foo package
#
if foo_is_running ; then
if [ "$1" = "install" ] ; then
foo-ctrl send-nameserver-info-to-resolvconf
elif [ "$1" = "remove" ] ; then
...
fi
fi
If foo is controlled by an initscript whose methods take appropriate actions
conditional upon resolvconf's presence then something like the following might
be appropriate.
force_reload_foo() {
if which invoke-rc.d >/dev/null 2>&1 ; then
invoke-rc.d foo force-reload
elif [ -x /etc/init.d/foo ] ; then
/etc/init.d/foo force-reload
fi
}
case "$1" in
install|remove) force_reload_foo ;;
esac
The hook script is called (with argument "install") from resolvconf's postinst
"configure" method and (with "remove") from resolvconf's postrm "remove"
method.
Foo's hook script is called with argument "install" if and only if foo is
fully installed both when resolvconf's preinst install runs and when its
postinst configure runs. The hook script is called with argument "remove" if
and only if foo is fully installed when resolvconf's postrm remove runs.
The hook script must be owned by root and have its execute permission bit set
and must have the same name as the package that owns it.
Arguments other than "install" and "remove" are reserved for future use and
must be silently ignored.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#777228: Please add resolvconf packaging-event hook script
Aak, the correct path is /usr/lib/resolvconf/dpkg-event.d/. The other path beginning with /etc is obsolete and only got mentioned because I copypasted text from another message. My apologies! -- Thomas Op 21 feb. 2015 23:31 schreef "Robert Edmonds" : > Thomas Hood wrote: > > Please add the hook script /etc/resolvconf/packaging-event.d/unbound. > > [...] > > Any package, foo, that supports supplying information to resolvconf > should > > include a hook script /usr/lib/resolvconf/dpkg-event.d/foo [...] > > Hi, > > Can you clarify the path to the hook script that unbound should use? > Should it be /etc/resolvconf/packaging-event.d/unbound or > /usr/lib/resolvconf/dpkg-event.d/unbound? > > -- > Robert Edmonds > edmo...@debian.org >
Bug#776778: TODO
Am I correct in tentatively concluding that the only thing that has to be done in order to make dnssec-trigger work correctly with resolvconf and thus grant this wish (#776778) is to stop dnssec-trigger from touching /etc/resolv.conf directly when /sbin/resolvconf is present on the filesystem? So far as I can see dnssec-trigger doesn't have to do anything further with respect to resolv.conf. * Unbound itself registers its listen address with resolvconf for inclusion in resolv.conf. * Resolvconf collects search domain names from the DHCP client for inclusion in resolv.conf. -- Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#776778: Report filed
I wrote: > We can file a new bug report requesting that unbound include > the file in question. I have filed bug report #777228. http://bugs.debian.org/777228 -- Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#700850: Hangs?
Matthijs Möhlmann wrote: > Ok, after installing the package with the pdns-recursor > script installed in /usr/lib/resolvconf/dpkg-event.d: > > Now I tried to purge the resolvconf package using the following > command: > > aptitude purge resolvconf > > The command never returns, a zombie process was created > and nothing else happened then. Aptitude runs dpkg which runs the resolvconf postrm which runs the script with argument "remove" which does "invoke-rc.d pdns-recursor force-reload". So if the apt command hangs then I would suspect that it's the pdns-recursor initscript that is doing something incorrectly. That should be investigated, also because it could be a problem quite independently of this report. Cheers, -- Thomas Hood -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#777228: Please add resolvconf packaging-event hook script
Package: unbound
Version: 1.4.22-3
Severity: wishlist
Please add the hook script /etc/resolvconf/packaging-event.d/unbound.
The purpose of this script is to cause unbound to take notice of the
installation or removal of the resolvconf package. If resolvconf has
been installed then unbound should register its listen IP address with
resolvconf.
See below for an except from resolvconf's README file giving general
information about resolvconf packaging-event hook scripts.
For unbound, the following script should suffice. However, if there is
a more efficient way of causing unbound to register its listen address
with resolvconf then of course do it that way.
=== /etc/resolvconf/packaging-event.d/unbound ===
#!/bin/sh
# Resolvconf packaging event hook script for the unbound package
restart_unbound() {
if which invoke-rc.d >/dev/null 2>&1 ; then
invoke-rc.d unbound restart
elif [ -x /etc/init.d/unbound ] ; then
/etc/init.d/unbound restart
fi
}
case "$1" in
install) restart_unbound ;;
esac
=== Excerpt from resolvconf README ===
Any package, foo, that supports supplying information to resolvconf should
include a hook script /usr/lib/resolvconf/dpkg-event.d/foo which, when called
with the argument "install", takes whatever actions are necessary to cause the
program(s) in foo to supply their nameserver information to resolvconf; and
when called with the argument "remove" takes whatever actions are appropriate
given that the resolvconf package has been removed.
The hook script thus has the following form.
#!/bin/sh
#
# /usr/lib/resolvconf/dpkg-event.d/foo
#
# The resolvconf dpkg-event hook script for the foo package
#
if foo_is_running ; then
if [ "$1" = "install" ] ; then
foo-ctrl send-nameserver-info-to-resolvconf
elif [ "$1" = "remove" ] ; then
...
fi
fi
If foo is controlled by an initscript whose methods take appropriate actions
conditional upon resolvconf's presence then something like the following might
be appropriate.
force_reload_foo() {
if which invoke-rc.d >/dev/null 2>&1 ; then
invoke-rc.d foo force-reload
elif [ -x /etc/init.d/foo ] ; then
/etc/init.d/foo force-reload
fi
}
case "$1" in
install|remove) force_reload_foo ;;
esac
The hook script is called (with argument "install") from resolvconf's postinst
"configure" method and (with "remove") from resolvconf's postrm "remove"
method.
Foo's hook script is called with argument "install" if and only if foo is
fully installed both when resolvconf's preinst install runs and when its
postinst configure runs. The hook script is called with argument "remove" if
and only if foo is fully installed when resolvconf's postrm remove runs.
The hook script must be owned by root and have its execute permission bit set
and must have the same name as the package that owns it.
Arguments other than "install" and "remove" are reserved for future use and
must be silently ignored.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#776778: Please play nicely with resolvconf
On 5 February 2015 at 21:28, Thomas Hood wrote: > Second, it might be simpler just for resolvconf to detect that > dnssec-triggerd is running and, in that case, to override the > immutability attribute when installing the symlink at > /etc/resolv.conf. I have committed the change to resolvconf source so that resolvconf's postinst will remove the immutability attribute from /etc/resolv.conf at configure time if the dnssec-trigger package is installed. This new behavior will appear in (post-Jessie) version 1.77. So a future resolvconf-compatible version of dnssec-trigger should declare "Breaks: resolvconf (<< 1.77)" instead of the current not-versioned "Breaks: resolvconf". Dnssec-trigger could also "Suggests: resolvconf (>= 1.77)". > So (3) resolvconf should then cause > unbound to restart so that unbound notices resolvconf's presence and > registers its address with resolvconf. The way to do this is for the > unbound package to include a script > /usr/lib/resolvconf/dpkg-event.d/unbound which restarts unbound. I should have mentioned that this issue is independent of #776778. We can file a new bug report requesting that unbound include the file in question. Already on my TODO list (... in the resolvconf source tree in the debian/NOTES file: http://anonscm.debian.org/cgit/resolvconf/resolvconf.git/tree/debian/NOTES). -- Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#776778: Please play nicely with resolvconf
On 5 February 2015 at 16:35, Axel Beckert wrote: > Ondřej Surý wrote: >> There's already a unblock bug filled as well. Great! >> Then we need to come up with solution that doesn't break resolvconf when >> installing it after dnssec-trigger is already installed. > > Just an idea, but what about resolvconf checking in its postinst if > dnssec-triggerd is available and if so restarting it first? Then > dnssec-triggerd would notice that resolvconf is installed (as > /sbin/resolvconf already exists) and talks to resolvconf instead > making /etc/resolv.conf immutable again. Well, first, if resolvconf is installed then dnssec-trigger should refrain from any further futzing with /etc/resolv.conf. Thus any code in the dnssec-trigger package that futzes with /etc/resolv.conf should be bracketed with the equivalent of "if ! [ -x /sbin/resolvconf ] ; then futz ; fi". It shouldn't be necessary to restart dnssec-trigger for it to behave according to the newfound presence of resolvconf. Second, it might be simpler just for resolvconf to detect that dnssec-triggerd is running and, in that case, to override the immutability attribute when installing the symlink at /etc/resolv.conf. So when dnssec-trigger has been installed and resolvconf is subsequently installed, (1) /sbin/resolvconf appears on the filessystem causing dnssec-trigger to refrain from any further futzing with /etc/resolv.conf; (2) resolvconf's postinst deimmutabilizes /etc/resolv.conf and installs the symlink. On installation, before the next reboot, resolvconf includes existing nameserver information in its database, so the information about the local "unbound" instance will not be lost. However, this information may not be prioritized correctly. So (3) resolvconf should then cause unbound to restart so that unbound notices resolvconf's presence and registers its address with resolvconf. The way to do this is for the unbound package to include a script /usr/lib/resolvconf/dpkg-event.d/unbound which restarts unbound. Resolvconf runs the script /usr/lib/resolvconf/dpkg-event.d/foo at postinst time for each package foo (having such a script) that is already installed at resolvconf preinst time. See dnsmasq for an example of a package which has such a resolvconf packaging event hook script. I don't know dnssec-trigger very well. It it possible that it does other things that conflict with what resolvconf does. -- Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#776778: Please play nicely with resolvconf
On 4 February 2015 at 12:00, Ondřej Surý wrote: > On Wed, Feb 4, 2015, at 11:14, Axel Beckert wrote: >> Ondřej Surý wrote: >> > do you think that we can push the resolvconf compatibility to jessie? >> > >> > I see two possible paths here: >> > >> > a) add Breaks: resolvconf >> >> That's ok-ish. It would be the short-hack temporary solution and >> likely suitable for Jessie. > > okay, this is fairly easy Please do this quickly, closing #776776, and push to Jessie. For post Jessie we can work on making dnssec-trigger compatible with resolvconf, which is bug report #776778. On that topic Dnssec-trigger should certainly not Pre-Depend on resolvconf and should also not Depend on resolvconf. When resolvconf is installed, dnssec should refrain entirely from touching /etc/resolv.conf. This goes for install time and for run time. > [...] unless there's a way how dnssec-trigger can hook into resolvconf > postinst, it won't play well. > > Also we will need to have lo.dnssec in first place in the list of > priorities and a way how to tell resolvconf to stop after localhost > (e.g. trigger TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS when > dnssec-trigger is installed). As I mentioned earlier, unbound itself already registers the nameserver address 127.0.0.1 with record name "lo.unbound". This matches the pattern "lo.!(pdns|pdns-recursor)" in /etc/resolvconf/interface-order and thus gets a high priority. So the address 127.0.0.1 will be listed before external addresses. If it turns out that unbound's record needs a different priority than it now has then we (resolvconf maintainers, in a new release of resolvconf) can add a line "lo.unbound" at the right place in that file. TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS=yes is the default, so we don't need to do anything new in order to cause there to be no further addresses listed after unbound's 127.0.0.1. -- Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#776778: Please play nicely with resolvconf
Currently dnssec-trigger is not resolvconf-compatible. For one thing, dnssec-triggerd writes /etc/resolv.conf directly and sets the immutability attribute on the file, causing resolvconf installation to fail and resolvconf to fail to function as designed. Let this report track the request that dnssec-trigger be made resolvconf-compatible. To be resolvconf-compatible, dnssec-trigger executables should refrain from writing to /etc/resolv.conf. Looking at unbound, I see that its initscript already communicates correctly with resolvconf. So there may be no need at all for dnssec-trigger itself to futz with /etc/resolv.conf. -- Thomas Hood -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#776776: Breaks resolvconf
Let this report (#776776) track the issue that dnssec-trigger breaks resolvconf and therefore must declare a Breaks: resolvconf. This can and should be fixed immediately, for jessie. -- Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#776776: Bug in resolvconf?
The dnssec-trigger daemon sets the immutability attribute on a file /etc/resolv.conf which it writes out. Evidently, dnssec-trigger is not resolvconf-compatible. The immediate, straightforward solution is for the dnssec-trigger package to Conflict with the resolvconf package. At least this should be done for jessie. The next thing to do is to look at the possibility of making dnssec-trigger resolvconf-compatible. To be resolvconf-compatible, dnssec-trigger should not write to /etc/resolv.conf directly. Instead dnssec-trigger, or more probably unbound itself, should do something like the following after the local "unbound" process is started. echo "nameserver 127.0.0.1" | resolvconf -a lo.unbound And the following before the process is stopped. resolvconf -d lo.unbound When 127.* is one of the nameserver addresses resolvconf by default doesn't list any further addresses. So once the above has been done it may not be necessary to change the resolvconf package. However, if necessary it would also be possible to change the resolvconf package so that, for example, it gives the lo.unbound record special treatment. -- Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#776778: Don't play well together
Is dnssec-trigger meant to work with resolvconf or does it conflict (functionally) with resolvconf, so that it should declare a Conflicts: resolvconf? -- Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#776776: Bug in resolvconf?
Hi and thanks for the report. Do you think that this failure means that there is a bug in the resolvconf package? -- Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775356: New patch
OK, I've pushed code to git as described by the attached patch with
the resulting attached /etc/dhcp/dhclient-enter-hooks.d/resolvconf.
Will be released as 1.77.
--
Thomas
diff --git a/debian/changelog b/debian/changelog
index eb219dd..7f925b8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+resolvconf (1.77) unstable; urgency=medium
+
+ * [eb81ca0] Eliminate bashisms.
+Thanks to Michael Gilbert (Closes: #775356)
+
+ -- Thomas Hood Fri, 23 Jan 2015 21:46:34 +0100
+
resolvconf (1.76) unstable; urgency=low
* resolvconf.service: Install into sysinit.target, not into
diff --git a/etc/dhcp/dhclient-enter-hooks.d/resolvconf b/etc/dhcp/dhclient-enter-hooks.d/resolvconf
index 529504b..72b2be7 100644
--- a/etc/dhcp/dhclient-enter-hooks.d/resolvconf
+++ b/etc/dhcp/dhclient-enter-hooks.d/resolvconf
@@ -23,7 +23,7 @@ if [ -x /sbin/resolvconf ] ; then
# It gets run later (or, in the TIMEOUT case, MAY get run later)
make_resolv_conf() {
local R
- local nameserver
+ local N
R=""
if [ "$new_domain_name_servers" ] && [ "$new_domain_name" ] ; then
R="${R}domain $new_domain_name
@@ -33,8 +33,8 @@ if [ -x /sbin/resolvconf ] ; then
R="${R}search $new_domain_search
"
fi
- for nameserver in $new_domain_name_servers ; do
-R="${R}nameserver $nameserver
+ for N in $new_domain_name_servers ; do
+R="${R}nameserver $N
"
done
[ ! "$interface" ] || echo -n "$R" | /sbin/resolvconf -a "${interface}.dhclient"
@@ -45,27 +45,27 @@ if [ -x /sbin/resolvconf ] ; then
# It gets run later (or, in the TIMEOUT case, MAY get run later)
make_resolv_conf() {
local R
- local nameserver
- local zone_id
+ local N
+ local N_LOW
+ local ZONE_ID
R=""
if [ "$new_dhcp6_name_servers" ] && [ "$new_dhcp6_domain_search" ] ; then
R="${R}search $new_dhcp6_domain_search
"
fi
- shopt -s nocasematch
- for nameserver in $new_dhcp6_name_servers ; do
+ for N in $new_dhcp6_name_servers ; do
# If the nameserver has a link-local address
# then add a zone ID (interface name) to it.
-if [[ "$nameserver" =~ ^fe80:: ]] ; then
- zone_id="%$interface"
+N_LOW="$(echo "$N" | tr '[:upper:]' '[:lower:]')"
+if expr "$N_LOW" : ^fe80:: >/dev/null ; then
+ ZONE_ID="%$interface"
else
- zone_id=""
+ ZONE_ID=""
fi
-R="${R}nameserver $nameserver$zone_id
+R="${R}nameserver $N$ZONE_ID
"
done
- shopt -u nocasematch
[ ! "$interface" ] || echo -n "$R" | /sbin/resolvconf -a "${interface}.ip6.dhclient"
}
;;
resolvconf
Description: Binary data
Bug#775356: Evolved patch
Here's a cosmetically evolved patch which I'll commit and release
shortly. Thanks!
--
Thomas
diff --git a/etc/dhcp/dhclient-enter-hooks.d/resolvconf b/etc/dhcp/dhclient-enter-hooks.d/resolvconf
index 529504b..cf61615 100644
--- a/etc/dhcp/dhclient-enter-hooks.d/resolvconf
+++ b/etc/dhcp/dhclient-enter-hooks.d/resolvconf
@@ -45,27 +45,26 @@ if [ -x /sbin/resolvconf ] ; then
# It gets run later (or, in the TIMEOUT case, MAY get run later)
make_resolv_conf() {
local R
- local nameserver
- local zone_id
+ local N
+ local N_LOW
+ local ZONE_ID
R=""
if [ "$new_dhcp6_name_servers" ] && [ "$new_dhcp6_domain_search" ] ; then
R="${R}search $new_dhcp6_domain_search
"
fi
- shopt -s nocasematch
- for nameserver in $new_dhcp6_name_servers ; do
-
+ for N in $new_dhcp6_name_servers ; do
# If the nameserver has a link-local address
# then add a zone ID (interface name) to it.
-if [[ "$nameserver" =~ ^fe80:: ]] ; then
- zone_id="%$interface"
+N_LOW="$(echo "$N" | tr '[:upper:]' '[:lower:]')"
+if expr "$N_LOW" : ^fe80:: >/dev/null ; then
+ ZONE_ID="%$interface"
else
- zone_id=""
+ ZONE_ID=""
fi
-R="${R}nameserver $nameserver$zone_id
+R="${R}nameserver $N$ZONE_ID
"
done
- shopt -u nocasematch
[ ! "$interface" ] || echo -n "$R" | /sbin/resolvconf -a "${interface}.ip6.dhclient"
}
;;
Bug#773749: Resolvconf vs wicd
On 14 January 2015 at 16:18, Axel Beckert wrote: >> It's up to the admin to change things in /etc/. Programs that play >> around with things in /etc/ at runtime are not well behaved by Debian >> standards. > > Depends. I agree for anything in the maintainer scripts, but I > disagree for anything which can be seen as (configuration) editor. Configuration is what the administrator does before starting a service, not what a program does to maintain state at runtime. As the FHS puts it: «The /etc hierarchy contains configuration files. A "configuration file" is a local file used to control the operation of a program; it must be static [...].» Configuration is thus by definition not dynamic. The list of nameserver addresses obtained via the most recent DHCP negotiation *is* dynamic. Admittedly it is difficult to draw a completely sharp distinction between configuration and state. But the idea behind it, which is clear enough, is that it should be possible to run a Debian machine with the root filesystem (including /etc) mounted read-only. These issues were discussed at some length in 2003, e.g., in the following thread. https://lists.debian.org/debian-devel/2003/03/msg00493.html So as dictated by the FHS, well-behaved programs do not change files in /etc at run time. Resolvconf was introduced in order to deal with the exceptional case of the file /etc/resolv.conf which is under /etc but has to be updated dynamically. In the resolvconf scheme, the dynamic file is on another filesystem and /etc/resolv.conf itself is a static but configurable symbolic link. -- Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#773749: Resolvconf vs wicd
On 14 January 2015 at 15:08, Vincent Lefevre wrote: > On 2015-01-14 14:14:22 +0100, Thomas Hood wrote: >> This is an allowed configuration (which is sometimes even useful). [...] > > OK, but this is a very atypical usage for users of wicd, whose goal > is to make things work without needing to be root. So what about an > option for /etc/default/resolvconf to force the link creation when > using dhclient? It's up to the admin to change things in /etc/. Programs that play around with things in /etc/ at runtime are not well behaved by Debian standards. > Otherwise the user needs to modify > /etc/dhcp/dhclient-enter-hooks.d/resolvconf to get this behavior. Now I have the feeling I'm missing something. Is there some reason that the symlink at /etc/resolv.conf has to be created at run time? Why can't the administrator just do "ln -s /run/resolvconf/resolv.conf /etc/resolv.conf" to restore the symlink? >> When the resolvconf package is initially installed it optionally and >> by default creates the symlink at /etc/resolv.conf, > > But the symlink got removed for some reason I ignore. I'm wondering > whether wicd was the cause (with the code related to the backup file). If so then there might be room for improvement in wicd or in its maintainer scripts. Wicd should not touch a symlink at /etc/resolv.conf. -- Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#773749: Resolvconf vs wicd
I just read bug report #514597 entitled "wicd does not work properly
with resolvconf" which was closed in version 1.5.9-2 with the message
that "07-add_resolvconf_support.patch added". Although I don't see
this patch in the current source tree, I do see references to the
resolvconf program which indicate that resolvconf is supported by wicd
to some extent.
$ grep -r resolvconf .
[...]
wicd-1.7.2.4/wicd/wnettools.py:""" Checks for the existence of
resolvconf."""
wicd-1.7.2.4/wicd/wnettools.py:self.resolvconf_cmd =
self._find_program_path("resolvconf")
wicd-1.7.2.4/wicd/wnettools.py:if self.resolvconf_cmd:
wicd-1.7.2.4/wicd/wnettools.py:cmd = [self.resolvconf_cmd,
'-a', self.iface]
We can at least conclude that the problem isn't that wicd has never
been adapted to cooperate with resolvconf.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#754084: More info please
Hi there. Can you please provide more information for Debian bug report #754084? I don't see what the problem is. -- Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#754084: [Resolvconf-devel] Bug#754084: stateless DHCPv6 info request doesn't set /etc/resolv.conf
On 30 July 2014 13:37, Harald Dunkel wrote: > Any news on this? Hi there. How 'bout sending us a patch? We'll include it in the upcoming release. -- Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#752521: Misleading man page statements and command names
Package: dh-systemd Version: 1.18 Severity: minor It is conventional to choose command names that express what the command does. Accordingly, it is conventional for debhelper command names to express what they do. For example, the dh_installinit command installs init files into package build directories. The dh-systemd package departs from this convention and gives its two debhelper scripts names that don't express what THEY do, but what the maintainer scripts that they generate do. The name of the dh_systemd_start script would conventionally be interpreted to suggest that the command starts something. But a debhelper command can do no such thing; it cannot start a service. It can only operate on a package. What it does is prepare the package so that it starts a unit when installed. According to debhelper conventions it should be called something starting with "dh_installsystemd". Whereas this departure from naming conventions is perhaps merely annoying, the man pages are downright misleading. dh_systemd_start(1p) says explicitly "dh_systemd_start is a debhelper program that is responsible for starting/stopping or restarting systemd unit files". First, it doesn't really make sense to speak of starting or stopping a file. Assuming it's the unit or service that's intended, the quoted statement isn't true. The program does not start a systemd unit, it just prepares other programs so that they will do that if they are run. Please fix the man page and rename the commands, leaving behind compatibility symlinks. Or else please explain how I am mistaken.
Bug#749405: [Resolvconf-devel] Bug#749405: Bug#749405: Current Status + Moving Forward?
Here is a patch which survives some basic testing. The tricky part turns out to be cleaning up after a change to the .service file. The available helpers don't handle this properly. In order to remove the obsolete symbolic link /etc/systemd/system/network.target.wants/resolvconf.service on a system without systemctl installed I resorted to using rm, but I don't know how evil that is. Comments, please. $ git diff debian/1.75..HEAD | cat - diff --git a/debian/changelog b/debian/changelog index 56d3e91..e2a1971 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +resolvconf (1.76) unstable; urgency=medium + + * resolvconf.service: Install into sysinit.target, not into +network.target (Closes: #749405) + + -- Thomas Hood Tue, 24 Jun 2014 11:50:33 +0200 + resolvconf (1.75) unstable; urgency=low * [49dedb8] Update man page re: "dns-nameserver" (Closes: 718021) diff --git a/debian/postinst b/debian/postinst index cb50a26..750e350 100755 --- a/debian/postinst +++ b/debian/postinst @@ -29,6 +29,18 @@ rm -f /etc/dhcp3/dhclient-enter-hooks.d/resolvconf # We use dh_installinit with --no-start #DEBHELPER# +### Clean up old symlinks from release 1.75: see #749405 ### +case "$1" in + configure) + if [ "$2" = "1.75" ] ; then + if which systemctl >/dev/null 2>&1 ; then + systemctl reenable resolvconf + else + rm -f /etc/systemd/system/network.target.wants/resolvconf.service || : + fi + fi + ;; +esac ### Create run-time directories and linkify ### # diff --git a/debian/resolvconf.service b/debian/resolvconf.service index 2a7285d..94fde69 100644 --- a/debian/resolvconf.service +++ b/debian/resolvconf.service @@ -11,4 +11,4 @@ ExecStart=/sbin/resolvconf --enable-updates ExecStop=/sbin/resolvconf --disable-updates [Install] -WantedBy=network.target +WantedBy=sysinit.target
Bug#749405: [Resolvconf-devel] Bug#749405: Current Status + Moving Forward?
On 23 June 2014 05:45, Nick Daly wrote: > What still needs to be done on this bug to resolve it? I think it just needs to be tested. Have you tested the proposed fix at all? -- Thomas
Bug#749405: [Resolvconf-devel] Bug#749405: resolvconf: /etc/resolvconf/run/interface either does not exist or is not a directory
Hi all, First of all I must apologize for the inconvenience caused by this bug. Martin, can you please comment? -- Thomas
Bug#700846: Service file
Martin, Cameron, Is resolvconf.service releasable? Should I now copy the file /lib/systemd/system/resolvconf.service from Martin Pitt's package to the Debian resolvconf package? Anything else you want to remind me to do when I include this file? -- Thomas
Bug#746941: Proposed solution
I would suggest that the initscript disable itself in the absence of some non-conffile file in the dnsmasq package. E.g., add a file /usr/lib/dnsmasq/package-is-installed to the package and add a line of code to the beginning initscript like the following. [ -e /usr/lib/dnsmasq/package-is-installed ] || exit 0 The file /usr/lib/dnsmasq/package-is-installed could include a comment explaining the purpose of the file. -- Thomas Hood
Bug#746941: Initscript fails to disable itself when the dnsmasq package is removed
Package: dnsmasq Version: 2.70-1 Severity: serious By means of test -x $DAEMON || exit 0 the initscript disables itself if /usr/sbin/dnsmasq is not installed. But this binary belongs to another package, dnsmasq-base. So the initscript disables itself if and only if that other package, dnsmasq-base, is not installed. Whereas Debian policy says (§9.3.2) that the initscript should disable itself if the package that owns the initscript is not installed. As a result of this error, someone who installs dnsmasq and later removes dnsmasq and not dnsmasq-base still has a fully functional dnsmasq package. A case of this was reported at https://bugs.launchpad.net/debian/+source/dnsmasq/+bug/1315741
Bug#746940: Cruft in initscript
Package: dnsmasq Version: 2.70-1 Severity: minor In the initscript the following three lines of code at the end of the "stop" function are superfluous. RETVAL="$?" [ "$RETVAL" = 2 ] && return 2 return "$RETVAL" They can be deleted without changing the behavior of the script.
Bug#700846: service file
Thanks for the service file, Cameron. Readers are invited to test and (if necessary) to improve it. -- Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#483098: Resolvconf - bind9 integration
First of all, thanks to Matt for adding his +1. :)
Please note, however, that the script from the old resolvconf package
is sub-optimal insofar as it writes a whole dynamic options file
instead of just the fragment comprising a forwarders{} statement.
I earlier wrote, "If the bind9 maintainers agree to include the
requested hook script then I am prepared to write and submit it here."
That offer still stands, but I have never heard a peep from the bind9
maintainers, so I have not submitted a modified script.
Please see my earlier comment for other details.
--
Thomas Hood
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#729665: Please implement an option that causes resolvconf to list VPN nameservers exclusively
Package: resolvconf Version: 1.74 Severity: wishlist A user wishes that when a VPN is established and registers a VPN nameserver address with resolvconf then only the VPN nameserver is used, not other nameservers. What is wished for is in effect an option USE_VPN_NAMESERVER_EXCLUSIVELY_IF_PRESENT. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#629100: winexe build
> On configure gave error of cli-ldap not found (but present). The latest code upstream works around this problem. > It still gives "the -z option missed" on winexesvc ld I don't get this message when building winexe according to the instructions in the upstream README on plain Wheezy + Samba 4.0.10 packages from unstable. -- Thomas Hood -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#721082: The patch (take 2)
Attached is a second version of the patch with a bug removed that was noticed by Nathan Stratton Treadway. The bug was that I had used 'echo' instead of 'exit' in two instances at the top of the script. Thanks to Nathan and my apologies for the bug. -- Thomas etc-openvpn-update-resolv-conf_20130905th1.patch Description: Binary data
Bug#721082: The patch
Attached is the patch for /etc/openvpn/update-resolv-conf. Below is the
patch with my commentary.
--
Thomas
>--- update-resolv-conf_ORIG2012-03-30 21:01:54.0 +0200
>+++ update-resolv-conf 2013-09-03 20:17:15.653120813 +0200
>@@ -5,50 +5,54 @@
> # up /etc/openvpn/update-resolv-conf
> # down /etc/openvpn/update-resolv-conf
> #
>-# Used snippets of resolvconf script by Thomas Hood
>-# and Chris Hanson
>+# Used snippets of resolvconf script by Thomas Hood and Chris Hanson.
Thomas Hood's e-mail address has changed.
> # Licensed under the GNU GPL. See /usr/share/common-licenses/GPL.
>-#
>-# 05/2006 chlau...@bnc.ch
That e-mail address is not longer active. We don't want a changelog in
every file anyway.
> #
> # Example envs set from openvpn:
>-# foreign_option_1='dhcp-option DNS 193.43.27.132'
>-# foreign_option_2='dhcp-option DNS 193.43.27.133'
>-# foreign_option_3='dhcp-option DOMAIN be.bnc.ch'
>+#
>+# foreign_option_1='dhcp-option DNS 193.43.27.132'
>+# foreign_option_2='dhcp-option DNS 193.43.27.133'
>+# foreign_option_3='dhcp-option DOMAIN be.bnc.ch'
>+#
Indent.
> [ -x /sbin/resolvconf ] || exit 0
>+[ "$script_type" ] || echo 0
>+[ "$dev" ] || echo 0
Exit if certain variables aren't set, otherwise the script will
simply screw up later.
>+split_into_parts()
>+{
>+ part1="$1"
>+ part2="$2"
>+ part3="$3"
>+}
Create a function to split up a string at space boundaries.
>-case $script_type in
>-up)
>- for optionname in ${!foreign_option_*} ; do
>- option="${!optionname}"
>- echo $option
>- part1=$(echo "$option" | cut -d " " -f 1)
>- if [ "$part1" == "dhcp-option" ] ; then
>- part2=$(echo "$option" | cut -d " " -f 2)
>- part3=$(echo "$option" | cut -d " " -f 3)
>- if [ "$part2" == "DNS" ] ; then
>- IF_DNS_NAMESERVERS="$IF_DNS_NAMESERVERS $part3"
>- fi
>- if [ "$part2" == "DOMAIN" ] ; then
>- IF_DNS_SEARCH="$IF_DNS_SEARCH $part3"
>+case "$script_type" in
>+ up)
>+ NMSRVRS=""
>+ SRCHS=""
>+ for optionvarname in ${!foreign_option_*} ; do
>+ option="${!optionvarname}"
>+ echo "$option"
>+ split_into_parts $option
>+ if [ "$part1" = "dhcp-option" ] ; then
>+ if [ "$part2" = "DNS" ] ; then
>+ NMSRVRS="${NMSRVRS:+$NMSRVRS }$part3"
>+ elif [ "$part2" = "DOMAIN" ] ; then
>+ SRCHS="${SRCHS:+$SRCHS }$part3"
Indent pattern. Initialize lists to null strings. Rename variable
'optionname' to 'optionvarname' for accuracy. Use quotation marks
unless it's necessary to omit them in order to obtain word splitting.
Split using our function instead of external programs. Compose list
without a leading space. Don't use IF_DNS* variable names which come
from ifupdown's resolvconf hook script.
> fi
> fi
> done
> R=""
>- for SS in $IF_DNS_SEARCH ; do
>- R="${R}search $SS
>+ [ "$SRCHS" ] && R="search $SRCHS
> "
>- done
Don't write multiple "search" options into the record since only
one is allowed. All domains should go on one line.
>- for NS in $IF_DNS_NAMESERVERS ; do
>+ for NS in $NMSRVRS ; do
> R="${R}nameserver $NS
> "
> done
>- echo -n "$R" | /sbin/resolvconf -a "${dev}.inet"
>+ echo -n "$R" | /sbin/resolvconf -a "${dev}.openvpn"
> ;;
>-down)
>- /sbin/resolvconf -d "${dev}.inet"
>+ down)
>+ /sbin/resolvconf -d "${dev}.openvpn"
> ;;
> esac
Use "openvpn" as the record name suffix and not "inet" which
belongs to ifupdown.
--
Thomas Hood
etc-openvpn-update-resolv-conf_20130903th1.patch
Description: Binary data
Bug#721082: Please better document the update-resolv-conf script and/or explain why it conflicts with ifup
On Mon, Sep 2, 2013 at 12:49 PM, Alberto Gonzalez Iniesta wrote: > Hi Thomas, Hi! > I'm happy to take patches to fix the possible problems. I'm no master of > resolvconf, so I didn't figure the issues this script may have. If you > have a fix in mind, it will be welcome, otherwise I'll have a look at it > as time permits. I was going to submit a patch, but with my finger perched over the proverbial Send button it occurred to me that there might be something tricky going on that I didn't understand — something odd relying on using the same identifiers as ifup and deliberately overwriting ifup's resolvconf record. So I decided to ask about that first. Especially in light of your answer, I think that the aforementioned oddities are just a result of the user copying the hook script from ifup and not changing identifiers. So I will submit the patch. :) -- Thomas Hood resolvconf maintainers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#344233: Bug still exists
In Debian 7 the host.conf(5) man page still describes the "order" option which has been inoperative for years and still refers to resolv+(8) which doesn't exist. And it still fails to mention nsswitch.conf. -- Thomas Hood -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#270368: Fwd: Bug still exists
In Debian 7 the host.conf(5) man page still describes the "order" option which has been inoperative for years and still refers to resolv+(8) which doesn't exist. And it still fails to mention nsswitch.conf. -- Thomas Hood -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#721082: Please better document the update-resolv-conf script and/or explain why it conflicts with ifup
Package: openvpn
Version: 2.3.2-4
Severity: wishlist
The openvpn package includes a script /etc/openvpn/update-resolv-conf.
Observation #1. The script adds nameserver addresses extracted from
openvpn dhcp-option strings to the variables IF_DNS_NAMESERVERS and
IF_DNS_SEARCH which are not initialized earlier in the script. These
same variables are used by ifup to pass information to its hook
scripts in /etc/network/if-*.d/.
Question #1. Does the script expect IF_DNS_NAMESERVERS and IF_DNS_SEARCH to
contain information when it starts? Information coming from ifup?
Observation #2. The script calls resolvconf as follows.
echo -n "$R" | /sbin/resolvconf -a "${dev}.inet"
Note that the resolvconf record name suffix ".inet" identifies ifup as
the sender of the information to resolvconf: this is one of ifup's
address family names; if /etc/network/interfaces contains "iface DEV
inet ..." then ifup will create a resolvconf record named DEV.inet.
Question #2. Is it intentional that update-resolv-conf overwrites
ifup's resolvconf record for the same device?
Depending on the answers, this will either become a wish that the
answers be included in documentation or comments, or a bug report.
--
Thomas Hood
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#720732: Please apply yet another patch to resolvconf update script
Package: dnsmasq Version: 2.66-4 Severity: wishlist Tags: patch Here is another change for dnsmasq's resolvconf update script whose purpose is better to prepare dnsmasq for use in a multi-dnsmasq-instance chain. A possible chain is, for example, dnsmasq serving libvirt | dnsmasq server | dnscrypt. Background: Two recent changes were: (1) to handle lo.dnscrypt specially; (2) to use list-records's "--after" option. The purpose of change #2 was to avoid including lo.other-dnsmasq which has higher priority than lo.dnsmasq, because we can expect other-dnsmasq's update script to include lo.dnsmasq and we don't want to create a loop. The purpose of change #1 was to forward to dnscrypt exclusively if it is available, since other nameservers are not equivalent. The present change generalizes the latter idea to all local nameservers. With the change, the update script stops including records after it includes any lo.* record. Under normal circumstances, lo.* records have the highest priority so under normal circumstances this has the consequence that if any lo.* record is listed by list-records, the script includes it and only it. Why is this right? Because the nameserver represented by any record after the first lo.* one is unlikely to be equivalent to the local nameserver represented by the lo.* one. And even if one is equivalent then there is no need to include it. This has low priority, just something to include in the next release whenever that happens for other reasons. Thanks! -- Thomas Hood etc-resolvconf-update-dnsmasq_20130824th1.patch Description: Binary data
Bug#663006: Retitle to RFP?
Given that this ITP was filed over a year ago, should it be retitled to RFP? -- Thomas Hood -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#716908: New version of patch for latest version of the update script
I just realized that I based the submitted patch on a version of the update script that isn't the latest in Debian. I based it on the latest version of the script in Ubuntu, which is out of date in comparison with Debian. Sorry about that! For the latest script in Debian the patch has to look like the following. - for F in $(/lib/resolvconf/list-records) ; do + for F in $(/lib/resolvconf/list-records --after "$MY_RECORD_NAME") ; do -- Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#718021: [Resolvconf-devel] Bug#718021: dns-nameservers vs dns-nameserver
On Tue, Jul 30, 2013 at 12:16 AM, Christoph Anton Mitterer < cales...@scientia.net> wrote: > it's just that we're probably better off with > suggesting people only one variant... so we can phase out the other on > the long term scale... > I'll make "dns-nameserver" the canonical one and "dns-nameservers" an explicitly supported alternative. The former is more consistent with the semantics of resolv.conf; the latter is too established to eliminate now. The other reason for recommending "dns-nameserver" is that it takes exactly one argument. This leaves room to extend the semantics of this option in the future. E.g., it might be useful to be able to say dns-nameserver 192.168.1.254 some.domain dns-nameserver 12.34.56.78 another.one dns-nameserver 8.8.8.8 meaning that *.some.domain queries should be routed to 192.168.1.254; *.another.one to 12.34.56.78 and the rest to 8.8.8.8. Dnsmasq supports this sort of query routing. Perhaps you should also ask the ifupdown people what they're going to > plan with their stanzas at the long term. > Especially for the "address" keyword a version that supports more > addresses per line would be reasonable... and I guess the concepts > should be kept more or less sync on all the /e/n/interfaces keywords. > Accepting multiple instances of an option in a stanza is a feature that was recently added to ifupdown. I presume that it will continue to be a supported feature in the future. :) -- Thomas
Bug#718232: update-rc.d: warning: start and stop actions are no longer supported
Thanks for the report. I wasn't aware of this issue. It seems the "start" and "stop" arguments are now deprecated. Roger Leigh announced this debian-devel. http://lists.debian.org/debian-devel/2013/05/msg01109.html We should go with the flow and stop using "start" and "stop". Here's the postinst code that needs to be changed. # Automatically added by dh_installinit if [ -x "/etc/init.d/resolvconf" ]; then update-rc.d resolvconf start 38 S . stop 89 0 6 . >/dev/null || exit $? fi # End automatically added section This arises from the following line in debian/rules. dh_installinit --no-start -- start 38 S . stop 89 0 6 . I see that Roger Leigh has opened a report (#717592) against debhelper asking that dh_installinit not pass through "start" and "stop". But we shouldn't rely on this. I guess the debian/rules line should be simply the following. dh_installinit --no-start -- Thomas
Bug#716908: Resolvconf 1.74 released
Hi Simon, Resolvconf 1.74 has been released with the "--after" feature which dnsmasq-resolvconf-hook-script_20130718th1.patch makes use of. BTW, the back story for this change can be read at https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1163147 Cheers, -- Thomas
Bug#717438: Recall latest pdnsd version
> Also tell me if there are any hot alternatives to pdnsd, Most people use dnsmasq for DNS caching. It is very well maintained. -- Thomas
Bug#716908: New patch
One curious thing about my proposal is that I called the new list-records option "--omit-up-to" instead of simply "--after". Some thinking did precede that. I thought: "If the option is called 'after' then that will suggest that if there is no record named like the argument then nothing will be printed, whereas list-records with that option prints the whole list if there is no record named like the argument; so I'll call it 'omit-up-to'." But now I am thinking again. *Should* list-records print the whole list if there is no record named like the argument? Well, in the case of dnsmasq it doesn't make much difference. If lo.dnsmasq is absent then dnsmasq is out of the resolving chain and then it doesn't matter whether it has a (too) long or a (too) short list of forwarding addresses. After dnsmasq starts it adds a record 'lo.dnsmasq' and its resolvconf update hook script gets run and generates the correct forwarders list. Sooo... please find attached a patch which differs from the previous patch in that the option given to list-records is "--after" instead of "--omit-up-to". Sounds better. -- Thomas dnsmasq-resolvconf-hook-script_20130718th1.patch Description: Binary data
Bug#716908: Please apply patch to dnsmasq's resolvconf hook script
Package: dnsmasq Version: 2.65 Severity: wishlist Please apply the attached patch to dnsmasq's resolvconf hook script /etc/resolvconf/update.d/dnsmasq. With the patch the script calls the list-records program with a new option "--omit-up-to lo.dnsmasq". This causes a new version of list-records in resolvconf 1.74 to omit list items up to and including the item lo.dnsmasq. The option has no effect on existing versions of list-records so it won't cause malfunction with existing (i.e., << 1.74) resolvconf. The "sed -e '/^lo.dnsmasq$/d'" remains necessary in order to continue supporting existing resolvconf. After a while perhaps we can add a "Conflicts: resolvconf (<< 1.74)" and drop the sed. The purpose of the new option is better to support forwarding nameserver chains. Suppose you have two instances of forwarding nameservers that you want to chain together as follows. resolver -> 127.0.0.2 d2 -> 127.0.0.1 d1 -> 8.8.8.8 g The idea is that d2 registers "lo.d2" with "nameserver 127.0.0.2" and d1 registers "lo.d1" with "127.0.0.1". Assume that something else registers "NetworkConfigurer" with "8.8.8.8". Assume the list-records program lists the records as follows. lo.d2 lo.d1 NetworkConfigurer The d2 and d1 packages include resolvconf update scripts. At present d2's update script does "list-records | sed -e '/^lo.d2$/d'" so that it only looks for forwarding addresses in records lo.d1 and NetworkConfigurer. But d1 does likewise and looks in lo.d2 and NetworkConfigurer, resulting in a loop. To fix this, d1's update script will henceforth do "list-records --omit-up-to lo.d1" yielding only the item NetworkConfigurer. This may seem like overkill but cases like this are becoming increasingly realistic. There are already people running dnsmasq server (record lo.dnsmasq with "nameserver 127.0.0.1") plus NetworkManager-controlled dnsmasq (record NetworkManager with "nameserver 127.0.1.1"). And there are people running dnsmasq server plus dnscrypt-proxy (record lo.dnscrypt with "nameserver 127.0.2.1"). And there are people running libvirt-controlled dnsmasq plus NetworkManager-controlled dnsmasq. Other combinations are possible. If my plan is misconceived, please don't hesitate to let me know. ;) -- Thomas dnsmasq-resolvconf-hook-script_20130712th1.patch Description: Binary data
Bug#582916: Testing eglibc 2.17-7
On Mon, Jul 8, 2013 at 9:35 AM, Jens Thiele wrote: > from the test: > > "to easily reproduce, fake packet loss/overloaded dns server > on linux do something like: > # iptables -I OUTPUT -p udp -m udp --dport 53 -j DROP > # iptables -I OUTPUT -p udp -m udp --dport 53 -j LOG --log-prefix "DROP > DNS REQUEST " > # iptables -I OUTPUT -p udp -m udp --dport 53 -m limit --limit 10/sec -j > ACCEPT > first > " > > all 3 lines are needed! > OK, tried again after running all three commands. Output: y.c:44: error: r=-2 Name or service not known -- Thomas
Bug#683061: getaddrinfo() return value chaos
It looked to me as if #582916 and roughly duplicate #671789 could have been fixed in libc6 2.17-7 which it includes two commits http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=cfde9b463d63092ff0908d4c2748ace648e2ead8 http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=3d04f5db20c8f0d1ba3881b5f5373586a18cf188 the first of which is included in eglibc 2.17 http://www.eglibc.org/cgi-bin/viewvc.cgi/branches/eglibc-2_17/libc/NEWS?view=markup and the second of which is included as a patch named 'cvs-getaddrinfo-EAI_NONAME.diff' in 2.17-7. So I upgraded libc6 on my Debian 7.0 machine. With the standard nsswitch.conf there is no change in the behavior of my test program. As before, either with empty or with bogus resolv.conf or with bogus domain name getaddrinfo() returns -2 with (supposedly therefore not significant) errno 2. With nsswitch.conf changed to have simply "hosts: dns", the following is the output of the test program. Making resolv.conf empty Results of looking up www.google.com: status = -2, errno = 111 Results of looking up a bogus name: status = -2, errno = 111 Writing nameserver option to resolv.conf Results of looking up www.google.com: status = 0, errno = 101 Results of looking up a bogus name: status = -2, errno = 101 Making resolv.conf empty Results of looking up www.google.com: status = -2, errno = 111 Results of looking up a bogus name: status = -2, errno = 111 Writing incorrect nameserver option to resolv.conf Results of looking up www.google.com: status = -2, errno = 110 Results of looking up a bogus name: status = -2, errno = 110 This is different from both Debian 7.0 and Ubuntu 13.04 and sort of half way between the two. As in Debian 7.0 the status is still always -2 in case of error. As in Ubuntu 13.04 errno is 110 when an incorrect nameserver address is given, as opposed to 111 when resolv.conf is empty (but errno is not supposed to be significant here because status is -2). Callers of getaddrinfo() will only be able to rely on these return values once the values have stabilized in eglibc (which they may not yet have done) and once the bug (assuming it's a bug and not a feature) is fixed whereby, with the standard nsswitch.conf, the incorrect errno is returned. Interested parties might want to enter into discussion with upstream in order to ensure that there is a clear specification of what these return values should be under different circumstances. Ideally tests would be added which check whether the specification has been adhered to. -- Thomas
Bug#582916: Testing eglibc 2.17-7
On Mon, Jul 8, 2013 at 9:16 AM, Jens Thiele wrote: > > Output: > > > > y.c:44: error: r=-2 Name or service not known > > > > Output after replacing "karme.de." with "www.google.com": none; the > program > > completed successfully. > > > > Output after doing "iptables -I OUTPUT -p udp -m udp --dport 53 -j DROP": > > > > y.c:29: error: r=-5 No address associated with hostname > > > > Comments? > > you have to use a name with A but no record for the test: > After "iptables -I OUTPUT -p udp -m udp --dport 53 -j DROP" the output of the program is the same whether hosts="www.google.com." or "karme.de.". It's y.c:29: error: r=-5 No address associated with hostname -- Thomas
Bug#582916: Testing eglibc 2.17-7
Jens, I ran your program ("updated test") on a Debian 7.0 system with libc6
et al
upgraded to 2.17-7.
Output:
y.c:44: error: r=-2 Name or service not known
Output after replacing "karme.de." with "www.google.com": none; the program
completed successfully.
Output after doing "iptables -I OUTPUT -p udp -m udp --dport 53 -j DROP":
y.c:29: error: r=-5 No address associated with hostname
Comments?
--
Thomas
Bug#582916: Is #582916 still a bug?
On Sun, Jul 7, 2013 at 3:00 PM, I wrote: > Does getaddinfo() do what you expect on Ubuntu 13.04 which has > version 2.17-0ubuntu5 of eglibc? > > Do you think that the bug has been properly fixed upstream? > > http://sourceware.org/bugzilla/show_bug.cgi?id=14719 > http://sourceware.org/bugzilla/show_bug.cgi?id=15339 > http://sourceware.org/bugzilla/show_bug.cgi?id=15635 > > http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=cfde9b463d63092ff0908d4c2748ace648e2ead8 > > http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=3d04f5db20c8f0d1ba3881b5f5373586a18cf188 > > And/or perhaps more importantly, has the bug been fixed in Debian unstable, version 2.17-7, which closed related bug #713799? * debian/patches/any/cvs-getaddrinfo-EAI_NONAME.diff: new patch from upstream to return EAI_NONAME instead of EAI_SYSTEM when the network is down. Closes: #713799. -- Thomas
Bug#582916: Is #582916 still a bug?
Hi there Jens, I have been looking into bug #683061 and Kurt Roeckx pointed me to #582916 which you investigated last November. I have trouble understanding exactly what the current behavior is and what you expect. Does getaddinfo() do what you expect on Ubuntu 13.04 which has version 2.17-0ubuntu5 of eglibc? Do you think that the bug has been properly fixed upstream? http://sourceware.org/bugzilla/show_bug.cgi?id=14719 http://sourceware.org/bugzilla/show_bug.cgi?id=15339 http://sourceware.org/bugzilla/show_bug.cgi?id=15635 http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=cfde9b463d63092ff0908d4c2748ace648e2ead8 http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=3d04f5db20c8f0d1ba3881b5f5373586a18cf188 -- Thomas
Bug#683061: getaddrinfo() return value chaos
Continuing on from the "boot ordering and resolvconf" thread; cc:ed to Helmut in case this gets filtered again; bcc:ed to 683...@bugs.debian.org since this is relevant for how that issue is addressed... Executive summary: The getaddrinfo() returns different values depending on the OS and on nsswitch.conf settings, making it very difficult to use getaddrinfo() return values to deciding how to handle an error. Here are the results of further experiments with getaddrinfo(). I am using the attached x.c program. It tries to look up the valid domain name 'www.google.com' and an invalid name four times: * once with empty /etc/resolv.conf (in which case the resolver tries 127.0.0.1:53) * once with /etc/resolv.conf pointing to a working nameserver on my LAN * once with empty /etc/resolv.conf (again) * once with /etc/resolv.conf pointing to an IP address where there is no working nameserver OS is Debian 7.0. # ./a.out Making resolv.conf empty Results of looking up www.google.com: status = -2, errno = 2 Results of looking up a bogus name: status = -2, errno = 2 Writing nameserver option to resolv.conf Results of looking up www.google.com: status = 0, errno = 101 Results of looking up a bogus name: status = -2, errno = 2 Making resolv.conf empty Results of looking up www.google.com: status = -2, errno = 2 Results of looking up a bogus name: status = -2, errno = 2 Writing incorrect nameserver option to resolv.conf Results of looking up www.google.com: status = -2, errno = 2 Results of looking up a bogus name: status = -2, errno = 2 As I saw before, status is always -2 (EAI_NONAME). The manpage doesn't say that errno is significant in that case. (It is significant when status is -11.) Helmut got different results. Is the difference between my machine and Helmut's machine attributable to some diff in nsswitch.conf, perhaps? I have: hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 I tested next with hosts: dns and got different results. Making resolv.conf empty Results of looking up www.google.com: status = -2, errno = 111 Results of looking up a bogus name: status = -2, errno = 111 Writing nameserver option to resolv.conf Results of looking up www.google.com: status = 0, errno = 101 Results of looking up a bogus name: status = -2, errno = 101 Making resolv.conf empty Results of looking up www.google.com: status = -2, errno = 111 Results of looking up a bogus name: status = -2, errno = 111 Writing incorrect nameserver option to resolv.conf Results of looking up www.google.com: status = -2, errno = 111 Results of looking up a bogus name: status = -2, errno = 111 Now errno for empty or incorrect resolv.conf is 111 (ECONNREFUSED ). And with correct resolv.conf and bogus domain name errno is 101 (ENETUNREACH). That doesn't make too much sense but as I said I don't think we are supposed to pay attention to errno if status is -2. Next I ran the program on Ubuntu 13.04 with "hosts: dns". Making resolv.conf empty Results of looking up www.google.com: status = -11, errno = 111 Results of looking up a bogus name: status = -11, errno = 111 Writing nameserver option to resolv.conf Results of looking up www.google.com: status = 0, errno = 101 Results of looking up a bogus name: status = -2, errno = 101 Making resolv.conf empty Results of looking up www.google.com: status = -11, errno = 111 Results of looking up a bogus name: status = -11, errno = 111 Writing incorrect nameserver option to resolv.conf Results of looking up www.google.com: status = -11, errno = 110 Results of looking up a bogus name: status = -11, errno = 110 This is different in two ways. First the status is -11 (EAI_SYSTEM) instead of -2 (EAI_NONAME) when no nameserver can be reached. Second, there is now a difference between the empty-resolv.conf case and the resolv.conf-with-bogus-address case. In the latter case errno is 110 (ETIMEDOUT) instead of 111 (ECONNREFUSED). This is better. Debian 7.0 has libc6 version 2.13-37. Ubuntu 13.04 has libc6 version 2.17-0ubuntu5. What's behind all this? [google, google...] I see that in November 2012 a change was made upstream http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=cfde9b463d63092ff0908d4c2748ace648e2ead8 in response to a complaint that the wrong status was returned in the case of an internal error (out-of-fds). http://sourceware.org/bugzilla/show_bug.cgi?id=14719 This is possibly the reason that I get status -11 instead of -2 on Ubuntu. But the result of the change was that getaddrinfo() returned EAI_SYSTEM in too many cases. http://sourceware.org/bugzilla/show_bug.cgi?id=15339 This has recently (May 2013) been fixed http://sourceware.org/bugzilla/show_bug.cgi?id=15635 http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=3d04f5db20c8f0d1ba3881b5f5373586a18cf188
Bug#683061: [pkg-ntp-maintainers] Bug#683061: Bug#683061: bug report #683061
On Tue, Jul 2, 2013 at 3:57 PM, Kurt Roeckx wrote: > Do you expect the DHCP server on the LAN then to set that ntp > server? Currently this would now result in ntpd getting restarted > by dhcp and should get you a working ntp server. > I think it is a good idea to furnish time server addresses over DHCP in the same manner as name server addresses. How widespread that practice is, I have to admit I don't know. I notice, however, that NetworkManager doesn't support obtaining time server addresses over DHCP. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627343 https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/267891 > But do you want it to log this every second? Or do you have some > trigger for when it should log this again? (For instance on > interface/ip change.) > Perhaps a failed lookup should be logged once and then not logged again until after at least one successful lookup of that name? Perhaps also the retry interval for a given name should increase gradually from 1 second to, say, 15 minutes? -- Thomas
Bug#275487: willfix?
package resolvconf tags 275487 - wontfix stop This feature would be useful for debugging purposes.
Bug#683061: [pkg-ntp-maintainers] Bug#683061: bug report #683061
On Tue, Jul 2, 2013 at 1:59 PM, Kurt Roeckx wrote: > Do you know NXDOMAIN returns? I think it returns just the same? > I don't immediately see how getaddrinfo() alone can be used to tell whether or not an actual NXDOMAIN was received. A test with a small C program reveals that retval -11 errno 2 is returned both in the NXDOMAIN case and in the case where no nameservers could be found. > > So ntpd should just keep trying to resolv invalid hostnames? > That may seem like a waste of resources, but * Computers are mobile these days and DNS also changes from the perspective of those computers. A laptop may connect sometimes to a LAN where the domain name ntp.somecorp.private resolves to the address of a time server. On other LANs this name does not exist. * If the retry period is on the order of seconds then the resources used aren't very significant. * If the name of the time server never resolves and this is a problem then it's the admin's fault for failing to configure ntpd properly. I suppose the question really is, when should the admin be notified that there is a problem? Good question. Is there something wrong with ntpd just logging resolution failures and leaving it at that? Anyway, you be the judge. Best wishes, -- Thomas
Bug#683061: bug report #683061
getaddrinfo() returns -11 with errno 2 (EAI_SYSTEM with errno ENOENT) both when no nameserver can be reached and when the domain name does not exist. So if you want to behave differently in these two cases you can't do so based solely on the returned status of getaddrinfo(). Hypothesis: ntpd handles -11/2 as meaning NXDOMAIN and treats this as a permanent error whereas -11/2 could also mean that no nameservers could be reached which should not be treated as a permanent error. What I would suggest is that both no-nameservers-are-reachable and NXDOMAIN be treated as non-permanent errors. That a domain name does not now exist does not entail that it never will exist. And then there is no need to distinguish the two cases. -- Thomas Hood P.S. I got to this bug report from here: http://lists.debian.org/debian-devel/2013/06/msg00316.html
Bug#629100: Status update
The Samba team has been very busy preparing a unified, solid, and policy-compliant package based on release 4.0.6. Those guys deserve some serious respect. Their package will soon appear in experimental and then unstable and in Ubuntu. Once this package appears and has stabilized for a few weeks, winexe upstream (viz., the author and myself) will get winexe building against it. This may require some time, since the samba packaging has changed significantly. Once that work is done I will post another update here. To any Debian developer using winexe: please volunteer to package winexe for Debian! -- Thomas
Bug#710960: Please support domain name lookup routing with resolvconf
Package: dnsmasq Version: 2.66-3 Severity: wishlist When NetworkManager controls dnsmasq it configures dnsmasq to route VPN domain name lookups to the VPN nameserver. It should be possible to implement this for dnsmasq server too. Suppose the VPN client has registered the following record called 'tap0.vpnclient'. search abc.com nameserver 172.17.24.1 Earlier the following 'eth0.dhclient' record was already registered. search myhome.nu nameserver 192.168.1.1 Dnsmasq's resolvconf hook script could direct dnsmasq to do the equivalent of server=/abc.com/172.17.24.1 server=192.168.1.1 First, the "whether". Is this a desirable feature? Second, the "how". Currently, dnsmasq's resolvconf hook script writes a resolv.conf-format file at /var/run/dnsmasq/resolv.conf. To implement the new functionality, I take it that the hook script would have to depart from that. It would have to write a configuration file and restart dnsmasq, or send the information to dnsmasq via D-Bus, as NetworkManager does. Am I right in assuming that the latter would be better? Let the discussion begin. :) -- Thomas
Bug#709179: Here's the patch
Oops, forgot this part of the patch which fixes a spelling mistake. ;)
@@ -27,7 +27,7 @@
report_err() { echo "$0: Error: $*" >&2 ; }
# Stores arguments (minus duplicates) in RSLT, separated by spaces
-# Doesn't work properly if an argument itself contain whitespace
+# Doesn't work properly if an argument itself contains whitespace
uniquify()
{
RSLT=""
Bug#709179: Here's the patch
package dnsmasq tags 709179 patch stop Attached is the patch to implement this. dnsmasq.gz - The patched /etc/resolvconf/update.d/dnsmasq dnsmasq_2.65-1ubuntu1_bug709179.patch - Patch against 2.65-1ubuntu1 -- Thomas dnsmasq.gz Description: GNU Zip compressed data dnsmasq_2.65-1ubuntu1_bug709179.patch Description: Binary data
Bug#709258: Please automagically handle dnscrypt-proxy correctly
Package: resolvconf Version: 1.71 Severity: wishlist OpenDNS's DNSCrypt client for Linux (called 'dnscrypt-proxy')[0] is not yet packaged for Debian but some people are already installing it from source and it is of course possible that it will eventually be packaged. (It is free software and there's an ITP for it, bug report #692320.) This is a request that the resolvconf package be enhanced to make it easy to use dnscrypt-proxy. Dnscrypt-proxy doesn't cache. So it makes sense to run a local caching forwarding nameserver configured to forward queries to dnscrypt-proxy at a loopback address. The request is that resolvconf automagically handle both the situation where dnscrypt-proxy is installed, in which case its listen address should be listed exclusively in resolv.conf, and the situation where both dnscrypt-proxy and a local caching forwarding nameserver are installed, in which case the loopback address of the local caching forwarding nameserver should be listed exclusively in resolv.conf and the address of dnscrypt-proxy not. Dnscrypt-proxy's record will probably be called 'lo.dnscrypt'. Libc's resolvconf hook script should see to it that: * if lo.dnscrypt is present but lo.dnsmasq et al are not present, only the address from lo.dnscrypt will be written to /run/resolvconf/resolv.conf. * if lo.dnscrypt is present and some lo.LOCALCACHINGFORWARDINGNAMESERVER is also present, only the address from lo.LOCALCACHINGFORWARDINGNAMESERVER will be written to /run/resolvconf/resolv.conf. LOCALCACHINGFORWARDINGNAMESERVER is expected then to forward to dnscrypt-proxy. [0]https://github.com/opendns/dnscrypt-proxy
Bug#709179: Please automagically forward to dnscrypt-proxy if available
Package: dnsmasq Version: 2.66-2 Severity: wishlist OpenDNS's DNSCrypt client for Linux (called 'dnscrypt-proxy')[0] is not yet packaged for Debian but some people are already installing it from source and it is of course possible that it will eventually be packaged. This is a request that the dnsmasq package be enhanced to make it easy to use dnsmasq along with dnscrypt-proxy and resolvconf. Dnscrypt-proxy doesn't cache. So it makes sense to run dnsmasq with caching turned on and configured to forward queries to dnscrypt-proxy at a loopback address. The request is that this happen automagically when resolvconf is also installed. Getting it to happen automagically on a resolvconfful system just requires tweaking dnsmasq's resolvconf hook script. Currently dnsmasq's resolvconf hook script gathers all nameserver addresses from the resolvconf database, excludes dnsmasq's own listen address and writes the remaining addresses to /var/run/dnsmasq/resolv.conf. When dnscrypt-proxy is running only dnscrypt-proxy's address should be used. Let's decide here and now that the name of dnscrypt-proxy's resolvconf record will be "lo.dnscrypt". (Thus dnscrypt-proxy or its initscript will do something like "echo 127.0.0.2 | resolvconf -a lo.dnscrypt".) Dnsmasq's resolvconf hook script should thus be changed such that if lo.dnscrypt is present, only the address from lo.dnscrypt will be written to /var/run/dnsmasq/resolv.conf. Once there is agreement I will submit a patch. [0]https://github.com/opendns/dnscrypt-proxy
Bug#705759: Please support and Recommend resolvconf as well as openresolv
Package: dhcpcd5 Version: 5.5.6-1 Severity: wishlist The dhcpcd5 package currently Recommends openresolv. As openresolv is resolvconf-compatible (it Provides: resolvconf), it should be possible to extend the recommendation to resolvconf as follows. Recommends: openresolv | resolvconf If this is not immediately possible for some reason then please consider this a request that this reason be eliminated and that dhcpcd5 support resolvconf as well as openresolv.
Bug#705745: Please add resolvconf dpkg-event hook script
Package: dhcpcd
Severity: wishlist
Please add the hook script /usr/lib/resolvconf/dpkg-event.d/dhcpcd
The purpose this script is to cause dhcpcd to take notice of the
installation (or removal) of the resolvconf package. If resolvconf
has been installed then dhcpcd should register with resolvconf
IP addresses of nameservers that dhcpcd has obtained during
DHCP negotiation.
See below for an except from resolvconf's README file giving
general information about resolvconf dpkg-event hook scripts.
For a DHCP client the simplest way to implement this might be
for the dpkg-event hook script, on resolvconf install, to trigger
the client to renegotiate the lease.
Usage information for maintainers
~
[...] All suppliers of
nameserver information should supply their information to resolvconf after
resolvconf has been installed.
As of resolvconf release 1.55 this is supported via the following mechanism.
Any package, foo, that supports supplying information to resolvconf should
include a hook script /usr/lib/resolvconf/dpkg-event.d/foo which, when
called
with the argument "install", takes whatever actions are necessary to cause
the program(s) in foo to supply their nameserver information to resolvconf;
and when called with the argument "remove" takes whatever actions are
appropriate given that the resolvconf package has been removed (and,
in being removed, may have removed foo's nameserver information).
The hook script thus has the following form.
#!/bin/sh
#
# /usr/lib/resolvconf/dpkg-event.d/foo
#
# The resolvconf dpkg-event hook script for the foo package
#
if foo_is_running ; then
if [ "$1" = "install" ] ; then
foo-ctrl send-nameserver-info-to-resolvconf
elif [ "$1" = "remove" ] ; then
...
fi
fi
If foo is controlled by an initscript whose methods take appropriate actions
conditional upon resolvconf's presence then something like the following
might be appropriate.
force_reload_foo() {
if which invoke-rc.d >/dev/null 2>&1 ; then
invoke-rc.d foo force-reload
elif [ -x /etc/init.d/foo ] ; then
/etc/init.d/foo force-reload
fi
}
case "$1" in
install|remove) force_reload_foo ;;
esac
The hook script is called (with argument "install") from resolvconf's
postinst
"configure" method and (with "remove") from resolvconf's postrm "remove"
method.
Foo's hook script is called with argument "install" if and only if foo is
fully installed both when resolvconf's preinst install runs and when its
postinst configure runs. The hook script is called with argument "remove"
if and only if foo is fully installed when resolvconf's postrm remove runs.
The hook script must be owned by root and have its execute permission
bit set and must have the same name as the package that owns it.
Arguments other than "install" and "remove" are reserved for future use
and must be silently ignored.
Bug#629100: Status update
Winexe in the winexe-waf repository now builds nicely against the Samba 4 public API and shared libraries as represented by Debian Samba 4 packages and I am hoping, therefore, that there will soon be a new Winexe release based on this winexe-waf code. Once Winexe has been released it would be very nice if someone from the Debian community would package it. :) (Winexe can also be built statically, but this requires building against the Samba 4 source tree since the necessary static Samba 4 libraries aren't available.) -- Thomas
Bug#705582: Please add option PREFER_IPV6
Package: resolvconf
Version: 1.71
Severity: wishlist
-- Forwarded message --
From: Pali Rohár
Date: Sun, Apr 14, 2013 at 8:31 PM
Subject: [Resolvconf-devel] [PATCH] Add option PREFER_IPV6
To: resolvconf-de...@lists.alioth.debian.org
Hello,
I created small patch which adding new env option PREFER_IPV6.
When is set to YES then libc resolvconf updater will add ipv6
nameservers before ipv4 in /etc/resolv.conf. This is usefull if
you want to prefer using nameservers via ipv6 protocol.
Patch was generated against ubuntu resolvconf version 1.67ubuntu2.
--- etc/resolvconf/update.d/libc.orig 2013-04-02 15:27:34.017686814 +0200
+++ etc/resolvconf/update.d/libc2013-04-02 15:37:55.121668638 +0200
@@ -87,6 +87,21 @@ uniquify()
done
}
+ipv6_nameserver_list()
+{
+ while [ "$1" ] ; do
+ case "$1" in (*:*) : ;; (*) shift ; continue ;; esac
+ for E in $NMSRVRS ; do
+ [ "$1" = "$E" ] && { shift ; continue 2 ; }
+ done
+ NMSRVRS="${NMSRVRS:+$NMSRVRS }$1"
+ case "$TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS" in
(y|Y|yes|YES|Yes) case "$1" in (127.*|::1) return 0 ;;
esac ;; esac
+ N=$(($N + 1))
+ [ "$N" = 3 ] && return 0
+ shift
+ done
+}
+
# Args are candidate items not containing spaces
# Returns NSMSRVS -- space-separate list of no more than 3 items,
#without duplicates,
@@ -95,6 +110,7 @@ uniquify_nameserver_list()
{
NMSRVRS=""
N=0
+ case "$PREFER_IPV6" in (y|Y|yes|YES|Yes) ipv6_nameserver_list "$@"
;; esac
while [ "$1" ] ; do
for E in $NMSRVRS ; do
[ "$1" = "$E" ] && { shift ; continue 2 ; }
--
Pali Rohár
pali.ro...@gmail.com
___
Resolvconf-devel mailing list
resolvconf-de...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/resolvconf-devel
signature.asc
Description: PGP signature
Bug#704528: Please include new resolvconf hook script which handles multiple postfix instances
Package: postfix Version: 2.9.6-2 Severity: wishlist Tags: patch Attached is a new resolvconf update hook script (/etc/resolvconf/update-libc.d/postfix) which handles multiple postfix instances. Please include it instead of the existing script. Thanks to Patrik Båt for writing this. -- Thomas Hood resolvconf developers postfix-resolvconf_20130307th1 Description: Binary data
Bug#700385: Improved update script
I wrote: > Then include a file named /etc/resolvconf/update-libc.d/000nscd > in the nscd package with the following content. > >#!/bin/sh >[ -x /etc/init.d/nscd ] && /etc/init.d/nscd invalidate-hosts There's a bug in this one-line script. :) The script with accompanying amendment to /etc/init.d/nscd worked well in my casual testing. However, when I removed the nscd package the "-x" test failed and consequently the script exited with status 1, causing resolvconf also to exit with nonzero status. That was not the intent. So the /etc/resolvconf/update-libc.d/000nscd file should instead have the following content or something equivalent. #!/bin/sh ! [ -x /etc/init.d/nscd ] || /etc/init.d/nscd invalidate-hosts
Bug#700846: Please add systemd support
Package: resolvconf Version: 1.70 Severity: wishlist Please make resolvconf work properly on a systemd machine (if it doesn't already). N.B. The addition of support for init systems other than sysvinit is governed by Policy §9.11. At present I have no clue how to do this so I'd appreciate it if someone would give advice or submit patches. -- Thomas Hood
Bug#700385: Either fix automatic hosts cache invalidation or add resolvconf update script to invalidate the hosts cache
Package: nscd Version: 2.13-38 Severity: normal When resolvconf is installed it updates the resolver configuration file resolv.conf as needed. (It actually writes to /run/resolvconf/resolv.conf to which /etc/resolv.conf is a symbolic link.) When nscd is running and the hosts cache is enabled and resolv.conf changes, the hosts cache needs to be invalidated, but this does not currently happen. I discovered this while running nscd with the hosts cache enabled. I connected to a VPN whose internal nameservers resolve certain domain names differently from external nameservers: external nameservers resolve the name to the IP address of the company's reverse proxy whereas the internal nameservers resolve it to an internal IP address. After I connected to the VPN my resolv.conf file was updated by resolvconf such that the VPN nameserver was listed first, but nscd continued to supply the old external IP address out of its cache. Same problem again on disconnecting from the VPN. I would have expected that nscd would invalidate its hosts cache automatically when resolv.conf changed. I thought that this was the point of the patch discussed here: http://www.eglibc.org/archives/patches/msg00977.html which I believe has been integrated into Debian and Ubuntu nscd. But experimentation proves that nscd does *not* invalid its hosts cache when resolv.conf changes... at least, not under the circumstances described above. If nscd is supposed to invalidate its hosts cache when resolv.conf changes then please fix the bug which causes this not to happen under the circumstances described above. If it is not the intent to include that functionality in nscd, then please add a resolvconf update script that invalidates the hosts cache when resolv.conf is changed by resolvconf. I would suggest that this be implemented in two parts. First, add a new "invalidate-hosts" method to the initscript which invalidates the hosts cache, making use of nscd's "--invalidate" option. Then include a file named /etc/resolvconf/update-libc.d/000nscd in the nscd package with the following content. #!/bin/sh [ -x /etc/init.d/nscd ] && /etc/init.d/nscd invalidate-hosts The code in the initscript could look something like the following. invalidate-hosts) log_daemon_msg "Invalidating hosts cache of $DESC" status || nscd --invalidate hosts case "$?" in 0) log_end_msg 0 ; exit 0 ;; *) log_failure_msg " (failed)" ; exit 1 ;; esac ;; Should you implement this, please Suggest resolvconf (>= 1.70) and Conflict with resolvconf (<< 1.70), since those older versions of resolvconf restarted nscd if resolv.conf changed and nscd had the hosts cache enabled. -- Thomas Hood
Bug#699425: Fetchmail's resolvconf update script can be simplified
Package: fetchmail Version: 6.3.22-2 Severity: minor Fetchmail's resolvconf update script (/etc/resolvconf/update-libc.d/fetchmail) can be simplified. Resolvconf no longer calls update scripts with "--nscd" to indicate that nscd is running and has been restarted. (Resolvconf no longer restarts nscd when resolv.conf changes.) Consequently, the while...done statement can be deleted from fetchmail's resolvconf update script as shown in the appended patch. Whether or not it is still necessary to "awaken" fetchmail after a resolv.conf change, I don't know. Someone who knows fetchmail better than I do will have to be the judge of that. They just need to be aware that the glibc resolver has been enhanced such that resolver clients are asked to re-initialize the resolver when resolv.conf changes. At least for nscd that means that nscd doesn't have to be restarted after a resolv.conf change (as it once did have to be). -- Thomas Hood --- fetchmail_ORIG 2013-01-31 11:11:39.926431750 +0100 +++ fetchmail 2013-01-31 11:11:57.522479569 +0100 @@ -1,12 +1,5 @@ #!/bin/sh -while [ "$1" ]; do - if [ "$1" = "--nscd" ]; then - exit 0 - fi - shift -done - if [ -x /etc/init.d/fetchmail ] && [ -n "$(pidof fetchmail)" ]; then /etc/init.d/fetchmail awaken fi
Bug#699061: Please ignore leading whitespace on lines in resolv.conf
Package: libc6 Version: 2.13-38 Severity: wishlist Currently, if an option in /etc/resolv.conf is preceded by a space then the option is not recognized. This fact is documented, not entirely explicitly, in resolv.conf(5) which says The keyword and value must appear on a single line, and the keyword (e.g., nameserver) must start the line. It is quite common, however, for configuration syntaxes to allow whitespace at the beginnings of lines (which will be ignored). Here is a case where this gave someone some trouble. http://askubuntu.com/questions/246385/can-resolve-hostname-via-dns-using-host-but-cant-ping-ssh-ntp/247542 I request that leading whitespace on lines in resolv.conf be ignored. -- Thomas Hood
Bug#697435: Warn users about removal of old update.d/bind
Package: resolvconf Version: 1.69 Severity: minor Tags: confirmed Resolvconf 1.69 (and thus Wheezy+1) moves the old /etc/resolvconf/update.d/bind script out of the way. (See bug report #687507.) (The file has not been included in resolvconf since 1.53 and thus has not been included in a Debian release since Squeeze.) A few users may be using this file because it was installed in the Squeeze or earlier era, or because they copied the example file to /etc/resolvconf/update.d/ and named it "bind". For the benefit of such users there should be a warning in NEWS that the file is being moved out of the way. -- Thomas
Bug#695121: kppp not resolvconf-aware; appears to clobber /etc/resolvconf
Package: kppp
Version: 4.8.4-1
Severity: important
Looking at the kdenetwork 4.8.4-1 source code I see the following code
snippets in kppp/connect.cpp starting at line 1419:
// Replace the DNS domain entry in the /etc/resolv.conf file and
// disable the nameserver entries if option is enabled
void add_domain(const QString &domain) {
// adds the DNS entries in the /etc/resolv.conf file
void adddns()
{
// remove the dns entries from the /etc/resolv.conf file
void removedns() {
The code inside the functions writes directly to /etc/resolv.conf. Nowhere
is there a check for the presence of /sbin/resolvconf.
When /sbin/resolvconf is present and executable it is not permitted to
write directly to /etc/resolv.conf. Programs that want to make changes to
resolv.conf must interface with /sbin/resolvconf which takes care of adding
material to and removing material from resolv.conf. Please see
/usr/share/doc/resolvconf/README.gz for more instructions.
It looks as if kppp writes to /etc/resolv.conf and does not mv
/etc/resolv.conf. So if /etc/resolv.conf is a symbolic link, as is normally
the case when resolvconf is installed, then kppp will write through the
link to /run/resolvconf/resolv.conf. Then the next time resolvconf updates
this file, kppp's changes will be obliterated.
I haven't tested kppp so I don't know whether the code in question is
actually executed.
