Netz - Rettung - Recht (Artikel mit Tag PHP)

Validierung von Eingaben im Kontaktformular

nospam@example.com (Thomas Hochstein) — Thu, 24 Mar 2022 05:00:00 +0000

Meine Homepage hat noch ein Kontaktformular. Selbstverständlich findet sich auf derselben Seite auch meine Mailadresse (samt GPG-Key), und man sollte annehmen, dass das der übliche Weg zur Kontaktaufnahme wäre, aber überraschend viele Nachrichten erreichen mich dann doch noch über das Kontaktformular. Dafür mag es verschiedene Gründe geben: der Mailclient auf dem Arbeitsrechner (oder dem Smartphone) hat vielleicht kein Profil mit der gewünschten Absenderadresse - oder für den Absender ist “E-Mail” gleichbedeutend mit “GMail” oder einem anderen webbasierten Dienst, d.h. es wird gar kein Mailprogramm mehr verwendet. Sei dem, wie dem sei - das Kontaktformular wird (trotz Recaptcha) durchaus genutzt, und ab und an verschluckte es sich an unerwarteten Eingaben. Gerne genommen war beispielsweise ein Komma im Eingabefeld für den Namen (“Müller, Egon”). Da das Formular die Eingabe einfach 1:1 in das From:-Feld übernommen hat, fand sich da dann etwas wie

Müller, Egon <absender@domain.example>

Das aber gefällt der Technik nicht, denn ein , trennt im From: oder To: mehrere Absender/Adressaten voneinander. Soll im Namen ein Komma vorkommen, muss der gesamte Name in " gesetzt werden. Außerdem fiel mir bei dieser Gelegenheit auf, dass ich die Eingaben insgesamt nicht wirklich validiere. Zeit, das zu ändern.

Und während ich noch überlegte, wie man noch einmal am besten eine Mail-Adresse validiert (ein wirklich nicht einfaches Unterfangen, aber mit Regular Expressions möglich, wenn man keine Kommentare akzeptiert), fiel mir wieder ein, dass ich so etwas doch schon einmal gebastelt hatte. Und richtig: da lag eine bereits halb vergessene PHP-Klasse herum, die Validierungsfunktionen bietet, u.a. die syntaktische Validerung einer Mailadresse. Und außerdem kann sie eine Eingabe auch gegen einen beliebigen regulären Ausdruck validieren.

Also prüft das Kontaktformular jetzt, ob die E-Mail-Adresse syntaktisch gültig ist (weiterhin aber nicht, ob es diese Adresse gibt - was zumindest mit hoher Wahrscheinlichkeit möglich ist - oder ob sie dem Absender des Formulars gehört - was nicht möglich ist), wobei fast alle gültigen und jedenfalls alle real anzunehmenden Mailadressen akzeptiert werden, und es testet auch, ob der Absendername eines der Zeichen enthält, die nur zulässig sind, wenn der Name insgesamt in " steht. Dabei wird nicht jeder denkbare Fall abgefangen, aber immerhin die naheliegenden. Das ist schon einmal ein deutlicher Schritt nach vorne (und war nicht wirklich Aufwand, weil ich den Großteil der Vorarbeit bereits geleistet hatte).

[Nachträglich veröffentlicht im April 2022.]

Naives MVC

nospam@example.com (Thomas Hochstein) — Thu, 25 Mar 2021 21:20:00 +0000

Seit 2014 setze ich sowohl bei neuen Websites als auch bei der “Renovierung” alter auf static site generators, also Generatoren für statische Webseiten, die aus Templates und Inhalten in verschiedenen Markups, aus Helper-Klassen und ggf. auch Datenbankinhalten HTML-Seiten generieren, die dann auf den Server hochgeladen werden. Das hat verschiedene Vorteile ggü. CMS oder selbstgeschriebenem Code: weil nur statisches HTML ausgeliefert wird, muss auf dem Server keine Scriptsprache wie PHP laufen, was die Last vermindert und vor allem auch aus Sicherheitsgründen angenehm ist, denn wo kein Code läuft, gibt es auch keine Sicherheitslücken. Außerdem bringen Generatoren wie Nanoc, mein bevorzugtes Werkzeug, ein ganzes Toolset wie Helper-Klassen für häufige Aufgaben und Filter für die verschiedensten Markup-Formate mit. So habe ich mich daran gewöhnt, dass ich das Grundgerüst einer Website in Form von Templates, meistens in HAML, erstelle, für die optische Gestaltung CSS-Frameworks wie Bootstrap nutzen kann, wobei ein LESS-Compiler automatisch mitkommt, und dass ich die eigentlichen Inhalte in Markdown (oder in einer Kombination aus HAML und Markdown) erstellen kann. Auf diese Weise habe ich mir einen gut funktionierenden Workflow geschaffen.

Das alles erfüllt seinen Zweck im Grundsatz sehr gut, auch für in begrenztem Umfang dynamische Elemtente: es genügt ja, die Webseitengenerierung in regelmäßigen Abständen neu anzustoßen, bspw. nachts, oder wenn man will auch stündlich. Nanoc kann man zudem aus Datenbanken speisen, und auch beim bloßen Umgang mit Textdateien lassen sich deren Metadaten auswerten, um bspw. die letzten Änderungen zu verlinken, Termine anzukündigen (aber nur, solange sie noch bevorstehen), Zeitangaben automatisch zu ersetzen (“Diese Seiten stehen schon seit x Jahren online”) und anderes mehr. Man kann auch mal ein PHP-Script dazwischenmixen, beispielsweise für ein Kontaktformular. Ihre Grenzen erreicht die Technik erst, wenn es um tatsächlich dynamische Seiten geht, also bspw. die Suche in Datenbanken (bei der man die Einträge nicht schlicht insgesamt vorab als statische Seiten erzeugen kann) - oder wenn ein Passwortschutz (jenseits von Basic Auth) oder ein Session-Management implementiert werden soll. Dann braucht es etwas anderes. Nur was?

Bestimmt fünf Jahre lang habe ich die Überarbeitung verschiedener Webseiten vor mir hergeschoben, deren Anforderungen über die Möglichkeit von static site generators hinausgehen. Der ursprüngliche Ansatz aus meinen ersten (und zweiten) Schritten mit PHP - jede Seite ein Mix von HTML und PHP, letzteres vor allem Funktionen zum Generieren der Seitenstruktur (Header, Footer) und Navigation als “Templating für Arme” - kam natürlich nicht mehr in Betracht; natürlich machen allein Templates in diesem Zusammenhang Sinn. Aber ich wollte die Inhalte auch nicht mehr in HTML verfassen, sondern zumindest in Markdown; und ein CSS-Baukasten wie Bootstrap sollte sich auch einbinden lassen, was einen Preprocessor wie LESS oder SASS zumindest wünschenswert macht. Über die Jahre habe ich mit vielen Gedanken gespielt, bspw. an Frameworks wie Laravel oder Symfony; früher hatte ich über viele Jahre die CakePHP-Mailingliste abonniert. Das erschien mir dann aber doch vergleichsweise aufwendig, um letztlich einen Passwortschutz und ein paar Formulare bzw. Datenbankausgaben zu implementieren.

Nach langer Pause und Stagnation wollte ich das Thema dieses Jahr über die Osterzeit aber noch einmal angehen. Dazu gehörten mehrere Schritte: Zunächst waren einige eng verbundene Webseiten zu entkoppeln, die gemeinsame Ressourcen nutzten, also bspw. alle dieselbe CSS-Datei eingebunden hatten. Danach brauchte es ein Design, das optisch den bisherigen Webseiten ähnlich sein sollte, nur schicker und möglichst unter Verwendung von Bootstrap - und dafür wiederum musste ich mich mit Bootstrap 5 auseinandersetzen (meine bisherigen Webseiten setzen alle noch auf die Version 3 auf), und dafür wiederum von LESS auf SASS wechseln. Der wiederum nächste Schritt wäre dann ein PHP-basiertes Templating-System, und dann musste all das zusammengesetzt und um die notwendige Funktionalität erweitert werden.

Bootstrap 5 und SASS

Bootstrap 5 erwies sich als gar nicht so anders; klar, das Grid ist neu und setzt auf Flexbox, es gibt einen Haufen Utility-Klassen für Abstände und bei den Komponenten hat das neue “Card”-Element einige bisherige Elemente ersetzt, aber die einzige Neuerung mit Umstellungs- und Änderungsbedarf war der Wechsel von LESS als CSS-Preporzessor zu SASS.

Ich habe also zunächst die Quell-Dateien heruntergeladen und mich damit vertraut gemacht und mir dann eines der Beispiele ausgesucht, um davon ausgehend einen groben Design-Entwurf zu puzzeln. Das war dann auch der Zeitpunkt, wo ich einen SASS-Compiler brauchte. Das erwies sich als überraschend einfach: Dart Sass bietet Pakete für Windows an. Herunterladen, dart.exe und sass.snapshot in ein bin/-Verzeichnis packen, eine Batch-Datei mit bin/dart.exe bin/sass.snapshot mein.scss mein.css ins Hauptverzeichnis des Projekts, und schon kann ich aus mein.scss eine CSS-Datei zaubern. In der .scss-Datei importiere ich dann die notwendigen Bootstrap-Komponenten (oder auch einfach alles), ggf. weitere Elemente (wie Font Awesome), passe Variablen an (insbesondere das Farbschema), ergänze eigenes CSS - et voilá. Und all das kann ich dann direkt lokal auf meinem unter Windows laufenden Entwicklungsrechner testen: Änderungen vornehmen, Build-Script starten, HTML-Datei im Browser neu laden - und ggf. von vorne.

Eine solche .scss-Datei kann dann beispielsweise so anfangen:

/* --------------------------------------------------------
 *  SCSS styles and Bootstrap import
 */

// custom variables
$primary:   #314e8c;
$secondary: #bad1e1;
$info:      #ced4da; /* gray-400 */
$body-bg:   $secondary;

// import from Bootstrap
@import "bootstrap/scss/bootstrap.scss";

// import from FontAwesome (Solid)
@import "fontawesome/scss/fontawesome.scss";
@import "fontawesome/scss/solid.scss";

// custom SCSS
/* --------------------------------------------------------
 * Text elements
 */

h1, h2, h3, h4, h5, h6 {
  color: $primary;
}

Damit werden die gewünschten Primär- und Sekundärfarben gesetzt, die ich aus dem bisherigen Design übernommen habe, die Farbe für “Info”-Boxen auf einen Grauton umgestellt und der Hintergrund in der Sekundärfarbe eingefärbt. Dann ziehe ich das komplette Bootstrap-Framework und Font Awesome als Webfont ein (hier kann man sich natürlich auf die Elemente beschränken, die man nutzt; das macht alles schlanker), und danach folgen die Anpassungen und eigenen Elemente. So färbe ich bspw. die Überschriften gerne in der Primärfarbe der jeweiligen Website ein.

Das war, ehrlich gesagt, im Ergebnis dann sehr viel einfacher als ich befürchtet habe, und es gelang mir überraschend schnell, ein brauchbares Mockup zu erstellen. Feinheiten folgen dann, wie immer, sobald sie für bestimmte Elemente oder Situationen benötigt werden.

Den ganzen Kram - Bootstrap-Quellcode, Font-Awesome-Quellcode, die ausführbaren Dateien von Dart Sass und meine .scss-Datei - habe ich natürlich in ein Git-Repository gepackt. Dabei haben sowohl Bootstrap als auch Font Awesome als auch Dart Sass jeweils nach dem initialen Einkopieren der Dateien einen eigenen Branch erhalten. Wenn ich nun bspw. eine neue Bootstrap-Version einspielen will, genügt es, den Bootstrap-Branch auszuchecken, die neuen Dateien einzukopieren und ihn in den Master-Branch zu mergen. So sehe ich sofort alle Änderungen und kann ggf. Anpassungen vornehmen.

Die am Ende dieser Operationen erzeugte mein.css-Datei kann ich dann jeweils in das Repository (oder die Repositories) für den Quellcode der einzelnen Webseiten einkopieren.

Templates

So weit, so gut. Im nächsten Schritt sollte ich dann aus dem Mockup ein Template machen, in das sich Inhalte einbinden lassen. Davor bedarf es aber eines Template-Systems, das diesen Schritt (Template laden, mit Inhalten füllen) technisch umsetzt.

Für eine simple interne Seite - Erzeugen von Mailboxen und Mailadressen über ein Webinterface - hatte ich 2017 bei der Renovierung des ursprünglich aus dem Jahr 2009 stammenden Codes auf Plates, ein einfaches PHP-Templating-System, gesetzt. Zusammen mit Bootstrap sah das hübsch aus und war funktional, wenn auch vielleicht von der Funktionalität her eher überschaubar. So richtig wollte das aber nichts werden; schon das Einbinden machte mir Schwierigkeiten, und mit dem Templating-System wurde ich ebenfalls nicht warm.

Also dachte ich mir, warum nicht etwas verwenden, von dem ich weiß, dass es sich anderswo bereits bewährt hat? So habe ich mich dann für Smarty entschieden, denn was für Serendipity gut ist, kann für ein simples Projekt nicht schlecht sein. Außerdem kann ich dann das, was ich lerne, direkt noch anderswo zum Einsatz bringen. Das funktionierte dann auch direkt sehr schön, zumal Smarty das Einbinden von Teil-Templates (Partials) in Templates unterstützt; man kann sich also das endgültige Template aus wiederverwertbaren Bausteinen zusammenstückeln. Einen Wermutstropfen gibt es freilich: die Templates sind kein HAML, sondern HTML und Smarty, aber das passt - so viele Templates braucht man ja in der Regel nicht.

Wichtiger war mir, die Inhalte nicht komplett als HTML verfassen zu müssen; Markdown ist da meine Standardlösung. Und wenn ich mich schon an Serendipity bediene, warum dann nicht auch hier? Das Markdown-Plugin dort nutzt PHP Markdown, und das lässt sich natürlich auch sehr schön in meinem Projekt verwenden.

Model-View-Controller

Jetzt mussten alle diese Einzelteile “nur noch” sinnvoll zusammengeführt werden. In meinem schon angesprochenen Plates-Projekt hatte ich für jede Webseite weiterhin jeweils eine gesonderte PHP-Datei, die im Prinzip aber nichts anderes machte, als das Template aufzurufen und mit Inhalten zu füllen. Außerdem gab es für jede Seite dann ein gesondertes Template, dass auf ein Standard-Template aufsetzte. Das kann aber natürlich nicht die Lösung sein. Nicht nur Serendipity macht das anders: im Prinzip gibt es primär eine PHP-Datei, nämlich eine index.php im Webroot, die als Parameter die jeweils anzuzeigende Webseite übergeben bekommt und sich dann um den Rest kümmert.

Im Grundsatz ist das ein Model-View-Controller-Pattern, kurz MVC. Das Model liefert die Daten, sorgt also in einer Applikation üblicherweise für die Abbildung in einer Datenbank. Views sind die Präsentation, die Templates, die mit Inhalten gefüllt werden. Und der Controller führt beides zusammen. Natürlich kann man das mehr oder weniger ausgefeilt betreiben; mir genügte eine weniger ausgefeilte Lösung, die bspw. einzelne Aktionen im Controller nicht in Funktionen auslagert, sondern im Kern auf ein langes switch-Statement setzt. Immerhin enthält der Großteil der Webseiten primär einmal Text, der angezeigt werden muss; ich will ja keine Webapp schreiben.

Am Anfang steht die Frage, wie man die anzuzeigende Webseite als Parameter übergeben möchte. Eine URL wie https://meine-website.example/index.php?page=about/contact sieht ja wirklich hässlich aus und ist auch unter SEO-Gesichtspunkten keine gute Idee. Stattdessen möchte ich gerne URLS wie https://meine-website.example/about/contact/ haben. Hier kommt mod_rewrite zu Hilfe:

RewriteEngine On
# rewrite URLs to controller
RewriteCond %{REQUEST_URI} !^/.well-known
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ /index.php?page=$1 [QSA,L]

Die erste der beiden Bedingungen sorgt dafür, dass alle Aufrufe in das Verzeichnis /.well-known/ nicht umgesetzt werden; das ist bspw. erforderlich, damit certbot von Let’s encrypt seine Aufgaben erfüllen kann. Die zweite sorgt dafür, dass tatsächlich physisch vorhandene Dateien angezeigt werden. So lassen sich bspw. Textdateien oder Downloads unterbringen, die “as is” ausgeliefert werden sollen. Die darauffolgende Regel schnappt sich den Pfad - im Beispiel also about/contact/ - und ruft die index.php mit diesem Pfad als Parameter auf. Damit lässt sich arbeiten.

Im zentralen PHP-Script wird dieser Pfad dann zunächst normalisiert (damit er mit oder ohne abschließenden Slash “/” zur selben Seite führt) und auf unerwünschte Zeichen geprüft, damit nicht böse Menschen versuchen, unerwünschte Pfade (../../../../etc/passwd) zu übergeben. Der Rest des Scripts arbeitet dann mit diesem Pfad weiter. Dazu wird eine weitgehend aus Smarty abgeleitete Controller-Klasse benutzt, die ein Template-Objekt erzeugt und mit Variablen befüllt; wo erforderlich, steht eine spezialisierte Datenbank-Klasse bereit, die spezifische Funktionen für alle erforderlichen Lese- und Schreib-Operationen bereithält. Für das Session-Management konnte ich auf eine bestehende PHP-Klasse aus dem Jahre 2011 zurückgreifen, die ich damals für ein anderes Projekt geschrieben und bewusst modular aufgebaut hatte; tatsächlich war sie 10 Jahre später mit kleinen Anpassungen - vor allem in bisher nicht oder kaum genutzten Codepfaden - sofort verwendbar. Auth- und Controller-Klasse lassen sich modular wiederverwenden, die Datenbank-Klasse ist weitgehend projektspezifisch.

Den Hauptteil der index.php bildet dann tatsächlich ein langes switch-Statement, das für bestimmte Seiten spezifischen (Datenbank-)Code enthält, in den meisten Fällen aber auf default zurückfallen und schlicht eine Markdown-Datei in HTML konvertieren, in ein Template einsetzen und dann anzeigen kann.

Verzeichnisstruktur

Die Verzeichnisstruktur des Projekts sieht im Grundsatz so aus:

\___ source/
 \
  \__ data/
   \
    \__ web/

Das web-Verzeichnis ist das Webroot; dort finden sich die index.php, die Unterverzeichniss mit CSS, Javascript, Webfonts, Bildern und Icons und die Downloadverzeichnisse, also alles, was “as is” ausgeliefert werden soll.

In source liegen die Module und externen Elemente: Smarty, PHP Markdown Extra, meine eigenen Module und eine Konfigurationsdatei, die etliche Variablen setzt (bspw. für die Datenbankanbindung) und zugleich alle notwendigen Elemente einbindet.

data schließlich enthält zum einen die Templates (also die typischen Smarty-Verzeichnisse wie templates, templates_c, cache und Co.) und zum anderen im Verzeichnis content die eigentlichen Inhalte in Form von Markdown-Dateien in einer Verzeichnisstruktur, die der der Webseite entspricht. Der Inhalt, der nach Aufruf von https://meine-website.example/about/contact/ angezeigt werden soll, liegt also in data/content/about/contact.md.

Umsetzungsbeispiele

$controller = new Controller($config);
$controller->assign('page',$page);

Auf diese Weise wird ein neues Controller-Element erzeugt, dass den Inhalt des Arrays $config (aus der zentralen Konfigurationsdatei) und die anzuzeigende Seite ($page) in Smarty verfügbar macht. Die assign-Methode akzeptiert entweder ein Array oder - wie im Beispiel - ein Tupel aus Schlüssel und Wert.

# create pages from Markdown/YAML
$yaml = $controller->create_from_md($page);

Diese Funktion liest eine Datei ein, konvertiert das enthaltene Markdown in HTML und kann YAML front matter verarbeiten, also YAML, das als Vorspann (eingefasst in ---) in einer anderen Datei enthalten ist. Diese Inhalt werden in Smarty als Variablen bereitgestellt.

Die technische Umsetzung der Funktion create_from_md() ist im Kern wirklich einfach:

# parse YAML and copy to Smarty
$yaml = yaml_parse_file($content_file);
$this->template->assign($yaml);

# parse Markdown, ignoring YAML front matter, and assign to content
$this->template->assign('content',Michelf\MarkdownExtra::defaultTransform($this->read_ignore_frontmatter($content_file)));

# return YAML metadate
return $yaml;

Die PHP-Funktion yaml_parse_file() kann YAML front matter verarbeiten und ignoriert den Rest. Die selbstgeschriebene Funktion read_ignore_frontmatter() ist das Gegenstück dazu; sie sorgt dafür, dass beim erneuten Einlesen der Datei diesmal das YAML front matter übersprungen und nur der Markdown-Teil verarbeitet wird. Danach werden die eingelesenen YAML-Daten zurückgegeben und stehen daher nicht nur im Smarty-Template, sondern auch für den PHP-Code zur Verfügung.

Auf diese Weise können beispielsweise Titel und Beschreibung der Seite, der Autor usw. übergeben werden. Für die (wenigen) Seiten, die nicht nur aus Markdown bestehen, sondern weitergehende Funktionalität enthalten, werden diese Daten als Array in der index.php definiert. Jede Webseite besteht also entweder aus einem speziellen Smarty-Template mit zusätzlichem Code in der index.php oder aus dem Inhalt einer Markdown-Datei, die in das Default-Template eingesetzt wird.

# check for protected pages
if(isset($yaml['login'])) $auth->check_session();

Wenn im YAML-Vorspann login gesetzt ist, wird geprüft, ob ein berechtigter Benutzer eingeloggt ist; ansonsten erfolgt die Umleitung zur Anmeldeseite.

# display template
$controller->display('index.tpl');

Am Schluss wird das mit Inhalt gefüllte Template angezeigt.

Ein paar Worte zum Schluss

Das Konzept stand natürlich nicht von Anfang an in der hier präsentierten Form, sondern ist dynamisch gewachsen - so gab es zunächst nur Smarty-Templates, dann kam die Möglichkeit von Markdown-Dateien hinzu, und noch später das Parsing von YAML front matter. Und natürlich waren viele Tests und etliche Iterationen über einige Abende und ein langes Wochenende notwendig - aber am Ende war ich überrascht, erfreut und beeindruckt, mit wie vergleichsweise geringem Aufwand sich ein solches doch (für meine Verhältnisse) einigermaßen komplexes Projekt umsetzen lässt. Frei verfügbare externe Projekte und Frameworks - Smarty, PHP Markdown, Bootstrap, SASS und natürlich am Ende auch PHP selbst -, eigene kleine Module und ein bißchen Klebstoff, um das alles miteinander zu verbinden, dazu ein altes Design zum Aufhübschen und die bestehenden Inhalte, die ergänzt und übernommen werden, sind eine ebenso mächtige wie vielseitige Kombination.

[Nachträglich veröffentlicht im August 2021.]

Titelbild © pripir - stock.adobe.com

Webserver-Tuning

nospam@example.com (Thomas Hochstein) — Tue, 22 Aug 2017 05:40:00 +0000

Alle paar Monate wieder turnt ein - weniger rücksichtsvoller - Crawler vorbei und spidert sich zügig durch alle Einträge meines Blogs. Damit brachte er meinen bisherigen Server gerne an den Rand seiner Leistungsfähigkeit, durfte dieser doch für jeden Link einen php-cgi-Prozess starten. Man merkte das recht schnell an den steigenden Antwortzeiten, und auch interaktiv auf der Shell machte sich die steigende load bemerkbar. Am Ende blieben meist einige php-cgi-Prozesse übrig, die man dann manuell mittels kill entsorgen durfte. (Vielleicht lag auch hier das eigentliche Problem, dass nämlich die genutzten Ressourcen nicht wieder freigegeben wurden. Hinter die Einzelheiten bin ich nie so recht gekommen.)

Die brandneue Maschine hingegen sollte durch FastCGI und massenhaft RAM sowie schnelle SSDs einem solchen Ansturm (auch bei weiterer Verwendung des doch eher schwergewichtigen Apachen) besser gewachsen sein - dachte ich mir. Bis eines Freitagmorgens die E-Mails des Monitoring-System eingingen, die mir mitteilten, dass der Webserver nicht mehr auf Anfragen reagiert. Gar nicht mehr.

Der Grund dafür fand sich schnell im Log:

[mpm_event:error] [pid 1365:tid 139856442496192] AH00484: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting

Alle Threads des Webservers waren mit Anfragen ausgelastet (und offensichtlich wurden sie auch nicht mehr freigegeben - oder der Apache hatte sich “verschluckt”). Ein service apache2 restart löste daher das Problem; Zeit aber für einen Blick in die Konfiguration - vielleicht sollte man etwas an den Limits drehen (“consider raising the MaxRequestWorkers setting “).

Apache Event-MPM

Für das verwendete MPM findet sich die entsprechende Konfiguration (unter Debian) in /etc/apache2/mods-enabled/mpm_event.conf; sie sieht per default so aus:

# event MPM
# StartServers: initial number of server processes to start
# MinSpareThreads: minimum number of worker threads which are kept spare
# MaxSpareThreads: maximum number of worker threads which are kept spare
# ThreadsPerChild: constant number of worker threads in each server process
# MaxRequestWorkers: maximum number of worker threads
# MaxConnectionsPerChild: maximum number of requests a server process serves
<IfModule mpm_event_module>
       StartServers              2
       MinSpareThreads          25
       MaxSpareThreads          75
       ThreadLimit              64
       ThreadsPerChild          25
       MaxRequestWorkers       150
       MaxConnectionsPerChild    0
</IfModule>

Es werden also standardmäßig zwei Serverprozesse (StartServers)gestartet; jeder hat 25 Threads (ThreadsPerChild), also können 50 parallele Anfragen abgearbeitet werden. Sobald weniger als 25 freie Threads zur Verfügung stehen (MinSpareThreads), werden weitere Serverprozesse gestartet, bis zum Maximum von 150 Threads (MaxRequestWorkers) - das entspricht sechs Prozessen (mit je 25 Threads). Sobald mehr als 75 Threads unbeschäftigt sind (MaxSpareThreads), werden Serverprozesse wieder zurückgefahren.

150 Prozesse für eine Vielzahl von Webpräsenzen erschien mir wirklich nicht viel; ich habe (angesichts des zur Verfügung stehenden Speichers) daher etwas nachgelegt:

<IfModule mpm_event_module>
        ServerLimit               40
        StartServers               5
        MinSpareThreads          100
        MaxSpareThreads          250
        ThreadLimit               64     
        ThreadsPerChild           25
        MaxRequestWorkers       1000
        MaxConnectionsPerChild  1000
</IfModule>

Wir fangen jetzt also mit mit 125 Threads an (fünf Server mit je 25 Threads) und halten minimal 100 Threads bereit, maximal 250 - eine Lastspitze kann daher besser abgefedert werden, weil von Anfang an mehr Ressourcen bereitstehen und schneller zusätzliche Ressourcen hochgefahren werden). Maximal können dann 1.000 Threads laufen (statt vorher 150) - zu diesem Zweck muss auch ServerLimit erhöht werden, das per Default auf 16 steht - denn 1.000 Threads brauchen bei 25 Threads pro Prozess 40 Prozesse (mit dem Default von 16 Prozessen kommt man daher maximal auf 400 Threads).

Außerdem lasse icn jeden Thread nach 1.000 beantworteten Anfragen neu starten (MaxConnectionsPerChild); so können sich Speicherlecks nicht zu Problemen auswachsen.

Seitdem war der Webserver jedenfalls nicht mehr komplett ausgelastet; schauen wir mal, ob das schon der richtige Mittelweg zwischen der Bereitstellung ausreichender Ressourcen und dem Schutz des Gesamtsystems vor Überlast war oder mir als nächstes die ganze Maschine in die Knie geht, wenn es mal richtig rundgeht …

FPM-Konfiguration

Für Webapplikationen in PHP ist die Apache-Konfiguration nicht das einzige limitierende Element - vielmehr muss jede Anfrage auch von einem FastCGI-Prozess beantwortet werden, und auch die sind limitiert: per Default (bei Debian) auf 50 pro Pool, konfiguriert (unter Strech) in /etc/php/7.0/fpm/pool.d/www.conf, wobei statt www.conf eben der jeweilige Pool einzusetzen ist.

Das erscheint mir ebenfalls nicht besonders viel; ich habe daher den Pool für mein Blog etwas nach oben angepasst:

pm.max_children = 250
pm.start_servers = 30
pm.min_spare_servers = 10
pm.max_spare_servers = 50

Zu lesen ist das ähnlich wie oben beim Apachen: 30 Prozesse stehen von Anfang an zur Verfügung, 10 müssen mindestens immer arbeitslos sein, sonst werden Prozesse nachgelegt, bis zur Maximalzahl von 250. Ab 50 “arbeitslosen” Prozessen werden überzählige Prozesse gestoppt.

Erfahrungswerte

Ich habe bisher, muss ich gestehen, nicht die geringste Erfahrung mit solchen “Tuning-Aufgaben”, und werde daher abwarten müssen, ob sich die Werte bewähren. Aus dem Log kann ich jedenfalls sehen, dass 50 Prozesse viel zu wenig waren und auch 150 mehrfach nicht ausreichten:

WARNING: [pool blog] server reached pm.max_children setting (150), consider raising it

Andererseits habe ich bisher zumindest aus Munin - das allerdings nicht sehr fein auflöst - keine Hinweise für Lastspitzen (CPU-Nutzung, RAM-Nutzung und Load); da scheint im Tagesverlauf überall noch viel, viel Luft nach oben zu sein.

Hat jemand aus der werten Leserschaft Erfahrungen und Tips, die er gerne teilen möchte? Sonst berichte ich, wenn das nächste Mal etwas danebengeht.

PHP-FPM - jetzt mit mod_proxy_fcgi

nospam@example.com (Thomas Hochstein) — Tue, 26 Apr 2016 05:50:00 +0000

Vergangene Woche hatte ich darüber berichtet, wie man - unter Debian Jessie - PHP-FPM mit mod_fastcgi installieren kann. In den Kommentaren hatte Sven mir dann nachfolgend erläutert, wie sich die Einbindung einfacher und besser über mod_proxy_fcgi lösen lässt, vorausgesetzt, man hat (wie in Debian Jessie) einen Apache 2.4 vor sich.

Da mir das ebenfalls vorzugswürdig erscheint, beschreiben ich in der Folge nunmehr diese Variante.

PHP-FPM und `mod_proxy_fcgi` installieren

Unter Debian Jessie ist die Installation der Pakete hinreichend einfach:

apt-get install php5-fpm php5

Debian hinterlegt dabei die php.ini für die FastCGI-Prozesse unter /etc/php5/fpm/php.ini und die Konfiguration für FPM unter /etc/php5/fpm/php-fpm.conf, ergänzt u.a. um die Konfiguration installierter Module in /etc/php5/fpm/conf.d/, wie man das so kennt.

Im Verzeichnis /etc/php5/fpm/pool.d/ sind dann die einzelnen Pools definiert, die ebenfalls in die /etc/php5/fpm/php-fpm.conf inkludiert werden, standardmäßig nur der Pool des Benutzers www-data, unter dem der Webserver läuft.

`mod_proxy_fcgi` für PHP-FPM konfigurieren

Serverweit lässt sich PHP-FPM dann wie folgt in einer neuen Datei /etc/apache2/conf-available/php5-fpm.conf konfigurieren:

<IfModule mod_proxy_fcgi.c>
    <Proxy "unix:/var/run/php5-fpm.sock|fcgi://php-fpm">
        # we must declare a (any) parameter in here 
        # or it won't register the proxy ahead of time
        ProxySet disablereuse=off
    </Proxy>
    <FilesMatch ".+\.php$">
        SetHandler proxy:fcgi://php-fpm
    </FilesMatch>
</IfModule>

Auf diese Weise werden auf .php endende Dateien an den darüber definierten Prxoy durchgereicht. Wer will, kann stattdessen bspw. auch <FilesMatch ".+\.ph(p[345]?|t|tml)$"> verwenden, wie Sven das empfohlen hat; das deckt auch alle anderen gebräuchlichen Endungen für PHP-Scripts ab.

Standardmäßig sorgt Debian übrigens dafür, dass das - mitinstallierte - Modul mod_proxy nicht als forward proxy arbeitet; das ist in der Datei /etc/apache2/mods-available/proxy.conf konfiguriert und stellt also kein Problem dar.

Nach Aktivieren des Moduls und der Konfiguration vermittels a2enmod proxy_fcgi und a2enconf php5-fpm sowie einem Restart des Webservers (service apache2 restart) sollte PHP nun zur Verfügung stehen.

Pools für einzelne Benutzer einrichten

Um nun verschiedene Pools für verschiedene Benutzer einzurichten, bedarf es neben einer passenden Konfiguration des jeweiligen Pools in /etc/php5/fpm/pool.d/ und eines geänderten Aufrufs in jedem virtual host, der diesem Benutzer zugeordnet ist.

Am einfachsten kopiert man sich die bestehende Konfiguration für den Pool www und wandelt sie ab:

cd /etc/php5/fpm/pool.d
cp www.conf user1.conf
vim user1.conf

Folgende Teile der Konfiguration müssen ersetzt werden: der Name des Pools, user, group und listen:

; Start a new pool named 'user1'.
; the variable $pool can we used in any directive and will be replaced by the
; pool name ('user1' here)
[user1]

[...]

user = user1
group = users

[...]

listen = /var/run/php5-fpm-user1.sock

Selbstverständlich können auch andere, für diesen Pool spezifische Änderungen vorgenommen werden

Und danach bekommt der bspw. in /etc/apache2/sites-available/user1-domain.example konfigurierte virtual host noch folgende Ergänzung (zwischen <VirtualHost ...> und </VirtualHost>):

<IfModule mod_proxy_fcgi.c>
    <Proxy "unix:/var/run/php5-fpm-user1.sock|fcgi://php-fpm-user1">
        # we must declare a (any) parameter in here 
        # or it won't register the proxy ahead of time
        ProxySet disablereuse=off
    </Proxy>
    <FilesMatch ".+\.php$">
        SetHandler proxy:fcgi://php-fpm-user1
    </FilesMatch>
</IfModule>

In diesem virtual host kommuniziert der Apache also nicht mit dem FastCGI-Server über /var/run/php5-fpm.sock, sondern über /var/run/php5-fpm-user1.sock, und den haben wir ja anders konfiguriert. Ein service apache2 restart bzw. service php5-fpm restart später sollte die geänderte Konfiguration zur Verfügung stehen.

Soll PHP in mehreren virtual hosts unter derselben Benutzerkennung laufen, empfiehlt es sich, die o.g. Konfiguration in eine eigene Datei (bspw. /etc/apache2/sites-available/user1.fcgi) auszulagern und diese Datei dann in die virtual host-Konfiguration einzubinden:

Include /etc/apache2/sites-available/user1.fcg

Das spart nicht nur Tipparbeit, sondern erleichtert auch spätere Änderungen sehr.

Die Installation testen

Am einfachsten gestaltet sich der Test, wenn man im Webroot des Servers (Debian Jessie: /var/www/html/) und der einzelnen virtual hosts jeweils eine Datei test.php speichert, die nur phpinfo() aufruft:

<?php phpinfo(); ?>

In der Ausgabe von phpinfo() wird angezeigt, unter welchem Benutzer das Script ausgeführt wird.

Vielen Dank an Sven für den hilfreichen Tip!

PHP-FPM mit Debian Jessie

nospam@example.com (Thomas Hochstein) — Mon, 18 Apr 2016 06:45:00 +0000

Statische Webseiten sind nett (und durchaus wieder im Kommen), aber zumindest für manche Zwecke sind dynamisch generierte Seiten und die auf diese Weise ermöglichte Interaktivität doch dann besser oder gar notwendig. Facebook, bspw., würde sich als statische Seite dann doch eher schwierig gestalten.

Die Welt dynamischer Webseiten

Scriptsprachen

Dynamisch generierte Seiten bedingen, dass beim Aufruf einer Webseite nicht nur eine auf dem Server abgelegte Datei angezeigt wird, sondern dass ein Programm dort läuft, das die Ausgabe mehr oder weniger live generiert. Das hat ganz andere Implikationen für die Sicherheit des Servers, denn nunmehr läuft dort von außen erreichbarer Code, der schlimmstenfalls noch durch die Nutzer selbst aufgespielt werden kann. Nicht jeder, der seine ersten Gehversuche mit Scripts macht, hat dabei auch Fragen der IT-Sicherheit ausreichend im Blick - um das Problem einmal stark verharmlosend zu beschreiben. Gerade PHP hat nicht den Ruf, zumindest in den ersten Jahren seiner Entwicklung großes Gewicht auf das Fördern oder gar Erzwingen sicherer Praktiken gelegt zu haben, und viele lern(t)en es vor allem als eine Art Templating-Sprache kennen, die man irgendwie in seine HTML-Seiten einbettet, um ihnen damit eine erweiterte Funktionalität zu verleihen, ohne dabei groß an Konsequenzen zu denken (schuldig, euer Ehren!).

Rechteprobleme

Besondere Schwierigkeiten kommen hinzu, wenn mehr als ein Benutzer auf dem Server Scripts nutzen will. Denn wenn der Webserver bzw. der von diesem gestartete Interpreter das Script ausführen will, muss er es lesen können. Dann muss er aber - logischerweise - auch die Scripts aller anderen nutzer lesen können, was bedeutet, dass Nutzer A ein Sript schreiben kann, mit dem er sich die Scripts von Benutzer B anzeigen lassen kann, samt aller dort gespeicherten Informationen (Datenbankpassworte usw.), ebenso wie Dateien, die Benutzer B anlegt. Und wenn das Script irgendwelche Dateien anlegt (man denke an hochgeladene Bilder), dann werden diese Dateien unter der Nutzerkennung des Webservers angelegt, so dass der Benutzer dann keinen vollen Zugriff darauf hat. Das ist alles etwas unschön, weshalb man schon bald die Möglichkeit geschaffen hat, Scripts (sei es Perl, sei es Python, sei es PHP) unter der Benutzerkennung des jeweiligen Nutzers laufen zu lassen, dem das Script “gehört”.

suexec und suphp

Das schafft zwar andere Probleme, insbesondere im Bereich der Performance, denn nun kann ein Webserverprozess nicht mehr beliebig viele Scripts in parallelen Threads abarbeiten, weil diese ja vielleicht verschiedenen Nutzern gehören, so dass für jedes Script ein neuer Interpreter-Prozess gestartet werden muss, aber es ist doch in der Regel vorzugswürdig.

Für Scripts, die über die CGI-Schnittstelle (ja, ich weiß, das “I” steht schon für “Interface”) gestartet werden, stellt suexec die entsprechende Funktionalität bereit. Für PHP tat das traditionell suphp. suphp gibt es aber in Debian Jessie nicht mehr. Was also tun?

Als Lösung bietet sich PHP-FPM an.

PHP-FPM

FPM steht dabei für FastCGI Process Manager und ist eine sehr angenehme Lösung, um PHP als FastCGI einzubinden. FastCGI ist ein Mittelding zwischen der Einbindung per mod_php, also als Modul im Webserver, und als CGI, so dass für jeden Aufruf eines PHP-Scripts ein eigener Prozess gestartet werden muss: es werden einige FastCGI-Prozesse gestartet, die in einem Pool vorgehalten werden, und wenn ein PHP-Script aufgerufen wird, wird der Aufruf vom Webserver an den schon laufenden Prozess weitergereicht. Das erspart den sonst für jeden Aufruf notwendigen Start des Interpreters - und es bietet die Möglichkeit, pro Pool festzulegen, unter welcher Benutzerkennung die Prozesse dieses Pools laufen sollen.

Hinweis: Der folgende Vorschlag ist nicht der einzige Weg, PHP-FPM zu installieren. Eine bessere Lösung unter Verwendung von mod_proxy_fcgi, auf die ich in den Kommentaren hingewiesen wurde, habe ich mittlerweile auch beschrieben. Dieser andere Weg setzt Apache 2.4.x voraus, benötigt aber kein Paket aus dem nicht-freien Debian-Repository. Insgesamt erscheint mir dieser andere Weg vorzugswürdig.

PHP-FPM installieren

Unter Debian Jessie ist die Installation der Pakete hinreichend einfach:

apt-get install libapache2-mod-fastcgi php5-fpm php5

libapache2-mod-fastcgi kommt hier aus dem non-free-Repository, das dementsprechend eingebunden sein muss.

FastCGI für PHP-FPM konfigurieren

Wenn man möchte, kann man die bestehende Konfigurationsdatei sichern:

cp /etc/apache2/mods-available/fastcgi.conf /etc/apache2/mods-available/fastcgi.conf.backup

und danach sie danach mittels vim /etc/apache2/mods-available/fastcgi.conf neu befüllen wie folgt:

<IfModule mod_fastcgi.c>
    AddType application/x-httpd-fastphp5 .php
    Action application/x-httpd-fastphp5 /php5-fcgi
    Alias /php5-fcgi /usr/lib/cgi-bin/php5-fcgi
    FastCgiExternalServer /usr/lib/cgi-bin/php5-fcgi -socket /var/run/php5-fpm.sock -pass-header Authorization
    <Directory /usr/lib/cgi-bin>
        Require all granted
    </Directory>
</IfModule>

Auf diese Weise bekommen auf .php endende Dateien den Typ x-httpd-fastphp5 zugewiesen, der über den Handler /php5-fcgi aufgerufen wird, der wiederum auf /usr/lib/cgi-bin/php5-fcgi zeigt, was aber ebenfalls nicht existiert, so dass Apache stattdessen alles dem externen FastCGI-Server zuwirft, der über den Socket /var/run/php5-fpm.sock kommuniziert.

Nach Aktivieren der notwendigen Module mittels a2enmod fastcgi actions alias und einem Restart des Webservers (service apache2 restart) sollte PHP zur Verfügung stehen.

Pools für einzelne Benutzer einrichten

Am einfachsten kopiert man sich die bestehende Konfiguration für den Pool www und wandelt sie ab:

cd /etc/php5/fpm/pool.d
cp www.conf user1.conf
vim user1.conf

Folgende Teile der Konfiguration müssen ersetzt werden: der Name des Pools, user, group und listen:

; Start a new pool named 'user1'.
; the variable $pool can we used in any directive and will be replaced by the
; pool name ('user1' here)
[user1]

[...]

user = user1
group = users

[...]

listen = /var/run/php5-fpm-user1.sock

Selbstverständlich können auch andere, für diesen Pool spezifische Änderungen vorgenommen werden

Und danach bekommt der bspw. in /etc/apache2/sites-available/user1-domain.example konfigurierte virtual host noch folgende Ergänzung (zwischen <VirtualHost ...> und </VirtualHost>):

<IfModule mod_fastcgi.c>
    AddType application/x-httpd-fastphp5 .php
    Action application/x-httpd-fastphp5 /php5-fcgi
    Alias /php5-fcgi /usr/lib/cgi-bin/php5-fcgi-user1
    FastCgiExternalServer /usr/lib/cgi-bin/php5-fcgi-user1 -socket /var/run/php5-fpm-user1.sock -pass-header Authorization
</IfModule>

Include /etc/apache2/sites-available/user1.fcg

Das spart nicht nur Tipparbeit, sondern erleichtert auch spätere Änderungen sehr.

Wichtig: Der Eintrag FastCgiExternalServer darf dabei nur einmal erfolgen, also nicht pro vhost wiederholt werden.

Die Installation testen

<?php phpinfo(); ?>

In der Ausgabe von phpinfo() wird angezeigt, unter welchem Benutzer das Script ausgeführt wird.

Weiterer Lesestoff

Alex Fornuto bei linode: Install PHP-FPM and Apache on Debian 8 (Jessie)
Apache httpd Wiki: High-performance PHP on apache httpd 2.4.x using mod_proxy_fcgi and php-fpm

Digitale Ausstellungsstücke

nospam@example.com (Thomas Hochstein) — Mon, 10 Jan 2011 18:28:00 +0000

Wer (digitale) Fotos - in welcher Menge, Häufigkeit und Qualität auch immer - macht, der kennt das Problem, sie online verfügbar zu machen. Gut, das eigentliche Problem ist die Überwindung der eigenen Faulheit und das Auswählen, Sortieren, Umbenennen und ggf. Kommentieren einmal wirklich anzugehen, aber man möchte dazu auch die entsprechende, möglichst einfach verwendbare, aber alle notwendigen Funktionen bietende Software haben.

Man kann dazu Web-2.0-Dienste wie flickr nutzen, aber nicht jeder möchte das, sei es, daß man solchen Diensten generell nicht traut und/oder die Software lieber selbst installieren möchte, sei es, daß man am "Sharing" von Fotos gar nicht interessiert ist, sondern den Zugriff potentiell nur wenigen ermöglichen möchte. Insoweit habe ich dann schon einiges durch: mehr schlecht als recht selbst gebaute Implementationen für die Webseiten meiner Hilfsorganisation oder einer Newsgroup (seit ~ 2002), dann für meine private Homepage (ebenfalls seit ~ 2002) mig, ein sehr einfaches Script (auch deshalb, weil man von den Platzhirschen wie Gallery nicht viel Gutes über die Sicherheit hörte), und seit Anfang 2008 (nach dem Erhalt meiner neuen Kamera Weihnachten 2007) auch eine Gallery-2-Instanz, mit der ich allerdings nie so recht angefreundet hatte (zumal bis zu einem Kurzurlaub 2008 zurück noch Bilder zum Sortieren und Hochladen im Backlog liegen - siehe die einleitenden Worte zu diesem Artikel ). Während ich jetzt darüber nachdachte, ob sich nicht ein Update auf Gallery 3 anbietet, bekam ich den weisen Rat, mir doch einmal piwigo anzusehen.

Und das hat mich überzeugt. Zumindest dann, wenn man eine Fotogalerie-Applikation nur für sich selbst ohne ausgefeiltes Benutzermanagement für mehrere Fotografen braucht (und wie oft teilt man sich eine Galerie wirklich zu mehreren?), ist piwigo eine tolle Lösung. Installation und Konfiguration sind einfach (Voraussetzungen: PHP und mySQL), wenn man das Prinzip einmal begriffen hat, der Upload ist übers Web wie auch einfach per FTP möglich, Thumbnails werden erstellt, Benutzer können in vorgegebene Rechtegruppen (Gast, Bekannter, Freund, Familie, …) oder in Nutzergruppen eingeteilt werden, und für Alben bzw. Fotos lassen sich dann die entsprechenden Zugriffsrechte setzen. Fotos lassen sich nicht nur in Alben, sondern in Kategorien zusammenfassen und zugleich noch beliebig taggen; der Benutzer kann sich die Fotos nach Kategorien oder Tags oder nach dem Kalender oder sonstwie anzeigen lassen, bekommt dabei aber immer nur die Fotos oder Kategorien zu sehen, für die er entsprechende Rechte hat. Außerdem gibt es eine Reihe vorgefertigter, recht ansehnlicher Skins.

Mir gefällt’s jedenfalls, und ich habe den heutigen Tag dann im wesentlichen dazu genutzt, aus den drei oder vier vorgenannten Quellen der letzten 10 Jahre die dort vorhandenen Fotos in einer Galerie zusammenzuführen und dann den Rest zu löschen. So gesehen also wie gestern ein weiterer Tag des Räumens und Sortierens.

Mantis Bug Tracker und Mantis Graphs 1.0

nospam@example.com (Thomas Hochstein) — Fri, 14 May 2010 16:14:00 +0000

Mantis (aktuell in der Version 1.2.1) ist ein ganz netter Bugtracker, also ein Ticketsystem (Fallbearbeitungssystem) für die Softwareentwicklung, dessen auffallendstes Manko allerdings die unterirdische Qualität der Dokumentation (weitgehend schlicht nicht vorhanden, ansonsten grob unvollständig oder weit veraltet) ist. *seufz*

"Mantis Graphs 1.0" ist ein Plugin für Mantis, das graphische Darstellungen ermöglicht, und ich habe heute längere Zeit damit verbracht, es in Betrieb zu setzen, nachdem es immer nur "unable to read/find font" von sich geben wollte. Einer der ersten Schritte war die Installation der msttcorefonts (aptitude install ttf-mscorefonts-installer), aber das genügte nicht. Längeres Debugging mit eingestreuten Statements im Quellcode ergab schließlich, daß Mantis weder das passende Font-Verzeichnis erkennen noch - bei expliziter Angabe des Verzeichnisses in der Konfiguration mit $g_system_font_folder - die Fontdatei laden wollte. Die Lösung dafür fand sich in der Dokumentation der PHP-Funktion file_exists(): diese liefert auch dann false zurück, wenn auf die entsprechende Datei aufgrund von safe_mode-Restriktionen nicht zugegriffen werden kann …

Und natürlich ist das der Fall: das Font-Verzeichnis - bpw. /usr/share/fonts/truetype/msttcorefonts/ - gehört root, und die Font-Dateien auch. Jedenfalls ist Owner dieser Dateien niemals der Webserver oder der Benutzer, unter dessen Kennung die PHP-Scripts dank su_php o.ä. ausgeführt werden. *brummel*

Es bleibt demnach nur der Verzicht auf die Grafiken oder die Deaktivierung von safe_mode (für Mantis).

Apache 2.x, php-cgi, mod_suphp und "No input file specified!"

nospam@example.com (Thomas Hochstein) — Fri, 17 Apr 2009 15:03:00 +0000

Im Zusammenhang mit dem Update einer Maschine auf Debian Lenny bin ich auf das seltsame Phänomen einer - offensichtlich von PHP erzeugten - Fehlermedlung gestoßen: der Aufruf einer bestimmten Webseite (respektive des PHP-Scripts, das diese erzeugen sollte) ergibt nur die Meldung "No input file specified!". Google führt einen zu diversen Threads, die sich vor allem um die Konfiguration des richtigen Handlers für die Interpretation von PHP-Scripts und um hilflose Fragen von Benutzern, die eigentlich nur ein fertiges Paket installieren wollten und nun nicht mehr weiter wissen, drehen. Erst ein alter Blogeintrag in ixs’ Vodkamelone (nein, das hat nichts mit einem Kamel Nr. Eins zu tun!) von 2005 half mir auf die Sprünge.

Der Grund dieser Fehlermeldung ist offenbar ein ganz seltsames Zusammenspiel der Ausführung von PHP als mod_suphp, d.h. der CGI-Version von PHP in der Weise, daß Scripts unter den Rechten des jeweiligen Benutzers ausgeführt werden, mit der Vergabe von Datei- und Verzeichnisrechten. Die oben genannten Fehlermeldung tritt demnach genau dann auf, wenn zwar der Webserver auf die Datei bzw. ihr Verzeichnis zugreifen, sie also "finden" kann, der Benutzer selbst aber nicht. Dann findet der Webserver - unter der UID www-data - das Script, erkennt es, ruft den Handler auf, der als suid root installiert ist, sich Root-Rechte verschafft, damit auf die UID des Benutzers wechselt und dann mit diesen Rechten den PHP-Interpreter aufruft, um ihn das Script ausführen zu lassen. Dieser PHP-Prozess, der jetzt aber im Kontext des Benutzers läuft, kann dann selbst auf das entsprechende Verzeichnis nicht mehr zugreifen, das Script also auch nicht ausführen, und reagiert dann mit der obigen Fehlermeldung, denn er findet ja keine Datei, die er ausführen könnte.

Vielleicht hilfts ja jemanden, wenn ich ixs’ Analyse her noch einmal wiedergebe und verlinke.

Netz - Rettung - Recht (Artikel mit Tag PHP)

Validierung von Eingaben im Kontaktformular

Naives MVC

Bootstrap 5 und SASS

Templates

Model-View-Controller

Verzeichnisstruktur

Umsetzungsbeispiele

Ein paar Worte zum Schluss

Webserver-Tuning

Apache Event-MPM

FPM-Konfiguration

Erfahrungswerte

PHP-FPM - jetzt mit mod_proxy_fcgi

PHP-FPM und mod_proxy_fcgi installieren

mod_proxy_fcgi für PHP-FPM konfigurieren

Pools für einzelne Benutzer einrichten

Die Installation testen

PHP-FPM mit Debian Jessie

Die Welt dynamischer Webseiten

Scriptsprachen

Rechteprobleme

suexec und suphp

PHP-FPM

PHP-FPM installieren

FastCGI für PHP-FPM konfigurieren

Pools für einzelne Benutzer einrichten

Die Installation testen

Weiterer Lesestoff

Digitale Ausstellungsstücke

Mantis Bug Tracker und Mantis Graphs 1.0

Apache 2.x, php-cgi, mod_suphp und "No input file specified!"

PHP-FPM und `mod_proxy_fcgi` installieren

`mod_proxy_fcgi` für PHP-FPM konfigurieren