Beiträge von TCRserver

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

Zitat von pkambach

Da ja die SOAP-API eingestellt wurde (betrifft meinen zweiten Punkt oben), wollte ich das Ganze nun auf der REST-API aufbauen. Hat jemand da schon was umgestellt? Bei https://www.liveconfig.com/de/…html#creating-own-content wird auf die Beispiel-Dateien von der SOAP-API verwiesen

Klar, eine vollständige Integration in unsere Dienste.
Mit der Rest API ist es um einiges einfacher geworden, aber an manchen Stellen auch etwas verwirrend.
Im Prinzip ist die Doku sehr gut, sobald man es verstanden hat.
Woran klemmt es denn?

In diesem Setup wäre LAC eigentlich nur für den Web Server Relevant.
Ein Ausbruch aus einem Skript bzw. ein Shell Zugriff auf den DB oder Mail-Server macht keinen Sinn, oder?
Und eigentlich war ja der Plan von LC, dass man keinen expliziten C&C Server benötigt, sondern man einen ganz normal genutzten Server dafür nimmt. Somit könnte man den Webserver mit der Business ausstatten und den dann mit LAC.

Oder vielleicht reicht es ja auch aus einen Business Server als C&C zu nutzen und dann wird die Funktion auf die Standard Server vererbt.
So wie beim Let's Encrypt Feature. Das muss aber KK beantworten.

Zitat von kk

Meine persönliche Meinung (als Techniker und Nicht-Jurist) ist, dass E-Mail kein verlässlicher zweiter Faktor ist.

Der Grund ist banal: wenn das Passwort für LC via E-Mail zurückgesetzt werden kann, und Mail auch als 2FA genutzt wird, dann ist das eben nur ein Faktor.

Sehe ich auch so. Aber leider sind die Juristen keine Techniker...

Liest sich aber so, als ob es schon einen groben Plan für das Thema gibt.
Dann mache ich in meiner Checkliste mal einen Haken bei "In Planung".

Logging via Syslog - mit einem LC eigenen Dienst oder sowas wie z.B. GrayLog?

Ich würde hier gerne eine Diskussion zur NIS2 und LC3 eröffnen:

Meiner Meinung nach, müssten alle LC Accounts (die eine DNS Verwaltung ermöglichen) eine erzwungenen 2FA Aktivierung haben.
Derzeit ist in LC3, wenn ich es richtig gesehen habe, die 2FA Anmeldung optional.

Somit müsste eigentlich eine 2FA E-Mail Methode für LC3 nachgerüstet werden und eben einen Option zur Zwangsaktivierung.

Wie ist eure Meinung dazu und was ist Seitens LC3 schon in Planung dazu?

Wie kann man die Site-Pro Funktionen unter LC3 testen?
Aktuell finde ich keinen mod der für LiveConfig3 angeboten wird.