Posts by -Manu-

Ja, der Post von mir vorhin hat mich doch nochmal bewegt nochmal alles durchzuschauen....lässt mir keine Ruhe^^.

Ich hab jetzt in den tiefen meiner Logs doch noch was gefunden:

Das Skript hat seine Mail rausgeblasen und sich dann beendet....in den System- bzw. Mail-Logs (ich nutze msmpt) finde ich aber zu den besagten Uhrzeiten (Wald vor lauter Bäumen wohl nicht gesehen) einen jeweiligen "timeout exceeded" (Mail-Server nicht erreichbar) zu meinem Netcup-Mail-Server "mx99b...."

D.h. entweder macht Netcup da seit neuestem Wartung oder der ist absolut busy, weil zu der Uhrzeit plötzlich alle Ihre nächtlichen Backup/Skript/Job/...-Mails versenden....glaube ich aber nicht, sonst wäre das nicht erst seit ein paar Tagen so.

Aber da ich testweise und erfolglos ja auch mal statt 04:00 um 04:30 das Skript hab laufen lassen und das andere Skript um 05:00 keine Mail-Probleme hat....ist der Mail-Server wohl ziemlich lange "nicht erreichbar".

Ich habe jetzt testweise Skript A statt um 04:00 auf 05:00 gesetzt und Skript B statt 05:00 auf 06:00....

Was ich mir ankreiden muss ist, dass mein Skript das im Rahmen der Fehlerbehandlung nicht berücksichtigt...das schickt raus und macht dann Ende.

Soviel ist es derzeit nicht, alles per Docker:

1. Dockhand (Container-Orchestrator)
   mMn besser als Portainer, da Dockhand (im Gegensatz zu Portainer) meine Container-Umgebung verwaltet "as it is".
   Portainer hat Probleme, Container-Dinge zu verwalten, die nicht über Portainer selbst erstellt wurden.
2. Bento PDF
   PDF-Multi-Tool, hat bei mir StirlingPDF abgelöst
3. Glances
   Systemstatus des Container-Hosts (da kann man immer mal "schnell schauen", was das System gerade treibt)
4. Calibre Web Automated
   EBook-Verwaltung
5. Shelfmark
   EBook-Suchmaschine mit automatischer Verwurstung der Ebooks in Calibre bei Download
6. Nginx Proxy Manager
   Reverse Proxy
7. RomM
   ROM-Verwaltung für Retro-Games, Spiele können direkt im Browser gespielt werden. So eine Art Calibre für Retro-Games.
8. Rustpad
   Online-Datei-Editor, der viele Syntax beherrscht. Per Link kann man bspw. Code-Snippets, Skripte,etc. mit anderen teilen und gemeinsam daran
   arbeiten.
9. Technitium DNS
   Hat bei mir AdGuard/Pi-Hole abgelöst. Sehr schneller DNS-Server der per Default die Root-Zonen abfragt und noch jede Menge anderer Spielereien
   mit sich bringt (Persistent Cache nach Reboot,etc.). Abfragen erfolgen per DoH an den ReverseProxy und gehen dann an Technitium.
10. Uptime Kuma
    Monitoring, sollte nicht unbekannt sein
11. Vaultwarden
    Passwort-Manager, sollte ebenfalls ja bekannt sein

zzgl. zugehörige Datenbank-Container für entsprechende, oben genannte Services

Ich hatte früher noch mehr Services, mit Containern geht das ja in der Regel recht fix. Aber ich betreibe derzeit nur Services, die ich auch wirklich nutze und nicht "Weil ich es kann, weil es halt schnell deployed ist"

Ich bin gerade verwirrt.

Ausgangssituation:

Ich habe 2 Skripte, welche um 04:00 (Skript A) und um 05:00 (Skript B) per crontab ausgeführt werden und bei (Miss)Erfolg eine Mail über ein mein Webhosting versenden. Das lief auch die letzten 3 Monate problemlos...ist ja auch kein Hexenwerk.

Seit dem 23.02.2026 habe ich folgenden Zustand:

Skript A läuft "as usual" um 04:00 durch, es kommt aber keine mehr Mail an...gem. Logs ist der Job aber (mit Mailversand) sauber durchgelaufen. Skript B läuft weiterhin wie immer problemlos um 05:00 mit erfolgreicher Mailzustellung.

Führe ich Skript A manuell aus:

Mail kommt an (nur tagsüber getestet)

Führe ich Skript A per cronjob testweise zu unterschiedlichsten Uhrzeiten aus (tagsüber bis spät Abends):

Mail kommt an

Führe ich Skript A wieder um 04:00 (oder auch testweise um 04:30) aus:

Mail kommt nicht an.

Führe ich Skript A um 05:00 wie Skript B aus:

Mail kommt wieder an

Weiter wollte ich das betroffene Zeitfenster nicht eingrenzen, da ich ja jedesmal die Nacht abwarten muss um mich "heranzutasten". Aber es scheint so, als ob irgendwann zwischen X und Y Uhr seit dem 23.02.2026 in der Nacht meine versendete Mail im Valhalla landet....

Bin ich jetzt doof!?

Die pragmatische Lösung wäre, zunächst auf Debian 12 zu bleiben. Das wird ja noch bis 10.06.2026 supported....und danach noch LTS bis Juni 2028.

Wenn das Ding nur für Jitsi ist, zeitgleich Debian 12 noch eine Weile bis EOL hat....warum dann upgraden, wenn Jitsi hier (noch) Probleme macht?

Es macht doch alles, was es soll....und ist supported in Bezug auf Sicherheitspatches.

Ich würde das entspannt solange aussitzen, bis Jitsi das geregelt hat....scheint ja logischerweise sehr viele zu betreffen.

Wer Kunde bei der Telekom ist (Mobil oder Fest):

Seit Anfang der Woche wird Cloudflare-Traffic seitens der Telekom wieder abgewürgt (Peering).

Die streiten sich schon seit Jahren, da Cloudflare nicht bereit ist die Vorstellungen der Telekom zu erfüllen.

Daher publiziert Cloudflare das auch nicht als "Fehler" im eigenen Netz, da die Telekom der Auslöser ist (=alles grün)

Bedeutet:

Wer versucht Services zu erreichen, welche hinter Cloudflare liegen: Langsam bis unbenutzbar

Wer eigene Services hinter Cloudflare betreibt: Langsam bis unbenutzbar

Es gibt immer Zeitfenster (mehrere Stunden) in denen alles wie gewohnt läuft, bis es wieder einbricht.

Derzeit geht es wieder....wie lange und/oder es nochmal einbricht, kann nur die Glaskugel beantworten.

Und da unglaubliche viele Betreiber Cloudflare nutzen (vor allem den Free-Plan)...sind auch entsprechend viele Erreichbarkeiten betroffen.

Seit heute morgen läuft bisher wieder alles...ich hoffe das bleibt so.

Quote from Marschi

Bei der lila Pest hast du einen extra APN für dynamic IP ohne v6.

Bei der blauen Pest zahlst du einmalig 60€ damit der APN freigeschalten wird.

Bei der roten Pest keine Ahnung.

Bei "Lila" also Telekom gibt es derzeit folgende, "reguläre" APN für Privatkunden.

internet.v6.telekom (Standard)

Hier wird 464XLAT angewendet, IPv6-only mit Umsetzung auf IPv4 (kein CGNAT, aber selber Effekt)

internet.telekom (Legacy)

Dual-Stack mit CGNAT IPv4 und IPv6

internet.t-d1.de

IPv4-only mit Public IPv4 (Dynamisch)

Wird offiziell nicht kommuniziert, gibt es seit der Jahrtausendwende.

-> den meintest du oder?

Quote from fisi

Meines Erachtens gehören Firmenrechner immer komplett gesichert, incl. OS usw.

Ab einer gewissen Größe des Unternehmens ist das hinfällig. Da werden die Rechner schlicht mit einem Image von Stand X neu betankt und anschließend per zentralem Software-/Patchmanagement mit der nötigen Standardsoftware bespielt und auf aktuellen Patchstand gebracht.

Ob das jetzt mit MECM (Microsoft Endpoint Configuration Manager) oder Intune oder sonstwas passiert....ist immer das selbe Programm. Da wird dann der Task "Buchhaltung" angestoßen und der Client bekommt alles an nötiger Standardsoftware für seinen Bereich.

Die Datenhaltung erfolgt ja nicht lokal auf dem Client, wenn dann ist komplett was schief gelaufen.

Selbst bei Unternehmen mit "nur" 30 Clients rennt da mMn doch keiner mehr mit einem USB-Stick rum und macht "Einzelbehandlung".

EDIT: Ich wüsste nichts, was an einem Firmen-Client am Betriebssystem "sicherungswürdig" sein sollte.

Ich hab das Upgrade vorhin durchlaufen lassen....wie erwartet sehr unspektakulär und in 3 Minuten durch (höchstens).

EDIT: Ich befand mich aber auch mit 13.2 auf dem aktuellen Patchstand, also es war das "reine" Upgrade auf 13.3

Meines Wissens nach werden da keine Anrechnungen durchgeführt. Du kannst das Webhosting kündigen und dir parallel einen vServer mieten.

Bei einem Webhosting bist du jedoch im Prinzip "Nutzer", während sich der Anbieter (hier Netcup) um den Unterbau kümmert.

In dem Moment, wo du dir einen vServer mietest.....bist du im Prinzip ab diesem Zeitpunkt Linux-Server-Administrator, der "auch" Python nutzt.

Wie der Umstieg bzw. die Migration aussieht, dafür bist du dann verantwortlich. Also deine bestehenden Projekte aus dem Hosting auf den vServer zu migrieren.

Ein eigener vServer bringt natürlich alle Freiheiten. Wenn man sich aber mit der Linux-Server-Administration nicht auseinandersetzen will oder das Know-How fehlt (völlig legitim), dann würde ich eher einen Wechsel zu einem Webhosting-Anbieter in betracht ziehen, der deine geforderten Features unterstützt.

Ich kann in deinem Post nicht erkennen, wie "fit" du im Umgang mit Linux-Servern bist.

Meine Erfahrung: Installiere mehrere Windows Server 2kXY exakt gleich mit selben Patchstand auf dem selben Node....die sind trotzdem nicht "gleich", in der Tiefe (ob man es glauben mag oder auch nicht) bestehen da durchaus Abweichungen.

Zumal besonders W2K25 auch nach Release noch mit vielen Bugs zu kämpfen hatte.

Wir haben in der Arbeit noch überwiegend W2K19 im Einsatz, aber die W2K25 machen durchaus "komische Sachen" oder Verhalten sich unerwartet.

Mit 2K22 hingegen hatten wir in anderen Umgebungen absolut keine Probleme.

Ich sehe das Problem rein aus technischer Sicht zunächst(!) eigentlich nicht am Hypervisor, sondern an einem Treiber.

Du könntest Testweise in Chrome die Hardwarebeschleunigung deaktivieren oder auch bspw. Firefox verwenden.

Das gilt aber auch für "klassisch", da nimmst du ja auch nur Quellen (Installationsdaten, Repositories) von "trusted" Sources...und nicht von "CrazyMax3000".

Wenn ich den offiziellen Container-Images von bspw. Mailcow nicht vertrauen kann/will/möchte....dann kann ich ebenso auch nicht von denen irgendwelche "klassischen" Installationsdaten/-quellen benutzen.

Mir war nicht bewusst, dass ich mit meinem Halbsatz so eine Kontroverse auslöse^^

Aber....sollten wir woanders diskutieren, wäre bestimmt interessant (die verschiedenen Ansichten). Hier sind wir damit im falschen Thema.

Und irgendwann lernst du Container (Docker/Podman)....und fragst dich, wieso du jahrelang den ganzen Krampf wie ein Steinzeitmensch "nativ" auf dem System installiert hast.

Aber das ist ein Thema für einen anderen Thread :-)...gibt ja auch gegensätzliche Meinungen.

Dann Glückwunsch.

Und auch die (vorherigen) Mißerfolge muss man immer positiv sehen....man kennt dann 68 Wege, wie es nicht funktioniert....was ja auch das Wissen und den Erfahrungswert steigert

Wenn es um um u.a. WAF geht: Self-Hosted Bunkerweb

....wenn man sich da ran traut, dass vollends einzurichten/konfigurieren

Ich bin überzeugt, es liest sich ggf. anders als es tatsächlich gemeint war .

Quote from Bud

Welche wirklichen Vorteile bringen mir Monitoring-Tools wie checkmk und Netdata gegenüber solchen Leichtgewichten wie munin und Beszel?

Also, mir ist schon bewusst WAS genau sie mehr können, aber welchen usecase hat das wirklich? Wenn wirklich mal live-Daten relevant sind, mache ich das meistens schmerzlos über htop

Im Privatbereich bin ich da relativ stumpf, da interessiert mich nur "geht" oder "geht nicht(mehr)"....und da langen mir persönlich die Funktionalitäten von Uptime Kuma.

Und wenn was ist, dann gehe ich auf die Kiste und schaue warum und wieso und weshalb.

Beruflich wäre das eher semi-geil...

Das sind zu viele Clients, zu viele Server, zu viele Services, zu viele Kommunikationsbeziehungen, zu viele Verzahnungen, zu viele dislozierte Standorte, zu viel Blech, zu viele Cluster, zu viel VMs/Container...und und und.
Da will man dann bspw. schon rechtzeitig wissen, wenn irgendwo in Deutschland bei einem Server die Platte anfängt vollzulaufen (aus welchen Gründen auch immer)....oder irgendein Systemdienst meint, er hat jetzt einfach mal keine Lust mehr zu funktionieren.

Natürlich variieren die Relevanzen "WAS" gemonitored wird je nach Fachbereich.

Wer für die Infra verantwortlich ist, hat natürlich andere Interessen am Monitoring als Verantwortlichkeiten für die Funktionalität von Services,etc.

Wir haben auch große Fernseher in den Büros, mit entsprechenden Dashboards um zumindest direkt sehen zu können, ob alles Grün ist oder irgendwas das Mucken anfängt.

Aber der Usecase ergibt sich aus den Anforderungen....privat würde ich mir das nicht mal im Ansatz vorstellen.

Da langt mir eine Mail mit "ACHTUNG! nginx-service nicht mehr erreichbar!"

Der Rest ist dann "IT-Handwerker-Elektrobäcker-Style" am Server wegen dem "Wieso?"

Ich habe jetzt auch dem Support geschrieben, mal schauen was passiert.

Ist jetzt nicht eilig, ich hab Jahre ohne das Ding überlebt...das kommt jetzt auf die paar Tage (oder Wochen ) auch nicht drauf an.

[netcup] Lars S.

So, ich hab jetzt nochmal etwas getestet:

STEP 1 - Ausgangssituation

Firewall steht auf ANY:ANY

any_any.png

Ergebnis: Alles funktioniert, alle Kommunikationsbeziehungen werden zugelassen

STEP 2

Hinzufügen einer Policy, welche nur SSH und ICMP eingehend erlaubt (da mein SSH-Port versetzt ist, hier geschwärzt)

ssh_icmp.png

Ergebnis: Nach ca. 1 Minute keine SSH-Connection mehr möglich

STEP 3

Austauschen der Policy, welche SSH, ICMP und HTTPS eingehend erlaubt

ssh_https_icmp.png

Ergebnis: Nach ca. 15 Minuten abgebrochen, da bis hierhin alle eingehenden Verbindungen gem. Firewall durchgehend funktionierten

STEP 4

Erneuter Austausch der Policy gegen die aus STEP 2

ssh_icmp.png

Ergebnis: Nach ca. 1 Minute keine SSH-Connection mehr möglich

STEP 5

Erneuter Austausch der Policy gegen die aus STEP 3 (welche augenscheinlich funktioniert hatte)

ssh_https_icmp.png

Ergebnis: Nach ca. 1 Minute keine SSH/HTTPS-Connection mehr möglich

Im Fazit doch augenscheinlich *random"

Ich habe den Server heruntergefahren, nochmal alle Regeln komplett neu gemacht, Server wieder hochgefahren.....aber nach anfänglicher Freude war dann leider nach einigen Minuten erneut alles dicht.

Die Ports (leider nicht auf dem Screenshot) sind weiterhin 0815 auf den Destination-Port.

Screenshot 2025-12-10 17.20.42.png