Beiträge von TCRserver

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.

Zitat von weltmeister

Bieten wir die Weiterleitungen nicht an, ist der Kunde weg...

Man muss die Regeln ja nicht in Stein meißeln.
Für manche Kunden gibt es durchaus auch Außnahmen.

Das wäre eine Option für die LC GUI, "Kunde darf Weiterleitungs-Sperre umgehen". Gleich mal einen CR schreiben

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.

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.

Ah ok, also nicht nur installieren, sondern auch gleich ein ganzes Feature Pack.
Dann macht das auch mehr Sinn. Weil runterladen und installieren... aber das hatten wir ja schon

Laravel ist doch ein PHP Framework, richtig?!
Warum muss man das jetzt auch noch via App Installer installieren?
Also so etwas sollte ich doch hinbekommen, wenn ich programmieren möchte. Oder habe ich das nicht verstanden?

Vielen Dank für den Aufwand, der uns das Leben leichter macht!

Zitat von antondollmaier

Wir sind seit 2013 bei http://www.smart-nic.services und sehr zufrieden.

Kann ich nur bestätigen! Auch wir sind vor vielen Jahren wegen einem Streit mit Internet X zu Smart-Nic gewechselt.

Und ja, der Umzug ist extrem aufwändig!
.de ist nicht das Problem, aber .com und Co.

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:

<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

Es öffnet die Option zum sperren des Kunden. Email, FTP und Web jeweils als Option. Drauf klicken ist ungefährlich, da passiert noch nichts.

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.

Damit uns nicht langweilig wird, kommt jetzt der Dirty Frag, wenn die Gerüchte stimmen. Dann kann man endlich mal wieder einen Kernel Patch einspielen.

https://github.com/V4bel/dirtyfrag/tree/master#mitigation

jein, man muss vereinfacht gesagt, den "PC" in irgendeiner Form dazu bringen ein Skript auszuführen mit beliebigen User Rechten. Und damit erreicht man dann Root. Da reicht theoretisch auch ein kompromittiertes WordPress aus.

lc-ext-sitepro ist der Name für LC3

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.

Berichte > Server
Zeigt nur 10 Server an, der Rest ist verschollen bzw. die übliche Anzeige für Anzahl Zeilen fehlt.

Wir sind auch mit dem Upgrade durch und es funktioniert soweit.

Mir fällt gerade auf, dass ein Debian 11 Server folgende Meldung beim Update ausgibt:

dpkg-deb: Fehler: Archiv »/var/cache/apt/archives/php-8.1-opt-hardened_1.1-1_all.deb« verwendet unbekannte Komprimierung für Element »control.tar.zst«, Abbruch

dpkg: Fehler beim Bearbeiten des Archivs /var/cache/apt/archives/php-8.1-opt-hardened_1.1-1_all.deb (--unpack):

Es trifft anscheinend nur die hardened Pakete. Alle anderen sind durch gegangen.

Ist hier etwas in den Paketen verrutscht?

Also dann fände ich MongoDB viel wichtiger als PG.

Also mit LC3 funktioniert es