Drop hard requirement on networking

[jlebon]

Hi,

While integrating Clevis into Fedora CoreOS and RHCOS, we've encountered problems with the way the dracut modules and Clevis units pull in networking targets. These problems are not unique to FCOS/RHCOS (see e.g. #54 and #206). This patch series fixes these dependencies to better conform to the systemd and dracut models. The most important commits in this patch series are the first two:

commit 088be96472a234b9368a437078582e8446fffc73
Date:   Thu Jul 2 11:08:55 2020 -0400

    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

commit 48e426f4631eeac7dc516ef4bbe25768b71cc58c
Date:   Thu Jul 2 11:08:56 2020 -0400

    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 #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: #54
    Closes: #206

[jlebon]

Looks like Travis CI is failing on centos8 because of:

/tmp/build/build/src/luks/tests/tests-common-functions: line 111: diff: command not found

and on debian:latest because of:

+docker exec '' -e CC -e DISTRO fc61de21c7aaebe8ccef07fefbe539d301665970 ./.travis/script
Error: No such container: 

Neither of which I think is related to this PR.

[cgwalters]

Looks great to me!

[sergio-correia]

Thanks @jlebon, it looks good. The CI failure is unrelated, indeed. Thanks @cgwalters also for looking into it.

[jlebon]

Thanks all for the quick review! @sergio-correia Were you planning on doing a release some time soon? Would greatly appreciate these patches in Fedora soon-ish (and RHEL8 too, though will make that request through bugzilla). :)

[jlebon]

OK filed an RHBZ for that here: https://bugzilla.redhat.com/show_bug.cgi?id=1853651.

I was looking at the other RHBZs filed against clevis, and I think at least https://bugzilla.redhat.com/show_bug.cgi?id=1628258 and maybe https://bugzilla.redhat.com/show_bug.cgi?id=1810332 can be closed once this PR reaches Fedora.

[sergio-correia]

Thanks, @jlebon. There's a couple of PR's I would like to get reviewed first, but yeah, we can have a release soon-ish.