#hetzner — Public Fediverse posts

When two Hetzner servers died at the same time

On May 12, 2026, two of my Arch Linux + LUKS servers at Hetzner became unreachable at the same moment. Both had been running for 4+ months without issue. Both had received the same pacman -Syyu the day before, but had stayed on the old kernel until the morning the websites stopped responding. I rebooted — SSH never came back. nmap -Pn -p 22 showed filtered from anywhere. No ping. No banner. The Hetzner Robot panel insisted the hardware was fine.

Several hours went into hypotheses that turned out to be wrong:

• The encryptssh initcpio hook referencing a /usr/lib/initcpio/udev/11-dm-initramfs.rules file that no longer exists. Real bug, no boot impact — the initramfs rebuilds anyway.
• PermitRootLogin no in sshd_config. Real misconfiguration, fixed it, didn’t help. A refusing sshd shows closed, not filtered.
• Predictable interface-naming drift after the systemd 260 upgrade. Patched the .network config to match by MAC. Useful hardening; not the cause.
• Stale GRUB stage1 + core.img in the MBR. Arch never re-runs grub-install after a grub package upgrade. Refreshed it. Still filtered.
• Kernel 7.0.5 regression. Downgraded to 6.18.3, the kernel that had run for 4 months. Still filtered. So the kernel itself wasn’t it either.

The clue was in the persistent journal: a single recorded boot from December 31 to May 12 10:13 UTC, and absolutely nothing after. Every reboot since the upgrade was failing before systemd-journald could flush to disk — so the failure had to be in the initramfs, before the root filesystem was even mounted.

What it almost certainly was

Hetzner Dedicated servers configure the initramfs network with ip=dhcp on the kernel command line. That depends on Hetzner’s DHCP server replying to whatever request format the current kernel sends. Somewhere between kernel 6.18 / iproute2 6.18 and kernel 7.0 / iproute2 7.0, the request format changed enough that Hetzner’s DHCP stopped responding. Effects:

• Old kernel at runtime kept the interface already configured (Phase A — 32 hours of healthy operation after the package upgrade).
• New kernel cold-boots, hits DHCP, never gets an IP, dropbear cannot listen, port 22 stays filtered.

Hetzner’s own documentation has been quietly moving away from ip=dhcp toward static IPv4 in the kernel command line. The fix is exactly that:

GRUB_CMDLINE_LINUX="cryptdevice=/dev/md1:cryptroot ip=A.B.C.D::GATEWAY:255.255.255.255:hostname:eth0:none"

One line in /etc/default/grub, grub-mkconfig, reboot. No more dependency on Hetzner’s DHCP responding to whatever your current kernel sends.

Why it matters for anyone running this stack

If you run Arch on Hetzner Dedicated with full-disk encryption and remote unlock via dropbear, the ip=dhcp shipped by installimage is a latent bug. It can keep working for years and then break overnight, on every machine you have, after a routine pacman -Syyu. The static-IP version is what Hetzner now recommends and removes the entire dependency.

Tooling

While debugging, I turned the whole rescue / chroot / diagnose / fix workflow into a Python CLI (hal) — including hal fix static-ip, which derives the static cmdline directly from your existing systemd-networkd .network file:

→ github.com/kevinveenbirkenbach/hetzner-arch-luks

Single command, idempotent, reversible (the original /etc/default/grub is backed up to .hal-backup). If you’re on this stack, switch to static IP before the next kernel upgrade catches you.

When two Hetzner servers died at the same time

On May 12, 2026, two of my Arch Linux + LUKS servers at Hetzner became unreachable at the same moment. Both had been running for 4+ months without issue. Both had received the same pacman -Syyu the day before, but had stayed on the old kernel until the morning the websites stopped responding. I rebooted — SSH never came back. nmap -Pn -p 22 showed filtered from anywhere. No ping. No banner. The Hetzner Robot panel insisted the hardware was fine.

Several hours went into hypotheses that turned out to be wrong:

• The encryptssh initcpio hook referencing a /usr/lib/initcpio/udev/11-dm-initramfs.rules file that no longer exists. Real bug, no boot impact — the initramfs rebuilds anyway.
• PermitRootLogin no in sshd_config. Real misconfiguration, fixed it, didn’t help. A refusing sshd shows closed, not filtered.
• Predictable interface-naming drift after the systemd 260 upgrade. Patched the .network config to match by MAC. Useful hardening; not the cause.
• Stale GRUB stage1 + core.img in the MBR. Arch never re-runs grub-install after a grub package upgrade. Refreshed it. Still filtered.
• Kernel 7.0.5 regression. Downgraded to 6.18.3, the kernel that had run for 4 months. Still filtered. So the kernel itself wasn’t it either.

The clue was in the persistent journal: a single recorded boot from December 31 to May 12 10:13 UTC, and absolutely nothing after. Every reboot since the upgrade was failing before systemd-journald could flush to disk — so the failure had to be in the initramfs, before the root filesystem was even mounted.

What it almost certainly was

Hetzner Dedicated servers configure the initramfs network with ip=dhcp on the kernel command line. That depends on Hetzner’s DHCP server replying to whatever request format the current kernel sends. Somewhere between kernel 6.18 / iproute2 6.18 and kernel 7.0 / iproute2 7.0, the request format changed enough that Hetzner’s DHCP stopped responding. Effects:

• Old kernel at runtime kept the interface already configured (Phase A — 32 hours of healthy operation after the package upgrade).
• New kernel cold-boots, hits DHCP, never gets an IP, dropbear cannot listen, port 22 stays filtered.

Hetzner’s own documentation has been quietly moving away from ip=dhcp toward static IPv4 in the kernel command line. The fix is exactly that:

GRUB_CMDLINE_LINUX="cryptdevice=/dev/md1:cryptroot ip=A.B.C.D::GATEWAY:255.255.255.255:hostname:eth0:none"

One line in /etc/default/grub, grub-mkconfig, reboot. No more dependency on Hetzner’s DHCP responding to whatever your current kernel sends.

Why it matters for anyone running this stack

If you run Arch on Hetzner Dedicated with full-disk encryption and remote unlock via dropbear, the ip=dhcp shipped by installimage is a latent bug. It can keep working for years and then break overnight, on every machine you have, after a routine pacman -Syyu. The static-IP version is what Hetzner now recommends and removes the entire dependency.

Tooling

While debugging, I turned the whole rescue / chroot / diagnose / fix workflow into a Python CLI (hal) — including hal fix static-ip, which derives the static cmdline directly from your existing systemd-networkd .network file:

→ github.com/kevinveenbirkenbach/hetzner-arch-luks

Single command, idempotent, reversible (the original /etc/default/grub is backed up to .hal-backup). If you’re on this stack, switch to static IP before the next kernel upgrade catches you.

When two Hetzner servers died at the same time

On May 12, 2026, two of my Arch Linux + LUKS servers at Hetzner became unreachable at the same moment. Both had been running for 4+ months without issue. Both had received the same pacman -Syyu the day before, but had stayed on the old kernel until the morning the websites stopped responding. I rebooted — SSH never came back. nmap -Pn -p 22 showed filtered from anywhere. No ping. No banner. The Hetzner Robot panel insisted the hardware was fine.

Several hours went into hypotheses that turned out to be wrong:

• The encryptssh initcpio hook referencing a /usr/lib/initcpio/udev/11-dm-initramfs.rules file that no longer exists. Real bug, no boot impact — the initramfs rebuilds anyway.
• PermitRootLogin no in sshd_config. Real misconfiguration, fixed it, didn’t help. A refusing sshd shows closed, not filtered.
• Predictable interface-naming drift after the systemd 260 upgrade. Patched the .network config to match by MAC. Useful hardening; not the cause.
• Stale GRUB stage1 + core.img in the MBR. Arch never re-runs grub-install after a grub package upgrade. Refreshed it. Still filtered.
• Kernel 7.0.5 regression. Downgraded to 6.18.3, the kernel that had run for 4 months. Still filtered. So the kernel itself wasn’t it either.

The clue was in the persistent journal: a single recorded boot from December 31 to May 12 10:13 UTC, and absolutely nothing after. Every reboot since the upgrade was failing before systemd-journald could flush to disk — so the failure had to be in the initramfs, before the root filesystem was even mounted.

What it almost certainly was

Hetzner Dedicated servers configure the initramfs network with ip=dhcp on the kernel command line. That depends on Hetzner’s DHCP server replying to whatever request format the current kernel sends. Somewhere between kernel 6.18 / iproute2 6.18 and kernel 7.0 / iproute2 7.0, the request format changed enough that Hetzner’s DHCP stopped responding. Effects:

• Old kernel at runtime kept the interface already configured (Phase A — 32 hours of healthy operation after the package upgrade).
• New kernel cold-boots, hits DHCP, never gets an IP, dropbear cannot listen, port 22 stays filtered.

Hetzner’s own documentation has been quietly moving away from ip=dhcp toward static IPv4 in the kernel command line. The fix is exactly that:

GRUB_CMDLINE_LINUX="cryptdevice=/dev/md1:cryptroot ip=A.B.C.D::GATEWAY:255.255.255.255:hostname:eth0:none"

One line in /etc/default/grub, grub-mkconfig, reboot. No more dependency on Hetzner’s DHCP responding to whatever your current kernel sends.

Why it matters for anyone running this stack

If you run Arch on Hetzner Dedicated with full-disk encryption and remote unlock via dropbear, the ip=dhcp shipped by installimage is a latent bug. It can keep working for years and then break overnight, on every machine you have, after a routine pacman -Syyu. The static-IP version is what Hetzner now recommends and removes the entire dependency.

Tooling

While debugging, I turned the whole rescue / chroot / diagnose / fix workflow into a Python CLI (hal) — including hal fix static-ip, which derives the static cmdline directly from your existing systemd-networkd .network file:

→ github.com/kevinveenbirkenbach/hetzner-arch-luks

Single command, idempotent, reversible (the original /etc/default/grub is backed up to .hal-backup). If you’re on this stack, switch to static IP before the next kernel upgrade catches you.

When two Hetzner servers died at the same time

On May 12, 2026, two of my Arch Linux + LUKS servers at Hetzner became unreachable at the same moment. Both had been running for 4+ months without issue. Both had received the same pacman -Syyu the day before, but had stayed on the old kernel until the morning the websites stopped responding. I rebooted — SSH never came back. nmap -Pn -p 22 showed filtered from anywhere. No ping. No banner. The Hetzner Robot panel insisted the hardware was fine.

Several hours went into hypotheses that turned out to be wrong:

• The encryptssh initcpio hook referencing a /usr/lib/initcpio/udev/11-dm-initramfs.rules file that no longer exists. Real bug, no boot impact — the initramfs rebuilds anyway.
• PermitRootLogin no in sshd_config. Real misconfiguration, fixed it, didn’t help. A refusing sshd shows closed, not filtered.
• Predictable interface-naming drift after the systemd 260 upgrade. Patched the .network config to match by MAC. Useful hardening; not the cause.
• Stale GRUB stage1 + core.img in the MBR. Arch never re-runs grub-install after a grub package upgrade. Refreshed it. Still filtered.
• Kernel 7.0.5 regression. Downgraded to 6.18.3, the kernel that had run for 4 months. Still filtered. So the kernel itself wasn’t it either.

The clue was in the persistent journal: a single recorded boot from December 31 to May 12 10:13 UTC, and absolutely nothing after. Every reboot since the upgrade was failing before systemd-journald could flush to disk — so the failure had to be in the initramfs, before the root filesystem was even mounted.

What it almost certainly was

Hetzner Dedicated servers configure the initramfs network with ip=dhcp on the kernel command line. That depends on Hetzner’s DHCP server replying to whatever request format the current kernel sends. Somewhere between kernel 6.18 / iproute2 6.18 and kernel 7.0 / iproute2 7.0, the request format changed enough that Hetzner’s DHCP stopped responding. Effects:

• Old kernel at runtime kept the interface already configured (Phase A — 32 hours of healthy operation after the package upgrade).
• New kernel cold-boots, hits DHCP, never gets an IP, dropbear cannot listen, port 22 stays filtered.

Hetzner’s own documentation has been quietly moving away from ip=dhcp toward static IPv4 in the kernel command line. The fix is exactly that:

GRUB_CMDLINE_LINUX="cryptdevice=/dev/md1:cryptroot ip=A.B.C.D::GATEWAY:255.255.255.255:hostname:eth0:none"

One line in /etc/default/grub, grub-mkconfig, reboot. No more dependency on Hetzner’s DHCP responding to whatever your current kernel sends.

Why it matters for anyone running this stack

If you run Arch on Hetzner Dedicated with full-disk encryption and remote unlock via dropbear, the ip=dhcp shipped by installimage is a latent bug. It can keep working for years and then break overnight, on every machine you have, after a routine pacman -Syyu. The static-IP version is what Hetzner now recommends and removes the entire dependency.

Tooling

While debugging, I turned the whole rescue / chroot / diagnose / fix workflow into a Python CLI (hal) — including hal fix static-ip, which derives the static cmdline directly from your existing systemd-networkd .network file:

→ github.com/kevinveenbirkenbach/hetzner-arch-luks

Single command, idempotent, reversible (the original /etc/default/grub is backed up to .hal-backup). If you’re on this stack, switch to static IP before the next kernel upgrade catches you.

When two Hetzner servers died at the same time

On May 12, 2026, two of my Arch Linux + LUKS servers at Hetzner became unreachable at the same moment. Both had been running for 4+ months without issue. Both had received the same pacman -Syyu the day before, but had stayed on the old kernel until the morning the websites stopped responding. I rebooted — SSH never came back. nmap -Pn -p 22 showed filtered from anywhere. No ping. No banner. The Hetzner Robot panel insisted the hardware was fine.

Several hours went into hypotheses that turned out to be wrong:

• The encryptssh initcpio hook referencing a /usr/lib/initcpio/udev/11-dm-initramfs.rules file that no longer exists. Real bug, no boot impact — the initramfs rebuilds anyway.
• PermitRootLogin no in sshd_config. Real misconfiguration, fixed it, didn’t help. A refusing sshd shows closed, not filtered.
• Predictable interface-naming drift after the systemd 260 upgrade. Patched the .network config to match by MAC. Useful hardening; not the cause.
• Stale GRUB stage1 + core.img in the MBR. Arch never re-runs grub-install after a grub package upgrade. Refreshed it. Still filtered.
• Kernel 7.0.5 regression. Downgraded to 6.18.3, the kernel that had run for 4 months. Still filtered. So the kernel itself wasn’t it either.

The clue was in the persistent journal: a single recorded boot from December 31 to May 12 10:13 UTC, and absolutely nothing after. Every reboot since the upgrade was failing before systemd-journald could flush to disk — so the failure had to be in the initramfs, before the root filesystem was even mounted.

What it almost certainly was

Hetzner Dedicated servers configure the initramfs network with ip=dhcp on the kernel command line. That depends on Hetzner’s DHCP server replying to whatever request format the current kernel sends. Somewhere between kernel 6.18 / iproute2 6.18 and kernel 7.0 / iproute2 7.0, the request format changed enough that Hetzner’s DHCP stopped responding. Effects:

• Old kernel at runtime kept the interface already configured (Phase A — 32 hours of healthy operation after the package upgrade).
• New kernel cold-boots, hits DHCP, never gets an IP, dropbear cannot listen, port 22 stays filtered.

Hetzner’s own documentation has been quietly moving away from ip=dhcp toward static IPv4 in the kernel command line. The fix is exactly that:

GRUB_CMDLINE_LINUX="cryptdevice=/dev/md1:cryptroot ip=A.B.C.D::GATEWAY:255.255.255.255:hostname:eth0:none"

One line in /etc/default/grub, grub-mkconfig, reboot. No more dependency on Hetzner’s DHCP responding to whatever your current kernel sends.

Why it matters for anyone running this stack

If you run Arch on Hetzner Dedicated with full-disk encryption and remote unlock via dropbear, the ip=dhcp shipped by installimage is a latent bug. It can keep working for years and then break overnight, on every machine you have, after a routine pacman -Syyu. The static-IP version is what Hetzner now recommends and removes the entire dependency.

Tooling

While debugging, I turned the whole rescue / chroot / diagnose / fix workflow into a Python CLI (hal) — including hal fix static-ip, which derives the static cmdline directly from your existing systemd-networkd .network file:

→ github.com/kevinveenbirkenbach/hetzner-arch-luks

Single command, idempotent, reversible (the original /etc/default/grub is backed up to .hal-backup). If you’re on this stack, switch to static IP before the next kernel upgrade catches you.

2/2 This blog post (hosted on said solution) gives some more details about the usage: https://pelle.io/posts/solidblocks-cloud-s3/. Given the included 20 TB of traffic on Hetzner, this makes it an attractive alternative to avoid the high egress fees of AWS S3 buckets.

#hetzner #cloud #linux #eu #did

1/2 In my ongoing quest to replace AWS with a simple YAML file (nearly there 😀), I added a new feature to Solidblocks Cloud to quickly deploy an S3 service to a Hetzner Cloud VM to host public static websites that can be deployed with any S3-compatible client.

#hetzner #cloud #linux #eu #did

I read so many good things from #nextcloud , i'm even tempted to move from my local #synology to an instance at #hetzner

Only things that are in the way are:
- I like the idea that my data is at home (well at least 1 copy)
- Migration of all data (will take long)
- Config of clients (family's devices)
- Cost, because hosting everything remotely might anyway be expensive

lg vom diday, brought to you by #hetzner #schland 🇧🇪

Looking for #S3 provider in EU.
#Scaleway or #Hetzner ?

Any other recommendations?

Finding the best server deals from the terminal! 🔥

💰 **hzfind** — A TUI for Hetzner auction deals

💯 Compare servers by CPU/€, RAM/€, storage/€ with live data + benchmarks

🦀 Written in Rust & built with @ratatui_rs

⭐ GitHub: https://github.com/clouedoc/hzfind

#rustlang #ratatui #tui #hetzner #auction #servers #cloud #terminal

To clarify cloud-init works when manually ran but on boot there’s a race condition where the network isn’t fully up #cloudinit #freebsd #hetzner #runbsd #sre #cloud

Wrote another blog post about my fun trying to get #cloudinit to work on #freebsd running in #hetzner

If anyone has any cool ideas I’m open to suggestions

https://bev.is/posts/2026-04-22-freebsd-on-hetzner-2-cloud-init-boogaloo/

#runbsd #sre #cloud

#Migrating from #DigitalOcean to #Hetzner: From $1,432 to $233/month With #ZeroDowntime

https://isayeter.com/posts/digitalocean-to-hetzner-migration/

#Migrating from #DigitalOcean to #Hetzner: From $1,432 to $233/month With #ZeroDowntime

https://isayeter.com/posts/digitalocean-to-hetzner-migration/

#Migrating from #DigitalOcean to #Hetzner: From $1,432 to $233/month With #ZeroDowntime

https://isayeter.com/posts/digitalocean-to-hetzner-migration/

#Migrating from #DigitalOcean to #Hetzner: From $1,432 to $233/month With #ZeroDowntime

https://isayeter.com/posts/digitalocean-to-hetzner-migration/

#Migrating from #DigitalOcean to #Hetzner: From $1,432 to $233/month With #ZeroDowntime

https://isayeter.com/posts/digitalocean-to-hetzner-migration/

Migrating from DigitalOcean to Hetzner: From $1,432 to $233 With Zero Downtime

https://isayeter.com/posts/digitalocean-to-hetzner-migration/

#HackerNews #migratingservers #cloudmigration #digitalocean #hetzner #costreduction #devops

There is a package for #Caddy reverse proxy for obtaining certificates using DNS challenge through #Hetzner's new Cloud API.

https://github.com/caddy-dns/hetzner

#homelab #reverseproxy #selfhosted #selfhosting #selfhost #ssl

Direct IPv6 peering with @hetzner in Frankfurt for my AS201379 🥳 🥳

That's amazing! What a nice short path...

#networking #bgp #peering #hetzner #ixp #ipv6 #freebsd

@ironicbadger I use #ProxmoxBackup for virtual machines, containers and desktops. Datasets are mirrored locally and separated on different floors. The third mirror is offsite encrypted on a #hetzner #objectstorage in Europe.

Grafana-Ablösung – Monitoring in Home Assistant

https://www.myhome.zone/grafana-abloesung-monitoring-in-home-assistant/

Grafana-Ablösung – Monitoring in Home Assistant

https://www.myhome.zone/grafana-abloesung-monitoring-in-home-assistant/

Grafana-Ablösung – Monitoring in Home Assistant

https://www.myhome.zone/grafana-abloesung-monitoring-in-home-assistant/

Grafana-Ablösung – Monitoring in Home Assistant

https://www.myhome.zone/grafana-abloesung-monitoring-in-home-assistant/

Grafana-Ablösung – Monitoring in Home Assistant

https://www.myhome.zone/grafana-abloesung-monitoring-in-home-assistant/

I installed #Mattermost on the cheapest #Hetzner cloud server. I found it to be quite similar to #Slack, with a much more intuitive UI than #RocketChat. So far, it's working perfectly.

All of these solutions are much better than #Teams, which I find terrible for written communication.

Does anyone here have experience of self-hosting Mattermost, and what are the costs? How many users? Did you use a dedicated server?

I also considered comparing it to #Matrix, but I don't think it's quite there yet in terms of UI for non-tech-savvy people.

#OpenSource

Läuft! Das war, alles in allem, dann doch recht einfach. Nun kann der Umzug vom alten #rootServer zum Hetzner Server weiter gehen.
Die Zwischenlösung mit dem #Cloudserver kann nach dem Daten-Cleanup dann in die Tonne.

Bevor dann ab 01.04. die Preiserhöhung bei #Hetzner greift.

【为什么 Hetzner 不适合Tor🧅出口节点】
https://www.reddit.com/r/TOR/comments/1m9yssc/why_hetzner_is_not_suitable_for_exit_nodes

Hetzner禁止扫描外网——Tor 出口流量来自运行出口节点的服务器——用户活动包括端口扫描和探测——违反条款——收到滥用报告

所以办法是只运行中继和网桥，而不运行出口节点：
✅ Middle Relay ✅ obfs4 Bridge ✅ Snowflake ✅ WebTunnel
❌ Exit Node

#tor #hetzner #exitnode #OnionServices #onionnetwork #洋葱网络

As Hetzner is deprecating dns configuration via the dns-console, I migrated my domains to the new Cloud API. Last piece of the puzzle was to create new tokens and move from the old cert-manager-webhook-hetzner (by vadimkim) to the official chart maintained by Hetzner.

Migrated my 7 kubernetes clusters (k3s, rke2, OpenShift) without major hiccups, only had to do some cleanup due to old acme challenge entries being leftover after the migration (as cert-manager could not remove them without the new webhook and API token).

Only things left are the machines without k3s using lego.

#homelab #hetzner #certmanager #dns #hellyeah #kubernetes #k3s #rke2

Thinkpad #X230 of 2013 (gift from friend),
#apple #imac 18.2 of 2017 (350 euros 64 Gb RAM 27" Retina display) ,
#hetzner CX43 #vm (10 euros per month) online server,
#Supermicro (SM in table on right) X11-WTR SYS-5019P-WTR #Xeon Silver 4110 × 16 (basic parts 500 euros 2nd hand)
CPU comparisons using #hardinfo2 #benchmarking #homelab

Thinkpad #X230 of 2013 (gift from friend),
#apple #imac 18.2 of 2017 (350 euros 64 Gb RAM 27" Retina display) ,
#hetzner CX43 #vm (10 euros per month) online server,
#Supermicro (SM in table on right) X11-WTR SYS-5019P-WTR #Xeon Silver 4110 × 16 (basic parts 500 euros 2nd hand)
CPU comparisons using #hardinfo2 #benchmarking #homelab

Thinkpad #X230 of 2013 (gift from friend),
#apple #imac 18.2 of 2017 (350 euros 64 Gb RAM 27" Retina display) ,
#hetzner CX43 #vm (10 euros per month) online server,
#Supermicro (SM in table on right) X11-WTR SYS-5019P-WTR #Xeon Silver 4110 × 16 (basic parts 500 euros 2nd hand)
CPU comparisons using #hardinfo2 #benchmarking #homelab

Thinkpad #X230 of 2013 (gift from friend),
#apple #imac 18.2 of 2017 (350 euros 64 Gb RAM 27" Retina display) ,
#hetzner CX43 #vm (10 euros per month) online server,
#Supermicro (SM in table on right) X11-WTR SYS-5019P-WTR #Xeon Silver 4110 × 16 (basic parts 500 euros 2nd hand)
CPU comparisons using #hardinfo2 #benchmarking #homelab

Thinkpad #X230 of 2013 (gift from friend),
#apple #imac 18.2 of 2017 (350 euros 64 Gb RAM 27" Retina display) ,
#hetzner CX43 #vm (10 euros per month) online server,
#Supermicro (SM in table on right) X11-WTR SYS-5019P-WTR #Xeon Silver 4110 × 16 (basic parts 500 euros 2nd hand)
CPU comparisons using #hardinfo2 #benchmarking #homelab

3 Occitanie-based #CyberSecurity & #SelfHosted peers.
#DigitalSovereignty #FrenchTech #Occitanie #ExpatLife #StrategicAutonomy

Français:
Installation prévue en Occitanie (65/31) pour 2027 sous le régime Passeport Talent. 🇫🇷🛠️
Création d'une filiale de services IT basée sur une "Sovereign Stack" : #Hetzner (Finlande), #Forgejo et #MinIO. Approche "manuelle et cloisonnée", conforme à l'EU Data Act 2026, garantissant une souveraineté numérique totale hors cloud américain. (2/3)

Die zerbrechlichen Ketten der Bequemlichkeit

Ein Plädoyer für die digitale Emanzipation Europas

Wir haben unsere digitale Freiheit gegen Komfort eingetauscht. Microsoft, Amazon, Google und Meta bestimmen, wie wir kommunizieren, arbeiten und denken. Der CrowdStrike-Schock war kein Unglück, er war eine Ansage. Es ist Zeit, die Ketten zu sprengen. Ein Plädoyer für die digitale Emanzipation Europas. [Mehr lesen...]

christin-loehner.de/blog/die-z…

#DigitaleSouveränität #DigitalSovereignty #Linux #OpenSource #FOSS #FreieSoftware #Datenschutz #Privacy #BigTech #FuckBigTech #DeGoogle #DeleteGoogle #DeleteFacebook #BoycottAmazon #BoycottMicrosoft #BoycottApple #Überwachungskapitalismus #SurveillanceCapitalism #Fediverse #Mastodon #Dezentralisierung #Decentralization #PublicMoneyPublicCode #ÖffentlichesGeld #RightToRepair #Fairphone #Framework #SelfHosted #Nextcloud #Signal #Tor #VPN #CrowdStrike #CloudAct #DSGVO #GDPR #Hetzner #EuropeFirst #TechSovereignty #DigitalRights #DigitaleRechte #Netzpolitik #CCC #ChaosComputerClub #ByeByeElon #QuitX #LeaveX #SaveSocial #Ecosia #Startpage #uBlockOrigin #LibreWolf #Firefox #FediTips #EuropäischeWerte #EuropeanValues #TechEthics #Nachhaltigkeit #Sustainability #GeplantéObsoleszenz #PlannedObsolescence #KaufLokal #LocalFirst #Widerstand #DigitalResistance #PolitischeTech #TechForGood #KI #AI #OpenSourceAI #ZenDiS #PublicCode #Libre #GNU #Debian #Fedora #PopOS #ZorinOS #NixOS #AntiColonialism #DigitalerKolonialismus #Cloudflare #AWS #AzureAlternative #EUTech #MadeInEurope

Die zerbrechlichen Ketten der Bequemlichkeit

Ein Plädoyer für die digitale Emanzipation Europas

Wir haben unsere digitale Freiheit gegen Komfort eingetauscht. Microsoft, Amazon, Google und Meta bestimmen, wie wir kommunizieren, arbeiten und denken. Der CrowdStrike-Schock war kein Unglück, er war eine Ansage. Es ist Zeit, die Ketten zu sprengen. Ein Plädoyer für die digitale Emanzipation Europas. [Mehr lesen...]

christin-loehner.de/blog/die-z…

#DigitaleSouveränität #DigitalSovereignty #Linux #OpenSource #FOSS #FreieSoftware #Datenschutz #Privacy #BigTech #FuckBigTech #DeGoogle #DeleteGoogle #DeleteFacebook #BoycottAmazon #BoycottMicrosoft #BoycottApple #Überwachungskapitalismus #SurveillanceCapitalism #Fediverse #Mastodon #Dezentralisierung #Decentralization #PublicMoneyPublicCode #ÖffentlichesGeld #RightToRepair #Fairphone #Framework #SelfHosted #Nextcloud #Signal #Tor #VPN #CrowdStrike #CloudAct #DSGVO #GDPR #Hetzner #EuropeFirst #TechSovereignty #DigitalRights #DigitaleRechte #Netzpolitik #CCC #ChaosComputerClub #ByeByeElon #QuitX #LeaveX #SaveSocial #Ecosia #Startpage #uBlockOrigin #LibreWolf #Firefox #FediTips #EuropäischeWerte #EuropeanValues #TechEthics #Nachhaltigkeit #Sustainability #GeplantéObsoleszenz #PlannedObsolescence #KaufLokal #LocalFirst #Widerstand #DigitalResistance #PolitischeTech #TechForGood #KI #AI #OpenSourceAI #ZenDiS #PublicCode #Libre #GNU #Debian #Fedora #PopOS #ZorinOS #NixOS #AntiColonialism #DigitalerKolonialismus #Cloudflare #AWS #AzureAlternative #EUTech #MadeInEurope

Die zerbrechlichen Ketten der Bequemlichkeit

Ein Plädoyer für die digitale Emanzipation Europas

Wir haben unsere digitale Freiheit gegen Komfort eingetauscht. Microsoft, Amazon, Google und Meta bestimmen, wie wir kommunizieren, arbeiten und denken. Der CrowdStrike-Schock war kein Unglück, er war eine Ansage. Es ist Zeit, die Ketten zu sprengen. Ein Plädoyer für die digitale Emanzipation Europas. [Mehr lesen...]

christin-loehner.de/blog/die-z…

#DigitaleSouveränität #DigitalSovereignty #Linux #OpenSource #FOSS #FreieSoftware #Datenschutz #Privacy #BigTech #FuckBigTech #DeGoogle #DeleteGoogle #DeleteFacebook #BoycottAmazon #BoycottMicrosoft #BoycottApple #Überwachungskapitalismus #SurveillanceCapitalism #Fediverse #Mastodon #Dezentralisierung #Decentralization #PublicMoneyPublicCode #ÖffentlichesGeld #RightToRepair #Fairphone #Framework #SelfHosted #Nextcloud #Signal #Tor #VPN #CrowdStrike #CloudAct #DSGVO #GDPR #Hetzner #EuropeFirst #TechSovereignty #DigitalRights #DigitaleRechte #Netzpolitik #CCC #ChaosComputerClub #ByeByeElon #QuitX #LeaveX #SaveSocial #Ecosia #Startpage #uBlockOrigin #LibreWolf #Firefox #FediTips #EuropäischeWerte #EuropeanValues #TechEthics #Nachhaltigkeit #Sustainability #GeplantéObsoleszenz #PlannedObsolescence #KaufLokal #LocalFirst #Widerstand #DigitalResistance #PolitischeTech #TechForGood #KI #AI #OpenSourceAI #ZenDiS #PublicCode #Libre #GNU #Debian #Fedora #PopOS #ZorinOS #NixOS #AntiColonialism #DigitalerKolonialismus #Cloudflare #AWS #AzureAlternative #EUTech #MadeInEurope

Die zerbrechlichen Ketten der Bequemlichkeit

Ein Plädoyer für die digitale Emanzipation Europas

Wir haben unsere digitale Freiheit gegen Komfort eingetauscht. Microsoft, Amazon, Google und Meta bestimmen, wie wir kommunizieren, arbeiten und denken. Der CrowdStrike-Schock war kein Unglück, er war eine Ansage. Es ist Zeit, die Ketten zu sprengen. Ein Plädoyer für die digitale Emanzipation Europas. [Mehr lesen...]

christin-loehner.de/blog/die-z…

#DigitaleSouveränität #DigitalSovereignty #Linux #OpenSource #FOSS #FreieSoftware #Datenschutz #Privacy #BigTech #FuckBigTech #DeGoogle #DeleteGoogle #DeleteFacebook #BoycottAmazon #BoycottMicrosoft #BoycottApple #Überwachungskapitalismus #SurveillanceCapitalism #Fediverse #Mastodon #Dezentralisierung #Decentralization #PublicMoneyPublicCode #ÖffentlichesGeld #RightToRepair #Fairphone #Framework #SelfHosted #Nextcloud #Signal #Tor #VPN #CrowdStrike #CloudAct #DSGVO #GDPR #Hetzner #EuropeFirst #TechSovereignty #DigitalRights #DigitaleRechte #Netzpolitik #CCC #ChaosComputerClub #ByeByeElon #QuitX #LeaveX #SaveSocial #Ecosia #Startpage #uBlockOrigin #LibreWolf #Firefox #FediTips #EuropäischeWerte #EuropeanValues #TechEthics #Nachhaltigkeit #Sustainability #GeplantéObsoleszenz #PlannedObsolescence #KaufLokal #LocalFirst #Widerstand #DigitalResistance #PolitischeTech #TechForGood #KI #AI #OpenSourceAI #ZenDiS #PublicCode #Libre #GNU #Debian #Fedora #PopOS #ZorinOS #NixOS #AntiColonialism #DigitalerKolonialismus #Cloudflare #AWS #AzureAlternative #EUTech #MadeInEurope

Die zerbrechlichen Ketten der Bequemlichkeit

Ein Plädoyer für die digitale Emanzipation Europas

Wir haben unsere digitale Freiheit gegen Komfort eingetauscht. Microsoft, Amazon, Google und Meta bestimmen, wie wir kommunizieren, arbeiten und denken. Der CrowdStrike-Schock war kein Unglück, er war eine Ansage. Es ist Zeit, die Ketten zu sprengen. Ein Plädoyer für die digitale Emanzipation Europas. [Mehr lesen...]

https://www.christin-loehner.de/blog/die-zerbrechlichen-ketten-der-bequemlichkeit

#DigitaleSouveränität #DigitalSovereignty #Linux #OpenSource #FOSS #FreieSoftware #Datenschutz #Privacy #BigTech #FuckBigTech #DeGoogle #DeleteGoogle #DeleteFacebook #BoycottAmazon #BoycottMicrosoft #BoycottApple #Überwachungskapitalismus #SurveillanceCapitalism #Fediverse #Mastodon #Dezentralisierung #Decentralization #PublicMoneyPublicCode #ÖffentlichesGeld #RightToRepair #Fairphone #Framework #SelfHosted #Nextcloud #Signal #Tor #VPN #CrowdStrike #CloudAct #DSGVO #GDPR #Hetzner #EuropeFirst #TechSovereignty #DigitalRights #DigitaleRechte #Netzpolitik #CCC #ChaosComputerClub #ByeByeElon #QuitX #LeaveX #SaveSocial #Ecosia #Startpage #uBlockOrigin #LibreWolf #Firefox #FediTips #EuropäischeWerte #EuropeanValues #TechEthics #Nachhaltigkeit #Sustainability #GeplantéObsoleszenz #PlannedObsolescence #KaufLokal #LocalFirst #Widerstand #DigitalResistance #PolitischeTech #TechForGood #KI #AI #OpenSourceAI #ZenDiS #PublicCode #Libre #GNU #Debian #Fedora #PopOS #ZorinOS #NixOS #AntiColonialism #DigitalerKolonialismus #Cloudflare #AWS #AzureAlternative #EUTech #MadeInEurope

Die zerbrechlichen Ketten der Bequemlichkeit

Ein Plädoyer für die digitale Emanzipation Europas

Wir haben unsere digitale Freiheit gegen Komfort eingetauscht. Microsoft, Amazon, Google und Meta bestimmen, wie wir kommunizieren, arbeiten und denken. Der CrowdStrike-Schock war kein Unglück, er war eine Ansage. Es ist Zeit, die Ketten zu sprengen. Ein Plädoyer für die digitale Emanzipation Europas. [Mehr lesen...]

https://www.christin-loehner.de/blog/die-zerbrechlichen-ketten-der-bequemlichkeit

#DigitaleSouveränität #DigitalSovereignty #Linux #OpenSource #FOSS #FreieSoftware #Datenschutz #Privacy #BigTech #FuckBigTech #DeGoogle #DeleteGoogle #DeleteFacebook #BoycottAmazon #BoycottMicrosoft #BoycottApple #Überwachungskapitalismus #SurveillanceCapitalism #Fediverse #Mastodon #Dezentralisierung #Decentralization #PublicMoneyPublicCode #ÖffentlichesGeld #RightToRepair #Fairphone #Framework #SelfHosted #Nextcloud #Signal #Tor #VPN #CrowdStrike #CloudAct #DSGVO #GDPR #Hetzner #EuropeFirst #TechSovereignty #DigitalRights #DigitaleRechte #Netzpolitik #CCC #ChaosComputerClub #ByeByeElon #QuitX #LeaveX #SaveSocial #Ecosia #Startpage #uBlockOrigin #LibreWolf #Firefox #FediTips #EuropäischeWerte #EuropeanValues #TechEthics #Nachhaltigkeit #Sustainability #GeplantéObsoleszenz #PlannedObsolescence #KaufLokal #LocalFirst #Widerstand #DigitalResistance #PolitischeTech #TechForGood #KI #AI #OpenSourceAI #ZenDiS #PublicCode #Libre #GNU #Debian #Fedora #PopOS #ZorinOS #NixOS #AntiColonialism #DigitalerKolonialismus #Cloudflare #AWS #AzureAlternative #EUTech #MadeInEurope

Die zerbrechlichen Ketten der Bequemlichkeit

Ein Plädoyer für die digitale Emanzipation Europas

Wir haben unsere digitale Freiheit gegen Komfort eingetauscht. Microsoft, Amazon, Google und Meta bestimmen, wie wir kommunizieren, arbeiten und denken. Der CrowdStrike-Schock war kein Unglück, er war eine Ansage. Es ist Zeit, die Ketten zu sprengen. Ein Plädoyer für die digitale Emanzipation Europas. [Mehr lesen...]

https://www.christin-loehner.de/blog/die-zerbrechlichen-ketten-der-bequemlichkeit

#DigitaleSouveränität #DigitalSovereignty #Linux #OpenSource #FOSS #FreieSoftware #Datenschutz #Privacy #BigTech #FuckBigTech #DeGoogle #DeleteGoogle #DeleteFacebook #BoycottAmazon #BoycottMicrosoft #BoycottApple #Überwachungskapitalismus #SurveillanceCapitalism #Fediverse #Mastodon #Dezentralisierung #Decentralization #PublicMoneyPublicCode #ÖffentlichesGeld #RightToRepair #Fairphone #Framework #SelfHosted #Nextcloud #Signal #Tor #VPN #CrowdStrike #CloudAct #DSGVO #GDPR #Hetzner #EuropeFirst #TechSovereignty #DigitalRights #DigitaleRechte #Netzpolitik #CCC #ChaosComputerClub #ByeByeElon #QuitX #LeaveX #SaveSocial #Ecosia #Startpage #uBlockOrigin #LibreWolf #Firefox #FediTips #EuropäischeWerte #EuropeanValues #TechEthics #Nachhaltigkeit #Sustainability #GeplantéObsoleszenz #PlannedObsolescence #KaufLokal #LocalFirst #Widerstand #DigitalResistance #PolitischeTech #TechForGood #KI #AI #OpenSourceAI #ZenDiS #PublicCode #Libre #GNU #Debian #Fedora #PopOS #ZorinOS #NixOS #AntiColonialism #DigitalerKolonialismus #Cloudflare #AWS #AzureAlternative #EUTech #MadeInEurope

Die zerbrechlichen Ketten der Bequemlichkeit

Ein Plädoyer für die digitale Emanzipation Europas

Wir haben unsere digitale Freiheit gegen Komfort eingetauscht. Microsoft, Amazon, Google und Meta bestimmen, wie wir kommunizieren, arbeiten und denken. Der CrowdStrike-Schock war kein Unglück, er war eine Ansage. Es ist Zeit, die Ketten zu sprengen. Ein Plädoyer für die digitale Emanzipation Europas. [Mehr lesen...]

https://www.christin-loehner.de/blog/die-zerbrechlichen-ketten-der-bequemlichkeit

#DigitaleSouveränität #DigitalSovereignty #Linux #OpenSource #FOSS #FreieSoftware #Datenschutz #Privacy #BigTech #FuckBigTech #DeGoogle #DeleteGoogle #DeleteFacebook #BoycottAmazon #BoycottMicrosoft #BoycottApple #Überwachungskapitalismus #SurveillanceCapitalism #Fediverse #Mastodon #Dezentralisierung #Decentralization #PublicMoneyPublicCode #ÖffentlichesGeld #RightToRepair #Fairphone #Framework #SelfHosted #Nextcloud #Signal #Tor #VPN #CrowdStrike #CloudAct #DSGVO #GDPR #Hetzner #EuropeFirst #TechSovereignty #DigitalRights #DigitaleRechte #Netzpolitik #CCC #ChaosComputerClub #ByeByeElon #QuitX #LeaveX #SaveSocial #Ecosia #Startpage #uBlockOrigin #LibreWolf #Firefox #FediTips #EuropäischeWerte #EuropeanValues #TechEthics #Nachhaltigkeit #Sustainability #GeplantéObsoleszenz #PlannedObsolescence #KaufLokal #LocalFirst #Widerstand #DigitalResistance #PolitischeTech #TechForGood #KI #AI #OpenSourceAI #ZenDiS #PublicCode #Libre #GNU #Debian #Fedora #PopOS #ZorinOS #NixOS #AntiColonialism #DigitalerKolonialismus #Cloudflare #AWS #AzureAlternative #EUTech #MadeInEurope

Die zerbrechlichen Ketten der Bequemlichkeit

Ein Plädoyer für die digitale Emanzipation Europas

Wir haben unsere digitale Freiheit gegen Komfort eingetauscht. Microsoft, Amazon, Google und Meta bestimmen, wie wir kommunizieren, arbeiten und denken. Der CrowdStrike-Schock war kein Unglück, er war eine Ansage. Es ist Zeit, die Ketten zu sprengen. Ein Plädoyer für die digitale Emanzipation Europas. [Mehr lesen...]

https://www.christin-loehner.de/blog/die-zerbrechlichen-ketten-der-bequemlichkeit

#DigitaleSouveränität #DigitalSovereignty #Linux #OpenSource #FOSS #FreieSoftware #Datenschutz #Privacy #BigTech #FuckBigTech #DeGoogle #DeleteGoogle #DeleteFacebook #BoycottAmazon #BoycottMicrosoft #BoycottApple #Überwachungskapitalismus #SurveillanceCapitalism #Fediverse #Mastodon #Dezentralisierung #Decentralization #PublicMoneyPublicCode #ÖffentlichesGeld #RightToRepair #Fairphone #Framework #SelfHosted #Nextcloud #Signal #Tor #VPN #CrowdStrike #CloudAct #DSGVO #GDPR #Hetzner #EuropeFirst #TechSovereignty #DigitalRights #DigitaleRechte #Netzpolitik #CCC #ChaosComputerClub #ByeByeElon #QuitX #LeaveX #SaveSocial #Ecosia #Startpage #uBlockOrigin #LibreWolf #Firefox #FediTips #EuropäischeWerte #EuropeanValues #TechEthics #Nachhaltigkeit #Sustainability #GeplantéObsoleszenz #PlannedObsolescence #KaufLokal #LocalFirst #Widerstand #DigitalResistance #PolitischeTech #TechForGood #KI #AI #OpenSourceAI #ZenDiS #PublicCode #Libre #GNU #Debian #Fedora #PopOS #ZorinOS #NixOS #AntiColonialism #DigitalerKolonialismus #Cloudflare #AWS #AzureAlternative #EUTech #MadeInEurope

@dnkrupinski Moin. Guck mal in den Spam-Ordner, war bei mir auch dort gelandet, weil #Hetzner scheinbar keine Ahnung vom Setzen der richtigen DNS Einstellungen (#SPF, #DKIM, #DMARC usw.) hat. Scann mal die Domain bei mxtoolbox.com … Für so einen großen #Provider ist das echt lächerlich!

Wochenrückblick, Ausgabe 131 (2026-09)

Themen:

🚵‍♂️ 3× kurz: Kurze Gravelrunde, kurzes Trikot, kurze Hosen

🐗 Frühling bedeutet: Wildschweine sind wieder im Garten unterwegs 🤦‍♂️

💸 Hetzner erhöht Preise drastisch

🗺️ Bikerouter: Pseudo-Tags jetzt für ganz Europa

🐚 CLI-Tool der Woche: ts fügt einer Ausgabe Zeitstempel hinzu

🇪🇺 EU-Flagge statt US-Flagge für den Sprachumschalter

🔊 In dieser Woche gehört: bovt, Marnix Mulder, Wanda Wild

#Wochenrückblick #Hetzner #Bikerouter #Airport #Flughafen #Flugzeug #Condor #Garten #Wildschweine #Fuchs #Hühner #Blog #CLI #ts #Timestamp #CliToolDerWoche #Techno

https://www.marcusjaschen.de/blog/2026/2026-09/

Am 28.02. habe ich „aus Gründen“ meinen #Hetzner #S3 #Objektspeicher gekündigt. Die haben es einfach mit ihrer Preiserhöhung übertrieben! #IONOS bleibt hoffentlich im erträglichen Rahmen, wenn es denn unbedingt sein muss … bin gespannt! #did #provider

I've been a little rough and irresponsible with my #baremetal #Kubernetes cluster, especially when it comes to randomly rebooting nodes. Today I fixed that.

I'm running a bunch of somewhat delicate workloads, including database clusters with CSIs like #Longhorn and #OpenEBS. Checking if everything is in working order has been demanding task and often something I've skipped before rebooting or upgrading nodes - occasionally with horrific results.

Last night I finally took the time and wrote a pretty thorough script that checks that everything is working and healthy, before politely cordoning off a node, draining it and applying upgrades.

I felt so confident today that I tested it by running this new safe upgrade script for all the nodes in the cluster - and it worked! All nodes are now fully upgraded and running kernel 6.12.73 on Debian 13.

This also fixes the outstanding issue caused by #Hetzner no longer supporting obtaining IP addresses through DHCP.

#Linux #MSTDNDK #K8s