Bug#943735: resolvconf maintenance

[Thomas Hood]

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

[Thomas Hood]

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

[Thomas Hood]

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

[Thomas Hood]

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

[Thomas Hood]

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 <ja...@zx2c4.com> 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

[Thomas Hood]

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

[Thomas Hood]

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

[Thomas Hood]

Hi and thanks for the patch. Did you test it in Debian?

-- 
Thomas

Bug#776778: Still to do

[Thomas Hood]

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

[Thomas Hood]

> 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

[Thomas Hood]

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 <mh+debian-b...@zugschlus.de> 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

[Thomas Hood]

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

[Thomas Hood]

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

[Thomas Hood]

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

[Thomas Hood]

On Jul 10, 2015 11:04 PM, Stephen Crowley c...@canaccord.com 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: More info, pls

[Thomas Hood]

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#791978: interfaces-order is being ignored

[Thomas Hood]

 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#787457: Cannot reproduce

[Thomas Hood]

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

[Thomas Hood]

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

[Thomas Hood]

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

[Thomas Hood]

On 28 April 2015 at 16:28, Andrew Shadura and...@shadura.me 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

[Thomas Hood]

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#783596: Not a bug

[Thomas Hood]

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 bugzi...@tut.by  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#777228: Bug report with paths corrected

[Thomas Hood]

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 21 ; 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 21 ; 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

[Thomas Hood]

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 edmo...@debian.org:

 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

[Thomas Hood]

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

[Thomas Hood]

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?

[Thomas Hood]

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

[Thomas Hood]

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 21 ; 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 21 ; 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

[Thomas Hood]

On 5 February 2015 at 21:28, Thomas Hood jdth...@gmail.com 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

[Thomas Hood]

On 4 February 2015 at 12:00, Ondřej Surý ond...@sury.org 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

[Thomas Hood]

On 5 February 2015 at 16:35, Axel Beckert a...@debian.org 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#776776: Bug in resolvconf?

[Thomas Hood]

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#776776: Breaks resolvconf

[Thomas Hood]

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#776778: Please play nicely with resolvconf

[Thomas Hood]

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: Bug in resolvconf?

[Thomas Hood]

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#776778: Don't play well together

[Thomas Hood]

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#775356: New patch

[Thomas Hood]

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 jdth...@gmail.com  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

[Thomas Hood]

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

[Thomas Hood]

On 14 January 2015 at 16:18, Axel Beckert a...@debian.org 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

[Thomas Hood]

On 14 January 2015 at 15:08, Vincent Lefevre vinc...@vinc17.net 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

[Thomas Hood]

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

[Thomas Hood]

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

[Thomas Hood]

On 30 July 2014 13:37, Harald Dunkel harald.dun...@aixigo.de 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#749405: [Resolvconf-devel] Bug#749405: Bug#749405: Current Status + Moving Forward?

[Thomas Hood]

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 jdth...@gmail.com  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 21 ; 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#752521: Misleading man page statements and command names

[Thomas Hood]

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: Current Status + Moving Forward?

[Thomas Hood]

On 23 June 2014 05:45, Nick Daly nick.m.d...@gmail.com 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

[Thomas Hood]

Hi all,

First of all I must apologize for the inconvenience caused by this bug.

Martin, can you please comment?
-- 
Thomas

Bug#746941: Proposed solution

[Thomas Hood]

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#700846: Service file

[Thomas Hood]

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#746940: Cruft in initscript

[Thomas Hood]

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#746941: Initscript fails to disable itself when the dnsmasq package is removed

[Thomas Hood]

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#700846: service file

[Thomas Hood]

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

[Thomas Hood]

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

[Thomas Hood]

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

[Thomas Hood]

 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)

[Thomas Hood]

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

[Thomas Hood]

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 jdth...@yahoo.co.uk
-# 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

[Thomas Hood]

On Mon, Sep 2, 2013 at 12:49 PM, Alberto Gonzalez Iniesta
a...@inittab.org 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

[Thomas Hood]

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

[Thomas Hood]

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

[Thomas Hood]

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#663006: Retitle to RFP?

[Thomas Hood]

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#720732: Please apply yet another patch to resolvconf update script

[Thomas Hood]

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#716908: New version of patch for latest version of the update script

[Thomas Hood]

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

[Thomas Hood]

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

[Thomas Hood]

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

[Thomas Hood]

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

[Thomas Hood]

 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

[Thomas Hood]

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

[Thomas Hood]

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

[Thomas Hood]

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#683061: getaddrinfo() return value chaos

[Thomas Hood]

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

[Thomas Hood]

On Mon, Jul 8, 2013 at 9:16 AM, Jens Thiele ka...@karme.de 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

[Thomas Hood]

On Mon, Jul 8, 2013 at 9:35 AM, Jens Thiele ka...@karme.de 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

[Thomas Hood]

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#582916: Is #582916 still a bug?

[Thomas Hood]

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#582916: Is #582916 still a bug?

[Thomas Hood]

On Sun, Jul 7, 2013 at 3:00 PM, I jdth...@gmail.com 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#683061: [pkg-ntp-maintainers] Bug#683061: bug report #683061

[Thomas Hood]

On Tue, Jul 2, 2013 at 1:59 PM, Kurt Roeckx k...@roeckx.be 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#275487: willfix?

[Thomas Hood]

package resolvconf
tags 275487 - wontfix
stop

This feature would be useful for debugging purposes.

Bug#683061: [pkg-ntp-maintainers] Bug#683061: Bug#683061: bug report #683061

[Thomas Hood]

On Tue, Jul 2, 2013 at 3:57 PM, Kurt Roeckx k...@roeckx.be 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#683061: bug report #683061

[Thomas Hood]

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

[Thomas Hood]

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

[Thomas Hood]

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

[Thomas Hood]

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#709179: Here's the patch

[Thomas Hood]

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: Please automagically forward to dnscrypt-proxy if available

[Thomas Hood]

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#709258: Please automagically handle dnscrypt-proxy correctly

[Thomas Hood]

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#705745: Please add resolvconf dpkg-event hook script

[Thomas Hood]

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 21 ; 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#705759: Please support and Recommend resolvconf as well as openresolv

[Thomas Hood]

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#705582: Please add option PREFER_IPV6

[Thomas Hood]

Package: resolvconf
Version: 1.71
Severity: wishlist

-- Forwarded message --
From: Pali Rohár pali.ro...@gmail.com
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#629100: Status update

[Thomas Hood]

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#704528: Please include new resolvconf hook script which handles multiple postfix instances

[Thomas Hood]

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 resolvconf-de...@lists.alioth.debian.org


postfix-resolvconf_20130307th1
Description: Binary data

Bug#700385: Improved update script

[Thomas Hood]

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

[Thomas Hood]

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

[Thomas Hood]

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

[Thomas Hood]

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

[Thomas Hood]

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

[Thomas Hood]

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

[Thomas Hood]

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.