Ah, verstehe. Wir werden die unter conf/ untergeordneten Verzeichnisse kurzfristig mit dem Immutable-Flag versehen. Preview-Update kommt in ca. einer Stunde, Release dann voraussichtlich morgen Vormittag. Während des Upgrades werden bestehende Verzeichnisse automatisch mit +i versehen.
php.ini-Dateien kann der Kunde übrigens dennoch nicht bearbeiten (durch +i geschützt), auch wenn er die Schreibrechte für die php*-Verzeichnisse erweitert hat.
Nein, der Benutzer hat ja keine Schreibberechtigungen in /conf und dessen untergeordneten Verzeichnissen.
$ ls -al conf/
total 20
drwxr-x--- 5 www-data web11 4096 Jun 21 13:56 .
drwxr-xr-x 8 root root 4096 Jun 21 13:56 ..
dr-xr-xr-x 2 web11 web11 4096 Jun 21 13:57 php5
dr-xr-xr-x 2 web11 web11 4096 Jun 21 13:57 php56
dr-xr-xr-x 2 web11 web11 4096 Jun 21 13:57 php70Welchen Sinn macht es DSN komplett zu unterdrücken?
DSNs können unerwünscht weitere Informationen zur internen Serverstruktur ausplaudern (z.B. Namen des nächsten Hops). Es gehört eigentlich zu den "Best Practices", positive DSNs nicht zu erlauben.
Wenn Sie das aber nutzen möchten, brauchen Sie nicht die ganze Postfix-Konfiguration sperren. Es genügt folgender Eintrag in die custom.lua:
postfix.LOCALCONFIG = {
['smtpd_discard_ehlo_keywords'] = ""
}Auf CentOS 7 sehen die Verzeichnisrechte so aus:
]# ls -al /var/www/web1
total 0
drwxr-xr-x 9 root root 85 Jun 21 11:35 .
drwxr-xr-x. 5 root root 42 Jun 21 11:35 ..
drwxr-x--- 2 web1 apache 6 Jun 21 11:35 apps
drwxr-x--- 4 apache web1 29 Jun 21 11:35 conf
drwxr-x--- 3 web1 apache 20 Jun 21 11:36 htdocs
drwxr-x--- 3 apache web1 36 Jun 21 11:35 logs
drwxr-x--- 2 web1 web1 6 Jun 21 11:35 priv
drwxr-x--- 2 apache web1 23 Jun 21 11:35 stats
drwxrwx--- 2 web1 apache 6 Jun 21 11:35 tmpUnter Debian 9:
# ls -al /var/www/web1
total 32
drwxr-xr-x 8 root root 4096 Jun 21 11:01 .
drwxr-xr-x 9 root root 4096 Jun 21 11:01 ..
drwxr-x--- 5 www-data web1 4096 Jun 21 11:01 conf
drwxr-x--- 3 web1 www-data 4096 Jun 21 11:01 htdocs
drwxr-x--- 3 www-data web1 4096 Jun 21 11:01 logs
drwxr-x--- 2 web1 web1 4096 Jun 21 11:01 priv
drwxr-x--- 2 www-data web1 4096 Jun 21 11:01 stats
drwxrwx--- 2 web1 www-data 4096 Jun 21 11:01 tmpWas jedoch unschöner ist, dass der Kunde bei LiveConfig Webhostings ebenso die Berechtigungen für /priv /tmp und /conf ändern kann. Gerade im /conf Ordner meinte dann mancher Kunde schon, herumfrickeln zu müssen..
Uh-oh, dann ist da was anderes schief gelaufen. Das Homeverzeichnis des Kunden (/var/www/<Vertrag>) muss root:root gehören (mode 0755). Im conf-Verzeichnis darf er generell gar keine Schreibrechte haben, die PHP-FastCGI-Starter sind mittels Immutable-Flags geschützt.
Bitte legen Sie testweise mal einen neuen Vertrag an und prüfen die Rechte der erstellten Verzeichnisse.
[2018/06/20 13:49:40.209923] [18007|18007] Server child process 18009 terminated; uncaught signal: 11 (Segmentation fault)
..... + viele Zeilen mit Verweis auf Files....
Könnten Sie uns bitte genau diese "vielen Zeilen" (den Stacktrace) an support@liveconfig.com schicken? Das könnte Hinweise darauf geben, wo genau das Problem liegt.
Viele Grüße
-Klaus Keppler
Vielleicht liefert der "dmesg"-Befehl hilfreiche Hinweise?
Ansonsten können wir Ihnen da leider auch nicht weiterhelfen - das muss sich ein Admin direkt auf dem Server anschauen.
Der Log-Meldung nach wurde LiveConfig jedenfalls regulär beendet und ist nicht abgestürzt o.ä. - zusammen mit dem Hinweis auf ein langsames System deutet das auf den OOM-Killer hin.
Ich habe jetzt das in der liveconfig Log gefunden.
Das ist eine völlig normale Meldung, wenn LiveConfig beendet wird.
Stellt sich also die Frage, warum LiveConfig beendet wird (bzw. wer das beendet).
Ein Blick in /var/log/messages bzw. /var/log/syslog gegen 06:02:58 könnte da weiterhelfen.
Eine Möglichkeit: ein Backup-Prozess der um diese Zeit läuft, zu viele Ressourcen benötigt und über den OOM-Killer LiveConfig abschießt...
LiveConfig arbeitet überhaupt nicht mit den User-IDs, sondern nur mit den Benutzernamen.
Daher dürfte es auch künftig keine Probleme seitens LiveConfig geben. 
Muss man mehr machen, als die User ID im[INDENT]/etc/passwd
[/INDENT]
ändern
Soweit nicht, da LiveConfig keine User-IDs speichert sonder nur mit den Usernamen arbeitet.
und dann alle Files im Filesystem mittels[INDENT]chown -R 20000:20000 /var/www/web1
[/INDENT]
[INDENT]chown -R 20000:20000 /var/mail/[/INDENT]
NEIN - bloß nicht!
Die Rechte in /var/mail/ müssen gar nicht geändert werden, da die Mails dem Systemuser "mail" gehören.
Bei den Webspaces ist das deutlich differenzierter - einige Verzeichnisse gehören <Vertrag>:www-data, andere <Vertrag>:<Vertrag>, usw.
Der Benutzer darf KEINE Schreibrechte in seinem Homeverzeichnis haben, das muss weiterhin root:root gehören!
Führen Sie einfach das Script "/usr/lib/liveconfig/lcservice.sh fix-permissions [Vertrag]" aus (optional mit einem Vertragsnamen, oder ohne Parameter um alle Webspace-Verzeichnisse durchzugehen).
(am besten im ersten Durchgang mal nur mit einem einzelnen Webspace testen, also z.B. "/usr/lib/liveconfig/lcservice.sh fix-permissions web1")
LiveConfig v2.6.1 is available for download now.
This release contains basically bugfixes and minor improvements.
Anyone using NGINX with LiveConfig should install the upgrade as soon as possible. There was a bug which led to flooded access.log files in many cases.
The changes are:
Ab sofort steht LiveConfig v2.6.1 zum Download bereit.
Es handelt sich dabei hauptsächlich um Bugfixes und kleinere Verbesserungen.
Wer NGINX mit LiveConfig betreibt, sollte dieses Update bitte möglichst zeitnah einspielen. Es gab in dieser Konstellation einen Fehler, der in vielen Fällen dazu führte, dass access.log-Dateien von NGINX-Webspaces voll laufen.
Die Änderungen sind:
Das Update (v2.6.1) ist ab sofort verfügbar. Wer NGINX mit LiveConfig betreibt, sollte das bitte möglichst zeitnah einspielen.
Noch mal ein ehrliches und großes SORRY für die vollgelaufenen Log-Dateien. 
Der Fehler ist auch wirklich äußerst ärgerlich. Um das vielleicht kurz zu erklären: lclogsplit wurde komplett neu entwickelt und arbeitet intern nun vollständig Event-basiert. Dabei erkennt lclogsplit auch, ob Log-Dateien rotiert wurden - und zwar dann wenn sich die inode-Nummer der betroffenen Log-Datei geändert hat oder die Logdatei zurückgesetzt (truncated) wurde. Genau hier gab es einen Fehler, der bei Logfile-Quellen (also nur bei NGINX) in manchen Fällen fälschlicherweise ein "Truncate" bei der Logdatei gemeldet hat - woraufhin diese komplett neu eingelesen und durchgeparsed wurde. Je nachdem wie groß wie Quell-Log-Datei war, führte das dann entsprechend zu viel Output.
Wir planen nun die Testphase vor größeren Änderungen etwas umzustrukturieren, um so etwas früher erkennen zu können. (das NGINX-Log wird z.b. standardmäßig nur wöchentlich rotiert, und der Fehler kann frühestens ab der zweiten Rotation auftreten).
Gab oder gibt es einen Problem mit dem LOGGING ??
In der aktuellen v2.6.0 kann es ein Problem geben, wenn NGINX genutzt wird und die Logrotation zuschlägt. Wir arbeiten daran, Update kommt in den nächsten Stunden.
yesterday I must hard-restart my server, and from that moment,
this problem exist.
Ok, possibly /var/run/ is located on a RAM drive or tmpfs (and thus deleted on restart).
Please create /var/run/liveconfig, then it should work again.
We'll check that lclogsplit cares for this automatically with the next update.
Zitatone more thing, some serious bug lclogsplit have on my server, just nginx web server is there,
but i`l wrote about it later..
We're currently investigating a problem with lclogsplit after NGINX log rotation (log file is periodically re-read from start). Bugfix expected within the next few hours.
Jun 18 10:28:52 web3 systemd[1]: Starting LiveConfig lclogsplit...
Jun 18 10:28:52 web3 lclogsplit[6981]: lclogsplit: pid_create: open: No such file or directory
Jun 18 10:28:52 web3 lclogsplit[6981]: pid_create: open: No such file or directory
Did you modify the location of the lclogsplit PID file (/var/run/liveconfig/lclogsplit.pid)?
Does /var/run/liveconfig/ exist? (owned by root:root, mode=0755)
Was liefert der Befehl
ldd /opt/php-7.0/lib/php/extensions/no-debug-non-zts-20151012/gd.so
zurück?
Ist das Paket "libgd3" korrekt installiert?
Ich tippe mal darauf, dass das Upgrade nicht vollständig durchgelaufen ist und libgd nicht aktualisiert wurde.
Ok... but mode 0654 doesn't make sense, you should use mode=0644.
What Linux distribution do you use?
I've just checked with Debian 9, here the access.log is being created correctly (with mode 0644).
on the webspace page, view log window, access.log is empty
Please restart lclogsplit ("service lclogsplit restart") and then check if the access.log is updated when the website is accessed.
If even after a lclogsplit restart the access.log remains empty, check if the domain name is listed within /var/lib/liveconfig/accesslog.map.