Seit 28.01.2026, kausaliert durch EU-NIS2-Richtlinie.
https://blog.denic.de/neue-gesetzgeb…nabfrage-whois/
Danke 
Ja gut, Netcup fragt halt nicht, ob natürliche oder juristische Person. Gewerblicher Account ist scheinbar automatisch juristische Person. Datenschutzrechtlich fragwürdig, aber ich sage ja immer, dass auch sowas eine bewusste Entscheidung ist und man mit den Konsequenzen leben können muss, wenn man sowas macht. 
Wenn man als natürliche Person, welche gewerbetreibend ist, ein Geschäftskundenkonto hier bei Netcup hat, meldet Netcup einen als juristische Person bei der DENIC. Und die DENIC veröffentlicht die Domaininhaber-Daten im WebWhois, wenn der Domaininhaber eine juristische Person ist.
Das ist natürlich auch wieder genial... war das schon immer so? Mir ist es jetzt erst aufgefallen, weil meine bei Netcup hinterlegte Mailadresse kräftig Spam erhält.
Also die Flexibilität hinsichtlich vertikaler Skalierung von Servern des roten H hast du hier bei Netcup leider nicht. Es muss ja einen Grund geben, weshalb es hier günstiger ist.
Imho ist ein Server Upgrade in einen größeren Tarif hier bei Netcup jederzeit möglich (auch unter Beibehaltung der IP Adressen/Prefixe), ein Downgrade aber nicht (da es nicht die Option gibt, die Plattengröße beim Upgrade beizubehalten).
De facto könntest du mit Snapshots und Exports arbeiten, um quasi Server a) mit einem kleineren Server b) zu ersetzen, aber dann behältst du einerseits die IP nicht (wenn du nicht eine extra Failover IP dazu kaufst, die sich dann flexibel routen lässt) und andererseits könntest du genauso gut beide Server in irgendein Live Linux booten und dann so Dinge wie dd durch nen SSH Tunnel o.Ä. machen, um die Festplatte(n) eines Servers auf die des anderen zu klonen.
Stundengenau abrechnen tut Netcup allerdings auch. Nur so wild hin und her scalen wie beim roten H, das klappt nicht wirklich bzw. nur mit viel manuellem Arbeitsaufwand und Kompromissen.
Ergebnis: falsches Ziel, TLS-Fehler. das Entfernen des search-Eintrags behebt es.
Das ist mir durchaus klar. Aber Interessant, den von dir verlinkten Issue habe ich wohl bisher übersehen. Danke für den Hinweis!
Ich habe das Problem jetzt mal tiefergreifend analysiert und es hat tatsächlich nichts mit irgendwelchen libc's oder libcurl's.
ArtCore7 Die LLM Ausgabe war eine komplette Halluzination, php-curl nutzt libcurl und damit einhergehend kein c-ares, genauso wie das curl auf der CLI. Generell hat das ganze nichts mir c-ares zu tun, das ist im curl Kontext seit 2010 nicht mehr auf Debian zu finden.
Generell konnte ich sowohl mit unterschiedlichen Debian (und damit glibc und (lib)curl) Versionen, als auch unterschiedlichen PHP Versionen keine Unterschiede feststellen.
Das Problem lag tatsächlich in einer Nextcloud eigenen DNS-Middleware, welche explizit den A Record und dann explizit den AAAA Record auflöst. Diese Middleware greift auf dns_get_record von PHP zurück. Zu gut deutsch passiert da das selbe, wie wenn curl oder wget mit -6 aufgerufen wird - AAAA ist NXDOMAIN, also weiter mit dem AAAA Record der Domain + search Domain. Denn wir haben explizit nach AAAA bzw. einer IPv6 Adresse gefragt. Alles verhält sich so, wie es soll. Nur die Nextcloud DnsMiddleware "is a bissl doof".
Im Endeffekt ist das ganze halt ein Feature von dns_get_record, man kann halt entweder explizit A oder explizit AAAA auflösen, aber nicht den normalen Fallback Mechanismus nutzen. Den gibt es da schlicht und ergreifend nicht.
Andere Anwendungen bekommen das ja auch hin, aber die werden sicher selbst nochmal die Antworten "sortieren" bzw. priorisieren. Mein dirty Fix, den ich auch im von Morfyum verlinkten Issue vorgeschlagen habe, wäre, das Host Feld der DNS Antwort mit der angefragten Domain zu vergleichen und alles, was nicht gleich ist, zu discarden.
Ich denke die sauberste Variante wäre es, das ganze irgendwie zu sortieren... aber das ist imho nicht ganz so einfach bzw. würde da einen größeren Change an der Code Base erfordern.
Achja - falls ihr euch fragt: Warum zum Henker haben die ne eigene DnsMiddleware?! Diese Middleware cached die DNS Anfragen im Memory Cache (z.B. Redis) - also die Antwort ist in erster Linie: DNS Caching.
Danke nichtsdestotrotz für eure Ideen, insbesondere an Morfyum für den Issue.
Wenn ein FQDN auf Cloudflare-IPs auflöst, dann befindet sich der betriebene Server (das "Origin").i.d.R. hinter Cloudflare (Proxy, genannt "Edge")
Ob der Server IPV4-only ist wäre dabei irrelevant, da das "Edge" IPv4+IPv6 ist, die nachgelagerte Verbindung vom Edge zum Origin wäre dann IPv4-only.
Die Verbindung vom User/Client zum "Edge" läuft hierbei über Zertifikate von Cloudflare. Vom Edge zum Origin in der Regel dann über eigene (Lets Encrypt,....) oder von Cloudflare bereitgestellten Wildcard-Origin-Zertifikate (die ich auf dem Server nutzen kann)
Mich hat "löst auf Cloudflare-IPs" sofort getriggert....aber dann wäre das Verhalten überall das selbe....
Da haben wir uns wohl sehr offensichtlich hochgradig missverstanden. Ich weiß durchaus, wie Cloudflare funktioniert, allerdings stehen weder der betroffene Server, noch GitHub, hinter Cloudflare. Das betrifft nur "den Rest" der betroffenen Domain (in meiner Veranschaulichung example.org). Das Verhalten bzgl. HTTPS und TLS ist nachvollziehbar und korrekt, wenn man verstanden hat, was in Puncto DNS passiert - nur, was hinsichtlich DNS nicht funktioniert ist nicht nachvollziehbar.
Mir wurde per Konversation die Ausgabe eines LLM geschickt, welches generiert hat, dass php-curl wohl abweichend zu curl (konkret unter Debian) und wget nicht den glibc Resolver nutzt, sondern den von c-ares. Konkret soll es wohl so sein, dass NXDOMAIN "Stop" bedeutet und NODATA "Probier es nochmal anders" (der Resolver nutzt dann die Suchdomain) - und der glibc Resolver berücksichtigt das, wohingehen c-ares NXDOMAIN wie NODATA behandelt, wodurch das beschriebene Verhalten entstehen soll.
Ich hatte noch keine Zeit, das zu validieren. Aber ich werde dieser Annahme auf jeden Fall nochmal nachgehen, da sie das Verhalten auf jeden Fall recht nachvollziehbar erklären würde. Also, es bliebe dann natürlich immer noch die Frage, warum c-ares das so macht (aka was sich die Entwickler dabei dachten), aber das lässt sich dann sicher auch noch herausfinden.
Hallo in die Runde (ja, mich gibt es noch ),
mir ist heute ein sehr verrücktes Verhalten auf einem Server begegnet, welches ich gerne mal mit dem Schwarmwissen hier technisch etwas ausdiskutieren und analysieren wollte.
Seit einigen Tagen hat sich ein Debian Trixie basierter VPS beschwert, dass dort keine Nextcloud App Updates mehr installiert werden konnten. Beim Downloadversuch des entsprechenden tar-Archivs kam es zu einem TLS Handshake Failure. Der Downloadversuch an dieser Stelle erfolgte über php8.4-curl.
Zum Debugging habe ich dann mit curl und wget auf der Bash versucht, eben jenes tar-Archiv herunterzuladen, was funktionierte. Danach probierte ich, das ganze auf IPv4 oder IPv6 einzuschränken - das Problem tauchte nur bei IPv6 auf... und ab hier wird es verrückt, da GitHub (wie ihr vielleicht wisst) nur IPv4 anbietet. Allerdings haben sowohl curl, als auch wget auf zwei Cloudflare IPv6 Adressen aufgelöst.
Wenn ich allerdings github.com gegen die Netcup DNS Server (und auch andere DNS Server) manuell mit dig/host/nslookup aufgelöst habe, dann kam (so wie es auch sein muss), ein NXDOMAIN zurück. Ab dem Punkt habe ich dann langsam an mir selbst gezweifelt, den kompletten Server auf den Kopf gestellt, wenngleich ich wusste, dass da keine Konfiguration sein kann, welche quer schießt, weil alles meinem Standardsetup enspricht und sich weitere Server, die ähnlich aufgesetzt waren, eben nicht so verhalten haben.
Zur Problemlösung: Nehmen wir mal an, der Hostname des Servers ist srv01 und er hängt unter der Domain example.org - dementsprechend habe ich den FQDN auf srv01.example.org gesetzt und die Suchdomain in der /etc/resolv.conf auf example.org gesetzt. In meinem Falle war die Domain nicht von mir verwaltet, und irgendein spezieller Spezialexperte hat einen Wildcard-Record mit Ziel Cloudflare eingerichtet. Dadurch wurde, nachdem der Request auf den AAAA Record von github.com mit NXDOMAIN beantwortet wurde, anstatt des A Records von github.com der AAAA Record von github.com.example.org aufgelöst.
Am Ende konnte ich das Problem recht einfach lösen, indem ich den sowieso nicht zwingend benötigten search-Eintrag aus der resolv.conf rausgeschmissen habe.
Aber ich habe Fragen... einige. Warum verhält sich php8.4-curl eben genau so? Meine Erwartung wäre eine Auflösung in folgender Reihenfolge: AAAA, A, AAAA auf search-Domain, A auf search-Domain
Und insbesondere - warum verhalten sich curl und wget auf der Bash anders? Dort hatte ich das Verhalten nur, wenn ich explizit den -6 Parameter mitgegeben habe. Ich hätte außerdem erwartet, dass PHP 8.4-curl am Ende nur ein "Frontend" für libcurl ist, gleichermaßen wie die CLI Applikation curl genauso nur ein "Frontend" für libcurl ist, und ich dementsprechend ein einheitliches Verhalten vorfinde - oder habe ich da einen Denkfehler?
Bin ich mit meiner Erwartungshaltung da alleine oder seht ihr das auch so? Und hat da evtl. jemand tiefergreifendes Wissen, um das Verhalten zu erklären?
Ja. Aber am Ende war es Overkill und hat mega viele False Positives geschmissen. Daher habe ich es irgendwann wieder rausgeschmissen.
An sich sind WAFs ja auch nur Symptombekämpfung. Wenn die Webanwendung in sich so unsicher ist, dass man vorher mit einer WAF etwas abfangen muss, dann sollte man eher an der Anwendung anfassen. Oder anders herum betrachtet: Wenn die Anwendung safe ist, kann man sich die WAF sparen.
Am Ende nutze ich nur noch einiges Tweaks im Webserver (ACLs, Header Checks, etc.) und Anubis. Das entfernt so ein bisschen das Grundrauschen und Crawler/Bots einigermaßen gut, ansonsten schaue ich halt, dass ich die Probleme an der Ursache anfasse.
Und ja, natürlich kann man Dritttools nur bedingt beeinflussen. Wobei: Einerseits kann man bei freier Software ja Fixes beitragen oder zumindest melden, und andererseits kann man immer noch andere Software nutzen. Oder zumindest die Software per ACLs vom freien Internet abschotten.
Betreibt hier irgendjemand einen Proxmox BS (Backup Server) auf dem gleichen System wie ein Proxmox VE (Virtual Environment)?
Also nicht in einer VM, wirklich auf dem "Hostsystem" direkt! Das sollte bei einer manuellen Installation ja theoretisch möglich sein.
Ja.
Mich würden nur ein paar Erfahrungsberichte interessieren, ob das wirklich problemlos läuft und Dist-Upgrades überlebt. Besonders da man z.B. bei netcup ja keine VM für PBS auf einem PVE-System erstellen kann. Dementsprechend wäre das hier die einzige Alternative, wenn man beides auf einem einzigen vServer laufen lassen möchte. Dass man darin dann nicht die Backups von genau diesem System speichern sollte, versteht sich von selbst.
Mein größtes Problem ist, dass mein Browser immer Autocompletion auf Port 8007 statt 8006 macht lol.
Spaß bei Seite - bisher hatte ich noch keine Probleme. PBS ist bei weitem nicht so invasiv wie PVE, bringt z.B. keinen eigenen Kernel mit etc.
Du kannst den PBS auch als LXC laufen lassen, siehe hier LINK
Aber die Idee mit dem LXC Container finde ich auch nicht übel. Am Ende kann man das ja, genau wie PVE, auf einem einfachen Debian System "oben drauf" installieren.
is it possible to install windows arm on VPS 2000 ARM G11?
I try many method but no way to boot the windows installation...
Thanks
Actually, there is no Windows Server Edition for ARM and the client version of Windows is not really made for server operation, especially not in virtualized environments. Even if you get it running, it would be - regarding to IT security - very irresponsible to run a Windows system directly on the internet.
But to get back to your question - running Windows on those ARM based VPS is, from what i know, not officially supported by netcup. There is some documentation in the internet for getting a running OS in such an environment, but as an experienced administrator i just want to recommend you: Don't do it. It will become a security disaster and your VPS will get hacked and abused faster, as you can spell the word hacker. (Thats also the reason, why i wont link to the mentioned documentation here).
Nur lesen tut das keiner und das Support Discord wird deswegen mit angeblichen Fehlermedungen zugespammt. Wie heisst es immer so schön: Wer lesen kann ist klar im Vorteil
Wobei ich sagen muss, dass es schon eine ziemliche Umgewöhnung ist. Ich saß jetzt schon ein paar mal davor und dachte mir "WTF genau dieses Passwort ging doch eben noch?!?!?" - "Oh, falsche Login Maske".
Also ich habe es jedes mal selbst gemerkt, aber es ist schon krass, wie sich manche Dinge über die Jahre einfahren und wie schwer es ist, sich umzugewöhnen.
EDIT: Oder ist es gar nicht so schlimm und ich werde einfach nur alt? 
An die mailcow Serveradmins unter euch: Verwendet irgendjemand die Funktion "Rspamd Settings Map", idealerweise mit regulären Ausdrücken in den Regeln? Dann prüft bitte einmal, ob die nach dem Update auf 2025-03 wirklich noch greifen, ohne dass ihr sie neu speichert!
Ich verwende das z.B. um E-Mails an No-Reply Postfächer abzuweisen oder zum Blockieren von bestimmten Spammails, die zu leicht massenhaft durchkommen. Diese Regeln zeigten nach dem Update keinerlei Wirkung mehr, erst nach dem erneuten Speichern. Mir fehlt leider die Zeit für einen Versuchsaufbau in einer frischen VM, um das eindeutig zu reproduzieren. Vielleicht ist es auch ein individuelles Problem meiner Installation/Konfiguration.
Das kann ich bei beiden Installationen, welche ich betreue, nicht bestätigen. Die Mails werden ohne mein Zutun nach wie vor wie gewünscht abgewiesen.
Hey,
vielen Dank für diese ausführliche Rückmeldung!
Woodpecker ist ein Fork von Drone.
Das wusste ich gar nicht, erspart mir aber da nochmal Recherchearbeit.
Letztendlich war es aber immer ein "externes" System
Das ist es auch, was mich von einem externen Tooling abschreckt. Aber wenn die "Language" da besser ist, würde ich es vermutlich auf mich nehmen.
Als "Workaround" hab ich ne Abwandlung von https://github.com/addnab/docker-run-action im Einsatz.
Das ist ein guter Tipp, danke dafür. Darf ich fragen, was du daran abgeändert/abgewandelt hast?
Warum ich nicht "nur" Github nutze: Es gibt gewisse Einschränkungen wie dass die CI sich nach 60 Tagen ohne Commit deaktiviert und so. Diese "Empty" Commit Bots dagegen als Lösung finde ich nicht prickelnd...
Das ist tatsächlich für mich gar kein so großes Problem. Ich nutze eine selbst geschrieben Ansible Rolle, um mir die Forgejo Runner auf einer lokalen VM zu deployen, wie ich sie brauche und habe auch genug Leistung "vorrätig", um alle Jobs selbst abzuarbeiten.
Moin,
ich bin etwas "verloren" bei der Suche nach einem CI System für Forgejo, daher möchte ich hier einfach mal nach Erfahrungen und Meinungen fragen.
Zu meiner Situation: Ich habe eine GitLab Instanz und nutze dort sehr aktiv GitLab CI. Konkret habe ich ein Repository nur für CICD-Templates, welches quasi eine große, automatische Pipeline enthält, die über diverse Regeln immer das tut, was in einem Projekt erforderlich ist. Diese Pipeline wird zentral gepflegt und ist in jedem Projekt eingebunden.
Jetzt habe ich mir eine Forgejo Instanz aufgebaut und würde gerne auch zu Forgejo wechseln, da es im Vergleich zu GitLab viel performanter ist, weniger Leistung in Anspruch nimmt und auch vom UI her deutlich angenehmer in der Benutzung ist. Auf der Forgejo Instanz möchte ich natürlich auch CI nutzen, am liebsten mit der selben Vorgehensweise wie bisher. Allerdings basiert Forgejo Actions auf mehr oder minder auf GitHub Actions und ist für meinen Geschmack furchtbar in der Benutzung. Dinge wie "Hier ist mein Docker Image und da sind meine Befehle zum Ausführen" ist nur sehr umständlich bis gar nicht machbar. Es gibt zwar viele fertige Actions, allerdings maintaine ich meine CI Job/Pipeline Definitionen schon ganz gerne selbst und ziehe sie nur ungern von extern an.
Als Alternativen sind mir aktuell Woodpecker CI und Drone CI bekannt (Gibt es noch andere, die Forgejo/Gitea kompatibel sind?). Woodpecker CI kann scheinbar gar keine Templates und Includes, zumindest finde ich nichts dazu in der Dokumentation (Oder geht es doch?). Was Drone CI betrifft - das hat einen recht faden, kommerziellen Beigeschmack und bietet zumindest offiziell nur Support für Gitea - die Syntax habe ich mir hier bisher noch nicht angeschaut. Prinzipiell aber immer noch ein Kandidat mit Potenzial.
Nun bin ich auf eure Meinungen und Erfahrungen gespannt... vielleicht finde ich ja damit einen für mich passenden Weg.
Enorme Lizenzkosten zwingen EU-Cloudanbieter zum Umstieg
Upsi. Über 500% Erhöhung... das tut wirklich weh.
EDIT: Paul war drei Minuten schneller. 
whoami0501 Wie hast du http3 abgeschaltet? Global im Caddyfile, so wie hier?
Code{ servers { protocols h1 h2 } }
So habe ich es abgeschaltet, ja.
Sorry, ich hatte den falschen Sever erwischt. Bei mir funktioniert es jedenfalls jetzt mit und ohne http/3.
Es war auch total spooky, denn zig Kunden berichteten davon aber bei mir und auch noch jemand anders, der es für mich gegengeprüft hat ist es nicht passiert. Nach ungefähr einer halben Stunde rumprobieren, ist es dann aus heiteren Himmel mit meinem Chromium basierten Browser hier auch passiert, dass ich in den Error 411 gelaufen bin.
Und seitdem HTTP/3 aus ist, geht es wieder bei allen Beteiligten.
Hat aktuell noch jemand Probleme mit UDP/HTTP3 in Nürnberg? Hatten gerade sporadische, aber häufige Error 411 und leere Seiten als Antwort. Mit einem aktuellen Caddy als Webserver, ein gutes dutzend verschiedene Server. Seitdem ich HTTP3 ausgeschalten habe, tut alles wieder. Das ist gerade total spooky.
Ich habe ja vor gefühlt geschätzt Jahren mal bei einem Gewinnspiel hier im Forum diesen Netcup-Akku-Smoothie-Maker gewonnen. Damit habe ich direkt zu Beginn einmal Smoothie gemacht, dann nie wieder. Aber ich erwische mich immer wieder dabei, wie ich das Ding als Gewürzmühle missbrauche, um größere Mengen Salz oder Pfeffer zu zerkleinern oder auch Rubs herzustellen. Und das funktioniert verdammt gut.
Sowas aber auch, jetzt hats die letzten 1-2 Tage etwas an meinem Netzwerk gehakelt und irgendwie hat mein etwas komplexeres IPv6 Setup partiell angefangen, komische Dinge zu tun. Siehe da, kein Prefix mehr da. Ich, verantwortungsbewusster ITler, habe natürlich aufm Router Port 546 eingehend nur für fe80::/64 offen. Jetzt bin ich aber bei O2... eh ich darauf gekommen bin, dass ich tatsächlich auch von dem Schmarrn mit den verkorksten Link-Local Adressen, die gar keine sind, betroffen bin. Habe jetzt noch ne Firewall Regel für 0:80fe::/64 angelegt, und zack, war das Prefix wieder da.
Bei diesem Thread rollen sich einem schon ein wenig die Fußnägel auf. Ich meine, man sollte bei einem Discounter-Anbieter, wie O2 es ist, einfach nicht zu viel erwarten... aber irgendwie ist es schon traurig, dass das Verhalten seit 16.09. bekannt ist und scheinbar das Rollout dieses kaputten Updates oder dieser kaputten Config in der eigenen Infrastruktur nicht gestoppt wird. Anders kann ich es mir jedenfalls nicht erklären, dass es bei mir knappe 2 Monate nach bekannt werden des Problems plötzlich scheppert.
Wie viel Strom verbraucht denn die Starlink Empfangsanlage? Ich habe irgendwo mal gelesen, dass das verhältnismäßig viel sein soll. Kannst du das bestätigen?
Denkt ihr ein VPS piko G11s tut für Uptime Kuma? Oder hat der zu wenig CPU/RAM?
