Gespeichert von Frank Pfabigan am
7 Minuten, 34 Sekunden ∅ Lesezeit @ 225 WPM

Nicht nur bei Drupal rückt Composer immer mehr in die Liste der must-have Tools zur Verwaltung von externen PHP-Libraries. Auch andere CMS, Webshops wie z.B. Magento und andere Anwendungen auf dem Webserver nutzen mehr und mehr zur Installation und Update der "Bestandteile" der Anwendung das Tool Composer.

Was ist Composer?

Composer ist ein PHP-Script im Format "phar", das sich um die Abhängigkeiten von PHP-basierten Lösungen kümmert, diese auflöst, selbständig die benötigten weiteren Dinge herunterlädt und insgesamt für die übergeordnete Anwendung bereitstellt.

Da es natürlich überhaupt keinen Sinn macht, das Rad immer wieder neu zu erfinden, nutzen Programmierer zur Erstellung von Web-Anwendungen sog. PHP-Packages, die eine ganz bestimmte Teilaufgabe lösen. Wie z.B. einen RSS-Feed bereitstellen, die Verbindung zu einer Datenbank bereitstellen uvm. Diese PHP-Packages selbst sind erprobt und beschleunigen durch ihre Nutzung den Entwicklungsprozess, da dieser Code eben nicht nochmal programmiert werden muss.

Nun ist es aber so, daß diese PHP-Packages auch von anderen PHP-Packages abhängen, um funktionieren zu können. Außerdem wird jedes einzelne PHP Package natürlich auch ständig weiterentwickelt, um noch sicherer und noch effizienter zu sein.

Indem nun also ein ganz bestimmtes PHP-Package in einer Anwendung genutzt werden soll, eröffnet sich ein schier unüberschaubares Netzwerk an Abhängigkeiten der PHP-Packages untereinander.

Jedes Package trägt in sich die Information, welche anderen Packages es selbst in welcher Version benötigt, in einer Datei namens composer.json, die eine einfache Textdatei ist und in der auch von Menschen lesbar die Informationen eingetragen sind.

Composer löst alle Abhängigkeiten untereinander vollständig auf und lädt alle benötigten, weiteren PHP Packages selbständig herunter und legt sie in einem definierten Verzeichnis ab.

Weder der Programmierer noch der Nutzer der Anwendung muss sich um diese Abhängigkeiten kümmern. Das erledigt composer automatisch, auch bei Updates bezüglich neuer Versionen.

Composer ist hier zu finden: https://getcomposer.org/

Composer bei Hosteurope installieren

Wenn nun eine Anwendung auf dem Webserver oder ein Modul von Drupal nach der Nutzung von composer verlangt, muss man sich die erforderlichen Schritte zur Installation und Betrieb des composer-Skripts gemäß den Bedingungen auf dem gebuchten Webspace anschauen und evt. etwas herumprobieren. Denn natürlich unterscheidet sich der Webserver vom eigenen Rechner, auf dem jedes Programm alles darf und alle Verzeichnisse verfügbar sind. Auf dem Webserver sind durch den Hoster nur bestimmte Aktionen zulässig, da dieser alles, was die Sicherheit des Webspace gefährdet, abschaltet oder aushebelt. Dies ist ja auch seine Aufgabe und damit völlig in Ordnung.

Ich beschreibe hier die Installation von Composer auf Hosteurope Webserver Basic, einem Webspace mit SSH Zugang, eigener IP, bei dem das System gemanaged wird. Ähnliche und "höhere" Webspaces von Hosteurope werden wahrscheinlich ähnlich funktionieren. Das entscheidende Kriterium hierbei ist der SSH-Zugang, der es einem erlaubt, sich per Shell direkt auf den Server zu verbinden und dort Kommandozeilen-Befehle auszuführen.

Hier sind die Infos zum genannten Webspace: Hosteurope Webserver Basis

Ablage: Wo liegen welche Dateien?

Zunächst muss man sich vergegenwärtigen bzw. planen, wo welche Dateien zum Liegen kommen sollen:

  1. das composer-script selbst
  2. die "anfordernde Anwendung" mit der composer-Konfigurationsdatei (composer.json)
  3. die durch die Abhängigkeiten zu ladenden PHP-Packages

Installation von composer

Das composer-Skript selbst sollte nicht einfach irgendwo mittendrin in den Dateien zu einer Website liegen. Nach 3 Wochen hat man vergessen, wo es lag und muss suchen. Oder ein Kollege löscht es, weil er damit nichts anzufangen weiß. Also am besten außerhalb des Webroot, im Wurzelverzeichnis ablegen, in einem Ordner "script".

Da der Web-Nutzer keine Schreibrechte auf das per FTP erreichbare Webroot hat, muss man eine der beiden folgenden Methoden nutzen, um den Ordner /script anzulegen.

Der Dateimanager im KIS legt diesen automatisch an, wenn man die "temporäre Domain" (wpxxxxxx.hosteurope.de) einfach auf den Pfad /script einstellt. Mit diesem "exploit" kann man schnell und einfach direkt in der Weboberfläche des KIS Ordner im Webroot erzeugen (z.B. auch für Backup-Dateien, Distributionen, Liesmich-Ordner mit Textdateien mit Infos für Web-Mitarbeiter etc.).

Ein anderer Weg zum Erzeugen von Ordnern (und Dateien) im Webroot ist das Verbinden per SSH mit dem SSH-FTP-Benutzer. Normalerweise wird man beim Zugriff zu seinem Webspace den SSH-Webbenutzer nehmen, da dieser auf alles Zugriff hat, außer eben auf das Rootverzeichnis. Der SSH-FTP-Benutzer hat hier Zugriff und kann Ordner anlegen. Durch den Dateimanager im KIS überträgt man anschließend einfach die angelegten Dinge an den Webbenutzer, damit Anwendungen auf dem Webspace hierauf Zugriff haben.

Die entsprechenden Einträge findet man im KIS unter "SSH Zugang", wo man auch das Passwort hierfür festlegt und diesen Dienst generell ein-/ausschalten kann.

Innerhalb des nun verfügbaren Ordner /script habe ich nun den Ordner composer angelegt, also: /script/composer und kann mich nun per ssh auf den Webspace verbinden und in dieses Verzeichnis wechseln.

ssh [email protected]
# passwort eingabe
# begrüßungsnachricht vom server
#
cd ~/script/composer

Oben auf der Seiten bei getcomposer.org/download stehen nun Anweisungen, wie composer selbst zu installieren ist. Die ersten beiden Zeilen werden genau so funktionieren. Man kopiert einfach die erste Befehlszeile von der Webseite und fügt sie in die Shell ein und führt sie aus. Ebenso die 2. Befehlszeile.

Die erste Zeile kopiert das Install-Script von getcomposer.org und legt es als Datei "composer-setup.php" im aktuellen Ordner ab. Die zweite Zeile vergleicht den SHA-Hashwert dieser Datei mit einem bestimmten Wert. Wenn dieser übereinstimmt, wurde die Datei nicht manipuliert und ist OK.

php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"

php -r "if (hash_file('SHA384', 'composer-setup.php') === '55d6ead61b29c7bdee5cccfb50076874187bd9f21f65d8991d46ec5cc90518f447387fb9f76ebae1fbbacf329e583e30') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
# Meldung "Installer verified" sollte hier dann stehen

Die nächste Zeile hat mir ein bisschen Kopfschmerzen bereitet und ich musste ein bisschen recherchieren, um diese (für die Anforderungen bei Hosteurope) korrekt auszuführen.

php composer-setup.php

Dies führt zu einer längeren Fehlermeldung, bei der es darum geht, daß der bei Hosteurope vorgeschaltete Sicherheitslayer Suhosin kein "phar" ausführen kann und daß man dies also den Einstellungen von Suhosin als "erlaubt" hinzufügen möchte. Nach ein wenig Suche im KIS findet man die Suhosin Einstellungen unter den Script-Einstellungen und kann dort "phar" hinzufügen. Das nützt einem nur leider herzlich wenig, da die PHP-Version, die unterhalb des Webservers läuft, eine andere ist als die, auf die man zugreift, wenn man sich per SSH verbindet. Das herauszufinden, war ein bisschen Gewurschtel und Gelese.

# Fehlermeldung, die auftaucht, wenn man >> php composer-setup.php ausführt

Some settings on your machine make Composer unable to work properly.
Make sure that you fix the issues listed below and run this script again:

The suhosin.executor.include.whitelist setting is incorrect.
Add the following to the end of your `php.ini` or suhosin.ini (Example path [for Debian]: /etc/php5/cli/conf.d/suhosin.ini):
    suhosin.executor.include.whitelist = phar http://,https://

A php.ini file does not exist. You will have to create one.
If you can not modify the ini file, you can also run `php -d option=value` to modify ini values on the fly. You can use -d multiple times.

Im vorliegenden Webpaket gibt es keine (für mich zugängliche) php.ini oder suhosin.ini. Also muss man die lange Anweisung "suhosin.executor....." dem Befehl hinzufügen.

php -d suhosin.executor.include.whitelist=phar,http://,https:// composer-setup.php

Soweit, so gut.. Nein, eine neue Fehlermeldung taucht auf :-)

All settings correct for using Composer

Unable to create Composer home directory "/is/htdocs/wpxxxxxxxx_xxxxxxxxx/.config/composer": mkdir(): Permission denied

Composer versucht offensichtlich, im Webroot /.config/composer anzulegen, was natürlich fehlschlägt, da dies für den Webuser (und alle Anwendungen darin) nicht erlaubt ist. Nach erneuter Lektüre auf getcomposer.org stellt man fest, daß man eine Environment-Variable für Composer festlegen muss, in der das Heimatverzeichnis für composer definiert ist. Die Option composer-setup.php --install-dir hatte ich natürlich probiert, dies führt nicht zum gewünschten Ergebnis. Bei Hosteurope läuft bash als Shell, also muss man kurz nachschlagen, wie man eine Environment-Variable mit bash festlegt und kommt dann zu:

# composer home environment variable setzen, absoluter pfad

# lokale variable COMPOSER_HOME
COMPOSER_HOME="/is/htdocs/wpxxxxxxxx_xxxxxxxxxx/script/composer"

# in environment übernehmen
export COMPOSER_HOME

Nachzulesen unter https://getcomposer.org/doc/03-cli.md#composer-home. Nach dieser Aktion sollte ein erneuter Aufruf von

php -d suhosin.executor.include.whitelist=phar,http://,https:// composer-setup.php

zum Erfolg führen. Composer ist jetzt installiert. Wenn man erstmal herausgefunden hat, wie man die auftauchenden Klippen umschifft, ist es einfach, aber mich hat es insgesamt initial etwas mehr als 2 Stunden gebraucht, um diesen Lösungsweg herauszufinden. Man muss sich aus der Fülle an Informationen im Internet ja erstmal die richtigen herausfiltern. Jemand, der sich gewohnheitsmäßig auf der Shell bewegt, hätte es wahrscheinlich nur einen Bruchteil der Zeit gebraucht, aber ich bin da relativ selten unterwegs.

Composer nutzen

Die Anwendung, die Composer angefordert hatte, war bei mir ein Drupal 7-Modul, das wie gewohnt unter /sites/all/modules zum liegen kommt. Hier gibt es nichts weiter zu beachten. Das Modul wird wie gewohnt über die Weboberfläche von Drupal installiert und fertig. Die Datei "composer.json" mit den Konfigurationseinstellungen hat dieses Modul in /sites/{domain.de}/files/composer abgelegt.

Ein Blick in diese Datei zeigt, daß die abhängigen PHP-Packages in /sites/all/vendor/ zum liegen kommen sollen. Also noch schnell diesen Ordner erzeugt und dann kann es endlich losgehen.

Damit man einfach composer mit Anweisungen in die Shell schreiben kann, legt man sich am besten noch ein Alias an, denn ansonsten muss man für jeden Aufruf von composer eine irrsinnig lange Zeile tippen.

Hierzu legt man eine Datei namens .bashrc im Webroot an (wir wissen ja jetzt, wie) und fügt dort dies ein:

alias composer='php -d suhosin.executor.include.whitelist=phar,http://,https:// /is/htdocs/wpxxxxxxxx_xxxxxxxxxx/script/composer/composer.phar'

Anschließend ins Verzeichnis mit der comoser.json Datei wechseln, in meinem Fall /sites/{domain.de}/files/composer und dort einfach composer aufrufen, der Rest ist dann endlich automatisch. Das Verzeichnis /sites/all/vendor füllt sich nun mit den abhängigen PHP Packages und alles funktioniert, wie es soll.

Fazit

Wenn composer erstmal läuft, ist es eine tolle Sache. Ich wünsche mir, daß die Hosting-Anbieter dieses Script einfach mit in die Liste der "notwendigen Dinge für einen Webserver" aufnehmen und es von sich aus bereitstellen, damit der meist Shell-unerfahrene User nicht jedesmal durch diesen Dschungel stolpern muss. Das wäre eine großartige Zeitersparnis.

Und die Programmierer größeren Webanwendungen wie z.B. CMS und Webshops täten gut daran, eine Art Web-Oberfläche für composer berreitszustellen, auf der man im gewohnten Backend schnell mal nachschauen und die PHP-Packages prüfen und aktualisieren kann. Ansätze hierfür existieren für Drupal schon durch die tollen Leute von Acquia und Lullabot. Es gibt z.B. ein Modul "Composer Manager" von Acquia, das von anderen Modulen genutzt werden kann: composer_manager bei drupal.org.

Falls sich hier in der Beschreibung der Vorgehensweise Fehler eingeschlichen haben oder es ggf. andere, evt. bessere Wege zur Installation von Composer gibt, kann man mir schreiben (Kontakt) oder einen Kommentar hinterlassen. Ich freue mich über Feedback.

Update 16.07.2019:

Es gibt einen Artikel von HostEurope selbst zu diesem Thema, der evt. besser als meiner die nötigen Schritte beschreibt:

HostEurope: Wie installiere ich den Composer?

Content created (7 years 7 months)
Content changed (vor 1 year 7 months)
URL Path /blog/composer-hosteurope
UUID afcf076a-a616-4682-b585-703e75852e82