home.social

#ovh — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #ovh, aggregated by home.social.

fetched live
  1. #selfhosting a #mailserver on #OVH turns out to be a nightmare.
    Esoteric blocklists won’t release my IP, only after paying ransom, it appears.

  2. #selfhosting a #mailserver on #OVH turns out to be a nightmare.
    Esoteric blocklists won’t release my IP, only after paying ransom, it appears.

  3. #selfhosting a #mailserver on #OVH turns out to be a nightmare.
    Esoteric blocklists won’t release my IP, only after paying ransom, it appears.

  4. #selfhosting a #mailserver on #OVH turns out to be a nightmare.
    Esoteric blocklists won’t release my IP, only after paying ransom, it appears.

  5. #selfhosting a #mailserver on #OVH turns out to be a nightmare.
    Esoteric blocklists won’t release my IP, only after paying ransom, it appears.

  6. OVHcloud discontinues all-inclusive plans for public cloud instances starting 1 October. They will bill local storage and IPv4 addresses separately.

    blog.ovhcloud.com/en/posts/pub
    - - -
    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.

    blog.ovhcloud.com/fr/posts/pub

    #OVH #OVHcloud

  7. OVHcloud discontinues all-inclusive plans for public cloud instances starting 1 October. They will bill local storage and IPv4 addresses separately.

    blog.ovhcloud.com/en/posts/pub
    - - -
    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.

    blog.ovhcloud.com/fr/posts/pub

    #OVH #OVHcloud

  8. OVHcloud discontinues all-inclusive plans for public cloud instances starting 1 October. They will bill local storage and IPv4 addresses separately.

    blog.ovhcloud.com/en/posts/pub
    - - -
    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.

    blog.ovhcloud.com/fr/posts/pub

    #OVH #OVHcloud

  9. OVHcloud discontinues all-inclusive plans for public cloud instances starting 1 October. They will bill local storage and IPv4 addresses separately.

    blog.ovhcloud.com/en/posts/pub
    - - -
    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.

    blog.ovhcloud.com/fr/posts/pub

    #OVH #OVHcloud

  10. OVHcloud discontinues all-inclusive plans for public cloud instances starting 1 October. They will bill local storage and IPv4 addresses separately.

    blog.ovhcloud.com/en/posts/pub
    - - -
    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.

    blog.ovhcloud.com/fr/posts/pub

    #OVH #OVHcloud

  11. 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 handelsblatt.com/technik/it-in

  12. 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 handelsblatt.com/technik/it-in

  13. 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 handelsblatt.com/technik/it-in

  14. 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 handelsblatt.com/technik/it-in

  15. 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 handelsblatt.com/technik/it-in

  16. 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

  17. 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

  18. 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

  19. 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

  20. OVHcloud announces price increases for their 2024 and 2026 generation dedicated servers, whether already deployed or new orders

    blog.ovhcloud.com/en/posts/ded
    - - -
    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 #OVH

  21. OVHcloud announces price increases for their 2024 and 2026 generation dedicated servers, whether already deployed or new orders

    blog.ovhcloud.com/en/posts/ded
    - - -
    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 #OVH

  22. OVHcloud announces price increases for their 2024 and 2026 generation dedicated servers, whether already deployed or new orders

    blog.ovhcloud.com/en/posts/ded
    - - -
    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 #OVH

  23. OVHcloud announces price increases for their 2024 and 2026 generation dedicated servers, whether already deployed or new orders

    blog.ovhcloud.com/en/posts/ded
    - - -
    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 #OVH

  24. OVHcloud announces price increases for their 2024 and 2026 generation dedicated servers, whether already deployed or new orders

    blog.ovhcloud.com/en/posts/ded
    - - -
    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 #OVH

  25. 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.

  26. 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.

  27. 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.

  28. 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.

  29. 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.

  30. 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 winfuture.de/news,160538.html?

  31. 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 winfuture.de/news,160538.html?

  32. 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 winfuture.de/news,160538.html?

  33. 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 winfuture.de/news,160538.html?

  34. 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 winfuture.de/news,160538.html?

  35. 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

  36. 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

  37. 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

  38. 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

  39. 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

  40. 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

  41. 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

  42. 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

  43. 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

  44. 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

  45. OVHcloud facing the Canadian b digital sovereignty challenge

    // Article in French //
    - - -
    OVHcloud face au test canadien de la souveraineté numérique

    moncarnet.com/2026/07/31/ovhcl

    #Canada #OVH #OVHcloud

  46. OVHcloud facing the Canadian b digital sovereignty challenge

    // Article in French //
    - - -
    OVHcloud face au test canadien de la souveraineté numérique

    moncarnet.com/2026/07/31/ovhcl

    #Canada #OVH #OVHcloud

  47. OVHcloud facing the Canadian b digital sovereignty challenge

    // Article in French //
    - - -
    OVHcloud face au test canadien de la souveraineté numérique

    moncarnet.com/2026/07/31/ovhcl

    #Canada #OVH #OVHcloud

  48. OVHcloud facing the Canadian b digital sovereignty challenge

    // Article in French //
    - - -
    OVHcloud face au test canadien de la souveraineté numérique

    moncarnet.com/2026/07/31/ovhcl

    #Canada #OVH #OVHcloud

  49. OVHcloud facing the Canadian b digital sovereignty challenge

    // Article in French //
    - - -
    OVHcloud face au test canadien de la souveraineté numérique

    moncarnet.com/2026/07/31/ovhcl

    #Canada #OVH #OVHcloud

  50. Migration von Certbot zu Lego

    blog.sengotta.net/migration-vo

    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/lego

    Wie 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.ovh

    Lego 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.webroot

    Das 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.yaml 

    Jetzt 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.target

    und

    [Unit]
    Description=Lego Certificate Renewal
    
    [Service]
    Type=oneshot
    ExecStart=/usr/local/sbin/lego --config /etc/lego/lego.yaml
    ExecStartPost=systemctl reload nginx

    Nun 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.timer

    Und 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
  51. Migration von Certbot zu Lego

    blog.sengotta.net/migration-vo

    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/lego

    Wie 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.ovh

    Lego 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.webroot

    Das 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.yaml 

    Jetzt 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.target

    und

    [Unit]
    Description=Lego Certificate Renewal
    
    [Service]
    Type=oneshot
    ExecStart=/usr/local/sbin/lego --config /etc/lego/lego.yaml
    ExecStartPost=systemctl reload nginx

    Nun 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.timer

    Und 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
  52. Migration von Certbot zu Lego

    blog.sengotta.net/migration-vo

    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/lego

    Wie 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.ovh

    Lego 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.webroot

    Das 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.yaml 

    Jetzt 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.target

    und

    [Unit]
    Description=Lego Certificate Renewal
    
    [Service]
    Type=oneshot
    ExecStart=/usr/local/sbin/lego --config /etc/lego/lego.yaml
    ExecStartPost=systemctl reload nginx

    Nun 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.timer

    Und 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
  53. Migration von Certbot zu Lego

    blog.sengotta.net/migration-vo

    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/lego

    Wie 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.ovh

    Lego 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.webroot

    Das 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.yaml 

    Jetzt 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.target

    und

    [Unit]
    Description=Lego Certificate Renewal
    
    [Service]
    Type=oneshot
    ExecStart=/usr/local/sbin/lego --config /etc/lego/lego.yaml
    ExecStartPost=systemctl reload nginx

    Nun 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.timer

    Und 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