Warum aber gelten diese beiden als Vorzeige-Einrichtungen?
Gibt es solche Institutionen nicht in jeder (größeren) Stadt?
Haben diese dann auch so fancy Abkürzungen?
Heißt es etwa ‘SFPD‘ in San Francisco oder ‘LVPD‘ in Las Vegas?
Was machen die ganzen Städte, die sich nur einen Buchstaben als Abkürzung leisten können? ‘DPD‘ in Detroit? ‘PPD‘ in Phoenix?
Und kriegen sich Seattle, Sacramento und Salem nicht in die Haare, wenn sie sich die selbe Abkürzung teilen müssen?
Und kriegt Sigmar Gabriel, seines Zeichens Chef unserer Sozialdemokraten, Ärger wegen Amtsanmaßung, wenn er fähnchenwedelnd in eben diesen drei Städten zu Besuch ist?

Fragen über Fragen. Keine interessant genug um intensivere Recherchen zu bemühen, dennoch wüsste ich die Antworten schon ganz gerne.
Vielleicht kann mich ja einer meiner Leser in den Kommentaren erleuchten.

Mir ist bei meinen Arbeiten zum Projekt: Neuer Server aufgefallen, dass die History in der Shell zwar hilfreich ist, aber durchaus noch etwas verfeinert werden kann.

Nach kurzer Recherche konnte ich sie meinen Ansprüchen anpassen, in dem ich die Datei ~/.bashrc um folgende Zeilen erweiterte:

Der Parameter HISTCONTROL kann mit einen der folgenden Strangs gefüttert werden: ‘ignorespace‘, ‘ignoredups‘ oder ‘ignoreboth‘.

Durch ignorespace werden alle Zeilen, die mit einem Leerzeichen beginnen, nicht in die History aufgenommen.
Mit ignoredups werden doppelte Einträge entfernt, so dass immer nur der jüngste vorhanden bleibt.
Selbsterklärend ist nun ignoreboth: Dort werden einfach beide Funktionen übernommen.

Die eingetragene Zahl in HISTSIZE bestimmt, wieviele Einträge in der History gespeichert werden. Üblicherweise sollten die letzten 500 Zeilen nachvollziehbar sein.

HISTIGNORE enthält die Befehle, die nicht mit in die History aufgenommen werden sollen. Dadurch halte ich persönlich meine History sauber, in dem ich unnötige Zeilen wie ls oder exit von ihr fern halte.

Mit HISTTIMERFORMAT lasse ich einen Zeitstempel in der History anzeigen. Sehr hilfreich, wenn man mit mehreren Leuten in der Bash rumhängt oder beim Suchen einer Befehlszeile nur noch die Uhrzeit im Kopf hat.

Projekt: Neuer Server

Zuerst: Backup erneuern. Damit heißt meines nun 2012.01.10_02:26 und ist 512.76 MB groß.

Inzwischen haben wir einen funktionierenden Webserver, der mit allen grundlegenden Dingen umgehen kann. PHP in Verbindung mit MySQL kann also nun ohne Probleme genutzt werden.
Im Prinzip könnten wir jetzt unsere vHosts anlegen und beginnen, unsere Webprojekte hochzuladen, das werde ich jedoch noch nicht tun, da ich das Einpflegen von Daten (außer für Funktionalitätstests) erst ganz am Ende durchführe, um eine gewisse Routine zu entwickeln.
Immerhin möchte ich nicht jetzt vHosts anlegen, dann erstmal wieder was installieren, dann für die entsprechenden vHosts die Mailadressen anlegen… alles in einem Rutsch gefällt mir da doch besser.
Außerdem kann ich mir dann sogar vielleicht noch ein paar Skripte schreiben, um mir die Arbeit in Zukunft noch etwas zu vereinfachen.

Nun wollen wir unserem Server erstmal beibringen, mit eMails umzugehen. Der Plan sieht so aus:

Los geht’s.

Wir installieren alle erforderlichen Pakete:

# apt-get install postfix postfix-mysql

Wählt im Assistenten zunächst ‘Internet-Site‘ aus, danach gebt den FQDN eures Servers an.

Sollte euer Debian nicht ganz so minimal sein wie ihr dachtet, hat es vielleicht standardmäßig exim4 als Mailservice installiert. Ihr solltet zur Vorsicht einfach den Befehl hier durchlaufen lassen, um es zu deinstallieren, sollte es vorhanden sein:

# apt-get --purge remove 'exim4*'

Installieren von Dovecot und, testweise, Roundcube. Dann noch den Shell-IMAP-Client mutt, den wir später gut zum testen nutzen können.

# apt-get install dovecot-pop3d dovecot-imapd
# apt-get install roundcube
# apt-get install mutt

Dann fangen wir mal an unsere Datenbank vorzubereiten. Wer will, kann dies in phpMyAdmin machen, muss dafür meine Konsolenbefehle entsprechen anpassen. Ich werde der Einfachheit halber sämtliche SQL-Queries in der Shell durchführen.
Wir erstellen zu Anfang die Datenbank, die ich hier einfach mal ‘mailserver‘ nenne. Wir werden nach dem root-Kennwort gefragt, welches wir bei der Installation von MySQL angegeben haben:

# mysqladmin -p create mailserver

Nun loggen wir uns in die Datenbank ein und erstellen einen neuen Benutzer. Postfix benötigt definitiv keinen root-Zugriff auf unsere Datenbanken Ich wähle als Benutzer hier ‘mailuser‘ und als Kennwort ‘mailpass‘. Bitte wählt euer Kennwort sorgfältiger aus:

# mysql -p mailserver

> GRANT SELECT ON mailserver.*
TO 'mailuser'@'127.0.0.1'
IDENTIFIED BY 'mailpass';

Nun haben wir einen User für Postfix, der ausschließlich Leserechte für unsere Mail-Datenbank besitzt.
Möchten wir später Datensätze anlegen oder ändern, müssen wir uns einen weiteren User mit Schreibrechten anlegen oder den root-User nutzen.

Nun erstellen wir unsere Tabellen für virtuelle Domains, virtuelle User und virtuelle Aliases. Alles, was man eben so benötigt, um später vernünftig mit Mails umgehen zu können:

> CREATE TABLE `virtual_domains` (
  `id` int(11) NOT NULL auto_increment,
  `name` varchar(50) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

> CREATE TABLE `virtual_users` (
  `id` int(11) NOT NULL auto_increment,
  `domain_id` int(11) NOT NULL,
  `password` varchar(32) NOT NULL,
  `email` varchar(100) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `email` (`email`),
  FOREIGN KEY (domain_id) REFERENCES virtual_domains(id) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

> CREATE TABLE `virtual_aliases` (
  `id` int(11) NOT NULL auto_increment,
  `domain_id` int(11) NOT NULL,
  `source` varchar(100) NOT NULL,
  `destination` varchar(100) NOT NULL,
  PRIMARY KEY (`id`),
  FOREIGN KEY (domain_id) REFERENCES virtual_domains(id) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Damit wir nicht ganz dumm sterben zeige ich euch mal anhand von ein paar Testdaten die Struktur unserer Tabellen:

virtual_domains:

virtual_users:

virtual_aliases:

Durch die virtual_aliases Werden nun alle Mails an user2@example.com an user2@web.de weitergeleitet.
Analog jede Mail, die an user3@example.net geht an user3@gmx.net sowie user3@gmail.com.
Hierfür werden zwei Einträge in die Datenbanktabelle eingetragen.

Nun füttern wir unsere Datenbank mit den ersten Einträgen, damit wir später testen können, ob unsere Konfigurationen auch funktionieren.
In meinem Beispiel füge ich die Domain ‘bonsailinse.net‘ ein, einen User ‘mail@bonsailinse.net‘ mit Kennwort ‘vollgeheim‘ und zusätzlich noch eine Weiterleitung aller Mails an ‘admin@bonsailinse.net‘ nach ‘mail@bonsailinse.net‘:

> INSERT INTO `mailserver`.`virtual_domains` (
  `id` ,
  `name`
)
VALUES (
  '1', 'bonsailinse.net'
);

> INSERT INTO `mailserver`.`virtual_users` (
  `id` ,
  `domain_id` ,
  `password` ,
  `email`
)
VALUES (
  '1', '1', MD5( 'vollgeheim' ) , 'mail@bonsailinse.net'
);

> INSERT INTO `mailserver`.`virtual_aliases` (
  `id`,
  `domain_id`,
  `source`,
  `destination`
)
VALUES (
  '1', '1', 'admin@bonsailinse.net', 'mail@bonsailinse.net'
);

Nun beenden wir MySQL und dann bringen wir Postfix bei, wo in unseren Datenbanken es unsere virtuellen Domains, User und Aliase finden kann:

> exit
# nano /etc/postfix/mysql-virtual-mailbox-domains.cf

Damit Postfix Bescheid weiß, kriegt er die Config eingelesen:

# postconf -e virtual_mailbox_domains=mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf

Das Ganze wird dann fix getestet, bei einem geglückten Mapping sollte eine ‘1‘ als Rückmeldung kommen:

# postmap -q bonsailinse.net mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf

Das selbe Spiel nochmal für das Mapping der Mailboxen und der Aliase:

# nano /etc/postfix/mysql-virtual-mailbox-maps.cf

# postconf -e virtual_mailbox_maps=mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf

Testen:

# postmap -q mail@bonsailinse.net mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf

# nano /etc/postfix/mysql-virtual-alias-maps.cf

# postconf -e virtual_alias_maps=mysql:/etc/postfix/mysql-virtual-alias-maps.cf

Testen, diesmal müsste ‘mail@bonsailinse.net‘ als Zieladresse ausgegeben werden:

# postmap -q admin@bonsailinse.net mysql:/etc/postfix/mysql-virtual-alias-maps.cf

Phew. Kurze Verschnaufpause.

Jetzt sehen wir zu, dass nur die User ‘root’ und ‘postfix’ auf unsere Konfigurationfiles zugreifen können:

# chgrp postfix /etc/postfix/mysql-*.cf
# chmod u=rw,g=r,o= /etc/postfix/mysql-*.cf

Für die Konfiguration von Dovecot erstellen wir zunächst einen neuen Systemuser, der in Zukunft für den ganzen Mailkram zuständig sein wird. Ich wähle hier den User ‘vmail‘ mit der User-ID 5000 und die Gruppe ‘vmail‘ mit der Gruppen-ID 5000. Achtet darauf, dass die IDs noch nicht anderweitig belegt sind. Ihr könnt jede ID zwischen 1000 und 65000 nutzen, solange sie noch nicht verwendet wird (siehe ‘cat /etc/passwd‘).
Dann noch die Rechte für unser zukünftiges Mail-Verzeichnis setzen:

# groupadd -g 5000 vmail
# useradd -g vmail -u 5000 vmail -d /var/vmail -m

# chown -R vmail:vmail /var/vmail
# chmod u+w /var/vmail

Dann fangen wir mal an Dovecot zu konfigurieren:

# nano /etc/dovecot/dovecot.conf

Die erste Zeile definiert die Protokolle, die gestartet werden sollen. Hier könnt ihr bei Bedarf bspw. die unsicheren Varianten ohne ‘s‘ rauslöschen oder ausschließlich IMAP aktivieren.

Die zweite Zeile steht standardmäßig auf ‘yes‘, was sicherheitstechnisch auch super ist, allerdings kann es passieren, dass ihr unter der Verwendung diverser Mailprogramme diese Einstellung auf ‘no‘ setzen müsst:

Mit folgender Zeile teilen wir Dovecot mit, wo die Mailboxen unserer User liegen.
Mit der folgenden Konfiguration befinden sie sich stets unter /var/vmail/DOMAIN/USER/Maildir und liegen im maildir Format vor:

In der Sektion ‘auth default‘ sollten wir dem Part ‘mechanisms‘ die Methode ‘login‘ hinzufügen:

Damit Dovecot weiß, wo sich die Zugangsdaten der User befinden, suchen wir die Sektionen ‘passdb sql‘ und ‘userdb static‘ und sehen zu, dass sie folgendermaßen ausschauen:

Achja, wir sollten vielleicht noch die Sektion ‘passdb pam‘ auskommentieren (achtet auf die abschließende, geschwungene Klammer!), da Dovecot sonst auch nach lokalen Usern Ausschau hält, was uns nur unsere Logfiles mit Fehlern zumüllt.

Wir suchen die Sektion ‘socket listen‘ und bearbeiten sie wie folgt:

Ähnliches Spiel mit der Sektion ‘protocol lda‘, wobei ihr hier eine Mail-Adresse eintragen solltet, unter der ihr als Admin des Servers erreichbar seid:

Wenn ihr den log_path leer lasst, landen eure Logs zusammen mit anderen eMail-relevanten Logs in /var/log/mail.log. Definiert ihr hier einen anderen Pfad könnt ihr eventuell falsch konfigurierten Filtern oder ähnlichem auf die Schliche kommen.

Wir schließen die Datei und kümmern uns um die nächste Config:

# nano /etc/dovecot/dovecot-sql.conf

Dovecot neustarten und noch schnell die Rechte vernünftig setzen:

# /etc/init.d/dovecot restart
chgrp vmail /etc/dovecot/dovecot.conf
chmod g+r /etc/dovecot/dovecot.conf
chown root:root /etc/dovecot/dovecot-sql.conf
chmod go= /etc/dovecot/dovecot-sql.conf

Wir müssen Postfix dazu bringen mit Dovecot zu sprechen und fügen folgende Zeilen der Konfiguration von Postfix hinzu:

# nano /etc/postfix/master.cf

Dann Postfix neustarten und die Konfiguration einlesen lassen:

# postfix reload
# postconf -e virtual_transport=dovecot
# postconf -e dovecot_destination_recipient_limit=1

Dann testen wir mal, ob Mails auf dem Server ankommen.
Folgende Zeilen geben uns zuerst einen Überblick, ob der Speicherort der zukünftigen Mails erreichbar ist (das Verzeichnis sollte zunächst nahezu leer sein), dann senden wir eine Testmail und überprüfen im Anschluss, ob sich eine Verzeichnisstruktur aufgebaut hat:

# find /var/vmail
# echo test | mail mail@bonsailinse.net
# find /var/vmail

Sollte etwas schiefgegangen sein lohnt sich ein Blick in ‘/var/log/mail.log‘.
Ein weiterer Test stellt fest, ob bspw. IMAP funktioniert. Evtl. werdet ihr aufgefordert, einer Erstellung des Verzeichnisses /root/Mail zuzustimmen und etwaige SSL-Zertifikate zu akzeptieren. Einfach zustimmen. Wenn ihr eure Testmail einsehen könnt ist das schonmal ein sehr gutes Zeichen. Mit ‘q‘ beendet ihr Mutt:

# mutt -f imap://mail@bonsailinse.net@localhost

Dann stellen wir mal fix unseren SMTP so ein, dass er nur eMails von authentifizierten Usern annimmt. Dies ist schön einfach, da Postfix die Logindaten von den in Dovecot hinterlegten Usern mit nutzen kann:

# postconf -e smtpd_sasl_type=dovecot
# postconf -e smtpd_sasl_path=private/auth
# postconf -e smtpd_sasl_auth_enable=yes
# postconf -e smtpd_recipient_restrictions="permit_mynetworks permit_sasl_authenticated reject_unauth_destination"

An dieser Stelle erstelle ich mir SSL-Zertifikate, die natürlich nicht als “vertrauenswürdig” eingestuft werden. Wenn ihr Zertifikate zum Beispiel bei StartSSL erstellt habt oder gar eines gekauft habt, wisst ihr sicherlich auch, wie ihr sie einfügt.
Ansonsten hier die Vorgehensweise für selbst signierte Zertifikate.
Wichtig ist, dass ihr bei der Erstellung bei ‘common name‘ exakt die Domain eingebt, mit der sich die User einloggen sollen. Soll dies also ‘mail.example.com‘ sein, gehört genau dies dort rein.

# openssl req -new -x509 -days 3650 -nodes -out /etc/ssl/certs/dovecot.pem -keyout /etc/ssl/private/dovecot.pem
# chmod o= /etc/ssl/private/dovecot.pem
# /etc/init.d/dovecot restart

# openssl req -new -x509 -days 3650 -nodes -out /etc/ssl/certs/postfix.pem -keyout /etc/ssl/private/postfix.pem
# chmod o= /etc/ssl/private/postfix.pem
# postconf -e smtpd_tls_cert_file=/etc/ssl/certs/postfix.pem
# postconf -e smtpd_tls_key_file=/etc/ssl/private/postfix.pem

Projekt: Neuer Server

Unser Webserver läuft schonmal, bevor wir uns um das Anlegen weiterer vHosts kümmern wollen wir erstmal noch die restlichen Dinge installieren, die wir so benötigen. MySQL und so ein Kram eben.

Zuerst kümmern wir uns aber um unser Backup. Ich erwähnte ja schon, dass ich zwischendurch gerne mal was kaputtkonfiguriere und so Und damit ich den Namen des Backups leichter dem Stand meines Servers zuordnen kann, tippsel ich ihn wieder einfach hier rein:

Aktuell heißt mein Backup 2012.01.06_05:04 und ist 344.40 MB groß.

Nun können wir anfangen, unseren Server mit MySQL zu infizierenMySQL zu installieren:

# apt-get install mysql-server mysql-client

Der Installer fragt uns nach einem Admin-Kennwort, welches wir definitiv anlegen sollten. Nehmt bitte nicht das selbe wie für den root-Benutzer des Servers, ja?

Eine gute Konfiguration für den Anfang ist folgende (natürlich gehe ich hier von meinem Server aus, 1 bis 2 GB RAM sollten da schon eingebaut sein. Sonst sucht euch passende Werte im Internet oder belasst es bei den Standard-Einträgen):

# nano /etc/mysql/my.cnf

Ein Restart damit die Konfiguration angenommen wird:

# /etc/init.d/mysql restart

Eine optionale, aber empfehlenswerte Vorgehensweise an dieser Stelle ist das Ausführen der mysql_secure_installation, mit der wir ein paar Sicherheitsrisiken eliminieren:

# mysql_secure_installation

Die Fragen sind selbsterklärend, bis auf ein neues root-Kennwort (ihr habt ja hoffentlich bereits bei der Installation eines eingegeben) können sämtliche Fragen mit der Standard-Auswahl beantwortet werden. Lest es euch trotzdem durch, falls ihr bspw. Remote-Zugriff auf euren MySQL-Server benötigt solltet ihr diesen Punkt überspringen.

Bei der Installation von phpMyAdmin wird nach dem verwendeten Webserver gefragt, leider sind hier nur Apache und LIGHTTPD auswählbar. Also wählen wir keinen aus und beantworten auch die zweite Frage nach der Konfiguration der Datenbank mit dbconfig-common mit ‘Nein‘.

Dann passen wir unseren vHost an, damit nginx die phpMyAdmin-Installation auch findet.
Dazu erstellen wir eine neue Include-Datei, die dann in jedem vHost eingebunden wird, der phpMyAdmin erreichen können soll:

# apt-get install phpmyadmin
# nano /etc/nginx/phpmyadmin.inc

# nano /etc/nginx/sites-available/bonsailinse.net

nginx neustarten:

# /etc/init.d/nginx restart

Unter http://bonsailinse.net/phpmyadmin sowie http://bonsailinse.net/phpMyAdmin können wir nun den Login für unser MySQL-Verwaltungstool erreichen.

Projekt: Neuer Server

So, bevor ich jetzt irgendwas an meinem Server kaputt mache (ich hab da definitiv nen Hang zu. Benötige einen Undo-Knopf für sowas) erstelle ich an dieser Stelle ein komplettes Backup.

Bei netcup ist das glücklicherweise ziemlich einfach, ich erstelle das Backup im Verwaltungsbereich für die Server, da brauch ich kein Backuptool oder sonstiges bemühen.
In meinem Tarif habe ich zwei Backups frei, das heißt, ich kann hier und da ein wenig rumspielen und verschiedene Snapshots zurückspielen, falls ich mir bei irgendwelchen Installationen mal nicht ganz so sicher bin *g*.

Das Einzige, was ich nicht kann, ist dem Backup einen Namen oder eine Beschreibung zu geben, was es etwas einfacher machen würde, es dem jeweiligen Stand des Servers zuzuordnen. So muss ich mit einer Uhrzeit leben. Aber wofür habe ich denn ein Blog?! Ich schreib den Namen einfach hier rein, dann weiß ich immer, wo ich ihn finde

Das Backup zum aktuellen Stand hat also nun den Namen 2012.01.05_00:51 und ist 287.03 MB groß.

Wie bereits erwähnt möchte ich nicht mehr wie bisher Apache verwenden sondern gerne umsteigen. Ich habe mich nach kurzer Lektüre für den schlanken Webserver nginx (Gesprochen: En-gin-iX) entschieden. Das hat mehrere Gründe. Dazu hier ein kurzer Vergleich des Indianers, LIGHTTPD und nginx:

Meine Entscheidung fiel hiermit auf nginx, da ich mir viel von der Performance verspreche und keine Lust auf die hässliche Rewrite-Engine vom lighty habe, wenn es darum geht, die Permalinks von WordPress anzupassen.

Für FastCGI-Prozesse werde ich php-fpm nutzen, was gar nicht so kompliziert sein soll. Mal abwarten =/

Also, los gehts!

Wie bereits im ersten Teil angedeutet, holen wir uns die aktuelle Version von nginx aus dem Repository von Dotdeb, da wir hier alles so aktuell bekommen wie wir es benötigen und auf eine aufbereitete, etwas hübschere Standard-Konfiguration von nginx stoßen werden.

Wir installieren uns nginx, php und einige php-Module über apt-get:

# apt-get install nginx
# apt-get install php5 php5-fpm php-pear php5-common php5-mcrypt php5-mysql php5-cli php5-gd php5-suhosin php5-curl

Wir wechseln in das nginx Verzeichnis um ein paar Einstellungen vorzunehmen:

# cd /etc/nginx/
# nano nginx.conf

Die nun folgende Konfiguration ist das Beispiel, welches für meine Bedürfnisse passt, für euch ist die Lektüre vom Wiki eventuell interessant, um eure Konfigurationen anzupassen.

Wir entfernen den Standard-vHost und schreiben uns einen eigenen (der Name ist hier natürlich frei wählbar, der Übersicht halber am besten den Domainnamen verwenden). Dabei natürlich darauf achten, dass ihr eure Domain entsprechend eintragt und den vHost nach euren Bedürfnissen anpasst. Hier sei wieder auf das nginx-Wiki verwiesen:

cd /etc/nginx/sites-enabled
rm default
nano /etc/nginx/sites-available/bonsailinse.net

Da wir keine Lust haben, diesen ganzen Wulst für jeden einzelnen vHost neu einzutragen erstellen wir uns eine Datei, die wir einfach für jede Domain fix includen.

Damit sieht die Include-Datei nun so aus:

# nano /etc/nginx/defaults.inc

Dementsprechend ist unser vHost nun etwas kürzer:

# nano /etc/nginx/sites-available/bonsailinse.net

Ein neuer Symlink sorgt dafür, dass unser vHost auch aktiv ist:

# ln -s /etc/nginx/sites-available/bonsailinse.net /etc/nginx/sites-enabled/bonsailinse.net

Fröhliches Neustarten:

# /etc/init.d/nginx restart

Und den eben angelegten vHost am besten mit einer phpinfo testen:

# mkdir -p /var/www/bonsailinse.net/{www,tmp}
# chown -R root:www-data /var/www/bonsailinse.net
# chmod -R 0770 /var/www/bonsailinse.net
# cd /var/www/bonsailinse.net/www
# nano info.php

Ein Aufruf von http://bonsailinse.net/info.php zeigt mir jetzt meine PHP-Konfiguration an.
Bei euch sollte das nun auch funktionieren.

Projekt: Neuer Server

Zu Beginn kümmern wir uns um grundlegende Dinge, die einen neu aufgesetzten Server etwas brauchbarer machen. Die meisten Schritte sind als optional, aber empfehlenswert, einzustufen.

Das Projekt wird in mehrere Teile aufgeteilt, damit wir den Überblick nicht verlieren. Ich hoffe, dass die einzelnen Teile relativ zügig nacheinander online kommen können und das Projekt abgeschlossen werden kann. Drückt uns also die Daumen, dass wir nicht auf allzu hässliche Hindernisse stoßen. Die Links in der Box rechts werden entsprechend nach Veröffentlichung eines Artikels aktualisiert.

Wir loggen uns also als root ein und ändern zu allererst das Kennwort. Ich empfehle eine möglichst lange Zeichenfolge mit Ziffern und Sonderzeichen, das übliche eben.

# passwd

Der nächste Schritt sollte auf jeden Fall das Updaten des Systems sein. Vorher überprüfen wir noch die eingetragenen Repositories:

# nano /etc/apt/sources.list

Dort tragen wir, neben den von netcup bereits eingetragenen Mirrors noch den von Dotdeb ein, den wir später zum Beispiel für die Installation von nginx benötigen:

Da die Pakete von Dotdeb signiert sind müssen wir unserem System noch den GPG-Key bekannt machen, wenn wir nicht bei jedem Aufruf von apt eine Fehlermeldung provozieren wollen:

# wget http://www.dotdeb.org/dotdeb.gpg
# cat dotdeb.gpg | apt-key add -
# rm dotdeb.gpg

Nun können wir via apt-get das System aktualisieren:

# apt-get update && apt-get upgrade

Als nächstes kümmern wir uns um ein paar Kleinigkeiten wie die Serverzeit und die Ausgabesprache der Shell:

# dpkg-reconfigure tzdata

Dort Europe und Berlin auswählen, jeweils mit [Enter] bestätigen. Nun ist unsere Zeitzone eingestellt.

Eine automatisierte Zeiteinstellung können wir mit ntp erreichen. Bei Bedarf noch die Lieblingsserver in die ntp.conf eintragen:

# apt-get install ntp
# nano /etc/ntp.conf

# /etc/init.d/ntp restart

Da wir alle sehr faul sind, hätten wir die Ausgabe der Shell noch gerne in deutscher Sprache:

# apt-get install locales
# dpkg-reconfigure locales -plow

Dort wählen wir via [Leertaste] die Punkte de_DE ISO-8859-1, de_DE.UTF-8 UTF-8 und de_DE@euro ISO-8859-15 aus. Mit [Enter] bestätigen und in der nächsten Auswahl für einen der drei als Standard entscheiden. Ich persönlich favorisiere UTF-8. Die Änderungen sind nach einem erneuten Login in die Shell sichtbar. Spart euch die Mühe, haben wir eh gleich vor

Jetzt wird es Zeit, dass wir unseren sshd absichern. Ein neuer Benutzer ohne root-Rechte ist hier der erste Schritt. Der Name des Users sollte vielleicht nicht unbedingt leicht zu erraten sein, um eine erste Hürde für Skriptkiddies einzubauen:

# adduser [username]

Diesen User machen wir nun zu dem einzigen, der sich über SSH einloggen darf. Dazu ändern oder fügen wir folgende Zeilen in die ‘/etc/ssh/sshd_config‘ ein:

# nano /etc/ssh/sshd_config

Mit der ersten Zeile ändern wir den Port, über den wir SSH erreichen. Hier wählt optimalerweise einen zufälligen zwischen 49152 und 65535 aus und merkt ihn euch für zukünftige Logins. Die zweite und dritte Zeile sorgen dafür, dass sich der root-User nicht mehr und ausschließlich unser eben angelegter User einloggen kann:

Nun noch den Daemon neu starten:

# /etc/init.d/ssh restart

Im Anschluss in einem neuen Terminalfenster den Login mit dem neuen User versuchen. So sperrt ihr euch nicht komplett aus, sollte es nicht gleich geklappt haben. Denkt daran, beim Login nun den neuen Port zu nutzen!
Funktioniert der Login, kann im neuen Terminalfenster per ‘su‘ auf root gewechselt und das alte Fenster geschlossen werden.

Projekt: Neuer Server

Zu Weihnachten habe ich mir einen neuen Server gegönnt. Hoffnungslos overpowered für das, was er aktuell leisten muss (ein paar Blogs und diverse andere Kleinigkeiten), aber im Sonderangebot Und in diesem Sinne habe ich jetzt einen guten Puffer für zukünftige, eventuell größere Projekte (immerhin will ich den Server jetzt ein Weilchen behalten, und nicht in dem Moment dann schon wieder umsteigen müssen).

Da ich jetzt also eh von dem alten zum neuen Server umziehen muss, nutze ich die Chance und installier mir mal alles von Grund auf.
Kein vorgefertigtes Image von netcup, die ja auch ganz nett sind, sondern eine minimal Installation ohne vorinstallierte Dienste wie Webserver oder Admin Control Panels.

Nachdem ispCP nicht mehr offiziell weiterentwickelt wird und ich keine Lust habe, auf ein Stable-Release von i-MSCP zu warten, mir Froxlor nicht gefällt und ich gar nicht von Plesk oder Confixx anfangen möchte, habe ich mich entschlossen kein Admin Control Panel mehr einzusetzen.
Damit nehme ich mir zwar ein wenig Luxus was das Anlegen von Virtuellen Hosts angeht, aber all zu oft tut man das dann ja doch nicht und der Gewinn an Individualität und Konfigurationsmöglichkeiten schlägt meine Faulheit.

Als Grundinstallation dient also ein Debian Squeeze (64 Bit), die einzigen Dienste, die beim Systemstart nun vorhanden sind, sind der sshd für den Zugriff über SSH, der rsyslogd als zentrale Logverwaltung und cron.

Als Ziel setze ich mir erstmal ein System mit den nötigsten Diensten:

Dann wird weiter überlegt, zum Beispiel bin ich mir noch nicht sicher, ob ich ProFTP für den Zugriff via FTP benötige. DNS und son Kram wäre auch noch ne Idee, wie ich WebDAV (oder einen adäquaten Ersatz) mit nginx umsetze, und sonst mal schauen was mir noch so einfällt. Erstmal kümmere ich mich um die Sachen in der Liste oben.

.

Man kann sich mit etwas eine halbe Ewigkeit nicht mehr beschäftigt haben, irgendwann kriecht es dann doch aus der Versenkung und erschleicht sich Aufmerksamkeit.

So auch StudiVZ. Vor Jahren mal dort angemeldet weil man dort die Kontakte der Schulzeit pflegen konnte, wurde es doch relativ zügig durch Facebook abgelöst. Also den Account im VZ versauern lassen.
Löschen war damals noch doof, weil die Kontakte noch nicht alle bei FB zu finden waren, danach hab ich das Teilchen schlicht und einfach vergessen.

Aber was passiert heute? Ich krieg eine eMail von denen 0.o Soweit ich mich erinnern kann, habe ich noch nie eine bekommen.
Aber klar, man merkt im VZ auch, dass es bergab geht, und versucht die Aufmerksamkeit der Benutzer mit einem letzten Aufbäumen auf sich zu lenken.
Also haben die jetzt so ein tolles Featureeine nervige Belästigung eingeführt, bei dem man, schätzungsweise wöchentliche, Statusupdates empfängt.
Natürlich standardmäßig für jeden User aktiviert, so dass ich mich jetzt dort einloggen (erstmal das Kennwort erraten >.<) und die Benachrichtigungen manuell ausstellen muss.

Das ist übrigens das, was mich am meisten aufregt. Features, die einen mit Benachrichtigungen penetrieren, bei Implementierung ins System standardmäßig für alle zu aktivieren. Wenn ich das will, reicht doch eine Ankündigung auf deren Startseite, dass diese Funktion nun vorhanden ist. Aber haja, damit wären ja die abtrünnigen User nicht erreicht worden *seufz*

Dabei geht der Schuss, jedenfalls bei mir, nach hinten los: Ich werde mir jetzt die Mühe machen, alle meine Kontakte bei Facebook zu suchen um sie dort zu adden. Wer dort nicht zu finden ist, wird von mir im VZ angeschrieben. Dank des tollen neuen Features kann ich ja jetzt relativ sicher sein, dass sie diese Nachricht auch erhalten werden.

Ich nutze auch gleich mal die Gelegenheit, ein paar Leute auszusortieren. Bei manchen lohnt ein Mitschleppen des Kontaktes einfach nicht mehr, weil man sich eh nie schreibt und sich gegenseitig auch nicht wichtig genug ist. So läuft es nunmal.

Achjo: Wieso genau die Mail doppelt und nachts um halb 4 ankam, kann ich mir übrigens auch nicht erklären 0.o

Hooray! Wir haben einen Gewinner!
Nochmals Entschuldigung für die Verzögerung, deswegen auch jetzt keine langen Reden, der Gewinner des Gewinnspieles heißt Thermi! Er war der erste, der einen Kommentar hinterlassen hat und damit freut mich das besonders! Ich nehme dann jetzt direkt Kontakt mit Thermi auf und wünsche ihm ein spaßiges Wochenende beim Antesten der ganzen Spiele
Vielen Dank für eure Teilnahme und viel Glück beim nächsten Mal!

Vor kurzem startete das Humble Bundle in die dritte Runde.
Zu einem selbst bestimmbaren Preis konnte man sich ursprünglich fünf Spiele im Gesamtwert von circa $50 sichern. Auf halber Strecke der Laufzeit der Aktion gab es dann noch zwei Boni-Spiele oben drauf, also insgesamt sieben Spiele.

Sehr schön finde ich, dass man, bezahlte man mehr als den Durchschnittspreis, alle Spiele aus dem Humble Bundle #2 als Geschenk erhielt:

Insgesamt wurde das Bundle #3 372’380 mal verkauft und erzielte knapp 2,2 Mio Dollar.
Die jeweiligen Ausgaben konnten dabei vom Käufer an Entwickler und Charity-Vereine verteilt werden.
Ich habe damals bereits das Humble Frozenbyte Bundle gekauft und auch dieses mal wieder zugegriffen.

Für euch habe ich das Bundle einfach nochmal gekauft, und kann einen von euch hiermit mit insgesamt 13 Spielen glücklich machen. Super Deal, ihr bekommt Spiele und ich spende dafür ein wenig =)

Die Spiele sind komplett Plattform-unabhängig, also spielbar auf Linux, Mac OS X und Windows. Es gibt bei keinem der Spiele einen Kopierschutz, das heißt ihr könnt das Spiel so oft installieren wie ihr wollt. Zusätzlich bekommt ihr einen Key für Steam und/oder Desura, um die Spiele euren Bibliotheken hinzuzufügen.

Folgende Spieletitel sind enthalten:

Das Gewinnspiel findet ab sofort statt und läuft eine Woche. Ich würde euch bitten, nur teilzunehmen, wenn ihr nicht bereits in den Genuss gekommen seid, das Bundle gekauft zu haben

Ich werde nach einer Woche, also am 26.08.2011 01.09.2011, einen Gewinner auslosen.
Dabei gilt folgendes, um am Gewinnspiel teilzunehmen:

• Das Gewinnspiel endet am Donnerstag, den 25.08.2011,Mittwoch, den 31.08.2011 23:59:59 Uhr.
• Der Gewinner wird ausgelost und anschließend von mir kontaktiert.
  Bei Kommentaren hier im Blog sollte also eine gültige eMail-Adresse angegeben werden
• Der Gewinner wird zusätzlich auf meinem Blog namentlich erwähnt.
• Der Rechtsweg ist selbstverständlich ausgeschlossen.

Sämtliche Grafiken sind Eigentum der jeweiligen Spieleentwickler bzw. humblebundle.com und unterliegen entsprechendem Copyright.