Beiträge von TCRserver

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

Über den GET /accounts Request und dann im Response nach "usage:webspaceUsed" suchen.

Kunden bekommen keinen Zugriff auf das PMG.

Das ist zu verwirrend. Einfach die Einstellungen aus dem LiveConfig holen (mit LC3 geht es einfach via API) und dann die Daten ins PMG (ebenfalls API) schreiben.
Der Kunde stellt alles im LC ein und die Daten werden ans PMG übertragen. Einige der Funktionen im PMG muss man auch deaktivieren, z.B. Quarantäne. Im Prinzip nutzt man PMG nur als Admin.

Und wie gesagt, im nachhinein hätte ich den gleichen Effekt auch mit einem LiveConfig mit SA hinbekommen.
Da PMG ja auch nur auf SA setzt!

Ich glaube egal ob SA oder Rspamd, man muss sich mit der Thematik auseinandersetzen, die Mailflut monitoren und es regelmäßig auf seinen Mailverkehr anpassen.

Wir haben PMG Vorgeschaltet, Abusix integriert und pflegen zusätzlich eigene Regeln. Damit fahren wir ganz gut.

Beim PMG ist halt die Oberfläche und das Cluster ganz nett. Dafür muss aber auch Transports, Relay Domains und DKIM gepflegt werden.
Im Nachgang wäre das gleiche mit SA möglich gewesen oder auch mit Rspamd. Aber einfach nur einschalten und laufen lassen, bringt nichts.
Egal welcher Filter dran hängt.

Wir sind auf LC3 gewechselt und ja es gibt noch Probleme. Aber keine Showstopper.
Von dem her kann ich es empfehlen, aber ich verstehe es auch, wenn man noch wartet.
Kommt vermutlich ganz darauf an wie man LC nutzt.

Die meisten unserer Probleme kommen vom Datenbestand bzw. vom nicht Testkonformen zustand unserer Server
Hier mal ein Account nicht sauber gelöscht, hier mal ein korrupter Eintrag, ein fehlgeschlagenes Update, irgendwas rumgepfuscht, eine Funktion missbraucht für eigene Zwecke, usw.

Immerhin pflegen wir den ältesten Cluster auch schon seit über 13 Jahren und haben div. Serverumzüge damit gemacht.

TLS-Zertifikate funktionieren bei uns problemlos. Zum Glück.
Aber ja, sowas wäre auch bei uns ein Showstopper.

Trixie scheint in der Tat nicht ganz einfach zu sein. Den Vorteil, warum man am Veröffentlichungs-Tag einen Server auf Trixie upgradet verstehe ich nicht so richtig.

Wir setzen jetzt dann mal einen Testserver auf und binden diesen in den Cluster ein. Und dann mal schauen was passiert und irgendwo zum Jahresende wenn es ruhiger wird, dann planen wir die Upgrades ein. Ich kenne aktuell auch keinen wirklichen Vorteil von Debian 13 ggü. 12.

Und zu den mangelnden Rückmeldungen... Bayern und BaWü sind jetzt in den letzten Wochen der Sommerferien. Könnte also sein, dass auch einfach das Team kleiner ist aktuell, weil im Urlaub

Was sagt denn dig meinedomain ANY @meinnameserver oder ein Test der Zone mit Zonemaster?

https://zonemaster.se/en/run-test

Damit müsste sich ein Fehler im DNSSEC bzw. mit den Nameservern finden lassen.
Aber insgesamt mehr Infos wäre schon ganz nett. Laufen alle Server Dienste korrekt, Logfiles, Was sagt das Logfile von den Nameservern, etc.

Zitat von Nomflow

Da auf viele der speziell in diesem Thread gemeldeten Beiträge bisher keine offizielle Stellungnahme/Rückmeldung erfolgte, sei mir folgende Nachfrage gestattet: wann kann mit weiteren Fixes/Updates diesbezüglich gerechnet werden?

Wäre es möglich, dass alle User zu den Fehlern GitHub Issues anlegen?
Dann hätten wir auch den Überblick was schon gemeldet ist, und was noch offen ist.
Die Übersichtlichkeit hier im Forum ist, durchaus etwas schwierig, da alles in einen Thread gepostet wird.

Ich glaube das würde auch den LC Entwicklern helfen.

ja richtig.

Hallo Klaus,

bei mir sind noch immer Dienste maskiert nach der Umstellung auf lcclient3 (3.0.2).

# systemctl list-unit-files | grep masked
lcbackup.service                       masked          enabled
lclogsplit.service                     masked          enabled
lcpolicyd.service                      masked          enabled

Sind das noch die alten dienste von LiveConfig2?

# ls -l /etc/systemd/system
...
lrwxrwxrwx  1 root root    9  9. Jun 09:03 lcbackup.service -> /dev/null
lrwxrwxrwx  1 root root    9  9. Jun 09:03 lclogsplit.service -> /dev/null
lrwxrwxrwx  1 root root    9  9. Jun 09:03 lcpolicyd.service -> /dev/null
lrwxrwxrwx  1 root root    9  9. Jun 09:03 lcsam.service -> /dev/null
...