The Elder Scrolls Online – Announcement Trailer

Wie euch vielleicht aufgefallen ist, ist hier in letzter Zeit nicht mehr so viel los.
Liegt in erster Linie daran, dass ich versuche, mein Theme komplett umzubauen, zum anderen an so Kleinigkeiten wie einem kaputten Notebook ;___;

Auf jeden Fall werde ich mich jetzt verstärkt daran setzen, Tempo zu machen. Neu aufgesetzt habe ich dieses Blog auch mal fix, damit ich mit dem neuen Theme “sauber” starte.
Bis dahin sieht das Blog hier noch hässlich aus, Bilder werde ich nach und nach einpflegen, damit alles funktioniert.

Blogkommentare konnte ich mit umziehen, das einzige was mir aufgefallen ist und nicht funktioniert sind die Kommentar-Abonnements. Die sind leider nicht ohne großen Aufwand zu retten, und da in den ganzen alten Beiträgen eh nichts mehr passiert spare ich mir den Stress.

Wünscht mir Glück, dass sonst alles reibungslos klappt und freut euch auf ein schickes Design *g*

In diesem Sinne noch ein schönes (und für die, die ihren Urlaub schlau geplant haben: langes) Wochenende.

Die Linse

Dadurch, dass es jetzt bei uns etwas bergauf geht, haben wir ein wenig bessere Chancen, uns den einen oder anderen Cache anzuschauen.

[image size="small" align="left" icon="zoom" lightbox="true" group="geocaching" quality="100"]http://mediathek.bonsailinse.net/2012/03/IMG_1202.png[/image]Heute haben wir, witzigerweise auf dem Weg zum Arzt, einen der wenigen Caches hier im Dorf angesteuert. Eine kleine Filmdose versteckt in einem Baum beherbergte das Logbuch, in das wir uns nicht ohne Stolz eintrugen.

Auf jeden Fall hat uns das Fieber gepackt, die nächste Schatzsuche wird in meinem Elternhaus stattfinden, in dem irgendwo noch ein altes Garmin GPS-Gerät rumfliegt

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.

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

[code]
export HISTCONTROL=ignoreboth
export HISTSIZE=500
export HISTIGNORE="&:ls:history:exit"
export HISTTIMEFORMAT="[%d.%m.%Y - %T] "
[/code]

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.

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:

[note align="center"]
Postfix um Mails aus dem Internet zu ziehen und den ganzen Basiskram zu erledigen
Dovecot um Mails auf dem Server zu speichern und sie dem User via Pop3 / IMAP zugänglich zu machen
MySQL um Domains, Useraccounts und Forwarding-Regeln zu verwalten
AMaViS zum Scannen eingehender Mails mit Hilfe von ClamAV und SpamAssassin
Clam Antivirus für einen Virus-Check
SpamAssassin für die Einordnung von Spam

evtl. Roundcube als Webmail-Lösung, falls es nötig werden sollte.
[/note]

Los geht’s.

Wir installieren alle erforderlichen Pakete:

[pre]
# apt-get install postfix postfix-mysql
[/pre]

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

[info]
Achtung: Hier wird ein FQDN (Fully Qualified Domain Name) benötigt.
Der Hostname eures Servers sollte hoffentlich aus so einem bestehen.
Dies ist nicht einfach nur eure Domain, sondern, salopp gesagt, inklusive einer Subdomain. Typischerweise bietet sich server.bonsailinse.net oder ähnliches an. Überprüfen könnt ihr das übrigens mit ‘hostname -f‘
[/info]

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:

[pre]
# apt-get –purge remove ‘exim4*’
[/pre]

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

[pre]
# apt-get install dovecot-pop3d dovecot-imapd
# apt-get install roundcube
# apt-get install mutt
[/pre]

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:

[pre]
# mysqladmin -p create mailserver
[/pre]

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:

[pre]
# mysql -p mailserver
[/pre]

[info]
Achtung: Ich verwende für die Anzeige von MySQL-Queries das Präfix ‘>‘, um zu verdeutlichen, dass wir uns in der Datenbank befinden (wie sonst die Raute ‘#‘ für die Eingabe in der Shell).
Bitte kopiert das Zeichen nicht mit, es gehört nicht zu dem Query!
[/info]

[pre]
> GRANT SELECT ON mailserver.*
TO ‘mailuser’@’127.0.0.1′
IDENTIFIED BY ‘mailpass’;
[/pre]

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:

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

[pre]
> 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;
[/pre]

[pre]
> 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;
[/pre]

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

virtual_domains:
[styled_table]

id	name
1	example.com
2	example.net

[/styled_table]

virtual_users:
[styled_table]

id	domain_id	email	password
1	1	user1@example.com	hd7wo93n64
2	1	user2@example.com	j3bh1n0d74
3	2	user3@example.net	o30bq4lh5z

[/styled_table]

virtual_aliases:
[styled_table]

id	domain_id	source	destination
1	1	user2@example.com	user2@web.de
2	2	user3@example.net	user3@gmx.net
3	2	user3@example.net	user3@gmail.com

[/styled_table]

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‘:

[pre]
> INSERT INTO `mailserver`.`virtual_domains` (
`id` ,
`name`
)
VALUES (
’1′, ‘bonsailinse.net’
);
[/pre]

[pre]
> INSERT INTO `mailserver`.`virtual_users` (
`id` ,
`domain_id` ,
`password` ,
`email`
)
VALUES (
’1′, ’1′, MD5( ‘vollgeheim’ ) , ‘mail@bonsailinse.net’
);
[/pre]

[pre]
> INSERT INTO `mailserver`.`virtual_aliases` (
`id`,
`domain_id`,
`source`,
`destination`
)
VALUES (
’1′, ’1′, ‘admin@bonsailinse.net’, ‘mail@bonsailinse.net’
);
[/pre]

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

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

[code]
user = mailuser
password = mailpass
hosts = 127.0.0.1
dbname = mailserver
query = SELECT 1 FROM virtual_domains WHERE name='%s'
[/code]

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

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

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

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

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

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

[code]
user = mailuser
password = mailpass
hosts = 127.0.0.1
dbname = mailserver
query = SELECT 1 FROM virtual_users WHERE email='%s'
[/code]

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

Testen:

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

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

[code]
user = mailuser
password = mailpass
hosts = 127.0.0.1
dbname = mailserver
query = SELECT destination FROM virtual_aliases WHERE source='%s'
[/code]

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

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

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

Phew. Kurze Verschnaufpause.

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

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

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:

[pre]
# 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
[/pre]

Dann fangen wir mal an Dovecot zu konfigurieren:

[pre]
# nano /etc/dovecot/dovecot.conf
[/pre]

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:

[code]
protocols = imap imaps pop3 pop3s
disable_plaintext_auth = no
[/code]

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:

[code]
mail_location = maildir:/var/vmail/%d/%n/Maildir
[/code]

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

[code]
mechanisms = plain login
[/code]

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:

[code]
passdb sql {
args = /etc/dovecot/dovecot-sql.conf
}

userdb static {
args = uid=5000 gid=5000 home=/var/vmail/%d/%n/Maildir allow_all_users=yes
}
[/code]

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:

[code]
socket listen {
master {
path = /var/run/dovecot/auth-master
mode = 0600
user = vmail
}

client {
path = /var/spool/postfix/private/auth
mode = 0660
user = postfix
group = postfix
}
}
[/code]

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

[code]
protocol lda {
auth_socket_path = /var/run/dovecot/auth-master
postmaster_address = admin@bonsailinse.net
mail_plugins = sieve
log_path =
}
[/code]

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:

[pre]
# nano /etc/dovecot/dovecot-sql.conf
[/pre]

[code]
driver = mysql
connect = host=127.0.0.1 dbname=mailserver user=mailuser password=mailpass
default_pass_scheme = PLAIN-MD5
password_query = SELECT email as user, password FROM virtual_users WHERE email='%u';
[/code]

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

[pre]
# /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
[/pre]

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

[pre]
# nano /etc/postfix/master.cf
[/pre]

[error]
Vorsicht! Achtet darauf, dass die zweite Zeile eingerückt sein muss! Außerdem gehört das nach dem $ noch ein die zweite Zeile, die Zeile ist einfach nur zu lang für mein Blog.
[/error]

[code]
dovecot unix - n n - - pipe
flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -f ${sender} -d ${recipient}
[/code]

Dann Postfix neustarten und die Konfiguration einlesen lassen:

[pre]
# postfix reload
# postconf -e virtual_transport=dovecot
# postconf -e dovecot_destination_recipient_limit=1
[/pre]

[info]An dieser Stelle habe ich persönlich meinen Server neugestartet.
Nach so vielen neu installierten Programmen und geänderten Konfigurationen ist das gar keine so schlechte Idee, um sicherzustellen, dass alles von jedem angenommen wurde. Außerdem sieht man in den Logfiles des Servers, ob alles einwandfrei gestartet werden konnte.
[/info]

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:

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

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:

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

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:

[pre]
# 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”
[/pre]

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.

[pre]
# 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
[/pre]

[info]Ich persönlich nutze für die eMail-Adresse des Serveradmins IMAPs, SMTP läuft bei mir weiterhin unverschlüsselt, da ich dort immer wieder auf Probleme mit diversen Mailprogrammen stoße.
Solltet ihr dort also Probleme bekommen, kann ich euch leider nicht helfen.
IMAPs und POP3s sollten aber einwandfrei funktionieren.[/info]

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:

[pre]
# apt-get install mysql-server mysql-client
[/pre]

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):

[pre]
# nano /etc/mysql/my.cnf
[/pre]

[code]
key_buffer = 512M
max_heap_table_size = 128M
max_allowed_packet = 16M
thread_stack = 128K
thread_cache_size = 8
max_connections = 250
table_cache = 512
query_cache_limit = 16M
query_cache_size = 128M

log_slow_queries = /var/log/mysql/mysql-slow.log
long_query_time = 2
log-queries-not-using-indexes
[/code]

Ein Restart damit die Konfiguration angenommen wird:

[pre]
# /etc/init.d/mysql restart
[/pre]

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

[pre]
# mysql_secure_installation
[/pre]

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:

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

[code]
location /phpmyadmin {
root /usr/share/;
index index.php index.html index.htm;
location ~ ^/phpmyadmin/(.+\.php)$ {
try_files $uri =404;
root /usr/share/;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $request_filename;
include /etc/nginx/fastcgi_params;
}
location ~* ^/phpmyadmin/(.+\.(jpg|jpeg|gif|css|png|js|ico|html|xml|txt))$ {
root /usr/share/;
}
}

location /phpMyAdmin {
rewrite ^/* /phpmyadmin last;
}
[/code]

[pre]
# nano /etc/nginx/sites-available/bonsailinse.net
[/pre]

[code]
server {
server_name bonsailinse.net www.bonsailinse.net;

root /var/www/bonsailinse.net/www;

include defaults.inc;
include phpmyadmin.inc;
}
[/code]

nginx neustarten:

[pre]
# /etc/init.d/nginx restart
[/pre]

[info]
Übrigens: An dieser Stelle würde es auch reichen, die nginx-Konfiguration mit ‘/etc/init.d/nginx reload‘ neu laden zu lassen, jedoch starte ich nginx immer komplett neu, zum einen dauert das nicht wesentlich länger und zum anderen bekomme ich so schneller mit, wenn er aus irgendwelchen Gründen (meist eine falsche Konfiguration) nicht mehr starten will.
[/info]

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

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:

[one_third]
Apache

+ Open Source
+ unendlich viele Module
+ große Community
+ viele Tutorials
- schlechte Performance
- vglb. geringe Stabilität
- Langsame Entwicklung
- Veraltet und überfüllt
- Keine zufriedenstellende Standard-Konfiguration
[/one_third]

[one_third]
LIGHTTPD

+ Open Source
+ unendlich viele Module
+ gute Community
+ unglaublich ressourcenschonend
+ gute Geschwindigkeit
- vglb. geringe Stabilität
- miese Rewrite-Engine
- nicht so schnelle Entwicklung
- ungefixte Memory-Leaks
[/one_third]

[one_third_last]
nginx

+ Open Source
+ genügend Module
+ ziemlich ressourcenschonend
+ geniale Geschwindigkeit
+ stabil und ohne bekannte Leaks
+ vernünftige Rewrite-Engine
+ rasante Weiterentwicklung
+ schöne & übersichtliche Konfiguration
- kleine Community
- kein FastCGI, externer fcgi-Spawner erforderlich
[/one_third_last]

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:

[pre]
# 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
[/pre]

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

[pre]
# cd /etc/nginx/
# nano nginx.conf
[/pre]

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.

[code]
index index.php index.htm index.html;
keepalive_timeout 15;

client_max_body_size 20M;
client_body_buffer_size 128k;

##
# Gzip Settings
##

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;
[/code]

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:

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

[code]
server {
server_name bonsailinse.net www.bonsailinse.net;

root /var/www/bonsailinse.net/www;

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;
}

location ~ \.php$ {
try_files $uri =404;

fastcgi_split_path_info ^(.+\.php)(.*)$;
fastcgi_pass 127.0.0.1:9000;
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;
}
}
[/code]

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:

[pre]
# nano /etc/nginx/defaults.inc
[/pre]

[code]

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;
}

location ~ \.php$ {
try_files $uri =404;

fastcgi_split_path_info ^(.+\.php)(.*)$;
fastcgi_pass 127.0.0.1:9000;
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;
}
[/code]

Dementsprechend ist unser vHost nun etwas kürzer:

[pre]
# nano /etc/nginx/sites-available/bonsailinse.net
[/pre]

[code]
server {
server_name bonsailinse.net www.bonsailinse.net;

root /var/www/bonsailinse.net/www;

include defaults.inc;
}
[/code]

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

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

Fröhliches Neustarten:

[pre]
# /etc/init.d/nginx restart
[/pre]

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

[pre]
# 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
[/pre]

[code]
phpinfo();
?>
[/code]

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

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.

[info]
Info: Sollte im Folgenden mal ein Befehl nicht funktionieren, weil die Shell ‘Kommando nicht gefunden.‘ zurückliefert, kann es sein, dass ich das entsprechende Programm bereits zwischendurch installiert, dies aber nicht dokumentiert habe, oder es bereits im Image von netcup enthalten war (so bspw. der Fall bei ‘wget‘).
Einfach via ‘apt-get install [Programmname]‘ nachinstallieren, im Normalfall ist keine gesonderte Konfiguration erforderlich.
[/info]

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.

[pre]
# passwd
[/pre]

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

[pre]
# nano /etc/apt/sources.list
[/pre]

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:

[code]
deb http://debian.netcup.net/debian squeeze main
deb-src http://debian.netcup.net/debian squeeze main

deb http://packages.dotdeb.org stable all
[/code]

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:

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

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

[pre]
# apt-get update && apt-get upgrade
[/pre]

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

[pre]
# dpkg-reconfigure tzdata
[/pre]

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:

[pre]
# apt-get install ntp
# nano /etc/ntp.conf
[/pre]

[code]
server 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst
[/code]

[pre]
# /etc/init.d/ntp restart
[/pre]

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

[pre]
# apt-get install locales
# dpkg-reconfigure locales -plow
[/pre]

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:

[pre]
# adduser [username]
[/pre]

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:

[pre]
# nano /etc/ssh/sshd_config
[/pre]

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:

[code]
Port 52942
PermitRootLogin no
AllowUsers [username]
[/code]

Nun noch den Daemon neu starten:

[pre]
# /etc/init.d/ssh restart
[/pre]

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.

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:

[note title="" align="center"]
nginx (mit php-fpm) als Webserver
MySQL inklusive phpMyAdmin
Postfix und Dovecot für den ganzen eMail-Kram
[/note]

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.

.