xaptum / xaptum-buildroot

External Buildroot tree for Xaptum hardware
GNU General Public License v2.0
0 stars 0 forks source link

Manage router card modes using systemd targets #101

Closed drbild closed 5 years ago

drbild commented 5 years ago

The router card will operate in one of three modes: passthrough, secure host, or secure lan mode (the latter is not yet supported).

Currently, the modes are managed as different systemd services: xbridge (passthrough) and xbridges (secure host). Each service expresses its dependencies as Requires/After parameters in its unit file. This scatters the dependencies through a chain of service files. It's hard to reason about and maintain.

Instead, we can treat each mode as a different systemd target (or runlevel, in sysv parlance). Then the service dependencies of each target can be expressed in one easy spot, as symlinks in the <target-name>.target.wants directory.

The target that systemd boots to is specified by the /etc/systemd/systemd/default.target symlink. So changing the mode is as simple as changing the symlink and rebooting.

Directory and File Structure

I envision the following directory structure

passthrough.target looks something like:

[Unit]
Description=Passthrough Mode
Requires=multi-user.target
Conflicts=secure-host.target secure-lan.target
After=multi-user.target
AllowIsolate=yes

And secure-host.target looks something like:

[Unit]
Description=Secure Host Mode
Requires=multi-user.target
Conflicts=passthrough.target secure-lan.target
After=multi-user.target
AllowIsolate=yes

When secure-lan mode is added, we might add a /etc/systemd/system/secure.target.wants target to specify services required by both secure-host and secure-lan modes. For now though, just secure-host.target.wants is sufficient.

Services and Dependencies

multi-user.target.wants

passthrough.target.wants

secure-host.target.wants

Reworking the xbridge/xbridges services

TODO. @drbild finish this section

dberliner commented 5 years ago

Switching with conman presents an issue because there is no way to tell Connman which connection file to load and no way to tell connmanctl to disable IPv4/6 after it has begun (the command suggested in the documentaiton fails as not implemented).

For now I think the best way to handle this is to have two different wifi connection files that get symbolically linked into /var/lib/connman at initialization. To do this I would create two services, connman-secure.service and connman-pass.service which link the file and cause the regular connman initialization process to begin. In the future we will not want users to have to maintain two separate files for the same wifi connections so it will either have to be managed or the passthrough mode gets those lines appended at runtime.

drbild commented 5 years ago

The approach makes sense to me.

I suggest defining just one templated systemd service to do the linking, perhaps called connman-wifi-config@.service. The template parameter will tell it which file to link.

So passthrough.target.wants would contain a symlink called connman-wifi-config@passthrough.service and secure-host.target.wants would contains a symlink called connman-wifi-config@secure-host.service.

It can list Before=connman.service to ensure it is run before connman starts. It doesn't need to start connman itself; that can be done by enabling connman.service explicitly in the active target as well. This keeps all the services clearly listed in the *.target.wants folder.

The data directory would have multiple files:

/data/connman/passthrough/wifi.config
/data/connman/secure-host/wifi.config

captived will take care of generating both versions of this file.

The unit file would look something like:

[Unit]
Description=Configure Connman Wi-Fi credentials for %I
Bore=connman.service

[Service]
Type=oneshot
ExecStart=/bin/ln -s -f /data/connman/%i/wifi.config /var/lib/connman/wifi.config

[Install]
WantedBy=%i.target

I'm not sure how systemd escaping handles hyphens (as in secure-host), so some of the %i might need to be %I.

drbild commented 5 years ago

Fixed by #103