Startseite » Forum » LiveConfig-Foren (deutsch) » Fehler und Problembehebung » Falscher Pfad in PHP mod_apache /usr/share/liveconfig/html/
Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 12
  1. #1
    Neuer Benutzer
    Registriert seit
    21.09.2019
    Beiträge
    6

    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?

  2. #2
    LiveConfig-Team Avatar von kk
    Registriert seit
    10.12.2010
    Beiträge
    3.312
    Zitat Zitat von Nobbi Beitrag anzeigen
    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.

    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

  3. #3
    Neuer Benutzer
    Registriert seit
    21.09.2019
    Beiträge
    6
    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.
    Geändert von Nobbi (30.09.2019 um 22:41 Uhr)

  4. #4
    Erfahrener Benutzer
    Registriert seit
    07.04.2011
    Beiträge
    710
    Zitat Zitat von Nobbi Beitrag anzeigen
    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.

    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.

  5. #5
    Neuer Benutzer
    Registriert seit
    21.09.2019
    Beiträge
    6
    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.
    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
    Geändert von Nobbi (01.10.2019 um 12:24 Uhr)

  6. #6
    Benutzer
    Registriert seit
    25.03.2014
    Beiträge
    52
    @Nobbi: Rein aus Interesse, Du speicherst 900.000.000.000 E-Mails und deren Rohdaten in einer MySQL (!) Datenbank? Warum macht man sowas?

  7. #7
    Neuer Benutzer
    Registriert seit
    21.09.2019
    Beiträge
    6
    @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.
    Geändert von Nobbi (01.10.2019 um 13:12 Uhr)

  8. #8
    Erfahrener Benutzer
    Registriert seit
    21.02.2011
    Beiträge
    308
    Klingt nach B1gmail. Wobei man sowas über Queue im Hintergrund machen sollte.

  9. #9
    Erfahrener Benutzer
    Registriert seit
    07.04.2011
    Beiträge
    710
    Zitat Zitat von Mogwais Beitrag anzeigen
    Wobei man sowas über Queue im Hintergrund machen sollte.
    jup. Schöner Redis/RabbitMQ, Daemon mit ggf. mehreren Threads/Prozessen im Hintergrund. Erleichtert vieles.

  10. #10
    Neuer Benutzer
    Registriert seit
    21.09.2019
    Beiträge
    6
    Zitat Zitat von Mogwais Beitrag anzeigen
    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
    Geändert von Nobbi (01.10.2019 um 14:42 Uhr)

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •