So viele neue Posts, gar nicht mehr gewohnt!
apache läuft nach dessen Installation auf der CPU, das habe ich schon angenommen.
Den kann ich auch starten/stoppen/restarten.
- Läuft php auch nach der Installation oder nur wenn das durch z.B. apache getriggert wird?
- Durchsucht apache/php automatisch alle weiteren Unterordner von /var/www/html/ (oder anderen VHosts) nach index.html oder *.php?
- Oder benötigt es immer (auch im Hauptordner) erst einen Aufruf der Seite von extern (z.B. einem Webbrowser auf 123MeineAdresse.myfritz.net/Unterordner/example.php)?
PHP mit Apache's mod_php läuft innnerhalb des Apache Prozesses, also immer wenn Apache läuft, die *CGI oder auch "ReverseProxy" Alternativen haben mindestens einen Main-Prozess (der die Arbeit verteilt, wie im echten Leben) und Childs, die dann wirklich arbeiten.
Das macht Apache übrigens auch, wenn du dir `ps -ef`anschaust. Die Daemons leben quasi (oder nur oft!) vom "
forken"
In jedem Fall muss Apache wissen, was es mit *.php Files machen soll. mod_php übernimmt das eingeständig. Bei Proxies kommt meist ein RegEx o.ä. zum Einsatz (Hier Beispiele:
https://httpd.apache.org/docs/2.4/mod/mod_proxy_fcgi.html )
Du musst einen Aufruf auf Apache auch so verstehen: Apache bekommt URL + Header + Body und "reagiert darauf". Es kann bspw. die URL interpretieren und davon ableiten, "etwas zu tun".
Beispielsweise:
- Ist die URL blabla.com/irgendwas/einfile.trouble => blabla.com:80 (Der Browser added den Port, also es gibt immer einen Port)
- => VirtualHost "X"
- => X hat einen Alias für "/irgendwas" auf "/var/troublesome"
- => Außerdem einen Directory Eintrag auf "/var/troublesome" (denn jetzt ist das der neue Pfad, denn der Alias hat Vorrang!) mit "Require all granted" (Ich schrieb dies nachdem ich Require wiederentdeckt hatte, siehe viiieeel weiter unten!)
- => Nun ist der Default nach einer Datei dort zu gucken, aber vielleicht wird *.trouble durch eine Regel (oder ein mod_*? Vielleicht mod_troublesomeinterpreter?
) zu einer anderen Aktion aufgerufen, als die Datei auszuliefern. Bspw. ein Interpreter, oder wir geben einfach nur "einfile" als Inhalt zurück, weil eine Regeln sagt, gib den Inhalt zurück und ignoriere, ob es diese Datei überhaupt gibt
- oder oder oder.
Sehr gerne mehr Details!
Challenge accepted!
Die Separation of Concerns (ich nenns später SoCo. Keiner macht das, aber ich bin faul und schreib lieber
10 100 255 Wörter Erklärung, als nur einmal mehr "Separation of Concer...VERDAMMT!) ist der Grund für viele Splits in der IT. Wir haben die Server vom Client gesplittet, die Serverprozesse untereinander, damit wir mehrere Server haben können, das Frontend vom Backend, die vielen Frontends und Backends miteinander von anderen Frontends und Backends (SCS) und dann die Backends untereinander vom Frontend (Microservice). Und dann kamen wir auf die Idee, die Infrastruktur auszulagern (IaaS) und letzten Endes ganz weg zu lassen (Serverless).
Also: Wir entkoppeln so weit wir müssen. Für den einfachen Anwendungsfall eines Homemade Webservers entkoppeln wir gar nichts, denn wir brauchen das nicht: "Apache Module "mod_php"". Aber wenn es an's eingemachte geht, dann entkoppeln wir, was das Zeug hält. Denn je größer der Workload, desto relevanter wird es, die Einzelteile nur einzeln zu skalieren.
Jede Trennung bedeutet aber: Mehr Komplexität. Deswegen haben wir selten Serverless in Privatanwendungen. Denn wer Serverless "rechnet", sollte auch Serverless "speichern", "CICD". (Also: Wenn dein Codeteil Serverless ist, muss auch dein Datenbankteil Serverless sein - sonst macht es eh keinen Sinn! usw! Und das zieht sich Business seitig in Backend-Systeme in SaaS, die das dann wiederum nicht können! (Ich mach immer das beste draus, hoffe ich!))
Mehr als nur "Apache" zu haben, also beispielsweise "PHP-FPM" für PHP-Interpretation zu betreiben, ist ein Schritt zwischen "Server vom Client trennen" und "Serverprozesse untereinander trennen". Denn es trennt den Workload eines HTTP Servers (Apache) vom Workload eines Script-Interpreters (PHP) (Manche bezeichnen PHP als vollwertige Programmiersprache. Das wäre sie auch gerne und versucht dafür alles, früher z.B. Perl zu kopieren, heute z.B. TypeScript zu kopieren!)
Die Prozesse dürfen zwar gerne auf einem Server laufen - aber gerne auch auf unterschiedlichen. Und gerne auch jeweils auf vielen! (Stichworte: Load Balancer - für Apache
https://httpd.apache.org/docs/2.4/mod/mod_proxy_balancer.html ) Also heißt SoCo auch: Skaliere besser. Und jetzt wissen wir auch, warum jede weitere Abstraktion und Separierung Sinn machen
könnte: Wir möchten besser skalieren!
Darauf läuft es immer hinaus und deshalb ist es kein "Shame", mod_php zu benutzen. Das macht uns nicht uncool (PHP schafft das auch ohne mod_*) und es erfüllt die Maßgabe "The right tool for the right job", bis unser Workload zu groß (Sprich: Unwirtschaftlich) dafür wird.
Im Falle meiner angedachten Anwendungen Pi-Hole und nextcloud und Test.html und test_smf.php.
Ich hätte jetzt:
- Pi-Hole mit extra Port in extra VHost gelegt - /var/www/PiHoleOrdner/ (kein Zugriff von extern)
- Alles andere mit Port80 in einem VHost, und dort mit
- Unterordnern für html und smf.php test gearbeitet - /var/www/html/Unterordner1/ ...
- Aliasen für nextcloud gearbeitet - /var/www/nextcloud/
Oder wäre es besser auch nextcloud einen eigenen Port+VHost zu spendieren?
Aliase sind mir irgendwie eingänglicher, oder was wäre der Vorteil von Symlinks und Allow?
Bzw. andere Vorschläge (nicht zu abgefahren, lieber BestPractice Hausmannskost zu der ich auch viel Doku finde)?
Das ist absolut richtig! Die Aliase zu benutzen bedeutet abr trotzdem eine Directory Direktive - vermutlich mit
Allow (Require) drin. Das ist ja auch keine Einschränkung, sondern nur ein Detail, also keine Nachteile für ein Alias, denn
Allow Require's braucht es immer! Entweder sind
Allow Require's vererbt, oder explizit gegeben.
Außerdem bin ich schon sehr alt in der IT, obwohl ich mich jung fühle und Allow ist schon eine Weile durch "Require" ersetzt. Ich wusste das schon eine Weile, aber Allow und Deny waren so drin und in meinem alten Job auch nach wie vor gang und gäbe, jedenfalls, hier die korrekte Art das zu benutzen:
https://httpd.apache.org/docs/2.4/howto/access.htmlAlter schützt vor Strafe nicht, oder auch: Hausmannskost muss man doch immer mal neu Abschmecken.
Bei requests von extern passt mein Bild mit apache.
apache schaut ob es den angefragten Pfad gibt und liefert genau die html oder triggert die angesprochene *.php.
Aber könnte eine php Anwendung z.B. Nachts um 03:27 ein "lala" in ein log schreiben ohne das um 03:27 irgendjemand von extern auf dieses *.php zugreift (sozusagen selbstgetriggert)?
(klar, das könnte auch ein cron Job, mir ist nur nichts besseres eingefallen)
Damit schließt sich auch wieder der Kreis zu oben - ob so etwas automatisch durchsucht und gestartet wird oder nur nach min 1 externen Aufruf.
PHP Kann sowohl durch Apache (mod_php), PHP-FPM oder auch durch normale cgi (Command "php") aufgerufen werden. PHP kann wie jedes andere Skript auch einfach in der Konsole aufgerufen werden. Erstelle eine PHP Datei mit dem Inhalt `<?php echo "I'm called"; ?>` und dann ruf in deiner Konsole auf `php meinedatei.php`. Das geht, denn PHP ist ein Interpreter wie auch bash. (`bash -e "echo I'm called;"`) Und PHP versucht natürlich auch wie Bash zu sein!
Achso, und das bedeutet natürlich auch: PHP kann auch per cron gestartet werden, oder per jedem anderen Aufruf.
Ein Wort zu PHP: Treat it like Facebook. (Das sollte alle verschiedenen Menschengruppen, die das lesen könnten, korrekt instruieren.)
Thema: apache Webserver, DynDNS, VirtualHosts (Gelesen 71972 mal)