Beiträge von antondollmaier

Könnte an TLS 1.3 liegen, wie der erste Treffer bei Github zeigt:

https://github.com/proftpd/proftpd/issues/1151

Und ja, dürfte sich damit durch das Upgrade auf Bullseye (mit 1.3.7a) lösen.

Mein Fehler, das hab ich nicht gesehen.

Nimm doch mysqldumper?

Zitat von Mathias_Thielen

Aktuell kann ich ja keine Updates sauber einspielen ohne dass die Problematik wieder auftritt, weil die vsftpd.lua natürlich durch neue Pakete überschrieben wird.

Die angepasste Funktion kann via custom.lua "sauber" überschrieben werden und so "update-fest" genutzt werden.

Machen wir für einige Webspace-Funktionen auch so.

liveconfig-meta hat eine "depends"-Abhängigkeit mit "awstats oder webalizer".

Somit kann liveconfig-meta nicht beibehalten werden, ohne auch awstats beizubehalten.

=> awstats in der Serververwaltung deaktivieren. Mehr geht nicht.

Zitat von hchristo

so könnte man schonmal Standard werte wie: TXT und _DMARC Infos Automatisch hinzufügen

SPF-Record ist bereits via Servereinstellungen möglich.

Zu DMARC: CloudFlare hat da einen richtig coolen Wizard gebaut: https://blog.cloudflare.com/tackling-email-spoofing/

# /etc/systemd/system/clamav-daemon.service.d/clamav_restart.conf
[Service]
Restart=always

Danach ein "systemctl daemon-reload; systemctl restart clamav-daemon" und clamav wird automatisch neu gestartet.

Logs (SSH sowie LiveConfig) prüfen, sowie die /etc/shadow vor und nach der PW-Änderung vergleichen, ggf. auszugsweise hier posten.

Zitat von hchristo

Guten morgen Herr Keppler, Es scheint alles abzurauchen:
- DynDNS Updates funktionieren nicht mehr
- Lets Encrypt Updates gehen nicht mehr
- FTP Passwort änderungen gehen nicht mehr
- Apache/nginx Änderungen gehen nicht mehr

dann hängt wohl LiveConfig.

Zitat

Alle Child prozesse rauchen vollkommen ab. Im Log sehe ich auch dass Liveconfig Meldet "Sending crash report to https://update.liveconfig.com/"

ggf. die kompletten Logs mit dem Backtrace als Ticket versenden.

Zitat

Wenn ich Liveconfig Stoppe meldet Liveconfig dass er nicht beendet werden konnte und sich selber abgeschossen hat.
Es läuft erst alles wieder wenn ich den Kompletten Server reboote.

Ein kompletter Reboot ist in 99% der Fälle nicht nötig.

Neustart von LiveConfig ggf in mehreren Schritten:

- "systemctl stop liveconfig"
- "systemctl status liveconfig": prüfen, ob noch ein Prozess "hängt". Diesen ggf. manuell via "kill -9" beenden.
- "systemctl start liveconfig"
- nun nochmals via "status" prüfen, ob LiveConfig sauber läuft.

In der Vergangenheit gab es Crashs, wodurch der Prozess die Memory-Segmente nicht aufräumen konnte.

Daher hier also manuell eingreifen und die Segmente löschen.

Anleitung: https://www.liveconfig.com/dow…onfig-Handbuch-2.10.0.pdf - Seite 162 ("ipcs").

Zitat von annehess

Das von der Distribution mitgelieferte PHP ist ohne FPM und ohne Ioncube Loader konfiguriert.

"php-fpm" nachinstallieren. Für ioncube kannst du die .so aus /opt/php-7.4 sowie die ioncube.ini auch nach /etc/php übernehmen.

Zitat von annehess

Was sich mir hier aber nicht erschließt ist die Tatsache dass für die Distribution eigentlich das Liveconfig PHP Paket in der Version 7.4.3 zur Verfügung steht aber nur 7.4.24 installiert wird.

Ubuntu hat 7.4.3: https://packages.ubuntu.com/focal/php7.4-fpm

LiveConfig selbst hat eine andere Version: https://www.liveconfig.com/de/…an-mehrere-php-versionen/

Das Paket von LiveConfig ist also neuer (die dritte Zahl gibt das Patchlevel an: Ubuntu hat Patch-Level 3, LiveConfig bringt 24).

Zitat von robby

ich hatte jetzt den Fall, dass das Zertifikat korrekt verlängert wurde (stimmt alles in der DB), aber die Zertifikats-Datei auf dem System wurde nicht neu geschrieben.

Das sollte nur der Fall sein, wenn das Zertifikat nicht bei "Domains" konfiguriert ist - ggf. gibt es mehrere.

Zitat

Kann man das irgendwie händisch anstoßen?

Eine (Sub-)Domain aus dem Vertrag öffnen, irgendwas kurz ändern, so dass der Speichern-Knopf grün wird, dann Speichern. Nun wird der VirtualHost mit den dazugehörigen SSL-Zertifikaten neu geschrieben.

Zitat von annehess

Theoretisch dürften 2 php7.4 Versionen doch garnicht auf dem System parallel existieren dürfen;

Doch, natürlich können zwei PHP 7.4 parallel existieren: einmal in /usr/bin/php von Ubuntu/Debian selbst, und einmal in /opt/php-7.4/bin/php mit den PHP-Paketen von LiveConfig.

Hier gibt es keinen Widerspruch, die Pakete sind auch komplett voneinander unabhängig.

Spannend wird es dann beim Upgrade von Debian/Ubuntu: hier wird aus der "PHP" in /usr/bin/php aus dem PHP 7.4 dann irgendwann PHP 8.0 - die zusätzliche Version in /opt/php-7.4 bleibt aber unverändert bestehen.

Logs prüfen... "journalctl -u liveconfig", bzw /var/log/liveconfig.

Da steht genau, wenn was schief läuft.

Wir haben zusätzlich alle Server im Debug-Mode laufen (log_level=debug), weil dann wirklich alle Logmeldungen aufgezeichnet werden. Nachteile habe ich jedoch noch nicht bemerkt.

Zitat von weltmeister

Hier werden IPs über Jahre(!!) gespeichert

Signed. Hier sollte Anonymisierung möglich sein, insbesondere im Einklang mit der Datenschutzerklärung. Kontakt-Cleanup wäre in dem Zusammenhang auch sinnvoll zu nennen.

Zitat

Es interessiert sicher niemanden mehr, wann diese z.B. 2013 irgend eine Änderung auf dem Server vorgenommen haben. GGf. macht es sinn, alle Einträge, die z.B. älter als ein Jahr sind zu löschen.

Hier muss ich widersprechen: wir haben Kunden, die sich zuletzt 2018 eingeloggt haben, sich aber dennoch über "plötzlich falsche Passwörter" wundern.

An den paar MB an Logs solls ja letztendlich nicht scheitern.

Danke für's Teilen!

Um nicht wie im XKCD-Comic zu enden: was war's denn?

Signed. Standard-Wert nach Typ, oder gar ganz global via LCDEFAULTS, wäre super.

Zitat

Um das noch einmal klar zu stellen: ein reines Renewal ändert NICHTS an der Liste der Zwischenzertifikate. Weder mit LiveConfig, noch mit irgendeinem anderen ACME-Client.

naja, hier doch.

Validierungs-Fehler in CURL/OpenSSL treten ja auf, weil LiveConfig die CA-Chain in die *-ca.crt gelegt hat. Das wäre so kein Problem, gäbe es nicht die abgelaufenen oder ähnliche veraltete Zertifikate. Löse ich nun einen Renew dieser alten Zertifikate aus, ist das abgelaufene CA-Zertifikat auch weg und somit funktioniert die Validierung wieder.

Danke für das Update und die umfangreichen Infos!

Zitat von hchristo

Die Direkte Änderung durch Entfernen von einer IP oder DNSSEC läuft nur darauf hinaus dass Liveconfig dauerhaft als Status dann Anzeigt "Status:Konfiguration ok, warte auf Service-Neustart"

LetsEncrypt Zertifikate werden auch nicht Aktualisiert, Status 3er Domains: pending

Eine wirkliche Abhilfe bring nur nen Kompletter System Neustart des Servers

Das liegt eher an LiveConfig als an BIND - bitte die Logs von LiveConfig selbst durchgehen, vermutlich stirbt einer der Child-Prozesse.

Logs sammeln und per Ticket raus senden