Captain's blog

Zur Abwechslung (und um wenigstens mal irgendwas hier zu posten) wieder mal ein wenig komplett ungeordnete Laberei aus dem "Privatleben":

Ich kann mich leider nicht mehr daran erinnern, wann Zeit zu einem meiner wertvollsten Güter geworden ist. Der Beginn des "nebenher laufenden" Studiums war sicherlich das erste Eriegnis, das dazu beitrug; die Selbständigkeit im Nebenberuf hat's auch nicht besser gemacht. Komischerweise stelle ich fest, dass es einigen meiner Freunden und Bekannten spätestens seit Mitte dieses Jahres genau so ergeht, wobei ich mich nach Gründen oder kausalen Zusammenhängen frage. Sollte hier eine groß angelegte Verschwörung am Werk sein?

Anbei ein paar Dinge, die mich ganz aktuell (neben Arbeit und Studium) auf Trab halten:
- Einiges an neuem Lesestoff (Einsteigerseminar Latex / C und Linux / BSD-Hacks / Unix-/Linux-Hochverfügbarkeit / Existenzgründung IT)
- Weiterführende Beschäftigung mit OpenBSD
- Schreiben eines Artikels über das Gibraltar Security Gateway 2800
- Umzug des alten Strato-Servers, der nur noch als Spielwiese diente auf eine dickere Kiste bei Hetzner (DS5000), der direkt auf mehrere virtuelle Server aufgeteilt wird. An dieser Stelle werde ich mir dann auch direkt den Traum eines kleinen, öffentlichen Honeypots wahr machen.
- Sonstiger Kleinscheiß, der an dieser Stelle zu weit führen würde...

Darüber hinaus habe ich eben erfahren, dass ich (nun zum dritten Mal in Folge) in der Jury der diesjährigen LinuxNew Media-Awards sitzen werde, deren Ergebnisse am 15. November auf der LinuxWorld Expo in Köln vorgestellt werden.

Nachdem ich heute wieder Gelegenheit hatte, mich mit weiteren Maßnahmen zur Hochverfügbarkeit von Linux-Servern zu befassen, kam ich endlich mal wieder in Kontakt mit Bonding. Manch einer mag dabei an Seile und andere Nettigkeiten denken, dabei handelt es sich schlicht und ergreifend um die Bündelung verschiedener Netzwerkkarten mit dem Ziel, die Geschwindigkeit und / oder die Verfügbarkeit zu erhöhen. Jeder, der sich mal näher mit Cisco-Switchen auseinandergesetzt hat, wird der Begriff Etherchannel hier direkt in den Sinn kommen, schlussendlich laufen beide Dinge aber auf's Gleiche hinaus.

Obwohl es von großem Nutzen sein kann, haben nur vergleichweise wenige Linux-Admins (die ich kenne) auch schon damit gearbeitet. Alleine aus diesem Grund möchte ich das Thema hier einmal in aller Kürze vorstellen:

Sollte sich jemand wundern, warum es hier in letzter Zeit so OpenBSD-lastig geworden ist, liegt das schlicht und ergreifend daran, dass ich von dessen Möglichkeiten immer begeisterter bin.

Besonders netzwerkseitig haben die Entwickler des Systems in manchen Punkten endlich zu Linux aufgeschlossen, wohingegen sich Linus und Co. in anderen Belangen ein dickes Stück dort abschneiden könnten. Ein sehr guter Artikel zu OpenBSD 3.8 auf Onlamp stellt einige Dinge heraus, die vielen so gar nicht bewusst waren:

Auch wenn ich seit mittlerweile über einem Jahr (natürlich immer nur schubweise ) an meinem Artikel über nmap für's Linux-Magazin saß, hielt ich ihn gestern zum ersten Mal in gedruckter Form in den Händen.

Ab Seite 46 geht's los, und ich bin echt froh, diesmal nicht doch wieder diverse Tippfehler entdeckt zu haben. Einen besonders blöden habe ich dann aber doch noch gefunden...und das noch auf der letzten Seite (52): natürlich muss es "IDS für Arme" heißen, und eben nicht IPS.
Na ja, ich werd's überleben.

Der Artikel passt jedenfalls meiner Meinung nach sehr gut zum restlichen Themenschwerpunkt "Security", und es ist ein gutes Gefühl, seinen Namen in einer solch illustren Runde zu lesen. Besonders gut gefällt mir übrigens der Artikel über HA-Firewalls mit OpenBSD, der mir nicht zuletzt aufgrund meiner aktuellen OpenBSD-Spielereien extrem entgegen kommt.
Im Gegensatz zu hochverfügbaren Linux-Firewalls ist diese Technik nämlich durch den Einsatz von CARP (Common Address Redundancy Protocol) spätestens im Fehlerfall überlegen, ganz abgesehen davon, dass ich PF erheblich einfacher (und konsistenter) finde als IPTables.

Vielleicht liest ja der eine oder andere hier meinen geistigen Erguss, und traut sich sogar, das durch konstruktuves Feedback hier zuzugeben?

Mein Plan, hier regelmäßig (am besten täglich) zu posten wurde Montag leider temporär durch meinen Boss zunichte gemacht.
Zur Zeit komme ich zu fast nichts anderem, als die "grandiose" Idee, für eine besondere Aktion temporär (!) und innerhalb von nicht einmal fünf Tagen (!!) eine stabil laufende, und eigentlich gut performende Internetanbindung mit 2x100 MBit durch eine Gigabit-Anbindung zu ersetzen. Zu Ausfällen darf es dabei natürlich nicht, bzw. nur für ein paar Minuten kommen...

Ich hoffe daher, mich spätestens Sonntag wieder mit einem Posting hier zurückmelden zu können...

Für ein bestimmtes Projekt evaluiere ich zur Zeit die Möglichkeit, einzelne Server zu konsolidieren. Für unsere Zwecke würden sich hier zwei Möglichkeiten bieten:

- VMWare ESX Server sowie
- Xen

Beide bieten grundsätzlich die gleichen Möglichkeiten, in HA-Umgebungen wird selbst Xens sogenannte "Live-Migration" wird seitens VMWare mit Hilfe des (zusätzlich zu erwerbenden) VMotion gelöst.
Sofern es also um "externen" Support und Unterstützung geht (wichtiges Managementkriterium) hat VMWare also zunächst die Nase vorn. Wenn ich mir allerdings im Gegenzug einmal XenSource anschaue, muss ich mich fragen, ob dieses Argument auch weiterhin Gültigkeit besitzt.

Ich persönlich würde Xen bisher klar den Vorzug geben, da ich hier (im Gegensatz zu VMWare) auch weiterhin einen freien (und sehr ausgerefiten) Ansatz zur Serverkonsolidierung sehe. Allein, wenn ich mir einmal die Kosten der ESX-Variante anschaue, läuft's mir gleich kalt den Rücken runter.
Vielleicht stand ja bereits einmal jemand vor der gleichen Frage, und kann mir schon mal ein bis zwei weitere Argumente pro oder contra liefern.

Mein Vorhaben, mein bereits am Montag angekündigtes Posting zum Thema "Privatsphäre im Internet" gestern zu verfassen wurde relativ kurzfristig durchkreuzt. Aufgeschoben bedeutet aber nicht aufgehoben.
Den gestrigen Tag habe ich komplett ohne Internetverbindung (ja, mittlerweile geht's mir wieder gut ) größtenteils in einer kleinen Schulung verbracht. Dort habe ich einiges darüber erfahren, wie man Nokias IP-Plattform im Zusammenhang mit CheckPoints Firewall-1 hochverfügbar machen kann.

Heute konnte ich endlich ein Projekt umsetzen, das ich schon einmal vor ca. drei Jahren angegangen war, damals aber aufgrund fehlender Informationen aber einstellen musste: eine hochverfügbare Proxy-Lösung.

Die HA wird dabei von zwei redundanten Loadbalancern sichergestellt, die (wie der Name schon andeutet) zudem noch die Last auf zwei "hinter" ihnen stehenden Server verteilen. Wer bei Loadbalancern nun an sündhaft teure, eigens dafür konzipierte Stücke Hardware denkt, die nur von hochbezahlten Spezialisten bedient werden können, liegt dabei gänzlich falsch: es handelt sich schlicht und ergreifend um zwei Linux-Server, die mit einem etwas aufgebohrten LVS (Linux Virtual Server) bestückt sind.
Das System ist so aufgebaut, dass der Dienst im Hintergrund (Squid) in regelmäßigen Abständen vom gerade aktiven Loadbalancer überprüft, und im Fehlerfall der Server automatisiert aus dem "Cluster" herausgenommen wird. Auch die Loadbalancer überprüfen sich gegenseitig auf Funktionsfähigkeit, und übernehmen im Fehlerfall die Dienste des ausgefallenen.

Bisher haben wir diese Lösung nur für zwei getrennt voneinander laufende Emailsysteme (mit jeweils zwei Backend-Servern) genutzt, und ich bin schon sehr gespannt, wie sich die Proxies im Hintergrund verhalten. Noch gespannter bin ich darauf, wie viel mehr Last der Loadbalancer durch diese Maßnahme abbekommt. Bisher langweilt der sich nämlich eher zu Tode.