Hier sind folgende Dateien und Verzeichnisse betroffen:

/etc/hosts

Damit unser lokaler Webserver überhaupt vom Webbrowser gefunden werden kann, müssen wir unseren Localhost mitteilen, dass wir eine Applikation mit dem Namen weightapplication haben.
Öffne die Datei /etc/hosts (mit Root-Rechten) und füge folgende Zeile hinzu:

127.0.0.1 weightapplication

Damit wird festgelegt, dass der DNS weightapplication auf der IP-Adresse 127.0.0.1 (localhost) erreicht werden kann.
Speichere die Datei.

/etc/apache2/sites-available

In diesem Verzeichnis legst du eine Datei weightapplication an.
Diese befüllst du mit folgenden Zeilen:

NameVirtualHost weightapplication
<VirtualHost weightapplication>
    ServerAdmin root@localhost
    ServerName weightapplication
    DocumentRoot "/home/roland/workspace/weightapplication/app/webroot"
    <Directory "/home/roland/workspace/weightapplication/app/webroot">
        Options Indexes FollowSymLinks
        AllowOverride FileInfo Indexes
        Order allow,deny
        Allow from all
    </Directory>
<IfModule alias_module>
</IfModule>
<IfModule mpm_peruser_module>
    ServerEnvironment apache apache
</IfModule>
</VirtualHost>

Anstatt /home/roland/workspace fügst du bitte den WORKSPACE Pfad von deiner Konfiguration ein. Spannend ist hier, dass das Webroot von CakePHP in /app/webroot liegt. Hier greift der Apache auf die index.php zu. Alle darunterliegenden Verzeichnisse sind für Webanwender versteckt. Damit hat CakePHP eine einfache und effiziente Möglichkeit implementiert, die Konfigurationen der Applikation vor unliebsamen Anwendern zu verstecken.

Nachdem du diese Datei abgespeichert hast, müssen wir noch dafür Sorge tragen, dass Apache diese Konfiguration auch verwendet.

Hierfür führst du den Befehl

a2ensite weightapplication

Dieser Befehl legt in /etc/apache2/sites-enabled einen symbolischen Link auf die Datei weightapplication im Verzeichnis /etc/apache2/sites-available
.
So, fertig ist die Apache Konfiguration.

Nun müssen wir unserem Apache die neue Konfiguration mitgeben.

Mit apachectl configtest können wir kontrollieren ob wir uns in der weightapplication Datei vertippt haben. Falls der Check Syntax ok zurückliefert, kannst du mit apachectl graceful den Apache neu starten.

Fertig konfiguriert

Ähnliche Beiträge

Mit Synaptic, dem Paketmanager von Ubuntu, ist die Installation kinderleicht.

PHP Installation

Ich habe hier einen Screenshot meiner installierten PHP-Komponenten gemacht.

Wähle bitte php-5 und php5-mysql aus. Die restlichen Pakete müssten dann mit angezogen werden.

MySQL Installation

Wenn du mysql-server auswählst, wird der Rest entsprechend mit angezogen.
Bei der Installation wirst du nach einem root-Passwort gefragt. Dies ist dein Root-Passwort für den DB-Server. Wähle eins und merke es dir. In der Demoinstallation werden wir zuerst den User root und sein Passwort verwenden. Wenn du das später ändern willst, ist das ein Artikel für sich

Apache2 Installation

Auch das ist kinderleicht.
Hier meine installierten Pakete:

Wenn du das Paket apache2 auswählst, sollte eigentlich alles von alleine laufen.

Nach der Installation dieser Pakete können wir uns wieder um die eigentliche Applikationsentwicklung kümmern.
Juchhu! Drei Komponenten sind beschrieben. Das geht doch voran gelle?

Ähnliche Beiträge

Diese Meldung hat mich bei meinen lokalen Webservern immer ziemlich genervt.
Was macht man dagegen?

Ganz einfach:

Irgendwo in deinen apache.conf Dateien (z.b. bei Ubuntu im /etc/apache2/sites-available oder bei Gentoo im /etc/apache2/vhosts.d) kannst du in deine .conf Datei einfach noch den Servernamen eintragen.

Also:
servername [DEIN SERVERNAME] und weg ist die Meldung.
Einfach gelle?

Ähnliche Beiträge

Softwarepaket Installation

Wenn man über den Webserver auf Subversion zugreifen will, braucht man natürlich einen Webserver (apache2) und Subversion.
Also zuerst im /etc/make.conf die use-Flags apache2 und subversion eintragen.
Dann apache2 und subversion emergen.
Falls apache2 schon vorab installiert war, lohnt sich ein emerge –newuse –deep world. Damit ist sichergestellt, dass apache2 die notwendigen Module, wie beispielsweise mod_dav nachinstalliert.

Apache konfigurieren

Die Konfiguration von Apache2 erfordert das Anpassen von ein paar Dateien.

/etc/apache2/modules.d/47_mod_dav_svn.conf

Hier wird der Zugriff auf die SVN-Repositories eingetragen.
Ich will meine SVN-Repositories im Verzeichnis /var/svn/repos anlegen.
Nehmen wir mal an, dass dein SVN-Repository hugo heißen soll.
Dann kannst du die folgenden Einträge in 47_mod_dav_svn.conf eintragen:

Du kannst hier recht gut sehen was alles konfiguriert werden muss.
Zuerst muss das mod_dav_svn und das mod_authisolde htdocs # cz_svn Modul geladen werden. Damit erreichst du, dass später über das DAV Protokoll mit dem Subversion System kommuniziert werden kann.
Mit SVNPath gibst du an, wo dein Repository schlussendlich liegt. (Hier heißt das Repository hugo)
Ich habe in /var/svn/conf/svnusers ein File generiert in dem ich alle berechtigten User eintrage. Dazu später mehr.
Mit SVNIndexXSLT kannst du das Repository über einen Webbrowser ansprechen und darin rumstöbern.

svnindex.xsl bereistellen

Wenn du mit dem Webbrowser später dein SVN-Repository aufrufen willst, muss diese Datei im localhost verfügbar sein.
Da im 47_mod_dav_svn.conf das svnindex.xsl direkt im Root-Verzeichnis des localhost deklariert wurde, müssen wir es dort hinkopieren.
Meine copy-Befehle lauteten dafür:

Falls du eine andere Subversion Version hast, musst du den Copy-Befehl natürlich entsprechend anpassen.

svnusers erstellen

Ich möchte nur User, die auch berechtigt sind, auf das SVN zugreifen lassen.
Deshalb generiere ich in /var/svn/conf/svnusers eine entsprechende Datei mit meinem User.

Du kannst mit htpasswd2 natürlich noch weitere User hinzufügen. Wenn du z.B. alfred hinzufügen willst, dann schreibe

Subversion Server starten

Jetzt solltest du mit /etc/init.d/svnserve start den Subversion Server starten. Wenn du ihn bei jedem Neustart starten willst, lohnt sich noch ein rc-update add svnserve default.

Repository hugo anlegen

Wir müssen noch das Repository anlegen, damit wir auch was zum Zugreifen haben

Apache neu starten

Immer wenn du an der 47_mod_dav_svn.conf rumfummelst, und beispielsweise neue Repositories einträgst, musst du den Apache neu starten.
Das kannst du mit pache2ctl graceful oder für die harten Jungs mit /etc/init.d/apache2 restart erledigen.

So das wars

Mehr sollte es eigentlich nicht sein.
Happy Subversioning!

Ähnliche Beiträge

6:51 Uhr: Definition der Vision

Gut, zuerst brauchen wir mal eine Vision die wir umsetzen wollen.
In meinem Fall möchte ich einen Datenspeicher haben in dem ich schnell mein Gewicht eingeben kann.
Das bedeutet, dass ich mit der Applikation die Resultate vom Wiegen abspeichern will.
In der ersten Version dieser Applikation soll also eine Eingabemaske zur Verfügung stehen, mit der man sein Gewicht in kg (z.B. 83,7kg) eingegeben werden kann.
Da es mir peinlich ist, mein tatsächliches Gewicht öffentlich zu machen, möchte ich dieses Gewicht in einem Bereich abspeichern der nur über User – Passwort zu erreichen ist.
Alle Anwender, die dieses System verwenden, sollen mit dem gleichen User-Passwort einsteigen können. Z.B. können so alle Teilnehmer einer Fett-Weg Aktion ihre Ergebnise untereinander diskutieren.

6:53 Uhr: Festlegung der umzusetzenden Komponenten

Ich möchte in einer Stunde fertig sein. Der Grund ist ganz einfach, ich sitze im Zug und in einer Stunde bin ich am Arbeitsort angekommen. Also kann ich nicht so viel umsetzen.
Was will ich also realisieren?

Modell für die Anwender

Jeder Anwender soll sich durch Name, Vorname und eine Beschreibung im System outen.
Also braucht es eine Datenbanktabelle mit folgendem Inhalt:

Modell für die Gewichtseingabe

Ich möchte ein Modell haben in dem die Gewichtsverläufe der Personen eingetragen werden kann.
Also eine Datenbanktabelle, die folgenden Tabelle zur Verfügung stellt:

Mit user_id kann eine Verknüpfung zum jeweilgen Anwender erfolgen. Damit können wir also die Relation Gewicht->Person erstellen.

Eingabemaske Create, Read, Update, Delete (CRUD)

Um das Gewicht zu verwalten möchte ich Create, Read, Update und Delete Eingabemasken haben.

Userverwaltung

Die Anwender sollen sich über ein User-Passwort am System anmelden können. Jeder Anwender erhält dieses Passwort vom Administrator zugestellt. Das ist also nicht Teil dieser 1h Übung.

7:06 Vorbereiten des Servers

So, genug Design. Jetzt gehts los!
Zuerst erstellen wir mal die Datenbanktabellen.

Anlegen der Datenbank

Wir wählen uns mit mysql -u root -p an unserer Datenbank an.
Dann erstellen wir eine neue Datenbank mit create database weights.

Localhost Einstellen

Ich bin auf meiner kleinen Entwicklungsmaschine tätig. Im /etc/hosts füge ich die neue Webapplikation weight hinzu.

Eclipse Projekt anlegen

In meinem Workspace (/home/roland/workspace) lege ich mit Eclipse ein neues PHP Projekt mit dem Namen weight an.

CakePHP Installieren

Ich habe Cake vor kurzem heruntergeladen.
Ich wechsle mit einer Konsole in das Verzeichnis in dem die Zip-Datei liegt (z.B. /home/roland/Downloads) und führe folgende Befehle aus:

Jetzt ist Cake soweit mal installiert.
Damit das Caching funktioniert, müssen noch die Rechte geradegebogen werden.

Jetzt muss noch der Security Salt in ~/workspace/weight/app/config/core.php verändert werden.
Suche die Zeile Configure::write(‘Security.salt’, und ändere den Wert um.

Datenbankkonfiguration innerhalb von Cake

Kopiere die Datei ~/workspace/weight/app/config/database.php.default nach ~/workspace/weight/app/config/database.php und füge die Zugangsdaten zu deiner Datenbank ein.

vhost konfigurieren

Bei Gentoo wird im /etc/apache2/vhosts.d ein neuer Virtual Host eingerichtet:

Wie ihr sehen könnt, wird meine Applikation in meinem Home-Verzeichnis im Eclipse Standard workspace abgelegt.
Nicht vergessen mit /etc/init.d/apache2 restart den Webserver neu starten.
Probiere kurz mal mit einem Webbrowser aus, ob die Applikation hochkommt und die Datenbank usw. erreicht werden kann.
Das kannst du mit http://weight/ als Adresse erreichen.

7:32 Uhr: Modelle erstellen

So, die Applikation ist installiert.
Gehe im Eclipse zu deinem (noch leeren) Projekt und drücke refresh. Nun können wir in Eclipse die notwendigen Dateien editieren.
Wechsle nun ins Verzeichnis /app/config/sql und erstelle die Datei create_tables.php
Füge dort die Create Statements, die ich oben definiert habe, ein.
Gehe in eine Konsole und wechsle in /app/config/sql Verzeichnis.
Erstelle die Datenbanktabellen mit dem Befehl mysql -u root -p weights < create_tables.sql.
Nun sind die Datenbanktabellen vorhanden.
Wechsle ins /app Verzeichnis und lege mit cake bake die Modelle, Controller und Views an.
Dazu kannst du dem Menü Folgen und die Modelle zuerst anlegen. Bitte achte darauf, dass du die Relation hasone und belongsto in den Modellen mit reinfummelst.

Testen der Applikation

Mit http://weight/users solltest du nun die CRUD Methoden für die Userverwaltung vorfinden.
Mit http://weight/weights solltest du in der Lage sein ein Gewicht für einen User anzulegen.

7:44Uhr: Security reinfummeln

Füge in der Datei /app/config/bootstrap.php den Eintrag Configure::load(‘config’); hinein.
Dann erstelle eine Datei in /app/config/config.php.
In diese Datei trägst du die folgende Zeilen ein:

Im /app/controllers/users_controller.php fügst du die folgende Funktion ein:

Das Gleiche fügst du im /app/controllers/weights_controller.php ein.
Ok, das ist Code-Replikation und sollte in die Basisklasse rein, aber meine Stunde ist gleich rum

7:53: Fertig

Das war knapp!
Ich hatte mich noch ein paarmal vertippt. Aber die Applikation läuft jetzt und kann angesprochen werden.
Natürlich sollte jetzt die Aufräumaktion kommen und alles schön verlinkt werden. Aber immerhin, in einer Stunde ist eine funktionsfähige Applikation und dieser Blogartikel entstanden.
Cool gelle?

Ähnliche Beiträge

Was ist die Infrastruktur und Systemkomponenten Anforderung?

Die Produktionsumgebung hat folgende Konfiguration:

• Apache Webserver (aktuelle Version)
• PHP 5.X
• MySQL (aktuelle Version)
• AMD 64 Bit Root-Server

Was für eine Entwicklungsumgebung verwende ich?

Ich habe zwei Rechner mit denen ich die meiste Zeit entwickle:

• Asus Eee 900 für Unterwegs. Da ich viel Reise, ist das Teil im Moment wirklich meine primäre Maschine Kaum zu glauben oder? Aber ich kann darauf wirklich arbeiten.
• Desktop Quad Core Pentium Maschine mit 4 GByte RAM, zwei Monitoren usw.

Was man hier sieht ist, dass ich von Hardwareseite aus schon einen ziemlichen Zoo beieinander habe und die Komponenten nicht nah an der Produktion sind.
Auf den Maschinen habe ich die gleichen Softwareumgebungen drauf wie auf der Produktion.
Das heisst, nicht ganz. Ich führe zuerst auf den Entwicklungsrechnern Softwareupdates durch. Wenn die funktionieren und unsere Komponenten immer noch gut zucken, wird die Produktion aktualisiert.
Eigentlich logisch oder?

Abnahmeumgebung

Damit die Produktionsumgebung nur dann umgestellt wird wenn sichergestellt ist, dass wir funktionsfähige Software einsetzen, haben wir einen weiteren Rechner für die Abnahmeumgebung aufgebaut.
Dieser Rechner ist ein AMD 64 bit Rechner. Damit ist die Prozessorarchitektur mit der des Root-Servers übereinstimmend.
Er hat auch das gleiche Betriebssystem mit den identischen Libraries wie der Produktionsrechner.

Was erreichen wir mit dieser Konfiguration?

Die Entwicklungsrechner verwenden identische Software wie in der Produktion.
Das hat folgende Vorteile:

• Wir entwickeln mit den gleichen Softwarepaketen wie in der Produktion. (Apache, PHP, MySQL usw.)
• Die Konfiguration des Webservers (httpd.conf usw.) können wir schon in der Entwicklung üben. Die Unterschiede zur Produktion sind relativ gering und wir sind für die Migration trainiert.
• Upgrades können auf der Entwicklungsmaschine ausprobiert werden.
• Ich kann immer und überall mit meinem kleinen Netbook entwickeln. Das hat sich schon oft als Vorteil erwiesen, falls ein paar kleinenere Anfragen von Kunden schnell behandelt werden mussten. Ich war damit nicht ortsgebunden.

Nachteile dieser Entwicklungsumgebung

Wir haben einen Zoo an Rechnern rumstehen.
Wenn wir genug Geld hätten, könnten wir uns einen Typ von Hardware kaufen und betreiben. Das würde viel Aufwand und somit Geld sparen.
Mein Asus Eee 900 ist eine nette Maschine, aber es ist und bleibt ein Zwerg. Eigentlich ist es nicht vernünftig so eine kleine Maschine für diesen Einsatzbereich zu verwenden.
Aber wie hat schon einer meiner Profs gesagt: “Alle wünschen sich die besten Studenten, aber wir haben nur sie!”.
Ich bin auch ein grosser Bastler und deshalb habe ich halt im Moment die kleine Maschine.
Dirk hat mir eine lange Mail geschrieben in der er ausführt, dass ich auf einen leichteren Webserver umsteigen sollte.
Damit könnte ich wichtige Systemresourcen einsparen und mein Asus wäre dann wohl etwas schneller.
Doch hierzu kann ich nur sagen, dass es mir wichtig ist mit dem Webserver zu arbeiten, den ich später auch in der Produktion einsetze. Spezielle Flags, die ich Beispielsweise für BuddyPress benötige, möchte ich gleich bei mir auf der Maschine ausprobieren und optimieren können.

Fazit

Es ist wichtig mindestens die Abnahmetestumgebung mit der Produktionsumgebung gleich aufzusetzen.
Wenn möglich, sollte identische Hard- und Softwarekonfigurationen eingesetzt werden.
Häufig ist dies aus Kostengründen nicht möglich. Dann muss man wenigstens versuchen so nah wie möglich an die Produktionsumgebung heranzukommen.
Bei der Entwicklungsumgebung sollte wenigstens der gleiche Softwarestack eingesetzt werden. Die Entwickler arbeiten dann mit den gleichen Tools, die später in der Produktion eingesetzt werden. Somit können Unterschiede und Problemstellungen schon während der Entwicklung erkannt werden.
Ein Mix von Komponenten sollte, wenn möglich, immer vermieden werden.

Ähnliche Beiträge

Das Verzeichnis /etc/apache2/sites-available

In diesem Verzeichnis findest du nach der Basisinstallation von apache2 die default Datei.

Darin ist der Standard Webserver (/var/www) definiert. Wenn du also deinen localhost im Webbrowser aufrufst, wirst du die Standard Startseite vorfinden.
Kopiere diese Datei und benenne die Kopie z.B. blog.
Editiere die Datei blog und füge folgende Informationen hinzu:

Diese Datei beinhaltet somit die identischen Definitionen, wie bei den Installationen unter Gentoo.

/etc/apache2/sites-enabled Link setzen

Damit der Apache unter Ubuntu die neue Konfiguration findet, musst du in /etc/apache2/sites-enabled noch einen Link auf unsere neue Konfiguration setzen.
Also:

rewrite Mode aktivieren

Mit dem Befehl:

wird das rewrite Modul im Apache freigeschalten.
Dieses Modul wird benötigt damit WordPress seine URLs umbenennen kann.

Hast du auch libapache2-mod-auth-mysql installiert?

Ich hatte ein bisschen Startschwierigkeiten, da dass Paket libapache2-mod-auth-mysql nicht installiert war. Mit diesem Modul wird erreicht, dass wir uns an der MySql Datenbank anbinden können.
Also installiere es mit

Die restlichen Installationsabläufe für BuddyPress kannst du im Artikel Eine BuddyPress Installation durchführen nachlesen.

Ähnliche Beiträge

Im Betrieb für eine Blogplattform mit mehreren hundert Blogs wäre das nicht sinnvoll weil:

• Jeder neue Blog würde die vhost Konfiguration verändern
• Hoher Administrationsaufwand
• Risiken, da mehrere Dateien zeitgleich angepasst werden müssen
• Hohe Server-Down-Time da bei jedem neuen Blog der Apache kurz neu gestartet werden muss

Also ziemlich unbrauchbar gelle?

Wildcards für die Konfiguration

Die Lösung ist wirklich einfach.

Anstatt z.B. folgende Konfiguration zu verwenden:

Kannst du mit einem Wildcard erzeugen, dass alle Subdomänen auf karle.domainname geleitet werden.

Der Vorteil dieser Lösung ist klar, dass alle Subdomänen ohne einen eigenen Eintrag für WordPress MU richtig verwaltet werden.

Der Nachteil dieser Lösung besteht darin, dass du keine absolute Kontrolle über deine Subdomänen hast. Ein böser Administrator kann dir jetzt beliebig viele Subdomänen anlegen und der Apache wird alle brav verwalten.

Ähnliche Beiträge