Allow systemd services to not rely on other per VM configuration #1677
Conversation
|
I have a working PR, but I am running into a situation that requires discussion: freedomofpress/securedrop-workstation#1033 (comment). |
deeplow
force-pushed
the
log-no-more-rc-local-mods
branch
from
ca949a4 to
9bdafea
Compare
deeplow
force-pushed
the
log-no-more-rc-local-mods
branch
2 times, most recently
from
42ad584 to
0c9aa5d
Compare
|
This PR is now back into shape, ready for review. |
There was a problem hiding this comment.
Just did a pass on the code, will do actual testing in a bit. Since I'm technically the PR owner I can't actually "request changes" :< but pretend I did :)
I really like the conceptual split between log client and log server.
Also for some reason, your git identity is set to deeplow <francisco at freedom.press>, with a literal "at" instead of @, which is throwing off github's account detection.
legoktm
force-pushed
the
log-no-more-rc-local-mods
branch
from
aa32259 to
f5fbb5a
Compare
There was a problem hiding this comment.
Test plan mostly checks out, except:
sd-logdoes not receive log output fromsd-app,sd-proxyetc.
Did you mean to say it does not receive log output from sd-log and sd-gpg? If so, I verfied that.
Also do you want me to fix your git author metadata? Otherwise I think we're ready to land this \o/
That's a typo and even the opposite of the previous line. I'll remove it. I don't know what happened there. |
Yes, please if you don't mind and have time today. Otherwise I'll do it tomorrow. |
Securedrop-log had a lot of different files belonging to two distinct architectural components: a server and a client with no actual coupling. This change will help accommodate the creation of separate systemd services for the client and server. Refs securedrop-workstation#1004 NOTE: securedrop-log-saver and securedrop-redis-log now have python extensions and their binary form is created through setup.py's console scripts.
Adds the following qubes services for starting the server and respective client components of securedrop logging. The new qubes services are: - securedrop-log-client - securedrop-logging-disabled Reasoning behind this change is in securedrop-workstation#1004.
Rsyslog service should only start after this as explicitly stated by the systemd `Before` parameter.
Even though keeping it in log_server_files would keep the clean separation between client and server, since it's just one file, we can keep in the log project root.
legoktm
force-pushed
the
log-no-more-rc-local-mods
branch
from
f5fbb5a to
d83764d
Compare
This PR was migrated from freedomofpress/securedrop-log#34
This change leverages systemd features to start certain services/operations conditionally based on
hostnamequbes services, allowing us to reduce the complexity of our provisioning logic, i.e. remove modifications to rc.local per VMs.Partially fixes freedomofpress/securedrop-workstation#1033
Testing
securedrop-logsdw-admin --uninstall)securedrop-logdeb tosd-small-bullseye-templateandsd-large-bullseye-templateand install itsd-small-bullseye-template:sd-small-bullseye-templatesd-gpgandsd-log:/rw/config/rc.localin is emptysudo systemctl status securedrop-logging-disabledshows a last successful run (but the service should be inactive since it has finished)systemctl is-active securedrop-log-serverin …sd-gpgit returnsinactivesd-proxyit returnsinactivesd-logit returnsactivesystemctl status securedrop-logging-disabledin …sd-logis shows a successful runsd-gpgit shows a successful runsd-proxyfailed due to condition not met (/var/qubes/service/...)sd-logstill receives log output fromsd-app,sd-proxyetc.sd-logdoes not receive log output fromsd-app,sd-proxyetc.make dev(this requires nightly packages to test)Order of operation for merging
To not waste CI time, I'd recommend merging in the following order: