Beiträge von Febas

  • LiveConfig v2.8.0

    Zitat von kk

    "Nicht zugeteilt" filtert alle Zertifikate, die nicht irgendeinem Kunden zugeteilt sind.
    Damit sollten doch die eigenen Zertifikate angezeigt werden - oder etwa nicht?


    Ist hier nicht der Fall. Wenn „Nicht zugeteilt“ ausgewählt ist, erscheint nur das Default SSL Zertifikat. Die eigene Zertifikate werden bei „einem Kunden zugeordnet“ angezeigt. Unter Kunde steht dann „Administrator, System (0)“.

  • LiveConfig v2.8.0

    Zitat von kk

    Mit der v2.9 haben wir beim Tabellen-Objekt nun ein Dropdown zur Filterung von Einträgen. Ich nehme das für die SSL-Zertifikate gleich mal so mit auf.


    Der Filter ist ja jetzt da, aber man hat immer noch keine Möglichkeit sich nur die eigenen Zertifikate anzuzeigen.

  • LiveConfig v2.8.0

    Eventuell sollte man wegen der Übersichtlichkeit im Admin-Bereich zwei Tabellen (oder einen Filter [Checkbox etc.]) vorfinden können: Einmal für die Kunden angelegte Zertifikate und einmal für sich selber angelegte Zertifikate. Derzeit ist die Übersicht wegen der vielen Kunden-Zertifikate nicht schön, wenn man zuvor eigene Admin-Zertifikate verwaltet hat.

  • LiveConfig v2.8.0

    Ist es normal, dass unter Debian 10 PHP-FPM nicht erkannt wird?


    php7.3-fpm ist installiert und proxy_fcgi aktiviert.



    DIAG:

    Code
    - PHP 7.3.4 [DEFAULT] (code='php7')
   CGI/FastCGI: /usr/bin/php-cgi
   default php.ini: '/etc/php/7.3/cgi/php.ini'


    Code
    [2019/08/22 18:23:57.753024] [737|749] [LUA] PHP version nil configured as FPM for subscription xxx but no PHP-FPM found for this version!


    Bei den optionalen PHP-Versionen von LiveConfig funktioniert FPM ohne Probleme.

  • PHP FPM und mod_rewrite


    Wirklich alle Rewrite-Regeln?


    Probier es mal ansonsten mit folgender Zeile ganz oben in der .htaccess-Datei aus:


    Options -MultiViews

  • Anwendung WordPress 5.1.1

    Hallo,


    die neue WordPress-Version 5.1.1 im Installer (2019-03-23) scheint ein Fehler zu haben. Nach der Installation kommt die Fehlermeldung "Fehler beim Aufbau einer Datenbankverbindung" beim Aufrufen der Domain. In der wp-config.php wurden die Datenbank-Zugangsdaten anscheinend nicht ersetzt:


    Code
    ...
define( 'DB_PASSWORD', 'passwort_hier_einfuegen' );..

  • Standard PHP-Version ändern

    Zitat von tfi

    Wir würden nun gerne den Standard überall auf 7.3 setzen ohne aber die bestehenden Verträge/Webseiten,
    die in der Auswahl Standard (und damit 5.6 usw.) gewählt haben, zu beeinflussen.


    Das geht in Prinzip nur wenn man manuell von Standard auf PHP 5.6 für den Kunden bzw. Domain umstellt. Wir haben hierbei einfach direkt in die Datenbank eingegriffen und bei den Domains die keine bestimmte PHP-Version hatten, fest auf die 5.6-Version geändert. Aber aufpassen, dass man nicht die Datenbank zerschießt oder sonst was anrichtet ;)

  • LiveConfig v2.7.0

    Zitat von kk

    Danke für die Info. Offenbar haben Sie eine recht restriktive umask für Init-Scripte (077 statt 022). Wir prüfen das mal, ggf. werden die Init-Scripte (für non-systemd) noch mal entsprechend angepasst.


    Viele Grüße


    -Klaus Keppler


    Gibt es da schon was neues? Danke.

  • LiveConfig v2.7.0

    Auf dem Server ist Debian 9 drauf (ursprünglich wurde mal Debian 7 installiert). Sowohl systemd als auch sysvinit ist installiert.


    Code
    ps -p 1
  PID TTY          TIME CMD
    1 ?        00:00:02 init


    Laufen tut aber wohl sysvinit.


    FPM habe ich nicht mit den LiveConfig-PHP-Versionen, sondern mit der Standard PHP7-Version von Debian getestet.


    Nun habe ich den Vertrag auf PHP 7.2 umgestellt (die neuen PHP-Pakete von Heute wurden ebenfalls aktualisiert). Der Hauptprozess läuft:


    Code
    root     23015  0.0  0.0 491952 17452 ?        Ss   16:32   0:00 php-fpm: master process (/etc/php-fpm/php72-fpm.conf)


    Aber es wird kein Pool-Prozess gestartet. Weiterhin der 503 Fehler. In der error.log vom Vertrag:


    Code
    [Tue Oct 30 16:33:21.662527 2018] [proxy:error] [pid 23044:tid 139913261623040] (13)Permission denied: AH02454: FCGI: attempt to connect to Unix domain socket /var/run/php72-fpm/vertragsname.sock (*) failed
[Tue Oct 30 16:33:21.662565 2018] [proxy_fcgi:error] [pid 23044:tid 139913261623040] [client 89.166.xx:52687] AH01079: failed to make connection to backend: httpd-UDS


    Diesmal existiert der Ordner inkl. der Datei:


    /var/run/php72-fpm/vertragsname.sock


    UPDATE:


    Anscheinend werden die Rechte auf diesem System falsch gesetzt (Der Ordner wurde automatisch angelegt):


    Code
    7370504  0 drwx------ (700)  2 root       root          60 Okt 30 17:18 php72-fpm
7632008  4 -rw------- (600) 1 root       root           4 Okt 30 17:18 php72-fpm.pid


    Auf einem neu installieren System werden folgende Rechte vergeben (Hier funktionierte alles auf Anhieb):


    Code
    931194  0 drwxr-xr-x (755)  2 root     root        80 Oct 30 17:22 php72-fpm
934050  4 -rw-r--r-- (644) 1 root     root         5 Oct 30 17:22 php72-fpm.pid

  • LiveConfig v2.7.0

    Nach dem Update auf LiveConfig 2.7.0 wurde ein Vertrag auf FPM umgestellt. Die PHP-Seite wirft beim Aufruf nun ein 503-Error ab.


    /var/log/php7.0-fpm.log:

    Code
    [30-Oct-2018 14:45:11] ERROR: unable to bind listening socket for address '/var/run/php7.0-fpm/vertragsname.sock': No such file or directory (2)
[30-Oct-2018 14:45:11] ERROR: FPM initialization failed


    Der Ordner /var/run/php7.0-fpm/ existiert nicht.


    Der Vertrag befindet sich auf einem lcclient-Server.


    Vor Aktivierung:


    Code
    ps aux | grep fpm
root     30328  0.0  0.0 448464 17516 ?        Ss   15:05   0:00 php-fpm: master process (/etc/php/7.0/fpm/php-fpm.conf)
www-data 30329  0.0  0.0 448464  9556 ?        S    15:05   0:00 php-fpm: pool www
www-data 30330  0.0  0.0 448464  9556 ?        S    15:05   0:00 php-fpm: pool www


    Nach Aktivierung, gibt es keinen einzigen FPM-Prozess.


    Code
    service php7.0-fpm status
[FAIL] php-fpm7.0 is not running ... failed!

  • Php-fpm

    Wie sieht es eigentlich mit den OPcache-Einstellungen:


    Wenn man nun ein Limit mittels opcache.max_accelerated_files z.B. auf 4000 Dateien setzt, gelten die 4000 je Vertrag oder für alle Verträge zusammen?

  • Php-fpm

    Thema Schnelligkeit: https://timreeves.de/internet-…-apcu-memcache-memcached/


    Zitat

    Nach eigener Beobachtung haben FastCGI-Prozesse tatsächlich je ein eigenes APCu Cache. Das ist ein starkes Argument für PHP-FPM bei Websites die viele Besuche haben und Userland-Cache stärker nutzen. FPM ist daher auch Voraussetzung dafür, dass APCu-Cache-Einträge automatisch konsistent bleiben, denn das Cache von einem FastCGI-Prozess könnte inhaltlich divergieren von dem eines anderen FastCGI-Prozesses. Fazit: Mit FastCGI dürfen nur „fixe“ Werte in APCu notiert werden, z.B. Basiswerte einer WordPress-Installation, damit sie nicht jedes Mal aus der DB gelesen werden müssen. Die Verwendung als klassischer Key-Value Store mit dynamischen Werten wird bei FastCGI nicht funktionieren!


    Das wäre ja ein gutes Argument für FPM. Hat da schon jemand auf FPM umgestellt und irgendwelche Geschwindigkeits-Unterschiede festgestellt?

  • Datenbankspeicher wird nicht zum belegten Speicherplatz dazu berechnet!!!

    Zitat von kk


    Wie gesagt: es ist nicht ganz trivial, ein Datenbank-Quota zu realisieren, weil das rein technisch eben nicht über ein Filesystem-Quota erledigt werden kann. LiveConfig zeigt die Datenbankgrößen an, kann diese aber nicht begrenzen.
    Wir haben bereits eine Lösung hierfür (vereinfacht gesagt wird beim Erreichen einer festzulegenden Datenbank-Größe das Recht für INSERT vorübergehend entfernt). Noch ist das aber nicht umgesetzt...


    Fast 5 Jahre her. Aber die Lösung wurde bisher nicht umgesetzt oder? :rolleyes:

  • Backup & LiveConfig Absturz


    Bei dem Kunden den Vertrag einfach deaktivieren und dann wieder auf "aktiv". Sollte dann wieder gehen.

  • Domain verschwindet bei Anlegen einer Subdomain

    Das Problem kann ich ebenfalls bestätigen:


    Beim Anlegen einer externen Domain z.B. "test.de" wird keine www-Subdomain angelegt. Bei der Domain "test.de" ist der http-Zugriff aktiviert, aber der Webspace deaktiviert. Lässt man das so stehen und legt im nächsten Schritt die Subdomain "www.test.de" an, verschwindet "test.de" und es bleibt nur "www.test.de" stehen. Dabei ist es von keiner Bedeutung ob man eine Subdomain "www.test.de" oder "andere.test.de" anlegt. Die "test.de" verschwindet in jedem Fall.


    Lediglich wenn man vor dem Anlegen der Subdomain "www.test.de" oder "andere.test.de" die Domain "test.de" bearbeitet und dabei den Webspace aktiviert, bleibt die Domain auch nach dem Anlegen der o.g. Subdomain bestehen.

  • cron.php.sh verwendet alte php.ini

    Zitat von kk


    Hmm, LiveConfig ging an der Stelle davon aus, dass /usr/bin/php in der Version 5.x vorliegt und nutzt daher das "Standard"-Verzeichnis der php.ini (~/conf/php5/).
    Wir haben das Session-Aufräum-Script inzwischen modifiziert, so dass die PHP-Version explizit ausgelesen wird. Die Änderungen sind in LiveConfig v2.5.2 drin (sollte heute Abend bereits als Preview bereitstehen).


    Super, vielen Dank!