CakePHP unter Sites in Mac OS X

Wie schon in dem vorherigen Post angekündigt, bin ich noch auf ein paar Problem gestoßen, als ich CakePHP versucht habe ans Laufen zu bringen. Die Lösung brachte dann folgender Link:

Mod_rewrite (CakePHP routing functionality) forbidden after Snow Leopard upgrade

Unter Mac OS X gibt es zwei Verzeichnisse, über die Webseiten freigegeben werden können:

/Libary/WebServer/Documents/
~/Sites/

Bei dem letztern Verzeichnis handelt es sich um eins innerhalb des Userverzeichnisses (erkennbar an ~). Innerhalb von Sites habe ich nun CakePHP entpackt. Damit CakePHP das Userverzeichnis richtig erkennt, sind noch 2 Schritte notwendig:

In /etc/apache2/users/{user}.conf muß folgendes stehen:

<Directory "/Users/{user}/Sites/">
  Options Indexes MultiViews FollowSymlinks
  AllowOverride all
  Order allow,deny
  Allow from all
</Directory>

Zusätzlich müssen die drei .htaccess Dateien, die CakePHP verwendet (im CakePHP root Verzeichnis, /app/ und /app/webroot/ um eine Angabe zu RewriteBase ergänzt werden. Z.B. sieht meine root .htaccess Datei dann folgendermaßen aus:

<IfModule mod_rewrite.c>
  RewriteEngine on
  RewriteBase /~{user}/cakephp/
  RewriteRule ^$ app/webroot/ [L]
  RewriteRule (.*) app/webroot/$1 [L]
</IfModule>

Hinzufügen zu PATH in Mac OS X

Auch unter Mac OS X kommt man ab und zu in die Verlegenheit, etwas zu PATH hinzuzufügen. Um zu prüfen, was sich aktuell in PATH befindet, gibt man in der Konsole folgendes ein:

echo $PATH

Dieser Befehl zeigt bei mir /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin: an. Um z.B. mysql und CakePHP ohne die Pfade auf der Konsole aufrufen zu können, habe ich eine Datei .profile mit folgendem Inhalt in meinem Userverzeichnis erzeugt:

PATH=$PATH\:~/Sites/cakephp/cake/console;
PATH=$PATH\:/usr/local/mysql/bin;

Wie man dem Pfad für CakePHP entnehmen kann, habe ich CakePHP in meinem Userverzeichnis entpackt. Diese Entscheidung hat noch ein paar zusätzliche Konsequenzen, über die ich in einem späteren Post schreiben werde.

Windows 7 64 Bit, der Oracle Instantclient und PHP

Leider bringt ein 64 Bit System an einigen Stellen einen höheren Konfigurationsaufwand mit sich. Das habe ich heute mal wieder sehr deutlich gemerkt.

Meine Ausgangskonfiguration war Windows 7 mit einer 64 Bit Java Version und Oracle SQL Developer in der 64 Bit Version. Ein Oracle Instantclient (Version 11.2) war auch in der 64 Bit Version installiert. Den Instantclient benötigt man, um auf eine entfernte Oracle Datenbank zuzugreifen. Diese Konfiguration funktionierte einwandfrei.

Heute habe ich es in Angriff genommen, XAMPP zu installieren. Die aktuelle Version von XAMPP war schnell heruntergeladen. Da es XAMPP aktuell nur in einer 32 Bit Version gibt, ahnte ich schon, daß das Zusammenspiel von PHP und Oracle nicht so einfach funktioniert. Um die Oracle Extension oci8 (php_oci8.dll) zu aktivieren, muß bei dem entsprechenden Eintrag in der php.ini das Semikolon entfernt werden. Nach einem Neustart des Apache Webservers meldete sich dieser dann aber mit eine Fehlermeldung: Der Prozedureinsprungpunkt von oci.dll wurde nicht gefunden. Folglich wurde die Oracle Extension nicht geladen. Nach einigen erfolglosen Versuchen PHP mit Oracle ans Laufen zu kriegen, installierte ich den Instantclient in der Version 10.3 als 32 Bit Version. Da ich mich mit einer 10gR2 Oracle Datenbank verbinden wollte, sollte dieser auch funktionieren. Erstaunlicherweise funktionierte er auch mit dem SQL Developer. Nach einem Neustart des Apache erschien aber wieder eine Fehlermeldung. Eine Datei, die nach ich nach einer kurzen Google Suche dem .NET Framework 1.1 zuordnen konnte, sollte fehlen. Das Ergebnis war, daß die Oracle Extension wieder nicht geladen wurde. Als letzten Versuch installierte ich den neuesten Instantclient, den ich ja schon vorher benutzt hatte. Nur jetzt in der 32 Bit Version. Nach einem Neustart des Apache wurde die Oracle Extension in PHP endlich richtig geladen.

Fazit: Eine 32 Bit PHP Version mit der Oracle Extension oci8 funktioniert anscheinend nur mit einem 32 Bit Oracle Instantclient. Der Oracle SQL Developer in der 64 Bit Version funktioniert aber mit einem 32 Bit Oracle Instantclient.

Anpassung GRUB_GFXMODE in Grub2

Auf meinem Sony Vaio Z21 habe ich Ubuntu 9.10 64 Bit installiert. Die aktuelle Ubuntu Version installiert automatisch Grub2. Als Einstieg in die Konfiguration von Grub2 bietet sich Grub 2 Basics Tutorials & Tips an.

Leider funktionierte bei mir die Anpassung der Auflösung des Grub Menüs nicht. Egal, welchen Wert ich in /etc/default/grub unter GRUB_GFXMODE angegeben habe, nach einem Update der Grub Konfiguration mit

sudo update-grub2

blieb die Einstellung bei 640x480. In /etc/default/grub werden Default Werte eingetragen. Die Einstellungen nach dem Update kann man sich unter der Datei /boot/grub/grub.cfg anschauen. Die Datei entspricht im Prinzip der alten /boot/grub/menu.lst. Allerdings ist sie schreibgeschützt und sollte nie direkt sondern nur über die Konfigurationsdateien bearbeitet werden.

Da der Eintrag in /etc/default/grub nicht die gewünschte Wirkung hatte, habe ich mir angeschaut, wo dieser Default Wert denn ausgelesen wird. In der /etc/grub.d/00_header findet sich folgender Eintrag:

if [ "x${GRUB_GFXMODE}" = "x" ] ; then GRUB_GFXMODE=640x480 ; fi

Die Variable ${GRUB_GFXMODE} sollte also richtig gesetzt werden. Schaut man sich die Datei /etc/grub.d/00_header weiter an, findet sich dort nur ein Verweis auf den gfxmode:

set gfxmode=640x480

Die Variable wird also gar nicht ausgelesen. Um nun mein Menü an die richtige Auflösung anzupassen, habe ich die Zeile wie folgt geändert

set gfxmode=${GRUB_GFXMODE}

Anschließend kann das Boot Menü in gewünschter Auflösung bewundert werden.

Installation von OpenSolaris 2008.05

Mit diesem ersten Post möchte ich die Installation von OpenSolaris auf einem alten Dimension 4550 beschreiben. Der PC beherbert bereits Windows XP und Sidux - ein Debian Linux. Über Sidux befindet sich der Bootmanager GRUB im MBR. Diese Ausgangskonfiguration sollte beibehalten werden.

Live Betrieb

OpenSolaris kann man wie viele Linux Distributionen auch ohne Risiko über eine Live CD (oder in meinem Fall einer DVD aus dem aktuellen Sonderheft der c't) testen. Nach dem Booten stellte ich überrascht fest, daß der Treiber für die WLAN Karte bereits integriert war.

Bei der WLAN-Karte handelt es sich um eine MSI Karte, die den Atheros Treiber benutzt. Ich habe diese Karte bereits erfolgreich unter verschiedenen Linux Distributionen und unter PC-BSD - einem Free BSD betrieben.

Als nächstes startete ich das "Device Driver Utility" (in der Live DVD ist dies über ein Desktop Icon zu erreichen, ansonsten über System->Systemverwaltung). Diese Tool zeigt an, für welche Hardware OpenSolaris Treiber hat. Für meinen PC zeigte mir das Tool keine Treiber für die Soundkarte - eine Soundblaster Audigy 2 und die TV Karte - eine analoge WinTV Karte an.

Die Soundkarte kann mit dem Treiber von OpenSound arbeiten und für die TV Karte habe ich zumindest eine Webseite gefunden, die den Brooktree Treiber von Linux auf Solaris portiert. Ausprobiert habe ich die Installation der TV Karte allerdings noch nicht.

Installation

Für OpenSolaris hatte ich eine 40 GB große, primäre Partition als Zielverzeichnis ausgewählt. Nach dem Start der Installation über das Desktop Icon im Live Betrieb, ließ mich der Installer diese Partition auswählen. Nach der Eingabe der erforderlichen Daten brach der Installer aber jedes Mal ab mit der Meldung, daß mit der Partition etwas nicht in Ordnung sei. Nach einer kurzen Suche im Internet stellte sich heraus, daß es sich hier um einen Bug des Installers handelt. Die Zielpartition muß wohl bereits vor der Installation im richtigen Format Solaris2 formatiert sein. Diese Format läßt sich unglücklicherweise über GParted, welches ich zur Partitionierung verwendete, nicht auswählen. Also mußte ich über die Live DVD das Kommandozeilen Tool format benutzen. Über die Eingabe folgender Befehle (als root) ließ sich die Partition richtig formatieren:

• format -e
• fdisk
• Auswahl der richtigen Partition und dem Format Solaris2

Wichtiger Hinweis: das Formatieren zerstörte das bereits vorhandenes GRUB im MBR! Auch wird beim Starten des Installers das root Paßwort auf das in der Installation angegebene geändert und ist nicht mehr das für den Live Betrieb vorgegebene.

Anschließend ließ sich die Installation ohne Probleme durchführen (sieht man von der erforderlichen Neuinstallation von GRUB ab). Über meine ersten Erfahrungen mit OpenSolaris werde ich in einem nächsten Blog schreiben.