feat: Add socket-activated systemd service for discovery#218
feat: Add socket-activated systemd service for discovery#218christgau merged 1 commit intochristgau:masterfrom
Conversation
|
aleasto
force-pushed
the
systemd-socket
branch
from
bb33f4a to
91e3232
Compare
etc/systemd/wsdd-discovery.service
Outdated
| [Service] | ||
| Type=simple | ||
| ; The service is put into an empty runtime directory chroot, | ||
| ; i.e. the runtime directory which usually resides under /run | ||
| ExecStart=/usr/bin/wsdd --shortlog --chroot=/run/wsdd --source-port=37020 --no-host --discovery |
There was a problem hiding this comment.
Do we want to use the same flags from /etc/default/wsdd here?
There was a problem hiding this comment.
Might help in some minor use-cases, I think (including verbosity for debugging, e.g.), so why not. But I propose to use a different environment file.
I also propose to use a different run/chroot directory for the wsdd-discovery service in order to separate it from a regular host instance. Maybe even a different (dynamic) username might be good, although I'm not sure if dynamic users are inherently distinct (due to different namespace) even when sharing the same name.
There was a problem hiding this comment.
although I'm not sure if dynamic users are inherently distinct (due to different namespace) even when sharing the same name.
They're using the same UID/GID here, so no
There was a problem hiding this comment.
How's this?
I've used the same env file but a different variable name
There was a problem hiding this comment.
--source-port 37020 could also be set in the environment file instead of hard-coded inthe systemd unit
There was a problem hiding this comment.
It would be nice to make that configurable from the environmental file, but it is hardcoded in the firewall configuration anyway...
|
TODO: |
aleasto
force-pushed
the
systemd-socket
branch
from
91e3232 to
9f2caf3
Compare
That's #219 |
aleasto
force-pushed
the
systemd-socket
branch
from
9f2caf3 to
0a7e629
Compare
aleasto
force-pushed
the
systemd-socket
branch
from
0a7e629 to
6fa319f
Compare
|
@aleasto I split the UFW rules because I think enabling discovering other devices on the network should not open ports for the host itself to be discoverable. AFAIK, Windows actually has two services as well (fdPHost and FDResPub on Win11). WDYT? |
|
Yeah I think I agree. Shouldn't you do the same for firewalld? |
Good point. Done |
Introduce a system-wide daemon listening on /run/wsdd.socket, which is managed by systemd. When a client first connects to the socket the daemon is started. Multiple clients can connect and safely use the API simultaneously. The service runs in discovery-only mode. Uses a fixed multicast source-port 37020, which is used by the socket-activated discovery daemon. Allow port 37020 in firewall profiles and split configurations for discovery (client) and host roles. Co-Authored-by: Steffen Christgau <mail@s14u.de>
christgau
force-pushed
the
systemd-socket
branch
from
6da4adc to
81f49c1
Compare
|
Would it be time to make a tagged release? |
Rather than spawning our own wsdd daemon, prefer the system service which has: * security confinement features * a fixed multicast source port which can be allowlisted to enable wsdd discovery behind restrictive firewalls. See: christgau/wsdd#218 Part-of: <https://gitlab.gnome.org/GNOME/gvfs/-/merge_requests/242>
3 participants
Introduce a system-wide daemon listening on /run/wsdd.socket, which is managed by systemd.
When a client first connects to the socket the daemon is started. Multiple clients can connect and safely use the API simultaneously.
The service runs in discovery-only mode.
Uses multicast source-port 37020.