J'ai découvert #SecNumCloud de l'#ANSSI

https://notes.sklein.xyz/2025-06-21_1516/

#TIL #Hosting #Scaleway #OVH #CloudProvider #France

Wait, so OVH supports DNS Anycast ?
That's getting interesting...

#dns #anycast #ovh #homelab #cloud

A voir ce qu'ils vont faire, mais si c'est héberger leurs donne chez OVH, c'est déjà mieux que chez azure oui. Ensuite, tout passer sur des technos libre pour vraiment arrêter de renvoyer toutes nos data aux us serait un plus

https://next.ink/189030/la-commission-europeenne-negocierait-le-passage-de-son-cloud-de-microsoft-a-ovhcloud/

#azure #microsoft #ovh #ovhcloud #eu #souveraineténumérique

Is anybody else having problems with @OVHcloud marking legitimate emails with [SPAM] in the subject? They consistently have been doing this for legitimate emails coming from #bolcom and #ebem for the past four months! I have logged four support cases. Six times they said it was solved and still they mark these emails as spam. I did not have this problem before with another email hosting company. #ovh #email #spam

Es gibt Hoffnung in Sachen #Digitalsouveränität: Kurioserweise war die #EU selbst lange Jahre einer der größten Verfechter einer unsouveränen #Cloud-Datennutzungspolitik.

Nun scheint es mit Blick auf die globalen Veränderungen doch eine strategische Neuausrichtung zu geben, denn die Europäische Kommission plant laut internen Dokumenten, auf native europäische Anbieter wie #OVH oder #Ionos zu setzen - und das entgegen der neuesten Souveränitätsversprechen von #Microsoft:

https://www.euractiv.com/section/tech/news/scoop-commission-eyes-ditching-microsoft-azure-for-frances-ovhcloud-over-digital-sovereignty-fears/

My main bugbear with OVH is that they *still* don't offer "failover IP" (where you can fairly quickly move an IP between different dedicated servers) for IPv4, not IPV6.

And, no, they don't offer "Bring Your Own IP" for IPv6 either, only for IPv4.

So when I recently migrated us to a new server I had to do the DNS TTL dance with the IPv6 side of things.

Oh, and it's still only a /64 per server. Not that anything stops you from just using <prefix>::1, ::2, ::3 etc as needed.

Of course then we ran into an issue with the IPv4 failover IP anyway. For some reason moving it caused their "Game Firewall" to become active on it, default blocking all UDP. Took a little while to figure that out.

#ovh

#askfedi what are your favourite #VPS these days? I'm new to it, will run very basic services on it (#pihole , #deltachat , ...) so I need a cheap one, based in #europe .

I seem to hear good stuff about #hetzner and they seem cheaper than #commbell or #ovh .

Thank you!

@sebsauvage @siltaer Je viens de passer la dernière année à transférer la majeure partir de mes client·es chez eux depuis OVH pour des raisons de qualité de service mais aussi (beaucoup) pour des raisons éthiques 😭😭😭
Ça devient de plus en plus compliqué de passer entre les gouttes !
#OVH #infomaniak #donnespersonnelles

@dragondaddy
Unfortunately reading their docs #OVH does #IPv6 in a weird way and they do not listen to @beasts learnings.
Host should get /64 and not /128.

Blocklists are one /64 length.

https://youtu.be/ZqNYogK7B-w?si=wuYq2N9okcYqsgg0
https://www.ipv6.org.uk/wp-content/uploads/2022/10/10_Dual-stack-is-rubbish.pdf

Barman woes on OVH

So, due to a cascade of Barman’s errors and corrupted backups due to running out of backup space, I had to pretty much clear out my Barman backup storage.

After resetting everything, however, I was not able to make a full backup, because Barman was not able to receive write-ahead logs from PostgreSQL.

2025-06-04 22:00:21,209 [523687] barman.cli ERROR: [Errno 5] Input/output error: '/backup/barman/pg/wals/00000001000000CD/00000001000000CD00000009.tmp'
See log file for more details.
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/barman/cli.py", line 2390, in main
    args.func(args)
  File "/usr/lib/python3/dist-packages/barman/cli.py", line 1600, in archive_wal
    server.archive_wal()
  File "/usr/lib/python3/dist-packages/barman/server.py", line 2651, in archive_wal
    self.backup_manager.archive_wal(verbose)
  File "/usr/lib/python3/dist-packages/barman/backup.py", line 847, in archive_wal
    archiver.archive(verbose)
  File "/usr/lib/python3/dist-packages/barman/wal_archiver.py", line 213, in archive
    self.archive_wal(compressor, wal_info)
  File "/usr/lib/python3/dist-packages/barman/wal_archiver.py", line 356, in archive_wal
    shutil.copystat(src_file, tmp_file)
  File "/usr/lib/python3.12/shutil.py", line 388, in copystat
    _copyxattr(src, dst, follow_symlinks=follow)
  File "/usr/lib/python3.12/shutil.py", line 338, in _copyxattr
    os.setxattr(dst, name, value, follow_symlinks=follow_symlinks)
OSError: [Errno 5] Input/output error: '/backup/barman/pg/wals/00000001000000CD/00000001000000CD00000009.tmp'

Input/output error? That’s odd, but the stacktrace tells us a lot, as from the function name (os.setxattr), we can deduce that it’s trying to set xattrs on our WAL files. The underlying storage for my backups is OVH’s Backup Storage, accessible over NFS. And NFS, for most of its life, was not able to support xattrs even if the underlying filesystem does. The support has been added to NFS 4.2, while OVH (still) uses 4.1.

So, how to fix this?

Initially, I thought of downgrading Barman, because things had worked before. But that did not help, and so I had to go digging into the source code (which was painful as I am not a Python guy).

# Perform the real filesystem operation with the xlogdb lock taken.            # This makes the operation atomic from the xlogdb file POV            with self.server.xlogdb("a") as fxlogdb:                # If the content has changed, it means the file was either compressed                # or encrypted or both. In this case, we need to update its metadata                if content_changed:                    shutil.copystat(src_file, current_file)                    stat = os.stat(current_file)                    wal_info.size = stat.st_size

So, if content_changed is true, we use copystat from shutil.py, which copies xattrs from the original file.

# If the bits of the file has changed e.g. due to compression or encryption            content_changed = False            # Compress the file if not already compressed            if compressor and not wal_info.compression:                compressor.compress(src_file, tmp_file)                files_to_remove.append(current_file)                current_file = tmp_file                content_changed = True                wal_info.compression = compressor.compression            # Encrypt the file            if encryption:                encrypted_file = encryption.encrypt(current_file, dst_dir)                files_to_remove.append(current_file)                current_file = encrypted_file                wal_info.encryption = encryption.NAME                content_changed = True

Ah, so therein lies the rub: Barman assumes that it needs to do this if the content is either being compressed or encrypted. And it just so happens that I’ve also enabled GZIP compression so as not to run out of space again. Well, we have to deal with this the old-fashioned way (by lowering the retention policy). After disabling compression, Barman was able to make backups again.

Hope this helps someone, because it sure as fuck would’ve helped me.

#Barman #lighthearted #NFS #NFSv4 #OVH #pgsql #PostgreSQL #SelfHosting

And we're finally back.

They found a cooling issue and claim to have address it. Perhaps that was the root cause of the RAM issue, maybe we'll never know.

OVH action was delayed by a separate issue they had with a whole two racks, tying up their staff.

All of Fysh.Org is currently back up.

We've scheduled downtime from 13:00 BST (UTC+1) this Saturday 7th June 2026 in order to perform the migration to the new server.

#fyshorg #ovh

Once we'd reached 24 hours since opening the support ticket I used OVH's Live Chat.

Turns out that whoever they assigned yesterday went "does it ping? yes, well that's that then" and didn't bother to tell us at all.

They're now in the middle of an actual "intervention".

Meantime we've rented a *new* server to migrate things to once the old is back up again. We have backups we can restore to the new server, but they'll be missing a few hours of deltas, and it's just easier and quicker to image copy things from the old.

If the old server is handed back in a reasonable state (RAM replaced, or removed leaving reduced but workable amount) then we'll bring it back up fully ASAP.

Migration to the new server will then be pre-announced for this weekend, hopefully taking ~5-6 hours at most.

We had been on this old server for almost 10 years !

#fyshorg #ovh

Still no word/action from OVH.

In the meantime I've temporarily (a reboot will break it, due to reverting to the usual configuration for WWW in a VM) made https://www.fysh.org/ work (IPv4 and 6) to display a short message.

I'll update that as and when anything changes, or if the full service is back it'll revert to normal content (a mediawiki instance).

https://www.fysh.org/

#fyshorg #OVH

It's coming up 4 hours since we opened a tick with OVH, with no acknowledgement or response from them yet.

We've not paid extra, so their stated response time is "8 business hours".

We have a couple of contingency plans if they can't source a replacement DIMM.

fysh.org services will remain down in the meantime, as we no longer want to risk running them on suspect hardware. Yes, we have backups should we need to restore from them, but hopefully can manage to copy VM disk images to new hardware if needs be.

#fyshorg #ovh

J'ai une question pour techs du net : pourquoi les loueurs de serveurs type #ovh ou #scaleway se bornent à coller 2 disques identiques en miroir dans toutes leurs gammes, #ssd ou #hdd ?
Le raid n'est pas une sauvegarde... et franchement, j'aimerais tant avoir un ssd et un hdd uniques mais pas l'un ou l'autre ...

C'est infernal d'avoir un serveur #soyoustart chez #ovh ... j'ai demandé une ip supplémentaire il y a quelques semaines et un mail de relance me dit qu'elle n'est pas en renouvellement automatique (???). Aucune des procédures dans le mail ne permet de faire quelque chose (payer !) ... rien dans le compte client non plus ... Et pour dire, même le numéro de tel du service client n'est plus valide. Et ce n'est pas du spam...
Ticket ouvert pour une expi au 2 juin ... ça va couper ... 😡

« La première sensation lorsqu’on entre dans un data center, c’est la perception de la matérialité du numérique. OVH a beau être dans le secteur du cloud, ici rien de nuageux, de virtuel ou de vaporeux.

Non, on voit du cuivre, du métal, des câbles, des tuyaux, des racks, et des lumières qui crépitent, et ce ne sont pas celles des flashs de la montée des marches, au contraire un data center nous oblige à descendre dans la matière et sous la chaleur des machines, quant au bruit ambiant, ça donne ça : »

Petite plongée de 3 minutes par #FranceCulture chez #OVH… Hum, il me tarde d’entendre en 2030 « qui aurait pu prédire ? »

https://www.radiofrance.fr/franceculture/podcasts/un-monde-connecte/en-immersion-dans-l-un-des-plus-grands-data-center-de-france-5655997

Fin des modèles d’installation personnalisés d’OS sur les serveurs dédiés #OVH en faveur de l’utilisation d’une API.

- 17 juin 2025 -> plus de nouveaux modèles
- Octobre 2025 -> désactivation de la fonctionnalité.

Wenn ihr eure #dev Umgebung (#proxmox / LB / Firewall / #coder / #nomad / #iscsi ..) von eurem Büro und eigener #Hardware in eine europäische "#cloud" Umgebung schieben wolltet, was würde ihr für einen #hoster nehmen ?

Ist es sowas wie #Hetzner , #ovh .. oder #stackit (die scheinbar nirgends Preise haben) etc. pp.

Eure Meinungen sind gefragt ! :-)