Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

incus starts dnsmasq on bridge even if dns.mode none and ipv[46].dhcp false #1537

Open
smemsh opened this issue Dec 20, 2024 · 5 comments · May be fixed by #1544
Open

incus starts dnsmasq on bridge even if dns.mode none and ipv[46].dhcp false #1537

smemsh opened this issue Dec 20, 2024 · 5 comments · May be fixed by #1544
Assignees
Labels
Bug Confirmed to be a bug Easy Good for new contributors
Milestone

Comments

@smemsh
Copy link

smemsh commented Dec 20, 2024

In internal/server/network/driver_bridge.go, Incus gathers invocation flags to pass to a dnsmasq instance, and then makes a stub empty dnsmasq.raw config file so incus will not read system dnsmasq.conf.

Nowhere is a network's dns.mode setting consulted, except to avoid adding -s, --interface-name and -S options to dnsmasq invocation. The daemon is still started even with dns.mode=none and the values of both ipv4.dhcp=false and ipv6.dhcp=false, it just doesn't get the above flags added to dnsmasq invocation in that case.

The daemon does not need to be started when nothing is using it (and explicitly disabled by configuration). My use case is complete static host db in /etc/hosts, and static ip address, done by cloud-init.

I could use an unmanaged network, but I like the bridge being created and given an IP address by Incus, and also retain option to use managed nat/firewall later. In the meantime, dnsmasq should not be started, as long as both dns and dhcp are not in use.

Incus v6.7

config:
  dns.mode: none
  ipv4.address: 10.32.192.1/22
  ipv4.dhcp: "false"
  ipv4.firewall: "false"
  ipv4.nat: "false"
  ipv6.address: none
  ipv6.dhcp: "false"
  ipv6.firewall: "false"
  ipv6.nat: "false"
description: ""
name: br0
type: bridge
used_by:
- /1.0/profiles/default
managed: true
status: Created
locations:
- none
project: default
@smemsh
Copy link
Author

smemsh commented Dec 21, 2024

It looks like the dnsmasq code is not activated at all if there is no address (empty or "none") on the bridge itself, but I think this makes it unmanaged entirely, and would mean it has to be plumbed out of band from Incus. It would be useful if we could still have it declared as "managed" (and have firewall/nat features available) but without any DNS or DHCP.

@stgraber
Copy link
Member

Yeah, it would make sense to fully disable dnsmasq if we have all of:

  • dns.mode == none
  • ipv4.address == none || ipv4.dhcp == false
  • ipv6.address == none

@stgraber stgraber added Bug Confirmed to be a bug Easy Good for new contributors labels Dec 21, 2024
@stgraber stgraber added this to the incus-6.9 milestone Dec 21, 2024
@alex14641
Copy link

I'd like to take this one.

@stgraber
Copy link
Member

sounds good, I assigned it to you!

@smemsh
Copy link
Author

smemsh commented Dec 23, 2024

Having trouble creating the Pull Request

If I may, here's a few thing I noticed: (1) it looks like you made the PR in your own repository, rather than this one; (2) you did not make a branch, but added the commit to main branch; (3) your commit message summary line does not match the format from other commits; (4) there appears to be noise in there from other unrelated PRs.

Regarding the code, if I can make a suggestion: instead of adding a condition to each location in the file that does something, only UsesDNSMasq() really needs to be modified, because it decides on whether the dnsmasq block gets run at all, so those individual conditions would be bypassed by changing it there [only].

@alex14641 alex14641 linked a pull request Dec 23, 2024 that will close this issue
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
Bug Confirmed to be a bug Easy Good for new contributors
Development

Successfully merging a pull request may close this issue.

3 participants