Drei Jahre ist es her, seit ich PCLinuxOS das letzte mal getestet habe. Mittlerweile kenne ich auch die ihm zugrunde liegende Distribution Mandriva sehr gut. Ich war damals auf Anhieb begeistert, wie einfach eine gut durchdachte Desktop-Distribution sein kann, wenn die Macher sich wirklich auf das Wichtigste Konzentrieren: Die Zeit, die ein Benutzer für seine Tätigkeiten benötigt.
Wer wie ich das Vergnügen hat, für eine VPN-Verbindung in’s Büro auf ein proprietäres Werkzeug angewiesen zu sein, der muss sich zuweilen zu helfen wissen, um das entsprechende Programm auch unter modernen Linuxen betreiben zu können. So auch bei “SSL Network Extender” von Checkpoint, das nicht auf ein die Standards (Cisco VPN, OpenVPN) aufsetzt, sondern ein eigenes, nicht offenes VPN-Format verwendet, das unter der Haube machen kann, was es will, denn niemand sieht es. Abgesehen davon, dass es ziemlich schwierig ist, ohne Kundenlogin an das SSLExtender Binary für Linux ranzukommen, ist das Teil auch noch sauschlecht programmiert, aber dazu komme ich später.
Die Installation ist einfach, das selbstextrahierende Shellskript wird ausgeführt und 3 Sekunden später ist das Programm installiert und bereit:
./Check_Point_SNX_R66_HFA_01_For_Linux_800004013.sh
Beim ersten Ausführen allerdings wird einem schon der erste Stock zwischen die Beine geworfen:
snx
snx: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory
Die Software hat also tatsächlich eine Versionsabfrage für die Grundbibliothek libstc++ hart eincodiert! Uns fehlen die Worte und erste Zweifel an der Programmierqualität (oder fehlt einfach die Erfahrung mit Linux?) des Hauses Checkpoint kommen auf… Aber wir wären keine echten Geeks, wenn wir dafür keinen Workaround fänden:
Für Fedora u.ä. steht dazu meist eine compat-Version bereit, die für ebensolche Fälle gemacht ist:
yum install compat-libstdc++-33
Achtung! Auf 64bit-Versionen muss die 32bit-Version explizit angegeben werden (denn natürlich hat Checkpoint keine 64bit-Version auf Lager):
yum install compat-libstdc++-33.i686
Für Ubuntu’s neuere Versionen gibt es diese gar nicht mehr, aber man kann sie einfach aus einem älteren Repository ziehen: http://packages.ubuntu.com/jaunty/i386/libstdc++5/download
Also auf geht’s mit einem neuen Versuch:
snx -u BENUTZER -s SERVERNAME
FATAL: Could not open tun.ko. No such file or directory
SNX: Virtual Network Adapter initialization and configuration failed. Try to reconnect.
Oh je, warum zum Geier benötigt der SSL Network Extender das Tunnel-Kernelmodul? Eine kurze Suche im Internet bringt an’s Tageslicht, dass auch diese Abhängigkeit fest einprogrammiert ist, obwohl SSL Extender einen eigenen, proprietären VPN-Tunnel erstellt. Auf Fedora tritt dieser Fehler nicht auf, weil das Modul “tun” mit dem Standardkernel ausgeliefert wird. Unter Ubuntu jedoch ist dies Fehlanzeige, auch nachträglich lässt sich das Modul nicht installieren. Man müsste den Kernel neu übersetzen mit der entsprechenden Option. Aber wir sind doch nicht bescheuert und machen uns diese Mühe, bloss weil da ein paar Erstsemesterprogrammierer bei Checkpoint sizten! Das Modul muss einfach existieren, es muss überhaupt nix tun, also wird es einfach gefaked, siehe dazu auch: http://wiki.ubuntuusers.de/Check_Point_SSL_Network_Extender
mkdir faketun
cd faketun
echo -e "#include <linux/module.h>\nstatic int start__module(void) {return 0;}\nstatic void end__module(void){return;}\nmodule_init(start__module);\nmodule_exit(end__module);">tun.c
echo -e "obj-m += tun.o\nall:\n\tmake -C /lib/modules/\$(shell uname -r)/build/ M=\$(PWD) modules\nclean:\n\tmake -C /lib/modules/\$(shell uname -r)/build/ M=\$(PWD) clean\nclean-files := Module.symvers">Makefile
make
sudo install tun.ko /lib/modules/`uname -r`/kernel/net/tun.ko
sudo depmod -a
Ab jetzt funktioniert SSLExtender auch auf Ubuntu und man kann in Ruhe von zu Hause aus arbeiten, auch mit diesem proprietären VPN-Tunnel. Dem Arbeiten am Wochenende steht nun nichts mehr im Wege, ausser man hat nebenbei noch ein Privatleben 
Ich wünsche allen ein gutes neues Jahr, auf eine weitere Dekade! Pünktlich zum Jahresanfang stolperte ich auf die deutsche Übersetzung eines längeren Postings, das selber schon älteren Datums (aber immer noch absolut zutreffend) ist. Es beinhaltet eigentlich so ziemlich die beste Erklärung, warum Linux nie ein Windowsersatz ist und sein wird und warum viele verärgerte Windowsbenutzer erst eher bei sich selbst eine Veränderung machen müssen, als einfach mal schnell “auf Linux” (meist Ubuntu heutzutage) zu wechseln. Die Lektüre lohnt sich absolut:
http://www.felix-schwarz.name/files/opensource/articles/Linux_ist_nicht_Windows/
OK ausnahmsweise, weil Feiertage sind, auch mal eine Nicht-Linux-Distribution auf dem Prüfstand. Nämlich FreeNAS, eine hochspezialisierte BSD-Unix-Variante mit einem NAS-Server, wie der Name ja schon andeutet, der als Live-Image oder “installierbares Image” gebraucht werden kann.
Der Grund, weshalb ich auf FreeNAS kam, war, dass ich meine vielfältigen Heimnetz-Services, die sich über die Jahre in meinen virtuellen CentOS’s angesammelt haben, konsolidieren wollte. Mit einem NAS (Network Attached Storage, also Diskplatz, der über verschiedene Dienste im Netz auf vielfältige Weise nutzbar gemacht wird) und einer Weboberfläche ist dies einfach lösbar und macht mehr Spass als “nur” mit einer Hardware-Appliance, die teuer ist, keine offene Software hat und meist auch weniger Services anbietet.
FreeNAS ist ein kleines FreeBSD und wurde von Olivier Cochard und Volker Theile geschaffen. Heute besitzt iX-Systems FreeNAS, aber es wird natürlich als Opensource-Projekt weitergeführt.
Huge Pages [1] kennt jedes moderne Betriebssystem. Die Frage ist lediglich, ob Applikationen diese direkt nutzen können. Unter Linux müssen die Applikationen dies explizit anfordern. Es macht für grosse Serverapplikationen durchaus Sinn, Überlegungen anzustellen, ob man diese Möglichkeit nutzen soll. Oracle ist hierfür ein sehr gut geeignetes Beispiel. Schon ab 2GB Shared Memory (wenn man mehrere Instanzen hat und genügend Memory zur Verfügung stehen) lohnt sich die Konfiguration von dediziertem Speicherplatz bestehend aus Huge Pages. Da aber Oracle selber nicht automatisch Huge pages anfordert, reservieren wir einfach den voraussichtlichen Bereich im Shared Memory. Dies wird durch Kernelvariablen erledigt, entweder mit dem Kommando sysctl (für das laufende System) oder persistent in der Datei /etc/sysctl.conf. Im folgenden Beispiel habe ich einen Server mit 72GB RAM auf 48GB Shared Memory konfiguriert. Von einer huge page-Grösse von 2MB ausgehend reservieren wir die entsprechende Anzahl huge pages, um auf die 48GB zu kommen. Durch die Angabe einer Gruppe wird der Bereich exklusiv für die Gruppe “dba” reserviert.
Continue reading…
Boris on Was hat Microsoft an Opensource-Veranstaltungen zu suchen?
Chris on Distributions-Test Nr. 9: *** PCLinuxOS 2010 ***
Benji on Distributions-Test Nr. 9: *** PCLinuxOS 2010 ***
Mandriva Linux 2010.1 | Gustavo Pimentel's GNU/Linux Blog on Linux-Distributions Test Nr. 7: *** Mandriva 2009.1 ***Benji on Wie man Checkpoint’s SSL Network Extender auf Linux einsetzt