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.

Sign up for GitHub

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

Jump to bottom

Drop hard requirement on networking #211

Merged
merged 4 commits into from
Jul 2, 2020
Merged

Drop hard requirement on networking #211

merged 4 commits into from
Jul 2, 2020

Commits on Jul 2, 2020

  1. systemd: drop hard requirement on networking 

    Whether we need networking or not for unlocking an encrypted block
device is a property of the block device in question. This is expressed
in `/etc/crypttab` via the `_netdev` option. For example, the systemd
cryptsetup generator[1] picks up on this and correctly orders unlocking
of devices that need networking after `remote-fs-pre.target`.

Thus, we shouldn't need to unconditionally require and order ourselves
after networking comes up. Let whatever interprets `/etc/crypttab` take
care of this.

Add `DefaultDependencies=no` because we need to be able to run well
before `sysinit.target`.

[1] https://www.freedesktop.org/software/systemd/man/systemd-cryptsetup-generator.html
    @jlebon
    jlebon committed Jul 2, 2020
    Configuration menu
    Copy the full SHA
    088be96 View commit details
    Browse the repository at this point in the history

  2. dracut: drop rd.neednet=1 injection 

    By default, dracut builds generic initrds which by design shouldn't have
any configuration specific to a host baked in (as opposed to so-called
"hostonly" initrds). This property is leveraged with great success in
immutable hosts like Fedora CoreOS and its downstream RHCOS where the
initrd is created server-side.

By unconditionally injecting `rd.neednet=1`, the clevis-pin-tang dracut
module makes it impossible to be included into a truly generic initrd,
where one cannot make assumptions about the network (or lack thereof,
see latchset#54) of the target hosts.

So with a generic initrd, how can we make sure that networking is up at
initrd time on a host which has been configured with root-on-LUKS with a
Tang pin? By also configuring it with `rd.neednet=1` specified on the
kernel command-line, and possibly `ip=...` to configure the network
interfaces.

This is no different from root-on-{NFS,iSCSI,NBD,...}, where one must
use explicit kernel arguments like `root=nfs:<server>:...` or
`root=iscsi:<server>:...` or `root=nbd:<server>:...`, all of which imply
`rd.neednet=1` (one could imagine then a `root=tang:<luks2_uuid>` type
karg in the future which would be roughly equivalent to
`root=UUID=<luks2_uuid> rd.neednet=1`).

Dracut also allows one to build host-specific initrds using the
`-H`/`--hostonly` option, and further the ability to bake the
command-line arguments when `--hostonly-cmdline` is provided.

So a supplementary approach here would be for `install()` to only inject
`rd.neednet=1` if using `--hostonly-cmdline` *and* somewhere along the
root block device hierarchy, there is a Tang-pinned LUKS device. This is
also analogous to what other dracut modules like 95nfs and 95iscsi do.

However, optimizations for host-only initrds should not come before
getting correct support for generic initrds.

Closes: latchset#54
Closes: latchset#206
    @jlebon
    jlebon committed Jul 2, 2020
    Configuration menu
    Copy the full SHA
    8e35e69 View commit details
    Browse the repository at this point in the history

  3. systemd: add Documentation keys to units 

    To be nice to users who want to learn more about these units.
    @jlebon
    jlebon committed Jul 2, 2020
    Configuration menu
    Copy the full SHA
    4f0b136 View commit details
    Browse the repository at this point in the history

  4. systemd: reword Description of units 

    Let's match the description style that systemd itself uses for their
password agents (see e.g. `systemd-ask-password-wall.{path,service}`).
Keeping it uniform makes it more obvious that it's the exact same setup
without having to look inside it.
    @jlebon
    jlebon committed Jul 2, 2020
    Configuration menu
    Copy the full SHA
    b2a4d1b View commit details
    Browse the repository at this point in the history