In die Nginx-Konfiguration muss hierzu Folgendes aufgenommen werden:

if ($host = ‘host.net’ ) {
rewrite  ^/(.*)$  http://www.host.net/$1  permanent;
}

So aktualisiert man von der letzten LTS-Version 10.04 auf die aktuelle 12.04 LTS, und zwar über die “Umwege” 10.10, 11.04 und 11.10:

Zunächst ist zu prüfen, ob die aktuelle Version des Update-Mangers installiert ist:

sudo apt-get install update-manager-core

Nun wird die Datei /etc/update-manager/release-upgrades editiert:

Prompt=normal

Mit dem Befehl

sudo do-release-upgrade

wird das Update gestartet.

Dies wiederholt man so oft, bis man bei der aktuellen Version 12.04 LTS angelangt ist. Danach setzt man den Update-Pfad auf

Prompt=lts

zurück.

Aufgrund der sehr umfangreichen Änderungen von 10.04 zu 12.04 sollte allerdings genau abgewogen werden, ob man ein Update durchführt. Ich selbst update derzeit nach o.g. Muster nur “weniger wichtige” Systeme und belasse wichtige Produktivsysteme vorerst bei 10.04 LTS.

Zusätzlich existiert aptitude als Frontend für APT. Zudem existiert, jedoch nur noch aus Gründen der Abwärtskompatibilität, dselect.

Bereits seit Debian 3.1 (“Sarge”) wird offiziell aptitude zur Paketverwaltung empfohlen. Kurz gesagt kann aptitude alles, was apt-get kann, und darüber hinaus noch einiges mehr. Dank ncurses-Bibliothek ist aptitude in der Lage, eine grafische (zeichenorientierte) Oberfläche zu bieten. Um diese soll es hier jedoch nicht gehen.

Was Funktionalität und Syntax auf der Kommandozeile angeht, sind apt-get und aptitude im Wesentlichen identisch. Wichtig ist, dass man bei einem System entweder mit den Befehlen apt-get/apt-cache oder mit aptitude arbeitet. Denn beide Frontends verwalten Informationen über installierte Pakete und über Abhängigkeiten in jeweils eigenen Datenbanken.

Mischt man APT mit aptitude, kann es passieren, dass “die linke Hand nicht weiss, was die rechte tut”: Früher oder später kommt es zu Problemen durch die Verwendung von mehr als einem Ort, in dem Paketinformationen (und hier insbesondere Abhängigkeiten) gespeichert werden.

Der Einsatz von aptitude empfiehlt sich aus folgendem Grund:

aptitude führt ein gegenüber apt-get erweitertes Log über installierte Pakete. So speichert aptitude beispielsweise stets, ob ein Paket von einem Benutzer installiert wurde oder vom System selbst aufgrund einer Abhängigkeit. Wurde ein Paket automatisch wegen einer Abhängigkeit installiert, so entfernt es aptitude ebenso automatisch wieder, sobald das übergeordnete Paket deinstalliert wird (und keine weiteren Abhängigkeiten einer Entfernung entgegenstehen).

Verwaiste (nicht mehr benötigte) Pakete kann aptitude somit zuverlässig erkennen und deinstallieren. aptitude erleichtert das Sauberhalten des Systems dadurch ganz erheblich.

Die wichtigsten Befehle sind:

aptitude update lädt aktualisierte Paketquellen herunter. Dies sollte stets erfolgen, bevor weitere Befehle ausgeführt werden.

aptitude upgrade lädt Paketauktualisierungen herunter und wendet diese nach Rückfrage und expliziter Bestätigung an.

aptitude dist-upgrade gestattet das Aktualisieren der gesamten Distribution auf eine neue Version der Distribution.

aptitude install (Paketname) installiert ein bestimmtes Paket.

aptitude remove (Paketname) deinstalliert ein bestimmtes Paket. Eventuell vorhandene Konfigurationsdateien bleiben erhalten.

aptitude purge (Paketname) deinstalliert ein bestimmtes Paket und entfernt im selben Zuge auch eventuell vorhandene Konfigurationsdateien.

aptitude search (Suchbegriff) sucht im Repository nach Paketen.

Genaugenommen kommt statt einer Ramdisk das zeitgemäßere tmpfs (Temporary File System) zum Einsatz. Ein entscheidender Vorteil einer tmpfs-Partition ist, dass die Größe des RAM, die sie belegt, variabel ist: Eine tmpfs-Partition belegt physisch immer nur so viel Arbeitsspeicher, wie sie aufgrund ihrer aktuellen Größe gerade braucht. Sie wächst quasi mit, bis zum Wert, der als erlaubtes Maximum definiert wurde.

Die im Web an vielen Stellen zu findende Syntax funktioniert übrigens nicht, da mit dieser das Device von Magento nicht beschreibbar ist. Man muss es explizit User und Gruppe www-data zuweisen (das bezieht sich auf Debian/GNU, Ubuntu Server und deren Derivate; bei anderen Distributionen entsprechend dem User und der Gruppe, unter welchem bzw. welcher der Webserver läuft). Und zwar so:

mount -t tmpfs -o size=1G,mode=0744,uid=www-data,gid=www-data tmpfs /var/www/ihr-host/var/cache/

In o.g. Beispiel wird der tmpfs-Partition eine maximale Größe von einem Gbyte zugewiesen. Erlaubt sind natürlich auch Werte im Mbyte-Bereich, z.B. 512M oder 800M etc.

Zu bedenken ist, dass Partition und ergo deren Inhalt nach einem Neustart weg sind. Soll die Partition nach einem Neustart automatisch gemountet werden, erreicht man dies durch einen Eintrag in /etc/fstab .

Manuell kann man die Partition bei Bedarf mit

umount tmpfs

unmounten.

Diesen beseitigen wir, indem wir die Requests auf verschiedene Hosts verteilen. Im Magento-Backend findet sich hierfür unter “Konfiguration” -> “System” -> “Web” -> “Ungesichert” eine entsprechende Konfigurationsmöglichkeit:

Hier tragen wir nun jeweils vom Basis-Host abweichende Hosts ein:

Zuvor müssen die entsprechenden Hosts natürlich existieren und konfiguriert werden. Am Beispiel von js.host.tld sieht die entsprechende Apache-Konfigurationsdatei so aus:

<VirtualHost *:80>
ServerAdmin webmaster@host.tld

ServerName js.host.tld
DocumentRoot /var/www/host
<Directory /var/www/host/>
Options -Indexes FollowSymLinks MultiViews
AllowOverride None
Order deny,allow
deny from all
</Directory>
<Directory /var/www/host/js/>
Options -Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
Include /etc/apache2/deflate-expires.conf
</Directory>

ErrorLog /var/log/apache2/js.host_error.log
LogLevel warn
CustomLog /var/log/apache2/js.host_access.log combined
</VirtualHost>

Erläuterungen hierzu:

Der erste Directory-Container definiert das Verhalten des Magento-Rootverzeichnisses. Auf selbiges zeigen nämlich auch die zusätzlichen Hosts. Hier sollte zwecks Vermeidung von Duplicate Content unterbunden werden, dass das Magento-Rootverzeichnis über weitere Hosts erreichbar ist:

Order deny,allow
deny from all

Der zweite Directory-Container dagegen erlaubt den Zugriff für das jeweils benötigte Verzeichnis (in diesem Beispiel /js):

Order allow,deny
allow from all

Mit dem nachfolgenden Include-Befehl wird eine .conf-Datei inkludiert, welche die Inhalte aufweist, die eigentlich in der .htaccess-Datei des jeweiligen Verzeichnisses untergebracht sind. Ich habe diese “deflate-expires.conf” benannt, da im Wesentlichen Kompressions- und Expires-Anweisungen darin enthalten sind (und ich dieselbe Datei auch in weitere Hostfiles inkludiere, eine möglichst allgemeine, beschreibende und host-unabhängige Bezeichnung ergo angebracht ist).

Ich selbst arbeite nach Möglichkeit nicht mit .htaccess-Dateien (Direktive “AllowOverride None”). Sofern .htaccess-Dateien Berücksichtigung finden sollen, kann das Inkludieren von Anweisungen entfallen (Direktive “AllowOverride All”).

Analog dazu wird für die weiteren gewünschten Hosts verfahren (media.host.tld, skin.host.tld,…). Bei Bedarf kann für SSL-Requests ebenso verfahren werden, allerdings wird dann für jeden Host ein separates SSL-Zertifikat benötigt (oder alternativ ein Wildcard-Zertifikat, das Subdomains einschließt).

Fazit:

Durch das Verteilen der Requests auf weitere Hosts erreicht man im Handumdrehen eine Verfielfachung der clientseitigen Begrenzung simultan möglicher Requests. Mit Einrichtung und Inbetriebnahme der Hosts js, media und skin können theoretisch statt zehn vierzig Requests parallel durchgeführt werden.