PHP In PHP entwickeln unter Linux

[moonwalker99]

Ich habe früher unter Windows in PHP entwickelt. Da war die Einrichtung der Entwicklungsumgebung sehr einfach. Man hat XAMPP installiert, PHP und SQL-Server gestartet, ein gewünschtes Verzeichnis als htdocs-Verzeichnis angegeben, wo man seine PHP-Dateien ablegen und am Browser starten konnte.

Unter Linux installiert man ein LAMP und es gibt das /var/www-Verzeichnis, das dem Benutzer www-data gehört. Wie arbeitet man normalerweise unter Linux? Richtet man es so ein, dass man auch mit seinem User-Account in /var/www schreiben darf? Oder legt man sich im eigenen home-Verzeichnis ein public_html-Verzeichnis an, wo man seine PHP-Dateien ablegt? Ich habe schon verschiedene Anleitungen gesehen. Gibt es weitere Wege?

Meine Frage ist: welcher Weg hat sich "etabliert" und gilt als sinnvoll?

 

[NullPointer]

Du kannst die Dateien ablegen, wo immer es dir am besten passt. Dann musst du nur deinen Webserver (Apache / nginx) so konfigurieren, dass er das gewünschte Verzeichnis als Webroot benutzt und die PHP-Dateien darin richtig verarbeitet.

 

[Daaron]

Ich für meinen Teil nehme nicht den normalen apache2-mpm-prefork, der als Standard installiert wird, sondern apache2-mpm-itk. Das ganze kombiniere ich mit virtuellen Hosts und kann somit verschiedene Projekte in verschiedenen Ordnern voneinander abschotten und jedem Projekt/Ordner einen eigenen Benutzer zuweisen.

 

[moonwalker99]

Ich für meinen Teil nehme nicht den normalen apache2-mpm-prefork, der als Standard installiert wird, sondern apache2-mpm-itk. Das ganze kombiniere ich mit virtuellen Hosts und kann somit verschiedene Projekte in verschiedenen Ordnern voneinander abschotten und jedem Projekt/Ordner einen eigenen Benutzer zuweisen.

Das hört sich interessant an. Gibt es Anleitungen für diese Lösung?

 

[Daaron]

mpm-itk ist ein Nobrainer. einfach statt mpm-prefork installieren, ist in allen gängigen Distributionen als Drop-In-Replacement vorhanden.
In die Konfiguration des jeweiligen vhosts gehört dann nur noch ein:
<IfModule mpm_itk_module>
AssignUserId DeinUserName DeinGruppenName
</IfModule>
und der gesamte Web-Prozess läuft unter diesem Benutzer/Gruppe, inklusive des mod_php PHP Interpreters. Wenn man auf PHP via FastCGI (z.B. PHP-FPM) setzt, siehts anders aus.

Wie du vhosts konfigurierst, dafür gibts wirklich 1001 Tutorial.

 

[kling1]

statt dir auf deinem rechner nen lamp server aufzusetzen.. würde ich echt eher zu ner vm greifen.. mit vagrant hast hier: https://github.com/r8/vagrant-lamp zum beispiel eine fertig konfigurierte umgebung.. es wird in der regel ein verzeichnis in deinem homeverzecihnis gespiegelt , und wendd du /etc/hosts anpasst kannst du zumbeispiel über http://meineseite.dev oder wie da auf der seite beschrieben http://local.dev auf deine seite zugreifen..
vorteil ist dass viele tools schon vorkonfiguriert sind und das du machen kannst was du willst ohne dein eigenes system zu beinträchtigen

das ist die optimale lösung zum entwickeln

hier nochmal ein gutes tutorial um dir eine eigene vagrant vm zu erstellen http://geshan.blogspot.de/2014/07/getting-started-with-php-lemp-on-vagrant.html

 

[ice-breaker]

vorteil ist dass viele tools schon vorkonfiguriert sind und das du machen kannst was du willst ohne dein eigenes system zu beinträchtigen

Der große Vorteil ist, dass man auch mehrere Versionen von Produkten einsetzen kann. Ich möchte ungern auf meinem Rechner 8 versch. MySQL-Server laufen lassen, weil jeder Kunde eine andere Minor-Version bzw. ein anderes Patch-Level einsetzt. Oder gar so Dinge wie Crons usw., die will ich wirklich nicht während meiner normalen Arbeit laufen haben, die laufen dann eben nur wenn die virtuelle Maschine gestartet ist.

 

[mambokurt]

Der große Vorteil ist, dass man auch mehrere Versionen von Produkten einsetzen kann. Ich möchte ungern auf meinem Rechner 8 versch. MySQL-Server laufen lassen, weil jeder Kunde eine andere Minor-Version bzw. ein anderes Patch-Level einsetzt. Oder gar so Dinge wie Crons usw., die will ich wirklich nicht während meiner normalen Arbeit laufen haben, die laufen dann eben nur wenn die virtuelle Maschine gestartet ist.

Mal blöd gefragt: macht das bei Mysql echt so viel aus? Also ich hab da immer halbwegs SQL92 konforme Statements geschrieben und hatte jetzt noch nie Probleme zwischen zwei MySQL Versionen O.o

Zur Frage: also ich habe der Einfachheit halber immer Xampp installiert und da meinen Ordner /projects aus dem Homeverzeichnis nach /htdocs gemounted. Dann noch dem Webserver die Gruppe von meinem User gegeben und dann wars auch gut (das ist jetzt nicht paranoid sicher, aber ich arbeite damit eh nur zu Hause hinter einem Router alle 10 Tage, da interessiert es mich schlicht nicht ob das Ding ein Passwort gesetzt hat oder auf welcher Gruppe das läuft).

 

[ice-breaker]

Vor allem die Performance kann sehr verschieden sein, da der Query Planer immer besser wird, teilweise aber total schlecht ist.
Da macht es bei komplexen Anfragen einen gewaltigen Unterschied ob man diesen auf 5.1 oder 5.6 ausführt.

 

[Daaron]

Na ja, an der Performance kannst du aber wenig machen. Wenn du ein bestimmtes Datenset brauchst, dann schreibst du eben den passenden Query. Wenn der Live-Server dann eine veraltete Mistkrücke ist, dann kannst du auch nichts daran ändern. Du wirst ja wohl kaum die gesamte Datenstruktur und Funktionsweise eines eigentlich optimalen Programmes über den Haufen werfen, bloß weil der Kunde das Prinzip von "Mindestanforderungen" nicht versteht.

 

[mambokurt]

Vor allem die Performance kann sehr verschieden sein, da der Query Planer immer besser wird, teilweise aber total schlecht ist.
Da macht es bei komplexen Anfragen einen gewaltigen Unterschied ob man diesen auf 5.1 oder 5.6 ausführt.

Also ich habe eigentlich bei allen Versionen die selben Erfahrungen gemacht: max_heap_table_size und tmp_table_size für MySQL nach oben schrauben(wer hat da eigentlich die grenzdebilen Standardwerte entschieden?), Subselects mit IN vermeiden und statt dessen EXISTS verwenden, der Rest ist meistens mit einem Index erledigt. Wenn es irgendwo Performanceprobleme gab war es meistens ein Subselect mit IN oder ein Join hat zu viele Daten für tmp_table_size geliefert und der Server angefangen zu swappen.
Dazu muss ich aber wohl sagen dass ich kaum (eher keine) MySQL spezifischen Features verwende, ich weiß also nicht wo da evtl noch Fußangeln rumfliegen.

 

[ice-breaker]

Es gibt da genügend Fußangeln. Für ältere MySql Versionen muss man den Query vllt mal etwas umschreiben, in 2 einzelne aufsplitten und in PHP zusammenkleben oder bei einem Join die Nutzung eines bestimmten Index forcen.
Alte MySQL-Versionen können der Graus sein, aber bei komplexen Anfragen (Richtung OLAP) ist es auch mit neuen Versionen noch notwendig, dass der Query auf die MySQL-Version hingeschustert. Man kann den Kunden nicht immer zu einem Update zwingen.