Systemd issues [SOLVED]

Development
1

There are some difficult issues with the needed port to systemd for Debian jessie.

[hr]

GitHub - Kicksecure/initializer-dist: for better security. Makes finding backdoors easier. is supposed to only be started when the system boots up. No issue with redistributable images here. It does first run initialization on first boot and then won’t ever start again, because a done file will be created. For other kinds of future install methods this is not so nice. Because when it was installed by apt-get, the service would run in background and then suddenly force restart the system, which would be very surprising and not very nice. Therefore with sysvinit it was simple. /usr/lib/first_run_initializer_gui checked if the DPKG_MAINTSCRIPT_PACKAGE environment variable was set and exits if yes. The problem here is, that systemd does not preserve the environment. (Environment= or EnvironmentFile= are not help here.)

Asked on stackexchange if env vars can be preserved:

Other implementation option… Can systemd tell somehow the script if it was called as part system boot up or other case?

[hr]

Systemd does not support custom actions?

That would be a bit troublesome. Would require some refactoring in sdwdate then. No idea how to deal with that yet. I’ll explain what custom action it supports at the moment.

/etc/init.d/sdwdate restartnd - the “nd” stands for “no dispatch”. It passes options to not dispatch gui notifications when running for the first iteration. This is useful for timesync. Because timesync restarts sdwdate using restartnd, because timesync works as a monitor that starts its own gui.

/etc/init.d/sdwdate force-reload - it deletes the first success file. Sdwdate acts differently depending on if it started up for the very first time. Then it does clock jumps using date. But if it globally succeeded at least once, it gradually adjusts the clock using sclockadj. For enforcing clock jumps (what it does when run by timesync) the force-reload option is used.

/etc/init.d/sdwdate restartndclean - a combination of both.

[hr]

https://github.com/Whonix/Whonix/issues/292 - probably not that hard, but help welcome.

[hr]

Related to above. When using StandardInput=tty then sudo systemctl restart servicename no longer works. This is a problem, because dpkg maintainer scripts automatically run a similar command (invoke-rc.d) and it would hang forever during upgrades. (When aborting, ending up with fixable package system.) So this also needs some conditional case ignoring the restart action then.

[hr]

Porting Whonix’s sysvinit files to systemd. Probably not that hard either, but also help welcome.

2

[quote=“Patrick, post:1, topic:651”]There are some difficult issues with the needed port to systemd for Debian jessie.

[hr]

GitHub - Kicksecure/initializer-dist: for better security. Makes finding backdoors easier. is supposed to only be started when the system boots up. No issue with redistributable images here. It does first run initialization on first boot and then won’t ever start again, because a done file will be created. For other kinds of future install methods this is not so nice. Because when it was installed by apt-get, the service would run in background and then suddenly force restart the system, which would be very surprising and not very nice. Therefore with sysvinit it was simple. /usr/lib/first_run_initializer_gui checked if the DPKG_MAINTSCRIPT_PACKAGE environment variable was set and exits if yes. The problem here is, that systemd does not preserve the environment. (Environment= or EnvironmentFile= are not help here.)[/quote]

I listed an example below how to accomplish this. Just check for the file that is created after it is run for the first time. If the file does not exist, it is not run. You could have another script run before this that will place a file in /var/run/whonix/initializer.done or just read from file system? The oneshot means it runs, and then its done until next time system restarted.

[Unit]
Description=Whonix Initializer
!ConditionPathExists=|/var/root/.whonix/initialization.done
After=xxx.service

[Service]
Type=oneshot
ExecStartPre=/usr/lib/whonix/pre-initializer
ExecStartPre=/usr/lib/whonix/pre-initializer2
ExecStart=/usr/lib/whonix/whonix-initializer
StandardOutput=syslog

[Install]
WantedBy=multi-user.target
3

[quote=“Patrick, post:1, topic:651”]Systemd does not support custom actions?

That would be a bit troublesome. Would require some refactoring in sdwdate then. No idea how to deal with that yet. I’ll explain what custom action it supports at the moment.

/etc/init.d/sdwdate restartnd - the “nd” stands for “no dispatch”. It passes options to not dispatch gui notifications when running for the first iteration. This is useful for timesync. Because timesync restarts sdwdate using restartnd, because timesync works as a monitor that starts its own gui.

/etc/init.d/sdwdate force-reload - it deletes the first success file. Sdwdate acts differently depending on if it started up for the very first time. Then it does clock jumps using date. But if it globally succeeded at least once, it gradually adjusts the clock using sclockadj. For enforcing clock jumps (what it does when run by timesync) the force-reload option is used.

/etc/init.d/sdwdate restartndclean - a combination of both.[/quote]

Sorry, I have to make this real quick since I need to leave in 5 minutes :slight_smile:

You can break the sdwdate unit into multiple units; no need to just pile everything in one unit. I will look at it further later. I need to understand better how sdwdate works and I only had time to glance at this quickly

4

Interesting idea about multiple unit files for sdwdate! I don’t know if that would be Debian policy conform, though. (At some point getting it into official Debian repo would be nice.)

[hr]

About Whonix Initializer, image someone runs “sudo apt-get install whonix-workstation”. As part of it, also whonix-initializer gets installed. /root/.whonix/first_run_initializer.done does not exist at that time. So systemd would run it. But at the end of whonix-initializer, whonix-initializer would restart the system, which is unwanted. So whonix-initializer needs some way to know if it was run by apt-get/dpkg or during system startup (where reboot would be appropriate).

5

Why not just go the other way around then… When you do the initial installation place a file somewhere and when initialization is complete, delete it. I like this better anyway since less littering of file system and for my purposes in Qubes, one less file to link :slight_smile:

6

It looks like many package are doing that; guess you better look into it though.

I just split my setup script that was being called by udev into 3 separate systemd units since one of the qubes modules was enabling ip forwarding.

I am able to make sure it runs after that service now so I can disable it. Now the 3 units are:

[ul][li]network setup (add the actual eth1 interface)[/li]
[li]housekeeping including search and replace IP’s[/li]
[li]bring firewall up[/li][/ul]

7

Yeah, good idea. The cleanup chroot script can create that todo file. Thereby making run of whonix-initializer opt-in rather than opt-out. A much cleaner approach generally. Will work on that.

8

[quote=“Patrick, post:7, topic:651”][quote author=nrgaway link=topic=707.msg5310#msg5310 date=1415328418]
Why not just go the other way around then… When you do the initial installation place a file somewhere and when initialization is complete, delete it. I like this better anyway since less littering of file system and for my purposes in Qubes, one less file to link :slight_smile:
[/quote]
Yeah, good idea. The cleanup chroot script can create that todo file. Thereby making run of whonix-initializer opt-in rather than opt-out. A much cleaner approach generally. Will work on that.[/quote]
Implemented:

Not yet tested.

9

[quote=“nrgaway, post:6, topic:651”][quote author=Patrick link=topic=707.msg5302#msg5302 date=1415303866]
Interesting idea about multiple unit files for sdwdate! I don’t know if that would be Debian policy conform, though. (At some point getting it into official Debian repo would be nice.)
[/quote]

It looks like many package are doing that; guess you better look into it though.[/quote]
Know any examples that would be close to this use case?

https://packages.debian.org/search?searchon=contents&keywords=.service&mode=path&suite=testing&arch=any

10

[quote=“Patrick, post:9, topic:651”][quote author=nrgaway link=topic=707.msg5311#msg5311 date=1415328914]

It looks like many package are doing that; guess you better look into it though.
[/quote]
Know any examples that would be close to this use case?

https://packages.debian.org/search?searchon=contents&keywords=.service&mode=path&suite=testing&arch=any[/quote]

The one that comes to mind is lirc. They seems to use 2 systemd service files on Fedora. Looks like not many packages have been converted over to Debian yet, so maybe look at some fedora examples. Here is the rpm spec file for lirc http://pkgs.fedoraproject.org/cgit/lirc.git/tree/lirc.spec#n230. Looks like they still using sysvinit on Debian.

Looks like environments are also supported.
http://www.freedesktop.org/software/systemd/man/systemd.service.html
http://www.freedesktop.org/software/systemd/man/systemd.unit.html

11

How to implement policy conform systemd custom actions on Debian?

12

ticket:
https://phabricator.whonix.org/T106

13

All solved / implemented.