Ah..stimmt. Also PHP 5.6 funktioniert. PHP 7.2/7.3 kann nicht funktionieren da das Script noch mysql_connect verwendet und von haus erst einmal nicht kompatibel ist. Aber ja lag an der PHP Version.
Leider werden die SSL-Aufträge auch nicht bearbeitet:
[...]
Erst nach einem Neustart von LiveConfig wird das Zertifikat dann angelegt.
CentOS Linux release 7.6.1810 (Core)
LiveConfig 2.8.0-r5579
Unter CentOS 7 mit MariaDB (5.5.60) als LiveConfig-Backend können wir dieses Verhalten reproduzieren. Wir kümmern uns gerade darum, der Fix wird noch mit in v2.8.1 einfließen.
(mit SQLite als Backend, sowie auf anderen Distributionen mit anderen MySQL/MariaDB-Versionen klappt es interessanterweise...)
Update: die Ursache ist gefunden und behoben. Das Verhalten tritt auf, wenn man MySQL als LiveConfig-Backend verwendet und (das klingt vielleicht komisch) der Server zu schnell ist. 
In diesem Fall wird die Validierungsdatei auf dem Server angelegt und dem LiveConfig-Prozess zurückgemeldet, noch bevor die Transaktion mit dem Anlegen der Domain abgeschlossen ist.
Wir ändern den Workflow nun geringfügig, um das Problem zu umgehen.
Viele Grüße
-Klaus Keppler
Ach was waren das noch für Zeiten als die Server zu langsam waren 
Wie sieht denn die Zeitplanung für die 2.8.1 aus? Wir warten derzeit auf das Update, um unsere Anleitungen zu vervollständigen.
Bestenfalls liegt das Installationspaket für 2.7.x noch unter /var/cache/apt/archives/
Da isses. Besten Dank!
Bei uns ist es Ubuntu 10.4 mit dem 5.3 der Distri... nicht schlagen, bitte! Wir müssen von der alten Gurke eben die Daten noch migrieren.
nicht schlagen, aber der der dafür verantwortlich ist, dass ein System seit über 4 Jahren ohne Sicherheitsupdates am Internet hängt, ist rechtlich mit dran wenn dort - oder noch schlimmer von dort aus - etwas passiert.
sorry für den OT, aber da kann ich nicht still bleiben...
nicht schlagen, aber der der dafür verantwortlich ist, dass ein System seit über 4 Jahren ohne Sicherheitsupdates am Internet hängt, ist rechtlich mit dran wenn dort - oder noch schlimmer von dort aus - etwas passiert.
sorry für den OT, aber da kann ich nicht still bleiben...
Danke für die hilfreiche Aufklärung. Es hat aber keiner behauptet, dass wir von einem aktiven System reden, das noch direkt am Internet hängt, sondern dass von einem Altsystem Daten importiert werden müssen. 
Danke für die hilfreiche Aufklärung. Es hat aber keiner behauptet, dass wir von einem aktiven System reden, das noch direkt am Internet hängt, sondern dass von einem Altsystem Daten importiert werden müssen.
ok, unwahrscheinliches Szenario, dass ein Altsystem seit vier Jahren offline ist, die Daten noch da sind und man diese jetzt erst braucht - aber OK, ich nehme das mal so hin
Seit Version 2.8 liefert die cron.php.sh immer einen Return-Code 1:
+ set -e
+ . /etc/liveconfig/sysconfig
+ LC_WEBROOT=/var/www
+ LC_CFGVERSION=45
+ EXPIRE=1440
+ id -u
+ USER_ID=0
+ pgrep -u 0 -f /bin/sh /usr/lib/liveconfig/cron.php.sh
+ which php
+ [ -d /var/www ]
+ php -r echo phpversion();
+ cut -d . -f 1
+ PHPVERSION=7
+ [ -d /var/www/html -a -d /var/www/html/tmp ]
+ continue
+ [ -d /var/www/index.html -a -d /var/www/index.html/tmp ]
+ continue
+ [ -d /var/www/web108 -a -d /var/www/web108/tmp ]
+ CHUSR=
+ [ 0 = 0 ]
+ id -u /var/www/web108
+ CHECK_USER=
1"id -u" sollte mit dem Usernamen gefuettert werden und nicht mit dem Homeverzeichnis des Customers.
Die von Debian/SpamAssassin verwalteten Verzeichnisse unterhalb von /var/lib/spamassassin/ müssen weiterhin debian-spamd:debian-spamd gehören (3.00*, compiled, sa-update-keys). Die Benutzerverzeichnisse (<Vertrag>_<PostfachID>) müssen spamd:spamd gehören und mode=0750 haben.
LiveConfig macht das alles korrekt. Probleme gibt es nur, wenn SpamAssassin eben als Benutzer "debian-spamd" läuft (dann hat er keinen Zugriff auf die user_prefs). Umgekehrt hat SpamAssassin als Benutzer "spamd" aber Zugriff auf die Regeln, die "debian-spamd" gehören. Dieses Setup ist sicherer und deshalb so beabsichtigt.
Code# ls -l /var/lib/spamassassin/ total 0 drwxr-xr-x 3 debian-spamd debian-spamd 71 May 14 2016 3.003001 drwxr-xr-x 3 debian-spamd debian-spamd 71 Oct 23 2018 3.003002 drwxr-xr-x 3 debian-spamd debian-spamd 71 Jan 15 2019 3.004000 drwxr-xr-x 3 debian-spamd debian-spamd 71 Aug 23 07:02 3.004002 drwxr-xr-x 3 debian-spamd debian-spamd 18 Oct 23 2018 compiled drwx------ 2 debian-spamd debian-spamd 79 Aug 23 07:02 sa-update-keys drwxr-x--- 2 spamd spamd 57 Aug 2 18:34 web345_7
so weit, so gut - aber bayes funktioniert damit noch nicht.
Dazu müsste LC entweder "chgrp spamd /var/lib/spamassassin && chmod g+w /var/lib/spamassassin" machen. ( siehe https://www.liveconfig.com/de/…=8220&viewfull=1#post8220 )
Oder aber proaktiv für jedes Postfach einen Ordner vorab anlegen, statt erst wenn es user_prefs gibt.
Welchen Weg sollen wir gehen?
Hallo zusammen,
ist folgendes Verhalten beim Hinzufügen einer Domain beabsichtigt?
Menü: Kunde -> Kunde wählen -> Domains -> neue Domain
SSL/TLS ist automatisch angewählt.
Aber leider nicht mit dem LE-Account des Kunden bzw. des Vertrags
sondern mit dem LE-Account aus dem Admin bzw. Hosting-Bereich.
Eigentlich wollen wir die Certs für die Kunden-Domains nicht mit unserem LE-Account verwalten.
Sofern der Kunde über einen eigenen LE-Account verfügt sollte dieser verwendet werden.
Ist kein LE-Account vorhanden, sollte ggf. einer erstellt werden?
Bei Kunden die über einen LE-Account verfügen wird dieser auch nicht im Dropdown angeboten.
Gruß
Thomas
Eigentlich wollen wir die Certs für die Kunden-Domains nicht mit unserem LE-Account verwalten.
Exakt das ist mir auch schon so aufgefallen und sollte nachgebessert werden. D.h. das Zertfikat soll im Account des Kunden angelegt werden.
Hallo zusammen,
ich erlaube mir hier mal Herrn Keppler aus einer Mail zu zitieren (hoffe, das ist OK, da dort nichts verfängliches drinsteht):
ZitatAlles anzeigenZu Ihrer Frage: die Zuordnung der Zertifikate ist so korrekt und beabsichtigt.
Die Domain (mitsamt der Zertifikate) wird ja von *Ihnen* angelegt, daher landen diese auch in Ihrem Account.
Der Endkunde sollte mit den Zertifikaten im Idealfall überhaupt nichts zu tun haben; Endkunden brauchen daher i.d.R. die Berechtigung "SSL-Verwaltung" auch überhaupt nicht.
Nur Zertifikate, die der Endkunde *selber* bestellt, sollen ggf. in seiner eigenen SSL-Verwaltung auftauchen (das liegt ja dann außerhalb Ihrer Zuständigkeit).
Die Idee dahinter ist, dass das komplette SSL/TLS-Thema langfristig völlig transparent für die Kunden abgewickelt wird. Mit Zertifikaten, CSRs, Validierungen usw. sollen die sich überhaupt nicht herumschlagen müssen. Die meisten Kunden können damit eh nichts anfangen, und werden dann zwangsweise den Support beanspruchen. Da mit Let's Encrypt die Zertifikate kostenfrei sind, würde das also mehr Aufwand ohne Umsatz bedeuten -> schlecht.
Das war die Antwort auf das o.g. "Problem".
Ich denke das ist derzeit eher verwirrend für den Kunden. Sieht er unter SSL kein Zertifkat, wundert er sich --> und wieder kommen Support-Mails, wie: "Wo ist das Zertifikat?" "Warum ist kein Zertifikat sichtbar" ...
Danke für die Info aus der Mail.
Eventuell sollte man die Entscheidung selbst fällen können.
Immerhin gibt es doch schon das Dropdown-Feld, dort müsste nur der LE-Account
des Kunden mit rein und noch die Option geschaffen werden, den default-Wert zu wählen.
So hat man nun:
- LE-Certs für Domains vom Kunden im eigenen Hosting-Bereich sofern man die Domain hinzufügt
- LE-Certs für Domains vom Kunden im Kunden-Bereich sofern der Kunde (oder Admin als Kunde) das Cert aktiviert
- Kunden die dann nur einen Teil Ihrer Zertifikate sehen
- Kunden Zertifikate vermischt mit den eigenen Zertifikaten im eigenen Hosting-Bereich
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
