Beiträge von kk

Was liefert denn der Befehl "liveconfig --diag"? (der Teil rund um die erkannten PHP-Versionen genügt)

Meine ersten Ideen dazu:
- ist der Webspace (web2) evtl. voll? (Quota prüfen) Das php-Errorlog wird mit Berechtigung des Benutzers erstellt
- eine phpinfo()-Datei anlegen und aufrufen - dann prüfen ob die log_errors-Einstellungen etc. auch tatsächlich aktiv sind

Und warum um alles in der Welt LiveConfig 2.7.4? Das ist über ein Jahr alt. Ein Server darf durchaus wöchentlich (!) aktualisiert werden.

Hallo,

unsere PHP-Pakete für Debian/Ubuntu wurden eben auf die Versionen 7.2.29, 7.3.16 und 7.4.4 aktualisiert.

Viele Grüße & bleibt gesund

-Klaus Keppler

Ja, ich würde mal php-cgi installieren und versuchen ob "liveconfig --diag" dann die PHP-Erkennung korrekt ausführt.
Wobei es eigentlich auch in dieser Kombination funktionieren sollte (also nur mit php-fpm) - das testen wir morgen bei uns mal durch.

Legen Sie bitte mal irgendeine Subdomain an, und beobachten (mit "tail -f /var/log/liveconfig/liveconfig.log") was genau im LiveConfig-Log protokolliert wird.

Diese Ausgaben posten Sie dann am besten mal (oder schicken das an support@liveconfig.com)

Normalerweise sollte direkt nach dem Anlegen der Subdomain die entsprechende vHost-Konfiguration (/etc/apache2/sites-enabled/...) aktualisiert werden, und nach 10-60 Sekunden der Apache/NGINX reloaded werden.

Viele Grüße

-Klaus Keppler

Bei der Ausgabe vom "liveconfig --diag" fehlt leider die Info zum Webserver/PHP. Das sieht normalerweise ungefähr so aus:

[INFO]Detected 'Ubuntu 18.04.3 LTS'
       Distribution name: 'Ubuntu'
   Distribution codename: 'bionic'
     Distribution family: 'Debian'
    Distribution version: '18.04'
Distribution description: 'Ubuntu 18.04.3 LTS'
Checking for web server software:
 - Found 'apache' web server
   Version: '2.4.29'
   Package version: '2.4.29-1ubuntu4.11'
   Modules: core so watchdog http log_config logio version unixd access_compat actions alias auth_basic authn_core authn_file authz_core authz_host authz_user autoindex deflate dir env fcgid filter http2 include mime mpm_event negotiation proxy proxy_fcgi reqtimeout rewrite setenvif socache_shmcb ssl suexec
 - PHP 7.2.24 [DEFAULT] (code='php7')
   CGI/FastCGI: /usr/bin/php-cgi
   FPM: /usr/sbin/php-fpm7.2
        pool config: /etc/php/7.2/fpm/pool.d
   default php.ini: '/etc/php/7.2/cgi/php.ini'
 - default PHP CLI: /usr/bin/php
Checking for ftp server software:
[...]

Scheinbar passt was mit den verfügbaren und den gewählten PHP-Versionen nicht zusammen.
Posten Sie bitte mal die Ausgabe von "liveconfig --diag" (der Bereich rund um die PHP-Versionen genügt)

Viele Grüße

-Klaus Keppler

Mit /var/lib/dpkg/status hat das vermutlich nichts zu tun.
Ich schaue mir das gleich an und melde mich dann bei Ihnen (da ist ja aktuell glaube ich auch ein Ticket offen).

Hallo,

weil uns schon erste Anfragen zu dem Thema erreich haben, möchte ich kurz ein paar Worte dazu schreiben.

Als Softwareentwickler haben wir es unter den aktuellen Umständen ja relativ einfach, da wir problemlos im Home Office arbeiten können. Manche Mitarbeiter arbeiteten bisher schon regelmäßig von zu Hause aus, andere nur vereinzelt.
Gestern haben wir noch mal unsere eigene Infrastruktur dahingehend optimiert, so dass ab sofort alle Mitarbeiter vom Home Office aus arbeiten. Somit muss nur noch für Buchhaltung und Post ab und zu mal jemand kurz ins Büro kommen, und das geht auch einzeln.

Faktisch ist das Büro also ab sofort nicht mehr durchgehend besetzt. Unsere Erreichbarkeit per E-Mail ist aber unverändert, und telefonisch sind wir auch fast normal erreichbar (dank SIP und VPN). Bitte habt aber Verständnis, wenn im Hintergrund mal Kinder zu hören sind.
Die Bearbeitung von Post und buchhalterischen Anfragen wird teilweise etwas länger brauchen. Alles andere sollte nun wieder im weitesten Sinne "normal" laufen.
Die Geschäftszeiten bleiben unverändert (09-17 Uhr).

Viele Grüße & bleibt gesund!

-Klaus Keppler

What's the output of "liveconfig --diag"? (the section of detected PHP versions is sufficient)

Nein, damit kann man Domain Control Validation-Dateien für die Ausstellung von SSL-Zertifikaten anderer Anbieter per API für die jeweilige Domain hinterlegen.
Details folgen mit dem nächsten regulären Update.

Danke für die Rückmeldungen!

Aktueller Stand ist, dass die betroffenen Zertifikate heute (04.03.2020) um 20:00 UTC (also 21:00 MEZ) zurückgerufen werden (Quelle).

Version 2.9.3 steht ab sofort zur Installation bereit.

Diese behebt einen Fehler aufgrund dessen v2.9.2 mit MySQL-Backend nicht starten konnte.
Ansonsten gibt's keine Änderungen (wer also SQLite nutzt braucht dieses Update nicht einspielen).

Bitte entschuldigt die Unannehmlichkeiten.

Viele Grüße

-Klaus Keppler

Danke für die Rückmeldungen - Fehler ist gefunden und behoben. In unserer Testumgebung hatte die Schemaänderung funktioniert, mit älteren MySQL/MariaDB klappt's offenbar nicht.
Update (v2.9.3-release) wird eben gebaut und steht in ca. 20 Minuten online. Ich gebe dann noch mal Bescheid.

Zitat von bfal

Code

[2020/03/03 21:39:40.928042] [1531|1531] Upgrading database schema (r209021 -> 2.9.2-2)
[2020/03/03 21:39:41.826993] [1531|1531] Database connection failed: Table 'SSLCERTS' is specified twice, both as a target for 'UPDATE' and as a separate source for data

Oha. Dürfte mit MySQL zusammenhängen - wir prüfen das sofort.
Welche MySQL-Version genau setzen Sie ein? Und wissen Sie, ob diese im "strict mode" läuft?

Weil uns diese Frage inzwischen schon öfter erreicht hat:
es sind nicht alle Let's-Encrypt-Zertifikate betroffen, die in dem o.g. Zeitraum ausgestellt wurden.
Es betrifft nur die Fälle, in denen die CAA-Prüfung für die Domains älter als 8 Stunden waren - meistens also bei Zertifikaten die (unnötigerweise) in sehr kurzen Intervallen verlängert wurden.

In v2.9.2 (das Release von eben) ist das nicht enthalten - wir haben das Let's-Encrypt-Hotfix in den letzten stabilen Zweig integriert.

Das o.g. Feature ist dann im kommenden regulären Update enthalten (das wird auch nicht mehr lange dauern). Da wir heute zwingend ein "stable" Update freigeben mussten, ging das leider nicht anders.

Viele Grüße

-Klaus Keppler

Hallo,

ab sofort steht LiveConfig v2.9.2 zur Installation bereit.

Es handelt sich hierbei um ein ungeplantes Release, daher sind nur relativ wenige Änderungen enthalten (vollständige Liste siehe Changelog).

Der Grund für dieses kurzfristige Release ist der CAA Rechecking Bug beim SSL-Anbieter Let's Encrypt. Heute Nachmittag (!) hatte Let's Encrypt damit begonnen, Inhaber von betroffenen SSL-Zertifikaten (soweit möglich) per E-Mail darüber zu informieren, dass diese Zertifikate am 04.03.2020 um 00:00 zurückgezogen werden.

Der Grund für den so kurzfristigen Rückruf sind strenge Vorgaben des Browser-Forums. Let's Encrypt versucht zwar noch etwas mehr Zeit für den Zertifikatsaustausch auszuhandeln (siehe Bugzilla), aber ob das klappt ist derzeit noch nicht absehbar.

Die Begeisterung über diese gar so kurzfristige Aktion hält sich natürlich in Grenzen, wie man im Let's-Encrypt-Forum verfolgen kann.

Wir haben die Datenbank mit den betroffenen Zertifikaten (hier) heruntergeladen, die reinen Seriennummern aller 3.048.289 Zertifikate extrahiert und in eine Datenbank geschrieben. Auf http://www.liveconfig.com haben wir eine API eingerichtet, um zu prüfen ob ein Zertifikat betroffen ist.

LiveConfig v2.9.2 macht nun Folgendes:

• beim Start von LiveConfig werden alle SSL-Zertifikate, die von Let's Encrypt zwischen dem 04.12.2019 00:00 und dem 29.02.2020 04:00 ausgestellt wurden, speziell markiert (SSLCERTS.SSL_CHECKSTATUS=1)
• alle paar Minuten werden jeweils bis zu 100 dieser Zertifikate über den Webservice unter https://www.liveconfig.com geprüft - dabei wird lediglich eine JSON-Liste mit den Seriennummern (ohne Domainnamen) übermittelt und ggf. eine Liste mit den betroffenen Seriennummern zurück übermittelt.
  In /var/log/liveconfig/liveconfig.log sieht das dann so aus:
  
  
  Code

  Checking SSL CA reissue status for 100 certificates...

  
  

• Alle ggf. betroffenen Zertifikate werden anschließend automatisch neu beantragt (SSL_CHECKSTATUS wird dann auf "3" geändert). Alle nicht betroffenen Zertifikate erhalten SSL_CHECKSTATUS=2
• Nach wenigen Minuten sollte der Spuk somit vorbei sein.

Es sind wohl rund 2,6% aller Zertifikate betroffenen - unseren ersten Tests nach sieht das plausibel aus.

Sollten Fragen oder Probleme auftauchen melden Sie sich bitte einfach.

Viele Grüße

-Klaus Keppler

Das Update ist fertig, unsere Tests waren bislang positiv. Von knapp 500 SSL-Zertifikaten mussten 2 neu ausgestellt werden, was automatisch und fehlerfrei durchlief.

Wenn nichts dazwischen kommt, werden wir v2.9.2 (release) noch vor 22:00 freigeben. Fortsetzung folgt...

Kurzer Zwischenstand: der Webservice ist fertig, ebenso die Prüfung der Zertifikate. Aktuell wird noch das Anstoßen der Neuausstellung eingebaut.