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

security.acme #34422

Closed
qknight opened this issue Jan 30, 2018 · 4 comments
Closed

security.acme #34422

qknight opened this issue Jan 30, 2018 · 4 comments
Assignees

Comments

@qknight
Copy link
Member

qknight commented Jan 30, 2018

Issue description

we are creating security.acme records from two modules:

  • nixcloud.email
  • nixcloud-webservices

my original idea was that they could share the certificates but the security.acme won't merge my configurations and bails out with:

config from module a

    "example.com" = {
      webroot = "/var/lib/acme/acme-challenge";
      domain = "example.com";
      extraDomains = { "lastlog.de" = null; };
    };
  };

config from module b

    "example.com" = {
      webroot = "/var/lib/acme/acme-challenge";
      domain = "example.com";
    };
  };

the error message

nix-repl> :p config.security.acme.certs."example.com"
{ _module = { args = { name = "example.com"; }; check = true; }; allowKeysForGroup = false; domain = «error: The unique option `security.acme.certs.example.com.domain' is defined multiple times, in `/etc/nixos/configuration.nix' and `/h}

question & current solution

i wonder if certificate sharing can even work with the way security.acme is designed at the moment.

so for now, until someone can teach me otherwise, i will just issue a new certificate per abstraction which means:

  • more certificates to handle
  • faster exceeding or using up the certificate pool (let's encrypt issues 4/week for a single domain IIRC)
@zimbatm
Copy link
Member

zimbatm commented Jan 30, 2018

agreed this is weird, I would expect the submodule to recursively merge.

@zimbatm
Copy link
Member

zimbatm commented Jan 30, 2018

the answer is probably somewhere in here:

nixpkgs/lib/types.nix

Lines 263 to 269 in 71631a9

merge = loc: defs:
mapAttrs (n: v: v.value) (filterAttrs (n: v: v ? value) (zipAttrsWith (name: defs:
(mergeDefinitions (loc ++ [name]) elemType defs).optionalValue
)
# Push down position info.
(map (def: listToAttrs (mapAttrsToList (n: def':
{ name = n; value = { inherit (def) file; value = def'; }; }) def.value)) defs)));

the submodule system is quite hard to read

@qknight
Copy link
Member Author

qknight commented Jan 31, 2018

@zimbatm thanks for your insight. (just wanted to point this out and see if i was right or missed something).

@qknight qknight closed this as completed Jan 31, 2018
@qknight
Copy link
Member Author

qknight commented Apr 14, 2018

@zimbatm i've figured out what is going on in the mergin issue:

with this code i was able to merge the 'domain' properly.

  myDomain = mkOptionType {
    name = "myDomain";
    merge = mergeEqualOption;
  };
...
  certOpts = { name, ... } @ toplevel: {
    options = {
      domain = mkOption {
        type = myDomain;
        description = "Domain to fetch certificate for (defaults to the entry name)";
      };

**note: **

  • mergeEqualOption can be found in <nixpkgs>/lib/options.nix and is used by types.bool
  • other attributes, as email for instance, also need this 'special' type to merge correctly

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants