[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#717438: Confirmation



Control: tag -1 - moreinfo
Control: retitle -1 pdnsd: does no more work in combination with resolvconf

Hi Thomas,

thanks for providing details about this bug(s) as the initial report
was quite unclear about what's really the issue..

But in the future, please don't write to just -submitter@ as such
mails are not sent to the maintainer of the package (just archived in
the web) and hence may get lost if you are not the (only) maintainer
i.e. know about that mail being sent. This especially counts if the
maintainer address is set to a mailing list.

Full quote below for the Debian QA mailing list.

Thomas Hood wrote:
> I just tested pdnsd on Debian 7.1 and can confirm that at least the
> comination pdnsd + resolvconf does not work out of the box (even after
> setting START_DAEMON=yes in /etc/default/pdnsd).

> I found two apparent bugs. First, "resolvconf -a" is not called in the
> initscript on start. With "set -x" the initscript output is:
> 
> + start_resolvconf
> + test -x /sbin/resolvconf
> + seq 1 60
> + sleep 0.1
> + pdnsd-ctl status
> + break
> + grep+  -q resolvconf
> pdnsd-ctl status
> + sed -ne /^Global:$/,/^Server.*:$/s/.*Server ip.*: \(.*\)$/\1/p
> + pdnsd-ctl status
> + server=
> + exit 0
> 
> Something seems to be wrong with the processing of the output from
> "pdnsd-ctl status". The variable "server" has as value the null string and
> consequently "resolvconf -a" doesn't get run.
> 
> If I subsequently run "echo 'nameserver 127.0.0.1' | resolvconf -a
> lo.pdnsd" on the command line then pdnsd starts working.
> 
> The second bug is in pdnsd's resolvconf update hook script. After running
> "echo 'nameserver 127.0.0.1' | resolvconf -a lo.pdnsd" the output of
> "pdnsd-ctl status" is:
> 
> [...]
> Server 0:
> ------
> label: resolvconf
> ip: 127.0.0.1
>  server assumed available: yes
> ip: 192.168.1.254
> server assumed available: yes
> [...]
> 
> It appears that 127.0.0.1 is now included as a forwarding address. Turning
> on "set -x" I can see that /etc/resolvconf/update.d/pdnsd passes both the
> real forwarding address and 127.0.0.1 as arguments to "pdnsd-ctl server
> resolvconf up". The address 127.0.0.1 should of course be filtered out if
> it's an address that pdnsd itself is listening on.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5


Reply to: