Hacker News Reader

Comment by throw_a_grenade | Hacker News Reader

Unironicaly, I think having systemd-something util that would provide TLS certs for .services upon encountering specific config knob in [Service] section would be much better that having multitude uncoordinated ACME clients that will quickly burn through allowed rate limits. Even just as a courtesy to LE/ISRG's computational resources.

View on HN

It wouldn't specifically have to be a systemd project or anything; you could make a systemd generator[0] so that you could list out certs as units in the Requires= of a unit. That'd be really neat, actually.

[0] https://www.freedesktop.org/software/systemd/man/latest/syst...

I found this: https://github.com/woju/systemd-dehydrated/

It essentially creates per-domain units. However, those are timers, not services, because the underlying tool doesn't have long-running daemon, it's designed to run off cron. So I can't depend on them directly, and I also need to add multitude of dropins that will restart or reload services that use certificates (https://github.com/woju/systemd-dehydrated/blob/master/contr...). Coudn't figure out any way that would automate this better.

Well, every timer needs a service to activate. And at a cursory glance, this project has oneshot services, which is what I would expect for something like this. So your units (e.g. a webserver) would take After= and Wants=/Requires= on the given oneshot services.

This project looks neat! I might give it a try. I had never heard of dehydrated, but I don't particularly love certbot, and would certainly be willing to try.

A systemd-certd would actually kinda slap. One cert store to rule them all for clients, a way to define certs and specify where they're supposed to be placed with automatic reload using the systemd dependency solver, a way to mount certs into services privately, a unified interface for interacting with the cert store.

So ... not only would your system take ages to boot without the internets(tm) because that's how systemd works, it will be extended in the same spirit to not boot at all if letsencrypt is down.

Sounds enterprise.

Also, you people forgot that my proposal is to also fold the http server in, and ideally all the scripting languages and all of npm just in case.

  ExecStart=/usr/bin/python3 -m http.server
  WorkingDirectory=/srv/www

?

Well I mean if you configured your system in a manner that requires one of the wait-online services that's kinda on you. It's not required for anything by default.

It would be the same for certd. If you configure your system to hold up booting waiting for a cert then that's your choice but there's plenty of ways to have it not.

multiple services depending on different outputs of a single acme client can be expressed, right now, in 2025, within systemd unit definitions, without deeply integrating a systemd-certd-or-whatever-as-such.

which is basically ideal, no? for all the buy-in that the systemd stapling-svchost.exe-onto-cgroups approach asks of us, at the very least we have sufficiently expressive system to do that sort of thing. where something on the machine has a notion of what wants what from what, and you can issue a command to see whether that dependency is satisfied. like. we are there. good. nice. hopefully ops guys are content to let sleeping dogs lie, right?

...right?

Reply on news.ycombinator.com