Beiträge von kk

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 tmp

Unter 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 tmp

Zitat von leonex

Was 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.

Zitat von ateo

[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.

Zitat von dicker

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.

Zitat von moddie

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.

Zitat von moddie

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:

• updated integrated MariaDB client to v3.0.5
• automatically detecting language for iPhone/iPad configuration page (/liveconfig/hosting/mobileconfig)
• configuring ProFTPD (v1.3.5+) to also support TLS 1.1 and 1.2
• fixed bug when displaying CAPTCHA image on Safari browsers
• in some cases, new created access.log files can't be read by users (too restrictive umask in lclogsplit)
• lcclient: remove /etc/logrotate.d/liveconfig during upgrade (got replaced by /etc/logrotate.d/liveconfig-vhosts)
• fixed bug in lclogsplit when NGINX access log was rotated (already rotated log file sometimes was parsed again several times)
• date-based deactivation of autoresponder didn't work with SQLite backend

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:

• integrierten MariaDB-Client auf v3.0.5 aktualisiert
• automatische Erkennung der Sprache für die iPhone/iPad-Konfiguration (/liveconfig/hosting/mobileconfig)
• ProFTPD-Konfiguration (ab v1.3.5) unterstützt nun auch TLS 1.1 und 1.2
• Fehler in CAPTCHA-Anzeige mit Safari-Browser behoben
• neu erstellte access.log-Dateien konnten in manchen Fällen nicht durch Benutzer gelesen werden (zu restriktive umask in lclogsplit)
• lcclient: Datei /etc/logrotate.d/liveconfig wird nun während des Upgrades gelöscht (wurde durch /etc/logrotate.d/liveconfig-vhosts ersetzt)
• Fehler in lclogsplit behoben, wenn NGINX access.log-Datei rotiert wurde (die bereits rotierte Log-Datei wurde ggf. mehrmals erneut verarbeitet)
• Datums-basierte Abschaltung beim Autoresponder funktionierte nicht mit SQLite als DB-Backend

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).

Zitat von aci

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.

Zitat von leo

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.

Zitat

one 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.

Zitat von leo

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).

Zitat von leo

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.

Zitat von DominikP

Obwohl ein externer Server eingegeben wurde, versucht sich liveconfig auf ein Socket zu verbinden welches nicht existieren kann. (MySQL Server ist eine externe, gesicherte Anwendung)
[...]
Mit der vorherigen Version (2.5.0) hat dies noch einwandfrei funktioniert!

Mit v2.6.0 wurde der integrierte MySQL-Client durch den MariaDB Connector/C ersetzt. In unserer Testumgebung klappt die Verbindung via TCP/IP zu externen MySQL-Servern aber problemlos.
Welche Distribution genau setzen Sie ein? Können Sie uns ggf. Ihre my.cnf-Datei mal an support@liveconfig.com schicken?

Fehler gefunden: in der Upgrade-Funktion der RPMs wurde nur unter /etc/apache2/ gesucht (OpenSUSE), während CentOS aber /etc/httpd/ verwendet.
Wurde eben mit r4974 korrigiert. Danke für den Hinweis!

Zitat von llaehn

nach dem Update startet der Webserver nicht korrekt da die accesslog.map im Ordner /var/lib/liveconfig erwartet wird.
Die scheint sich nun aber im Ordner /etc/httpd zu befinden.
Ich habe ein Symlink au /var/lib/liveconfig erstellt. So ging es erstmal.
Wo muss der Pfad geändert werden?

Umgekehrt: die Datei befand sich offenbar noch in /etc/httpd/, gehört ab v2.6.0 aber in /var/lib/liveconfig.
Ich tippe mal auf CentOS? Welche Version genau?
Eigentlich sollte während des Upgrades die Datei automatisch entsprechend verschoben werden.
Welches Paket genau haben Sie installiert (liveconfig oder lcclient) und auf welcher Distribution genau?