PHP Programmierumgebung unter Debian

[moonwalker99]

Ich habe mir nach dieser Anleitung in VirtualBox ein Debian-System mit LAMP-Server installiert. Die Anleitung ist sehr informativ (wie auch die ganze Website), allerdings frage ich mich, wie sinnvoll es ist, in /var/www zu arbeiten. Wenn ich Dateien dorthin kopiere, dann muss ich jedes Mal mit chown den Besitzer auf www-data setzen. Das sieht mir zu umständlich aus.

Wie arbeitet ihr denn? Wäre es nicht sinnvoller mit das Apache-Modul userdir zu aktivieren, um dann im eigenen home-Verzeichnis arbeiten zu können? Mit der URL http://localhost/~username/ kann man ja leben.

 

[Suxxess]

Und wenn du "www-data" in die selbe Gruppe wirfst wie deinen User? Sollte doch klappen oder?

 

[moonwalker99]

Und wenn du "www-data" in die selbe Gruppe wirfst wie deinen User? Sollte doch klappen oder?

Ich habe meinen User der Gruppe www-data hinzugefügt.
Als ich Drupal nach /var/www entpackt habe und es über den Browser einrichten wollte, gab es Fehlermeldungen wegen fehlender Schreibrechte. Ich habe dann die in der Anleitung erwähnten Schritte ausgeführt, danach hat es geklappt. Jetzt weiß ich nicht, ob es an dem Besitzer oder an den Zugriffsrechten (775) gelegen hat. Trotzdem ist es umständlich, wenn ich das jedes Mal machen muss. Wie arbeiten andere Leute mit PHP?

 

[Daaron]

Geht viel leichter:
Installiere statt apache2-mpm-prefork doch das Paket apache2-mpm-itk. Dach packst du in der VHost-Konfiguration (wenn du keine VHosts nutzt: /etc/apache2/sites-available/default einfach

<IfModule mpm_itk_module>
AssignUserId deinUser deineGroup
</IfModule>

mit rein.
Danach läuft dieser VHost mit deinen Berechtigungen.

 

[g0l3m]

Wie arbeitet ihr denn?

Unter OS X mit einem per afp gemounteten /var/www, das eine virtuellen Maschine bereitstellt. In dieser Büchse läuft PHP via fastcgi/suexec an httpd angebunden und damit mit eigenen Rechten (anstelle von www-data).

Ist, was das Usermanagement für PHP angeht, das gleiche wie *itk.

 

[Daaron]

@g0l3m
Kleine OT-Frage: Wie verhält sich fcgi/suexec hinsichtlich PHP Opcode Caches wie APC? nach meinen Tests scheint mpm-itk wunderbar mit APC zusammen zu spielen, und für zukünftige Server-Setups suche ich eine sichere Multiuser-Lösung mit Opcode-Caching.

 

[g0l3m]

Generell funktioniert das. Der OpCode Cache wird aber nicht geteilt, d. h. jeder PHP Prozess hat seinen eigenen APC. Ist aber egal, da der Overhead klein ist und nach dem 1. Request jeder weitere profitiert.

Ich allerdings nutze aufgrund der sporadischen Segfaults gar keinen OpCode Cache unter PHP mehr. Nicht so schlimm wie unter eAccelerator aber immer noch vorhanden.

 

[ice-breaker]

@g0l3m: PHP5.4? Weil da musste ich APC auch wieder deaktivieren, die sind da noch Meilen von einer wirklich guten stabilen APC-Version entfernt. Nicht ohne Grund wurde nun beschlossen für PHP5.5 den Zend Optimizer+ direkt in den PHP Core aufzunehmen, damit wenigstens ein stabiler Opcode Cache jederzeit für jedes (neue) PHP existiert.

 

[g0l3m]

Nein, habe APC schon mit PHP 5.3 deaktiviert und seitdem keine gründlichen Tests mehr durchgeführt. Mir reicht im Moment das Caching der Apps (also Templates, die geparst als HTML Dateien für 24 h abgelegt und ausgeliefert werden).

 

[Daaron]

Mein Kernproblem sind Magento-Systeme, insbesondere die Such- und Filterfunktionen. Da gibt es keinen statischen HTML-Cache. Die einzige Methode, denen zügig in den Arsch zu treten, sind Opcode-Caches wie APC (und natürlich: mehr Hardware auf das Problem werfen).