Beiträge von TBT

  • NTP (Network Time Protocol) mit chrony und aktivierter Firewall nutzen

    Motivation: Aufgrund eines Problems mit 2FA (2 Faktor-Authentifizierung) bei einem meiner Services (https://dockhand.pro/) habe ich festgestellt, dass die Uhr auf meinem RS so weit abweicht (ca 60s), dass die zeitgesteuerte 2FA nur "manchmal" funktioniert und ansonsten den sechsstelligen Code nicht akzeptiert (wenn die 30 Sekundenfenster soweit auseinanderliegen, dass auf meinem Authenticator (der die richtige Zeit hat) kein gültiger Code für die falsche Zeit auf dem RS angezeigt wird.

    Natürlich will man NTP umsetzen. Dafür gibt es mehrere Optionen und man muss v.a. auch die NC Firewall konfigurieren (siehe unten). Dies betrifft sicherlich jegliche NTP Lösung, nicht nur die vorgeschlagene.

    Daher habe ich mich mit https://claude.ai/ Code hingesetzt und eine Lösung gesucht. Es hat mir https://chrony-project.org/ als robuste und genauere Lösung vorgeschlagen, das vorhandene systemd-timesyncd wird bei Umsetzung deaktiviert.

    Vielleicht wollt Ihr ja auch eine genaue(re) Uhrzeit auf Euerem Server haben ;) . Dann wäre hier das "Kochbuch", das mir Claude so schön übersichtlich geschrieben hat und das auch Claude Code vorgesetzt werden kann, um die Änderungen umsetzen zu lassen. Natürlich könnt Ihr die Schritte aber auch manuell umsetzen. Im Anhang das Markdown File für CC oder zur Ablage zum Download.

    Ich habe feste Quell IP Adressen konfiguriert, da man in der Firewall (Screenshots unten) den QUELLport 123 aufmachen muss (ein Zielport geht nicht, da der Zielport zufällig ist). Und das will man natürlich nur für wenige, vertrauenswürdige IPs erlauben. Daher sind hier sind die PTB IPs und das Google NTP Netzwerk fest konfiguriert und weiter unten auch in der Firewall frei gegeben. Die typischen *.pool.ntp.org DNS Namen funktionieren hier nicht, da sich die IP Adressen dahinter ständig ändern.

    Und hier die Firewallkonfiguration:

    Beschreibung Typ Aktion Protokoll Source(s) (IPs / Netzwerke) Source Port(s) Destination(s) (IPs / Netzwerke) Destination Port(s)
    1 123 UDP eingehend EINGEHEND ACCEPT UDP 192.53.103.108, 192.53.103.104, 216.239.35.0/24, 192.53.103.103 123 * *

    nc-chrony-fw.png

    nc-chrony-fw-regel.png

  • Best Practice bei Serverumzug

    Automatische Updates mache ich nicht mehr mit Watchtower (ist EOL), sondern habe dafür https://getwud.github.io/wud/#/ installiert.

    Und ja, probiert Claude Code (kostet leider mindestens einen Monatsbeitrag) aus, ist einfach toll. Habe einen neuen Skill, der mir neue Compose Stacks anlegt und dabei die Volumes und das Netzwerk so organisiert wie ich das haben will. Einfach nur „/neuer-stack <neue Anwendung>“ und das Ergebnis wird nahezu perfekt sein. Man kann auch noch zusätzliche, spezifische Anweisungen auf der Tonspur mitgeben.

    Zudem: Sync aller Claude Code Einstellungen, Plugins etc. (ohne secrets) via privatem Githubrepo gebaut. Unassisted Updates damit konfiguriert, inklusive Restarts und Telegram Nachricht falls neu gestartet werden muss, alles drei natürlich zeitgesteuert mitten in den Nacht.

    Für die Arbeit kooperative Arbeit an Konzepten, sowie Schaubildgenerierung als HTML. Was auch super geht: https://mermaid.ai (auch selbst hostbar) ist ein Diagramm Tool, das das die Diagramme per Text konfiguriert. Ein LLM kann natürlich super mit Text umgehen, insofern kann man mit CC auch ein Mermaid Diagramm erstellen.

    Zudem steht Anthropic auf der m.E. richtigen Seite der AI Diskussion in den USA gerade. OpenAI sind da die Stiefellecker.

  • Das längste Thema

    Netcup Image. Erst vor wenigen Wochen die BF25 Server installiert, Debian 13 hat 11 und 12 auf alten Servern ersetzt. Und auch bei beiden die neue UEFI Installationsvariante gewählt. Mit UEFI und Debian 13 sollte das wieder mehrere Jahre reichen.

  • Best Practice bei Serverumzug

    Zitat von fvbor

    Ja... Das ist auch noch ein Projekt was ich mal durchführen muss. Auch mehr mit .env Dateien arbeiten :D

    Den Sync kann man wunderbar mit Claude Code aufsetzen. Und bei der Umstellung auf .env Dateien hilft die GUI von Dockhand sehr, da hat man eine schöne Trennung, aber nebeneinander in Fenstern von Compose File und .env. Und kann wunderbar bisher existente geheime Daten durch Platzhalter ersetzen.

    Beides habe ich erst mit dem Neuaufsetzen im Feb diesen Jahres erstmalig gemacht, kann aber beides absolut empfehlen.

  • Das längste Thema

    Wer sich Openclaw ansehen will, sollte sich imho lieber Claude Code ansehen (insbesondere in unserem Umfeld hier). Das geht ab einem Pro Abo (20€).

    Damit kann man DEUTLICH sicherer und kostengünstiger absolut großartige Sachen machen. Claude Code auf meinen Netcup Servern: beste Sache seit geschnitten Brot! Das Ding boxt sich durch alle Probleme und Fehler unverdrossen durch. M.E. wie ein sehr kundiger Juniorprogrammierer, dem man immer mal über die Schulter schaut und ihn in die richtige Richtung stupst. Und ich kann nachts auch noch ruhig schlafen, denn mit "exit" ist eben Schluss.

  • Best Practice bei Serverumzug

    Zitat von duck

    Prinzipielle Frage: Nutzt du ausschließlich Docker-Volumes oder arbeitest du auch mit gemappten Host-Pfaden, in denen die Daten abgelegt werden?

    Beides. Lieber gemappte Host Pfade, denn dann ist das Backup leichter, irgendwo hab ich aber mal aufgeschnappt, dass für Datenbanken Docker Volumes besser sind. K.A. ob das so stimmt, aber ich machs so. Allerdings habe ich den Docker Ordner immer auch auf /docker rausgelegt, damit ich dann da leicht Zugriff habe.

    Ich verwende also

    /docker

    /docker_build

    applikationsordner/compose.yaml

    /docker_data

    applikationsordner/ (für die gemappten Hostpfade)

    Die Anpassung des Docker Data Root mache ich mit der Erstellung von /etc/docker/daemon.json ->

    Code
    {
"data-root": "/docker/",
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

    Neben der Ordnerumstellung adressiert das auch noch die max. Größe des Log Files, das sonst leicht den Rechner zumüllen kann. Natürlich muss man dann alle Inhalte aus /var/lib/docker/ auch nach /docker/ bei ausgeschaltetem Docker verschieben.

    Das ist so Standard auf jeder meiner Installationen. Am Besten macht man das natürlich wenn man noch gar keine Container angelegt hat, sollte aber auch danach noch gehen.

    Ich packe nicht alles wie fvbor in einen Ordner, denn den Compose File Ast kann man, wenn man das nicht macht, wunderbar in ein privates (!) Github Repo syncen.

    Zitat von duck

    Fail2Ban kann ich mir nach meinem aktuellen Verständnis dann vermutlich sparen zu übernehmen.

    Wenn kein SSH Port dank NC Firewall nach außen offen ist, brauch ich auch kein fail2ban.

    "Dank" Claude Code habe ich weitere Verbesserungen eingeführt, Claude hat mir bei JEDEM Container auch noch Healthchecks in den Stack eingebaut, damit Docker auch weiß wie der Zustand der Container ist.

    Zitat von duck

    Verwendest du Tailscale für den Zugriff oder setzt du stattdessen auf direkten SSH-Zugang mit Key-Authentifizierung bzw. eine andere Absicherungsmethode?

    Ich verwende SSH mit Keys und nicht Tailscale SSH, dann könnte ich auch einfach nur die FW aufmachen und komme mit der Public IP so auch drauf. Das ist für mich der passende Grad von "Abhängigkeit" von Tailscale (siehe terence ). Für Tailscale könnte man auch https://headscale.net/stable/ selbst installieren, oder man verwendet (auch parallel) Zerotier (auch selbsthostbar), Netbird oder andere. Daher habe ich mit der Abhängigkeit kein Problem.

  • Best Practice bei Serverumzug

    Zitat von duck

    Also bedeutet das in deinem Fall, dass du beim Serverumzug das System einfach neu aufsetzt, anschließend Tailscale sowie Docker installierst und damit direkt wieder einen sauberen, frischen Stand hast? In der netcup-Firewall wären dann lediglich die Ports 80 und 443 freigegeben, beispielsweise für einen im Docker laufenden Caddy-Reverse-Proxy, und der restliche Zugriff erfolgt über Tailscale.

    Jep. So in etwa. Wenn ich noch die Daten mitnehmen will, übertrage ich über SSH direkt zwischen alt und neu noch die Docker Volumes, bei meinen aktuell verwendeten Containern ist das nicht nötig. Ja, Port 80 und 443 sind freigegeben, ich verwende https://nginxproxymanager.com , weil ich mich damit schon immer am Besten anfreunden konnte (vs. Caddy, Traefik). Pangolin könnte jedoch den NPM ersetzen.

    Und ja, der Zugriff auf die https://dockhand.pro/ Weboberfläche erfolgt ausschließlich über Tailscale, wie auch der Zugriff auf https://getwud.github.io/wud/#/ (automatische Docker Updates), beides braucht ja nicht ins Internet gelegt werden.

    Es gibt noch einige weitere Anwendungen, die dann neben dem Webinterface eigene Ports brauchen, hierzu lege ich in der FW jeweils ein Profil an, das dann pro Server aktiv oder eben nicht aktiv geschaltet werden kann. Ich baue da für jede Anwendung ein Set aus allen Ports, TCP/UDP etc.

  • Best Practice bei Serverumzug

    Ich nutze neue Server dazu, Debian von einer früheren Version auf die aktuelle Version abzudaten (11 -> 13 bzw. 12 -> 13 bei meinen beiden). Ansonsten lasse ich alles über Docker laufen und ziehe in erster Linie die Docker Compose Files rüber, mache mir dabei Gedanken, ob ich noch alles benötige und verbessere dabei an vielen Stellen (z.B. Healthchecks bei allen Containern, Modernisierung von App Komponenten z.B. Postgres 15.2 -> 17, dank Claude Code sogar wenns das Original Compose File eigentlich gar nicht vorsieht).

  • Installation Windows Server

    Zitat von M@ik

    Wichtig: vorher Disks formatieren und dann saubere Win Installation.

    Kann man auch bei der Windows Installation machen. Da wird einem auch nix anderes übrig bleiben, denn auf ein Linux Filesystem lässt sich eh kein Windows installieren.

    Weiterer Stolperstein: bei SSDs >2TB brauchts UEFI aktiviert. Das kann man im Nachhinein nicht mehr ändern.

  • Installation Windows Server

    Tips für einen Windows Server:

    - einen anderen Nutzer als "Administrator" anlegen, diesen in die Admingruppe bringen, dann mit diesem User einloggen und den "Administrator" Account deaktivieren.

    - https://tailscale.com/ auf dem Windows Server und dem Fernbedienrechner installieren und RDP nur über die VPN Verbindung machen.

    - die Netcup Firewall aktivieren und den RDP Port 3389 für TCP und UDP eingehend sperren.

    So schützt man sich von permanent stattfindenden Angriffen auf den RDP Zugang, der bei Verwendung von "Administrator" und schlechtem Passwort irgendwann zu einem gehackten Server führen würde.

  • Installation Windows Server

    Die Installation von Windows wird auf https://helpcenter.netcup.com/de/wiki/server…ws-installation beschrieben.

    Was dabei nicht explizit drin steht: nach Installation von Windows von der DVD und VOR erstem Neuboot ins lauffähige Windows muss in den Einstellungen beim Server im SCP natürlich die Bootreihenfolge wieder auf "Hard Disk" an erster Stelle geändert werden, da sonst der Server permanent nur von DVD bootet. Du kannst das auch nach erfolgter Installation (also jetzt) machen und den Server dann resetten. Er sollte dann von der Festplatte booten.

  • RAMpocalypse: An honest update on the hardware situation

    Puh. Da liest man mal ein paar Tage nicht mit und schon verpasst man die RAMpocalypse (ich feiere den Deal!). =O

    Hinsichtlich der Hardwaresituation verstehe ich Netcup absolut, ich kaufe selbst Serverhardware für den Job und die Situation ist komplett verrückt und das wird sich auch so bald nicht ändern. Wer sich hier beschwert und den Umfang dieses Problems nicht mitbekommen hat, sollte mal unter dem Stein hervorkriechen unter dem man in den letzten 3-4 Monaten gelebt hat. Dass Lieferanden derartig hart nicht liefern können, kenne ich in meinen >30 Jahren IT nicht bzw. nur punktuell und kurzfristig (Überschwemmung von Festplattenfabriken in Vietnam).

    Ich glaube nicht, dass die Situation in diesem Jahr besser wird, neue Fabriken werden erst 2028 online kommen, manche RAM Hersteller sind komplett vom Markt verschwunden. Wer mal auf HBA Speicher umgestellt hat, wird jetzt nicht so schnell wieder auf DDR5 umstellen. Insofern wird das eine lange Durststrecke. Man bekommt Hardware schon noch (schaue auch https://geizhals.de/ ), aber eben nur zu signifikanten Aufpreisen von je nach Sparte rund 50-300%. Was für Consumer Hardware gilt, gilt für Serverhardware genauso. Wenn man also höhere Einkaufspreise hat, müssen die Verkaufspreise auch höher sein. Ganz normaler Kapitalismus.

    Zu AI: hier haben sich ja viele negativ zu AI geäußert und glauben "dass die Blase platzt". Ich sehe das anders. Während ich natürlich die Hardwaresituation und das Wettrennen entsetzlich finde, sehe ich trotzdem das Potential der Nutzung von AI in vielen Bereichen und denke nicht, dass hier "eine Blase platzt".

    Wenn einem Claude Code bei diversen Themen auf der Konsole begleitet (z.B. habe ich damit meinen Docker Compose Stack auf meinen Netcup Servern optimiert, das Ergebnis war großartig), das ist schon toll und kann und wird neben vielen anderen Anwendungen sehr sehr nützlich sein. Jede(r) ist jetzt Entwickler, jede(r) ist Manager der eigenen Agentenarmee.

    Es wird Effizienzgewinne geben, wie das schon bei jeglicher Modernisierungswelle war (Manufaktur von Pferdewägen zu Model T am Fließband von Ford) und Dinge werden sich deutlich verändern (z.B. auch die Arbeitsrealität vieler Menschen). Viele Schwarzseher haben bei jeglicher Modernisierung (Schreibmaschine -> Computer; Fax -> eMail u.v.m.) immer schon die Welt untergehen sehen. Das ist nicht passiert. Statt dessen ging einfach alles effizienter und es kamen neue, nützliche Anwendungen hinzu.

    Insofern: holt Euch die RAMpokalypse Kaffeetasse, trinkt daraus einen guten Kaffee und "carry on". Und probiert doch auch mal Claude Code, es ist wirklich großartig, insbesondere auch für Einsteiger.