Beiträge von TCRserver

  • Debian Trixie

    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 :D
    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 ;)

  • Debian Trixie

    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.

  • LiveConfig 3

    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.

  • Debian Trixie

    Hallo Klaus,


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


    Code
    # 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?

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

  • LiveConfig 3

    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. :D
    Woran klemmt es denn?

  • Ausblick auf das nächste große Release

    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.

  • LC3, NIS2 und zwangs 2FA

    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?

  • LC3, NIS2 und zwangs 2FA

    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?

  • Apache startet immer mal wieder neu

    Gute Idee, aber der ist es nicht. Der macht brav um 0:00 seine Rotation und der Apache hat dann um 07:50:24 einen Neustart gemacht.

    Dem Log nach ist es ein ganz normaler Restart, ausgelöst durch systemd.


    Ein CronJob ist es nicht und auch systemctl list-timers zeigt nichts passendes.
    Irgendwann werde ich noch drauf kommen.

  • Apache startet immer mal wieder neu

    Hallo Klaus,


    bei allen LC Servern meldet das Monitoring immer mal wieder einen Neustart vom Apache.
    Meistens im Abstand von ca. 24 h und oftmals auf allen Servern innerhalb von einer Stunde.

    Tut nicht weh und macht nichts kaputt, aber ich verstehe es nicht. Das ganze tritt seit vermutlich 2 Monaten auf.

    In den Logs oder den Metriken sehe ich keinen echten Grund dafür.
    Hat hier LiveConfig evtl. seine Finger mit im Spiel?

  • License Request failed

    Hallo Klaus,


    bei immer mehr Clients und auch Server fällt auf, dass ein Restart von LiveConfig fehl schlägt.

    Ursache ist, dass eine Abfrage der Lizenz fehl schlägt.
    Wenn ich die Lizenz entferne und neu lade, dann funktioniert es wieder.


    Code
    Jun 29 11:26:24 s17 lcclient[4667]:  - /usr/sbin/lcclient: Trying to renew license (serial# xxxxxxxx). Please wait a moment...
Jun 29 11:26:24 s17 lcclient[4667]:  ok.
Jun 29 11:26:24 s17 lcclient[4667]: Sending license request... ok.
Jun 29 11:26:24 s17 lcclient[4667]:  - /usr/sbin/lcclient: renewal failed: License request failed: Missing renewal token
Jun 29 11:26:24 s17 lcclient[4667]:  - /usr/sbin/lcclient: LiveConfig Client 2.18.0-dev20250526.1 starting...
Jun 29 11:26:24 s17 systemd[1]: Started lcclient.service - LiveConfig Client.

  • LiteSpeed Unterstützung?

    Zitat von kk

    Zudem testen wir bei einem Projekt einen serverweiten Brute-Force-Schutz für Wordpress (das ist ein immer häufigerer Grund für lang dauernde und teils extrem hohe Serverlasten).

    Ohja! Das Thema wäre extrem wichtig.
    Die "nutzlosen Anfragen" an WordPress werden immer mehr.
    Und die Plugins in den WordPress Installationen auch immer mehr. Dadurch gibt es extrem viel Blindleistung die einiges an Performance kostet.
    Durch kontinuierliches manuelles überwachen der Logs (zusätzlich zu div. Fail2Ban Filter) und ausfiltern von solchen nutzlosen Anfragen, bekommen wir die Load durchaus um 1-2 Punkte reduziert. Was sich Positiv in der Stromrechnung und der Performance bemerkbar macht.

    Beim LiteSpeed ist das aktuell größte Problem, dass Konfigurations-Änderungen in den .htaccess Dateien durch einen Neustart geladen werden.
    Das macht bei Docker Instanzen nichts aus. Wenn man aber auf einem Shared Host System permanent den http neu startet, dann sorgt das unter Umständen für reichlich Probleme.

  • LiteSpeed Unterstützung?

    Aus meiner Sicht wäre nur die kommerzielle Variante von LiteSpeed spannend.
    Aber die Nachfrage dafür ist in der Tat äußert gering.
    Und mit etwas Leidenschaft, kann man sicherlich den Apache oder auch den NGINX zur gleichen Performance bringen.
    Bottleneck dürfte auch eher PHP sein als der eigentliche http-Server.

  • Ausblick auf das nächste große Release

    Dann schreibe ich doch gleich noch ein paar Issues fürs lange Wochenende :D


    Kann ich eigentlich die aktuelle LC2 Datenbank auf dem LC3 Server nutzen, ohne dass die ganzen Clients angebunden sind?

    Also nur die DB kopieren und dann mit realistischeren Daten meine API Anbindung testen?

  • Bruteforce Angriff hebelt LiveConfig aus, fiktive E-Mail Adresse sendet SPAM - Was könnte man tun?

    Brute Force ist jetzt nicht unbedingt eine Lücke...

    Wenn man die Zugangsdaten hat, dann hat man "legitimen" Zugriff auf das Mail System.

    Hier hilft dann sowas wie fail2ban oder sshguard gegen zu häufige Anmeldeversuche.


    Anhand des Log Auszugs kann ich nichts erkennen.

    Im Prinzip müsste man die Queue prüfen wo die Mails her kommen, also von welchem Kunden oder ob die von z.B. PHP versendet werden.


    Code
    cd  /var/spool/postfix
find active bounce deferred incoming maildrop -type f | wc -l

    Wenn hier irgendwas größer 10 raus kommt, dann würde ich anfangen die Queue zu prüfen.

    Um danach zumindest mal den permanenten Versand zu beenden, könnte man temporär die Mailserver stoppen.

    Dann fängt die Suche nach dem Versender innerhalb des Systems an.