Tag Archive: debian

Mailserver From Scratch (Debian 8)

Mailserver From Scratch

Nach bald zwei Jahren, wenig freier Zeit, viel Unentschlossenheit und den üblichen Dramen, die einem das Leben um die Ohren wirft, revanchiere ich mich mit einer Neuauflage zum „Mailserver Artikel“.

Es mag einiges noch unaufgeräumt wirken sein, vergebt mir, die nächsten Zeilen habe ich spontan und in sehr kurzer Zeit geschrieben. Ich bin mir sicher, dass sich die Struktur noch verändert. :-)

An dieser Stelle möchte ich auch einfach mal vielen, vielen Dank sagen. Vielen Dank an euch, die Community, die ihr mir so unglaublich viel Feedback gegeben- und garantiert auch in vieler Hinsicht belehrt habt.
Das betrifft jeden einzelnen Artikel, den ich in den letzten Monaten, fast schon Jahren, geschrieben habe.

Der Geschmack, der ersten von Spenden finanzierten Pizza. Daran erinnere ich mich besonders gerne zurück, glaube ich… :-)
Weiterlesen

Schriftbild in Tanglu/Debian verbessern (amd64)

Infinality

Changelog

  • 20. Juli 2014 – Upgrade der amd64-Pakete

Zugegeben, Tanglus Entwickler haben keine schlechte Arbeit geleistet, als es um die Feinabstimmung des Debian Schriftbildes ging.
Aber auch hier kann der verwöhnte Benutzer noch einiges rausholen, nämlich mit Infinality.
Spätestens seit Ubuntus belohnten Bemühungen in der Weiterentwicklung des Font-Renderings, setze ich unter Debian die gepatchten Pakete ein.

Die „Arbeit“ des Bauenes eigener Pakete erspare ich mir, da hadrons123 seine Mühe im Debian User Forum teilt. (Ergänzung vom 20. Juli 2014: Da keine neuen Versionen zu erwarten sind, habe ich den aktuellen Stand aus dem Git-Repository geklont und die Pakete nun doch selber gebaut. Das trifft jedoch nur auf die amd64-Variante zu.)

Ubuntu-Benutzer dürfen natürlich auch. Hierzu gibt es ein PPA. Ich bin schon fast der Meinung, dass Ubuntu sehr gute Arbeit geleistet hat und die Installation fast nicht notwendig ist. Daher beschränke ich mich auch auf Debian und sehr nahe Derivate.

Benutzer Tanglus 1.0 (amd64) sowie Debians Jessie/Testing (amd64), bedienen sich an folgenden drei Paketen:
https://www.dropbox.com/s/0mrei0n85t2zsga/fontconfig-infinality_1-2_all.deb
https://www.dropbox.com/s/zlwyh9gch9t63qg/freetype-infinality_2.4.9-3_all.deb
https://www.dropbox.com/s/m2lnhohvlzu1k50/libfreetype-infinality6_2.4.9-3_amd64.deb

Für Debian Wheezy/Stable (amd64) hier entlang:
http://dl.dropbox.com/u/106654446/infinality_public/fontconfig-infinality_1-1_all.deb
http://dl.dropbox.com/u/106654446/infinality_public/freetype-infinality_2.4.9-1_all.deb
http://dl.dropbox.com/u/106654446/infinality_public/libfreetype-infinality6_2.4.9-1_amd64.deb

Angenommener Speicherort sei „~/Downloads“, so erfolgt die Installation:

sudo dpkg -i Downloads/fontconfig* Downloads/freetype* Downloads/libfreetype*

Abschließend den Gnome Desktop neu aufbauen, indem „Alt+F2“ gedrückt- und „r“ eingegeben wird. Alternativ ab- und anmelden.

Optional: Style-Anpassung

Infinality bietet mehrere Voreinstellungen, derer ihr euch bedienen könnt. Unter anderem hierzu wird das mitinstallierte Script „/etc/fonts/infinality/infctl.sh“ als „root“ ausgeführt.

sudo /etc/fonts/infinality/infctl.sh setstyle

Zur Auswahl stehen zur Zeit:

Select a style:
1) debug 3) linux 5) osx2 7) win98
2) infinality 4) osx 6) win7 8) winxp

Änderungen werden sofort wirksam, bestenfalls aber den Desktop neuladen.

Optional: Debian Jessie -> Downgrade von „libfreetype6“

Danke an Martin für den Tipp des Downgrades der „libfreetype6“, um die von vielen als Verschlimmbesserung empfundene Änderung der Bibliothek in Debian Jessie rückgängig zu machen, indem diese durch die vorherige Version aus Wheezy ersetzt wird.
Das entprechende Paket findet ihr hier.

Dual WAN Load Balancing

Network

In diesem Artikel beschreibe ich Dual WAN Load Balancing im – aber nicht ausschließlich – Round Robin-/(Rundlauf-)Verfahren und optionalen Failover.
Getestet habe ich das Vorgehen unter Debian Wheezy und Ubuntu Server LTS, jedoch lässt es sich bis auf wenige Kleinigkeiten, zum Beispiel die Netzwerkkonfiguration, auf andere Linux-Derivate mit „iproute2“ sinngemäß übertragen.

Die fiktive Umgebung

Zur besseren Übersicht wähle ich folgende Konfiguration:

eth0, SDSL1, Netzwerk 65.10.10.0/24, Adresse 65.10.10.1, Gateway 65.10.10.254, Tabelle „uplink1
eth1, SDSL2, Netzwerk 65.20.20.0/24, Adresse 65.20.20.1, Gateway 65.20.20.254, Tabelle „uplink2
eth2, Internal Link, Netzwerk 192.168.100.0/24, Adresse 192.168.100.1

IPv4-Forwarding setze ich als konfiguriert voraus.

Konfiguration

Zu Beginn definiere ich alternative DNS-Server. Das kann notwendig sein, da ISP1 womöglich nicht auf den DNS-Server des ISP2 zugreifen darf.
Da ich mit der Leistung der Google DNS-Server sehr zufrieden bin, wähle ich diese:

sudo nano /etc/resolv.conf

Und der Inhalt:

nameserver 8.8.8.8
nameserver 8.8.4.4

Sollte ich auf die DNS-Server der ISP bestehen, würde eine Route für die jeweiligen IPs notwendig, damit der Zugriff stets via Gateway des jeweiligen ISP erfolgt.

Eine weitere Möglichkeit wäre ein DNS-Server im internen Netzwerk, etwa via Windows Domain Controller. Hierzu könnte die IP ohne zusätzliche Route als Nameserver definiert werden, da der Zugriff sowieso via eth2 erfolgen würde.
Aber Vorsicht, ist der hier besprochene Router auch für besagten Domain Controller zuständig, stöße dieser schlussendlich auf das selbe Problem, wenn er zum Forwarden die IPs des ISP eingetragen hätte.

Mit einem Editor erstelle ich zwei neue Tabellen für das Routing, die Beschreibung ist individuell wählbar, darf jedoch – selbstverständlich – noch nicht vorhanden sein:

sudo nano /etc/iproute2/rt_tables

Am Ende folgendes einfügen:

201 uplink1
202 uplink2

Die Netzwerkkonfiguration gewohnt via „/etc/network/interfaces“ vornehmen.

sudo nano /etc/network/interfaces

Hier die gesamte Konfiguration inklusive Loopback:

auto lo eth0 eth1 eth2

iface lo inet loopback

iface eth0 inet static
	address 65.10.10.1
	netmask 255.255.255.0
	post-up ip route add 65.10.10.0/24 dev eth0 src 65.10.10.1 table uplink1
	post-up ip rule add from 65.10.10.1 table uplink1
	post-down ip rule del from 65.10.10.1 table uplink1
	
iface eth1 inet static
	address 65.20.20.1
	netmask 255.255.255.0
	post-up ip route add 65.20.20.0/24 dev eth1 src 65.20.20.1 table uplink2
	post-up ip rule add from 65.20.20.1 table uplink2
	post-down ip rule del from 65.20.20.1 table uplink2
	
iface eth2 inet static
	address 192.168.100.1
	netmask 255.255.255.0
	broadcast 192.168.100.255
	network 192.168.100.0
	post-up ip route add default scope global nexthop via 65.10.10.254 dev eth0 weight 1 nexthop via 65.20.20.254 dev eth1 weight 1

Zu sehen ist, dass die Einrichtung von Adresse und Netzwerk gewöhnlich erfolgt. „Post-up“ führt Aktionen aus, nachdem das übergeordnete Interface gestartet wurde. Dies können beinahe beliebige Befehle sein.
Die Reihenfolge der Abarbeitung erfolgt gemäß „auto 1. 2. 3. 4.“ in erster Zeile.

In letzter Zeile des Beispiels, erfolgt das eigentliche Load-Balancing, indem ein Bereich für die Standardroute mit beiden Gateways definiert wird:

ip route add default scope global nexthop via 65.10.10.254 dev eth0 weight 1 nexthop via 65.20.20.254 dev eth1 weight 1

Der „nexthop“ für alle Pakete nach außen, kann nun entweder via SDSL1 oder SDSL2 erfolgen. Durch die Gewichtung „weight 1“ sind beide Wege von gleicher Priorität.
Hinweis: Dieser Befehl kann auch an anderer Stelle ausgeführt werden, die Wahl traf ich eher willkürlich. Natürlich müssen die Links eth0 und eth1 bereits verfügbar sein.

Optional: Gewichtung der Ports

Genauso einfach wie es mutmaßen lässt, ist die Konfiguration zur Bevorzugung eines Weges, einen Haken gibt es dennoch zu beachten.
Letzte Zeile des Beispiels aus „/etc/network/interfaces“, ersetze ich folgendermaßen:

[...]
	post-up ip route add default scope global nexthop via 65.10.10.254 dev eth0 weight 10 nexthop via 65.20.20.254 dev eth1 weight 90
[...]

Im Gegensatz zu simplen numerischen Prioritäten, setzt „weight“ ein Verhältnis. Obiges Beispiel ergäbe demnach 10:90, also 10 Anteile eth0, 90 Anteile eth1.
Eine Aufteilung der Last zu 20% auf eth0 und 80% auf eth1 wäre 20:80, also „weight 20“ für eth0 und „weight 80“ für eth1.

Optional: Testen

Um zuverlässig zu testen, ob das Routing auch die definierte Gewichtung beachtet, reicht eine einfache FOR-Schleife via Bash:

for x in $(seq 1 20)
do
ip r g 1.2.3.$x
done

Hierbei werden die Routen zur jeweiligen IP in der Abfolge 1.2.3.1 bis 1.2.3.20 untereinander angezeigt, für Round Robin etwa:

[...]
1.1.2.4 via 65.10.10.254 dev eth0 src 65.10.10.1
1.1.2.5 via 65.20.20.254 dev eth0 src 65.20.20.1
1.1.2.6 via 65.10.10.254 dev eth0 src 65.10.10.1
1.1.2.7 via 65.20.20.254 dev eth0 src 65.20.20.1
[...]

Optional: Failover

Auf dem Weg durchs Internet stieß ich auf ein nützliches Script (http://fatalsite.net/?p=90, edit: Leider nicht mehr erreichbar.), das ununterbrochen in definiertem Zeitabstand (Standard: 10s) einen Ping via „uplink1“ und „uplink2“ auf eine IP/einen Hostnamen ausführt, dabei eine Auswertung durchführt und je nach Konfiguration des Scripts eine „Route abschaltet“.
Das Script ist gut dokumentiert, daher belasse ich es bei dem Hinweis, helfe aber gerne bei der Einrichtung/Fragen.

Optional: Statische Routen

Eine sich dauernd ändernde IP, könnte diverse (Web-)Dienste irritieren. Abhilfe verschafft eine statische Route, die besagt für Dienst X immer über „uplink1“ (Beispiel) oder „uplink2“ zu gehen:

ip route add Web.Dienst.X.IP via 65.10.10.254

Achtung: Bitte beachten, dass falls Failover via obigem Script ausgeführt wird, dieses zu bearbeiten ist, damit die Routen im Zweifelsfall nicht über den toten Link ins Nirvana geschickt werden. :-)