 | NixOS ACME / LetsEncrypt | 103 Members |
| Another day, another cert renewal | 42 Servers |
| NixOS ACME / LetsEncrypt | 103 Members |
| Another day, another cert renewal | 42 Servers |
| Sender | Message | Time |
|---|---|---|
| 16 Nov 2024 | ||
 m1cr0man | In reply to @stephank:stephank.nl Cool ok. This is one of those things that I don't think we will ever support in the in-tree ACME module, at least not whilst we use Lego. The main thing going around in my head is that I don't want either project to give the impression that the other is broken in some way, but if there are additional use cases and features in nixos-certmagic that security.acme does not currently offer, then users who stumble upon both options can understand when to chose one implementation over the other. I find it hard to justify ever changing from lego right now. Most people treat ACME as set-and-forget, literally. If we break people's configs, we need to have a really good reason to do so, and right now I don't think that removing a few lines of bash or improving activation time for more-than-average cert configs is worth it. That's why I'm apprehensive about all this talk of using daemons. Out of tree - sure, I can see the appeal as both an upgrade for those who can handle the reconfiguration of their system, and to cover extra use cases. | 20:32:21 |
| m1cr0man | ThinkChaos: thanks for the second round of reviews on my PR. I am contesting both of the latest comments though 😅 I was wondering if you wanted to have further discussion? | 20:34:26 |
 ThinkChaos | The path thing is just a nit, fine by me to leave as is (I'll say that in the review too) | 20:35:56 |
| ThinkChaos |
That's not how I view it, for instance secrets go in /run too. To me it's for anything ephemeral. AFAIU tmpfiles is generally used for stuff that's required as long as the system is active. Which fits well here. | 20:39:23 |
| ThinkChaos | And small side effect is we don't use the lockdir var in the service so it makes dependency more hidden | 20:40:15 |
| ThinkChaos | * And small side effect is we don't use the lockdir var in the service so it makes the dependency more hidden | 20:40:23 |
| m1cr0man | The acme-setup.service is a requirement of all the renewal services (and is oneshot+RemainAfterExit), but systemd-tmpfiles is not. We actually had a test failure on hydra a couple of days ago because tmpfiles had not ran when lockdir was accessed. Let me see if I can find you the logs. | 20:41:10 |
| m1cr0man |
I agree with this, however /run/acme is directly related to service activation + logic implemented in systemd services. Having its lifecycle managed as a RuntimeDirectory definitely makes things easier. I will definitely add a comment to say where it's created, that's a good call that the relation is not obvious | 20:42:16 |
| m1cr0man | In reply to @k900:0upti.meThis was the lockfiles error we saw last week. | 20:47:35 |
| ThinkChaos | Ok then RuntimeDir is ok with meI thought tmpfiles was something the activation scripts ensured ran earlier based on how it's generally used, but never confirmed that assumption. That also means lots of modules are broken 😕 | 20:47:47 |
| ThinkChaos | I'll reply and approve 🙂 | 20:47:58 |
| m1cr0man | So did I TBH, but then we had that race/permissions error, and the directory hadn't been created when acme-lockfiles ran. Maybe we could add more systemd service dependencies, but RuntimeDirectory was more appropriate IMO | 20:49:19 |
| m1cr0man | In reply to @thinkchaos:matrix.orgThank you :D | 20:51:15 |
| ThinkChaos | I still am not a fan of the RuntimeDir + RemainAfterExit to persist the dir, and the dir being used outside the service itself, but it's better than something that's broken 😄How would you feel if I just do a mkdir -p in the lock script in my PR? | 20:55:04 |
| ThinkChaos | * I still am not a fan of the RuntimeDir + RemainAfterExit to persist the dir, and the dir being used outside the service itself, but it's better than something that's broken 😄How would you feel if I just do a mkdir -p in the lock script in my (future) PR? | 20:55:17 |
| ThinkChaos | * I still am not a fan of the RuntimeDir + RemainAfterExit to persist the dir, and the dir being used outside the service itself, but it's better than something that's broken 😄~~How would you feel if I just do a mkdir -p in the lock script in my (future) PR?~~ needs root | 20:59:33 |
| ThinkChaos | * I still am not a fan of the RuntimeDir + RemainAfterExit to persist the dir, and the dir being used outside the service itself, but it's better than something that's broken 😄~How would you feel if I just do a mkdir -p in the lock script in my (future) PR?~ needs root | 20:59:39 |
| ThinkChaos | * I still am not a fan of the RuntimeDir + RemainAfterExit to persist the dir, and the dir being used outside the service itself, but it's better than something that's broken 😄mkdir -p in the lock script in my (future) PR? | 20:59:48 |
| 17 Nov 2024 | ||
| m1cr0man | Given how systemd dependent we are already, I generally prefer the systemd solution if one is available. It is very well tested and has outstandingly stable behaviour. Less bash scripting means less custom code for us to maintain | 13:15:23 |
| m1cr0man | Just got done testing an --overwrite-domains option for lego that lets us remove domainHash entirely. The delta on the module is kinda underwhelming but less code is less code | 22:50:19 |
| m1cr0man | In reply to @thinkchaos:matrix.orgSince you're blocked on merge would you mind if I reviewed on that commit itself? I don't want to keep you delayed on waiting for a review on the setup script | 22:56:06 |
| ThinkChaos | 1s let me give you a better link | 22:57:22 |
| m1cr0man | sure ok | 22:59:38 |
| ThinkChaos | https://github.com/ThinkChaos/nixpkgs/pull/1 | 22:59:52 |
| 18 Nov 2024 | ||
| m1cr0man | Right, this is going to be interesting. https://github.com/go-acme/lego/pull/2355 I'm curious to see how this is received by the lego team. | 23:36:29 |
| m1cr0man | Here's the would-be change to switch to it on the module: https://github.com/m1cr0man/nixpkgs/commit/0e84622dff2ab5c8ba37cf49a3dd212b253664ee What's nice is that this wont trigger a mass renewal on all nixos systems. domains thankfully won't part of the directory tree hashes that we have (e.g. account hash) | 23:38:32 |
| m1cr0man | * Here's the would-be change to switch to it on the module: https://github.com/m1cr0man/nixpkgs/commit/0e84622dff2ab5c8ba37cf49a3dd212b253664ee What's nice is that this wont trigger a mass renewal on all nixos systems. Domains options are thankfully aren't part of the directory tree hashes that we have (e.g. account hash) | 23:39:03 |
| m1cr0man | * Here's the would-be change to switch to it on the module: https://github.com/m1cr0man/nixpkgs/commit/0e84622dff2ab5c8ba37cf49a3dd212b253664ee What's nice is that this wont trigger a mass renewal on all nixos systems. Domains options are thankfully not part of the directory tree hashes that we have (e.g. account hash) | 23:39:09 |
| m1cr0man | yeah my typing has gone, I have to sleep ;) | 23:39:21 |
| ThinkChaos | Seems pretty straightforward, I'd just name it more explicitly, maybe --replace-cert-domainsGoon night 😉 | 23:40:41 |