erlöst – vergnügt – befreit             mal kritisch – mal blauäugig – mal vergeekt

Drush

Seit längerem plagt mich die Administration von ein paar Drupal 6-Websites, deren Updates noch auf althergebrachte Art eingespielt werden müssen. Auf dem Barcamp Kirche 2.0 hörte ich dann von Drush – der Drupal Shell. Zu kompliziert und zu zeitaufwändig, um sich mal eben einzudenken, dachte ich. Da in den letzten Tagen mal wieder ein Coreupdate von Drupal fällig war, habe ich Drush einfach mal ausprobiert.
Um es kurz zu sagen, Drush hält, was es verspricht (und bis jetzt habe ich nur einen einführenden Screencast gesehen und ein Update gemacht).
Ein Problem stellte sich allerdings. Meine Seiten liegen auf Domaingo-Webspace und dort ist auf der Kommandozeile PHP4 Standard. Drush braucht aber mindestens PHP 5.2 (was glücklicherweise auch installiert ist). Da Drush selbst nach PHP sucht, braucht es nur eine kleine Änderung in Zeile 50 im drush-Script, damit es PHP 5 benutzt:

php=`which php`
wird zu
php=`which php5`

Dazu noch im /kunden/Kundennummer_PLZ Verzeichnis eine .bash_profile anlegen, in der folgendes steht:

PATH=$PATH:/kunden/Kundennummer_PLZ/drush-Verzeichnis
export PATH

(das kann man natürlich auch nach jedem Neustart per Hand machen) und schon ist Drush an die Umgebung bei Domaingo eingepasst. Beim Update sollte man allerdings etwas aufpassen, denn bei Domaingo braucht Drupal ja eine angepasste .htaccess, die beim Update leider überschrieben wird.

Ja, ich weiß, alles Kinderkram, aber bevor ich nächstes Mal wieder suche… 😉

Advertisements

Kommentare zu: "Drush" (4)

  1. Danke für den Hinweis! Ich habe mir das Tutorial von Natalie angeschaut und bin recht begeistert. Bei insgesamt 9 Drupal-6-Seiten, die ich adminsitriere, klicke ich mir jedes Update die Finger wund: Jede Seite einzeln in den Wartungsmodus, Update-Prozess, Wartungsmodus deaktivieren… Da wäre so eine Shell sehr hilfreich: Virtual Server abschalten, ein paar Befehle auf der Konsole hacken und fertig.

    Wären da nicht meine Zweifel, dass die Shell auch mit Multisites (Shared Tables) klarkommt. Hast du da Informationen darüber?

    • Zu den Shared-Tables habe ich noch nichts gesucht, da ich bis jetzt nur wenig damit zu tun hatte. Ist denke ich sehr von den Modulen und den geteilten Tabellen abhängig. Andererseits traue ich dem Ding tatsächlich zu, dass es sowas zuverlässig erkennt. Falls Du Interesse hast, kann ich dir ein passendes Backupscript (nur quick’n’dirty per bash) geben. Aber drush macht auf Wunsch auch selber Backups…
      Im Moment arbeite ich gerade an einem Script, das mir automatisch Testumgebungen auf dem Server klont.

      • Andreas schrieb:

        Danke. Ich mache meine Backups bereits als Bash-Script automatisiert per Knock-Daemon und lade dann den als Tarball gepackten und mit aespipe verschlüsselten (enc) File von meinen Server über http. Falls dich diese Technik interessiert stelle ich sie dir natürlich ebenfalls gerne zur Verfügung. Trotzdem möchte ich das Risiko nicht eingehen und die drush an einem Produktivsystem testen. Ich werde – wenn mal Zeit ist – das Setup auf meinen Rechner klonen und dort ausgiebig testen.

      • Klar bin ich interessiert!

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

Schlagwörter-Wolke

%d Bloggern gefällt das: