Das “REST API Module” ist im Standard-Umfang der Gallery enthalten und bietet eine komfortable Möglichkeit, von außen mit der Gallery zu kommunizieren. Funktionen für das “Entgegennehmen” von hochgeladenen Dateien existieren bereits, so dass meine Aufgabe nun darin bestand, einen für mich nutzbaren Client zu schreiben, der die von mir benötigte Funktion des galleryadd-Skripts ablösen sollte.

Also schrieb ich in PHP ein Upload-Skript: gallery3-upload-1.00.txt (muss in .php umbenannt werden)

Es besteht aus zwei Funktionen, die zusammen arbeiten. Darunter befinden sich die Site-spezifische Konfiguration und der eigentliche Aufruf.

$galleryHost = "gallery.site";            // Gallery-URL
$galleryPort = 80;                        // HTTP-Port
$apiKey      = "xxx";                     // API-Key eines Gallery-Users
$itemID      = 1;                         // Album-ItemID

$importDir   = "/data/upload";    // Quell-Verzeichnis
$archiveDir  = "/data/archive";   // Archiv-Verzeichnis (optional)

processFiles($galleryHost, $galleryPort, $itemID,
        $apiKey, $importDir, $archiveDir);

Das Skript setzt voraus, dass die Gallery sich im Stammverzeichnis des Servers befindet und nicht als Unterordner (z.B. “/gallery/”). Falls jemand diese Erweiterung benötigt, möge er/sie sich bitte melden.

Die Album-ItemID habe ich kurzerhand direkt in der MySQL-Datenbank in der Tabelle “items” nachgesehen (Filter auf Datensätze mit “type” = “album”). Den API-Key kann man in der Administrationsoberfläche den User-Details entnehmen. Wichtig ist, dass der User des verwendeten API-Keys auch entsprechende Schreibrechte auf das Album besitzt.

Das Skript überträgt alle Dateien aus dem Ordner $importDir, es findet keine Filterung auf Dateitypen statt. Die Angabe von $archiveDir ist optional. Statt die hochgeladenen Bilder aus dem Ordner zu löschen, lege ich sie lieber in einem separaten Archiv ab. Ist diese Form des Backups nicht gewünscht, kann man $archiveDir auf NULL setzen. ACHTUNG: In diesem Fall muss man sich selbst darum kümmern, die abgearbeiteten Dateien aus dem $importDir zu entfernen!

Man kann diese PHP-Datei durch require/include zwar innerhalb einer anderen PHP-Anwendung verwenden, ich rufe sie stattdessen jedoch direkt über die Kommandozeile oder über einen Cronjob auf.

Kommandozeile:

/usr/bin/php /pfad/zum/skript/gallery3-upload.php

Cronjob (alle 10 Minuten):

*/10 * * * *    /usr/bin/php /skriptpfad/gallery3-upload.php > /dev/null 2>&1

Feedback ist herzlich willkommen.

Die genaue Fehlermeldung war “Error: Device 0 (vif) could not be connected. Hotplug scripts not working.“. In der Datei “/var/log/xen/xen-hotplug.log” war außerdem zu lesen: “/etc/xen/scripts/xen-hotplug-cleanup: line 24: [: !=: unary operator expected".

Anscheinend ist an der entsprechenden Stelle im genannten Skript nun eine Variable leer, die eigentlich gefüllt sein sollte. Das Ergebnis ist nun jedoch ungültig, woraufhin das Skript auf die Nase fällt. Bis Novell ein Update zur Verfügung stellt, um den Fehler zu beheben (ich hoffe, dass Novell die Lösung beisteuert) kann man sich mit einem Workaround helfen, der darin besteht, die Zeilen 24 und 25 im Skript "/etc/xen/scripts/xen-hotplug-cleanup" anzupassen:

aus:

if [ $(xenstore-read "$vm_dev" 2>/dev/null) != "" ]
&& [ "${path_array[1]}” = “vbd” ]; then

wird:

if [ x$(xenstore-read "$vm_dev" 2>/dev/null) != "x" ]
&& [ x"${path_array[1]}" = "xvbd" ]; then

Damit sollte das Problem umgangen werden können. Bisher funktioniert's bei mir ohne Probleme.

UPDATE (20.07.2010):

Meine Xen-Umgebung lief in den letzten Tagen ziemlich wackelig. Das Starten von domU's war möglich, wenn ich allerdings eine der Instanzen stoppen oder neu starten musste, befand sie sich für ca. eine Minute im "paused"-Zustand und brach dann ab. Die Meldung war (wie gehabt) "Error: Device 0 (vif) could not be connected. Hotplug scripts not working.".

Ich habe Foren durchsucht, Manuals gelesen und diverse Mailinglisten umgegraben, doch zunächst schien nichts zu helfen, was auch immer ich versuchte.

Nun habe ich endlich das Problem für mich isoliert und "vorerst" behoben. SLES11SP1 nutzt in der Standardauslieferung für Xen das Kernelpaket "kernel-xen-2.6.32.12-0.7.1". Damit lief alles reibungslos. Dann kam vor einigen Tagen ein Kernel-Patch heraus, Version "kernel-xen-2.6.32.13-0.4.1". Und hiermit fing - wie anfangs bereits vermutet - der ganze Ärger an. Ich habe mittlerweile die Version wieder auf den Originalzustand zurück gedreht und schon funktioniert alles wieder reibungslos. Ich hatte war vor ein paar Tagen schon probiert, den Kernel zurück zu drehen, doch ich hatte auf meinem Server noch ein weiteres Problem, dass mit dem Booten von Software-RAID-Partitionen zusammen hing. Das konnte ich beheben, indem ich "mkinitrd-2.5.10-4.6.1" installierte. Ich glaube aber nicht, dass es sich hierbei um ein grundsätzliches Problem handelt... aber wer weiß. :-)