Posts by pgloor

  • Vorsicht beim Pico und Ubuntu LTS Upgrade

    Nach genau 10 Jahren Ubuntu habe ich gestern zum ersten Mal darüber nachgedacht wieder zu Debian zurückzukehren. Mein Pico ist aber nicht der Hauptgrund dafür. Den lasse ich einfach mal auf Noble weiter laufen. Es ist viel mehr der Trend von Canonical, der immer mehr Abhängigkeiten schafft an denen ich keinen Gefallen finde.

  • Das längste Thema

    Quote from KB19

    Schuldigen gefunden: IN*X X/

    Offenbar ist DNSSEC auch bei anderen Anbietern mal kaputt: The Signature Expiration field of the RRSIG RR (2026-04-02 00:00:00+00:00) is 1 day in the past.

    Wobei es eher danach aussieht, dass die verschiedenen Nameserver von denen nicht mehr synchron sind. Manche hängen auf einer Serial von März fest, neue Records werden auch nicht mehr überall sichtbar.

    Und ist das Problem jetzt behoben? Ich habe all meine Domains und die, welche ich sonst noch irgendwie betreue, dort. Sie haben alle DNSSEC aber ich hatte bisher nichts davon mitbekommen.

  • Wireguard - ufw Port Forward auf localhost

    Was meine Server-Software betrifft, so ist es nicht so trivial. Sie ist modular aufgebaut und unterscheidet zwischen internen und externen Schnittstellen, bzw. Ports. Das ist zwar alles konfigurierbar, war mir aber für meine Zwecke zu komplex. Ich brauche die Verbindung über Wireguard nur um ein Modul zu testen an dem ich arbeite und so kann ich auf dem Port und der Schnittstelle aufsetzen, die normalerweise konfiguriert und verwendet wird.

  • Wireguard - ufw Port Forward auf localhost

    Meine Lösung: Wireguard, wie gehabt. Nichts weiter geändert. Auch ufw, belassen wie es von mir oben in #1 beschrieben ist. Dann Caddy installiert und konfiguriert.

    In /etc/caddy/Caddyfile habe ich im wesentlichen diesen Eintrag hinzugefügt:

    Code
    # Access demo from home LAN
:9000 {
    bind 10.121.1.1
    reverse_proxy localhost:9000
}

    Anschliessend das Caddyfile mit sudo caddy fmt --overwrite /etc/caddy/Caddyfile sauber formattiert und mit sudo systemctl reload caddy Caddy neu gestartet. Dann, nach einen ersten Test, den Server neu gestartet und weitere Tests mit der echten Anwendung gemacht. Im Rahmen einer halben Stunde war alles erledigt.

    Mit dem ufw *nat Prerouting hätte ich mich intensiver befassen müssen, denn beim ersten Versuch bin ich gar nicht mehr auf den Server gekommen und musste zuerst mal über das Rescue System die Datei /etc/ufw/before.rules wieder korrigigieren.

    Nginx wäre auch eine Lösung gewesen, aber ich kenne Caddy schon lange und besser. Es kann aber durchaus Fälle geben, in denen Nginx die bessere Wahl, oder sogar notwendig ist.

    Ich bin jetzt mit dem was ich mit dieser Lösung erreicht habe sehr zufrieden, zumal ich damit ausschliesslich Systemkomponenten verwende, die ich aus diversen Projekten bereits gut kenne.:)

  • Wireguard - ufw Port Forward auf localhost

    Das einzige was dagegen spricht auf der 10.121.1.1 zu lauschen ist, dass ich noch lokale Prozesse habe, welche über die gleiche Schnittstelle auf die API zugreifen. Ich dachte über eine Portweiterleitung wäre am einfachsten.

    Ich werde nochmals einen Versuch starten und falls es nicht klappt, nutze ich einen Proxy. Mir ist wichtig, dass die Lösung so einfach und klar wie möglich ist. Edge-Cases von denen man nicht so recht weiss, was dahinter steckt, mag ich nicht. Zur Zeit habe ich auf all meinen Servern einen Proxy, aber ich dachte, dass ich mir das sparen kann.

    Danke für eure Hinweise. Ich hatte gestern einen etwas stressigen Tag - Serverumzug etc - an dessen Ende ich vor lauter Bäumen den Wald nicht mehr gesehen habe.

  • Wireguard - ufw Port Forward auf localhost

    Ich habe gerade einen Knopf in der Leitung, weshalb ich mich an euch wende. Ich habe auf einem VPS mit Ubuntu 24.04 eine Server-Anwendung die auf http://127.0.0.1:9000 horcht. Der Client dazu befindet sich auf meinem PC zu Hause. Als Firewall benutze ich auf beiden Seiten ufw.

    Jetzt habe ich Wireguard eingerichtet. Dabei nutzt Wireguard das Netzwerk 10.121.1.0/24. Der Server hat daraus die Adresse 10.121.1.1 und mein PC die Adresse 10.121.1.2. Horcht der Anwendungs-Server auf dem VPS auf alle Adressen, also z.B. auf http://0.0.0.0:9000, dann kann ich mit curl http://10.121.1.1:9000 problemlos über Wireguard auf die Anwendung zugreifen. Damit das soweit funktioniert habe ich in der ufw auf dem Server folgende Regeln gesetzt:

    Code
    To                         Action      From
--                         ------      ----
51820/udp                  ALLOW       Anywhere                  
10.121.1.1 9000/tcp on wg0 ALLOW       Anywhere

    Aber was, wenn meine Anwendung auf http://127.0.0.1:9000 hört? Bis jetzt habe ich das nicht hinbekommen.

    Ich nutzte Wireguard schon vorher, aber da lief die Anwendung in einem LXD/LXC Container und ich konnte das Problem über das Forwarding an den Container lösen. Jetzt habe ich aber keine Ahnung, wie ich das so hinbekommen kann, dass der Port 9000 der über wg0 reinkommt sozusagen an 127.0.0.1:9000 weitergeleitet wird.

    Die folgenden sysctl-Settings könnten noch von Bedeutung sein. Das sind die aktuellen Werte:
    sysctl net.ipv4.ip_forward = 1
    net.ipv4.conf.all.route_localnet = 0

    route_localnet auf 1 zu setzen hat bisher nichts gebracht, deshalb habe ich es wieder auf die Vorgabe zurückgesetzt.

    Auf dem VPS läuft übrigens ansonten noch gar nichts. Also kein Docker oder LXD oder sonstwas, das ufw oder iptables beeinflussen könnte.

    Was hab ich noch nicht verstanden?

  • Das längste Thema

    Wie läuft das eigentlich mit gekündigten Servern? Werden die sofort wieder bestellbar, wenn davon keine mehr verfügbar sind?

    Oder anders rum gefragt: ich suche zur Zeit ein VPS 3000 ARM G11 oder VPS 4000 ARM G11 und gehe deshalb 4 - 5 Mal täglich vergeblich auf die Seite mit den vServer (ARM64)-Angeboten. Obwohl oben auf der Seite ein Hinweis steht, dass die VPS ARM aktuell ausverkauft sind, klicke ich mich trotzdem immer durch die von mir in Frage kommenden Server und Standorte, in der Hoffnung, dass vielleicht doch einer bestellbar ist. Macht das überhaupt Sinn?

    Vielleicht kennt jemand von euch einen Weg, wie man das automatisieren könnte. :)

  • Neuer Gutschein (nicht)

    Ganz unten in der Mitte im Kleinstgedruckten gibt es noch einen Link unter "Hier abmelden", wenn du keine weiteren E-Mails erhalten möchtest.

    Aber ganz ehrlich? Den würde ich sicher nicht anklicken!

    Ansonsten bin ich der Meinung, nur wer nichts tut, macht keine Fehler.

  • Linux UEFI Boot

    Quote from Pappmann

    Gibt es noch Distros die UEFI Boot nicht unterstützen und wäre es nicht sinnvoll, UEFI Boot standartmäßig zu aktivieren?

    Gute Frage, die ich mir auch gerade stelle. Ich verstehe insbesondere nicht, warum bis dahin BIOS weiterhin empfohlen wird (Until then we still recommend installing images with BIOS).

  • Wofür nutzt Ihr eure VPS Piko und Nano?

    Seit ich ihn habe nutze ich ihn für kleine statische Web-Seiten. "Versteckt" liegt da auch noch eine Web-Site, die vor einem Jahr neu erstellt und abgelöst wurde. Gerade erst heute brauchte ich sie um etwas nachzuschauen, von dem keiner mehr wusste, wie es gemacht war.

    Geplant ist meinerseits schon lange den auch für Monitoring zu nutzen.

  • Das längste Thema

    Quote from Blue_Gamer48

    kann man einer anderen Persohn zugriff euf einen root server per servercontrollpanel geben so das 2 accounts auxch neuinstallieren können?

    Das steht schon seit langem ganz oben auf meiner Wunschliste. Ich hatte schon öfters den Fall, dass ich gerne einer zweiten oder gar einer dritten Person Rechte auf gewisse Funktionen im Control Panel eines Server gegeben hätte. Beispiele bei mir waren insbesondere Neustarts und IPv6-Adressvergaben. Neuinstallation an Dritte zu vergeben, das hatte ich noch nie, aber ich kann mir durchaus Fälle vorstellen, wo auch das Sinn machen könnte.

    Wie machen das andere mit Stellvertretungen und dergleichen?