#ovh — Public Fediverse posts

OVHcloud facing the Canadian b digital sovereignty challenge

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

https://moncarnet.com/2026/07/31/ovhcloud-face-au-test-canadien-de-la-souverainete-numerique/

#Canada #OVH #OVHcloud

OVHcloud facing the Canadian b digital sovereignty challenge

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

https://moncarnet.com/2026/07/31/ovhcloud-face-au-test-canadien-de-la-souverainete-numerique/

#Canada #OVH #OVHcloud

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

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

@anolandria #OVH went cloud-native first:
https://www.reuters.com/world/blaze-destroys-servers-europes-largest-cloud-services-firm-2021-03-10/

@anolandria #OVH went cloud-native first:
https://www.reuters.com/world/blaze-destroys-servers-europes-largest-cloud-services-firm-2021-03-10/

Migrating from Certbot to Lego

Many of you know the problem: you just want to make a small adjustment on your VPS or homelab and than you stumble upon this unsolved problem you dont have the motivation to tackle for the last couple of months.

That happened to me today, i just wanted to test a new piece of software for which i needed a TLS certificate. No big deal, but than i have seen that the Certbot on my Debian Bookworm stull suffers a nasty bug and does not cleanup the TXT records for the DNS-01 challange after retrieving a new cert: https://github.com/certbot/certbot/issues/10492

Yes i know, that is only a cosmetic problem. But it is not the only problem i had with certbot in the last couple of months. In march i had the problem of the broken OVH DNS Addon in Debian Trixie.

To solve the problem i could have switch over to the certbot docker install, like i have done on my Debian Trixie machine, but that introduces another problem. One of my domain is managed via desec.io, a cool free german DNS hosting service. The problem is there is no official docker for their DNS-01 addon, which means i would have to maintain my own docker image for that. Sorry i but i dont want to do that.

So what to do now? I didnt wanna mess with Python virtual environments so a native install of certbot is a nogo. I remembered that in march someone told me about Lego an acme client written in Go, with a massive amount of supported DNS-01 capeable DNS providers. One thing i really like about it is that it is only one static go binary. Really easy to update without messing with the package management. Maybe in the foreseeable future i will craft a small bash script that does the updates.

At the first glimpse it seemed rather complicated to work with the config file, but when you break it down it is really good structured and easy.

In my case i have two providers that verify via DNS-01 and one that verifies via http-01 webroot challenge. So the acme client never has to bind to port 80 which means not interruption while getting new certs.

Getting it running is quite easy. Download the Lego binary from github, unpack it, move it to a suitable location (i chose /usr/local/sbin) and make it executeable. After that i created the folder /etc/lego to hold all the configs and the certificates.

What you can directly do is generating an account:

lego accounts register --email [email protected] -a --path /etc/lego

How to proceed depends on the verification challenges you need to use. Just an example what i did for my OVH domains which i use with DNS-01. I am working with .env- Files for storing credentials of my DNS Provider. So generate a file called /etc/lego/.env.ovh and fill it with the credentials described in the Lego wiki in my case Application Key, Application Secret, Consumer Key and the endpoint: https://go-acme.github.io/lego/dns/ovh/index.html

Now i can get my first certificate:

lego run --email [email protected] --path /etc/lego -a --dns ovh -d test.example.ovh --env-file /etc/lego/.env.ovh

Lego will store the certs in /etc/lego/certificates

But now i want to automate that so i will craft a lego.yaml in /etc/lego which tells Lego how to handle multiple domains verification methods etc. Mine looks like this:

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 # Needs to be deliverd by webserver
certificates:
  test.example.desec: #Free name to choose, will be the name of certifcate file
    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

This is just an example, definately have a look into the Wiki, and remember its yaml, so only spaces, no tabs etc.

If you have setup the config file like this you can simply get or renew certificates colling lego only with the config as argument:

lego --config /etc/lego/lego.yaml 

For me in my case i have than just created a systemd timer and a service unit so Lego runs periodically. They are stored in /etc/systemd/system/lego-renew.timer and /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

and

[Unit]
Description=Lego Certificate Renewal

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

Now we reload the systemd daemon, start and enable the timer:

systemctl daemon-reload
systemctl enable lego-renew.timer
systemctl start lego-renew.timer

And that it. Now Lego should take care of your certificates. Of course you now have to change your nginx etc. config files to point to the new location of the certificates, yeah there was a reason why i postponed that task so long.

I hope this post could help someone or is at least interesting. If not: at least i know what i have done here in six months.

Migrating from Certbot to Lego

Many of you know the problem: you just want to make a small adjustment on your VPS or homelab and than you stumble upon this unsolved problem you dont have the motivation to tackle for the last couple of months.

That happened to me today, i just wanted to test a new piece of software for which i needed a TLS certificate. No big deal, but than i have seen that the Certbot on my Debian Bookworm stull suffers a nasty bug and does not cleanup the TXT records for the DNS-01 challange after retrieving a new cert: https://github.com/certbot/certbot/issues/10492

Yes i know, that is only a cosmetic problem. But it is not the only problem i had with certbot in the last couple of months. In march i had the problem of the broken OVH DNS Addon in Debian Trixie.

To solve the problem i could have switch over to the certbot docker install, like i have done on my Debian Trixie machine, but that introduces another problem. One of my domain is managed via desec.io, a cool free german DNS hosting service. The problem is there is no official docker for their DNS-01 addon, which means i would have to maintain my own docker image for that. Sorry i but i dont want to do that.

So what to do now? I didnt wanna mess with Python virtual environments so a native install of certbot is a nogo. I remembered that in march someone told me about Lego an acme client written in Go, with a massive amount of supported DNS-01 capeable DNS providers. One thing i really like about it is that it is only one static go binary. Really easy to update without messing with the package management. Maybe in the foreseeable future i will craft a small bash script that does the updates.

At the first glimpse it seemed rather complicated to work with the config file, but when you break it down it is really good structured and easy.

In my case i have two providers that verify via DNS-01 and one that verifies via http-01 webroot challenge. So the acme client never has to bind to port 80 which means not interruption while getting new certs.

Getting it running is quite easy. Download the Lego binary from github, unpack it, move it to a suitable location (i chose /usr/local/sbin) and make it executeable. After that i created the folder /etc/lego to hold all the configs and the certificates.

What you can directly do is generating an account:

lego accounts register --email [email protected] -a --path /etc/lego

How to proceed depends on the verification challenges you need to use. Just an example what i did for my OVH domains which i use with DNS-01. I am working with .env- Files for storing credentials of my DNS Provider. So generate a file called /etc/lego/.env.ovh and fill it with the credentials described in the Lego wiki in my case Application Key, Application Secret, Consumer Key and the endpoint: https://go-acme.github.io/lego/dns/ovh/index.html

Now i can get my first certificate:

lego run --email [email protected] --path /etc/lego -a --dns ovh -d test.example.ovh --env-file /etc/lego/.env.ovh

Lego will store the certs in /etc/lego/certificates

But now i want to automate that so i will craft a lego.yaml in /etc/lego which tells Lego how to handle multiple domains verification methods etc. Mine looks like this:

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 # Needs to be deliverd by webserver
certificates:
  test.example.desec: #Free name to choose, will be the name of certifcate file
    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

This is just an example, definately have a look into the Wiki, and remember its yaml, so only spaces, no tabs etc.

If you have setup the config file like this you can simply get or renew certificates colling lego only with the config as argument:

lego --config /etc/lego/lego.yaml 

For me in my case i have than just created a systemd timer and a service unit so Lego runs periodically. They are stored in /etc/systemd/system/lego-renew.timer and /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

and

[Unit]
Description=Lego Certificate Renewal

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

Now we reload the systemd daemon, start and enable the timer:

systemctl daemon-reload
systemctl enable lego-renew.timer
systemctl start lego-renew.timer

And that it. Now Lego should take care of your certificates. Of course you now have to change your nginx etc. config files to point to the new location of the certificates, yeah there was a reason why i postponed that task so long.

I hope this post could help someone or is at least interesting. If not: at least i know what i have done here in six months.

Runnig your own server incl. TLS stuff is always quite funny. You only want to try a new service and you need a certificate for it. In the progress of obtaining this you realize the still unsolved certbot problem where is does not delete old acme challenges from OVH. Okay there ist no update for that using certbot on Debian 12. Okay i could switch to the docker version of certbot, but that does not include the desec.io DNS Provider provider plugin, which i need for the new domain.
I could now make my own docker container for that, and keep that updated.
Or i make that switch to the Lego acme client which includes numerous DNS Providers and cleans up acme challenges in OVH just fine.
Btw still have no certificates for the new domain 🫠️
#desec #ovh #letsencrypt #certbot #lego #selfhosting
@homelab

Runnig your own server incl. TLS stuff is always quite funny. You only want to try a new service and you need a certificate for it. In the progress of obtaining this you realize the still unsolved certbot problem where is does not delete old acme challenges from OVH. Okay there ist no update for that using certbot on Debian 12. Okay i could switch to the docker version of certbot, but that does not include the desec.io DNS Provider provider plugin, which i need for the new domain.
I could now make my own docker container for that, and keep that updated.
Or i make that switch to the Lego acme client which includes numerous DNS Providers and cleans up acme challenges in OVH just fine.
Btw still have no certificates for the new domain 🫠️
#desec #ovh #letsencrypt #certbot #lego #selfhosting
@homelab

Personal website down again.
No help to expect from OVH.
Getting tired of this. Hope I'll find time and energy to fix that before holiday....

#ovh #website #down

Personal website down again.
No help to expect from OVH.
Getting tired of this. Hope I'll find time and energy to fix that before holiday....

#ovh #website #down

Turns out, OVH had to patch all their hypervisors because of a vulnerability in KVM. This did lead to service disruptions to their customers.

https://blog.ovhcloud.com/cve-2026-53359-januscape-patching-campaign-lessons-learned-from-remediating-a-kvm-flaw-across-tens-of-thousands-of-machines/
- - -
Il se trouve, OVH a eu à corriger une vulnérabilité dans KVM sur tous leurs hyperviseurs. Ceci a entraîné des interruptions de service chez leur clientèle

https://blog.ovhcloud.com/campagne-de-patch-de-la-cve-2026-53359-januscape-retour-dexperience-sur-le-traitement-dune-faille-kvm-sur-plusieurs-dizaines-de-milliers-de-machines/

#OVH #Montréal

Turns out, OVH had to patch all their hypervisors because of a vulnerability in KVM. This did lead to service disruptions to their customers.

https://blog.ovhcloud.com/cve-2026-53359-januscape-patching-campaign-lessons-learned-from-remediating-a-kvm-flaw-across-tens-of-thousands-of-machines/
- - -
Il se trouve, OVH a eu à corriger une vulnérabilité dans KVM sur tous leurs hyperviseurs. Ceci a entraîné des interruptions de service chez leur clientèle

https://blog.ovhcloud.com/campagne-de-patch-de-la-cve-2026-53359-januscape-retour-dexperience-sur-le-traitement-dune-faille-kvm-sur-plusieurs-dizaines-de-milliers-de-machines/

#OVH #Montréal

Seems like OVH is finally doing VPS in Mumbai, India https://www.ovhcloud.com/en-in/public-cloud/prices/#compute

#OVH #Mumbai #India

Seems like OVH is finally doing VPS in Mumbai, India https://www.ovhcloud.com/en-in/public-cloud/prices/#compute

#OVH #Mumbai #India

@miyuru

Their management is still #LegacyIP therefore still a no go for me.

My FR to this topic has been open since ....

https://github.com/issues/created?issue=ovh%7Chosting-domain-names-roadmap%7C84

#OVH #IPv6 #S3 #objectstorage

@miyuru

Their management is still #LegacyIP therefore still a no go for me.

My FR to this topic has been open since ....

https://github.com/issues/created?issue=ovh%7Chosting-domain-names-roadmap%7C84

#OVH #IPv6 #S3 #objectstorage

Was ist denn bei #OVH bei den VPS los?

Teilweise Nicht-Erreichbarkeit im Halb-Stundentakt.

Something I noticed about OVH's VPS with FreeBSD on ZFS.

ashift seems to be set to 0. I would've thought it would be set to 12?

Is ashift=0 normal on their VPSes?

#ovh #ovhcloud #FreeBSD #ZFS

Something I noticed about OVH's VPS with FreeBSD on ZFS.

ashift seems to be set to 0. I would've thought it would be set to 12?

Is ashift=0 normal on their VPSes?

#ovh #ovhcloud #FreeBSD #ZFS

Sometimes newer is not better. At least not for the things that matter to you.

I benchmarked two OVH VPS in the same Zurich location. My current 2025 model with a 500 Mbit network against the newer 2027 model with 1 Gbit. Same AMD EPYC Genoa cores, same provider, nearly identical sysbench CPU scores.

Then the surprises started.
The older box pushes 6,612 MiB/s in memory tests, the newer one 932 MiB/s. That is 7x.
Random 4K reads: 1.32 million IOPS against 832k.
And the old model is even about 1 EUR cheaper.

For a Mastodon instance, databases, and Docker workloads, memory and disk beat extra bandwidth every time. So the shiny new VPS gets demoted to reverse proxy and backup duty, and this instance stays exactly where it is.

Benchmark before you migrate.

#SelfHosting #Mastodon #Fediverse #VPS #OVH #Benchmarks #Homelab #Blog #MastoAdmin

Sometimes newer is not better. At least not for the things that matter to you.

I benchmarked two OVH VPS in the same Zurich location. My current 2025 model with a 500 Mbit network against the newer 2027 model with 1 Gbit. Same AMD EPYC Genoa cores, same provider, nearly identical sysbench CPU scores.

Then the surprises started.
The older box pushes 6,612 MiB/s in memory tests, the newer one 932 MiB/s. That is 7x.
Random 4K reads: 1.32 million IOPS against 832k.
And the old model is even about 1 EUR cheaper.

For a Mastodon instance, databases, and Docker workloads, memory and disk beat extra bandwidth every time. So the shiny new VPS gets demoted to reverse proxy and backup duty, and this instance stays exactly where it is.

Benchmark before you migrate.

#SelfHosting #Mastodon #Fediverse #VPS #OVH #Benchmarks #Homelab #Blog #MastoAdmin

#OVH a finalement réparé (hier soir) et publié de l'information (largement fausse mais c'est mieux que rien) : https://public-cloud.status-ovhcloud.com/incidents/40y1wvq5tjmt

#OVH a finalement réparé (hier soir) et publié de l'information (largement fausse mais c'est mieux que rien) : https://public-cloud.status-ovhcloud.com/incidents/40y1wvq5tjmt

Mes sites OVH sont down depuis deux heures. Quelqu'un d'autre dans ce cas ?

#ovh #ovhcloud

Mes sites OVH sont down depuis deux heures. Quelqu'un d'autre dans ce cas ?

#ovh #ovhcloud

Aaah… there we go!

https://bare-metal-servers.status-ovhcloud.com/incidents/s2lv6fn56gc2
- - -
Aaah… voilà la raison!

// Publication en anglais //

#OVH #Montréal

Aaah… there we go!

https://bare-metal-servers.status-ovhcloud.com/incidents/s2lv6fn56gc2
- - -
Aaah… voilà la raison!

// Publication en anglais //

#OVH #Montréal

It seems like OVH took servers offline in the BHS6 zone 😬
- - -
Il semble qu’OVH a éteint des serveurs dans la zone BHS6😬

#OVH #Montréal

It seems like OVH took servers offline in the BHS6 zone 😬
- - -
Il semble qu’OVH a éteint des serveurs dans la zone BHS6😬

#OVH #Montréal

Someone having problems in #OVH #SBG? My server seems blocked since this morning. I saw some maintenance being done in SBG3, but I see nothing on SBG6 (the one I have my VPS), so I'm not sure if it's related to that. 🙃

Someone having problems in #OVH #SBG? My server seems blocked since this morning. I saw some maintenance being done in SBG3, but I see nothing on SBG6 (the one I have my VPS), so I'm not sure if it's related to that. 🙃

Give me a ping, ~~Vasili~~ #OVH. One ping only, please.

> 94 packets transmitted, 1 received, 98.9362% packet loss, time 95176ms

#IPv6

Give me a ping, ~~Vasili~~ #OVH. One ping only, please.

> 94 packets transmitted, 1 received, 98.9362% packet loss, time 95176ms

#IPv6

Ticket CS16211659 , on verra bien.

#OVH

Ticket CS16211659 , on verra bien.

#OVH

C'est moi, ou le routage IPv6 chez #OVH déconne bien ?

C'est moi, ou le routage IPv6 chez #OVH déconne bien ?

Questionnement du jour : migrer mes emails de #OVH (offre pro basée sur Exchange) vers la #kSuite de #Infomaniak sans migrer le domaine (que je viens de renouveler...) : bonne ou mauvaise idée ?

Vous utilisez quoi pour vos backups (chiffrés) distants ? J'ai un borgbackup qui tourne 4 fois par jour vers un Kimsufi à 5€ qui a 2 TB mais ça devient tendu niveau RAM/CPU pour mes autres usages (wallabag, nextcloud, etc...). Sauf qu'en dessous de 20€/mois j'ai l'impression que c'est compliqué d'avoir du stockage chez Kimsufi. Vous conseillez de séparer données et services chez 2 providers différents ? C'est quoi les solutions avec Borg ? #stockage #backup #autohebergement #yunohost #borg #ovh #kimsufi

@davidgerard I use @beasts and #ovh.

I do a bit of web, some #WireGuardVPN and email on both systems and manage it all myself. Both are fine and cheapish.

I used to use #bytemark but they got swallowed up by iomart.

Auch #OVH erhöht ab Juli die Preise: https://xcancel.com/olesovhcom/status/2069848711442694163

Kurzfassung:
Der CEO vermutet bis 2027 eine Verzwölffachung der RAM- und eine Versiebenfachung der NVMe-Preise. Beim Rest der Hardware-Komponenten werden es auch so +15% bis +20%.

Joah. Wie zu erwarten war, werden nach Hetzner jetzt nach und nach alle Provider nachziehen. Mal gucken, ob sich dann in Zukunft auch die Fediverse-Server konsolidieren werden.
Cloud- und Hosting-Maschinen werden mehr auf Kante geschnitten, immer am Rand der Last gefahren. Das Web wird nicht schneller, sondern eher träger werden.

Es wird Zeit, dass die #AI​-Bubble platzt.

Auch #OVH erhöht ab Juli die Preise: https://xcancel.com/olesovhcom/status/2069848711442694163

Kurzfassung:
Der CEO vermutet bis 2027 eine Verzwölffachung der RAM- und eine Versiebenfachung der NVMe-Preise. Beim Rest der Hardware-Komponenten werden es auch so +15% bis +20%.

Joah. Wie zu erwarten war, werden nach Hetzner jetzt nach und nach alle Provider nachziehen. Mal gucken, ob sich dann in Zukunft auch die Fediverse-Server konsolidieren werden.
Cloud- und Hosting-Maschinen werden mehr auf Kante geschnitten, immer am Rand der Last gefahren. Das Web wird nicht schneller, sondern eher träger werden.

Es wird Zeit, dass die #AI​-Bubble platzt.

Second incident with my OVH VPS in the Zürich local zone today.

The first incident was a network problem - https://dol.social/@dima/116781260837510263

This time their super resilient storage failed.

The first image is from the KVM console. It shows many I/O errors on the disk device sda1.
The EXT4 file system aborted the journal and remounted as read only.

The second image is from the OVH panel.
It says Remote storage Resilient is included (haha).

The third image is my monitoring graph.
It shows 4 hours of downtime on June 19 (due to the network issues).

The fourth image shows another downtime today. It lasted 2 hours.

Super resilient storage does not look very reliable right now.

Has anyone else seen problems with OVH storage or local zones? That's insane. 7h downtime per week.

#OVH #VPS #Outage #Storage #SelfHosting #Cloud #Hosting #OVHCloud #Mastodon #Fediverse #MastoAdmin

Bonsoir les Chtis et plus largement les Français. Si vous utilisez #DeltaChat, vous pouvez choisir un serveur relais près de chez vous, à #Roubaix (chez #OVH) : https://d.gaufr.es/
[* Edit: serveur mis à dispo par @Kooda - 🙏]

⚠️ OVH Local Zone Zurich outage (~4h)

My VPS in OVH’s Zurich Local Zone (where this Mastodon instance lives) was completely unreachable for about 4 hours yesterday.

No status page updates, no incident notice, nothing from OVH (so typical).

From my side it looked like a clean Layer 3 issue - pings to the VPS returned Destination Host Unreachable from their ToR router inside the zone:
localzone-zrh-zur1-tor2-as4210011009.ch.eu (57.128.121.83)

Monitoring graph for the last 24h is attached.

#SelfHosting #Mastodon #OVH #LocalZone #Zurich #Outage #Networking #Fediverse