Aus dem Leben eines Szlauszafs (Entries tagged as PHP)

Digitale Ausstellungsstücke

thh@inter.net (Thomas Hochstein) — Mon, 10 Jan 2011 19:28:00 +0100

Wer (digitale) Fotos - in welcher Menge, Häufigkeit und Qualität auch immer - macht, der kennt das Problem, sie online verfügbar zu machen. Gut, das eigentliche Problem ist die Überwindung der eigenen Faulheit und das Auswählen, Sortieren, Umbenennen und ggf. Kommentieren einmal wirklich anzugehen, aber man möchte dazu auch die entsprechende, möglichst einfach verwendbare, aber alle notwendigen Funktionen bietende Software haben.

Man kann dazu Web-2.0-Dienste wie flickr nutzen, aber nicht jeder möchte das, sei es, daß man solchen Diensten generell nicht traut und/oder die Software lieber selbst installieren möchte, sei es, daß man am “Sharing” von Fotos gar nicht interessiert ist, sondern den Zugriff potentiell nur wenigen ermöglichen möchte. Insoweit habe ich dann schon einiges durch: mehr schlecht als recht selbst gebaute Implementationen für die Webseiten meiner Hilfsorganisation oder einer Newsgroup (seit ~ 2002), dann für meine private Homepage (ebenfalls seit ~ 2002) mig, ein sehr einfaches Script (auch deshalb, weil man von den Platzhirschen wie Gallery nicht viel Gutes über die Sicherheit hörte), und seit Anfang 2008 (nach dem Erhalt meiner neuen Kamera Weihnachten 2007) auch eine Gallery-2-Instanz, mit der ich allerdings nie so recht angefreundet hatte (zumal bis zu einem Kurzurlaub 2008 zurück noch Bilder zum Sortieren und Hochladen im Backlog liegen - siehe die einleitenden Worte zu diesem Artikel ). Während ich jetzt darüber nachdachte, ob sich nicht ein Update auf Gallery 3 anbietet, bekam ich den weisen Rat, mir doch einmal piwigo anzusehen.

Und das hat mich überzeugt. Zumindest dann, wenn man eine Fotogalerie-Applikation nur für sich selbst ohne ausgefeiltes Benutzermanagement für mehrere Fotografen braucht (und wie oft teilt man sich eine Galerie wirklich zu mehreren?), ist piwigo eine tolle Lösung. Installation und Konfiguration sind einfach (Voraussetzungen: PHP und mySQL), wenn man das Prinzip einmal begriffen hat, der Upload ist übers Web wie auch einfach per FTP möglich, Thumbnails werden erstellt, Benutzer können in vorgegebene Rechtegruppen (Gast, Bekannter, Freund, Familie, ...) oder in Nutzergruppen eingeteilt werden, und für Alben bzw. Fotos lassen sich dann die entsprechenden Zugriffsrechte setzen. Fotos lassen sich nicht nur in Alben, sondern in Kategorien zusammenfassen und zugleich noch beliebig taggen; der Benutzer kann sich die Fotos nach Kategorien oder Tags oder nach dem Kalender oder sonstwie anzeigen lassen, bekommt dabei aber immer nur die Fotos oder Kategorien zu sehen, für die er entsprechende Rechte hat. Außerdem gibt es eine Reihe vorgefertigter, recht ansehnlicher Skins.

Mir gefällt’s jedenfalls, und ich habe den heutigen Tag dann im wesentlichen dazu genutzt, aus den drei oder vier vorgenannten Quellen der letzten 10 Jahre die dort vorhandenen Fotos in einer Galerie zusammenzuführen und dann den Rest zu löschen. So gesehen also wie gestern ein weiterer Tag des Räumens und Sortierens.

Mantis Bug Tracker und Mantis Graphs 1.0

thh@inter.net (Thomas Hochstein) — Fri, 14 May 2010 18:14:00 +0200

Mantis (aktuell in der Version 1.2.1) ist ein ganz netter Bugtracker, also ein Ticketsystem (Fallbearbeitungssystem) für die Softwareentwicklung, dessen auffallendstes Manko allerdings die unterirdische Qualität der Dokumentation (weitgehend schlicht nicht vorhanden, ansonsten grob unvollständig oder weit veraltet) ist. *seufz*

“Mantis Graphs 1.0” ist ein Plugin für Mantis, das graphische Darstellungen ermöglicht, und ich habe heute längere Zeit damit verbracht, es in Betrieb zu setzen, nachdem es immer nur “unable to read/find font” von sich geben wollte. Einer der ersten Schritte war die Installation der msttcorefonts (aptitude install ttf-mscorefonts-installer), aber das genügte nicht. Längeres Debugging mit eingestreuten Statements im Quellcode ergab schließlich, daß Mantis weder das passende Font-Verzeichnis erkennen noch - bei expliziter Angabe des Verzeichnisses in der Konfiguration mit $g_system_font_folder - die Fontdatei laden wollte. Die Lösung dafür fand sich in der Dokumentation der PHP-Funktion file_exists(): diese liefert auch dann false zurück, wenn auf die entsprechende Datei aufgrund von safe_mode-Restriktionen nicht zugegriffen werden kann ...

Und natürlich ist das der Fall: das Font-Verzeichnis - bpw. /usr/share/fonts/truetype/msttcorefonts/ - gehört root, und die Font-Dateien auch. Jedenfalls ist Owner dieser Dateien niemals der Webserver oder der Benutzer, unter dessen Kennung die PHP-Scripts dank su_php o.ä. ausgeführt werden. *brummel*

Es bleibt demnach nur der Verzicht auf die Grafiken oder die Deaktivierung von safe_mode (für Mantis).

Apache 2.x, php-cgi, mod_suphp und "No input file specified!"

thh@inter.net (Thomas Hochstein) — Fri, 17 Apr 2009 17:03:00 +0200

Im Zusammenhang mit dem Update einer Maschine auf Debian Lenny bin ich auf das seltsame Phänomen einer - offensichtlich von PHP erzeugten - Fehlermedlung gestoßen: der Aufruf einer bestimmten Webseite (respektive des PHP-Scripts, das diese erzeugen sollte) ergibt nur die Meldung “No input file specified!”. Google führt einen zu diversen Threads, die sich vor allem um die Konfiguration des richtigen Handlers für die Interpretation von PHP-Scripts und um hilflose Fragen von Benutzern, die eigentlich nur ein fertiges Paket installieren wollten und nun nicht mehr weiter wissen, drehen. Erst ein alter Blogeintrag in ixs’ Vodkamelone (nein, das hat nichts mit einem Kamel Nr. Eins zu tun!) von 2005 half mir auf die Sprünge.

Der Grund dieser Fehlermeldung ist offenbar ein ganz seltsames Zusammenspiel der Ausführung von PHP als mod_suphp, d.h. der CGI-Version von PHP in der Weise, daß Scripts unter den Rechten des jeweiligen Benutzers ausgeführt werden, mit der Vergabe von Datei- und Verzeichnisrechten. Die oben genannten Fehlermeldung tritt demnach genau dann auf, wenn zwar der Webserver auf die Datei bzw. ihr Verzeichnis zugreifen, sie also “finden” kann, der Benutzer selbst aber nicht. Dann findet der Webserver - unter der UID www-data - das Script, erkennt es, ruft den Handler auf, der als suid root installiert ist, sich Root-Rechte verschafft, damit auf die UID des Benutzers wechselt und dann mit diesen Rechten den PHP-Interpreter aufruft, um ihn das Script ausführen zu lassen. Dieser PHP-Prozess, der jetzt aber im Kontext des Benutzers läuft, kann dann selbst auf das entsprechende Verzeichnis nicht mehr zugreifen, das Script also auch nicht ausführen, und reagiert dann mit der obigen Fehlermeldung, denn er findet ja keine Datei, die er ausführen könnte.

Vielleicht hilfts ja jemanden, wenn ich ixs’ Analyse her noch einmal wiedergebe und verlinke.