Falscher Pfad in PHP mod_apache /usr/share/liveconfig/html/

  • Moin,


    aufgrund der Fehler in php-fpm, vor allem das der Timeout nicht unendlich einstellbar ist, hat mich dazu bewogen mod_apache für meinen Ubuntu 18.04 einzusetzen. Mit erfolg, die Seite läuft nun ohne Timeouts gerade bei langen Datenbankoperationen.


    Leider hat sich wohl ein Fehler durch liveconfig eingeschlichen den ich zwar nicht reproduzieren kann aber der in der error.log vermerkt ist


    Code
    [Mon Sep 30 12:38:07.344059 2019] [php7:error] [pid 1285] [client 44.64.56.xx:36166] script '/usr/share/liveconfig/html/email.compose.php' not found or unable to stat
    [Mon Sep 30 12:43:37.091285 2019] [php7:error] [pid 1236] [client 148.64.56.xx:33739] script '/usr/share/liveconfig/html/email.php' not found or unable to stat
    [Mon Sep 30 13:39:08.600601 2019] [php7:error] [pid 1236] [client 148.64.56.xx:23436] script '/usr/share/liveconfig/html/start.php' not found or unable to stat
    [Mon Sep 30 14:52:20.492367 2019] [php7:error] [pid 1264] [client 148.64.56.xx:35310] script '/usr/share/liveconfig/html/webdisk.php' not found or unable to stat
    [Mon Sep 30 15:10:46.469588 2019] [php7:error] [pid 1078] [client 54.36.148.xx:47560] script '/usr/share/liveconfig/html/index.php' not found or unable to stat
    [Mon Sep 30 15:57:08.857594 2019] [php7:error] [pid 9876] [client 148.64.xx.xx:20924] script '/usr/share/liveconfig/html/email.php' not found or unable to stat


    Die PHP Datein entsprechen den Datein die eigentlich unter /va/www/webx/htdocs/ zu finden sind...Irgendwo hat sich da ein falscher Pfad eingeschlichen:

    Code
    /usr/share/liveconfig/html/


    Die Datein existieren natürlich unter diesem Pfad nicht nur in htdocs, bei PHP-FPM tritt der Fehler nicht auf.... kann mir da jemand helfen?

  • aufgrund der Fehler in php-fpm, vor allem das der Timeout nicht unendlich einstellbar ist, hat mich dazu bewogen mod_apache für meinen Ubuntu 18.04 einzusetzen.


    mod_apache? Meinen Sie evtl. Apache mod_php?
    Das ist ein latentes Sicherheitsrisiko - bei Servern mit mehreren Benutzern sollte das besser nicht eingesetzt werden.


    Lange Scriptlaufzeiten sollten anderweitig "bekämpft" werden, sofern man für den Code verantwortlich ist (Datenbankabfragen strukturell beschleunigen, "langsame" Scripte in CLI/Cron-Aufrufe auslagern, usw.). Jedes lange PHP-Script blockiert zwangsläufig einen Slot in Apache, so fängt man sich ggf. sehr schnell einen DoS ein.


    Zitat
    Code
    [Mon Sep 30 12:38:07.344059 2019] [php7:error] [pid 1285] [client 44.64.56.xx:36166] script '/usr/share/liveconfig/html/email.compose.php' not found or unable to stat


    Das kann z.B. dann auftreten, wenn jemand über eine nicht konfigurierte Domain oder über die IP-Adresse auf "/email.compose.php" zugreift - dann landet das (durch den 000-default_vhost) in /usr/share/liveconfig/html/.


    Werfen Sie mal einen Blick auf /var/log/apache2/other_vhosts_access.log - da müsste der jeweilige Domainname mitprotokolliert werden, vielleicht hilft das weiter.


    Viele Grüße


    -Klaus Keppler

  • Guten Tag,


    danke für den Hinweis, werde ich prüfen...Ja ich meine mod-php aber ich verwende ausschließlich dedizierte Server allein für meine Projekte.


    Die timeouts passieren bei Datenbanken mit 900 Mrd Einträgen und deren Operationen nun mal, da kann man optimieren wie man will und es handelt sich auch um ein regelmäßig gepflegtes Script das schon fast 20 Jahre am Markt ist, keine Eigenentwicklung und auch die Hardware ist schon high end und völlig überdimensioniert für so ein kleines Script. Bei mod_php ist das alles unproblematisch nur bei FPM gibt es ständig gateway errors was wohl am mod_proxy selbst liegt, ich habe zumindest aktuell noch keine Lösung gefunden den Fehler gänzlich abzustellen, eventuell ist es aber auch nur ein bug.

  • Die timeouts passieren bei Datenbanken mit 900 Mrd Einträgen und deren Operationen nun mal, da kann man optimieren wie man will


    Lang-andauernde Operationen gehören nicht über den Apache, sondern in die CLI. Dort gibt es effektiv keine Zeit-Restriktionen, außerdem nimmt dein Prozess dann keinen Apache-Slot weg, wie Herr Keppler schon schrieb.


    Zitat

    Bei mod_php ist das alles unproblematisch nur bei FPM gibt es ständig gateway errors was wohl am mod_proxy selbst liegt


    Proxy?


    PHP-FPM wird über mod_fastcgi angebunden.


    Entsprechende Fehler werden protokolliert.


    Wie gesagt: Alle Anfragen, die EIGENTLICH in den Hintergrund gehören, dorthin verlagern. Damit sind nur noch "kleine" HTTP-Anfragen übrig.


    Zumindest nach den aktuell vorliegenden Infos.

  • Zitat

    Lang-andauernde Operationen gehören nicht über den Apache, sondern in die CLI.


    Gebe ich dir vollkommen recht bei mysql mache ich das auch so aber mein Dienstleistung ist ja genau das, Mailpostfächer anzubieten und da gibt es Postfächer mit großen Mengen an Daten die gelöscht werden müssen teilweise 100.000 und bei 900 Mrd Mail in SQL dauert das manchmal zu lange.

    Zitat

    Proxy?


    mod_proxy_fcgi und dafür braucht es mod_proxy (ich hasse Abhängigkeiten) und dann brauche ich vermutlich noch proxy_http2 und proxy_http meinst ich soll mal was anderes verwenden? Fcgi habe ich noch bei Ubuntu 14.04. verwendet. Das stecken wieder so viele apache module drinnen die den Apache ausbremsen, das gefällt mir alles nicht wieder neue logs bei 1.500.000 requests am Tag


    Also ist mod_php jetzt wirklich so schlecht? Das einzige was mich wirklich stört ist http2, das geht unter mod_php nicht und das ist mist

  • Zitat

    Nobbi: Rein aus Interesse, Du speicherst 900.000.000.000 E-Mails und deren Rohdaten in einer MySQL (!) Datenbank? Warum macht man sowas?


    Nein, die Datenbank hat nur die Verweise zu den Mails deren Daten auf dem Storage Server liegen, sonst wäre die Datenbank 21TB groß. Der Script Hersteller hat nun auch viele asynchrone Operationen eingeführt um das Löschen von Usern wenigstens erträglich und ohne Timeouts durchzuführen aber wenn ich z.b die tägliche Logfile durchsuchen will, Mails aus den Ordnern der User löschen oder User ihre Mails selbst löschen wollen dann muss das Script die 100.000 mails in der Datenbank finden und dann die Daten zusammen mit dem auf dem Storage befindlichen Daten zusammen löschen. Ich denke das es nicht sinnvoll ist jede Mail einzeln zu löschen gleichwohl die teilweise 400byte groß sind! Auch die Technik versagt hier immer mehr, der Storage und seine Suchzeiten sind auch unterirdisch und 21 TB SSD ist für einen kostenlosen werbefinanzierten Dienst 2019 eben auch nicht mal aus dem Ärmel geschüttelt.

  • Klingt nach B1gmail. Wobei man sowas über Queue im Hintergrund machen sollte.


    Jo korrekt, die Lösung hingegen verstehe ich nicht. Für die Mailzustellung und Versand gibt es ja bereits seit Jahren eine Warteschlange, hat ja jetzt mit Zustellung etc nicht zu tun, hier geht es ja um die Speicherung von langfristigen Daten bis hin zu 2008. Sicher wäre die Abarbeitung der Löschoperationen in einer Warteschlange sinnvoll aber ich wüsste nicht wie ich sowas gewährleisten kann.


    Das problem hat sich übrigens von selbst geklärt. Heute Update/Upgrade gemacht und der Timeout ist weg :D

  • Jo korrekt, die Lösung hingegen verstehe ich nicht, ich würde mir wünschen das sowas der Webserver oder das BS regelt.


    Das Betriebssystem? Wie soll das denn hier eingreifen können?


    Das ist Aufgabe der Anwendung - respektive die Konzeption der Anwendung an sich.


    Das ganze führt jetzt allerdings doch etwas ins Abseits.


    mod_php mag in deinem Setup funktionieren, zu empfehlen ist es in keinem Fall (Beispiel: unter Debian Stretch benötigt mod_php den mpm_prefork. Der kann aber kein HTTP2 mehr).

  • seit dem Update heute morgen scheint es keine Probleme mehr zu geben, kein Timeout, keine Fehlermeldung mehr, seltsam....alles gut plötzlich...ich hatte proxy_http und proxy_http2 deaktiviert, glaub zwar nicht das es daran lag aber vllt an dem Update und Upgrade von heute. Wegen dem BS war eigentlich der Gedankengang alle PHP Prozesse in einer Warteschleife oder cache zu halten bis diese abgearbeitet sind während im Vordergrund das Script weiter läuft, irgendwie so, Schnapsidee.


    Bei Ubuntu 18.04 kein mpm_event unter mod_php und demzufolge auch kein http2, daher ist das mit FPM schon besser jetzt....auf jedenfall danke für die Hilfe Männers!

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!