$ pacman -Rdd package

Ähnliche Artikel

• Das Arch Linux User-Community Repository
• Arch Linux: Alle explizit installierten Pakete auflisten
• Sabayon: Erster Eindruck

$ pacman -Qe

Ähnliche Artikel

• Arch Linux Pacman Dependency Skip
• Sabayon: Erster Eindruck
• Gnome 3.2 im Arch Linux Repository

Was ist Sabayon? Sabayon ist eine auf Gentoo basierende Linux Distribution. Die Philosophie hinter dem Projekt ist, dass alles out of the box funktioniert und die best mögliche UserExperience bietet.
Klingt für mich im ersten Moment nach einer Distribution, welche die Vorteile von Gentoo und Ubuntu vereint. Und damit schonmal sehr interessant. Ich hatte lange Zeit Ubuntu und Gentoo verwendet und bin nun seit knapp 2 Jahren ein Arch Linux User. Mal sehen, ob mich Sabayon begeistern kann

Ich habe mir also mal die Sabayon 7 Gnome x86 iso geladen. Leider ist der Installer beim ersten Versuch abgeraucht. Das kommt davon, wenn man die root Partition zu klein dimensionier (3,5GB) und die Warnungen ignoriert Beim zweiten Versuch hat es dann schließlich geklappt. 18GB Root Partition sollten jetzt ausreichen.

Um auf meinem Notebook Einzug zu erhalten, müssen einige Dinge fehlerfrei und interoperabel laufen: Nginx, Tomcat6, Sun JRE 1.6, Ruby 1.9, ZSH, VirtualBox, synergy, etc. Sobald ich das alles in der VBox zum Laufen bekommen habe, das System an sich stabil läuft und mich davon überzeugen kann, dass es mir mehr bringt als ArchLinux, werde ich es auf meinem Notebook installieren.

Mittlerweile ist das System fertig installiert und gebootet. Dabei ist mir im Grub schon direkt aufgefallen, dass das System noch mit dem Kernel 3.0.0 läuft. Mein  Arch Linux bootet  z.Z. den Kernel 3.1.5. Mal sehen, wie es nach dem Upgrade aussieht.

Nach dem Login befinde ich mich im Fallback Mode von Gnome 3.2. Warum der Fallback? Der erzwungene Fallback-Modus ist deaktiviert und auch beim Anmelden habe ich keine Option für den Fallback Modus gesehen oder entsprechend gesetzt. An der fehlenden 3D-Beschleunigung von VirtualBox kann es nicht liegen, da die LiveCD auch die Gnome-Shell gestartet hat. Strange.

Was mir direkt gut gefällt: LibreOffice, Gimp, Evince, Chromium, XChat, Empathy, Exalie, Adobe Flash Player, etc. sind vorinstalliert. Und auch das Menü sieht sehr übersichtlich aus. Außerdem gefällt mir das Icon-Set, aber das ist nebensächlich. Dafür ist VIM aber nicht vorinstalliert :/

Der grafische Paketmanager macht einen netten Eindruck, den werde ich als Shell Ninja aber ohnehin nicht verwenden. Equo lässt sich wirklich einfach bedienen und ist sehr gesprächig. Leider so gesprächig, dass es unübersichtlich wird. Außerdem verwendet Entropy die PROXY-Umgebungsvariablen nicht. Die Proxy Konfiguration muss also manuell in die entropy.conf eingetragen werden, was weniger flexibel ist.

Equo search ist ähnlich unübersichtlich wie die Portage Variante. Hier schneidet Pacman bzw. Yaourt auch etwas besser ab.

Nach dem Upgrade auf den aktuellen Stand und einem reboot steht mir dann zwar immer noch kein aktueller Kernel zur Verfügung aber dafür stirbt gnome auch instant nach dem booten. Super. Grund: assertion failed.

Damit ist mein Sabayon Experiment erstmal beendet.

Ähnliche Artikel

• Arch Linux Pacman Dependency Skip
• Arch Linux: Alle explizit installierten Pakete auflisten
• Gnome 3.2 im Arch Linux Repository

Warum? Weil es keinen ordentlichen Sys Tray gibt. Verstehe nicht ganz warum so etwas essentielles fehlt, aber nagut.

Sonst sieht es schon recht gut aus. Ich lass es jetzt mal ein paar Wochen im Fallback Mode laufen (um einen Sys Tray zu haben) und dann überlege ich mir nochmal ob mir das gefällt

Ähnliche Artikel

• Arch Linux Pacman Dependency Skip
• Arch Linux: Alle explizit installierten Pakete auflisten
• Sabayon: Erster Eindruck

Da es sich um vier voneinander unabhängige WordPress-Installationen handelt und ich die Server Config DRY halten möchte, gibt es für die WordPress-spezifischen Sachen mal wieder eine include Datei:

# vim /etc/nginx/wordpress.inc

rewrite ^(/[^/]+/)?files/(.+) /wp-includes/ms-files.php?file=$2 last;

rewrite ^(/[^/]+)?(/wp-.*) $2 last;
rewrite ^(/[^/]+)?(/.*\.php) $2 last;

rewrite ^/(.*)$ /index.php?q=$1 last;

if (!-e $request_filename) {
        rewrite ^(.+)$ /index.php?q=$1 last;
}

Nun müssen die VHost-Konfigurationen noch entsprechend um ein Include erweitern werden:

# blog.itws.de
server {
        server_name blog.itws.de;
        root /var/www/itws.de/blog;

        include defaults.inc;
        include enable_php.inc;
        include wordpress.inc;
}

Fertig. Wie ihr sehen könnt, an sich also kein Hexenwerk.

Ähnliche Artikel

• Debian: Von Apache zu Nginx – Teil 5: Basic Authentication
• Debian: Von Apache zu Nginx – Teil 4: Einen Tomcat anbinden
• Debian: Von Apache zu Nginx – Teil 3: PHP

• Teil 1: Vorwort
• Teil 2: Installation und Konfiguration
• Teil 3: PHP
• Teil 4: Einen Tomcat anbinden
• Teil 5: Basic Authentication

Wie im ersten Teil beschrieben, muss ich ein paar meiner VHosts per Basic Authentication schützen. Hier zeige ich euch noch kurz, wie ich das mit nginx angestellt habe.

In meinem Fall möchte ich die Subdomain ci.itws.de schützen. Dazu lege ich mir erstmal ein Verzeichnis auth an, in dem ich die htpasswd-Dateien speichere:

# mkdir /etc/nginx/auth

Und ich lege mir einen Benutzer an:

# htpasswd -c /etc/nginx/auth/ci ghost

Danach muss ich nur noch den server-Block in der Datei /etc/nginx/sites-available/itws.de anpassen:

server {
    server_name ci.itws.de;
    root /var/www/itws.de/ci;

    include defaults.inc;
    include enable_php.inc;

    auth_basic  "ITWS CI";
    auth_basic_user_file auth/ci;
}

Fertig. Nach einem schnellen Restart von Nginx ist ci.itws.de per BA geschützt.

Ähnliche Artikel

• Wordpress unter Nginx
• Debian: Von Apache zu Nginx – Teil 4: Einen Tomcat anbinden
• Debian: Von Apache zu Nginx – Teil 3: PHP

• Teil 1: Vorwort
• Teil 2: Installation und Konfiguration
• Teil 3: PHP
• Teil 4: Einen Tomcat anbinden
• Teil 5: Basic Authentication

Ich möchte den Nginx auch auf meinem Notebook verwenden um dort die gleiche Umgebung wie auf dem Server zu haben. Und auch die gleiche Performance.

Da ich aber in der Firma mit dem Tomcat arbeite (den ich zur Zeit über mod_proxy an den Apachen angeklingt habe), muss ich meinen Nginx auch entsprechen konfigurieren. Da die Proxy-Funktionen im Nginx kein Modul sind, sondern der Nginx selbst ein Proxy-Server ist, ist das spielend einfach:

server {
    server_name ci.itws.de;
    root /var/www/itws.de/ci;

    index index.jsp index.html index.htm;

    proxy_pass http://localhost:8080;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
}

Ähnliche Artikel

• Debian: Von Apache zu Nginx – Teil 1: Vorwort
• Deployment von Ruby on Rails Applikationen
• Wordpress unter Nginx

• Teil 1: Vorwort
• Teil 2: Installation und Konfiguration
• Teil 3: PHP
• Teil 4: Einen Tomcat anbinden
• Teil 5: Basic Authentication

Installation

# apt-get install php5 php5-cli php5-cgi php5-suhosin php5-fpm

# /etc/init.d/php5-fpm restart

# vim /etc/nginx/enable_php.inc

location ~ \.php$ {
    if (!-f $request_filename) {
        return 404;
    }

    fastcgi_split_path_info ^(.+\.php)(.*)$;
    fastcgi_pass   backend;
    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;

    include fastcgi_params;

    fastcgi_intercept_errors        on;
    fastcgi_ignore_client_abort     off;
    fastcgi_connect_timeout 60;
    fastcgi_send_timeout 180;
    fastcgi_read_timeout 180;
    fastcgi_buffer_size 128k;
    fastcgi_buffers 4 256k;
    fastcgi_busy_buffers_size 256k;
    fastcgi_temp_file_write_size 256k;
}

server {
    server_name itws.de www.itws.de;
    root /var/www/itws.de/www;

    # redirection to blog.itws.de
    rewrite ^(.*) http://blog.itws.de$1 permanent;
}

server {
    server_name blog.itws.de;
    root /var/www/itws.de/blog;

    include defaults.inc;
    include enable_php.inc;
}

server {
    server_name ci.itws.de;
    root /var/www/itws.de/ci;

    include defaults.inc;
    include enable_php.inc;
}

upstream backend {
    server 127.0.0.1:9000;
}

Ähnliche Artikel

• Debian: Von Apache zu Nginx – Teil 1: Vorwort
• Wordpress unter Nginx
• Debian: Von Apache zu Nginx – Teil 5: Basic Authentication

• Teil 1: Vorwort
• Teil 2: Installation und Konfiguration
• Teil 3: PHP
• Teil 4: Einen Tomcat anbinden
• Teil 5: Basic Authentication

Installation

Um eine aktuelle Version (1.0.6) auch unter Debian zu bekommen, kann man einfach das dotdeb Repository in die sources.list aufnehmen:
dotdeb.org bietet ein umfangreiches Repository um Debian Systeme in perfekte LAMP Server zu verwandeln. Hier ist nicht nur die aktuelle Version von PHP 5.3 mit dem FPM, den ich später noch brauchen werde, sondern auch die aktuelle Version des nginx zu finden. Außerdem ist die Default-Konfiguration des Nginx aus dem dotdeb Repo etwas sauberer als die aus dem offiziellen Debian Nginx Repo …

# vim /etc/apt/sources.list

deb http://packages.dotdeb.org stable all
deb-src http://packages.dotdeb.org stable all

Danach kurz die Paketliste aktualisieren und den nginx installieren:

# apt-get update
# apt-get install nginx

Basis Konfiguration

Was mir im Konfigurationsverzeichnis des Nginx direkt auffällt sind die beiden Verzeichnisse “sites-avilable” und “sites-enabled”, welche man ja bereits vom apache kennt.

In der nginx.conf ändere ich folgende Parameter:

• user www-data www-data;
• index index.php index.htm index.html;

In den http-Block füge ich außerdem noch einige gzip Parameter ein:

    gzip                    on;
    gzip_comp_level         9;
    gzip_proxied            any;
    gzip_types              text/plain text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript image/png image/gif image/jpeg;
    gzip_http_version       1.1;
    gzip_min_length         1000;
    gzip_buffers            16 8k;
    gzip_disable            "MSIE [1-6] \.";
    gzip_vary               on;

Zusätzlich benötigen wir zwei Include Statements. Ersteres sollte bereits in der nginx.conf enthalten sein. Letzteres benötigen wir für die VHosts:

include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;

Virtuelle Hosts konfigurieren

Im sites-aviable Verzeichnis benenne ich die Datei “default” in “itws.de” um und füge folgenden Inhalt ein:

server {
    server_name itws.de www.itws.de;
    root /var/www/itws.de/www;

    # redirection to blog.itws.de
    rewrite ^(.*) http://blog.itws.de$1 permanent;
}

server {
    server_name blog.itws.de;
    root /var/www/itws.de/blog;

    location / {
        try_files $uri $uri/ /index.php /index.html;
    }

    location ~ /\.ht {
        deny all;
    }

     location ~* ^.+.(jpg|jpeg|gif|css|png|js|ico|xml)$ {
         access_log off;
         expires 30d;
         root /var/www;
     }
}

server {
     server_name ci.itws.de;
     root /var/www/itws.de/ci;

     location / {
         try_files $uri $uri/ /index.php /index.html;
     }

     location ~ /\.ht {
         deny all;
     }

     location ~* ^.+.(jpg|jpeg|gif|css|png|js|ico|xml)$ {
         access_log off;
         expires 30d;
         root /var/www;
     }
}

Im Wiki gibts mehr Beispiele, Parameter und Dokumentation.

Danach gibts noch eine Datei yaana.de mit ähnlichem Inhalt.

Im Anschluss daran müssen beide Konfigurationen aktiviert werden:

# ln -s /etc/nginx/sites-available/itws.de /etc/nginx/sites-enabled/itws.de
# ln -s /etc/nginx/sites-available/yaana.de /etc/nginx/sites-enabled/yaana.de

Diese Konfiguration kann ich mit 2-3 statischen Hallo-Welt-Dateien schonmal testen.
Funktioniert einwandfrei.

Jetzt möchte ich aber nicht jedes Mal diese ganzen location-Blöcke in jedem VHost haben. Deswegen lege ich mir eine Include Datei hierfür an:

# vim /etc/nginx/defaults.inc

Diese erhält folgenden Inhalt:

location / {
    try_files $uri $uri/ /index.php /index.html;
}

location ~ /\. {#
    access_log off;
    log_not_found off;
    deny all;
}

location ~* ^.+.(jpg|jpeg|gif|css|png|js|ico|xml)$ {
    access_log off;
    expires 30d;
}

location ~ (\.inc\.php|\.tpl|\.sql|\.tpl\.php|\.db)$ {
    deny all;
}

Nun ändere ich meine VHost Konfigurationen entsprechend ab:

server {
    server_name itws.de www.itws.de;
    root /var/www/itws.de/www;

    # redirection to blog.itws.de
    rewrite ^(.*) http://blog.itws.de$1 permanent;
}

server {
    server_name blog.itws.de;
    root /var/www/itws.de/blog;

    Include defaults.inc;
}

server {
     server_name ci.itws.de;
     root /var/www/itws.de/ci;

     Include defaults.inc;
}

Perfekt! Weniger Konfiguration als im Apache, aber mehr Performance

Ähnliche Artikel

• Debian: Von Apache zu Nginx – Teil 1: Vorwort
• Wordpress unter Nginx
• Debian: Von Apache zu Nginx – Teil 5: Basic Authentication

• Teil 1: Vorwort
• Teil 2: Installation und Konfiguration
• Teil 3: PHP
• Teil 4: Einen Tomcat anbinden
• Teil 5: Basic Authentication

In diesem und den folgenden Beiträgen (es gibt jeden Tag einen) berichte ich euch ein wenig über meine Migration von Apache zu Nginx. Es war eigentlich nicht beabsichtigt, dass da ganze fünf Beiträge draus werden, aber irgendwie wurde es doch ziemlich viel Text und das war dann für einen einzelnen Artikel etwas zu viel. Da könnte man ja fast den Eindruck bekommen, ich würde gerne schreiben … Keine Angst, das einzige was ich gerne in großen Mengen schreibe ist Programmcode

However, ich hatte meinen VPS (Debian 6) bisher immer mit dem apache2 betrieben und auch meine Entwicklungsumgebung auf meinem Desktop und dem Notebook ebenfalls. Das hatte mehrere Gründe. Zum Einen bin ich mit dem Apache aufgewachsen und hatte eigentlich nie etwas anderes verwendet. Ich war auch immer sehr zufrieden mit dem Apachen. Es ist ein guter Webserver mit einer großen Auswahl an mächtigen Modulen und er ist sehr leicht zu konfigurieren. Da ich aber ab und an gerne etwas Neues ausprobiere und immer Spaß daran habe, an meinem Server zu schrauben (auf Software-Ebene), wollte ich mal einen anderen Webserver ausprobieren. Genaugenommen war das Projekt yaana.de einer der Auslöser. Ich möchte da noch etwas Performance aus dem Server quetschen. Und dafür sollte ich mich zu allererst vom Apachen verabschieden.

Zur Auswahl stehen also – neben dem Apachen – Lighttpd und Nginx (ausgesprochen: engine-x).

Zu allererst ein kurzer Überblick der Vor- und Nachteile der drei Kontrahenten: Apache, Lighttpd und Nginx:

Der Apache

Vorteile

• Open Source & Kostenlos
• Community. Apache ist der am meist verbeiteste Webserver, die Community dahinter ist entsprechend gigantisch.
• Module. Es gibt unzählige Module für den Apache um praktisch jede Funktionalität abzudecken

Nachteile

• Performance. Der Apache ist um einiges langsamer als seine Konkurenten. Vor Allem wenn es um das Ausliefern von statischen Dateien geht.
• Stabilität. Der Webserver hat schon mit schwachen DoS/DDoS Attacken Probleme, der Arbeitsspeicher (und das Logverzeichnis) verbrauchen innerhalb kurzer Zeit viel Speicher.
• Veraltet und überfüllt. Außerdem ist die Standard Konfiguration meistens nicht optimal und muss angepasst werden.
• Die Entwicklung läuft vergleichsweise langsam.

Der Lighttpd

Vorteile

• Open Source & Kostenlos
• Leichtgewichtig. In Version 1.4.13 benötigt der Lighty nicht mehr als 2Mb RSS auf einem VPS. Ein einzelner Prozess erledigt alles, selbst wenn 100 Connections eingehen.
• Geschwindigkeit. Die Auslieferung von statischen Dateien geschieht mit einer unglaublichen Geschwindigkeit. Das FastCGI und das Proxy Serving ist ebenfalls rasant schnell.
• Module. Es gibt gefühlt unendlich viele Module mit einer guten Dokumentation.
• Mod_magnet ist eine Scripting Engine direkt im Webserver. Das Modul integriert Lua in lighttpd.
• Community. Einen Blog, ein Wiki/bug tracker und ein Forum. Hier findet man immer Hilfe

Nachteile

• Geringe Stabilität gerade was HTTPS+Proxy in Kombination mit Python oder Ruby angeht.
• Kein Mod_rewrite. Die Built-in rewriting engine ist Schrott, und das Portieren der Apache mod_rewrite Regeln ist nicht ganz einfach.
• Memory leaks. Und diese wurden seither nicht gefixed.
• Die Entwicklung läuft vergleichsweise langsam.

Nginx

Vorteile

• Open Source & Kostenlos
• Leichtgewichtig. Zwar nicht ganz so leicht wie der Lighty, aber dennoch nicht so Ressourcenhungrig wie der Apache.
• Schnell. Einie benchmarks haben gezeigt, dass Nginx deutlich schneller ist als der Lighty und der Apache. Gerade was die Auslieferung von statischen Inhalten angeht.
• Module. Ähnlich wie bei den beiden anderen Kontrahenten gibt es auch hier mehr Module als man benötigt. Während Lighttpd eine Lua scripting engine besitzt, kann man den Nginx mit dem Perl Interpreter aufmotzen.
• Besseres Rewrite Modul. Ein sehr viel besseres Rewrite Modul als Lighttpd mit komplexen Bedinungen. Das Portieren von mod_rewrite Regeln vom Apache ist vergleichsweise einfach.
• Stabil und keine leaks. Keine Probleme bekannt.
• Sehr schnelle Entwicklung: Es gibt fast monatlich Updates
• Die Konfiguration ist einfach und übersichtlich.

Nachteile

• Kleine Community. Es gibt einen IRC und ein Wiki. Dann wirds auch schon eng.
• Nginx kann keine FastCGI Prozesse erstellen. Das muss dann über einen externen fcgi spawner geschehen.

Der Lighttpd kam bei mir eigentlich nie wirklich in Frage. Das hatte zwei Gründe:

1. Ist die Konfiguration wirklich hässlich Sorry aber ich bin da etwas sensibel.
2. Weil der Lighttpd ein paar Memory Leaks hat, die seit Jahren nicht gefixt werden.
3. Hatte ich mir bereits vor längerer Zeit die Rewrite Rules vom Lighty angesehen – eher durch Zufall darauf gestoßen und dann aus Neugierde recheriert – das hat mich direkt abgeschreckt.

Also fällt auf meine Wahl auf den hochangepriesenen Nginx Proxy-/WebServer, mit dem mittlerweile rund 7% des World Wide Webs betrieben werden. Darunter high-visibility Platformen wie WordPress.com, Github, Ohloh, SourceForge, Golem.de uvm. Außerdem verspricht dieser nicht nur mehr Performance sondern auch eine einfachere Konfiguration.

Auch wenn mich der Part mit dem FastCGI Prozessen etwas nerven wird. Mal sehen vielleicht finde ich dafür ja noch eine saubere Lösung.

Anforderungen

Ich habe natürlich einige Anforderungen an den Webserver. Damit ich meinen Server migrieren kann, benötige ich folgende Funktionen:

• RewriteRules für .htaccess files
• Basic Authentication
• Virtuelle Hosts
• PHP
• Einen Proxy um den Java Webserver dahinter anzubinden

Nginx ist nicht nur ein Webserver sondern auch ein POP3/IMAP-Proxy und ein reverse Proxy. Letzteres Problem war also schonmal gar kein Thema weil der Server einfach exakt für solche Dinge designed wurde. Auch Mongrel lässt sich sehr sehr gut mit Nginx betreiben, wie ich gelesen habe.

PHP lässt sich über FastCGI anbinden, was deutlich performanter ist als mod_php für den Apachen, da PHP somit nicht bei jedem Request mitgestartet wird. Was mir hier noch etwas Sorgen bereitet, ist das nicht vorhandene Feature vom Nginx, FastCGI Prozesse zu starten. Glücklichwerweise bringt PHP5 einen eigenen FastCGI Prozess Manager mit sich: PHP-FPM. Das erleichtert die Anbindung von PHP ungemein.

Virtuelle Hosts, Basic Authtentication und RewriteRules sind für moderne Webserver ohnehin bereits Standardumfang. Und die Rewrite Rules von Nginx sehen sogar ganz brauchbar aus (wenn es um das Portieren von  mod_rewrite Regeln geht). Sollte also alles kein Thema sein.

Bleibt noch eine kleine Anforderung: Die Verzeichnis-Struktur. Meine bisherige Verzeichnis-Struktur sieht wie folgt aus:

/var/www/hostname/subdomain/

Entsprechend gibt es folgende Verzeichnisse:

• /var/www/itws.de/blog
• /var/www/itws.de/ci
• /var/www/yaana.de/www
• /var/www/yaana.de/blog

Und einige mehr.

Diese Struktur will ich natürlich beibehalten. Es hätte mich nun gewundert, wenn das nicht gehen würde. Nach kurzer Recherche, war ich mir sicher, dass das kein Thema sein wird.

Es kann also los gehen.

Ähnliche Artikel

• Debian: Von Apache zu Nginx – Teil 3: PHP
• Debian: Von Apache zu Nginx – Teil 4: Einen Tomcat anbinden
• Debian: Von Apache zu Nginx – Teil 2: Installation und Konfiguration