[Quicktip] Apache Ant sshexec Befehle per && kombinieren

Wenn man in einem Apache Ant Build Script bei einem sshexec mehrere Befehle aneinanderreihen möchte, dann kann man nicht wie von Linux gewohnt mittels “&&” konkatinieren – Ant wirft dann einen Fehler, dass ein & nicht von einem & gefolgt werden darf. Die Lösung ist sehr banal:

<sshexec host=”${host.name}” trust=”true” username=”${user}” password=”${pw}” keyfile=”${optional.keypair}” command=”command1 &amp;&amp; command2  &amp; &amp; command3″/>

[php] Oracle XE und Doctrine/Symfony funktioniert nicht

Kurzer Warnhinweis: ich bin kein Freund von Oracle und finde es zumindest im Bezug auf php relativ kompliziert in der Einrichtung. Dieser Artikel besteht daher zum Teil aus gefährlichem Halbwissen – falls ich also Blödsinn erzähle, korrigiert mich bitte per Kommentar oder Mail 😉

Wenn ihr ein Symfony 2 Projekt mit einer Oracle XE Datenbank verbindet und dann folgende Fehler auftauchen – z.B. bei einem app/console doctrine:schema:create :

[Doctrine\ORM\Tools\ToolsException]
Schema-Tool failed with Error '' while executing DDL: CREATE TABLE Foo (id NUMBER(10) NOT NULL, name VARCHAR2(100) NOT NULL, PRIMARY KEY(id))
[Doctrine\DBAL\Driver\OCI8\OCI8Exception]

Dann müsst ihr folgende Dinge richtig machen:

Eure Konfiguration sollte so aussehen:

parameters:
    database_driver:   oci8
    database_host:     localhost
    database_port:     1521
    database_name:     xe
    database_user:     dbuser
    database_password: dbpass

Beim Treiber könnte man auch pdo_oci verwenden – was auch in vielen Tutorials empfohlen wird. Das Problem ist jedoch, dass dieser Treiber sehr instabil ist. Daher einfach oci8 verwenden 😉

Hostname und Port sollten klar sein, der Datenbankname ist bei einem Oracle XE grundsätzlich “xe”. Was ihr dann innerhalb eures Oracle Clients seht, was sich ähnlich wie eine DB in MySQL anfühlt, ist in der Oracle Sprachwelt ein Schema. Das Schema ist in der Regel gleich dem DB-Nutzernamen.

So, dass zu den Einstellungen. Der fiese Part, durch den es zum oben genannten Fehler kommen kann, ist, dass man noch zwei Umgebungsvariablen auf der Shell und im Apachen setzen muss, damit die Verbindung von Symfony zu Oracle korrekt läuft:

export ORACLE_HOME=/u01/app/oracle/product/11.2.0/xe
export LD_LIBRARY_PATH=/usr/local/lib

Diese beiden Zeilen (natürlich mit den jeweils korrekten Pfaden für euer System) packt ihr entweder in die .bashrc des jeweiligen Users oder in die envvars Datei vom Apachen (diese Angaben beziehen sich primär auf ein Standard Debian, wie es in anderen Distributionen aussieht weiß ich nicht!).

Falls ihr die Variablen für den Apachen setzen müsst, nicht vergessen, diesen mittels Neustart dazu zu bewegen, diese auch zu laden 😉

Nun sollte die Verbindung laufen.

[Quicktip] Starten von Apache httpd unter Mac OSX nur als root möglich

Wenn ihr Apache httpd per Homebrew auf eurem Mac installiert und ihn als normalen User starten möchtet, dann kann es sein, dass ihr folgende Fehlermeldung erhaltet:

(13)Permission denied: make_sock: could not bind to address [::]:80

Diese Meldung hat einen einfachen Hintergrund: unter OSX kann nur root die Ports mit den Nummern kleiner als 1024 belegen (das scheint im Unix Umfeld allgemein so zu sein). Und nichts anderes sagt diese Meldung aus. Ändert also in eurer http.conf (/usr/local/etc/apache2/httpd.conf) den Parameter “Listen 80” auf z.b. “Listen 8080” und ändert ggf. noch die Listening Ports für Virtual Hosts, falls ihr welche eingerichtet habt. Anschließend sollte Apache auch von einem nicht-root User gestartet werden können. Falls ihr den Apachen vorher bereits als root gestartet habt, denkt bitte dran, alle Logfiles zu löschen oder die Schreibrechte anzupassen, da der Apache sonst nicht starten wird…

GeekTool Script für die Statusanzeige von Prozessen, wie z.B. httpd oder mysqld

Wenn man auf seinem OSX Desktop immer gleich sehen möchte, ob Services, wie z.B. der Apache Webserver httpd oder der MySQL Server mysqld laufen, kann man folgendes GeekTool Script verwenden:

#!/bin/bash
if [ "$(ps -Ac | grep httpd)" != "" ]; then httpServ="running";
else httpServ="offline"; fi
if [ "$(ps -Ac | grep mysqld)" != "" ]; then sqlServ="running";
else sqlServ="offline"; fi
echo "HTTP : $httpServ";
echo "SQL : $sqlServ";

Das Beispiel kann man nach der Vorlage beliebig für andere Prozesse erweitern. Per GeekTool eingebunden sieht das dann folgendermaßen aus:

Wenn der Service nicht aktiv ist, steht an Stelle von running “offline”…

[Quicktip] cgi Scripte mit Plesk

Am letzten Wochenende habe ich das erste mal in meinem Leben ein cgi Script verwendet. In Zeiten von php – welches im Prinzip auch cgi ist – braucht man derartige Tools einfach nicht mehr so wirklich. Der Vorteil ist aber ganz klar: cgi Programme sind schnell – sofern wir von c oder c++ sprechen. Es wird wohl kein php, ruby, python oder perl Script geben, welches mit einem sauber in C aufgesetzten cgi mithalten kann. Dafür hat man aber den Aufwand, dass man erst kompilieren muss, um das Programm verwenden zu können. Natürlich kann man aber auch alle weiteren Script- oder kompilierten Sprachen als cgi verwenden. Bei interpretierten Sprachen ist dies aber deutlich langsamer, als wenn man diese per Apache Modul betreibt, da sonst bei jedem Aufruf erst einmal der Interpreter initialisiert werden muss.

Egal, ich war dabei, cgit (ein grafisches Frontend für lokale git-Repositories) aufzusetzen – da kommt auch nochmal ein Blogeintrag zu. Nachdem ich mit der Compilierung und Installation durch war, legte ich in Plesk die Domain an, aktivierte in den Domaineinstellungen, dass cgi-Scripte unterstützt werden sollen – und dann stand ich da…

Einfach in den httpdocs Ordner der Domain werfen brachte nichts, dann war die Datei als Download verfügbar. Mir fiel dann schnell der cgi-bin Ordner auf, der sich in der Ordnerstruktur neben den httpdocs und httpsdocs Ordnern befindet. Nur wie ruft man diese auf? Nach etwas Probierarbeit kam ich dann drauf:

http://www.domain.de/cgi-bin/script.cgi

Eigentlich ganz einfach, aber naja 😉

Nachdem ich das herausgefunden hatte, lief mein Tool natürlich trotzdem nicht. Über die Console lief es wunderbar, nur eben nicht im Browser. Dann wurde mir klar, dass das nur noch mit Benutzerrechten zu tun haben kann – und so war es auch. Es ist wichtig (zumindest wenn man mit Plesk arbeitet), dass das cgi Script der Gruppe “psacln” gehört. Außerdem habe ich auch den Benutzer der Domain als Inhaber der Datei festgelegt, was aber wohl nicht zwingend notwendig ist.