Posts by pgloor

Ich sehe es wie aRaphael. Ich habe schon mehrere Web Server für verschiedene Zwecke in Go gebaut, aber eben immer dem Zweck entsprechend. Seit einiger Zeit nutze ich aber fast nur noch Caddy, da ich da alles fertig finde, was ich normalerweise benötige.

Was KI betrifft, da beschränke ich mich darauf etwa Strukturen oder repetitiven Code so erstellen zu lassen, wie ich ihn selber geschrieben hätte. Ansonsten lasse ich es lieber ganz, da ich immer noch gerne so programmiere, wie ich es immer getan habe, auch wenn es etwas länger dauert.

Alpine nutze ich manchmal unter Docker, d.h. apk ist für mich somit schon mal kein Fremdwort Es würde wahrscheinlich gut zu meiner Nutzung des Pico's passen.

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.

Nebst Email liessen sich mit Notes auch interessante Projekte realisieren. Ich war von Anfang an dabei und habe mit Notes 20 Jahre lang meinen Lebensunterhalt bestritten

Es interessierte mich einfach, weil ich mir jetzt auch ein Cloud VLAN eingerichtet habe und für meine Zwecke eigentlich den Sinn darin gar nicht richtig sehe. Ich habe allerdings zeitweise einen Server mit dabei, der mit dem externen Verkehr schon mal an die Grenzen zur Drosselung stossen kann.

Quote from KB19

Schuldigen gefunden: IN*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.

Mir scheint hier etwas mit der IPv6 Adresse nicht zu stimmen. Ein mtr von extern auf diese Adresse bleibt jedenfalls nach GW-Anexia.retn.net hängen.

Quote from TBT

Nö, nur darauf hinweisen, dass etwas einfacher, günstiger und performanter geht als dieser doch etwas komplexe Weg mit zig VPSes und Free VLANs.

Wie ist das eigentlich mit dem Traffic von netcup vServer zu netcup vServer der nicht über Cloud VLAN's geht? Wird dieser nicht belastet?

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.

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:

# 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.

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.

Ich denke nat ist das Zauberwort. So was in der Art in den before rules?

*nat
:PREROUTING ACCEPT [0:0]
-A PREROUTING -p tcp --dport 80 -j DNAT --to-destination external_ip:80
COMMIT

Ich werde mir das am Donnerstag oder Freitag mal anschauen.

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:

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?

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.

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.

Mein gerade erhaltener Gutscheincode ist nicht "error-contact-support". Er sieht gültig aus. Ob er es ist, wird sich noch zeigen.

Ist bei mir auch gerade reingeflattert.

Boah... unschön. War bei mir auch so.

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).

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.