#ovh — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #ovh, aggregated by home.social.
-
#selfhosting a #mailserver on #OVH turns out to be a nightmare.
Esoteric blocklists won’t release my IP, only after paying ransom, it appears. -
#selfhosting a #mailserver on #OVH turns out to be a nightmare.
Esoteric blocklists won’t release my IP, only after paying ransom, it appears. -
#selfhosting a #mailserver on #OVH turns out to be a nightmare.
Esoteric blocklists won’t release my IP, only after paying ransom, it appears. -
#selfhosting a #mailserver on #OVH turns out to be a nightmare.
Esoteric blocklists won’t release my IP, only after paying ransom, it appears. -
#selfhosting a #mailserver on #OVH turns out to be a nightmare.
Esoteric blocklists won’t release my IP, only after paying ransom, it appears. -
OVHcloud discontinues all-inclusive plans for public cloud instances starting 1 October. They will bill local storage and IPv4 addresses separately.
https://blog.ovhcloud.com/en/posts/public-cloud-pricing-model-update-2026/
- - -
OVHcloud discontinue les forfaits tout inclus pour les instances en infonuagique publique à compter du 1er octobre. Il factureront les adresses IPv4 et le stockage local séparément.https://blog.ovhcloud.com/fr/posts/public-cloud-pricing-model-update-2026/
-
OVHcloud discontinues all-inclusive plans for public cloud instances starting 1 October. They will bill local storage and IPv4 addresses separately.
https://blog.ovhcloud.com/en/posts/public-cloud-pricing-model-update-2026/
- - -
OVHcloud discontinue les forfaits tout inclus pour les instances en infonuagique publique à compter du 1er octobre. Il factureront les adresses IPv4 et le stockage local séparément.https://blog.ovhcloud.com/fr/posts/public-cloud-pricing-model-update-2026/
-
OVHcloud discontinues all-inclusive plans for public cloud instances starting 1 October. They will bill local storage and IPv4 addresses separately.
https://blog.ovhcloud.com/en/posts/public-cloud-pricing-model-update-2026/
- - -
OVHcloud discontinue les forfaits tout inclus pour les instances en infonuagique publique à compter du 1er octobre. Il factureront les adresses IPv4 et le stockage local séparément.https://blog.ovhcloud.com/fr/posts/public-cloud-pricing-model-update-2026/
-
OVHcloud discontinues all-inclusive plans for public cloud instances starting 1 October. They will bill local storage and IPv4 addresses separately.
https://blog.ovhcloud.com/en/posts/public-cloud-pricing-model-update-2026/
- - -
OVHcloud discontinue les forfaits tout inclus pour les instances en infonuagique publique à compter du 1er octobre. Il factureront les adresses IPv4 et le stockage local séparément.https://blog.ovhcloud.com/fr/posts/public-cloud-pricing-model-update-2026/
-
OVHcloud discontinues all-inclusive plans for public cloud instances starting 1 October. They will bill local storage and IPv4 addresses separately.
https://blog.ovhcloud.com/en/posts/public-cloud-pricing-model-update-2026/
- - -
OVHcloud discontinue les forfaits tout inclus pour les instances en infonuagique publique à compter du 1er octobre. Il factureront les adresses IPv4 et le stockage local séparément.https://blog.ovhcloud.com/fr/posts/public-cloud-pricing-model-update-2026/
-
Das Auswärtige Amt vergibt seinen Cloud-Auftrag ohne Ausschreibung direkt an OVH – Begründung: EU-Hauptsitz, eigene Rechenzentren weltweit. Jetzt will der Franzose massiv ins deutsche Behördengeschäft, gegen Schwarz Digits, Ionos und Telekom. Alle werben mit „Souveränität", nur anders akzentuiert. Laut Fokuhl/Kerkmann, Handelsblatt.
#DigitaleSouveränität #Cloud #OVH https://www.handelsblatt.com/technik/it-internet/technologie-wie-frankreichs-cloudanbieter-ovh-um-deutsche-behoerden-wirbt/100245886.html -
Das Auswärtige Amt vergibt seinen Cloud-Auftrag ohne Ausschreibung direkt an OVH – Begründung: EU-Hauptsitz, eigene Rechenzentren weltweit. Jetzt will der Franzose massiv ins deutsche Behördengeschäft, gegen Schwarz Digits, Ionos und Telekom. Alle werben mit „Souveränität", nur anders akzentuiert. Laut Fokuhl/Kerkmann, Handelsblatt.
#DigitaleSouveränität #Cloud #OVH https://www.handelsblatt.com/technik/it-internet/technologie-wie-frankreichs-cloudanbieter-ovh-um-deutsche-behoerden-wirbt/100245886.html -
Das Auswärtige Amt vergibt seinen Cloud-Auftrag ohne Ausschreibung direkt an OVH – Begründung: EU-Hauptsitz, eigene Rechenzentren weltweit. Jetzt will der Franzose massiv ins deutsche Behördengeschäft, gegen Schwarz Digits, Ionos und Telekom. Alle werben mit „Souveränität", nur anders akzentuiert. Laut Fokuhl/Kerkmann, Handelsblatt.
#DigitaleSouveränität #Cloud #OVH https://www.handelsblatt.com/technik/it-internet/technologie-wie-frankreichs-cloudanbieter-ovh-um-deutsche-behoerden-wirbt/100245886.html -
Das Auswärtige Amt vergibt seinen Cloud-Auftrag ohne Ausschreibung direkt an OVH – Begründung: EU-Hauptsitz, eigene Rechenzentren weltweit. Jetzt will der Franzose massiv ins deutsche Behördengeschäft, gegen Schwarz Digits, Ionos und Telekom. Alle werben mit „Souveränität", nur anders akzentuiert. Laut Fokuhl/Kerkmann, Handelsblatt.
#DigitaleSouveränität #Cloud #OVH https://www.handelsblatt.com/technik/it-internet/technologie-wie-frankreichs-cloudanbieter-ovh-um-deutsche-behoerden-wirbt/100245886.html -
Das Auswärtige Amt vergibt seinen Cloud-Auftrag ohne Ausschreibung direkt an OVH – Begründung: EU-Hauptsitz, eigene Rechenzentren weltweit. Jetzt will der Franzose massiv ins deutsche Behördengeschäft, gegen Schwarz Digits, Ionos und Telekom. Alle werben mit „Souveränität", nur anders akzentuiert. Laut Fokuhl/Kerkmann, Handelsblatt.
#DigitaleSouveränität #Cloud #OVH https://www.handelsblatt.com/technik/it-internet/technologie-wie-frankreichs-cloudanbieter-ovh-um-deutsche-behoerden-wirbt/100245886.html -
Hey #OVH, you know the signup form, where the "I accept to receive ads and other shit" is not mandatory but you can't validate the form if the checkbox remains empty?
Yes, this you-deserve-eternal-sleep-deprivation #DarkPattern you have on your website!
Well, I did not sign up, you won't receive a dime from me and I dearly hope the manager that forced the dev to code this will suffer.
Xoxo
-
Hey #OVH, you know the signup form, where the "I accept to receive ads and other shit" is not mandatory but you can't validate the form if the checkbox remains empty?
Yes, this you-deserve-eternal-sleep-deprivation #DarkPattern you have on your website!
Well, I did not sign up, you won't receive a dime from me and I dearly hope the manager that forced the dev to code this will suffer.
Xoxo
-
Hey #OVH, you know the signup form, where the "I accept to receive ads and other shit" is not mandatory but you can't validate the form if the checkbox remains empty?
Yes, this you-deserve-eternal-sleep-deprivation #DarkPattern you have on your website!
Well, I did not sign up, you won't receive a dime from me and I dearly hope the manager that forced the dev to code this will suffer.
Xoxo
-
Hey #OVH, you know the signup form, where the "I accept to receive ads and other shit" is not mandatory but you can't validate the form if the checkbox remains empty?
Yes, this you-deserve-eternal-sleep-deprivation #DarkPattern you have on your website!
Well, I did not sign up, you won't receive a dime from me and I dearly hope the manager that forced the dev to code this will suffer.
Xoxo
-
OVHcloud announces price increases for their 2024 and 2026 generation dedicated servers, whether already deployed or new orders
https://blog.ovhcloud.com/en/posts/dedicated-servers-pricing-update-h2-2026/
- - -
OVHcloud annonce des augmentations de prix pour leurs serveurs des générations 2024 et 2026, qu’ils soient déjà déployés ou des nouvelles commandes// Article en anglais //
-
OVHcloud announces price increases for their 2024 and 2026 generation dedicated servers, whether already deployed or new orders
https://blog.ovhcloud.com/en/posts/dedicated-servers-pricing-update-h2-2026/
- - -
OVHcloud annonce des augmentations de prix pour leurs serveurs des générations 2024 et 2026, qu’ils soient déjà déployés ou des nouvelles commandes// Article en anglais //
-
OVHcloud announces price increases for their 2024 and 2026 generation dedicated servers, whether already deployed or new orders
https://blog.ovhcloud.com/en/posts/dedicated-servers-pricing-update-h2-2026/
- - -
OVHcloud annonce des augmentations de prix pour leurs serveurs des générations 2024 et 2026, qu’ils soient déjà déployés ou des nouvelles commandes// Article en anglais //
-
OVHcloud announces price increases for their 2024 and 2026 generation dedicated servers, whether already deployed or new orders
https://blog.ovhcloud.com/en/posts/dedicated-servers-pricing-update-h2-2026/
- - -
OVHcloud annonce des augmentations de prix pour leurs serveurs des générations 2024 et 2026, qu’ils soient déjà déployés ou des nouvelles commandes// Article en anglais //
-
OVHcloud announces price increases for their 2024 and 2026 generation dedicated servers, whether already deployed or new orders
https://blog.ovhcloud.com/en/posts/dedicated-servers-pricing-update-h2-2026/
- - -
OVHcloud annonce des augmentations de prix pour leurs serveurs des générations 2024 et 2026, qu’ils soient déjà déployés ou des nouvelles commandes// Article en anglais //
-
The problem now is that to get the automatic DNS population, there are only three compatible non-US providers - #ovh #deSEC and #bunnydns.
I'm ruling out bunnydns - they issue one API key which covers *everything*. deSEC is interesting, but I don't want to rely on a free service that could be yanked at any time. That leaves OVH... I'll have a play with them when I get a chance.
The other option is to run my own master and then use @beasts as secondary. I suspect this is where I'll go. -
The problem now is that to get the automatic DNS population, there are only three compatible non-US providers - #ovh #deSEC and #bunnydns.
I'm ruling out bunnydns - they issue one API key which covers *everything*. deSEC is interesting, but I don't want to rely on a free service that could be yanked at any time. That leaves OVH... I'll have a play with them when I get a chance.
The other option is to run my own master and then use @beasts as secondary. I suspect this is where I'll go. -
The problem now is that to get the automatic DNS population, there are only three compatible non-US providers - #ovh #deSEC and #bunnydns.
I'm ruling out bunnydns - they issue one API key which covers *everything*. deSEC is interesting, but I don't want to rely on a free service that could be yanked at any time. That leaves OVH... I'll have a play with them when I get a chance.
The other option is to run my own master and then use @beasts as secondary. I suspect this is where I'll go. -
The problem now is that to get the automatic DNS population, there are only three compatible non-US providers - #ovh #deSEC and #bunnydns.
I'm ruling out bunnydns - they issue one API key which covers *everything*. deSEC is interesting, but I don't want to rely on a free service that could be yanked at any time. That leaves OVH... I'll have a play with them when I get a chance.
The other option is to run my own master and then use @beasts as secondary. I suspect this is where I'll go. -
The problem now is that to get the automatic DNS population, there are only three compatible non-US providers - #ovh #deSEC and #bunnydns.
I'm ruling out bunnydns - they issue one API key which covers *everything*. deSEC is interesting, but I don't want to rely on a free service that could be yanked at any time. That leaves OVH... I'll have a play with them when I get a chance.
The other option is to run my own master and then use @beasts as secondary. I suspect this is where I'll go. -
Hetzner increased prices and made people unhappy and some even mad at them. We're living interesting times. As expected they will not stay alone.
Here we go, now it's OVH
https://www.theregister.com/off-prem/2026/08/11/ovh-cloud-warns-of-87-price-hikes-to-help-it-cover-rampocalypse-costs/5285867 -
Hetzner increased prices and made people unhappy and some even mad at them. We're living interesting times. As expected they will not stay alone.
Here we go, now it's OVH
https://www.theregister.com/off-prem/2026/08/11/ovh-cloud-warns-of-87-price-hikes-to-help-it-cover-rampocalypse-costs/5285867 -
Der Webhoster #OVH kündigt drastische Preiserhöhungen von bis zu 87 Prozent an. Grund sind die extrem gestiegenen Hardware-Preise im Zuge des weltweiten Booms um #KünstlicheIntelligenz. #Server #Hosting #Cloud https://winfuture.de/news,160538.html?utm_source=Mastodon&utm_medium=ManualStatus&utm_campaign=SocialMedia
-
Der Webhoster #OVH kündigt drastische Preiserhöhungen von bis zu 87 Prozent an. Grund sind die extrem gestiegenen Hardware-Preise im Zuge des weltweiten Booms um #KünstlicheIntelligenz. #Server #Hosting #Cloud https://winfuture.de/news,160538.html?utm_source=Mastodon&utm_medium=ManualStatus&utm_campaign=SocialMedia
-
Der Webhoster #OVH kündigt drastische Preiserhöhungen von bis zu 87 Prozent an. Grund sind die extrem gestiegenen Hardware-Preise im Zuge des weltweiten Booms um #KünstlicheIntelligenz. #Server #Hosting #Cloud https://winfuture.de/news,160538.html?utm_source=Mastodon&utm_medium=ManualStatus&utm_campaign=SocialMedia
-
Der Webhoster #OVH kündigt drastische Preiserhöhungen von bis zu 87 Prozent an. Grund sind die extrem gestiegenen Hardware-Preise im Zuge des weltweiten Booms um #KünstlicheIntelligenz. #Server #Hosting #Cloud https://winfuture.de/news,160538.html?utm_source=Mastodon&utm_medium=ManualStatus&utm_campaign=SocialMedia
-
Der Webhoster #OVH kündigt drastische Preiserhöhungen von bis zu 87 Prozent an. Grund sind die extrem gestiegenen Hardware-Preise im Zuge des weltweiten Booms um #KünstlicheIntelligenz. #Server #Hosting #Cloud https://winfuture.de/news,160538.html?utm_source=Mastodon&utm_medium=ManualStatus&utm_campaign=SocialMedia
-
Full disclosure on the cost of that free upgrade.
The reboot to pick it up hung at the hypervisor level and took the instance with it. Almost 15 hours of downtime, 41.91% uptime for the day, and nothing I could do from inside the box because there was no inside to get to.
Worth it. But this is the part of "simple restart" that the is mentioned in email.
Also a decent argument for the thing I keep saying: the box is disposable, the data is not.
#SelfHosting #VPS #OVH #Downtime #Homelab #Fediverse #Blog #Thoughts
-
Full disclosure on the cost of that free upgrade.
The reboot to pick it up hung at the hypervisor level and took the instance with it. Almost 15 hours of downtime, 41.91% uptime for the day, and nothing I could do from inside the box because there was no inside to get to.
Worth it. But this is the part of "simple restart" that the is mentioned in email.
Also a decent argument for the thing I keep saying: the box is disposable, the data is not.
#SelfHosting #VPS #OVH #Downtime #Homelab #Fediverse #Blog #Thoughts
-
Full disclosure on the cost of that free upgrade.
The reboot to pick it up hung at the hypervisor level and took the instance with it. Almost 15 hours of downtime, 41.91% uptime for the day, and nothing I could do from inside the box because there was no inside to get to.
Worth it. But this is the part of "simple restart" that the is mentioned in email.
Also a decent argument for the thing I keep saying: the box is disposable, the data is not.
#SelfHosting #VPS #OVH #Downtime #Homelab #Fediverse #Blog #Thoughts
-
Full disclosure on the cost of that free upgrade.
The reboot to pick it up hung at the hypervisor level and took the instance with it. Almost 15 hours of downtime, 41.91% uptime for the day, and nothing I could do from inside the box because there was no inside to get to.
Worth it. But this is the part of "simple restart" that the is mentioned in email.
Also a decent argument for the thing I keep saying: the box is disposable, the data is not.
#SelfHosting #VPS #OVH #Downtime #Homelab #Fediverse #Blog #Thoughts
-
Full disclosure on the cost of that free upgrade.
The reboot to pick it up hung at the hypervisor level and took the instance with it. Almost 15 hours of downtime, 41.91% uptime for the day, and nothing I could do from inside the box because there was no inside to get to.
Worth it. But this is the part of "simple restart" that the is mentioned in email.
Also a decent argument for the thing I keep saying: the box is disposable, the data is not.
#SelfHosting #VPS #OVH #Downtime #Homelab #Fediverse #Blog #Thoughts
-
Email from @OVHcloud this morning: the bandwidth on my VPS went from 400 Mbit to 1 Gbit. Same plan, same price, nothing for me to do.
This is the box running dol.social. The one I benchmarked last month, on the grounds that its memory and disk beat the newer 2027 model and the network gap did not matter enough to move.
The network gap is now gone too.
Correction while I am here: I said 500 Mbit in that thread. It was 400. The conclusion holds, my number did not.
#SelfHosting #VPS #OVH #Mastodon #Homelab #Fediverse #Blog #Thoughts
-
Email from @OVHcloud this morning: the bandwidth on my VPS went from 400 Mbit to 1 Gbit. Same plan, same price, nothing for me to do.
This is the box running dol.social. The one I benchmarked last month, on the grounds that its memory and disk beat the newer 2027 model and the network gap did not matter enough to move.
The network gap is now gone too.
Correction while I am here: I said 500 Mbit in that thread. It was 400. The conclusion holds, my number did not.
#SelfHosting #VPS #OVH #Mastodon #Homelab #Fediverse #Blog #Thoughts
-
Email from @OVHcloud this morning: the bandwidth on my VPS went from 400 Mbit to 1 Gbit. Same plan, same price, nothing for me to do.
This is the box running dol.social. The one I benchmarked last month, on the grounds that its memory and disk beat the newer 2027 model and the network gap did not matter enough to move.
The network gap is now gone too.
Correction while I am here: I said 500 Mbit in that thread. It was 400. The conclusion holds, my number did not.
#SelfHosting #VPS #OVH #Mastodon #Homelab #Fediverse #Blog #Thoughts
-
Email from @OVHcloud this morning: the bandwidth on my VPS went from 400 Mbit to 1 Gbit. Same plan, same price, nothing for me to do.
This is the box running dol.social. The one I benchmarked last month, on the grounds that its memory and disk beat the newer 2027 model and the network gap did not matter enough to move.
The network gap is now gone too.
Correction while I am here: I said 500 Mbit in that thread. It was 400. The conclusion holds, my number did not.
#SelfHosting #VPS #OVH #Mastodon #Homelab #Fediverse #Blog #Thoughts
-
Email from @OVHcloud this morning: the bandwidth on my VPS went from 400 Mbit to 1 Gbit. Same plan, same price, nothing for me to do.
This is the box running dol.social. The one I benchmarked last month, on the grounds that its memory and disk beat the newer 2027 model and the network gap did not matter enough to move.
The network gap is now gone too.
Correction while I am here: I said 500 Mbit in that thread. It was 400. The conclusion holds, my number did not.
#SelfHosting #VPS #OVH #Mastodon #Homelab #Fediverse #Blog #Thoughts
-
OVHcloud facing the Canadian b digital sovereignty challenge
// Article in French //
- - -
OVHcloud face au test canadien de la souveraineté numériquehttps://moncarnet.com/2026/07/31/ovhcloud-face-au-test-canadien-de-la-souverainete-numerique/
-
OVHcloud facing the Canadian b digital sovereignty challenge
// Article in French //
- - -
OVHcloud face au test canadien de la souveraineté numériquehttps://moncarnet.com/2026/07/31/ovhcloud-face-au-test-canadien-de-la-souverainete-numerique/
-
OVHcloud facing the Canadian b digital sovereignty challenge
// Article in French //
- - -
OVHcloud face au test canadien de la souveraineté numériquehttps://moncarnet.com/2026/07/31/ovhcloud-face-au-test-canadien-de-la-souverainete-numerique/
-
OVHcloud facing the Canadian b digital sovereignty challenge
// Article in French //
- - -
OVHcloud face au test canadien de la souveraineté numériquehttps://moncarnet.com/2026/07/31/ovhcloud-face-au-test-canadien-de-la-souverainete-numerique/
-
OVHcloud facing the Canadian b digital sovereignty challenge
// Article in French //
- - -
OVHcloud face au test canadien de la souveraineté numériquehttps://moncarnet.com/2026/07/31/ovhcloud-face-au-test-canadien-de-la-souverainete-numerique/
-
Migration von Certbot zu Lego
https://blog.sengotta.net/migration-von-certbot-zu-lego/Ich glaube jeder der selber Dienste hosted kenn das Problem. Da will man nur mal eben eine kleine Änderung auf dem VPS oder auf dem Server im Homelab machen, und dann stolpert man über dieses kleine nervige Problem was man einfach seit Monaten ignoriert hat.
das ist mir heute mal wieder passiert. Eigentlich wollte ich nur eine neue Webapp ausprobieren, aber dafür brauch ich nun einmal ein TLS Zertifikat. Eigentlich kein Problem, aber als ich in mein OVH Dashboard schaue um die Domain anzulegen viel mir auf das der Certbot auf meinem Debian 12 Server immer noch an einen doofen Bug leidet durch den die DNS-01 Acme Challenges nicht mehr richtig gelöscht weren, nachdem die Zertifikate darüber validiert hat: https://github.com/certbot/certbot/issues/10492
Ja ich weiß: das ist an sich nur ein kosmetisches Problem. Aber es ist nicht das einzige Problem was ich mit Certbot in den vergangenen Monaten hatte. Erst im März habe ich gemerkt das das OVH DNS Addon in Trixie einfach nicht mehr vorhanden ist.
Um das Problem zu lösen könnte ich einfach Certbot via Docker installieren, so wie ich es auf meiner Debian Trixie Maschine getan habe. Leider würde das aber zu einem anderen Problem führen. Eine meiner Domains lasse ich inzwischen von einem coolen deutschen DNS Anbieter namens desec.io verwalten. Leider gibt es keinen offizielles Docker Image mit deren DNS-01 Certbot Plugin. Ich müsste also ein eigenes Image erstellen und auch Pflegen. Da hab ich jetzt nicht wirklich bock drauf.
Also was mach ich jetzt. Mit einer nativen Certbot Installation pypi, venv etc. will ich mich echt nicht rumschlagen. Gang ehrlich dieses ganzen Python universum war nie wirklich intuitiv für mich. Im März hatte mir jemand im Fediverse zu Lego einem Acme Client der in Go geschrieben wurde geraten. Das Programm unterstützt ca. 200 DNS-01 Challanges verschiedener DNS Provider und kommt als eine statische Go Binary. Das find ich schon extrem cool, also einfach runterladen, entpacken, ausführbar machen und man kann loslegen. Vielleicht schreib ich mir in Zukunft mal ein kleines Script für solche updates.
Ich wollte unter Lego direkt mit der Config Datei arbeiten, damit die automatisierungen hinterher einfacher von der Hand gehen. Auf den ersten Blick schien das recht aber wenn man sich die Config Datei anschaut dann versteht man recht schnell was man davon braucht und was nicht.
In meinem Fall muss ich zwei DNS Provider mit DNS-01 verifikation anlegen und einen mit einer http-01 webroot challenge. Tja Strato hat immer noch keine DNS API für sowas. Das alles hat den Vorteil das der Acme Client nie an Port 80 etc. ran muss und der Webserver so die ganze Zeit online bleibt.
Das ganze zum laufen zu kriegen war recht eifnach. Lego binary von Github downloaden, entpacken, an einen passenden Ort verschieben (ich nehme /usr/local/sbin) und via chmod +x ausfürhbar machen. Danach habe ich den Ordner /etc/lego erstellt wo dann die ganzen Config Dateien und Zertifikate landen.
Nun kann man sich direkt einen Account (eigentlich einen privaten Schlüssel) anlegen, ich habe als Account Namen einfach meine Mail Adresse genommen:
lego accounts register --email [email protected] -a --path /etc/legoWie es weiter geht hängt ein bisschen davon ab wie man seine Domian gegenüber Lets Encrypt verifiziert. Hier ein Beispiel wie ich das bei meinen Domains mache die bei OVH liegen und bei denen ich DNS-01 nutzen. Ich arbeite mit .env- Files um die Zugangsdaten und Einstellungen der jeweiligen DNS Provider zu speichern. Also erstelle ich folgende Datei /etc/lego/.env.ovh und trage dort die im Lego Wiki für OVH aufgeführten Parameter ein, bei mir sind das Application Key, Application Secret, Consumer Key und der Endpoint: https://go-acme.github.io/lego/dns/ovh/index.html
Nun kann man sein erstes Zertifikat erstellen:
lego run --email [email protected] --path /etc/lego -a --dns ovh -d test.example.ovh --env-file /etc/lego/.env.ovhLego legt diese dann in /etc/lego/certificates ab.
Da ich jedoch nicht ewig lange Befehle in Cronjobs etc packen möchte bietet sich die Arbeit mit der Lego Config Datei an, sie macht die automatisierung des Vorgangs viel leichter. Dort fasst man Accounts, Challanges und die verwalteten Domains zusammen. Diese lego.yaml erstelle ich in /etc/lego. Meine sieht ungefähr so aus:
storage: /etc/lego/ accounts: [email protected]: email: [email protected] acceptsTermsOfService: true challenges: desec: dns: provider: desec envFile: /etc/lego/.env.desec resolvers: - 1.1.1.1:53 ovh: dns: provider: ovh envFile: /etc/lego/.env.ovh resolvers: - 1.1.1.1:53 webroot: http: webroot: /var/www/lego # Muss im webserver konfiguriert sein certificates: test.example.desec: #Kann irgendein Name sein, wird als Dateiname genutzt challenge: desec domains: - test.example.desec test.example.ovh: challenge: ovh domains: - test.example.ovh - www.test.example.ovh test.example.webroot: challenge: webroot domains: - test.example.webrootDas ist nur ein Beispiel wie es für mich funktioniert, schaut auf jeden Fall ins Wiki und denkt dran: das ist yaml also nur Leerzeichen, keine Tabs etc.
Wenn man diese Config Datei hat dann reicht ein einfacher aufruf mit dieser als Parameter aus um die Zertifikate zu beziehen oder zu erneuern.:
lego --config /etc/lego/lego.yamlJetzt müssen wir noch sehen das dieser Befehl regelmäßig ausgefürht wird, das kann man über einer Cronjob machen oder über einen Systemd Timer. Dafür werden folgende Dateien angelegt /etc/systemd/system/lego-renew.timer und /etc/systemd/system/lego-renew.service:
[Unit] Description=Lego Certificate Renewal Timer [Timer] OnCalendar=*-*-* 03:00:00 RandomizedDelaySec=1h Persistent=true [Install] WantedBy=timers.targetund
[Unit] Description=Lego Certificate Renewal [Service] Type=oneshot ExecStart=/usr/local/sbin/lego --config /etc/lego/lego.yaml ExecStartPost=systemctl reload nginxNun können wir den systemd daemon neu laden und den timer starten und aktivieren:
systemctl daemon-reload systemctl enable lego-renew.timer systemctl start lego-renew.timerUnd das war es auch schon. Lego sollte sich nun darum kümmern eure Zertifikate immer auf einem aktuellen Stand zu halten. Jetzt muss man natürlich noch sehen das man seinen nginx etc. auf die neuen Zertifikate konfiguriert. Ja das war bei mir Handarbeit, es gibt nen Grund warum ich mich so lange gedrückt habe.
Ich hoffe der Beitrag hilft irgendwem und ist zumindest halbwegs interessant. Falls nicht, dann weiss ich in sechs Monaten zumindest immer noch was ich hier getan habe.
#certbot #desecio #lego #letsencrypt #linux #ovh #selfhosting @bjoern -
Migration von Certbot zu Lego
https://blog.sengotta.net/migration-von-certbot-zu-lego/Ich glaube jeder der selber Dienste hosted kenn das Problem. Da will man nur mal eben eine kleine Änderung auf dem VPS oder auf dem Server im Homelab machen, und dann stolpert man über dieses kleine nervige Problem was man einfach seit Monaten ignoriert hat.
das ist mir heute mal wieder passiert. Eigentlich wollte ich nur eine neue Webapp ausprobieren, aber dafür brauch ich nun einmal ein TLS Zertifikat. Eigentlich kein Problem, aber als ich in mein OVH Dashboard schaue um die Domain anzulegen viel mir auf das der Certbot auf meinem Debian 12 Server immer noch an einen doofen Bug leidet durch den die DNS-01 Acme Challenges nicht mehr richtig gelöscht weren, nachdem die Zertifikate darüber validiert hat: https://github.com/certbot/certbot/issues/10492
Ja ich weiß: das ist an sich nur ein kosmetisches Problem. Aber es ist nicht das einzige Problem was ich mit Certbot in den vergangenen Monaten hatte. Erst im März habe ich gemerkt das das OVH DNS Addon in Trixie einfach nicht mehr vorhanden ist.
Um das Problem zu lösen könnte ich einfach Certbot via Docker installieren, so wie ich es auf meiner Debian Trixie Maschine getan habe. Leider würde das aber zu einem anderen Problem führen. Eine meiner Domains lasse ich inzwischen von einem coolen deutschen DNS Anbieter namens desec.io verwalten. Leider gibt es keinen offizielles Docker Image mit deren DNS-01 Certbot Plugin. Ich müsste also ein eigenes Image erstellen und auch Pflegen. Da hab ich jetzt nicht wirklich bock drauf.
Also was mach ich jetzt. Mit einer nativen Certbot Installation pypi, venv etc. will ich mich echt nicht rumschlagen. Gang ehrlich dieses ganzen Python universum war nie wirklich intuitiv für mich. Im März hatte mir jemand im Fediverse zu Lego einem Acme Client der in Go geschrieben wurde geraten. Das Programm unterstützt ca. 200 DNS-01 Challanges verschiedener DNS Provider und kommt als eine statische Go Binary. Das find ich schon extrem cool, also einfach runterladen, entpacken, ausführbar machen und man kann loslegen. Vielleicht schreib ich mir in Zukunft mal ein kleines Script für solche updates.
Ich wollte unter Lego direkt mit der Config Datei arbeiten, damit die automatisierungen hinterher einfacher von der Hand gehen. Auf den ersten Blick schien das recht aber wenn man sich die Config Datei anschaut dann versteht man recht schnell was man davon braucht und was nicht.
In meinem Fall muss ich zwei DNS Provider mit DNS-01 verifikation anlegen und einen mit einer http-01 webroot challenge. Tja Strato hat immer noch keine DNS API für sowas. Das alles hat den Vorteil das der Acme Client nie an Port 80 etc. ran muss und der Webserver so die ganze Zeit online bleibt.
Das ganze zum laufen zu kriegen war recht eifnach. Lego binary von Github downloaden, entpacken, an einen passenden Ort verschieben (ich nehme /usr/local/sbin) und via chmod +x ausfürhbar machen. Danach habe ich den Ordner /etc/lego erstellt wo dann die ganzen Config Dateien und Zertifikate landen.
Nun kann man sich direkt einen Account (eigentlich einen privaten Schlüssel) anlegen, ich habe als Account Namen einfach meine Mail Adresse genommen:
lego accounts register --email [email protected] -a --path /etc/legoWie es weiter geht hängt ein bisschen davon ab wie man seine Domian gegenüber Lets Encrypt verifiziert. Hier ein Beispiel wie ich das bei meinen Domains mache die bei OVH liegen und bei denen ich DNS-01 nutzen. Ich arbeite mit .env- Files um die Zugangsdaten und Einstellungen der jeweiligen DNS Provider zu speichern. Also erstelle ich folgende Datei /etc/lego/.env.ovh und trage dort die im Lego Wiki für OVH aufgeführten Parameter ein, bei mir sind das Application Key, Application Secret, Consumer Key und der Endpoint: https://go-acme.github.io/lego/dns/ovh/index.html
Nun kann man sein erstes Zertifikat erstellen:
lego run --email [email protected] --path /etc/lego -a --dns ovh -d test.example.ovh --env-file /etc/lego/.env.ovhLego legt diese dann in /etc/lego/certificates ab.
Da ich jedoch nicht ewig lange Befehle in Cronjobs etc packen möchte bietet sich die Arbeit mit der Lego Config Datei an, sie macht die automatisierung des Vorgangs viel leichter. Dort fasst man Accounts, Challanges und die verwalteten Domains zusammen. Diese lego.yaml erstelle ich in /etc/lego. Meine sieht ungefähr so aus:
storage: /etc/lego/ accounts: [email protected]: email: [email protected] acceptsTermsOfService: true challenges: desec: dns: provider: desec envFile: /etc/lego/.env.desec resolvers: - 1.1.1.1:53 ovh: dns: provider: ovh envFile: /etc/lego/.env.ovh resolvers: - 1.1.1.1:53 webroot: http: webroot: /var/www/lego # Muss im webserver konfiguriert sein certificates: test.example.desec: #Kann irgendein Name sein, wird als Dateiname genutzt challenge: desec domains: - test.example.desec test.example.ovh: challenge: ovh domains: - test.example.ovh - www.test.example.ovh test.example.webroot: challenge: webroot domains: - test.example.webrootDas ist nur ein Beispiel wie es für mich funktioniert, schaut auf jeden Fall ins Wiki und denkt dran: das ist yaml also nur Leerzeichen, keine Tabs etc.
Wenn man diese Config Datei hat dann reicht ein einfacher aufruf mit dieser als Parameter aus um die Zertifikate zu beziehen oder zu erneuern.:
lego --config /etc/lego/lego.yamlJetzt müssen wir noch sehen das dieser Befehl regelmäßig ausgefürht wird, das kann man über einer Cronjob machen oder über einen Systemd Timer. Dafür werden folgende Dateien angelegt /etc/systemd/system/lego-renew.timer und /etc/systemd/system/lego-renew.service:
[Unit] Description=Lego Certificate Renewal Timer [Timer] OnCalendar=*-*-* 03:00:00 RandomizedDelaySec=1h Persistent=true [Install] WantedBy=timers.targetund
[Unit] Description=Lego Certificate Renewal [Service] Type=oneshot ExecStart=/usr/local/sbin/lego --config /etc/lego/lego.yaml ExecStartPost=systemctl reload nginxNun können wir den systemd daemon neu laden und den timer starten und aktivieren:
systemctl daemon-reload systemctl enable lego-renew.timer systemctl start lego-renew.timerUnd das war es auch schon. Lego sollte sich nun darum kümmern eure Zertifikate immer auf einem aktuellen Stand zu halten. Jetzt muss man natürlich noch sehen das man seinen nginx etc. auf die neuen Zertifikate konfiguriert. Ja das war bei mir Handarbeit, es gibt nen Grund warum ich mich so lange gedrückt habe.
Ich hoffe der Beitrag hilft irgendwem und ist zumindest halbwegs interessant. Falls nicht, dann weiss ich in sechs Monaten zumindest immer noch was ich hier getan habe.
#certbot #desecio #lego #letsencrypt #linux #ovh #selfhosting @bjoern -
Migration von Certbot zu Lego
https://blog.sengotta.net/migration-von-certbot-zu-lego/Ich glaube jeder der selber Dienste hosted kenn das Problem. Da will man nur mal eben eine kleine Änderung auf dem VPS oder auf dem Server im Homelab machen, und dann stolpert man über dieses kleine nervige Problem was man einfach seit Monaten ignoriert hat.
das ist mir heute mal wieder passiert. Eigentlich wollte ich nur eine neue Webapp ausprobieren, aber dafür brauch ich nun einmal ein TLS Zertifikat. Eigentlich kein Problem, aber als ich in mein OVH Dashboard schaue um die Domain anzulegen viel mir auf das der Certbot auf meinem Debian 12 Server immer noch an einen doofen Bug leidet durch den die DNS-01 Acme Challenges nicht mehr richtig gelöscht weren, nachdem die Zertifikate darüber validiert hat: https://github.com/certbot/certbot/issues/10492
Ja ich weiß: das ist an sich nur ein kosmetisches Problem. Aber es ist nicht das einzige Problem was ich mit Certbot in den vergangenen Monaten hatte. Erst im März habe ich gemerkt das das OVH DNS Addon in Trixie einfach nicht mehr vorhanden ist.
Um das Problem zu lösen könnte ich einfach Certbot via Docker installieren, so wie ich es auf meiner Debian Trixie Maschine getan habe. Leider würde das aber zu einem anderen Problem führen. Eine meiner Domains lasse ich inzwischen von einem coolen deutschen DNS Anbieter namens desec.io verwalten. Leider gibt es keinen offizielles Docker Image mit deren DNS-01 Certbot Plugin. Ich müsste also ein eigenes Image erstellen und auch Pflegen. Da hab ich jetzt nicht wirklich bock drauf.
Also was mach ich jetzt. Mit einer nativen Certbot Installation pypi, venv etc. will ich mich echt nicht rumschlagen. Gang ehrlich dieses ganzen Python universum war nie wirklich intuitiv für mich. Im März hatte mir jemand im Fediverse zu Lego einem Acme Client der in Go geschrieben wurde geraten. Das Programm unterstützt ca. 200 DNS-01 Challanges verschiedener DNS Provider und kommt als eine statische Go Binary. Das find ich schon extrem cool, also einfach runterladen, entpacken, ausführbar machen und man kann loslegen. Vielleicht schreib ich mir in Zukunft mal ein kleines Script für solche updates.
Ich wollte unter Lego direkt mit der Config Datei arbeiten, damit die automatisierungen hinterher einfacher von der Hand gehen. Auf den ersten Blick schien das recht aber wenn man sich die Config Datei anschaut dann versteht man recht schnell was man davon braucht und was nicht.
In meinem Fall muss ich zwei DNS Provider mit DNS-01 verifikation anlegen und einen mit einer http-01 webroot challenge. Tja Strato hat immer noch keine DNS API für sowas. Das alles hat den Vorteil das der Acme Client nie an Port 80 etc. ran muss und der Webserver so die ganze Zeit online bleibt.
Das ganze zum laufen zu kriegen war recht eifnach. Lego binary von Github downloaden, entpacken, an einen passenden Ort verschieben (ich nehme /usr/local/sbin) und via chmod +x ausfürhbar machen. Danach habe ich den Ordner /etc/lego erstellt wo dann die ganzen Config Dateien und Zertifikate landen.
Nun kann man sich direkt einen Account (eigentlich einen privaten Schlüssel) anlegen, ich habe als Account Namen einfach meine Mail Adresse genommen:
lego accounts register --email [email protected] -a --path /etc/legoWie es weiter geht hängt ein bisschen davon ab wie man seine Domian gegenüber Lets Encrypt verifiziert. Hier ein Beispiel wie ich das bei meinen Domains mache die bei OVH liegen und bei denen ich DNS-01 nutzen. Ich arbeite mit .env- Files um die Zugangsdaten und Einstellungen der jeweiligen DNS Provider zu speichern. Also erstelle ich folgende Datei /etc/lego/.env.ovh und trage dort die im Lego Wiki für OVH aufgeführten Parameter ein, bei mir sind das Application Key, Application Secret, Consumer Key und der Endpoint: https://go-acme.github.io/lego/dns/ovh/index.html
Nun kann man sein erstes Zertifikat erstellen:
lego run --email [email protected] --path /etc/lego -a --dns ovh -d test.example.ovh --env-file /etc/lego/.env.ovhLego legt diese dann in /etc/lego/certificates ab.
Da ich jedoch nicht ewig lange Befehle in Cronjobs etc packen möchte bietet sich die Arbeit mit der Lego Config Datei an, sie macht die automatisierung des Vorgangs viel leichter. Dort fasst man Accounts, Challanges und die verwalteten Domains zusammen. Diese lego.yaml erstelle ich in /etc/lego. Meine sieht ungefähr so aus:
storage: /etc/lego/ accounts: [email protected]: email: [email protected] acceptsTermsOfService: true challenges: desec: dns: provider: desec envFile: /etc/lego/.env.desec resolvers: - 1.1.1.1:53 ovh: dns: provider: ovh envFile: /etc/lego/.env.ovh resolvers: - 1.1.1.1:53 webroot: http: webroot: /var/www/lego # Muss im webserver konfiguriert sein certificates: test.example.desec: #Kann irgendein Name sein, wird als Dateiname genutzt challenge: desec domains: - test.example.desec test.example.ovh: challenge: ovh domains: - test.example.ovh - www.test.example.ovh test.example.webroot: challenge: webroot domains: - test.example.webrootDas ist nur ein Beispiel wie es für mich funktioniert, schaut auf jeden Fall ins Wiki und denkt dran: das ist yaml also nur Leerzeichen, keine Tabs etc.
Wenn man diese Config Datei hat dann reicht ein einfacher aufruf mit dieser als Parameter aus um die Zertifikate zu beziehen oder zu erneuern.:
lego --config /etc/lego/lego.yamlJetzt müssen wir noch sehen das dieser Befehl regelmäßig ausgefürht wird, das kann man über einer Cronjob machen oder über einen Systemd Timer. Dafür werden folgende Dateien angelegt /etc/systemd/system/lego-renew.timer und /etc/systemd/system/lego-renew.service:
[Unit] Description=Lego Certificate Renewal Timer [Timer] OnCalendar=*-*-* 03:00:00 RandomizedDelaySec=1h Persistent=true [Install] WantedBy=timers.targetund
[Unit] Description=Lego Certificate Renewal [Service] Type=oneshot ExecStart=/usr/local/sbin/lego --config /etc/lego/lego.yaml ExecStartPost=systemctl reload nginxNun können wir den systemd daemon neu laden und den timer starten und aktivieren:
systemctl daemon-reload systemctl enable lego-renew.timer systemctl start lego-renew.timerUnd das war es auch schon. Lego sollte sich nun darum kümmern eure Zertifikate immer auf einem aktuellen Stand zu halten. Jetzt muss man natürlich noch sehen das man seinen nginx etc. auf die neuen Zertifikate konfiguriert. Ja das war bei mir Handarbeit, es gibt nen Grund warum ich mich so lange gedrückt habe.
Ich hoffe der Beitrag hilft irgendwem und ist zumindest halbwegs interessant. Falls nicht, dann weiss ich in sechs Monaten zumindest immer noch was ich hier getan habe.
#certbot #desecio #lego #letsencrypt #linux #ovh #selfhosting @bjoern -
Migration von Certbot zu Lego
https://blog.sengotta.net/migration-von-certbot-zu-lego/Ich glaube jeder der selber Dienste hosted kenn das Problem. Da will man nur mal eben eine kleine Änderung auf dem VPS oder auf dem Server im Homelab machen, und dann stolpert man über dieses kleine nervige Problem was man einfach seit Monaten ignoriert hat.
das ist mir heute mal wieder passiert. Eigentlich wollte ich nur eine neue Webapp ausprobieren, aber dafür brauch ich nun einmal ein TLS Zertifikat. Eigentlich kein Problem, aber als ich in mein OVH Dashboard schaue um die Domain anzulegen viel mir auf das der Certbot auf meinem Debian 12 Server immer noch an einen doofen Bug leidet durch den die DNS-01 Acme Challenges nicht mehr richtig gelöscht weren, nachdem die Zertifikate darüber validiert hat: https://github.com/certbot/certbot/issues/10492
Ja ich weiß: das ist an sich nur ein kosmetisches Problem. Aber es ist nicht das einzige Problem was ich mit Certbot in den vergangenen Monaten hatte. Erst im März habe ich gemerkt das das OVH DNS Addon in Trixie einfach nicht mehr vorhanden ist.
Um das Problem zu lösen könnte ich einfach Certbot via Docker installieren, so wie ich es auf meiner Debian Trixie Maschine getan habe. Leider würde das aber zu einem anderen Problem führen. Eine meiner Domains lasse ich inzwischen von einem coolen deutschen DNS Anbieter namens desec.io verwalten. Leider gibt es keinen offizielles Docker Image mit deren DNS-01 Certbot Plugin. Ich müsste also ein eigenes Image erstellen und auch Pflegen. Da hab ich jetzt nicht wirklich bock drauf.
Also was mach ich jetzt. Mit einer nativen Certbot Installation pypi, venv etc. will ich mich echt nicht rumschlagen. Gang ehrlich dieses ganzen Python universum war nie wirklich intuitiv für mich. Im März hatte mir jemand im Fediverse zu Lego einem Acme Client der in Go geschrieben wurde geraten. Das Programm unterstützt ca. 200 DNS-01 Challanges verschiedener DNS Provider und kommt als eine statische Go Binary. Das find ich schon extrem cool, also einfach runterladen, entpacken, ausführbar machen und man kann loslegen. Vielleicht schreib ich mir in Zukunft mal ein kleines Script für solche updates.
Ich wollte unter Lego direkt mit der Config Datei arbeiten, damit die automatisierungen hinterher einfacher von der Hand gehen. Auf den ersten Blick schien das recht aber wenn man sich die Config Datei anschaut dann versteht man recht schnell was man davon braucht und was nicht.
In meinem Fall muss ich zwei DNS Provider mit DNS-01 verifikation anlegen und einen mit einer http-01 webroot challenge. Tja Strato hat immer noch keine DNS API für sowas. Das alles hat den Vorteil das der Acme Client nie an Port 80 etc. ran muss und der Webserver so die ganze Zeit online bleibt.
Das ganze zum laufen zu kriegen war recht eifnach. Lego binary von Github downloaden, entpacken, an einen passenden Ort verschieben (ich nehme /usr/local/sbin) und via chmod +x ausfürhbar machen. Danach habe ich den Ordner /etc/lego erstellt wo dann die ganzen Config Dateien und Zertifikate landen.
Nun kann man sich direkt einen Account (eigentlich einen privaten Schlüssel) anlegen, ich habe als Account Namen einfach meine Mail Adresse genommen:
lego accounts register --email [email protected] -a --path /etc/legoWie es weiter geht hängt ein bisschen davon ab wie man seine Domian gegenüber Lets Encrypt verifiziert. Hier ein Beispiel wie ich das bei meinen Domains mache die bei OVH liegen und bei denen ich DNS-01 nutzen. Ich arbeite mit .env- Files um die Zugangsdaten und Einstellungen der jeweiligen DNS Provider zu speichern. Also erstelle ich folgende Datei /etc/lego/.env.ovh und trage dort die im Lego Wiki für OVH aufgeführten Parameter ein, bei mir sind das Application Key, Application Secret, Consumer Key und der Endpoint: https://go-acme.github.io/lego/dns/ovh/index.html
Nun kann man sein erstes Zertifikat erstellen:
lego run --email [email protected] --path /etc/lego -a --dns ovh -d test.example.ovh --env-file /etc/lego/.env.ovhLego legt diese dann in /etc/lego/certificates ab.
Da ich jedoch nicht ewig lange Befehle in Cronjobs etc packen möchte bietet sich die Arbeit mit der Lego Config Datei an, sie macht die automatisierung des Vorgangs viel leichter. Dort fasst man Accounts, Challanges und die verwalteten Domains zusammen. Diese lego.yaml erstelle ich in /etc/lego. Meine sieht ungefähr so aus:
storage: /etc/lego/ accounts: [email protected]: email: [email protected] acceptsTermsOfService: true challenges: desec: dns: provider: desec envFile: /etc/lego/.env.desec resolvers: - 1.1.1.1:53 ovh: dns: provider: ovh envFile: /etc/lego/.env.ovh resolvers: - 1.1.1.1:53 webroot: http: webroot: /var/www/lego # Muss im webserver konfiguriert sein certificates: test.example.desec: #Kann irgendein Name sein, wird als Dateiname genutzt challenge: desec domains: - test.example.desec test.example.ovh: challenge: ovh domains: - test.example.ovh - www.test.example.ovh test.example.webroot: challenge: webroot domains: - test.example.webrootDas ist nur ein Beispiel wie es für mich funktioniert, schaut auf jeden Fall ins Wiki und denkt dran: das ist yaml also nur Leerzeichen, keine Tabs etc.
Wenn man diese Config Datei hat dann reicht ein einfacher aufruf mit dieser als Parameter aus um die Zertifikate zu beziehen oder zu erneuern.:
lego --config /etc/lego/lego.yamlJetzt müssen wir noch sehen das dieser Befehl regelmäßig ausgefürht wird, das kann man über einer Cronjob machen oder über einen Systemd Timer. Dafür werden folgende Dateien angelegt /etc/systemd/system/lego-renew.timer und /etc/systemd/system/lego-renew.service:
[Unit] Description=Lego Certificate Renewal Timer [Timer] OnCalendar=*-*-* 03:00:00 RandomizedDelaySec=1h Persistent=true [Install] WantedBy=timers.targetund
[Unit] Description=Lego Certificate Renewal [Service] Type=oneshot ExecStart=/usr/local/sbin/lego --config /etc/lego/lego.yaml ExecStartPost=systemctl reload nginxNun können wir den systemd daemon neu laden und den timer starten und aktivieren:
systemctl daemon-reload systemctl enable lego-renew.timer systemctl start lego-renew.timerUnd das war es auch schon. Lego sollte sich nun darum kümmern eure Zertifikate immer auf einem aktuellen Stand zu halten. Jetzt muss man natürlich noch sehen das man seinen nginx etc. auf die neuen Zertifikate konfiguriert. Ja das war bei mir Handarbeit, es gibt nen Grund warum ich mich so lange gedrückt habe.
Ich hoffe der Beitrag hilft irgendwem und ist zumindest halbwegs interessant. Falls nicht, dann weiss ich in sechs Monaten zumindest immer noch was ich hier getan habe.
#certbot #desecio #lego #letsencrypt #linux #ovh #selfhosting @bjoern