On 5/14/19 3:52 AM, Nicolas Cavallari wrote:
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 found I could only use the system bus and not the session bus with namespaces. But maybe part is I don't think my dnsmasq configuration is very Dbus-friendly. For example, it is running inside a network namespace because there are most likely >1 tenant using the same private IP address space. So if I send a message on the system bus I want it scoped so only a single dnsmasq instance will get it, but my testing with some scripts showed that wasn't the case by default, I needed the --enable-bus flag and a corresponding profile entry.

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
dbus-daemon.

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
cleaned/adjusted:

bus_path="/tmp/test_$netns"
bus_addr="unix:abstract=$bus_path"

dbus_fifo="${bus_path}.fifo"

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
     "$bus_addr"*)
          export DBUS_SYSTEM_BUS_ADDRESS="$dbus_line";;
     [0-9]*)
          dbus_pid="$dbus_line";;
     *)
          echo "Unknown D-Bus output: '$dbus_line'" ;;
     esac
done < "$dbus_fifo"
wait

Thanks for the info, I hadn't thought of running an additional Dbus daemon inside the namespace. Unfortunately this will then start consuming even more resources (cpu, memory) as there could be hundreds or thousands of namespaces in our setup. If we can fix this with a small change it seems much less painful.

-Brian

_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Reply via email to