-
Notifications
You must be signed in to change notification settings - Fork 105
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Add socket-activated systemd service for discovery #218
Conversation
|
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to use the same flags from /etc/default/wsdd
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How's this?
I've used the same env file but a different variable name
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
--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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be nice to make that configurable from the environmental file, but it is hardcoded in the firewall configuration anyway...
TODO: |
91e3232
to
9f2caf3
Compare
That's #219 |
9f2caf3
to
0a7e629
Compare
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 <[email protected]>
6da4adc
to
81f49c1
Compare
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.