!MthpOIxqJhTgrMNxDS:nixos.org

NixOS ACME / LetsEncrypt

85 Members
Another day, another cert renewal38 Servers

Load older messages


SenderMessageTime
4 Sep 2023
@raitobezarius:matrix.orgraitobezariusYeah I think the issue is that systemd development is faster with someone who is close to systemd, I had the same issues and decided to bite the bullet to avoid things lingering for too long13:06:50
@raitobezarius:matrix.orgraitobezariusIt's hard to do better than what you have done and I am happy you went through all the thousands cuts13:07:09
@raitobezarius:matrix.orgraitobezariusI'd be happy taking your concurrency subject to Poettering and co to get it merged13:07:39
@os:matrix.flyingcircus.ioosnyx (he/him)
In reply to @raitobezarius:matrix.org
It's hard to do better than what you have done and I am happy you went through all the thousands cuts
Good to hear, because I know a person who wasn't that intrigued that I eagerly jumped through all those hoops ^^
13:08:06
@raitobezarius:matrix.orgraitobezariusThe problem is having someone responsive for the C bits but I can try to pick up the pieces and see what is left to do13:08:07
@raitobezarius:matrix.orgraitobezarius
In reply to @os:matrix.flyingcircus.io
Good to hear, because I know a person who wasn't that intrigued that I eagerly jumped through all those hoops ^^
It's usually very hard to please folks in open source development
13:08:31
@raitobezarius:matrix.orgraitobezarius
In reply to @os:matrix.flyingcircus.io
We're running stable releases. I am not sure whether we'd want all of our machines to run with a canary-systemd (🥶) but we might be able to do this for one of the few especially domain-rich machines – if there is a perspective of this helping things going upstream soonish.
If I have something on this end, I will be sure to ping you as a guinea pig :p
13:09:00
@os:matrix.flyingcircus.ioosnyx (he/him)
In reply to @raitobezarius:matrix.org
The problem is having someone responsive for the C bits but I can try to pick up the pieces and see what is left to do
Depending on whether the PR will progress again, you could take https://github.com/systemd/systemd/pull/27985#issuecomment-1621702189 as a starting point
13:09:51
@os:matrix.flyingcircus.ioosnyx (he/him)
In reply to @m1cr0man:m1cr0man.com
The closest we get to a systemd based solution is my PR. My real question here Oliver is, is there something in your PR that my one does not provide at a functional level? Personally, adding complexity to the renew script itself is something I actively try to avoid. I also add tests for any new features to avoid future regressions if someone attempts to optimise the module.

As for a custom hook - if that's acceptable for your case you actually can do that already 😁 just create a service which is requiredby + before the renew service to handle the lock
As I wrote in my comparison, the flock approach provides the concurrency guarantees in a broader scenario of cases.
As most of you are worried of added complexity, in the end it's just a decision on which approach you as the maintainers (not just m1cr0man because of course you as the implementor understand what's happening there ;) )you feel more comfortable with and which you understand better.
13:21:37
@os:matrix.flyingcircus.ioosnyx (he/him)When it comes to (not) modifying the service script, let me argue that my change barely counts as such a modification from the semantical level. It's just an optional wrapper around the otherwise unmodified service script.13:23:55
@os:matrix.flyingcircus.ioosnyx (he/him) My take on the "let's solve it with systemd unit options alone" approach is just the idea that we must be careful to not fall into the when all you want to use is a systemd-253 hammer, everything looks like a unit option hammer.
It might be a hammer you know, but that hammer bight also just be adding things to the evergrowing list of interwoven systemd unit relationships…
13:28:14
@os:matrix.flyingcircus.ioosnyx (he/him)But that's just one perspective on it, I'm not interested in NIH but just explaining and – if they turn out to be solid possibly defend – my implementation decisions (=13:29:43
@os:matrix.flyingcircus.ioosnyx (he/him)
In reply to @raitobezarius:matrix.org
I'd be happy taking your concurrency subject to Poettering and co to get it merged
So can I read this as a clear "we'll postpone the fix until systemd is ready" from your side and you won't even merge the m1cr0man PR? Then I need to prepare myself for maintaining a downstream acme fork.
If yes, can I rely on you to push this forward?
13:33:52
@os:matrix.flyingcircus.ioosnyx (he/him)
In reply to @raitobezarius:matrix.org
I'd be happy taking your concurrency subject to Poettering and co to get it merged
* So can I read this as a clear "we'll postpone the fix until systemd is ready" from your side and you won't even merge the m1cr0man PR? Then I need to prepare myself for maintaining a downstream acme fork.
If yes, can I interpret this as you taking on to push this forward?
13:41:35
@m1cr0man:m1cr0man.comm1cr0manI think your arguments are solid. I'm not on board for waiting for systemd to add features (and your hammer saying is the same reason why). Like I said if you're willing to just be around to take questions or PR fixes into that portion of the module, I'm happy to see your one merged. I do think it is more complicated but I can live with that if I'm not the only one that understands how it works. I would like you to copy over the test case I made though, to prevent future regressions 13:54:12
@raitobezarius:matrix.orgraitobezarius
In reply to @os:matrix.flyingcircus.io
So can I read this as a clear "we'll postpone the fix until systemd is ready" from your side and you won't even merge the m1cr0man PR? Then I need to prepare myself for maintaining a downstream acme fork.
If yes, can I interpret this as you taking on to push this forward?
I am not a blocker as said earlier
13:54:31
@raitobezarius:matrix.orgraitobezarius I will let m1cr0man do the call for the ACME module 13:54:42
@raitobezarius:matrix.orgraitobezariusIt's their turf13:54:45
@m1cr0man:m1cr0man.comm1cr0man
In reply to @raitobezarius:matrix.org
I am not a blocker as said earlier
I understand but your arguments are also valid.
13:54:56
@raitobezarius:matrix.orgraitobezariusOf course13:55:02
@raitobezarius:matrix.orgraitobezariusBut13:55:04
@os:matrix.flyingcircus.ioosnyx (he/him)Good, because I read conflicting signals 😅13:55:06
@raitobezarius:matrix.orgraitobezariusI'd rather focus on bringing the feature to systemd13:55:08
@raitobezarius:matrix.orgraitobezariusAnd let you folks figure out what you prefer to do here in Nixpkgs as long as you find an agreement :)13:55:19
@m1cr0man:m1cr0man.comm1cr0manYeah I agree but no one in this room (afaik) has the skills or time to do so13:55:37
@os:matrix.flyingcircus.ioosnyx (he/him)
In reply to @raitobezarius:matrix.org
I'd rather focus on bringing the feature to systemd
As I said earlier, once this is ready I'll happily help with porting things over.
13:55:38
@raitobezarius:matrix.orgraitobezarius
In reply to @m1cr0man:m1cr0man.com
Yeah I agree but no one in this room (afaik) has the skills or time to do so
I do have the time and skills to bring it to systemd ;)
13:56:10
@raitobezarius:matrix.orgraitobezariusI mean, time, well, I can always find some in another dimension :)13:56:18
@raitobezarius:matrix.orgraitobezarius * I mean, time, well, I can always find some in another dimension :)13:56:21
@os:matrix.flyingcircus.ioosnyx (he/him)For my PR, I'll happily ad the missing tests, I just didn't want to put any more time into something struggling to get any traction.13:56:35

Show newer messages


Back to Room ListRoom Version: 6