getsolus / packages

Solus Package Monorepo & Issue Tracker
64 stars 84 forks source link

systemd-resolved and avahi both listen for mDNS packets #1452

Closed ermo closed 9 months ago

ermo commented 9 months ago

Summary

systemd-resolved and avahi are both capable of providing multicast DNS support (self-configuring hostname and service discovery on the local network).

However, I just now noticed that avahi actively warns that this will cause issues in the systemd journal:

Jan 27 17:43:24 snekbox avahi-daemon[1382]: *** WARNING: Detected another IPv6 mDNS stack running on this host. This makes mDNS unreliable and is thus not recommended. ***
Jan 27 17:43:24 snekbox avahi-daemon[1382]: *** WARNING: Detected another IPv4 mDNS stack running on this host. This makes mDNS unreliable and is thus not recommended. ***

Here's the relevant output for listening UDP ports:

sudo ss -plnu |grep 5353
ermo@snekbox ~ $ sudo ss -plnu |grep 5353
UNCONN 0      0                          0.0.0.0:5353       0.0.0.0:*    users:(("avahi-daemon",pid=1382,fd=12))  
UNCONN 0      0                          0.0.0.0:5353       0.0.0.0:*    users:(("systemd-resolve",pid=760,fd=15))
UNCONN 0      0                                *:5353             *:*    users:(("systemd-resolve",pid=760,fd=16))
UNCONN 0      0                                *:5353             *:*    users:(("avahi-daemon",pid=1382,fd=13))

The main issue is that this causes e.g. samba service lookup in GUI file managers to become unreliable.

Steps to reproduce

  1. Start your system and check the journal
  2. Notice that avahi emits a warning as shown above

Expected result

Avahi should not emit a warning and for users with samba installed, browsing for shares should not be unreliable.

Actual result

Avahi emits a warning and users with samba installed may not see all the instances of samba servers within their network when browsing for them in their file manager.

Environment

Repo

Unstable

Desktop Environment

Plasma

System details

ermo@snekbox ~ $ inxi -b System: Host: snekbox Kernel: 6.6.12-271.current arch: x86_64 bits: 64 Console: pty pts/1 Distro: Solus 4.5 resilience Machine: Type: Desktop System: ASUS product: N/A v: N/A serial: Mobo: ASUSTeK model: ROG STRIX B550-F GAMING (WI-FI) v: Rev X.0x serial: UEFI: American Megatrends v: 3202 date: 06/15/2023 CPU: Info: 12-core AMD Ryzen 9 5900X [MT MCP] speed (MHz): avg: 2797 min/max: 2200/4950 Graphics: Device-1: AMD Vega 10 XL/XT [Radeon RX 56/64] driver: amdgpu v: kernel Display: server: X.org v: 1.21.1.11 with: Xwayland v: 23.2.4 driver: X: loaded: amdgpu unloaded: fbdev,modesetting,radeon,vesa dri: radeonsi gpu: amdgpu tty: 133x36 resolution: 3840x2160 API: OpenGL v: 4.6 compat-v: 4.5 vendor: mesa v: 23.3.4 note: console (EGL sourced) renderer: llvmpipe (LLVM 16.0.6 256 bits), AMD Radeon RX Vega (radeonsi vega10 LLVM 16.0.6 DRM 3.54 6.6.12-271.current) Network: Device-1: Intel Ethernet I225-V driver: igc Drives: Local Storage: total: 931.51 GiB used: 669.88 GiB (71.9%) Info: Processes: 404 Uptime: 2h 43m Memory: total: 64 GiB note: est. available: 62.71 GiB used: 1.7 GiB (2.7%) Init: systemd target: graphical (5) Shell: Bash inxi: 3.3.31

Other comments

No response

ReillyBrogan commented 9 months ago

Not convinced that this is the correct solution so I'll take a look at it later

ermo commented 9 months ago

Not convinced that this is the correct solution so I'll take a look at it later

For context: I did it this way because the user needs to be able to see that avahi is turning off systemd-resolved mDNS in the filesystem, such that if they have conflicting needs, they don't have to go hunting in the package repo for the specific patch or meson configure option that controls mDNS for systemd-resolved.

If a user (say a solus staff person) wants to turn off avahi-daemon and re-enable systemd-resolved mDNS, they can disable avahi-daemon.service and add another override in /etc/systemd/resolved.conf.d/enable-mdns.conf, which is completely straightforward.

In a nutshell, with this solution, what you see is what you get and you can deduce the defaults just by looking at the file system and there's no need to recompile packages to enable/disable functionality.

As an aside, @silkeh is also looking into our DNS setup.