Beiträge von hra42

Zitat von webdesignheld

Full circle

LOL CRAZY hast du Recht Ist mir gar nicht aufgefallen

Ich hab grade mal nach geschaut, ich bin seit 2019 Kunde bei Netcup, mein erster Server war damals ein:
RS 4000 SSD G8SE a1 Kundennummer 119xxx
Damals hab ich noch studiert und war stolz wie bolle meinen eigenen Server zu betreiben heute sind es 3000 Server auf der ganzen Welt, ach wie die Zeit vergeht

Zitat von webdesignheld

Absolut! Einfach Claude oder ChatGPT sagen: “Bau mir eine Webseite” und fertig. Das ist die Zukunft.

Ich hab mir gedacht das es zu Sarkasmus kommen würde, aber das ist nun mal die neue Realität niemand der noch bei Sinn und Verstand ist wird jemals wieder 100K für ne Website ausgeben wenn man das ganze auch mit einem LLM in Stunden zusammen schustern kann, das wird natürlich zu einem Verlust an Qualität führen, aber sind wir realistisch in Zukunft werden vermutlich mehr und mehr Agenten und LLMs Websites aufrufen, kann man heute schon an den Klickzahlen großer Websites sehen.

Du kannst du davor verschließen, aber die Realität ist wird sich nicht deiner Meinung anpassen.

P.S.: Ich sehe das auch kritisch, aber wenn Unternehmen Geld sparen können werden sie das tun, egal was dabei raus kommt. Darum der Hinweis auf die statische Seite..

Zitat von zeropage

Hallo allerseits,

ich möchte meinen Root Server G9.5 initialisieren und neu aufsetzen. Um einen Downtime zu vermeiden, habe ich dazu in der Vergangenheit einfach zwei Server für einen Monat parallel betrieben und den alten gekündigt. Wegen des nun aber damit verbundenen Preisanstiegs beim G12.5 habe ich Zweifel an dieser Vorgehensweise. Statt Preisanstieg müsste ich von RS auf VPS umzusteigen.

Nun ist mir eine weitere Variante in den Sinn gekommen: Für einen Monat einen zweiten Server mieten, dort alles installieren, davon ein Image-Backup erstellen und dann das Backup auf den alten (!) Server einspielen. Und schließlich (teuren) Zweitserver wieder kündigen.

Hat das jemand schon mal so gemacht? Gibt es irgendwelche Pitfalls, an die ich nicht denke? Oder gar eine weitere, bessere Vorgehensweise?

Danke, Titus

Verzeih mir die vlt dumme Frage aber wenn du den Server sowieso neu machst, dann wirst du doch Zwangsweise eine Downtime haben oder nicht? Warum also nicht einfach eine kurze Downtime ankündigen das der Server mal ne Stunde offline ist? Vorher einfach ein Script schreiben das installiert was du installieren willst und das letzte Backup wieder einspielen und fertig? Da sollte man doch in wenigen Minuten durch kommen.. Bevor du diesen Zauber mit Rsync machst und am Ende eine viel längere Downtime hast..

Alternativ warum nicht auf statische Websites setzen wie mit Astro oder Hugo oder oder oder.. das reicht um gute Websites zu bauen vollkommen aus, dazu noch nen lokales LLM im besten Fall und ihr habt euer eigenes "CMS" das ihr anpassen (lassen) könnt wie ihr wollt.

Allgemein sehe ich aber keine große Zukunft mehr darin neu Websites für Kunden zu bauen, die werden iwann auch auf den Trichter kommen sich ein LLM zu schnappen und sich eine Website zusammen zu schustern (wort wörtlich)

Zitat von NaN

Das ist die kurzsichtige (operative, bestenfalls taktische) westliche Sicht. Weil sich nicht nur die Chiphersteller sondern auch deren Kunden festgelegt haben, auf Jahre hinaus Preise zu verlangen, die mit den eigentlichen Produktionskosten nichts mehr zu tun haben, ist eine Lücke entstanden, die langfristig (strategisch) denkende Länder für sich nutzen werden. Das ist genug Zeit, um den Markt von unten aufzurollen. Stellt euch schon mal darauf ein, RAM bei Aliexpress zu bestellen, das kein Fake sondern Original Made-in-China ist.

CXMT macht genau das gleiche wie die anderen großen, schau dir die entsprechenden Pressemeldungen an..

CXMT hat über 10 Jahre gebraucht um auch nur in die Nähe der großen drei zu kommen, wenn du solange auf eine Lösung warten willst, dann ist das okay. Aber es wird nicht morgen ein neuer Hersteller aus China heraus fallen und den Markt aufräumen..

Zitat von ASS

Weshalb sollte es da anders sein, als Anfang des Jahres berichtet? Fest bestellte und vertraglich zugesicherte Hardware wurde einfach nicht geliefert (bzw nur zum xfachen Preis).

Bei den ungelegten Eiern werden wir wohl warten müssen, bis es so weit ist, bzw ob es so weit kommt.

Nehmen müssen wir es sowieso, wie es dann kommt...

Was auch kleine Reseller bis dahin in ihren Verträgen haben werden, ist eine Vorlieferantenklausel.

Ich möcht garnicht wissen, wieviele "kleine" im Ruin sind, weil sie nur mit 5-15% Aufschlag weiterverkauft hatten und dann Einkaufspreiserhöhungen von 20, 30, 50 200% hatten.

Wenn ich mich richtig Erinnere waren das nicht die DRAM Chips selbst die nicht geliefert wurden sondern fertige RAM Riegel und NVMEs, deren Hersteller natürlich selbst auch nur bei den großen Einkaufen und den Druck entsprechend durch die Kette nach unten weiter reichen, teilweise war es wohl so das selbst ODMs keine Chips kaufen konnten und wenn nur mit absurden Preisaufschlägen.

Naja klar werden wir darauf warten müssen, aber für eine langfristige Planung im nächsten Jahr ist es schon wichtig zu wissen wo die Reise hingeht und was Netcup stand heute plant, das es nochmal anders kommen kann als jetzt prognostiziert ist klar.

Zitat von [netcup] Alexander W.

Erstmal viele Dank an alle, die hier schon so fleißig geantwortet und geschrieben haben.

Eine sehr wertvolle Diskussion.

Wir beschäftigen und intern die ganze Zeit damit. Anfang des Jahres dachten wir, dass es vielleicht noch 2027 wieder runtergehen wird oder vielleicht, dass eine Bubble platzt. Wenn wir damals gewusst hätten, dass es nur noch weiter nach oben geht, dann hätten wir noch mehr Hardware eingekauft.

Wir von unserer Seite haben versucht so lange wie möglich die Preise unten zu halten - in der Hoffnung, dass die Nachbeschaffung wieder zu geringeren Preisen möglich wird. Das absolute Gegenteil ist passiert.

Außerdem gibt es ja auch einen Austausch in der Branche auf einschlägigen Events oder auch direkt,. Da gab es die Optimisten, die sagen es wird spätestens diesen Sommer wieder besser und die Pessimisten, die dachten es wird 20x so teuer. Schlussendlich sitzen wir (Cloud- und Infrastrukturanbieter) alle im selben Boot: Jeder versucht günstig die Hardware zu beschaffen.

Irgendwann ist das letzte Lager ausgeräumt, der letzte DDR4 und die letzte SSD verbaut und man muss nachbeschaffen. Das betrifft alle, weil keiner unlimitiert Hardware gebunkert hat.

Wir auf unserer Seite haben nicht mal die gesamten Kosten weitergegeben und bewusst auf Marge verzichtet, um es irgendwie verträglicher zu machen. Wobei man ganz ehrlich sagen muss: 110% ist ein Aufschlag, der nicht sehr verträglich ist, wenn man das aus der eigenen Tasche zahlen muss.

Die Transparenz ist eh da - ich hab die Börsepreise gepostet. Dort seht ihr, was der Speicher am Markt kostet. Verdienen tun da dran alle, die den Speicher herstellen - und das sind drei großen Anbieter für Speicher. Selbst die großen Hyperscaler kaufen jetzt zu diesem Preis zu.

Also es würde dir auch die Offenlegung sämtlicher Kosten nichts bringen, weil sie ohnehin mehr oder weniger transparent sind. Man hat hier fast keine Schankungen - im Großeinkauf spricht man im Anbietervergleich von Schwankungen unter 1%.

Genau das tun wir seit etwa zwei Jahren. Ich setze mich da im Rahmen der CISPE mit einigen anderen Anbietern aus Europa dafür ein, dass die Rahmenbedingungen besser werden und die europäische Cloud- und Infrastruktur Branche eine Stimme bekommt. Das gelingt bei fairen Regulierungen (oder Deregulierungen), bei Lizenz- und Wettbewerbskämpfen und vielem mehr sehr gut. Nur hier sind wir in keiner Wettbewerbssituation - wir sind hier in der beinharten Marktwirtschaft: Angebot und Nachfrage bestimmen den Preis. Solange die Anfrage so anhält (und das tut sie) und das Angebot gering ist (das bleibt es, weil Fabriken nicht so schnell gebaut werden können), wird der Preis oben bleiben.

Das ist Marktwirschaft - sehr nüchtern betrachtet. Oft ist es super, weil es Innovation und gute Preise fördert, aber es hat eben auch Schattenseiten - wie wir es jetzt gerade sehen.

Was kann man jetzt dagegen machen?

Es wurde eh schon teilweise geschrieben und da spreche ich gegen unser Geschäft, aber ganz ehrlich: Mehrere Services auf einem Server, Software speicherärmer programmieren (Microsoft Windows hat mit den neuen Patches grad genau das gemacht btw), Logrotation (ist so offensichtlich, machen aber wenige), etc.

Es ist ein bisschen wir in den 80er und 90ern, wo man sich ganz genau überlegt hat, wie viel RAM eine Variable benötigt

Alles anzeigen

Selbst wenn die Blase platzt würden die Preise nicht runter gehen, wie ihr sicher wisst haben die großen 4 (ich inkludiere hier mal CXMT aus China mit) langfristige Verträge die mind. bis Ende 2027 reichen, daher müssen die Abnehmer entweder den RAM kaufen oder Strafen zahlen. Wobei sich in letzterem Fall wahrscheinlich sehr hohe Nachholeffekte einstellen würden von den großten SIs (Lenovo, ASUS, Dell, HP etc.) gegen diese Firmen wird man preislich keinen Stich sehen. Neue Fabriken wurden nur sehr konservativ ans Netz gebracht um einen Abfall der Preise zu vermeiden.

Ähnlich sieht es bei NVMEs aus.

Daher meine wirkliche Frage: Bei dieser Preisentwicklung (absehbar eher nach oben als nach unten, für 2027 wird nochmal 2x erwartet) werdet ihr die Preise auch für Bestandkunden anheben müssen um die Neubeschaffung zu refinanzieren? Oder würdet ihr in so einem Fall auf Wachstum verzichten und die Server für Neukunden nicht verfügbar machen? (ähnlich ist es bei ARM Servern ja bereits)

Hallo liebes Team hinter eos,

ich wollte nur mal kurz positve Worte finden, ich hab heute eos mal richtig getestet mit OpenTofu Rollout von 5 Servern (inkl. dem Netzwerk, ACL etc.) durchgeführt. Hat super funktioniert.

Ich hab dann über Cloud Init automatisiert 4 Nodes und ein Manager Node für k8s ausgerollt, hat auch alles funktioniert wie zu erwarten war. Innerhalb von 20 Minuten steht so ein k3s cluster. Ist natürlich mit einem Manager nicht HA Details..

eos macht aufjedenfall spaß

P.S.: Falls ihr mal Lust drauf habt, ich wäre sehr interessiert daran zu sehen was passiert wenn ich 100 Nodes erstelle und mal richtig Last drauf gebe.

Als Idee:
- eos bekommt eine Container Registry wie GitHub Container Registry (ghcr.io)

- Der Usecase wäre Images sicher innerhalb der Cloud abzulegen und dann durch k8s / docker / podman etc. sicher ziehen zu lassen.

Es wäre toll wenn man langfristig eine Storage Plattform auf Basis von S3 aufbaut, grade webmedia (bilder und videos) gibt es wenig gute alternativen.

Zitat von webdesignheld

fehlt da noch das social-share.png target?

https://metatags.io

Bin mir nicht sicher wie GitHub das Repo ausliefert, in der App selbst ist es richtig gesetzt.

In der App selbst findest du das Target unter Open Graph

Ist ja ein Zufalls das wir beide eine ähnliche Idee zur gleichen Zeit hatten

GitHub - hra42/image-optimizer: High-performance web image optimizer with multi-target presets (web, Instagram, LinkedIn, etc.) built on Fiber v3 + govips (libvips).

High-performance web image optimizer with multi-target presets (web, Instagram, LinkedIn, etc.) built on Fiber v3 + govips (libvips). - hra42/image-optimizer

github.com

Zitat von ozdreamwalk

Nein, das ist nur auf zwei IPs von denen aus ich die Domain geprobed habe. Einmal meine Heim-IP (konnte ich durch router-reset wieder ändern, dann geht's wieder) und die IP von einem anderen VPS bei netcup. Spricht eben für ein fail2ban, bzw. firewall vor dem Webhosting, auf das ich keinen Einfluss habe. Ticket beim Support ist erstellt.

Ich würde das nie ohne SCHRIFTLICHE erlaubnis von Netcup machen. Auch ein Portscan kann (und wurde in Vergangenheit) von Gerichten als Computer Sabotage gewertet werden, besonders wenn durch deinen Portscan das System überlastet wird (§ 303b StGB).

Zitat von terence

Danke für das Tool und teilen des Quell-Codes! Ich selbst benötige es aktuell zwar nicht, weil ich u. a. SSH nur via IPv6 verwende und sich mein IPv6-Präfix i. d. R. nicht ändert. Aber es ist immer interessant zu sehen, wie sowas umgesetzt wurde und kann ja evtl. auch mal als Inspiration für eigene Implementierungen dienen.

Hier ist übrigens etwas Ähnliches zu finden: Firewallregeln mit dynamischer Home-IP über API updaten

Eine kleine Anmerkung zur Doku:

Bei einem DS-Lite-Anschluss hat man auch eine öffentliche IPv4-Adresse (sonst wäre es ja kein Dual-Stack). Man teilt sich diese Adresse aber mit anderen Kunden des ISP (via CGNAT). Daher würde ich es eher als Empfehlung formulieren, in diesem Fall nur IPv6 zu verwenden und beschreiben, warum es ggf. sinnvoll ist.

Danke für die Anmerkung zur Doku. Ich habe das eben angepasst

Zitat von Zierleiste

Hey super - die Lösung mit der Option --ipv6-prefix ist elegant.

Hast Du das netcup-autofirewall-Tool eigentlich auf der netcup-VM selbst laufen (also verfügt diese VM über die SCP-Zugangsdaten) oder steuerst Du die netcup-Firewall von einer externen Instanz aus an?

bei mir läuft das aus meinem HomeLab auf einem Rock 5T von Radxa. Du kannst das aber auf jedem beliebigen Computer hosten.

Zitat von ASS

und

Klingt irgendwie nach Bock als Gärtner

Niemand ist gezwungen das auch hinter Cloudflare zu setzen. Ich habe ein Enterprise Agreement mit Cloudflare und bin happy damit. Das ist das schöne wenn du die Quelle hast, hoste es selbst oder passe den Code an, tu was du willst damit

Zierleiste
Danke für das ausführliche Feedback, genau sowas hilft mir. Hab alle fünf Punkte umgesetzt: https://github.com/hra42/netcup-autofirewall/pull/1

Kurz zu den Details:

DynDNS statt Echo-Server: --dns-hostname home.example.org reicht jetzt, dann wird der Name aufgelöst statt der eigene Echo-Server gefragt. Nicht-routbare Antworten (also z.B. wenn der Router seine LAN-Adresse meldet) werden verworfen – so was darf nie in einer Firewall-Regel landen. Falls euer Resolver länger cached als euer Apply-Intervall, gibt's --dns-server, um direkt eine Nameserver-Adresse anzufragen.

IPv6-Präfix: Standardmäßig bleibt's bei /128, aber mit --ipv6-prefix 64 wird auf's Präfix erweitert und die Host-Bits genullt – genau wie du's beschrieben hast, analog zu IPv4, wo ja eh das ganze Heimnetz hinter einer Adresse steckt. Ich hab den Default bewusst bei /128 gelassen, damit ein Update nicht stillschweigend die Freigabe aufweitet.

DS-Lite: --ip-mode mit dual (Standard), v6only, v4only, auto. Vorher war IPv4 hart verdrahtet, jetzt läuft's auch ohne.

OpenVPN: eigene Policy, eigener Port, TCP oder UDP wählbar, läuft neben WireGuard. Ist mir aufgefallen, dass der WireGuard-Port bisher auch gar nicht konfigurierbar war – hab ich gleich mit nachgezogen.

Egress-Regeln fürs VPN: Das war tatsächlich der kniffligste Teil. Die netcup-Firewall ist bei UDP nicht stateful, du hattest also komplett recht. Aber es gab dabei eine Falle, auf die ich erst beim Testen gegen die echte API gestoßen bin: sobald man irgendeine Egress-Regel anhängt, kippt die implizite Egress-Regel des Interfaces von ACCEPT_ALL auf DROP_ALL. Eine UDP-Egress-Regel bedingungslos zu setzen hätte also nebenbei den kompletten ausgehenden TCP-Verkehr blockiert – und das Tückische daran: man merkt's nicht sofort, weil das VPN selbst ja weiterläuft.

Nochmal danke, ohne den Hinweis zu IPv6 und Egress hätte ich das vermutlich erst live gemerkt.

Hallo zusammen,

ich bin ein Rückkehrer nach längerer Zeit bei einem anderen Anbieter. Dort war ich es gewohnt, alles zu automatisieren, was ich für den täglichen Betrieb brauche – besonders die Firewall-Regeln. Ihr kennt das bestimmt: man sitzt hinter einem ISP mit dynamischer IP, und alle paar Tage muss man wieder die Adresse aktualisieren, um überhaupt auf den Server zu kommen. Nervig. Und SSH dauerhaft offen lassen will ja auch keiner.

Zum Glück bietet Netcup mit der SCP-API genau das, was man dafür braucht. Also hab ich mir ein kleines Tool gebaut: netcup-autofirewall.

Was es macht:

Bei jedem Lauf ermittelt es deine aktuelle öffentliche IPv4/IPv6, schreibt sie in eine Firewall-Policy namens ssh-autofirewall und hängt die an das Interface deines Servers – zusätzlich zu allem, was da schon dran hängt, nichts wird überschrieben. Die Policy selbst besteht aus drei Regeln: ACCEPT für deine aktuelle IPv4, ACCEPT für deine IPv6, DROP für den Rest. Läuft die IP-Adresse dir weg, wird beim nächsten Aufruf einfach dieselbe Policy aktualisiert statt eine neue anzulegen – da sammelt sich also nichts an.

Ein Punkt, der mir persönlich wichtig war: die IP-Erkennung läuft komplett selbst gehostet. Es gibt einen kleinen echo-server, den man auf einer eigenen Maschine laufen lässt (bei mir läuft er hinter Cloudflare), und der beantwortet nur die Frage "was ist meine IP". Kein Drittanbieter-Dienst sieht deine Adresse.

Außerdem dabei:

• Optional --cf, um zusätzlich HTTPS von Cloudflares Edge-Ranges freizugeben (praktisch, wenn der Server hinter Cloudflare-Proxy läuft)
• Optional --wg für WireGuard auf UDP 51820
• Ein eingebauter Scheduler (run), der sich selbst per Cron-Ausdruck immer wieder neu anwendet – man braucht also nicht mal Host-Cron dafür
• Beide Binaries (CLI + echo-server) gibt's als schlanke Container-Images

Login läuft über den OAuth2 Device Flow, danach genügt für den Alltag nur noch netcup-autofirewall apply --yes bzw. der Daemon-Modus.

Ist noch recht frisch, daher: Feedback, Issues und PRs sind willkommen. Falls jemand ähnliche Bedürfnisse hatte und selbst was gebaut hat, würde mich auch interessieren, wie ihr das gelöst habt.

Ein Wort der Warnung, falls jemand es ausprobiert: Serial/VNC-Konsole griffbereit halten, bis ihr sicher seid, dass es funktioniert. Lockout ist bei sowas immer ein Thema.

Viele Grüße
hra42