-
Notifications
You must be signed in to change notification settings - Fork 101
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
base: master
Are you sure you want to change the base?
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
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.
Used by the socket-activated discovery daemon
0a7e629
to
6fa319f
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.