Skip to content
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

Leverage systemd conditionals for logging services #396

Closed
wants to merge 1 commit into from

Conversation

eaon
Copy link
Contributor

@eaon eaon commented Oct 24, 2022

Goal of this change is to make it possible to just enable all the services we need on all VMs, but have them start exclusively in the VMs they're meant for.

Since we have predictable hostnames, we can ask systemd to only start services for specific hostnames.

Relies on 2 PRs in other repos:

Testing

  • CI passes
  • Check out Allow systemd services to not rely on other per VM configuration securedrop-log#34 next to this working directory
  • Build debian packages for securedrop-log and securedrop-workstation-config
  • Transfer both packages to sd-small-bullseye-template and install them
  • In sd-small-bullseye-template, run systemctl is-enabled securedrop-log and systemctl is-enabled securedrop-disable-remote-logging, both return enabled
  • Shut down sd-small-bullseye-template
  • Run mv /rw/config/rc.local.bak /rw/config/rc.local in sd-gpg and sd-log
  • Restart sd-gpg, sd-log, and sd-proxy
  • When running systemctl is-active securedrop-log in …
    • sd-gpg it returns inactive
    • sd-proxy it returns inactive
    • sd-log it returns active
  • When running systemctl is-active securedrop-disable-remote-logging in …
    • sd-log it returns active
    • sd-gpg it returns active
    • sd-proxy it returns inactive
  • sd-log still receives log output from sd-app, sd-proxy etc.

Order of operation for merging

To not waste CI time, I'd recommend merging in the following order:

  1. Allow systemd services to not rely on other per VM configuration securedrop-log#34
  2. Leverage systemd conditionals for logging services #396

Goal of this change is to make it possible to just enable all the
services we need on all VMs, but have them start exclusively in the VMs
they're meant for.

Since we have predictable hostnames, we can ask systemd to only start
services for specific hostnames.
@eaon eaon force-pushed the systemd-replacing-rclocal branch from d6952e4 to 942d41d Compare October 24, 2022 19:41
@legoktm
Copy link
Member

legoktm commented Nov 3, 2022

To install systemd units "properly", in d/rules we need:

override_dh_installsystemd:
	dh_installsystemd --name=securedrop-disable-remote-logging

And the unit should be located at securedrop-workstation-config/debian/securedrop-workstation-config.securedrop-disable-remote-logging.service.

Relevant docs at https://manpages.debian.org/bullseye/debhelper/dh_installsystemd.1.en.html#name=

@deeplow
Copy link

deeplow commented May 13, 2024

To install systemd units "properly", in d/rules we need:

override_dh_installsystemd:
dh_installsystemd --name=securedrop-disable-remote-logging

And the unit should be located at securedrop-workstation-config/debian/securedrop-workstation-config.securedrop-disable-remote-logging.service.

@legoktm it turns out you had already done pasted your research here over a year ago and I failed to see it. Sorry for the duplicated effort.

@deeplow
Copy link

deeplow commented May 13, 2024

Closing this PR since all the build logic is now in https://github.com/freedomofpress/securedrop-client and will be tackled in freedomofpress/securedrop-client#1677.

@deeplow deeplow closed this May 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants