attestation-server fails on first boot #80
Comments
|
It currently works on my machine but I admit that this is an ugly workaround. I was hoping that simply ordering a different command before copying the credentials would fix the race condition but it seems your computer is too fast. Anyway, the next version of systemd addresses this properly with systemd/systemd#16568. |
|
System 247 is already in nixpkgs (NixOS/nixpkgs#102355) but not yet in the stable release. |
|
Is it actually okay if we wait for the next stable or should I fix it now? I think something like this would work but this would give the service access to all files and directories owned by group diff --git a/nixos/attestation-server/module.nix b/nixos/attestation-server/module.nix
index fe7e55f..2b5c039 100644
--- a/nixos/attestation-server/module.nix
+++ b/nixos/attestation-server/module.nix
@@ -124,10 +124,11 @@ in
# first command is run as root the allocation of uid and gid for the
# service seems to be delayed, so we just run something else first.
"${pkgs.coreutils}/bin/touch %S/attestation/emailPassword"
- "+${pkgs.coreutils}/bin/install -m 0600 -o %N -g %N ${passwordFile} %S/attestation/emailPassword"
+ "+${pkgs.coreutils}/bin/install -m 0640 -g keys ${passwordFile} %S/attestation/emailPassword"
''${pkgs.sqlite}/bin/sqlite3 %S/attestation/attestation.db "INSERT OR REPLACE INTO Configuration VALUES ${values}"''
"${pkgs.coreutils}/bin/rm -f %S/attestation/emailPassword"
];
+ SupplementaryGroups = [ "keys" ];
# When sending TERM, e.g. for restart, AttestationServer fails with
# this exit code. |
|
It'd be nice to have it working before the next major NixOS release, and I aim to not use features from NixOS until it's in a stable release. If there isn't another reasonable alternative that doesn't require granting permissions to files in the |
As already noted previously, using the service name as the user and group name in conjunction with DynamicUser sporadically fails. There is a better way to provision secrets for services with upcoming systemd 247, but for now we use a SupplementaryGroup to install the secret.
As already noted previously, using the service name as the user and group name in conjunction with DynamicUser sporadically fails. There is a better way to provision secrets for services with upcoming systemd 247, but for now we use a SupplementaryGroup to install the secret.
If
passwordFileis set, I have failures at first boot with the following error message:invalid user 'attestation-server'. I can fix this until next boot usingsystemctl restart attestation-server. I haven't dug into this yet, but perhaps the race condition is still present?CC @hmenke
The text was updated successfully, but these errors were encountered: