Februar 2012
M	D	M	D	F	S	S
« Jan
	1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29

Archiv der Kategorie LAMP / Webentwicklung

Eclipse für PHP unter Opensuse - I

27.2.2011 von rmo.

Einführung - Eclipse statt Dreamweaver für die PHP-Entwicklung

Lange Zeit habe ich bei einfachen PHP-Projekten aus historischen Gründen Dreamweaver CS4 als besseren “Editor” eingesetzt und damit “herumgedoktert”. Und das gleich in zweifacher Hinsicht:

Dreamweaver betreibt man trotz Wine und Crossover Office immer noch am besten unter Windows. Aber wer will als Linuxer schon auf Dauer mit einer solchen Umgebung leben? Selbst wenn sie sich nur in einer virtuellen Maschine entfalten darf …..
Zudem ist die Arbeit bei komplexen Projekten sehr unkomfortabel, denn für einen schnellen, organisierten Entwicklungsprozess fehlen Dreamweaver eine Reihe von Features, die man im Lauf der Zeit immer mehr vermisst

Nachfolgend nenne ich nur drei der Mängel:

Fehlende Editor-Funktionen und Unterstützung bei der Bearbeitung von Klassen in Dreamweaver
So ist eine aktive Unterstützung während des Editierprozesses speziell von Klassen (u.a. Syntaxprüfung, automat. Angebot an Membervariablen / Methoden) so gut wie nicht vorhanden. Das reduziert sich bei Dreamweaver im wesentlichen auf Code-Highlighting und Angaben zu Interfaces von PHP-Standard-Funktionen. Auch ist es für den Entwickler kaum möglich, bei umfangreichen Klassen einen schnellen Überblick über die benutzten Variablen und Methoden der Klasse mit entsprechenden Links zu den Codestellen im Editor zu bekommen.

Fehlende Anbindung an ein Versionskontrollsystem in Dreamweaver CS4
Vor allem aber erforderte ein vernünftiges Versionsmanagement zumindest bis zur CS4-Version einen mühsamen Umweg über den Linux-Host, um erstellte Dateien dort in eine aktuelle SVN-Version einchecken zu können. Ganz sinnvoll und praktikabel fand ich aber unter Dreamweaver das Checkout/Checkin-Verfahren mit den zugehörigen Dateisperren im Zusammenspeil mehrerer Entwickler. (Hinweisen möchte ich allerdings darauf, dass man seit der CS5-Ausgabe SVN Repositories auch für die SVN Version 1.6.x angeblich an Dreamweaver anbinden kann).

Kein integriertes Tool zur systematischen Erfassung von anstehenden Aufgaben
Ein Nachteil ist aus meiner Sicht auch, dass man das systematische Erfassen und Abarbeiten von Aufgaben mit separaten Tools (z.B. einem Task- oder Projektmanagement-Tool) übernehmen muss, die nicht in die Entwicklungsumgebung “Dreamweaver” integriert sind.

Diese Nachteile einer PHP-Entwicklung unter Adobes Dreamweaver lassen sich dann gut ertragen, wenn in der Regel nur zwei bis drei Personen mit einem Projekt beschäftigt sind, die Entwicklung der Benutzerschnittstelle im Vordergrund steht und die Projekte - speziell die Klassen-Bibliotheken - einen überschaubaren Umfang haben.

Eclipse “Helios” als Kern eines Linux-basierten PHP-Entwicklungssystems als kostenfreie Alternative
Im vergangenen Jahr wurden unsere Projekte aber immer komplizierter und die Anzahl der Klassenbibliotheken immer größer. Deshalb war es allerhöchste Zeit, zu einer besseren Entwicklungsumgebung zu wechseln. Im Frühjahr 2010 ist dann Eclipse in der “Helios”-Version erschienen. Dieser IDE ging ein guter Ruf voraus. Auch die früheren Schwieigkeiten bei der Einbindung von Subversion sollten dort behoben sein. Nach einigen Tests und einer Einarbeitungsphase bin ich inzwischen komplett auf Eclipse Helios unter Linux umgestiegen.

In der folgenden Serie von Artikeln in diesem Blog will ich die Installation und den Einsatz von Eclipse in einer Linux-Umgebung unter Opensuse 11.3/11.4 beschreiben. Wichtig ist mir dabie die Kombination mit SVN, einer Apache/MySQL-Test-Umgebung und nicht zuletzt auch mit Dreamweaver.

Kombination von Eclipse mit Adobe Dreamweaver möglich ?
Wenn mehrere Leute zusammenarbeiten und eine Person sich weiter mit der Wysiwyg-Umgebung Dreamweaver um die Benutzerschnittstelle kümmern will oder muss, stellt sich natürlich die Frage, wie man die Eclipse-Helios-Welt unter Linux mit der Adobe Dreamweaver/Windows-Welt in einem geordneten Entwicklungsprozess kombinieren will. Das ist tatsächlich nicht ganz einfach, da das Checkout/Checkin-Verfahren der Dreamweaver-Umgebung schlecht zu Subversion passt. Hier wird vom Entwickler einige Disziplin verlangt. Dennoch ist ein geordnetes Vorgehen möglich.

Meine unter Eclipse entwickelten PHP-, HTML-, CSS-, Javascript-Dateien stehen heute - nach einigen Experimenten - immer auch meiner Mitarbeiterin zur Verfügung, die (noch) unter Dreamweaver weiterentwickelt und sich auf die Benutzerschnittstelle unserer Weblösungen konzentriert. Wir haben bei uns im Lauf der Zeit ein zweistufiges Entwicklungsverfahren unter der Einbeziehung von Eclipse unter Linux und Adobe Dreamweaver unter Windows etabliert. Das Vorgehen beruht wesentlich auf dem Einsatz von Samba als vermittelndem Verzeichnisdienst zwischen der Adobe-Umgebung in einem virtuellen Windows-System und der eigentlichen Web- und Datenbankserver-Umgebung unter Linux.

Einführung

Für wen ist die kommende Artikelserie zu Eclipse gedacht? Was werden die Inhalte sein?

Die nachfolgenden Artikel befassen sich mit der Implementierung von Eclipse und den ersten erforderlichen Schritten für den späteren produktiven Einsatz unter Opensuse-Linux. Die Artikelserie ist für Leute gedacht, die sich noch nicht mit Eclipse auseinandergesetzt haben, aber den Umstieg auf Eclipse und eine PHP-Entwicklungsumgebung unter Linux unter Einbeziehung eines Web- und Datenbankservers in Erwägung ziehen.

Administrative Grundkenntnisse im Umgang mit Linux (hier in der Opensuse-Ausprägung) sind dabei nötig. Das hält sich aber in Grenzen, da ich mich hier der Einfachheit halber hauptsächlich auf eine Implementierung auf einem einzigen lokalen Linux-System beschränken werde. Das Ergebnis entspricht dann etwa einem autonomen Entwicklungssystem auf einem Desktop-Rechner oder einem Laptop, auf dem eben auch einige einfach konfigurierte Serverkomponenten mitlaufen.

Man sollte also neben dem reinen Interesse für Eclipse auch den Ehrgeiz mitbringen, auf seinem Entwicklungssystem unter Linux auch einen Apache-Server und einen MySQL-Server aufzusetzen. Ohne einen Web- und Datenbank-Server macht ja eine PHP-Entwicklung ohnehin kaum Sinn. Ich werde mich in dieser Artikelreihe allerdings nicht mit den Details einer umfassenden Installation von Server-Modulen, geschweige denn mit der Konfiguration eines Netzwerkes mit Apache-, Samba-, DNS- und Datenbankservern befassen. Im hiesigen Zusammenhang müssen Hinweise auf eine lokale Server-Installation auf einem minimalen, aber hinreichenden Niveau genügen.

Ich selbst habe den Einstieg in Eclipse selbst insgesamt als etwas knifflig empfunden. Da ich auch nach fast 12 Monaten noch längst nicht alle Seiten der Eclipse IDE erkundet habe, bitte ich bei dem einen oder anderen möglichen Fehler oder der einen oder anderen Nachlässigkeit oder Unvollständigkeit der Ausführungen um Nachsicht.

Ich möchte an dieser Stelle nicht verhehlen, dass Eclipse auch einige Nachteile hat. U.a. ist die miserable Performance des eingebauten Editors bei der Behandlung großer Dateien (> 4000 Lines) zu nennen. Ferner kann es manchmal bei komplexen Operationen und Eingriffen in Dateiinhalte mit Fremd-Editoren zu merkwürdigen Kapriolen in der Versionsverwaltung kommen, die man nicht immer versteht. Zudem laufen Updates des Eclipse-Systems und seiner Plugins nicht immer anstandslos durch, weil ggf. Repositories fehlen oder nicht alle Abhängigkeiten aufgelöst werden können. Aber ich habe hier bislang noch immer in relativ kurzer Zeit ein Lösung gefunden.

Alles in allem möchte ich Leuten, die PHP-Entwicklung betreiben wollen und mit ihrer Entwicklungsumgebung - im speziellen Dreamweaver - unzufrieden sind, doch anraten, Eclipse wenigstens einmal testweise auszuprobieren. Der Schritt von Eclipse zu umfangreicheren Umgebungen (z.B. zu einer voll ausgebauten Zend Entwicklungsumgebung) ist dann oft recht einfach.

Implementierung für ein lokales und autonomes Entwicklungssystem

Die Implementierung möchte ich zur Vereinfachung am Beispiel eines lokalen Entwicklungssystems unter Opensuse 11.3/11.4 darstellen. Ich selbst habe die hier beschriebenen Schritte zum Einsatz von Eclipse im Juli 2010 zunächst auf einem Laptop mit nagelneu installierten “Opensuse 11.3″-System und KDE 4.4.4 durchgeführt und habe danach eine Installation in einer Umgebung mit separaten File, Web- und Datenbank-Servern nachgezogen. (Heute läuft Eclipse bei mir auf mehreren Desktops und Laptops unter Opensuse 11.4 und KDE 4.6.1.)

Unser lokales, autonomes Entwicklungssystem soll nach seiner Implementierung folgende Komponenten umfassen:

einen SSL-fähigen Apache-Webserver mit “PHP 5.3″-Modulen,
MySQL 5,
SVN 1.6,
Eclipse Helios mit Erweiterungen für die PHP-Entwicklung, eine SVN-Anbindung und mit Tools für Remote System Interaktionen.

Hinzu kommen für die Kooperation mit Dreamweaver

eine lokale virtuelle Maschine (in meinem Fall unter VMware Workstation mit einem Windows-System und der Adobe Web Premium Suite CS4.
ein lokaler Samba-Server.

In diesem ersten Teil befasse ich mich kurz mit den notwendigen Installationsarbeiten zu Apache, MySQL und SVN. Im zweiten Teil gehe ich dann auf die eigentliche Eclipse-Installation inkl. der Anlage eines ersten PHP-Projektes ein. Im 3-ten Teil behandle ich kurz die Implementierung von Eclipse-Erweiterungen (speziell für SVN) samt Updates. In Teil 4 wird zunächst ein Testprojekt mit SVN verbunden. Danach erzeugen wir im fünften Teil 5 umgekehrt ein PHP-Projekt unter Eclipse aus den Inhalten eines bereits vorhandenen SVN-Repositories.

Im sechsten Teil dieser Reihe binden wir das Eclipse-Testprojekt dann an den Apache-Server an. In weiteren Teilen gehe ich noch auf Besonderheiten wie das Code-Debugging auf dem Webserver ein. Abschließend fasse ich einige persönliche Erfahrungen mit Eclipse zusammen und beschreibe zudem grob das Zusammenwirken mit Adobe Dreamweaver CS4 in einer virtuellen Windows-Umgebung unter Linux.

Hardware- und Betriebssystem-Umgebung - Hinweise zu HW-Voraussetzungen

Der bei meiner ersten Eclipse-Installation verwendete Laptop hatte 2 GB Hauptspeicher - und die braucht er auch, wenn neben Linux, KDE, Apache, MySQL auch Eclipse in einer Java-Runtime-Umgebung läuft. Der Speicherbedarf von Eclipse ist enorm, bei größeren Aufgaben auch der Bedarf an Zeigern des Betriebsystems zu offenen Dateien - speziell wenn man gleichzeitig SVN einsetzt. Hier sind entsprechende Anpassungen im OS nötig, auf die ich an passender Stelle eingehen werde.

Der Dual-Core Prozessor des Laptops war mit 2,14 GHz ist für ein flüssiges Arbeiten völlig ausreichend. Wegen der doch sehr umfassenden und in viele Teilbereiche gegliederten Benutzer-Oberfläche vom Eclipse war ich zudem sehr froh über den 17 Zoll-Schirm des Laptops und seine hohe Auflösung (1920×1200 px). Im professionellen Einsatz möchte ich allerdings zu einer Desktop-Umgebung raten, in der man mit 2 größeren Schirmen arbeitet. Dies gilt erst recht, wenn neben Eclipse auch noch Adobe’s CSx-Umgebung (in einem virtuellen Windows) zum Einsatz kommt.

Vorbereitung und Know-How-Aufbau

Da ich mich mit Eclipse für PHP in der Praxis so gut wie nicht auskannte, habe ich vor meinen ersten Schritten versucht, im Internet Informationen zu finden, die für Einsteiger geeignet sind. Leider sind die meisten Artikel, die ich gesehen habe, naturgemäß an Java-Entwickler gerichtet - und die damit zusammenhängenden Verfahren und Subsysteme von Eclipse interessieren mich als PHP-Entwickler weniger. Leider sind die verfügbaren Artikel auch keineswegs immer so geschrieben, dass man das dort Gesagte einfach auf eine PHP-Entwicklungssituation übertragen könnte.

Wirklich hilfreich für mich war dann eine Video-Tutorial-Serie von “Ralphz” (s. die Links weiter unten), die ich empfehlen möchte. Sie betreffen zwar ältere Eclipse- und PTD-Versionen - aber didaktisch sind die Tutorials so gehalten, dass man das dort Gezeigte fast problemfrei auf die Helios-Umgebung übertragen kann.

Bitte also die Video-Tutorials in Ruhe und komplett ansehen, bevor man mit den Installationsarbeiten beginnt. Man sollte sich erst einen Überblick über die vielfältigen Möglichkeiten und PHP-relevanten Plugins sowie SVN-Plugins etc. verschafft haben, bevor man beginnt, seine persönliche Entwicklungsumgebung aufzubauen.

Die Tutorials machen auch klar, wie Eclipse mit SVN zusammenarbeitet. Man muss über SVN nicht viel wissen, um es zumindest für ein Projekt ohne Entwicklungsverzweigung unmittelbar einsetzen zu können. Ansonsten sei hier auf das auch von “Ralphz” zitierte Online-Buch zu Subversion verwiesen.

Links:

http://vimeo.com/1077103 und die dortigen weiteren Videos aus der Serie von “Ralphz”.
http://theorangeit.org/category/programming/php/page/3/ Ralphz’s Blog
http://www.eclipse.org/subversive/documentation/gettingStarted/aboutSubversive/install.php - Installation-Info zum Subversion-Plugin

Installationsplanung

Mein Ziel war es wie gesagt, eine vollständige Entwicklungsumgebung auf einem Laptop zum Laufen zu bringen. Eclipse ist davon natürlich nur ein Teil und interagiert mit anderen Komponenten. Ich liste mal die wesentlichen Komponenten etwas detaillierter als oben auf:

Apache2-Server mit virtuellen, SSL-fähigen Domainen (warum letztere nützlich sind, erläutere ich weiter unten).
Apache’s PHP5-Modul zur Unterstützung von PHP
Einen laufenden MySQL5-Server.
PhpMyAdmin
SVN in der Version 1.6.6 als Versionsverwaltungstool.
KDESVN als primären SVN-Client
Java 6 JRE von SUN oder das Open-JDK in der Version 1.6
Kate als sekundären Editor
Firefox als Browser
Eclipse Helios mit folgende Plugins:

dem PTD-Plugin für die eigentliche PHP-Entwicklungsarbeit,
dem Subversive-Plugin und Subversive Connectors für die Anbindung an SVN,
dem Web-Entwicklungs-Plugin WTP plus Javascript Development-Unterstützung,
das Target-Management mit dem Remote-System-Explorer
XDebug als Debugging-Subsystem.

Bzgl. einiger Eclipse Plugins gibt es Alternativen - z.B. das “Subclipse”-Plugin statt des “Subversion”-Plugins für die Anbindung an SVN oder ZEN-Tools für das Debugging. Ich habe Subclipse noch nicht erforscht und kann daher dazu nichts Vernünftiges sagen. Die von mir installierten Subversion-Plugins funktionieren aber gut und ich kann damit im Moment leben.

Installation der Nicht-Eclipse-Komponenten

In diesem Beitrag kann ich die Installation von Apache, MySql, etc. nicht im Detail beschreiben. Das würde den Rahmen sprengen. Ich habe die Minimal-Installation für beide Systeme aber in früheren Blog-Artikeln dargestellt, auf die ich an dieser Stelle hinweise. Ansonsten noch ein paar zusätzliche Anmerkungen:

Apache und PHP5 - lokale Installation

Das lokale Entwicklungssystem soll später autonom - d.h. ohne Netzverbindung funktionieren. Ein DNS-Dienst ist für ein rein lokales System überflüssig. Daher können Einträge in “/etc/hosts” das Loopback-Interface verwenden und etwa so aussehen.

127.0.0.1 localhost.localdomain localhost
127.0.0.2 mylap.myprivatedomain.de mylap
127.0.0.2 devdomain

Die IP-Adresse ist wichtig für das spätere Aufsetzen einer IP-basierten, SSL-fähigen virtuellen Web-Domaine “devdomain”. Unter dieser Domaine werden im weiteren Verlauf die Resuktate meines PHP-Projektes sichtbar werden. Als “Netzwerk-Adresse” in einem Browser muss dann halt eine Loopback-Adresse herhalten.

Es gibt im Internet immer wieder kritische Diskussionen zur Verwendung von Loopback-Adressen - ich denke, man kann das im hiesigen Zusammenhang mal getrost ignorieren. Der Weg über “/etc/hosts” und Loopback-Adressen ist eine Krücke Aber die wesentliche Funktionalität eines autonomen Entwicklungs- und Test-Systems lässt sich damit schnell, übersichtlich und ohne große Umwege erreichen.

Apache kann man unter Opensuse einfach über die Yast und die dortige Paketverwaltung installieren. Der folgende frühere Artikel in diesem Blog gibt eine Übersicht darüber, was zu tun ist, um auf die Schnelle die SSL-Fähigkeit des Servers zu aktivieren, eine Standarddomaine (für localhost) sowie eine SSL-fähige “devdomain” bereitzustellen.

Lokaler Apache auf die Schnelle

Die meisten meiner PHP-Lösungen für Kunden erzwingen in der Regel einen HTTPS-Verbindung. Wenn ich das lokal testen will, komme ich um SSL also nicht herum. SSL geht nur über IP-basierte virtuelle Domainen. Für den Standardhost “localhost” ist daher eine zweite separate virtuelle Domaine einzurichten. Siehe zu den Details und den Apache-Konfigurationsdateien den eben genannten, früheren Beitrag.

Die virtuelle SSL-Domaine “devdomain” des Apache-Servers wird über dei DocumentRoot-Anweisung in der Apache-Konfiguration später entweder dem Verzeichnis

DocumentRoot “/srv/www/htdocs/Entwicklung/devdomain/trunk”

oder aber einfacher dem Verzeichnis

DocumentRoot “/srv/www/htdocs/Entwicklung/devdomain/”

zugeordnet. Dieses Verzeichnis wird später auch über die Datei-Transfermechanismen des “Target-Managements” von Eclipse gefüllt.

Die erste Variante benötigt man, wenn man mit Entwicklungszweigen unter SVN arbeiten will. Die Zuordnung zu dem Unterverzeichnis “trunk” deutet bereits an, dass eine verzweigte SVN-Repository-Struktur auf den Apache-Server abgebildet wird. Man kann allerdings auf das “trunk”-Unterverzeichnis auch verzichten. In vielen einfachen Entwicklungsszenarien, in denen “Forks” keine Rolle spielen, ist das evtl. sogar hilfreich. Ich gehe auf beide Alternativen später beim Beschreiben (m)einer Variante des Zusammenspiels von Eclipse mit dem Apache-Server und auch Dreamweaver ein.

Die eingerichtete virtuelle Web-Domaine hilft später beim Testen übrigens auch deshalb erheblich, weil man damit die Tipparbeit in der Adresszeile des Browsers erheblich abkürzt.

Anpassungen der php.ini-Konfigurations-Datei

Auf einem Entwicklungssystem will man natürlich Fehlermeldungen und Warnungen zu PHP5-Programmen sehen. Evtl. hat man auch Programme, die mit der Kurzform der Script-Tags
“”
statt

lauffähig sein sollen. Um zudem beim Einsatz der Funktion date() Warnungen zu vermeiden, ist man zudem genötigt, die Standardzeitzone für das PHP-Modul ein.

Für all das muss man entsprechende Modifikationen an der Datei

“/etc/php5/apache2/php.ini”

vornehmen. Sehen Sie zu Details bitte den oben genannten, früheren Beitrag zur Apache-Installation .

XDebug

Plant man XDebug als Test- und Debug-Umgebung auf dem Apache/PHP-Server zu verwenden, so muss man unter Opensuse noch ein Repository für die Installation der zugehörigen Module aktivieren. Siehe:

http://download.opensuse.org/repositories/server:/php:/extensions/server_php_openSUSE_11.3

Generelle Informationen zu XDebug findet man unter:

http://www.xdebug.org/

Zur Installation von XDegbug sind ggf. folgende Beiträge hilfreich:

http://www.howtoforge.com/installing-php5-debugger-on-opensuse-11.3
http://serwatka.net/blog/xdebug_and_apc_on_opensuse
https://build.opensuse.org/package/show?package=php5-xdebug&project=server:php:extensions
http://osdir.com/ml/php.xdebug.general/2006-12/msg00015.html

Bzgl. Xdebug sind noch nachfolgende Einträge in der php.ini erwähnenswert. Ich folge hier im wesentlichen den Vorgaben des Videos 7 in der Eclipse-Video-Reihe von “ralphz” zu diesem Thema:

zend-extension=”/usr/lib64/php5/extensions/xdebug.so”

xdebug.remote_enable=On

xdebug.remote_host=”localhost”

xdebug.remote_port=9000

xdebug.dump_undefined=On

xdebug.collect_parms=4

xdebug.var_display_max_depth=4

Einheitliche Gruppe und Rechte für das Apache-Entwicklungs-Verzeichnis setzen

Nach der Einrichtung des Apache-Servers wollen wir uns das Leben bzgl. der Rechte auf dem lokalen Testserver etwas vereinfachen. Hierzu legen wir eine Gruppe “entwicklung” an, der der Apache-User - unter Opensuse “wwwrun” - und weitere Entwickler - hier “myself” und “developer” angehören sollen.

Alle Dateien, die wir später aus Eclipse in das zugeordnete Verzeichnis des Webservers - hier “/srv/www/htdocs/Entwicklung/devdomain/” - transportieren wollen, sollen automatisch Zughörigkeit zur Gruppe “entwicklung” und einen einheitlichen Rechtekamm für die Gruppenrechte erhalten.

Wie man zur Vererbung von Gruppenrechten mit ACLs vorgeht, ist ausführlich in einem früheren Beitrag beschrieben

Vererbung von Gruppenrechten mit ext3/ext4 und ACLs

Zunächst prüfen wir in der datei “/etc/fstab” nach, dass ACLs für das Dateisystem aktiv sind, auf dem auch die Apache DocumentRoot-Dateien untergebracht sind. Danach führen wir für das Apache-Haupt-Verzeichnis zu unseren Entwicklungsarbeiten

“/srv/www/htdocs/Entwicklung/”

folgende Kommandos durch (als root-User)

cd /srv/www/htdocs/

chgrp entwicklung Entwicklung

chmod 775 Entwicklung

chmod g+s Entwicklung

setfacl -m m::rwx Entwicklung

setfacl -dm g:entwicklung:rwx Entwicklung

Von nun an erben alle Verzeichnisse und Dateien, die später unterhalb des Verzeichnisses “/srv/www/htdocs/Entwicklung” angelegt werden, die Gruppenzugehörigkeit zur Gruppe “entwicklung” und die angegebenen vollen Gruppenrechte.

MySQL und PhpMyAdmin

Die MySQL-Installation unter Opensuse ist recht einfach. Sie ist in Grundzügen im Artikel

http://linux-blog.anracom.com/2010/08/28/lokale-mysql-phpmyadmin-installation/

beschrieben.

Installation SVN

Subversion ist schnell über entsprechende Pakete installiert:

subversion

subversion-server (wenn man plant, Subversion auf dem Apache-Server selbst laufen zu lassen)

svnmanager (wenn man plant, Subversion auf dem Apache-Server selbst zu administrieren)

subversion-tools

kdesvn (graphischer KDE Client für Subversion)

usvn (PHP-Tool für Subversion auf dem Apache Server)

Installation JRE

Die für Eclipse benötigte Runtime Umgebung installiert man unter Opensuse schnell mit Yast un der dortigen Paket-Verwaltung. Hier stehen das JDK und die Sun JRE zur Auswahl. Für weitere Informationen und zum Wechsel zwischen den Umgebungen - falls man beide installieren und ausprobieren will - siehe :

http://de.opensuse.org/Java#Zwischen_verschiedenen_Java_JREs_oder_SDKs_wechseln

So ausgestattet haben wir nun ein System, das alle elementaren Zutaten für eine autonome PHP-Web-Entwicklungsumgebung unter Opensuse 11.3/11.4 aufweist.

Im nächsten Beitrag beschäftigen wir uns dann mit der Eclipse-Installation und den erforderlichen Erweiterungen für PHP und Subversion.

Geschrieben in Eclipse für PHP-Projekte, LAMP / Webentwicklung | Keine Kommentare »

Lokale MySQL-/PhpMyAdmin-Installation

28.8.2010 von rmo.

Als IT-Mensch ist man oft unterwegs und möchte gerne die Zeit mit seinem Laptop für Entwicklungsarbeiten benutzen - in meinem Fall für LAMP-Applikationen. Für derartige Web-Applikationen benötigt man auf einem solchen lokalen Test- und Entwicklungssystem neben einem Apache-Web-Server i.d.R. auch einen lokalen Datenbankserver, den man dann eventuell mit PhpMyAdmin verwalten will. Ich gebe hier ein paar kurze Hinweise zur Installation von MySQL unter Opensuse 11.3. Wir besprechen hier nur die einfachst mögliche Installation. Sind keine speziellen Anforderungen gegeben, reicht das für Entwicklertests vieler einfacher Anwendungen schon aus.

PhpMyAdmin und vermutlich auch die zu testenden PHP-Applikationen erfordern einen bereits vorhandenen Web-Server mit PHP-Modul. Wie man sich den verschafft, habe ich in einem früheren Beitrag dargestellt.

http://linux-blog.anracom.com/2010/07/25/lokaler-apache-test-server-fur-php5/

MySQL-Installation

Die MySQL-Installation unter Opensuse 11 ist mit Yast recht einfach. Für den Server und einige nützliche Tools habe ich folgende Pakete aus dem Standard-SuSE-Repository installiert. (Für aktuellere Versionen und Varianten von MySQl werfe man bei Bedarf einen Blick in folgendes Repository: http://download.opensuse.org/repositories/server:/database/openSUSE_11.3/ )

mysql-community-server
mysql-community-server-client (!)
libmysqlclient16
libmysqlclient_r16
libmysqld0
libqt4-sql-mysql
php5-mysql
php5-mbstring
php5-mcrypt
php5-zlib
php5-hash
mysql-administrator
mysql-gui-tools
mysql-query-browser
mysql-workbench
mytop
qt3-mysql
perl-DBD-mysql

Nachtrag 20.04.2011:
Die Funktionalität des Pakets “mysql-administrator” ist mittlerweile im Paket “mysql-workbench” aufgegangen. Unter Opensuse 11.4 existiert das Paket “mysql-administrator” deswegen nicht mehr.

(Nebenbei: Man achte auf die feine Unterscheidung in der Paketbezeichnung, die mit der Übernahme von Sun durch Oracle Einzug gehalten hat. Es heißt jetzt an zwei Stellen : community. Ein Synonym für künftig eingeschränkte Funktionalität? Ich ahne schon, dass ich mich bald wieder intensiv mit Postgres auseinandersetzen werde. Überhaupt tauchen Oracle-Embleme inzwischen an jeder Ecke im Linux-System auf. Da merkt man erst, was wir möglicherweise mit Sun verloren haben. Aber das ist ein Thema für sich …. ).

Die genannten Pakete ziehen unter Yast ggf. die Installation weiterer benötigter Pakete nach sich.

Nach der Installation startet man den Datenbankserver unter Opensuse mit “rcmysql start”. Geht dies fehlerfrei, so setzt man nun ein erforderliches MySQL-Root-Passwort mit

mysqladmin - u root password ‘ein_passendes_Passwort’

(Die Anführungszeichen sind ernst zu nehmen! Der ‘root’-User für MySQL ist übrigens nicht mit dem Linux-System-Verwalter-Account zu verwechseln!).

Nachtrag - 20.04.2001:
Ist der eigene PC/Server benannt und einer Domaine zugeordnet - etwa als “mytux.mydomain.de” -, sollte man zusätzlich

mysqladmin - u root -p -h mytux.mydomain.de password ‘ein_passendes_Passwort’

ausführen. Man wird dabei nach dem zuvor angegebenen MySQL-Root-Passwort gefragt.

Alle nachfolgenden Verwaltungsaufgaben - wie die Anlage neuer User und deren Zugriffsrechte von verschiedenen Arbeitsstationen aus - kann man danach mit dem Kommandozeilentool “mysqladmin” oder mit dem grafischen Tool “MySQL Administrator”

/usr/bin/mysql-administrator

durchführen (Nachtrag: bzw. neuerdings mit den Admin-Tools der “mysql-workbench”). Letzteres Tool benutzt man für umfassendere Konfigurationsarbeiten bzgl. der Datenbank als (System-) root, da die Hauptkonfigurationsdateien

“/etc/my.cnf”
“/etc/mysqlaccess.conf”

aus Sicherheitsgründen nur für root schreibbar angelegt werden.

Hinweis: Will man sich den “MySQL Administrator” graphisch auf die eigene KDE-Useroberfläche oder in den “Arbeitsflächen-Ordner” legen, so gibt man in der Konfiguration des Plasma-Icons als Programmaufruf

“/usr/bin/xdg-su -c /usr/bin/mysql-administrator”

an - um den grafischen sudo-Berechtigungsdialog für die Eingabe des root-passwords auf den Schirm zu bekommen. Ähnliches gilt für die Workbench.

Das Kommandozeilentool “mysql” ruft man über

mysql -u root -p

auf und gibt dann danach das oben gesetzte MySQL-root-Passwort ein.

Für einen lokalen Testserver ist das oben Beschriebene als Ausgangsbasis für weitere Arbeiten (Anlegen und Konfiguration der benötigten Datenbanken und Tabellen) hinreichend. Für eine Produktiv-Umgebung sollte man besser eine “secure installation” durchführen. Genaueres dazu findet man unter den Links am Ende des Artikels.

Minimale PhpMyAdmin-Installation

Für unseren lokalen Testserver wollen wir nun PhpMyAdmin installieren. Auch hier besprechen wir nur die einfachst mögliche Implementierung. Voraussetzung ist, dass auf dem Apache-Server PHP5 installiert ist.

Zunächst prüfen wir, dass zusätzlich folgende Pakete installiert sind:

php5-mysql
php5-zip
php5-bz2
php5-mcrypt
mcrypt

und bei Bedarf ggf.

php5-pear
php5-pear-Crypt_Blowfish

Dann laden wir uns von der Seite

http://www.phpmyadmin.net/home_page/downloads.php

phpMyAdmin-3.3.5-all-languages.tar.gz

herunter und entpacken die Dateien in einem lokalen Verzeichnis. Wir gehen davon aus, dass unser lokaler Webserver ein DocumentRoot-Verzeichnis

/srv/www/htdocs

aufweist. Wir legen nun ein Verzeichnis

/srv/www/htdocs/phpmyad

an und kopieren dorthin den Inhalt (!) des vorher aus dem tar-Archiv erzeugten Verzeichnisses “phpMyAdmin-3.3.4-all-languages”.

Danach legen wir ein Verzeichnis

/srv/www/htdocs/phpmyad/config

an und machen es temporär für die Welt schreibbar

chmod 757 /srv/www/htdocs/phpmyad/config

Nun öffnen wir einen lokalen Browser und geben als Adresse an

http://localhost/phpmyad/setup

Auf der neuen Seite drüken wir den Button “Neuer Server”. Im folgenden Dialog “Grundeinstellungen” lassen wir alles unverändert (u.a. den Hostnamen auf “localhost” ) und wählen als Auth-Typ “cookie”. Wir wechseln nun zum Reiter “Serverkonfiguration” und erlauben dort den “root”-Login, damit wir danach Datenbanken anlegen können. Wir speichern dann die Einstellungen. Auf der folgenden Seite wählen wir ggf. “Deutsch” als voreingestellte Sprache und speichern erneut. Wir drücken nun abschließend den Knopf “Laden”.

Im nachfolgenden Schritt kopieren wir die frisch erzeugte config-Datei in das phpmyad-Verzeichnis:

cp /srv/www/htdocs/phpmyad/config/config.inc.php /srv/www/htdocs/phpmyad/

Danach geben wir im Browser ein

http://localhost/phpmyad/

Im nachfolgenden Dialog authentifizieren wir uns als “root” (dies ist der mySQL-root-user) mit dem Passwort, das wir oben am Ende der MySQL-Installation vergeben hatten. Danach sollte die PhpMyAdmin-Oberfläche auftauchen. Nun können wir auf einfache Weise evtl. vorhande Datenbanken importieren, User dazu anlegen und die benötigten Rechte vergeben !

Hinweis:
Die Warnungen und Informationen zur sicheren Verbindung und zur Deaktivierung bestimmter Möglichkeiten sollten uns nachdenklich machen und zu weiteren Arbeiten anregen. Für einen lokalen Testserver ist das ggf. nicht wichtig - wohl aber in Produktivumgebungen! In diesem Beitrag sparen wir uns aber eine Vertiefung.

Abschließender Schritt: Die Schreibrechte auf dem Verzeichnis “config” entfernen wir aus Sicherheitsgründen wieder.

Links

http://de.opensuse.org/MySQL
http://de.opensuse.org/Apache/SSL,_MySQL_und_PHP
http://www.susegeek.com/internet-browser/install-configure-lamp-apachemysqlphp-in-opensuse-110/
http://dev.mysql.com/doc/refman/5.1/de/installing.html
http://dev.mysql.com/doc/refman/5.1/de/default-privileges.html
http://www.howtoforge.com/perfect-server-opensuse11-p4
http://www.unixmen.com/linux-tutorials/237-install-lamp-in-openuse-110-and-111

Geschrieben in LAMP / Webentwicklung | Keine Kommentare »

Lokaler Apache/PHP-Testserver

25.7.2010 von rmo.

Ich entwickle oft “PHP 5″-Programme - auch unterwegs. Auf einem Laptop musste ich vor kurzem einen lokalen Apache-Server einrichten, um auch ohne Netzwerkanbindung Programme testen zu können. Der Server sollte natürlich PHP5 unterstützen und für eine bestimmte Testdomaine - “devdomain” - SSL-fähig sein. Hierzu muss man auf die Schnelle virtuelle Domainen einrichten. Das Ganze unter Opensuse 11.3.

Vielleicht ist die nachfolgende Vorgehensweise zur Lösung dieser Aufgabenstellung auch für andere interessant.

/etc/host-Einträge

Der Rechner soll später autonom - d.h. ohne Netzverbindung funktionieren. Ein DNS-Dienst ist für ein rein lokales System überflüssig. Für einen lokalen, autonomen Testserver kann für die notwendigen Einträge in der Datei “/etc/hosts” das Loopback-Interface verwenden. Die Einträge können dann etwa so aussehen:

127.0.0.1 localhost.localdomain localhost

127.0.0.2 mylap.myprivatedomain.de mylap

127.0.0.2 devdomain

Der erste Eintrag ist ein Standard Opensuse-Entrag, wie er bei einer automatischen Installation erzeugt wird. Den zweiten benötige ich für andere Programme. Interessant für unsere Problemstellung ist die dritte Zeile. Die dortige IP-Adresse ist u.a. wichtig für das spätere Aufsetzen der IP-basierten virtuellen Domaine “devdomain”.

Es gibt im Internet immer wieder Diskussionen um die Verwendung der Loopback-Adresse - ich denke, die oft angeführten Gegen-Argumente kann man im Zusammenhang mit dem beschriebenen Szenario getrost ignorieren. Ein System mit aktiven Netzwerkschnittstellen benötigt natürlich noch mehr Einträge an passender Stelle in der “/etc/hosts” und ggf. eine Adress-Systematisierung über einen DNS-Server. Aber die Funktionalität eines autonomen Entwicklungs- und Test-Systems ist mit den Loopback-Adressen wirklich in hinreichender Weise gegeben.

Für die korrekte lokale Namensauflösung sollte “files” die Reihenfolge der Ressourcen im “hosts”-Eintrag der Datei “/etc/nsswitch.conf” anführen:

hosts: files mdns4_minimal [NOTFOUND=return] dns

Grundinstallation Apache

Apache2 kann man unter Opensuse einfach über die Yast und die dortige Paketverwaltung installieren. Folgende Pakete aus dem Opensuse 11.3 Standard-Repository habe ich installiert:

apache2 (!)
apache2-devel (!)
apache2-doc
apache2-example-pages (!)
apache2-mod_dnssd
apache2-mod_perl
apache2-mod_php5 (!)
apache2-mod_python
apache2-prefork (!)
apache2-utils (!)
libapr-util1 (!)
libapr-util1-devel (!)
libapr1 (!)
libapr1-devel (!)

Nach der Installation und einem “rcapache2 start” sollte ein

http://localhost

im Browser bereits eine Seite mit dem schönen Text “It works!” anzeigen. Danach trägt man mit Yast den Apache2-Server in die Run-Level-Konfiguration ein, damit er automatisch z.B. in den Levels 3 und 5 gestartet wird.

Grundinstallation PHP5

Für eine relativ umfassende PHP5-Unterstützung sind für mich in der Regel folgende Pakete/Module von Bedeutung:

apache2-mod_php5, php-doc, php5, php5-bcmath, php5-bz2, php5-ctype, php5-devel, php5-dom, php5-gd, php5-hash, php5-iconv, php5-imagick, php5-json, php5-mbstring, php5-mcrypt, php5-mysql, php5-pdo, php5-pear, php5-phar, php5-sqlite, php5-tidy, php5-tokenizer, php5-xdebug, php5-xmlreader, php5-xmlwriter, php5-zip, php5-zlib

Die Zusammenstellung kann für umfangreiche Entwicklungsszenarien natürlich komplexer aussehen.

Hinweis zur Aktualisierung der PHP-Installation:
Um eine aktuelle PHP5-Installation unter Opensuse 11.2 zu erhalten (PHP 5.3.3) muss man ggf. die passenden Repositories unter

http://download.opensuse.org/repositories/server:/php/
http://download.opensuse.org/repositories/server:/php:/extensions/

in die Paketverwaltung einbinden. Über das zweite der genannten Repositories erhält man z.B. das Xdebug-RPM.

Modifikation an der php.ini

Auf einem Entwicklungssystem will man man Fehlermeldunge zu PHP5-Programmen sehen. Evtl. hat man auch Programme, die mit der Kurzform der Script-Tags “” statt lauffähig sein sollen. Um beim Einsatz der Funktion “date()” Warnungen zu vermeiden, stellt man auch die Standardzeitzone für das PHP-Modul ein. Für all das muss man entsprechende Modifikationen an der Datei

“/etc/php5/apache2/php.ini”

vornehmen. Entsprechende Einträge (plus ein paar mehr) :

short_open_tag = On
error_reporting = E_ALL & ~E_DEPRECATED
display_errors = On
log_errors = On
ignore_repeated_errors = Off
ignore_repeated_source = Off
register_globals = Off (immer gut)
include_path = “.:/usr/share/php5:/usr/share/php5/PEAR” (PEAR soll funktionieren)
date.timezone = Europe/Berlin

“Spiel-Zertifikat und SSL-Aktivierung unter Opensuse 11.3

Viele meiner PHP-Frameworks für Kunden erzwingen in der Regel einen HTTPS-Verbindung. Wenn ich das lokal testen will, komme ich um SSL also nicht herum. SSL geht nur über IP-basierte virtuelle Domainen. Für den Standardhost “localhost” ist dann zudem eine zweite separate virtuelle Domaine einzurichten.

SSL geht nicht ohne ein Minimal-Zertifikat. Für lokale Testzwecke reicht ein “Spiel-Zertifikat”. (Im Browser fügt man dann bei Warnungen eine Ausnahmeregel für das Zertifikat ein.)

Unter Opensuse 11.3 erreicht man die notwendige Grundausstattung des Apache-Servers unter Benutzung von Apache-Tools durch folgende Kommandos:

a2enmod ssl
a2enflag SSL
/usr/bin/gensslcert (als root absetzen)
cp /etc/apache2/vhosts.d/vhost-ssl.template /etc/apache2/vhosts.d/vhost-ssl.conf
Anpassung der vhost-Dateien (s.u.)

Ein paralleler Blick in die “sysconfig”-Dateien des SUSE-Systems ist hier nicht verkehrt. Dafür kann man z.B. den sysconfig-Editor von Yast heranziehen. Im dortigen kategoriebaum bewegt man sich in den Zweig

“Netzwerke >>> WWW >>> Apache2″.

Unter dem Eintrag “APACHE_MODULES” sollte man folgendes finden:

authz_host actions alias auth_basic authz_groupfile authn_file authz_user autoindex cgi dir include log_config mime negotiation setenvif status userdir asis imagemap ssl php5 authz_default

Unter dem Eintrag APACHE_SERVER_FLAGS sollte SSL auftauchen:

SSL

Hinweise:

Ein Extra-RPM für das SSL-Modul muss unter Opensuse 11.3 nicht installiert werden.
gensslcert erzeugt nur eine Spiel-Cert. Dabei werden folgende Dateien überschrieben:

/etc/apache2/ssl.crt/ca.crt
/etc/apache2/ssl.key/server.key
/etc/apache2/ssl.crt/server.crt
/etc/apache2/ssl.csr/server.csr

Der Virtual-Host für die SSL-Domaine muss IP-basiert (!) angelegt werden - also nicht namensbasiert. “*”-Angaben für die IP-Adressen werden mit Fehlermeldungen quittiert. In unserem Beispiel werden für das autonome Testsystem die Loopback-Adressen herangezogen.
Man darf nicht vergessen, dass man für einen Standardzugang “http://localhost” eine eigene virtuelle Domaine einrichten muss, da es bei virtuellen Domainen ohne Vorkehrungen keinen Standard-Host (Default-Web-Server) mehr gibt.

Konfigurationsdateien

Nachfolgend gebe ich (etwas verkürzt) an, welche Grundeinträge in zwei Konfigurationsdateien unter dem Verzeichnis

/etc/apache2/vhosts.d

notwendig sind, um das Ziel zu erreichen,

einen Standardhost ohne SSL-Verschlüsselung unter “http://localhost”
eine Testdomaine “devdomain” für Entwicklungszwecke über “https://devdomain”

ansprechen zu können:

Inhalt der Datei “ip-based_vhosts.conf” für den Standardserver

DocumentRoot /srv/www/htdocs

DirectoryIndex index.html index.html.var index.htm index.php index.php5

Options Indexes FollowSymLinks

AllowOverride None

Order allow,deny

Allow from all

</Directory>

</VirtualHost>

Hinweise:

Der Name der Datei kann beliebig gewählt werden !
Es wird hier kein “server-name angegeben” !!!! - Default-Server
Das Root-Verzeichnis für den Standardhost ist hier “/srv/www/htdocs”. Dort sind die Web-Dateien und PHP-Programme anzulegen.

Inhalt der Datei “vhost-ssl.conf” für den IP-basierten, SSL-Server für die Domaine “devdomain”

DocumentRoot “/srv/www/htdocs/Entwicklung/devdomain/trunk/”

ServerName devdomain:443

ErrorLog /var/log/apache2/error_log

TransferLog /var/log/apache2/access_log

SSLEngine on

SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

SSLCertificateFile /etc/apache2/ssl.crt/server.crt

SSLCertificateKeyFile /etc/apache2/ssl.key/server.key

SSLOptions +StdEnvVars

</Files>

SSLOptions +StdEnvVars

</Directory>

SetEnvIf User-Agent “.*MSIE.*” \

nokeepalive ssl-unclean-shutdown \

downgrade-1.0 force-response-1.0

CustomLog /var/log/apache2/ssl_request_log ssl_combined

</VirtualHost>

</IfDefine>

Hinweise:

Der Host muss eine IP-Adresse erhalten - hier die lokale Loopback-Adresse.
Der Servername (vergl. mit /etc/hosts) wird in einer speziellen, separaten Zeile eingetragen.
Die IP-Adresse muss mit dem angegebenen Namen des Servers auch in der Datei “/etc/hosts” eigetragen sein !
Das DocumentRoot-Verzeichnis habe ich deshalb mit dem “trunk”-Zweig ausgestattet, um die Verzeichnisstruktur eines an Eclipse angebundenes SVN-Repositories zu berücksichtigen. Das kann man natürlich auch anders machen.

Nach dem Anlegen der Dateien kann man nun die neue Konfiguration nach einem “rcapache2 restart” testen. Dazu legt man im Verzeichnis

/srv/www/htdocs/Entwicklung/devdomain/trunk/

eine kleine Testdatei an oder kopiert die “index.html” aus dem Pfad “/srv/www/htdocs” dorthin. Firefox sollte beim Aufruf der Adresse “https://devdomain” keine SSL-bezogene Fehlermeldung anzeigen, sondern nur wegen des nicht vertrauenswürdigen Zertifikats warnen. Der Warnung begegnet man mit einer dauerhaften Ausnahme-Regel. Danach sollte die Test-Datei angezeigt werden. Taucht wieder Erwarten eine Meldung “ssl_error_rx_record_too_long” auf, so ist etwas an der Apache-Konfiguration faul und man muss nacharbeiten.

Das ist natürlich nur eine Ruck-Zuck-Installation eines lokalen Testservers für den Hausgebrauch auf einem PC oder Laptop. (Ein ordentlich aufgesetzter Apache2 sieht anders aus). Aber mit der obigen Konfiguration lassen sich schon bestens PHP-Programme testen.

Viel Spaß also beim PHP-Entwickeln unterwegs - und natürlich unter Linux !

Links

http://de.opensuse.org/Apache/SSL-Anleitung
http://de.opensuse.org/Apache
http://www.schirmacher.de/display/INFO/Apache+SSL+Zertifikat+erstellen+und+installieren
http://wiki.ubuntuusers.de/Apache/SSL
http://aktuell.de.selfhtml.org/artikel/server/apacheconf/apconf12.htm
http://de.opensuse.org/Apache/Schnellstartanleitung

Geschrieben in Apache, LAMP / Webentwicklung | Keine Kommentare »

homepages

Archiv der Kategorie LAMP / Webentwicklung

Eclipse für PHP unter Opensuse - I

Lokale MySQL-/PhpMyAdmin-Installation

Lokaler Apache/PHP-Testserver