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

nixos/clevis: init & support for zfs, bcachefs and luks #257525

Merged
merged 2 commits into from
Dec 2, 2023

Conversation

JulienMalka
Copy link
Member

@JulienMalka JulienMalka commented Sep 26, 2023

Description of changes

Work done with equal contribution from @camillemndn. This work has been founded as part of an NGI Assure grant from NLNet.

This PR adds support for unattended decryption of encrypted boot device using Clevis and Tang. In this first PR, we add:

  • A module for Tang alongside its NixOS test
  • A module for Clevis that centralizes the devices that should be unlocked at boot using Clevis and their respective secret file
  • Tentative implementations for zfs, bcachefs and luks with implementations for initrd with and without systemd stage1 (bcachefs systemd stage 1 has not been done, waiting on bcachefs: support unlocking in systemd-based stage1 #249556)
  • A set of tests for these implementations using Tang-binded secrets

Remaining to do before merging this PR:

  • A NixOS manual page
  • Write tests for TPM2-binded secrets
  • Compute the exact closures for the tests and drop the includeBuildDependencies option
  • Test on more real hardware (only luks has been tested on real hardware)

@github-actions github-actions bot added 6.topic: nixos Issues or PRs affecting NixOS modules, or package usability issues specific to NixOS 8.has: documentation This PR adds or changes documentation 8.has: changelog 8.has: module (update) This PR changes an existing module in `nixos/` labels Sep 26, 2023
@camillemndn
Copy link
Contributor

To-do: write a test to check the fallback on interactive passphrase

@ofborg ofborg bot added 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin 10.rebuild-linux: 1-10 labels Sep 27, 2023
@jfroche
Copy link
Contributor

jfroche commented Oct 2, 2023

Maybe rebase it on #247037 ?

@JulienMalka
Copy link
Member Author

Maybe rebase it on #247037 ?

Oops sorry wasn't aware of the existence of #247037. Your tang module seems more advanced, I am favorable to rebasing on your PR :)

nixos/modules/tasks/filesystems/zfs.nix Show resolved Hide resolved
nixos/modules/tasks/filesystems/zfs.nix Outdated Show resolved Hide resolved
nixos/modules/tasks/filesystems/zfs.nix Outdated Show resolved Hide resolved
nixos/modules/services/security/tang.nix Outdated Show resolved Hide resolved
nixos/modules/services/security/tang.nix Outdated Show resolved Hide resolved
nixos/modules/system/boot/luksroot.nix Outdated Show resolved Hide resolved
@JulienMalka
Copy link
Member Author

I rebased this PR on #247037 from @jfroche, we can review tang specific stuff there

@JulienMalka JulienMalka force-pushed the clevis branch 2 times, most recently from 027ded9 to e20e20c Compare October 16, 2023 11:41
@h7x4 h7x4 added 8.has: module (new) This PR adds a module in `nixos/` 8.has: tests This PR has tests 8.has: module (update) This PR changes an existing module in `nixos/` and removed 8.has: module (update) This PR changes an existing module in `nixos/` labels Oct 16, 2023
@camillemndn camillemndn self-assigned this Oct 18, 2023
@camillemndn camillemndn force-pushed the clevis branch 2 times, most recently from 43a2a72 to d86644d Compare October 18, 2023 19:21
@camillemndn
Copy link
Contributor

We will have to rebase on #261884 when it is merged.

@RaitoBezarius RaitoBezarius marked this pull request as draft October 19, 2023 10:30
@JulienMalka
Copy link
Member Author

@ofborg test installer

@JulienMalka
Copy link
Member Author

Looks like ofborg is not able to run all the tests before timing out. what should we do about that? Target staging instead?

@RaitoBezarius
Copy link
Member

RaitoBezarius commented Nov 27, 2023 via email

@JulienMalka
Copy link
Member Author

JulienMalka commented Nov 27, 2023

Ran the tests,

installer.nix:

/nix/store/fkwps4301063isl04d8zacyqqf4h1cy1-vm-test-run-installer-bcachefs-encrypted
/nix/store/v36qlf0yn0yf8nwsi16yaz5i3xvgrlfj-vm-test-run-installer-bcachefs-linux-testing
/nix/store/hj25siq9z6h926z0vgiw0b45yqhrw8ym-vm-test-run-installer-bcachefs-multi
/nix/store/6fw3rpf278cqlhv3pnjgpl3zfnyisin2-vm-test-run-installer-bcachefs-simple
/nix/store/fm9w7zpncjnn1sj3w06anhjsd0bnq7jx-vm-test-run-installer-bcachefs-upgrade-to-linux-testing
/nix/store/ynk8d63n3ahx0bzkpaznqxf3jwxqc5gm-vm-test-run-installer-btrfsSimple
/nix/store/3xqkhqxbc2ciipmzsbvlklxpdls82y3p-vm-test-run-installer-btrfsSubvolDefault
/nix/store/f01qj9h8bic3csr5fqm0z6phjzv8diik-vm-test-run-installer-btrfsSubvolEscape
/nix/store/v0ivy260cgm6f9ijy5jqba4cfzjy5wc5-vm-test-run-installer-btrfsSubvols
/nix/store/b85ml9gmbhy66qcs6jlyn84fvbagirwq-vm-test-run-installer-clevis-bcachefs
/nix/store/2402fr2iqanypdg25x5ni5w9rc85lvyv-vm-test-run-installer-clevis-bcachefs-fallback
/nix/store/6plb6k4lsx827n0c7yxmg6g4hgxpfiy0-vm-test-run-installer-clevis-luks
/nix/store/bpx7rn0bf4vvqsixc9s449fqjz0v3xjj-vm-test-run-installer-clevis-luks-fallback
/nix/store/7g2ck0whxx9s4z2ivkafdv7y000pppqg-vm-test-run-installer-clevis-zfs
/nix/store/i28lb7p6s4iapsh16qla1lzpxcj8scpc-vm-test-run-installer-clevis-zfs-fallback
/nix/store/mx90a24l7y0s7sk2w21nkia9y27v89bb-vm-test-run-installer-encryptedFSWithKeyfile
/nix/store/k25zdz02gp6rm2kbcmjdz0k3axphh46w-vm-test-run-installer-fullDiskEncryption
/nix/store/1j837jk9qrq2d3fkv0gks206lvvywwr2-vm-test-run-installer-luksroot-format1
/nix/store/7myhf0cpyl0pp6v35y6vgxinv766s3d0-vm-test-run-installer-luksroot-format1
/nix/store/drncc05mgpryg81wsc8y74cm46p23xmi-vm-test-run-installer-luksroot-format2
/nix/store/06rd14kc1p9gbi36ag1wyfagg365k2xw-vm-test-run-installer-lvm
/nix/store/n1vqpmwgwpj8vp4ja8prlz042xy6b6rq-vm-test-run-installer-separateBoot
/nix/store/zi6qahyic9kvb0650ck881ir3xp8hnmf-vm-test-run-installer-separateBootFat
/nix/store/yzsm2vd8rdh263yisl3j10hldskm5biz-vm-test-run-installer-simple
/nix/store/2c7sadj2hmbw6jx2230cv3b9rp6hsisy-vm-test-run-installer-simpleLabels
nix/store/b2mh48ixlmlxf66jx13gqkah2xl2v077-vm-test-run-installer-simpleProvided
nix/store/h98rqgc7w0i1s9fimqilmk9m7b8r1jpx-vm-test-run-installer-simpleUefiGrub
/nix/store/jzslmgw6hyci7sbn2vyh3zdvbbsjnga3-vm-test-run-installer-simpleUefiSystemdBoot
/nix/store/bp1rnj2icgaxaby5wm6jqffsrx6vkx64-vm-test-run-installer-switch-to-flake
/nix/store/5132cl5c25q5xcc0rgh3ym0pbv2v48hf-vm-test-run-installer-swraid
/nix/store/2vwfl4f6aq3cqq0291dr0ljjgyf7qlck-vm-test-run-installer-zfs-root

installer-systemd-stage-1.nix:

/nix/store/4ijpwi32x001f4xn1fb8ymsv0v7m3i87-vm-test-run-installer-btrfsSimple
/nix/store/vx3qppin8w3d0dnd64rsj7ydsdab3wdl-vm-test-run-installer-btrfsSubvolDefault
/nix/store/605h7rld4cc2dk9b6v6c5ij2n2anvpv9-vm-test-run-installer-btrfsSubvolEscape
/nix/store/zvyjjs30y9pv9w12zjnn1jwlj1x1fv6f-vm-test-run-installer-btrfsSubvols
/nix/store/vmg6khdiphvw0dygnmrrn9ybx1hmj71r-vm-test-run-installer-clevis-luks
/nix/store/mdh3yik0p4mzz0ilr91ipxnn6b7fzbif-vm-test-run-installer-clevis-luks-fallback
/nix/store/hdsfb64pmhv8ijfh07g824csxwh10igk-vm-test-run-installer-clevis-zfs
/nix/store/z8xqnwrzjnix9lgqkndqqm9j59bd8zzr-vm-test-run-installer-clevis-zfs-fallback
/nix/store/h3xxhafgfipnaahn8ik8iyic51zw8dr8-vm-test-run-installer-encryptedFSWithKeyfile
/nix/store/y0r4qv923x2p0p2ihsgkv6z11hp8nq4n-vm-test-run-installer-luksroot-format1
/nix/store/0jjjhp5q2qh3cyqr05l5yxh2islv58yk-vm-test-run-installer-luksroot-format1
/nix/store/fn2nyir1m6kzw50h0v22mzwzvmkfl0gl-vm-test-run-installer-luksroot-format2
/nix/store/q6hrczmb06i51nms1hifj6r9dahxsajk-vm-test-run-installer-separateBoot
/nix/store/c3nqd5mp1f4kcxnymx3rx68hhhwg66r7-vm-test-run-installer-separateBootFat
/nix/store/wkqikd3j5h04xpxxsnqzivih4nwvc778-vm-test-run-installer-simple
/nix/store/vczsi44z4yhg11by79sj1dm88hchr32q-vm-test-run-installer-simpleLabels
/nix/store/g9i9jr4sbx2zb7m0jadrz1gdifk7iplp-vm-test-run-installer-simpleProvided
/nix/store/pbrkr535b7zkx8vpwcwhlhznbbzcg6yf-vm-test-run-installer-simpleUefiGrub
/nix/store/n3xnlyihrhjy7dkw0yykz2barhhhjd15-vm-test-run-installer-simpleUefiSystemdBoot
/nix/store/6hkv31rd4g0yma4fr03n9pkvbg1kifyg-vm-test-run-installer-stratisRoot
/nix/store/w2f5ajg87n65cfc5bggn947irlgddl7w-vm-test-run-installer-swraid
/nix/store/dd2v8d9z2xg691d21wg3h903nhxrbm2c-vm-test-run-installer-zfs-root

I had to exclude tests that are already broken on Hydra. @RaitoBezarius you have access to the machine on which I performed the tests so if you want to check go ahead.

@ElvishJerricco
Copy link
Contributor

@JulienMalka can you also run the installer-systemd-stage-1 tests?

@JulienMalka
Copy link
Member Author

@JulienMalka can you also run the installer-systemd-stage-1 tests?

I've done that already, the results are in the previous message.

@RaitoBezarius RaitoBezarius marked this pull request as draft November 28, 2023 18:10
@RaitoBezarius RaitoBezarius marked this pull request as ready for review November 28, 2023 18:10
Copy link
Member

@RaitoBezarius RaitoBezarius left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Merge conflict with release notes.

nixos/modules/system/boot/clevis.md Outdated Show resolved Hide resolved
nixos/modules/system/boot/clevis.md Outdated Show resolved Hide resolved
@@ -1081,6 +1096,35 @@ in
boot.initrd.preLVMCommands = mkIf (!config.boot.initrd.systemd.enable) (commonFunctions + preCommands + concatStrings (mapAttrsToList openCommand preLVM) + postCommands);
boot.initrd.postDeviceCommands = mkIf (!config.boot.initrd.systemd.enable) (commonFunctions + preCommands + concatStrings (mapAttrsToList openCommand postLVM) + postCommands);

boot.initrd.systemd.services = let devicesWithClevis = filterAttrs (device: _: (hasAttr device clevis.devices)) luks.devices; in
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One way you could address @RaitoBezarius's comment would be to make a service per device, and wed it to the systemd.device showing up. I think that's pretty clean, and it's a 1:1 map to the code in nixos/modules/system/boot/luksroot.nix

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you, I think I'll address these remarks in a follow-up PR.

nixos/modules/system/boot/luksroot.nix Show resolved Hide resolved
camillemndn and others added 2 commits December 2, 2023 11:55
Co-Authored-By: Julien Malka <julien@malka.sh>
Co-Authored-By: Camille Mondon <camillemondon@free.fr>
@JulienMalka
Copy link
Member Author

Fixed conflicts with rl-2405-section.md again

@RaitoBezarius
Copy link
Member

Merging because it is constantly entering into merge conflicts with release notes and we plenty tested this PR by now.

@RaitoBezarius RaitoBezarius merged commit 8626b5c into NixOS:master Dec 2, 2023
5 of 6 checks passed
@JulienMalka JulienMalka deleted the clevis branch December 2, 2023 14:41
@JulienMalka
Copy link
Member Author

Many thanks to everyone that took part of the review process of this PR, especially @ElvishJerricco, @RaitoBezarius, @philiptaron :)

@philiptaron
Copy link
Contributor

Yay! Congratulations @JulienMalka.

@@ -623,6 +629,9 @@ in
fi
poolImported "${pool}" || poolImport "${pool}" # Try one last time, e.g. to import a degraded pool.
fi

${concatMapStringsSep "\n" (elem: "clevis decrypt < /etc/clevis/${elem}.jwe | zfs load-key ${elem}") (filter (p: (elemAt (splitString "/" p) 0) == pool) clevisDatasets)}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't this add calls to clevis even when boot.initrd.clevis.enable is false?

I think that's why I started getting this evaluation error yesterday: https://gist.github.com/aij/bb5c49f0afbde2b3efdfc8f30c1e7b6e

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you have clevis devices set but clevis disabled ? Or do you have nothing clevis related in your config but still evaluation errors ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for reporting that, I am proposing a fix here: #272061

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry about the delay. FWIW, I had nothing clevis related in my configs.

Fix looks good. Thanks!

@@ -17,6 +17,9 @@ let
cfgZED = config.services.zfs.zed;

selectModulePackage = package: config.boot.kernelPackages.${package.kernelModuleAttribute};
clevisDatasets = map (e: e.device) (filter (e: (hasAttr e.device config.boot.initrd.clevis.devices) && e.fsType == "zfs" && (fsNeededForBoot e)) config.system.build.fileSystems);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is mishandling fileSystems with device = null (the default).

For example, I'm mounting /boot by label with

  fileSystems."/boot" =
    { label = "boot";
      fsType = "ext4";
    };

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I think you are right

@gernotfeichter
Copy link
Contributor

gernotfeichter commented Dec 25, 2023

First, thanks for all the effort that must have gone into this!

Unfortunately I'm still struggling to get this working.

Sry for reusing the thread but I guess all the experts are here and I feel many non-experts would appreciate some more guidance here ;)

I would like my tang server to unlock my LUKS device (setup via standard nix-os ui installer - full disk encryption).

Things I tried so far...

Approach via clevis luks bind

sudo clevis luks bind -d /dev/sda2 tang "{\"url\":\"${TANG_URL}\"}"

This creates an entry in the LUKS header such that sudo cryptsetup luksDump /dev/sda2 actually shows a new slot. While this approach is not documented, I think I used that approach successfully on non-nixos instances and feels "right".

Outcome: Nothing happens -> The password prompt still shows up, nothing regarding clevis is logged.

Could it be that what I want is still not possible and this issue status is actually still correct (OPEN atm.): #121636

I think people are also curious on that thread as well...

Approach via secretFile - JWE

Clevis.md actually only mentions a clevis encrypt tang snippet. I assumed it could make sense that it was implemented in a way that the actual passphrase is tang-encrypted, so I tried obtaining a jwe via specifying my LUKS passphrase as input to said command (along with the URL to the TANG server of course) and then referencing that keyFile in my hardware-configuration.nix.

Outcome: Boot Log shows No key available with this passphrase.

Whole boot log - see
screenshot_boot_log

My nix configs (used for both approaches)

Only the secretFile is different and only enabled in the latter approach!

hardware-configuration.nix

...shortened to relevant parts. I learned you should not alter that file because it could be overwritten in the future - but should not make a difference - a module is a module?!

  boot.initrd.availableKernelModules = [ "xhci_pci" "ehci_pci" "ahci" "usb_storage" "sd_mod" "sr_mod" "r8169" "iwlwifi" ];  # some kernel modules required for networking in initrd, the latter two I obtained by running `lspci -v | grep -iA8 'network\|ethernet' | grep 'Kernel modules'`

  fileSystems."/" =
    { device = "/dev/disk/by-uuid/8bab4a62-e773-4faa-abc0-003d57c4b4d4";
      fsType = "ext4";
    };

  boot.initrd.luks.devices."luks-f0675919-6bf4-4886-a68e-1c1f61036d34".device = "/dev/disk/by-uuid/f0675919-6bf4-4886-a68e-1c1f61036d34";

  fileSystems."/boot" =
    { device = "/dev/disk/by-uuid/52DB-C8DE";
      fsType = "vfat";
    };

  boot.initrd.network.enable = true;
  boot.initrd.network.udhcpc.enable = true;
  boot.initrd.clevis.enable = true;
  boot.initrd.clevis.useTang = true;
  boot.initrd.clevis.devices."luks-f0675919-6bf4-4886-a68e-1c1f61036d34".secretFile = ./luks-f0675919-6bf4-4886-a68e-1c1f61036d34.jwe;

Any help or hint appreciated!

UPDATE: it works now, not 100% what was the problem though.

PS: snippet for creating the .jwe file (fill out stuff in <brackets>):

echo -n '<your luks passphrase>' | clevis encrypt tang '{"url": "http://<your tang server>:<your tang port>"}' > test.jwe

@JulienMalka
Copy link
Member Author

@gernotfeichter Hello, ideally not to ping all the people suscribed to this PR can we continue this on Matrix ? My username is JulienMalka:matrix.org
Otherwise you can contact me via email: julien@malka.sh

"initrd-switch-root.target"
"shutdown.target"
];
wants = [ "systemd-udev-settle.service" ] ++ optional clevis.useTang "network-online.target";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

systemd-udev-settle is broken by design and should not be used, ever. See #73095 (comment).
I don't know what you're trying to depend on, but this is most likely not the correct way.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We use that to wait for TPM2 to be available. Do you know of another synchronization point for that ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you know the exact device path (say under /dev/ or /sys) in advance you can add a dependency on a device unit (see systemd.device(5)). Otherwise you could listen for the specific udev events using udevadm monitor -s <subsystem>/<devicetype> in you script. There's an example here.

Copy link
Contributor

@rnhmjoj rnhmjoj Jan 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems TPM2 devices get linked to /dev/tpmrm, so you should probably add a Wants=dev-tpmrm0.device dependency.

I don't know if systemd handles TPMs devices by default, though. If not you'll also have to add a TAG+=systemd rule on those devices.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, look what was just commited to systemd: systemd/systemd@4e1f003

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea, in the future, we should definitely change this to use tpm2.target. At the moment, I don't know if we can add dependencies on dev-tpmrm0.device directly, because that would cause boot to delay waiting for that device to timeout in the event that one doesn't exist.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The tpm2 target does exactly this: it adds a dependecy on dev-tpmrm0.device, so it will time out without a TPM.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rnhmjoj But tpm2.target is not in the initial transaction by default. It only gets added by systemd-tpm2-generator if it detects that the TPM2 exists in /dev or according to the firmware (via efi variables). Units aren't supposed to have Wants=tpm2.target, only After=tpm2.target so that they're ordered properly when a TPM exists.

Early boot programs that intend to access the TPM2 device should hence order themselves after this target unit, but not pull it in.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I see. Anyway, it seems that this service does require a TPM, so should it be if not a timeout?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rnhmjoj I don't think a TPM is required necessarily? I think the .jwe determines if a TPM is required.

@@ -154,6 +157,9 @@ let
poolImported "${pool}" || poolImport "${pool}" # Try one last time, e.g. to import a degraded pool.
fi
if poolImported "${pool}"; then
Copy link
Contributor

@misuzu misuzu Jun 11, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the entire zfs pool is encrypted it will ask the password before this check and clevis won't be able to decrypt the pool.

Jun 11 22:42:05 localhost zfs-import-rpool-start[327]: importing ZFS pool "rpool"...
Jun 11 22:42:05 localhost zfs-import-rpool-start[652]: Key load error: Keys must be loaded for encryption root of 'rpool/safe/root' (rpool).

I have this config:

{ config, pkgs, ... }:
{
  boot.initrd.clevis.enable = true;
  boot.initrd.clevis.devices."rpool/safe/root".secretFile = "/etc/initrd/clevis/rpool.jwe";
}

The filesystems config is roughly like this:

{
  fileSystems."/" =
    { device = "rpool/safe/root";
      fsType = "zfs";
    };

  fileSystems."/nix" =
    { device = "rpool/local/nix";
      fsType = "zfs";
    };

  fileSystems."/boot" =
    { device = "/dev/disk/by-uuid/E08C-AFC5";
      fsType = "vfat";
      options = [ "fmask=0022" "dmask=0022" ];
    };
}
% zfs list -rHo name,keylocation,keystatus -t volume,filesystem rpool
rpool   prompt  available
rpool/local     none    available
rpool/local/nix none    available
rpool/reserved  none    available
rpool/safe      none    available
rpool/safe/root none    available

With this config it tries to execute zfs load-key rpool/safe/root which fails with Key load error: Keys must be loaded for encryption root of 'rpool/safe/root' , but it works if I execute zfs load-key rpool:

-bash-5.2# zfs load-key rpool/safe/root
Key load error: Keys must be loaded for encryption root of 'rpool/safe/root' (rpool).
-bash-5.2# zfs load-key rpool
Enter passphrase for 'rpool':

If I use boot.initrd.clevis.devices."rpool".secretFile = "/etc/initrd/clevis/rpool.jwe"; it fails to evaluate:

       Failed assertions:
       - No filesystem or LUKS device with the name rpool is declared in your configuration.

This looks like a module deficiency to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
6.topic: nixos Issues or PRs affecting NixOS modules, or package usability issues specific to NixOS 8.has: changelog 8.has: documentation This PR adds or changes documentation 8.has: module (new) This PR adds a module in `nixos/` 8.has: module (update) This PR changes an existing module in `nixos/` 8.has: tests This PR has tests 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin 10.rebuild-linux: 1-10
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.