Mittwoch, 21. August 2013

OpenVPN Debian Wheezy + Seagate Dockstar

Dieser Blogpost beschreibt die Einrichtung einer sicheren Verbindung zwischen 2 gesicherten Netzwerken - kurz eines VPN-Netzwerks. Das folgende Bild beschreibt meinen Aufbau.

Wir haben 2 Netzwerke (Netzwerk A: 192.168.100.0/24 und Netzwerk B: 192.168.0.0/24) welche wir via VPN miteinander verbinden wollen. Im Netzwerk A gibt es einen öffentlich erreichbaren Rechner der als Router, Firewall und VPN Gateway funktioniert. Im Netzwerk B gibt es eine Router&Firewall Box, ebenfalls mit öffentlicher IP, welche die Verbindung zum Internet über einen gängigen Provider herstellt. Im Netzwerk B verwenden wir den Dockstar als VPN Gateway, da die Router&Firewall Box keine VPN Funktionalität bietet. In beiden Netzwerken befinden sich weitere Rechner welche von jeder Seite aus erreichbar sein sollen. Im folgenden werden wir Schritt für Schritt ein Zertifikat basiertes VPN installieren und konfigurieren.
OpenVPN unterscheidet in seiner Konfiguration zwischen Clients und Servern. Wir werden daher den OpenVPN Server auf den Gateway in Netzwerk A und den Client auf der Dockstar in Netzwerk B installieren.

Installation und Konfiguration (Netzwerk A)


Als erstes installieren wir das openvpn Packet mittels apt-get.
apt-get install openvpn
Nun nutzen wir easy-rsa um die benötigten Zertifikate für den Server zu erstellen. Wir erstellen uns als erstes ein Zertifikat Verzeichnis /etc/openvpn/easy-rsa und kopieren dann den Inhalt von easy-rsa in dieses Verzeichnis.
mkdir -p /etc/openvpn/easy-rsa
cd /etc/openvpn/easy-rsa
cp /usr/share/doc/openvpn/examples/easy-rsa/2.0/* .
Nun editieren wir die vars Datei entsprechend unseren Bedürfnissen und passen folgende Werte an.
export KEY_SIZE=2048
export KEY_COUNTRY="DE"
export KEY_PROVINCE="yourProvince"
export KEY_CITY="yourCity"
export KEY_ORG="yourOrganization"
export KEY_EMAIL="yourEMail"
Anschliessend erzeugen wir als erstes unsere Certificate Authority (ca).
. ./vars
./clean-all
./build-ca
Es werden nun hauptsächlich die default Werte aus der vars verwendet. Bei der Frage nach den common-name geben wir unseren Servernamen ein, z.B. "vpn.example.com". Nun erzeugen wir noch ein Zertifikat für den Server und unsere Client Zertifikate.
./build-key-server vpn.example.com
Bei der Abfrage nach den common Name geben wir erneut "vpn.example.com" ein. Anschliessend bestätigen wir noch die beiden Fragen "Sign the certificate? [y/n]" und "1 out of 1 certificate requests certified, commit? [y/n]" jeweils mit y. Um ein Client Zertifikat für "client1" zu erzeugen geben wir nun noch folgendes Kommando ein. Bei der Frage nach dem common Name geben wir wieder "vpn.example.com" ein.
./build-key client1
Als nächstes erzeugen wir nun die Diffie-Hellman Parameter. Dieser Vorgang kann eine Weile dauern...
./build-dh
Wir haben jetzt alle benötigten Zertifikate und Schlüsselim Verzeichnis /etc/openvpn/easy-rsa/keys vorliegen. Wir haben ebenfalls bereits für einen Client (client1) ein Zertifikat erstellt. Ein Client (clientX) benötigt bei sich lokal dann jeweils 3 Dateien (clientX.crt, clientX.key und die ca.crt).

Erstellen der Konfigurationsdatei für Netzwerk A

Wir erstellen uns nun eine serverseitige openvpn Konfiguration. Dazu erstellen wir uns eine networkA.conf Datei im /etc/openvpn Verzeichnis.
touch /etc/openvpn/networkA.conf
Anschliessend editieren wir die Datei wie folgt...
#dynamic tun device
dev tun
# P2P local VPN endpoint is 10.0.0.1, remote VPN endpoint is 10.0.0.2
ifconfig 10.0.0.1 10.0.0.2
#SSL/TLS key exchange
tls-server
#Certs/Keys/DH parameters
dh /etc/openvpn/easy-rsa/keys/dh2048.pem
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/vpn.mindfab.net.crt
key /etc/openvpn/easy-rsa/keys/vpn.mindfab.net.key

#downgrade to UID,GID nobody after initialization
user nobody
group nobody
#enable LZO compression
comp-lzo
#ping every 15 seconds (keep statefull firewalls open)
ping 15
#verbosity level (3 medium)
verb 3


#push our own network (192.168.100.0/24 - see picture above) to the client
push "route 192.168.100.0 255.255.255.0"

#allow routing to the client network (192.168.0.0/24)
route 192.168.0.0 255.255.255.0

#openvpn 2.0 introduced script security, we need at least level 2.
script-security 2
#execute external script to add tun routing...
up ./networkA.up
Die einzelnen Parameter sind in den openvpn Beispielen ganz gut dokumentiert - siehe auch /usr/share/doc/openvpn/examples/sample-config-files/. Als Anhaltspunkt kann hierzu tls-office.conf dienen. Nun erstellen wir noch die networkA.up Datei welche die Routing Tabelle beim aufbauen der VPN Verbindung anpassen soll.
touch networkA.up; chmod +x networkA.up
Wir fügen folgende Route hinzu:
#!/bin/sh
route add -net 10.0.0.0 netmask 255.255.255.0 gw $5
Der interessante Teil unsere Konfiguration ist der, wo wir die verschiedenen Netzwerke für den Client verfügbar machen. Dies geschieht über den push "route 192.168.100.0 255.255.255.0" Befehl. Dieser Befehl veranlasst den Client bei Verbindungsaufbau lokal bei sich eine Route (route add -net 192.168.100.0 netmask 255.255.255.0 gw 10.0.0.1) einzufügen. Der Befehl route 192.168.0.0 255.255.255.0 veranlasst den Server einen entsprechenden Routing Eintrag in seine Routing Tabelle einzufügen. Somit kann dann Netzwerk A nach Netzwerk B als auch umgekehrt Netzwerk B nach Netzwerk A routen.

Achtung, bitte auch die Anmerkungen ganz unten lesen...

Installation und Konfiguration (Netzwerk B)

Als erstes installieren wir das benötigte openvpn Packet auf der Dockstar. Anschliessend kopieren wir die erzeugten Client Schlüssel von den Gateway aus Netzwerk A auf den VPN Gateway(Dockstar) in Netzwerk B.
root@dockstar: cd /etc/openvpn
scp root@222.100.100.222:/etc/openvpn/easy-rsa/keys/client1.crt .
scp root@222.100.100.222:/etc/openvpn/easy-rsa/keys/client1.key .
scp root@222.100.100.222:/etc/openvpn/easy-rsa/keys/ca.crt .

Erstellen der Konfigurationsdatei für Netzwerk B

Auf unserer Dockstar erstellen wir nun eine Client Konfigurationsdatei...
touch /etc/openvpn/client.conf
und editieren diese wie folgt.
client
dev tun
remote 222.100.100.222 1194
resolv-retry infinite
nobind
user nobody
group nobody
persist-key
persist-tun
ca ca.crt
cert client1.crt
key client1.key
ns-cert-type server
comp-lzo
verb 3
ifconfig 10.0.0.2 10.0.0.1

Firewall/Gateway Anmerkungen

In unseren Setup sind wir auf die Konfiguration (öffnen der Firewalls) nicht eingegangen. In unseren Beispiel ist es daher noch nötig die Firewall auf den Gateway in Netzwerk A auf UDP Port 1194 (default OpenVPN Port) zu öffnen. Weiterhin ist es notwendig, das Packete von den tun Interfaces auf das lokale Netzwerk geroutet werden dürfen (Forwarding chain), sowie das IP Forwarding aktiviert ist (siehe auch hier unter Punk 2) - dieser Punkt muss für beide Gateways erfüllt sein.
Da auf der Client Seite (Netzwerk B) der VPN Server nicht auf den Gateway liegt bedarf es hier noch weiterer Anpassungen bzgl. des Routings. In der Firewall&Gateway Box fügen wir daher noch 2 weitere (erweiterte) Routing Einstellungen hinzu.

route add -net 10.0.0.0 netmask 255.255.255.0 gw 192.168.0.2
route add -net 192.168.100.0 netmask 255.255.255.0 gw 192.168.0.2
Mit diesen Einstellungen werden Packete die für Netzwerk A bestimmt sind an unseren VPN Gateway 192.168.0.2 weitergeleitet.

Testen der Konfiguration

Wir starten nun den openvpn Daemon auf beiden Gateways...
service openvpn start #restart
Debug Informationen können wir über die daemon.log erhalten.
tail -f /var/log/daemon.log
Wir sollten nun die Gegenseiten der tun Devices pingen können.
root@dockstar: ping 10.0.0.1
ping 192.168.100.100

root@workstation1: ping 192.168.0.2
ping 192.168.0.1
ping 192.168.0.100

Referenzen

  • http://openvpn.net/index.php/open-source/documentation/howto.html
  • http://dev.shyd.de/2011/02/dockstar-howto-setup-openvpn-debian/

Dienstag, 13. August 2013

fetchmail + POP3/IMAP + SSL/TLS + CERTCK (Debian Wheezy)

Im folgenden möchte ich beschreiben wie man fetchmail so einrichtet, das die E-Mails über eine gesicherte Verbindung (SSL-Verschlüsselung) abgeholt werden. Fetchmail soll ausserdem die Zertifikate prüfen um Man-In-The-Middle Attacks zu verhindern. Obwohl ich diese Installation und Konfiguration auf einen Debian Wheezy System ausgeführt habe sollte diese auch problemlos auf anderen Linux Derivaten/Versionen funktionieren.
Fetchmail soll in dieser Konfiguration die empfangenen E-Mails an procmail übergeben. Procmail realisiert eine einfache Filterung und übergibt die E-Mails dann an cyrus IMAP.

Installation der Packete

Als erstes Installieren wir die benötigten Packete/bzw. stellen sicher das diese bereits installiert sind (z.B. openssl).
apt-get install fetchmail procmail openssl
Nun beginnen wir damit procmail zu konfigurieren. Wir erstellen uns eine einfache Konfiguration welche E-Mails für nur einen Nutzer entgeben nimmt und diese direkt an cyrus übergibt. Später kann die procmail Konfiguration um E-Mail Filter/weitere Nutzer erweitert  werden. Wir erstellen und editieren daher die Datei /etc/procmailrc wie folgt.
DELIVER="/usr/sbin/cyrdeliver"
LOGFILE="/var/log/procmail.robert"
VERBOSE=on

:0w
| $DELIVER -a -q robert robert
Wir haben nun einen procmail Filter erstellt welcher alle eingehenden E-Mails an die Mailbox robert auf den cyrus IMAP Server via cyrdeliver ausliefert. Als nächstes konfigurieren wir den fetchmail Daemon.

Konfiguration fetchmail Daemon

Als erstes teilen wir fetchmail mit das dieser als Daemon/Service laufen soll. Wir editieren dazu die Datei /etc/default/fetchmail und ändern das START_DAEMON flag von no auf yes.
START_DAEMON=yes
Um fetchmail Scripte zu debuggen kann man in dieser Datei unter Options beispielsweise das verbose Flag setzen. Sobald die Scripte laufen sollte man die Optionen aber wieder löschen/auskommentieren.
OPTIONS=-v
Nun erstellen wir uns die Fetchmail Konfigurationsdatei. Wir legen dazu eine zentrale Konfigurationdatei unter /etc/fetchmailrc an. Wichtig ist auch das wir die Datei entsprechend schützen da hier später u.a. die Passwörter für unsere Postfächer stehen.
touch /etc/fetchmailrc
chmod 0600 /etc/fetchmailrc
chown fetchmail. /etc/fetchmailrc
Wir konfigurieren nun ein POP3 GMX Postfach. Als Beispiel soll die E-Mail Adresse example@gmx.de mit Passwort "secret" dienen. Die E-Mails sollen über POP3s (POP3 over SSL) abgeholt werden. Wir editieren die /etc/fetchmailrc wie folgt.
set daemon 300
set syslog
set postmaster root
poll pop.gmx.de with protocol POP3
       user 'example@gmx.de' there with password 'secret'
       mda '/usr/bin/procmail' options
       keep
       ssl sslcertck sslcertpath /etc/ssl/certs
       sslfingerprint ""
In den ersten drei Zeilen definieren wir den Poll Intervall (Abfrage der E-Mails aller 300 Sekunden, wir logen nach /var/log/syslog und definieren den postmaster.
Weiterhin haben wir jetzt ein gmx POP3 Postfach mit den Nutzer 'example@gmx.de' definiert. Die abgerufenen E-Mails werden alle an procmail übergeben. Für Testzwecke haben wir die Option keep angegeben. Diese Option verhindert das löschen der E-Mails von den POP3 Server, diese Option können wir später (sobald alles funktioniert) durch fetchall ersetzen. Die folgenden Optionen (ssl, sslcertck, sslcertpath und sslfingerprint) teilen fetchmail mit das SSL zu verwenden ist und das ausserdem die Zertifikate zu prüfen sind. Im folgenden werden wir nun noch den Eintrag für den sslfingerprint bestimmen.

Fetchmail sslfingerprint bestimmen

Wir werden nun für das gmx.de Postfach den md5 sslfingerprint bestimmen. Wir verwenden hierzu die openssl Tools.
root@xx:~# openssl s_client -connect pop.gmx.de:995 | openssl x509 -md5 -fingerprint
MD5 Fingerprint=3D:0C:9A:45:53:86:0B:5B:C8:65:0A:63:9D:EF:F3:C9
-----BEGIN CERTIFICATE-----
MIIEoDCCA4igAwIBAgIQQpEipkhuiS++nRBu
...
...
N+wf54qfy6f6vHW18AA1W3cshTXO6FmC805IA2lstqYjX9nc
-----END CERTIFICATE-----
Wir verbinden uns hierzu mit den SSL-Client von openssl mit den POP3 Server von gmx.de. Wichtig, wir verbinden uns auf Port 995 (Pop3s). Die Ausgabe des ersten openssl aufrufes "pipen" wir als Eingabe in den 2.Aufruf, in welchen wir jetzt den md5 fingerprint des Server Zertifikates extrahieren. Wir erhalten dann eine Ausgabe mit den Fingerprint und den Zertifikat. Wir kopieren den so erhaltenen fingerprint nun in unsere fetchmailrc.
poll pop.gmx.de with protocol POP3
       user 'example@gmx.de' there with password 'secret'
       mda '/usr/bin/procmail' options
       keep
       ssl sslcertck sslcertpath /etc/ssl/certs
       sslfingerprint "3D:0C:9A:45:53:86:0B:5B:C8:65:0A:63:9D:EF:F3:C9"
Nun können wir unseren Daemon testen...
service fetchmail start

tail -f /var/log/syslog

Referenzen

  • http://blog.busstra.net/?p=648
  •  http://www.chambreuil.com/2008/01/19/fetchmail-procmail-cyrus-sasl-ldap-roundcube-getlive
  • http://email.about.com/od/gmxmailtips/f/GMX_Mail_IMAP_Server_Settings.htm
  • http://www.madboa.com/geek/openssl/
  • http://www.gagravarr.org/writing/openssl-certs/others.shtml#ca-openssl

Montag, 12. August 2013

Squirrelmail + Cyrus + Sieve + avelsieve (auf Debian Wheezy)

Im folgenden möchte ich die Installation des avelsieve Plugins für Squirrelmail unter Debian Wheezy mit cyrus imapd beschreiben. In einen anderen Post hatte ich bereits beschrieben wie man Squirrelmail unter lighttpd installiert. Aufbauend auf diesen Post und auf unserer Cyrus Imapd Installation werden wir nun avelsieve installieren.

Installation des Plugins

Als ersten besorgen wir uns das Plugin aus dem Subversion Repository (siehe auch avelsieve Webseite) da es u.a. in Revision 1091 einige Patches für PHP 5.4 gab und diese Patches noch nicht im stable oder devel Release sind.
  1. Nun editieren wir die config.php und machen Debian Wheezy spezifische Anpassungen. (Bei mir lief das Plugin nicht "out-of-the-box".)
    $sieveport = 4190;
    $preferred_mech = "PLAIN LOGIN DIGEST-MD5";
    Auf meinen Debian lief der sieve Daemon auf Port 4190 anstatt auf Port 2000 (default). (Ein "cat /etc/services | grep sieve" sollte u.a. 4190/tcp zurückliefern.)
  2. Nun aktivieren wir noch das Plugin über squirrelmail-configure.
    squirrelmail-configure
    -> Menu Auswahl Punkt 8
    -> Plugin avelsieve und javascript_libs hinzufügen
    -> Konfiguration speichern

Konfiguration imapd/cyrus

Mein cyrus verwendet saslauthd als Authentifizierungs Mechanismus. Wichtig bei meiner Konfiguration war das in der /etc/imapd.conf als sasl Mechanismus nicht nur PLAIN sondern auch LOGIN mit eingetragen ist. Ich habe noch CRAM-MD5 und DIGEST-MD5 aktiviert.
sasl_mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5
Mit dieser Änderung verschwand dann auch folgende Fehlermeldung "Could not log on to timsieved daemon on your IMAP server localhost."

Sonntag, 11. August 2013

Bereitstellung von Webserverdiensten (http, https) auf einer virtuellen Maschine mit nginx als Reverse Proxy (Teil 2)

Im 1.Teil hatten wir uns bereits mit der Einrichtung von nginx als http Reverse Proxy beschäftigt. In diesem Teil wollen wir nginx als SSL http Reverse Proxy einrichten. Als Zertifikat verwenden wir ein sogenanntes "self-signed certificate" für die Domain "ssl.mindfab.net".

Zertifikat erstellen

Zuerst erstellen wir das Verzeichnis wo unser Zertifikat für die Domain mail.mindfab.net liegen soll.
root@xx: cd /etc/nginx
root@xx: mkdir -p ssl/ssl.mindfab.net

root@xx: cd ssl/ssl.mindfab.net
Nun erstellen wir uns als erstes einen private Key.
root@xx:/etc/nginx/ssl/ssl.mindfab.net# openssl genrsa -des3 -out ssl.mindfab.net.key 2048
Generating RSA private key, 2048 bit long modulus
.................................+++
..........+++
e is 65537 (0x10001)
Enter pass phrase for ssl.mindfab.net.key:
Verifying - Enter pass phrase for ssl.mindfab.net.key:

Als nächstes erzeugen wir ein CSR (Certificate Signing Request). Hierbei ist es wichtig das der später zu verwendende Domain Name (https://ssl.mindfab.net) unter Common Name eingetragen wird.
root@xx# openssl req -new -key ssl.mindfab.net.key -out ssl.mindfab.net.csr

Enter pass phrase for ssl.mindfab.net.key:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Saxony
Locality Name (eg, city) []:Dresden
Organization Name (eg, company) [Internet Widgits Pty Ltd]:MINDFAB.NET
Organizational Unit Name (eg, section) []:IT
Common Name (e.g. server FQDN or YOUR name) []:ssl.mindfab.net
Email Address []:admin@mindfab.net

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Als nächstes soll das Passwort von dem Private Key entfernt werden damit nginx ohne Passwort Eingabe automatisiert starten kann.
root@xx# cp ssl.mindfab.net.key ssl.mindfab.net.key.bak
root@xx# openssl rsa -in ssl.mindfab.net.key.bak -out ssl.mindfab.net.key

Enter pass phrase for ssl.mindfab.net.key.bak:
writing RSA key
Nun sollten wir folgende Dateien in unserem Verzeichnis haben.

root@xx# ls -l
-rw-r--r-- 1 root root 1062 Aug 10 17:05 ssl.mindfab.net.csr
-rw-r--r-- 1 root root 1679 Aug 10 17:11 ssl.mindfab.net.key
-rw-r--r-- 1 root root 1751 Aug 10 17:10 ssl.mindfab.net.key.bak
Schliesslich müssen wir das Zertifikat noch selbst signieren...
openssl x509 -req -days 365 -in ssl.mindfab.net.csr -signkey ssl.mindfab.net.key -out ssl.mindfab.net.crt
Signature ok
subject=/C=DE/ST=Saxony/L=Dresden/O=MINDFAB.NET/OU=IT/CN=ssl.mindfab.net/emailAddress=admin@mindfab.net
Getting Private key
Jetzt müssen wir noch nginx so konfigurieren das er unser Zertifikat verwendet. Wir passen daher unsere nginx Konfiguration entsprechend an.
vim /etc/nginx/conf.d/default.conf

## 192.168.100.12 -> ssl.mindfab.net ##
upstream sslmindfabnet  {
      server 192.168.100.12:80;
}

## Start https://ssl.mindfab.net ##
server {
    listen       443;
    ssl on;
    server_name  ssl.mindfab.net;

    # SSL cert files #
    ssl_certificate    /etc/nginx/ssl/ssl.mindfab.net/ssl.mindfab.net.crt;
    ssl_certificate_key    /etc/nginx/ssl/ssl.mindfab.net/ssl.mindfab.net.key;

    ssl_protocols    SSLv3 TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers        RC4:HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers    on;
    keepalive_timeout    60;
    ssl_session_cache    shared:SSL:10m;
    ssl_session_timeout    10m;   

    access_log  /var/log/nginx/ssl-ssl.mindfab.net.access.log;
    error_log  /var/log/nginx/ssl-ssl.mindfab.net.error.log;

    ## send request back to ssl.mindfab.net ##
    location / {
     proxy_pass  http://sslmindfabnet;    
     proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
     proxy_redirect off;
     proxy_buffering off;
     proxy_set_header         Accept-Encoding    "";   
     proxy_set_header        Host            $host;
     proxy_set_header        X-Real-IP       $remote_addr;
     proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
     proxy_set_header         X-Forwarded-Proto $scheme;
     add_header             Front-End-Https on;   
   }
}
## End ssl.mindfab.net ##
Nun starten wir den nginx Daemon neu und testen unsere Konfiguration.

service nginx reload

openssl s_client -connect ssl.mindfab.net:443

Referenzen

  • http://www.cyberciti.biz/faq/howto-linux-unix-setup-nginx-ssl-proxy/

Samstag, 10. August 2013

Installation von Squirrelmail mit Lighttpd

Problembeschreibung

E-Mails sollten immer und von überall aus erreichbar sein. Hierfür habe ich einen IMAP Server. Ein Web Interface soll den problemlosen Zugang zu den E-Mails auf diesen Server ermöglichen.

Lösungsansatz

Als E-Mail Server dient der cyrus IMAP Server. Als Web Interface habe ich mich für squirrelmail entschieden, da es funktional, einfach zu konfigurieren und durch Plugins erweiterbar ist (z.B. sieve). Ziel soll sein, das man über lynx http://localhost die Login Seite von squirrelmail angezeigt bekommt. Später soll dann nginx als SSL Reverse Proxy vor diesen Rechner geschalten werden (siehe anderer Post).

Installation von Lighttpd

Da Lighttpd unter Debian als Packet verfügbar ist können wir es direkt installieren.
apt-get install lighttpd
Anschliessend können wir z.B. mit lynx die Installation des Webservers testen.
lynx localhost
Wenn nun eine "Placeholder" Seite erscheint können wir mit der PHP Installation weitermachen.

Installation von PHP

Da Lighttpd CGI Unterstützung hat verwenden wir das Debian Packet php5-cgi um PHP in Lighttpd zu realisieren.
apt-get install php5-cgi

Konfiguration von Lighttpd und PHP

In der Datei /etc/php5/cgi/php.ini kommentieren wir folgende Zeile aus.
cgi.fix_pathinfo=1
Die Konfigurationsdatei von Lighttpd /etc/lighttpd/lighttpd.conf ändern wir wie folgt. Unter server.modules fügen wir "mod_fastcgi" ein...
server.modules = (
        "mod_access",
        "mod_alias",
        "mod_compress",
        "mod_redirect",
        "mod_fastcgi",
#       "mod_rewrite",
)
Am Ende der Datei fügen wir dann noch die Konfiguration des Handlers hinzu...
fastcgi.server = ( ".php" => (( "bin-path" => "/usr/bin/php5-cgi", "socket" => "/tmp/php.socket" )))
 Abschliessend wir der Server neu gestartet...
service lighttpd restart

Installation und Konfiguration von Squirrelmail

Eine sehr gute Anleitung um Squirrelmail zu installieren und initial zu konfigurieren findet sich hier.

Kurz zusammengefasst müssen wir folgende Schritte ausführen. Als erstes wird das Packet installiert.
apt-get install squirrelmail
Dannach rufen wir zur Konfiguration squirrelmail-configure auf.
squirrelmail-configure
Squirrelmail kommt mit vorkonfigurierten Optionen für die verschiedenen IMAP Server (Taste "D"). Ich habe hier cyrus IMAP ausgewählt, siehe auch andere Blog Einträge.

Nun müssen wir noch den lighttpd konfigurieren, damit dieser beim Zugriff auf den Server die Squirrelmail Quellen verwendet. Hierzu editieren wir die Datei /etc/lighttpd/lighttpd.conf und fügen am Ende folgende Zeilen hinzu.

# For squirrelmail alias.url += ("/" => "/usr/share/squirrelmail/" )
Nun starten wir lighttpd neu und können testen ob wir die Login Seite von squirrelmail bekommen.
service lighttpd restart
lynx http://localhost

Referenzen

  • http://www.howtoforge.de/anleitung/installation-von-lighttpd-mit-php5-und-mysql-unterstutzung-auf-debian-etch/
  • http://blog.coldtobi.de/1_coldtobis_blog/archive/285_squirrelmail_and_lighttpd_--_an_installation_guide_--.html

Installation eines Debian Servers mit Software Raid-1 im Degraded Mode

Problembeschreibung


Die Frage warum man einen Linux Server mit Software Raid-1im Vorfeld (während der Installation/Konfiguration) mit einen "degraded" Raid-1 installieren möchte ist mehr als berechtigt. Folgendes Szenario hat mich jedoch hierzu bewogen.
Ein Dell PowerEdge SC1435 sollte einen anderen Server ersetzen. Der alte Server wurde mit 2 Festplatten im Software Raid-1 Verbund betrieben. Der neue sollte ebenfalls 2 (jedoch grössere) Festplatten bekommen. Wer den Dell SC1435 kennt, der weiss das nur 2 SATA Anschlüsse vorhanden sind. Das Problem war nun: Wie bekomme ich die Daten von der alten Festplatte relativ problemlos auf die neue Festplatte?

Lösungsansatz

Während der Installation des Dell Systems wurden sowohl die neue als auch die alte Festplatte in den Server eingebaut. Somit waren alle SATA Kanäle belegt und beide Raids liegen zu dieser Zeit im degraded Modus (da jeweils eine Festplatte fehlte). Nun habe ich im Debian Installer (Wheezy) auf der neuen Festplatte (sda) ein Software Raid-1 konfiguriert. Hierzu habe ich die Festplatte nach Wunsch in 2 Partitionen (System/Daten sda1 -> "md0" und Swap sda2 -> "md1") partitioniert. Als Verwendung der Paritionen geben wir natürlich bei beiden Linux Software Raid an. Anschliessend konfigurieren wir das Software Raid mit 2 md Devices. Beim erzeugen der Devices geben wir an, das wir 2 Disks/Devices haben und keine Spar Disks. Nun soll man die Devices für den Verbund auswählen. Hier wählen wir für "md0" NUR "/dev/sda1" aus, keine weiteren! Dasselbe wiederholen wir dann für "md1" wo wir NUR "/dev/sda2" auswählen. Der Installer nimmt dies erstaunlicherweise ohne sich zu beschweren.
Anschliessend führen wir die Installation zu Ende und Konfigurieren unser System mit den benötigten Diensten. Irgendwann erreichen wir den Punkt wo wir die Daten von den alten System kopieren möchten. Hierzu mounten wir einfach die alte Festplatte (falls nicht bereits geschehen) und kopieren was wir benötigen. Nach dem erfolgreichen kopieren fahren wir das System herunter und tauschen die alte Festplatte gegen die 2. neue Festplatte. Nun müssen wir nur noch das Raid-1 neu bauen lassen.

Als erstes müssen wir hierzu auf der 2. Festplatte (/dev/sdb) eine völlig identische Partitionierung wie auf der ersten Festplatte (/dev/sda) herstellen. Hierfür kann man "sfdisk" verwenden.
sfdisk -d /dev/sda | sfdisk /dev/sdb
.
.
.
Successfully wrote the new partition table
Re-reading the partition table ...
.
.
Die Ausgabe ist ziemlich verbose und sollte irgendwo die Meldung beinhalten das die Partitionstabelle erfolgreich geschrieben wurde.

Als nächstes lassen wir uns sicherheitshalber mal den Raid Status einschliesslich der zugeordneten Partitionen anzeigen.
root@xx:~# cat /proc/mdstat
Personalities : [raid1]
md1 : active (auto-read-only) raid1 sda2[0]
      97980288 blocks super 1.2 [2/1] [U_]
     
md0 : active raid1 sda1[0]
      1855336256 blocks super 1.2 [2/1] [U_]
     
unused devices: <none>

Nun sehen wir das wir bei "md0" die Partition "sda1" enthalten ist, und wir als 2. Partition "sdb1" hinzufügen müssen (für "md1" ist dies "sdb2").


root@xx:~# mdadm --manage /dev/md0 --add /dev/sdb1
mdadm: added /dev/sdb1
root@xx:~# mdadm --manage /dev/md1 --add /dev/sdb2
mdadm: added /dev/sdb2
Das System resynchronisiert nun das Raid Array, den Status hierzu können wir z.B. mit mdstat überprüfen.
root@xx:~# watch -n5 cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 sdb2[2] sda2[0]
      97980288 blocks super 1.2 [2/1] [U_]
          resync=DELAYED
    
md0 : active raid1 sdb1[2] sda1[0]
      1855336256 blocks super 1.2 [2/1] [U_]
      [>....................]  recovery =  0.4% (8669312/1855336256) finish=276.1min speed=111432K/sec
    
unused devices: <none>

Referenzen:

  • http://www.cyberciti.biz/tips/linux-raid-increase-resync-rebuild-speed.html
  • http://www.howtoforge.com/replacing_hard_disks_in_a_raid1_array