Beiträge von TCRserver

  • logrotate files zerschossen

    /etc/logrotate.d/clamav-milter

    Code
    /var/log/clamav/clamav-milter.log {
     rotate 12
     weekly
     compress
     delaycompress
     create 640  clamav adm
     postrotate
     invoke-rc.d clamav-milter restart > /dev/null || true
     endscript
     }


    /etc/logrotate.d/liveconfig


  • Fehler bei manuellen Backup

    Bitte mäßigt doch den Ton bei solchen "nicht" Reaktionen. Das ist nicht nett...
    Vor allem wenn man anscheinend keinen Plan von LC und den aktuellen Problemen hat.


    Zu dem ganzen Problem:


    LC 2.14.4
    Beim erstellen eines manuellen Backups über die Backup BETA Funktion von LC kommt folgende Fehlermeldung:


    An error occured while processing your request: mysql_stmt_execute: (1452) Cannot add or update a child row: a foreign key constraint fails (`LIVECONFIG`.`BACKUPS`, CONSTRAINT `BACKUPS_ibfk_3` FOREIGN KEY (`B_PLANID`) REFERENCES `BACKUPPLANS` (`BP_ID`) ON DELETE SET NULL)


    Dass es hier einen Fehler im Query bzw. der DB Struktur gibt, ist klar.
    Auch ich kann einen SQL Query lesen und interpretieren.


    Ich vermute, dass es einen Zusammenhang mit den DB Struktur Updates gibt. Hab mich aber auch nicht darum gekümmert, da die Funktion zum einen BETA ist und zum anderen von mir nicht genutzt wird. Aber ja der BUG existiert aktuell in LC.


    Nachtrag:


    Logfile Eintrag

    Zitat

    [2022/10/21 15:00:34.935544] [14902|14903] ERROR: Releasing db connection, but still have open statements
    [2022/10/21 15:00:34.935599] [14902|14903] aborting SQL: 'INSERT INTO BACKUPS ( B_CONTRACTID, B_CREATED, B_USERID, B_PLANID, B_NOTIFY, B_NOTIFYADDR) VALUES ( ?, ?, ?, ?, ?, ?)'
    [2022/10/21 15:00:34.935876] [14902|14903] Database Exception: mysql_stmt_execute: (1452) Cannot add or update a child row: a foreign key constraint fails (`LIVECONFIG`.`BACKUPS`, CONSTRAINT `BACKUPS_ibfk_3` FOREIGN KEY (`B_PLANID`) REFERENCES `BACKUPPLANS` (`BP_ID`) ON DELETE SET NULL) (SQL: INSERT INTO BACKUPS ( B_CONTRACTID, B_CREATED, B_USERID, B_PLANID, B_NOTIFY, B_NOTIFYADDR) VALUES ( ?, ?, ?, ?, ?, ?))

  • Roundcube Update

    Ok, es ist genau umgekehrt.
    LC bringt die mbstring Extension mit, aber in der Standard Server Version ist es auf einem blanko System nicht installiert.
    Und der Updater nimmt eben nur den Aufruf php und nicht /opt/php-x.x/bin/php was zu einer LC-PHP Version führt.


    Lösung (Ubuntu/Debian): apt install php-mbstring


    Damit sollte es funktionieren.

  • Roundcube Update

    php_mbstring ist meines Wissens nach nicht in den LC PHP Versionen mit dabei.
    Wäre aber eine gute Sache wenn das mit rein kommen würde. Ich stolpere immer wieder über Anwendungen die mbstring benötigen.
    Und wenn roundcube es jetzt als Voraussetzung mit bringt, dann wäre es ein Argument mehr um es mit auf zu nehmen.


    Ich aktualisiere im Lauf des Tages mal eine Instanz von mir, dann kann ich es testen.

  • Fehlermeldung beim Update auf Version 2.13.0

    Das passiert häufig, wenn man gleichzeitig ein MariaDB Update macht. Dann ist der DB Server noch nicht wieder online, während LC das Update macht und versucht auf die Datenbank zu zu greifen. (Nur relevant wenn man MySQL/MariaDB für die LC Datenbank benutzt)
    Den Fall hatten wir zumindest vor einigen Tagen mal wieder.

  • Lets Encrypt SSL-Zertifikate des Administrators werden ungültig angezeigt

    Zitat von Marco


    Mal in den Ordner "/etc/ssl/certs" wechseln und dort "ls -la | grep 'ca.crt' | grep '\->'" ausführen. Es sollten dann Verlinkungen sichtbar werden, die man löschen muss. Danach funktioniert das mit Let's Encrypt Zertifikaten wieder.


    Stimmt! Ich habe mir die Deltas zwischen den Servern angeschaut und alle problematischen Server hatten als xxxxxx.0 folgendes Zertifikat enthalten:


    Let's Encypt X3

    Code
    -----BEGIN CERTIFICATE-----
MIIEkjCCA3qgAwIBAgIQCgFBQgAAAVOFc2oLheynCDANBgkqhkiG9w0BAQsFADA/
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
DkRTVCBSb290IENBIFgzMB4XDTE2MDMxNzE2NDA0NloXDTIxMDMxNzE2NDA0Nlow
....


    Sobald diese Verlinkung gelöscht wird, nutz zumindest CURL wieder die korrekte Kette.
    Ich vermute das ist ein "Feature", dass hier nicht die komplette Kette abgearbeitet, sondern nur der erste Pfad und dann mit einem Fehler abgebrochen wird.


    OpenSSL streikt aber weiterhin noch.

  • Lets Encrypt SSL-Zertifikate des Administrators werden ungültig angezeigt

    Nach einer langen Debug Nacht bin ich einen Schritt weiter aber habe noch keine Lösung!


    Ein simpler CURL Test zeigt auf, dass ein Teil unsere Server ein Problem mit dem ISRG Root X1 Zertifikat hat.
    Alle Server sind dank SaltStack absolut identisch! Aber trotzdem haben einige Server das Problem, dass sie das neue Zertifikat nicht nutzen.


    Der Fehler äußert sich zum Bsp. darin, dass roundcube keine Verbindung mit dem Mailserver herstellen kann.
    (Dazu muss natürlich der Mailserver mit einem LE Zertifikat abgesichert sein. Wird ein alternatives Zert. verwendet, funktioniert es wieder.)
    Log von RC:

    Code
    SMTP Error: Connection failed: Failed to connect socket: fsockopen(): unable to connect to ssl://smtp.domain.de:465 (Unknown error)


    Test mit CURL auf valid-isrgrootx1.letsencrypt.org


    Testschritt 2 - kann OpenSSL auf das Zertifikat zugreifen:

    Code
    # openssl x509 -in ISRG_Root_X1.crt -noout -text
Can't open ISRG_Root_X1.crt for reading, No such file or directory
140091262317696:error:02001002:system library:fopen:No such file or directory:../crypto/bio/bss_file.c:69:fopen('ISRG_Root_X1.crt','r')
140091262317696:error:2006D080:BIO routines:BIO_new_file:no such file:../crypto/bio/bss_file.c:76:
unable to load certificate


    >> NEIN


    Ist das System kompatibel?

    Code
    # openssl version
OpenSSL 1.1.1d  10 Sep 2019


    OpenSSL >= 1.1 wird als kompatibel gelistet


    Code
    # cat /etc/*release
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION="10 (buster)"


# apt list --installed ca-certificates
ca-certificates... 20200601~deb10u2 all  [installiert]


    Aktuelles CA Bundle ist installiert


    Einmal checken ob das Zertifikat via dpkg konfiguriert wurde (* beim entsprechenden Zertifikat)

    Code
    # dpkg-reconfigure ca-certificates


    >> JA


    Ist das ISRG Root X1 Zertifikat auch wirklich installiert?!

    Code
    # awk -v cmd='openssl x509 -noout -subject' '
    /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt
...
Subject: O = Digital Signature Trust Co., CN = DST Root CA X3
...
subject=C = US, O = Internet Security Research Group, CN = ISRG Root X1
...


    >> JA


    Ist das Zertifikat auch wirklich in /etc/ssl/certs/ca-certificates.crt enthalten?

    Code
    grep 'MIIFazCCA1OgAwIBAgIRAIIQz7DSQONZRGPgu2OCiwAwDQYJKoZIhvcNAQELBQAw' /etc/ssl/certs/ca-certificates.crt


    >> Ja


    Und jetzt gehen mir im Moment die Ideen aus.

  • Lets Encrypt SSL-Zertifikate des Administrators werden ungültig angezeigt

    Konkretes Beispiel aus unseren Support Tickets:
    Windows 10 20H2
    iPhone 12 (keine Ahnung welches OS)


    Aber es ist immer eine Drittsoftware im Spiel!
    Die vermutlich ggü. einer alten OpenSSL Bibliothek gelinkt ist.


    Und es trifft nicht LiveConfig! Sondern nur Webseiten! Also kein wirkliches LC Problem.


    Mein Workaround oben führt auch eher zu unerwünschten Querwirkungen und nicht ans Ziel.
    Warum auch immer es bei einem Kunden geholfen hat.


    Auf Serverseite können wir vermutlich echt nichts machen, außer eben von LE weg zu wechseln solange bis es sich beruhigt hat und die meisten Anwendungen aktualisiert wurden.

  • Lets Encrypt SSL-Zertifikate des Administrators werden ungültig angezeigt

    Bei uns ruckelt das Internet heute auch etwas (um heise.de mal zu zitieren)


    Die Probleme mit den Ablauf des LE Zertifikates scheinen doch größer zu sein als erwartet.
    Ein Muster in den betroffenen Geräten können wir nicht erkennen. Es sind aber in allen Fällen aktuelle Geräte mit aktueller Software!


    Eine Lösung die zumindest vereinzelt hilft, aber nicht praktikabel für große Massenupdates ist:

    Code
    # Debian/Ubuntu
# entfernt, weil Querwirkungen


    - Server neu starten (evtl. unnötig)
    - Zertifikat löschen und neu ausstellen


    Danach ist auch der Anzeige Fehler in LC behoben, bei dem jeweiligen Zertifikat.