HowTo: Node.js Installation unter Debian Squeeze / wheezy + Ubuntu
Step-by-Step Anleitung wie Node.js unter Debian Squeeze / Wheezy oder Ubuntu / Linux Mint installiert wird.
Da die Node.js in den Debian Repositories nur in der unstable (Sid) Version vorhanden sind, und unter Ubuntu bzw. Linux Mint nicht immer in der aktuellsten Version zur Verfügung stehen, ist es auf Linux Webservern der beste und sicherste Weg Node.js selbst zu kompilieren. Es sind nur sehr wenige Schritte dafür notwendig:
Abhängigkeiten installieren:
Folgende Pakete sind für die Installation notwendig und können bequem via apt-get installiert werden:
apt-get update apt-get install g++ curl libssl-dev
Option1: Download der Node.js Sourcen via git:
Es gibt die Möglichkeit, die node.js Sourcen direkt via git auszuchecken, oder direkt die tar.gz Datei von der Webseite downzuloaden. Bei git hat man den Vorteil auch aktuelle pre Releases zu testen, und die meisten Anwender und Admins haben ohnehin Git in Verwendung. Wer kein git verwenden möchte kann bei der nächsten Überschrift weiterlesen (Download via tar Package).
apt-get install git-core cd /usr/src git clone https://github.com/joyent/node.git cd node
Damit wir mit der stable Version und nicht mit einer Pre Entwickler Version arbeiten können, sollte zuvor die Version auf Stable umgestellt werden. (Aktuellste Stable Version kann auf http://nodejs.org/ nachgelesen werden)
git checkout v0.10.4
Option2: Download von Node.js via tar Package
Wer kein git verwenden möchte, kann auch das stable tar Package downloaden:
wget http://nodejs.org/dist/node-latest.tar.gz tar -xzvf node-latest.tar.gz cd node-v0.10.4
Installation von Node.js unter Debian und Ubuntu / Linux Mint
Der Kompilierungsvorgang kann unter Umständen einige Zeit in Anspruch nehmen, also geduldig bleiben
./configure make make install
Installierte Node.js Version ausgeben:
node -v
Ausgabe Stand 23.04.2013:
v0.10.4
QuickTipp: /bin/tar: Removing leading `/’ from member names
Die Warnung “/bin/tar: Removing leading `/’ from member names” kommt wohl den meisten Linux Usern ziemlich bekannt vor. Doch was bedeutet diese Warnung eigentlich und warum wird sie ständig angezeigt? Ganz einfach erklärt:
Der Befehl wird für unser Beispiel wie folgt eingesetzt um das Verzeichnis /etc in das Archiv etc.tar.gz zu packen und zu komprimieren:
tar -czf etc.tar.gz /etc
Ausgabe:
tar: Removing leading `/' from member names
Die Meldung hat absolut seine Richtigkeit und ist durchaus sinnvoll, denn der tar Befehl entfernt den ersten / (trailing Slash), der zu sichernden Dateien und Verzeichnisse und “relativiert” somit den Pfad (etc/)…
Wenn das nicht passiert, dann würde beim Entpacken des Archivs sämtliche vorhandene Dateien, im Beispiel unter /etc, durch neuere Dateien aus dem Archiv überschrieben werden.
Absolute Pfade im tar Befehl verwenden und Warnung entfernen
Damit die Warnung verschwindet können auch absolute Pfade verwendet werden. Hierzu wird der Flag “P” (–absolute-names) gesetzt. Dieser teilt dem tar Befehl mit, dass absolute Pfade verwendet werden sollen und der trailing Slash erhalten bleibt (/etc).
tar -czPf etc.tar.gz /etc
Die Warnung verschwindet.
Entpacken des Archivs mit absoluten Pfaden
Wenn das Archiv nun ganz normal entpackt wird, wird ebenfalls der trailing Slash entfernt. (Doppelte Absicherung vom tar Befehl, also keine Sorge)
tar -xzf etc.tar.gz /etc
Ausgabe:
tar: Removing leading `/' from member names
Wird das Archiv allerdings mit dem Flag -P entpackt, so wird der absolute Pfad verwendet und /etc wird komplett überschrieben.
tar -xzPf etc.tar.gz /etc
Movies as Code – Filme als Code dargestellt
Ziemlich Coole Webseite, wer sie noch nicht kennt: moviesascode.net
Filme werden als Codeschnipsel dargestellt. Hier ein paar Ausschnitte:
HowTo: Browser Caching im Apache Webserver aktivieren + htaccess mit mod_expires oder mod_headers
Browser Caching ist eine einfache Methode um den Traffic einer Webseite zu reduzieren und somit die Performance zu erhöhen. Zudem dauert die Einrichtung im Apache Webserver maximal fünf Minuten und sollte bei allen gängigen Webhosting Paketen unterstützt werden.
Browser Caching nutzen
Browser Caching mit mod_expires
Browser Caching mit mod_headers
Auswirkung und Fazit
Performance Test via Google Page Speed Insights
Auf Google Pages Speed Insights, kann man seine Website auf Geschwindigkeit (Performance) überprüfen lassen und erhält zudem eine detailierte Auswertung und sehr ernst gemeinte Verbesserungsvorschläge. Eine Überprüfung von www.sysadminslife.com sieht zB. (ohne aktiviertem Browser Cache) wie folgt aus:
Google sagt: ”Browser-Caching nutzen” – Leverage Browser Caching
Jeder moderne Webbrowser (Chrome, Firefox, Internet Explorer, etc) hat einen eingebauten Cache, was bedeutet: dass Dateien zwischengespeichert und nicht bei jedem Aufruf neu heruntergeladen werden müssen. Darunter fallen in der Regel Dateitypen wie Bilder, Stylesheets, Javascripts, etc.. Der Browsercache funktioniert allerdings nur dann vernünftig, wenn auch am Webserver entsprechende Regeln bzw. ein Ablaufdatum für die einzelnen Dateitypen festgelegt wird.
Ist eine entsprechende “expire” Regel aktiviert, so wird dem Browser vom Webserver mitgeteilt, dass zB. das Bild background.jpg für 7 Tage gecached werden kann. Der Browser muss das Bild somit nicht bei jedem Seitenaufruf neu laden, sondern behält es in seinem Zwischenspeicher. Das spart somit Traffic und dadurch auch Ladezeit.
Browser Caching aktivieren – htaccess mit mod_expires
Damit man das Browser Caching nun auf dem eigenen Root Server aktivieren kann, wird zuvor das Modul “mod_expires” aktiviert, falls es noch nicht aktiviert ist. Ein managed Webhosting Paket sollte das Modul eigentlich zur Verfügung stellen. Unter den gängigsten Linux Distributionen wird mod_expires folgendermaßen auf der Commandline aktiviert. Ein Neustart des Apache Prozess ist anschließend erforderlich:
a2enmod expires /etc/init.d/apache2 restart
Anschließend wird in die bestehende .htaccess Datei (falls vorhanden) oder in eine neue .htaccess Datei folgender Inhalt eingefügt. Der Teil kann auch direkt in die globale Apache Konfiguration oder in die Vhost Konfiguration geschrieben werden. Die If Anweisung schützt dabei den Apache Prozess, sodass angeführte “Expire Regeln” nur zum Einsatz kommen, wenn auch das Modul mod_expires aktiviert ist:
<IfModule mod_expires.c> ExpiresActive On ExpiresByType image/gif "access plus 7 days" ExpiresByType image/ico "access plus 7 days" ExpiresByType image/jpeg "access plus 7 days" ExpiresByType image/jpg "access plus 7 days" ExpiresByType image/png "access plus 7 days" ExpiresByType text/css "access plus 7 days" ExpiresByType text/javascript "access plus 7 days" ExpiresByType application/x-javascript "access plus 7 days" ExpiresByType application/javascript "access plus 7 days" </IfModule>
“ExpiresByType” spricht den MIME Type an und setzt via “access plus 7 days” den Cache Wert auf 7 Tage. Die entsprechenden Dateien bleiben also bis zu 7 Tage im Browser Cache erhalten. Hier kann natürlich auch ein höherer oder für gewisse MIME Types (css, xml, js, ..) auch ein niedrigerer Wert eingestellt werden. Je nach Anwendungsgebiet kann hier variiert werden. Mit 7 Tage haben wir allerdings gute Erfahrungen gemacht.
Alternative: Browser Caching mit mod_headers
Als Alternative zur Methode mit dem Modul mod_expires gibt es noch eine Variante mit dem Modul mod_headers. Hier können die Dateitypen direkt über die Dateiendungen angesprochen werden und nicht via MIME-Types:
a2enmod headers /etc/init.d/apache2 restart
Nachdem das Modul aktiviert wurde, kann folgender Teil wieder direkt in die .htaccess Datei oder in die Apache Konfiguration eingetragen werden.
<IfModule mod_headers.c> <FilesMatch “\.(gif|ico|jpeg|jpe|png|css|js)$”> Header set Cache-Control “max-age=604800, public” </FilesMatch> </IfModule>
Header set Cache-Control setzt den Wert für max-age auf 604800 Sekunden (7 Tage). Dem Browser wird somit mitgeteilt, dass die gespeicherten Dateien für 7 Tage aktuell sind und nicht erneut vom Server geladen werden müssen. Wenn man für andere Dateitypen noch verschiedene Ablaufdaten festlagen möchte, dann kann einfach eine weitere Zeile (<FilesMatch …. </FilesMatch>) eingefügt werden.
Auswirkung und Fazit
Sobald die htaccess Datei gespeichert wird, ist das Browser Caching aktiv. Eine Aktualisierung des Google Page Speed Insights sollte dabei sofort eine Score Verbesserung anzeigen:
Der Score nur durch die Aktivierung des Browser Caching von 87 auf 90 gestiegen. Das mag auf den ersten Blick nicht viel erscheinen, bringt aber tatsächlich ein wenig Geschwindigkeit und sollte daher auch genutzt werden. Warum Potential verschenken, wenn es so einfach umgesetzt werden kann?
Weitere Verbesserungsmöglichkeiten bietet die gzip Komprimierung einer Website und die Verwendung eines OPcache für PHP.
Aktivierte Apache Module anzeigen / deaktivieren / aktivieren
Anleitung wie man aktivierte Apache Module auf seinem Linux Webserver anzeigen lassen kann und wie diese deaktiviert (a2dismod) bzw. aktiviert (a2enmod) werden können.
Aktivierte Apache Module anzeigen lassen
Auf allen gängigen Linux Distributionen kann man einfach folgendem Befehl in der Commanline absetzten und man erhält eine Auflistung der aktivierten Apache Module. (Bei CentOS/RHEL wird apache2ctl durch httpd ersetzt) (Falls der Pfad nicht aufgelöst werden kann, einfach ein /usr/sbin/ davor hängen):
apache2ctl -M
oder
apache2ctl -t -D DUMP_MODULES
Beispielausgabe:
Loaded Modules: core_module (static) log_config_module (static) logio_module (static) mpm_prefork_module (static) http_module (static) so_module (static) actions_module (shared) alias_module (shared) auth_basic_module (shared) authn_file_module (shared) authz_default_module (shared) authz_groupfile_module (shared) authz_host_module (shared) authz_user_module (shared) autoindex_module (shared) cgi_module (shared) deflate_module (shared) dir_module (shared) env_module (shared) expires_module (shared) headers_module (shared) mime_module (shared) negotiation_module (shared) php5_module (shared) reqtimeout_module (shared) rewrite_module (shared) setenvif_module (shared) status_module (shared) Syntax OK
Die Ausgabe zeigt die geladenen Module mit den Werten static bzw. shared an.
static: Fix kompilierte Module – können nicht deaktiviert werden ohne dass der Apache neu kompiliert werden muss, was ich auf keinen Fall raten würde.
shared: Dynamisch geladene Module – können jederzeit, deaktiviert oder aktiviert werden. Man sollte jedoch wissen wofür und vor allem ob die aktivierten Module benötigt werden bevor man sie deaktiviert. Der Apache kann sonst in einen ziemlich “labilen” Zustand versetzt werden.
Apache Module unter Debian, Ubuntu, Linux Mint deaktivieren
Um ein Apache Modul auf Debian basierten Linux Distributionen zu deaktivieren verwenden wir den Befehl “a2dismod” und geben den entsprechenden Modulnamen an:
a2dismod MODULNAME
Beispiel:
a2dismod deflate
Deaktiviert das Modul deflate, welches zB. für die Komprimierung verwendet wird. Ein Neustart des Apache Dienstes ist anschließend notwendig:
/etc/init.d/apache2 restart
Apache Module unter Debian, Ubuntu, Linux Mint aktivieren
Um ein verfügbares Apache Modul auf Debian basierten Linux Distributionen zu aktivieren wird der Befehl “a2enmod” verwendet und geben den entsprechenden Modulnamen an:
a2enmod MODULNAME
Beispiel:
a2enmod ssl
Aktiviert das Modul ssl, um die HTTPS Verschlüsselung (Port 443) für den Apache zu aktivieren. Ein Neustart des Apache Dienstes ist anschließend notwendig:
/etc/init.d/apache2 restart
CentOS, RHEL Apache (HTTPD) Module deaktivieren / aktivieren
Unter RedHat Enterprise Linux und CentOS gibt es kein entsprechendes Verwaltungssystem (a2enmod/a2dismod), weshalb die mitgelieferten Module direkt in der Apache Konfigurationsdatei (/etc/httpd/conf/httpd.conf) via LoadModule geladen werden :
... LoadModule auth_basic_module modules/mod_auth_basic.so LoadModule auth_digest_module modules/mod_auth_digest.so LoadModule authn_file_module modules/mod_authn_file.so LoadModule authn_alias_module modules/mod_authn_alias.so LoadModule authn_anon_module modules/mod_authn_anon.so LoadModule authn_dbm_module modules/mod_authn_dbm.so LoadModule authn_default_module modules/mod_authn_default.so LoadModule authz_host_module modules/mod_authz_host.so LoadModule authz_user_module modules/mod_authz_user.so LoadModule authz_owner_module modules/mod_authz_owner.so LoadModule authz_groupfile_module modules/mod_authz_groupfile.so LoadModule authz_dbm_module modules/mod_authz_dbm.so LoadModule authz_default_module modules/mod_authz_default.so LoadModule ldap_module modules/mod_ldap.so ...
Nicht benötigte Module können hier mit einem # auskommentiert werden.
Zusätzliche httpd Module, welche zu einem späteren Zeitpunkt installiert werden, findet man als .conf Datei im Verzeichnis /etc/httpd/conf.d/ welches in die Apache Konfiguration eingebunden (included) wird.
Serverüberwachung / Monitoring mit ServerCheck24
Servermonitoring ist ein sehr wichtiger Bestandteil in modernen IT Infrastrukturen. Ist mein Webserver nicht erreichbar, verliere ich Kunden und somit Geld! Deshalb empfehle ich immer, überwacht eure Webserver. Ich habe mir das Produkt ServerCheck24 einmal genauer angesehen, mit dem es spielend möglich ist seine Server und ganzen Prozessabläufe zu überwachen, ohne lokaler Installation.
Kostenlosen 14 Tage Testaccount erstellen
ServerCheck24 ist kostenpflichtig und stellt verschiedene Lizenzierungspakete zur Verfügung, welche aber alle samt kostenlos getestet werden können. Die Registrierung ist sehr einfach gestaltet. Man wählt sein Paket aus und meldet sich kostenlos und unverbindlich für eine 14 Tage Testversion an, die man jederzeit in dieser Frist kündigen kann.
Name, Anschrift, Email Adresse eingeben und die IP oder den Hostnamen des zu überwachenden Servers (www.sysadminslife.com) eingeben. Anschließend wird eine Bestätigungsmail an die angegebene Mail Adresse gesendet, welche einen Code zur Verifizierung beinhaltet. Sobald der Verifizierungscode bestätigt wird, ist der Account auch schon aktiv.
Neue Dienste zur Überwachung definieren
Die Weboberfläche ist sehr übersichtlich gestaltet, sodass man nach dem Login sofort Dienste für die Serverüberwachung definieren kann. Dazu wählt man einfach einen der möglichen Dienste aus und klickt auf “Neuer Dienst”.
Im nächsten Schritt kann man die Parameter für den Dienst konfigurieren. Bevor man speichert sollte immer ein Test durchgeführt werden, damit man auch sicher gehen kann dass der Check funktioniert.
Im ersten Schritt definiere ich einen einfachen Dienst in Form eines Serverpings, da ich so immer sicherstellen kann dass der Server grundsätzlich Up ist – der Ping sollte bei den meisten Servern eine Antwort liefern..
Im nächsten Schritt können die Einstellungen zur Benachrichtigung und Intervalle des Dienstes konfiguriert werden:
*) Benachrichtigung – Bei welchem Status (Warnung oder Kritisch bzw. OK) wird ein Email und/oder eine SMS verschickt?
*) Kontakte – Wer soll im Falle eines Fehlers benachrichtigt werden? Hier können weitere Kontakte mit Mail Adresse bzw. Handynummer angelegt werden.
*) Überwachung – Wie oft soll der Dienst gecheckt werden und wann wird benachrichtigt?
*) Wartungsintervalle – Gibt es Wartungsarbeiten in denen der Check pausiert werden soll oder gibt es wiederholende Wartungszeiträume zu bestimmten Zeiten (Sicherung in der Nacht, Täglicher Shutdown, etc…)? Vorgenommen Einstellungen können später natürlich jederzeit geändert bzw. modifiziert werden.
Hier sind einige Dienste die ich auf meinem Server zum Testen hinzugefügt habe:
- FTP
- HTTP
- MySQL
- PING
- SMTP
- SSH
Wie sieht ein Mail bzw. eine SMS aus, wenn ein Check fehl schlägt?
Ich habe zum Testen einen HTTP Check absichtlich fehlschlagen lassen, indem ich nach einem String suchen lies, den es gar nicht auf der Webseite zu finden gibt – so sieht die Meldung per Email bzw. SMS aus. Die Geschwindigkeit der Benachrichtigung hängt von den gewählten Einstellungen ab:
Auswertungen
ServerCheck24 bietet zu den Checks natürlich auch ausführliche Berichte bzw. Auswertungen über definierte Zeiträume an. So sieht die Auswertung für den Ping Check aus:
Fazit:
Die Einrichtung von ServerCheck24 ist kinderleicht und einfache Dienste sind schnell konfiguriert ohne dass ein Fachwissen von Nöten ist. Das Webinterface bietet alles, was das Herz begehrt. So kann innerhalb von weniger Minuten und mit wenigen Mausklicks ein neuer Check hinzugefügt werden.
Der Preis ist absolut überschaubar wenn man bedenkt, dass bereits für 4,90 EUR monatlich ein Server mit fünf Checks überwacht werden kann. Die Pakete sind in drei unterschiedlichen Ausführungen zu haben (small/medium/large). Für Monitoring Einsteiger und einfache Webmaster ist ServerCheck24 ein tolles Produkt, für erfahrenere Systemadministratoren, welche 100te Server betreiben, ist wohl eine Inhouse Lösung wie Nagios oder Icinga besser geeignet.
Letzte Beiträge
- Icinga 1.9 Installation unter Debian squeeze + wheezy – aktuellste Version
- QuickTipp: klassischen GNOME Desktop (classic GNOME) unter Ubuntu installieren
- Debian-Ubuntu apt-get: The Following Packages Were Automatically Installed And Are No Longer Required
- Debian 7.0 Wheezy veröffentlicht – Das sind die Neuerungen
- Apache Webserver Directory Listing (Verzeichnisauflistung) deaktivieren / aktivieren














