staging.inyokaproject.org

adun schrieb:

DerDenker schrieb:

Grund für das kompilieren.

Externe Module. Wenn man natürlich nur einen http/https Server oder Loadbalancer braucht, braucht man die nicht. Aber ich zumindest hab bisher immer ein Modul gebraucht, musste also immer selbst kompilieren. Dann kommen da noch die nicht vorhandenen Updates zu.

Mit großer Sicherheit kann man das, aber es soll ja nicht Sinn der Sache sein "Kopier' dir hier ein wenig raus und dort noch etwas". Eventuell kennt ja jemand anders noch eine bessere Methode ☺

Man kann die natürlich auch selbst spawnen. Das Skript ist eher trivial, da man aber ohnehin ein Startscript braucht (reboot), kann man auch gleich das von lighty nehmen. Das Paket ist auch nur aus dem lighty-Paket rauskopiert, weiß also nicht was du dagegen hast. Setz doch das getestet auf "ab Karmic", dann ist es egal.

Ich weiß nicht, wie weit man die Konfiguration ausweiten soll. Wäre es nicht besser, statt die Einsteiger-Seite mit Rewrite-Rules, die auch wieder erklärt werden müssen, vollzuballern, lieber auf das nginx Wiki zu verlinken. Siehe hier.

Mir gings nicht um das rewrite, sondern um das if, das rewrite war nur ein Beispiel, das sehr häufig benutzt wird, beispielsweise um ne "Wir sind gerade nicht erreichbar Blabla" Seite anzuzeigen.

Was soll das heißen? Ich meine, ich kann doch nur mit PHP hochladen. Sonst drehe ich ihm doch den Hahn ab. 😕

Wenn jemand ein Skript hoch läd, willst du dann, dass es ausgeführt wird?

Sorry, ich wollte eigentlich den Beitrag löschen, da du in voller Linie recht hattest. Ich stand nur auf dem Schlauch. Ich habe deine Punkte auch mit aufgenommen. ☺

Letzer /push von meiner Seite.

So, jetzt bin ich soweit fertig mit meinem Artikel. Folgendes ist jetzt enthalten:

• Definition

• Installation

• Allgemeine Konfiguration

• PHP-, Python- und Perl-Anbindung

• Steuerungsmöglichkeiten

• Optimierungsmöglichkeiten

• "Tipps & Tricks"

• Kleiner Sicherheitsteil

• Problemlösungs-Bereich

• Weiterführende Links

Zusätzlich noch einige Sätze vereinfacht und verfeinert und die Struktur leicht verändert.

Ich bitte ein letztes Mal auf das Überprüfen von Fehlern. Danke ☺

Gruß

DerDenker

Mhh, keiner schreibt etwas. Wenn es keine Fehler etc. mehr gibt, bitte ich um Freigabe. ☺

Hallo,

Da ist ja einiges hinzu gekommen... Habe jetzt noch ein paar Textstellen geändert und ein paar Seiteninterne Links hinzugefügt. Was mir noch auffiel:

• Es sind noch sehr viele Hinweisboxen drin. Meiner Meinung nach könnten einige wegfallen.

• Die PHP/Python/Perl-Abschnitte sollten evtll weiter nach hinten verschoben werden. Sie sind ja für den Betrieb des Servers nicht unbedingt notwendig.

Zum Inhalt kann nix sagen.

Gruß
kaputtnik

kaputtnik schrieb:

• Es sind noch sehr viele Hinweisboxen drin. Meiner Meinung nach könnten einige wegfallen.

Ist erledigt.

• Die PHP/Python/Perl-Abschnitte sollten evtll weiter nach hinten verschoben werden. Sie sind ja für den Betrieb des Servers nicht unbedingt notwendig.

Auch erledigt.

Danke für deine treue Mithilfe an diesem Artikel 😉

Mhh... Ich bin fertig, aber nichts passiert. ☹

Naja, den Artikel habe ich noch um nWeb und SSL erweitert.

Soweit sollte auch alles funktionieren; falls sich noch ein Fehler eingeschlichen hat, bitte Bescheid sagen 😉

Hallo,

verschoben: nginx.

Hinweis für die Zukunft: Wenn noch jemand mehr in den Artikel packen will sollte der Artikel geteilt werden. Z.B. das FCGI-Zeug in einen eigenen unterartikel.

Gruß, noisefloor

Rewriting

Statt sich die Domäne wie z.B. „ http://www.example.com/index.php?artikel=1234 ” zu merken, ist es viel einfacher, sich die Domäne „ http://www.example.com/artikel/1234 ” zu merken. In der Konfigurationsdatei kann dies im server { [...] }-Block erledigt werden:

rewrite  ^/artikel/(.*)$  /index.php?artikel=$1?  last;

^/artikel/(.*)$ bedeutet folgendes: Sollte irgendwo /artikel/ vorkommen, dann kommt das, was hinter /artikel/ steht, in die Variable $.

/index.php?artikel=$1? bedeutet, dass statt „ http://www.example.com/artikel/1234 ” „ http://www.example.com/index.php?artikel=1234 ” aufgerufen wird. 1234 ist hier der Wert der Variable $ gewesen.

Hätte das Beispiel im Codeblock nicht den umgekehrten Effekt zum Beispiel im ersten Satz? Oder habe ich gerade einen Knoten im Hirn?

Hallo allerseits, Ich habe noch paar Ideen für den Artikel. Wie wär es wenn man statt diesen Shell Skript mit dem man php fcgi starten kann, stattdessen nur php5-fpm installiert. Es spart Copy&Paste. Zweitens eine Anleitung für pures CGI für zum Beispiel Bugzilla. Der Launcherskript von Bugzilla ist in CGI geschrieben. Eine Anleitung für Ruby wäre auch gut. Gruß, MDickie

Hallo,

Wie wär es wenn man statt diesen Shell Skript mit dem man php fcgi starten kann, stattdessen nur php5-fpm installiert. Es spart Copy&Paste.

Hm? Heißt was? Was bewirkt denn das Paket?

Zweitens eine Anleitung für pures CGI für zum Beispiel Bugzilla

Pures CGI gibt es in dem Sinne nicht. CGI ist "nur" eine standardisierte Schnittstelle, welche von allen möglichen Programmiersprachen aus genutzt werden kann.

Gruß, noisefloor

noisefloor schrieb:

Hm? Heißt was? Was bewirkt denn das Paket?

Es ist ein FastCGI Prozess Manager für php. Das heißt du brauchst nicht bei jeden neustart des Rechners einen php fastcgi Prozess starten, weil der Prozess per als Service gestartet wird. Nächstens sorgt er sich um die Userverwaltung und somit brauchst nicht suphp installieren.

Pures CGI gibt es in dem Sinne nicht. CGI ist "nur" eine standardisierte Schnittstelle, welche von allen möglichen Programmiersprachen aus genutzt werden kann.

Seltsamerweise gibt es bei bugzilla .cgi Dateien. Heißt dann das eigentlich das Bugzilla in Perl geschrieben ist wie es bei Wikipedia steht.

Hallo,

Seltsamerweise gibt es bei bugzilla .cgi Dateien.

Die Dateiendung sagt in diesem Fall nichts über den Inhalt = die Programmiersprache. Die Dateiendung sagt nur, dass die Datei via CGI eingebunden werden sollte. Programmiersprache könnte aber z.B. Perl, Python, ... sein.

Gruß, noisefloor

Ein paar Vorschläge zum Artikel:

1. Das FastCGI sollte einen UNIX-Socket benutzen an Stelle eines TCP-Sockets. Dürfte etwas performanter sein. Siehe z.B. https://library.linode.com/web-servers/nginx/php-fastcgi/ubuntu-12.04-precise-pangolin?format=print

2. Die zeitgemäße Methode (seit PHP 5.3.3?) für FastCGI mit NGINX und PHP5 scheint FPM zu sein (Paket: php5-fpm). Beispiele dazu unter https://www.digitalocean.com/community/articles/how-to-install-linux-nginx-mysql-php-lemp-stack-on-ubuntu-12-04 und http://wiki.nginx.org/PHPFcgiExample

Sehr wichtig auch http://wiki.nginx.org/Pitfalls#Passing_Uncontrolled_Requests_to_PHP

Wenn man nicht prüft ob die gewünschte PHP Datei existiert, ist das womöglich eine Sicherheitslücke (wenn die Software z.B: Upload von Avatarbildchen erlaubt und in diesem Bild dann PHP-Code eingebettet ist, wird der sonst ausgeführt, wenn man der bild.png URL noch ein /irgendwas.php anhängt).

Die genannten Vorschlaege bezgl. der Konfiguration duerfen jederzeit ergaenzt werden - es ist ein Wiki ☺