Beiträge von TCRserver

  • CVE-2026-109618 und CVE-2026-109619

    Es wäre ganz gut, einen Überblick zu bekommen, welcher Kunde welche PHP Version benutzt. Es muss ja nicht unbedingt eine GUI Ausgabe sein. manche Dinge könnten auch rein für die API ausgegeben werden.


    UND wenn eine PHP Version in LC nicht mehr zur Verfügung steht, dann muss das LC erkennen und eine Warnung ausgeben bzw. eine Default Version verwenden.

    Bei den ganz wenigen Kunden die noch uralt PHP Versionen aktiv haben, mussten wir gestern nach einem apt remove der Versionen, manuell die PHP Version bei den Domains anpassen.

  • E-Mail-Weiterleitung an fremde Provider nur mit aktiven Spamfilter

    Zitat von Systemhaus-EHST

    wir haben 24 Postfix Servern und 9 Exchange Servern die Ihre E-Mails eingehend und ausgehend über 2 MX (Proxmox Mailgateways) bekommen.
    Man hat dann ein Zentrales Mail Log für alle Server und Mail Queue falls ein Server mal ausfällt.


    Genau so haben wir es auch gelöst. Div. Mailserver laufen durch zwei PMG die als Cluster arbeiten.
    Im Prinzip sagt man via API dem Proxmox Mal Gateway an welchen Server die E-Mails weitergeleitet werden sollen und welche Domains es gibt.

    Hier kann man z.B. auch Abusix, Sanesecurite, Spamhaus und Co einbinden.
    Im Prinzip ist es auch nur ein Spamassassin mit Clamav und einer GUI.

    Der Einstieg ist evtl. etwas verwirrend, aber später hilft einem das Trackingcenter bei der Suche nach verschollenen Mails unheimlich gut weiter.

  • E-Mail-Weiterleitung an fremde Provider nur mit aktiven Spamfilter

    Wenn man ausgehenden Mail Traffic SPAM Filtern möchte, dann kann man ein PMG oder anderes SPAM Gateway davor schalten.

    Das Problem dabei ist, dass dieses Gateway dann auch DKIM und Co. übernehmen muss, sobald es wie z.B. MS einen Header verändern will.

    Ist kein all zu großes Problem, aber es ist auch keine Freizeit Admin Aufgabe die man mal eben mit einem klick einschaltet und die dann für immer problemlos läuft.


    Generell ist aber die Frage: Welches Support Ticket besser ist (Aufwand sind Beide):

    Meine weitergeleitet Mail kommt nicht an weil Sie vom ausgehende SPAM Filter gefressen wurde

    oder

    Meine Mail wurde abgewiesen weil ich ein SPAMer bin.


    Wir haben hier die Beste Erfahrung mit dem Ratelimiting gemacht.

    Ausgehende Mails beschränken UND Weiterleitungen nach web.de, gmx und Co. einfach beschränken.

    Bei uns landen täglich die unglaublichsten Anfragen wegen DSGVO und Co. aber jede noch so dusselige Mail wird an ein Freemail Konto weitergeleitet...
    Man muss manchmal auch einem Kunden erklären ab wo seine Handlungen grenzwertig sind.


    Zitat von comsystem

    Du fragst ob man eine Funktion einbauen könnte.

    Willkommen bei Liveconfig (die Antwort haste dir gleich selbst gegeben,... )

    Also wenn ich mir das Changelog ansehe, habe ich da einen anderen Eindruck.

  • Servicegebühr bei InternetX

    Zitat von WebService4U

    Ich hatte gestern einen sehr netten Kontakt zu Smart-Nic. Sehr angenehmer und ehrliche Kommunikation und ich würde ja sofort dorthin umziehen. Leider habe ich nur ein Problem: Mein DNS-Setup. Die Liveconfig-Server sind der primäre Nameserver, die Nameserver von InternetX sind die sekundären, die IP von InternetX für AXFR ist in Liveconfig hinterlegt. Ich lege die Domain in LiveConfig an und registriere sie dann bei InternetX im Modus "nur sekundäre Nameserver" und hinterlege den LiveConfig-Server als primären Nameserver. Das wars. Funktioniert einwandfrei. Leider kann Smart-Nic das nicht und das ist für mich gerade der Showstopper. Leider. Aber vielleicht hat ja einer der Kollegen hier eine Lösung für mich.

    Warum nicht gleich alle Nameserver von LiveConfig betreiben lassen? Funktioniert seit Jahren sehr gut bei uns. Ich habe den Vorteil des Hidden Primary nie wirklich verstanden.

  • Symbol "sperren"

    Zitat von chrisu

    Es macht genau das bei mir eben NICHT!


    Und da es keine Doku dazu gibt, frage ich eben nach...


    Ich habe das ganze soeben bei einem Test Account von uns getestet.

    Die entsprechende conf unter /etc/apache2/sites-available/ wurde verändert und folgender Eintrag für alle Domains aus dem Vertrag gesetzt:


    Apache Configuration
    <IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^/\.errorFiles/.* - [L]
RewriteRule .* /.errorFiles/suspended.html [R=503,L]
</IfModule>

ErrorDocument 503 /.errorFiles/suspended.html

    Jetzt gab es aber in der Tat ein Problem, ein Reload des Apache hat nicht funktioniert und deswegen hat die Änderung in der Tat nicht gegriffen!

    Warum der Reload nicht funktioniert hat, keine Ahnung, das muss ich selber noch klären evtl. hat unattended-upgrades ein Update eingespielt und den Apache nicht neu gestartet...
    Auf jeden Fall gab es keinen Reload und somit hat die Änderung nicht gegriffen.
    NACH einem manuellen Neustart vom Apache2, funktioniert das sperren und aktivieren wieder perfekt.
    LC3 verändert die conf und setzt erfolgreich den Reload ab.

    chrisu
    Jetzt wäre doch spannend zu Wissen ob es nach einem manuellen Neustart vom Apache2 funktioniert.

    Der Vollständigkeit halber:

    Debian 12

    LC3 3.2.2

    https://github.com/LiveConfig/lc3/issues/133

  • LiveConfig 3.2.2

    Zitat

    (PS: der Vollständigkeit halber: alleine letzte Woche wurden nochmal 381 (!) PHP-Pakete aktualisiert, die Versionen 5.6-7.4 erhielten nun auch noch Security-Backports)

    Danke!
    Das ist so eine unglaubliche Entlastung.

  • LiveConfig 3 - Passwort generieren bei Kunden anlegen, E-Mailadresse anlegen & Co.

    Ich finde XKCD Passwörter richtig gut.

    Gerade im Support machen mir die Passwörter das Leben deutlich einfacher.

    Zumal es ja auch nur einmal Passwörter sind ;) und man es mit LiveConfig jetzt ja auch erzwingen kann, dass die Passwörter geändert werden müssen.

    Und dann kann ja jeder ein beliebiges Passwort setzen.


    Wo es in der Tat ungewohnt ist, sind Datenbank Passwörter.
    Hier neige ich auch dazu, klassische zufällige Zeichenfolgen zu verwenden.


    Generell halte ich die XKCD Passwörter aber für eine deutlich sicherere Variante, da die Kunden insgesamt zu längeren Passwörtern neigen und sich somit auch die Entropie erhöht.
    Und (der für mich wichtigste Punkt) wir seit dem Einsatz von XKCD auch deutlich weniger Rücksetz-Anforderungen haben.