7735
Kommentar: Schoene URLs mit apache-redirects
|
7759
klarstellung
|
Gelöschter Text ist auf diese Art markiert. | Hinzugefügter Text ist auf diese Art markiert. |
Zeile 6: | Zeile 6: |
Zeile 9: | Zeile 8: |
Zeile 13: | Zeile 13: |
Zeile 21: | Zeile 20: |
* phpmyadmin dazu starten (a2ensite phpmyadmin; apache2ctl graceful) | * im datenbank-Server dazu phpmyadmin starten (a2ensite phpmyadmin; apache2ctl graceful) |
Zeile 24: | Zeile 23: |
* Passwort generieren und merken ;) | * Passwort generieren und merken ;-) |
Zeile 38: | Zeile 37: |
* in der ''/var/www/drupal-sao/.htaccess'' folgende Zeilen einfügen: {{{ | * in der ''/var/www/drupal-sao/.htaccess'' folgende Zeilen einfügen: {{{ |
Zeile 48: | Zeile 48: |
* aus der Kopie des sites/default Verzeichnisses, also aus dem neuen sites/www.moewenshiet.foo die ".svn" Verzeichnisse entfernen: {{{ | * aus der Kopie des sites/default Verzeichnisses, also aus dem neuen sites/www.moewenshiet.foo die ".svn" Verzeichnisse entfernen: {{{ |
Zeile 51: | Zeile 52: |
* dann die Dateien dem svn hinzufügen: {{{ | * dann die Dateien dem svn hinzufügen: {{{ |
Zeile 54: | Zeile 56: |
* hochladen nicht vergessen {{{ | * hochladen nicht vergessen {{{ |
Zeile 58: | Zeile 61: |
Zeile 60: | Zeile 62: |
Bei einer Multisites Installation liegen zusätzliche Module und Themes im Verzeichnis ''.../sites/all/[modules|themes]''. Während eines Upgrade sollten diese Module in den jeweiligen Multisites deaktiviert und anschließend wieder aktiviert werden. |
Bei einer Multisites Installation liegen zusätzliche Module und Themes im Verzeichnis ''.../sites/all/[modules|themes]''. Während eines Upgrade sollten diese Module in den jeweiligen Multisites deaktiviert und anschließend wieder aktiviert werden. |
Zeile 84: | Zeile 85: |
Zeile 89: | Zeile 89: |
Zeile 91: | Zeile 90: |
Zeile 99: | Zeile 97: |
* aktuellen trunk taggen und verschieben: {{{ | * aktuellen trunk taggen und verschieben: {{{ |
Zeile 102: | Zeile 101: |
* Code für Drupal 6.7 holen (in trunk): {{{ | * Code für Drupal 6.7 holen (in trunk): {{{ |
Zeile 106: | Zeile 106: |
* alle geänderten und zusätzlichen Dateien aus tags in trunk kopieren | * alle geänderten und zusätzlichen Dateien aus tags in trunk kopieren |
Zeile 108: | Zeile 108: |
* .svn Verz. entfernen: {{{ | * .svn Verz. entfernen: {{{ |
Zeile 113: | Zeile 114: |
Zeile 120: | Zeile 120: |
Zeile 126: | Zeile 125: |
* dann in apt-get Manier: {{{ | * dann in apt-get Manier: {{{ |
Zeile 135: | Zeile 135: |
Zeile 138: | Zeile 137: |
Zeile 141: | Zeile 139: |
* DB einer Site dumpen: {{{ | * DB einer Site dumpen: {{{ |
Zeile 145: | Zeile 144: |
Zeile 148: | Zeile 146: |
Drupal
[http://drupal.org drupal.org]
Cronjobs
Drupal kann durch Cronjobs Newsfeeds holen, nach Updates suchen usw.. Hier bietet sich entweder das Drupal Modul poormanscron an oder wie bei systemausfall ein Script, das in cron.hourly steht mit folgendem Inhalt:
wget -q -O - https://<meine.drupal.url>/cron.php
Development, Performance
Mit dem Modul devel lässt sich gut nachvollziehen, wieviel Datenbankzugriffe eine erstellte Seite macht und wieviel Speicher sie benötigt. (Vorsicht das verlangsamt ungemein!)
Drupal Multiseite
neue Domain bzw. Unterseite anlegen
- passenden URL Eintrag in webproxy setzen
- DB-Nutzer + Datenbank anlegen
- im datenbank-Server dazu phpmyadmin starten (a2ensite phpmyadmin; apache2ctl graceful)
neuen Nutzer erstellen sollte mit drupal_ beginnen z.B. "drupal_moewenshiet", dann bleibt eine Multisiteinstallation in einer großen DB übersichtlich
- Hostzugriffe über das Textfeld begrenzen
Passwort generieren und merken
- "Erstelle eine Datenbank mit gleichem Namen und gewähre alle Rechte" auswählen
- keine globalen Rechte vergeben
- phpmyadmin (a2dissite phpmyadmin; apache2ctl graceful)
- in der Apacheconfig der entsprechenden Domain (siehe sites-available) die URL auf die Drupal Documentroot verweisen
- in Drupal das Verzeichnis sites/default kopieren auf den Namen der neuen URL (Slashes werden zu Punkten)
!http://subdomain.systemausfall.org/moewenshiet -> .../sites/subdomain.systemausfall.org.moewenshiet
!http://www.moewenshiet.foo -> .../sites/www.moewenshiet.foo
- in der Datei .../sites/moewenshiet.../settings.php
den Parameter $db_url mit den DB Zugangsdaten der neuen Site füttern
$base_url auch entsprechend anpassen
für die neue Seite das install.php Script aufrufen (z.B. !http://subdomain.systemausfall.org/moewenshiet/install.php)
- die Formularfelder ausfüllen, dann wird der Adminuser angelegt und die DB mit Tabellen gefüllt
- Schöne URLs ermöglichen (sonst gibt es eine Umleitung zur sao-Webseite mit Zugangsverweigerung):
in der /var/www/drupal-sao/.htaccess folgende Zeilen einfügen:
# moewenshiet RewriteCond %{REQUEST_URI} ^/moewenshiet/ RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_URI} !=/favicon.ico RewriteRule ^(.*)$ /moewenshit/index.php?q=$1 [L,QSA]
- cronjob einrichten
- in's svn einpflegen ..
- aus der Kopie des sites/default Verzeichnisses, also aus dem neuen sites/www.moewenshiet.foo die ".svn" Verzeichnisse entfernen:
find . -name .svn -type d -exec rm -r '{}' \;
- dann die Dateien dem svn hinzufügen:
svn add sites/www.moewenshiet.foo
- hochladen nicht vergessen
svn commit
- aus der Kopie des sites/default Verzeichnisses, also aus dem neuen sites/www.moewenshiet.foo die ".svn" Verzeichnisse entfernen:
- das war's auch schon
Module und Themes
Bei einer Multisites Installation liegen zusätzliche Module und Themes im Verzeichnis .../sites/all/[modules|themes]. Während eines Upgrade sollten diese Module in den jeweiligen Multisites deaktiviert und anschließend wieder aktiviert werden.
Drupal Core Update einspielen (ohne svn/cvs)
Vorarbeiten
- internes Backup machen
evtl. noch per Hand ein mysqldump der Datenabnk anstoßen
- neuen Drupal-Core nach /data/Drupalsoftware runterladen
- nach /data/drupal-x.x entpacken
- chown -R www-data. /data/drupal-x.x
- UPGRADE.txt lesen
Update
- als Admin anmelden und die Seite in den Wartungsmodus versetzen
- Während der folgenden Schritte nicht das Browserfenster schließen, damit die Anmeldung beim Update aktiv bleibt!
- Änderungen und zusätzliche Dateien aus der alten Drupalroot in die neue übernehmen. Das sind:
- /modules/ldap...
- /profiles/translations
- /sites/
- .htaccess und favicon.ico
- im neuen Drupalroot sites/default/settings.php:
- $update_free_access = TRUE; setzen
symbolishen Link unter /var/www auf neue Drupalroot setzen; apache2ctl graceful
- $URL/update.php aufrufen (läuft jetzt mit dem php Code des neuen Drupal Cores)
- Coremodul Updates durchführen (einfach durch die Seite klicken..)
Aufräumen
- $update_free_access = FALSE; setzen
- Wartungsmodus ausschalten
- veraltete, unbenutzte Module/Themes löschen
- Archive für aktualisierte Module und Themes im neuen Drupalroot entpacken und die alten damit ersetzen
Drupal Core Update einspielen (mit svn/cvs)
alle Drupalinstanzen sind im svn hinterlegt, die aktuelle Seite läuft immer in trunk, ältere versionen liegen in tags
- der Code für Drupal wird per cvs geholt
- damit vereinfacht sich das Update etwas und frühere Versionen sind leichter wiede rekonstruierbar
Ablauf
- Seiten in Offline-Modus schalten
- DB Backup anlegen
- aktuellen trunk taggen und verschieben:
svn cp trunk tags/drupal-6.6
- Code für Drupal 6.7 holen (in trunk):
cvs update -r DRUPAL-6-7 -dP
- nur wenn mit svn mv trunk geleert wurde:
- alle geänderten und zusätzlichen Dateien aus tags in trunk kopieren
- themes, modules, translation
- .svn Verz. entfernen:
find trunk/* -type d -name .svn -exec rm -r '{}' \;
- alle geänderten und zusätzlichen Dateien aus tags in trunk kopieren
- update.php starten
- Seite online schalten
Drupal Module aktualisieren
Mit drush (DRUpal SHell) lassen sich installierte Module bequem per ssh aktualisieren. Wenn bei Multisite Installationen drush in jeder Site installiert und aktiviert wurde, spart das 'ne Menge Download Gewusel.
einmalige Vorbereitung
- Evtl. musst du vorher in /etc/php5/cli/php.ini (für commandline php scripte) das Speicherlimit hochstellen.
- cvs wird für die Moduldownloads gebraucht
Updates
- Backup der DB und des Drupal Verz. anlegen!
- DB wird nächtlich gesichert
wenn svn status Änderungen zeigt, diese einpflegen
- als Admin anmelden und die Seite in offline Modus stellen
- dann in apt-get Manier:
cd /var/www/drupal ./sites/all/modules/drush/drush.php -l my.fancy.site.org pm refresh ./sites/all/modules/drush/drush.php -l my.fancy.site.org pm update
in settings.php $update_free_access = TRUE; setzen und update.php im Browser ausführen
- anschließend wieder auf false setzen
- wenn im Statusbericht keine Fehler oder Hinweise auftauchen, Seite wieder online schalten - et voila
- Codeänderungen in svn commiten
drush Mängel
- Wird in einer Domain einer Multisiteinstallation ein Modul aktualisiert, so liegt es anschließend unter /sites/all. Das muss dann per Hand an seinen ursprünglichen Ort verschoben werden. Dabei vorsichtig mit den .svn Verzeichnissen umgehen.
Database Backup
- tägliche DB Backups liegen in der Datenbank Domain
- DB einer Site dumpen:
/usr/bin/php5 /.../sites/all/modules/drush/drush.php -v -l http://site.domain.org sql dump > site-sql-dump
- dafür muss drush installiert und das drush-sql-modul für die site aktiviert sein
Prod./Dev Server synchronisieren
Um Updates, neue Module, experimentelle Dinge erst in einer Entwicklungsumgebung zu testen, bietet sich eine Entwicklungsumgebung an, die mit der Produktivumgebung synchronisiert wird. Falls die Änderungen vom Dev. Server später per Script auf dem Prod. Server eingepflegt werden sollen (per sql dump), dann muss die Seite auf dem Prod. Server vorher in den offline Modus gebracht werden, damit dort zwischendurch keine Änderungen stattfinden.
Schritte auf Prod. Server
- svn status
- dann evtl. svn add, svn commit
- DB dumpen (mit drush)
Schritte auf Dev. Server
- svn up
mysql -p root -p < site-sql-dump