On 26/04/2019 22:03, Brian Haley wrote:
> Currently, dhcp_release will only send a 'fake' release
> when the address given is in the same subnet as an IP
> on the interface that was given.
> This doesn't work in an environment where dnsmasq is
> managing leases for remote subnets via a DHCP relay, as
> running dhcp_release locally will just cause it to
> silently exit without doing anything, leaving the lease
> n the database.
> Change it to save the first IP it finds on the interface,
> and if no matching subnet IP is found, use it as a fall-back.
> This fixes an issue we are seeing in certain Openstack
> deployments where we are using dnsmasq to provision baremetal
> systems in a datacenter.
> While using Dbus might have seemed like an obvious solution,
> because of our extensive use of network namespaces (which
> Dbus doesn't support), this seemed like a better solution
> than creating system.d policy files for each dnsmasq we
> might spawn and using --enable-dbus=$id in order to isolate
> messages to specific dnsmasq instances.

I use D-Bus accross network namespaces without any problem. I also configured
D-Bus to look for additional policies in a tmpfs, and each time i need to start
a D-Bus enabled dnsmasq, i create an additonal policy for a new name and SIGHUP

If you want to isolate D-Bus across network namespaces, it is also possible
to start another dbus-daemon on another unix socket, then set the
DBUS_SYSTEM_BUS_ADDRESS to the address chosen by dbus-daemon, so that dnsmasq
and your other programs can use it.
I cobbled this shell script some time ago to test things, it could probably be



mkfifo "$dbus_fifo"

dbus-daemon --fork --address="$bus_addr" --system --nopidfile \
            --print-address=8 --print-pid=9 8>"$dbus_fifo" 9>&8 &

while read dbus_line; do
    case "$dbus_line" in
         export DBUS_SYSTEM_BUS_ADDRESS="$dbus_line";;
         echo "Unknown D-Bus output: '$dbus_line'" ;;
done < "$dbus_fifo"

Dnsmasq-discuss mailing list

Reply via email to