Bug#1037244: dhcpcd-ui: new upstream 0.7.9 release
Hi Leandro On 21/06/2023 20:37, Leandro Cunha wrote: [1] https://tracker.debian.org/pkg/dhcpcd5 [2] https://salsa.debian.org/debian/dhcpcd-ui/-/commit/3ca27368227960a2d97ca4fbd1a56314546d96d3 You can probably remove libdbus-1-dev as a buildtime dependency as well. Roy
Bug#761050: Please read Re: openresolv sets local bind to always forward requests, even when local bind is authoritative
Sorry aboutt he late response, for some reason this ended up in my spam filter. > On Mon, 22 Jun 2015 12:25:38 +0200 (CEST) >> On Tue, 16 Jun 2015, Herbert Parentes Fortes Neto wrote: >> >>> The upstream said: >>> >>> "Not really an openresolv bug as I see it. >>> For example 192.168.x.x can route to 10.x.x.x even if both sets are not >>> publicly route-able. In-fact some Spanish ISPs do this for their >>> Internet TV." >> >> I regret to say that upstream did not understand my bug report (perhaps I >> did not explain clearly). I never claimed that requests to resolve >> unroutable IPs should never be forwarded; I did claim (and maintain) that IF >> the local bind is set up to be authoritative on a domain (which happens to >> be an unroutable block of IPs for me, but does not have to be), then >> openresolv should not override that by always forwarding queries in any >> case. So the problem is not about forwarding queries involving unroutable >> addresses (even if that happens in my case) but about forwarding queries >> that can have (and therefore should have) an authoritative answer from the >> local bind, without going any further. >> >> If I did not explain clearly, please let me know and I will try to explain >> better. If you confirm wontfix, I will find a way to tweak my local >> configuration of bind + openresolv to work around this for myself, but I do >> believe the current behaviour is wrong in principle and in practice, so it >> should be fixed in a more general way. OK, so you have setup bind to be authortative in some way. Openresolv wants to setup forwarding servers. These two facts maybe in conflict. Now, I am no expert with bind configs, but it would really help if you could post your non working configuration and explain how it should be changed by openresolv to work for you. If you can do that, I'm sure we can make more progress with this issue. Roy
Bug#792430: openresolv: Fail if a zone is declared on multiple interfaces.
Hi
> When a zone is declared on multiple interfaces (not necessarely same
> content, but the same name), the configuration generated doesn't work,
> two entries are provided and this log indicates the failure at bind restart:
> config: error: /var/lib/bind/resolvconf-zones.conf:23: zone
> 'example.org': already exists previous definition:
> /var/lib/bind/resolvconf-zones.conf:16
>
> I think it's the same problem for other resolvers.
>
> Maybe use the first declaration, in interfaces order and drop others ?
> It's not perfect, but technically, the problem have no solution (if
> zones are the same, it works perfectly, else, some zone are not reachable).
>
> This problem also affects the version /3.5.2-1/.
I cannot replicate this.
Attached is output from a system with two interfaces each of which has
DNS servers from DHCP, IPv6RA and DHCPv6.
As you can see, the final result is generated perfectly.
uberlaptop2$ resolvconf -l
# resolv.conf from wm0.dhcp
# Generated by dhcpcd from wm0.dhcp
domain marples.name
search marples.name
nameserver 10.73.2.1
# resolv.conf from wm0.dhcp6
# Generated by dhcpcd from wm0.dhcp6
search marples.name
nameserver 2a01:348:31:2::1
# resolv.conf from wm0.ra
# Generated by dhcpcd from wm0.ra
search marples.name
nameserver 2a01:348:31:2::1
# resolv.conf from iwn0.dhcp6
# Generated by dhcpcd from iwn0.dhcp6
search marples.name
nameserver 2a01:348:31:2::1
# resolv.conf from iwn0.ra
# Generated by dhcpcd from iwn0.ra
search marples.name
nameserver 2a01:348:31:2::1
uberlaptop2$ resolvconf -v
DOMAIN='marples.name'
SEARCH='marples.name'
NAMESERVERS='10.73.2.1 2a01:348:31:2::1'
LOCALNAMESERVERS='127.0.0.1'
DOMAINS='marples.name:10.73.2.1,2a01:348:31:2::1'
uberlaptop2$ cat /etc/resolvconf.conf
name_servers=127.0.0.1
unbound_conf=/usr/pkg/etc/unbound/resolvconf.conf
named_options=/tmp/named-resolvconf-options.conf
named_zones=/tmp/named-resolvconf-zones.conf
uberlaptop2$ cat /tmp/named*
# Generated by resolvconf
forward first;
forwarders {
10.73.2.1;
2a01:348:31:2::1;
};
# Generated by resolvconf
zone "marples.name" {
type forward;
forward first;
forwarders {
10.73.2.1;
2a01:348:31:2::1;
};
};
uberlaptop2$
Can you post similar output from your system please?
Mail me directly if you don't want it to appear on this public tracker.
Roy
Bug#792428: openresolv: "Failed to get D-Bus connection" randomly at update and boot on bind9 restart
> After an update from any source (dhcp, openvpn, static, ...), restart of > bind fail with message: > Failed to get D-Bus connection: Operation not permitted > > It's not all the time, but very very often. the named (bind) subscriber doesn't use DBus, only the dnsmasq subscriber does. Are you sure it's bind it's trying to restart? Can you post your /etc/resolvconf.conf please? Roy
Bug#792428: openresolv: "Failed to get D-Bus connection" randomly at update and boot on bind9 restart
> After an update from any source (dhcp, openvpn, static, ...), restart of > bind fail with message: > Failed to get D-Bus connection: Operation not permitted > > It's not all the time, but very very often. In openresolv, only the dnsmasq subscriber uses DBus. All the named subscriber (bind) in openresolv will do is write the config files and restart named (bind). Have you modified the named subscriber to use DBus or do you write out to a dnsmasq configuration file as well? Please post your /etc/resolvconf.conf file. Roy
