Wurde das Zertifikat ggf beim Reseller/Admin angelegt?
Beiträge von antondollmaier
-
-
Schwierig. Ein öffentlicher SMTP-Server muss gemäß RFC3207 auch unverschlüsselte Verbindungen erlauben. Prinzipiell ist es aber möglich, Postfix so zu konfigurieren dass bei bestimmten Empfängerdomains nur verschüsselte eingehende Verbindungen erlaubt sind (reject_plaintext_session)
Das klingt doch nach DANE / MTA-STS ...
-
warnquota kann in /etc/default/quota aktiviert werden.
Empfänger ist jedoch der User selbst (sprich, Vertragsname). Eine Weiterleitung gibt es nicht, da LiveConfig keine Mailadresse für einen Nutzer erzwingt.
Der Linux-Dienst hilft einem so also nichts.
Wir haben einen eigenen Dienst geschrieben, der die LiveConfig-Datenbank abfragt und dann die Mails "sauber" via SMTP verschickt - wenn eine Mailadresse existiert.
-
Hallo,
Allerdings fände ich es großartig, wenn in den nächsten Updates eine Funktion kommt, mit der Domains auch HTTP-Protokoll unabhängig erstellen kann. Zum Beispiel, dass ich Domains hinzufügen kann, die im Virtualhost auf einen von mir festgelegten Port hören und nicht nur Port 80 oder 443.
Warum?Konkret: die HTTP-Validierung von SSL-Zertifikaten erfordert bei Let's Encrypt, dass HTTP/HTTPS (80/443) auf den CN/SAN des Zertifikates erreichbar sind. Bei anderen Ports kann somit keine Validierung erfolgen.
-
Das Problem ist dem Team um Herrn Keppler nur in der Form anzulasten, dass nicht auf die Nachfolgeversion 5.x umgestellt wurde/wird.
Schätze mal, da steht eher ne Migration auf Discourse an, als dass man das vBulletin noch weiter reitet.
-
Tendentiell Bug. Am Besten via "dig @ns1.... http://www.example.com" und in der Zone-Datei verifizieren, was tatsächlich geschrieben wurde.
Wir hatten da auch schon komisches Verhalten festgestellt, gerade mit externen DNS-Einträgen, CNAMES und der WWW-Subdomain.
-
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.
-
-
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.
-
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/
-
Code
# /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.
-
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.ZitatAlle 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.
ZitatWenn 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").
-
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.
-
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).
-
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.ZitatKann 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. -
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.
