| 26 Dec 2021 |
 m1cr0man | @Winter On top of what Arian said, there's two other reasons for acme-fixperms service and other various chgrp/chmods. The first is to fix permission changes that happened back in 19.09 (I think) where we went from root-owned to acme-owned certs. The second is for supporting changes of the group of an active cert. Additionally, in the new PR, it'll also support toggling useRoot. | 16:20:48 |
| m1cr0man | hexa: thanks I'll do that rebase now | 16:20:59 |
 Winter (she/her) | Got it. | 16:21:48 |
| m1cr0man | If you have any other questions feel free to ask. I'm trying to ensure that the test suite has 100% coverage of all use cases and features at all times. If you are ever wondering something technical it might help to give those a read and see what we're testing for. | 16:23:25 |
| Winter (she/her) | Can I ask questions that relate to the Nginx’s module’s ACME integration? I assume that’s in scope of this channel, but let me know if it’s not. | 16:27:30 |
| m1cr0man | yeah absolutely | 16:30:05 |
| m1cr0man | it's in scope, we maintain it :) | 16:30:15 |
| Winter (she/her) | https://github.com/NixOS/nixpkgs/blob/b0f154fd440bdf43a483b8ca46020d7d6cec5fbf/nixos/modules/services/web-servers/nginx/default.nix#L952
Why is mkDefault used here, in what scenario would this value need to be changed from the Nginx group? | 17:03:56 |
| m1cr0man | good question! It's very simple. we want security.acme.defaults.group or security.acme.certs.<cert>.group to take precedence | 17:08:11 |
| m1cr0man | actually, defaults.group won't override it I don't think, but the <cert>.group definitely will | 17:09:16 |
| m1cr0man | It gets even wilder in the next PR ;) https://github.com/NixOS/nixpkgs/pull/147784/files#diff-9b5561c4bb76ed61cd945467b6ccacb8343bb8ed8d2ad8a1e43505db34352722R943-R949 | 17:10:21 |
| Winter (she/her) | oh no. | 17:10:47 |
| Winter (she/her) | lol | 17:10:49 |
| Winter (she/her) | where is security.acme.defaults even defined? can’t find that anywhere >.< | 17:11:10 |
| m1cr0man | it's in that PR | 17:11:14 |
| m1cr0man | it's not in master yet | 17:11:19 |
| Winter (she/her) | ahh | 17:11:30 |
| m1cr0man | it's also fully doc'd in that PR, in case you were looking for docs too lol | 17:11:38 |
| m1cr0man | I specifically document how to make use of the nginx vhost stuff for DNS-01 validation, which includes making use of that webroot logic | 17:12:27 |
| m1cr0man | Wrote a test for caddy to cover https://github.com/NixOS/nixpkgs/pull/147973 . Once it passes I'll push + we'll be good for merge | 17:24:13 |
| Winter (she/her) | Is there any reason the acme user doesn’t have a preset UID/GID like other modules’ users do? | 20:01:48 |
 hexa | because it doesn't really matter? It is always referenced by name. | 20:11:20 |
| Winter (she/her) | that’s fair | 20:20:50 |
| m1cr0man | It did up until recently, but then some other maintainer removed its fixed UID. I was not against it - for the reason hexa says but also you're not transporting certs between systems anyway and the UID will never change when randomly picked. | 20:34:44 |
| m1cr0man | * It did up until recently, but then some other maintainer removed its fixed UID. I was not against it - for the reason hexa says but also you're not transporting certs between systems anyway and the UID will never change once randomly picked. | 20:34:50 |
| m1cr0man | so it turns out my tests found a bug in caddy ;D | 20:35:11 |
| Winter (she/her) | In reply to @m1cr0man:m1cr0man.com
It did up until recently, but then some other maintainer removed its fixed UID. I was not against it - for the reason hexa says but also you're not transporting certs between systems anyway and the UID will never change once randomly picked.
the UID will never change once randomly picked.
unless you’re wiping your rootdir on every boot (hi), which regenerates /etc/passwd, so then you’re at the mercy of JSON ordering
| 21:07:07 |
| Winter (she/her) | * In reply to @m1cr0man:m1cr0man.com
It did up until recently, but then some other maintainer removed its fixed UID. I was not against it - for the reason hexa says but also you're not transporting certs between systems anyway and the UID will never change once randomly picked.
the UID will never change once randomly picked.
unless you’re wiping your rootdir on every boot (hi), which regenerates /etc/passwd, so then you’re at the mercy of JSON ordering
| 21:07:14 |
| Winter (she/her) | * In reply to @m1cr0man:m1cr0man.com
It did up until recently, but then some other maintainer removed its fixed UID. I was not against it - for the reason hexa says but also you're not transporting certs between systems anyway and the UID will never change once randomly picked.
the UID will never change once randomly picked.
unless you’re wiping your rootdir on every boot (hi), which regenerates /etc/passwd, so then you’re at the mercy of JSON ordering | 21:07:23 |
| m1cr0man | you can always set your own UID :) | 21:07:36 |
