Archiv für den Monat: August 2014

Richtiges Update eines Cisco SG300-52 auf Firmware 1.4.0.88

Beim Update auf die neueste Firmware 1.4.0.88 gibt es beim Upload des Images eine Fehlermeldung. Man muss zuerst den Bootloader auf den neuesten Stand bringen, den Switch damit neu starten und dann erst das neue Image einspielen. Das Update des Bootloaders geht nur über die Console/CLI. Hier ein kurzes Howto wie man über die Console oder CLI mit SSH den Switch updaten kann. Zuerst müssen wir einen TFTP Server einrichten. Das geht sehr einfach mit dem portablen TFTPD32/64 von dieser Webseite. Den TFPD Server aus dem ZIP entpacken und starten. Als „Current Directory“ den Ordner auswählen der die beiden Files beinhaltet (RFB und ROS):
cisco-sg-300 update-tftpd

Nun verbinden wir uns mit SSH oder Consolenkabel auf den Switch:

cisco01#sh ver
SW version    1.3.7.18 ( date  12-Jan-2014 time  18:02:59 )
Boot version    1.0.0.4 ( date  08-Apr-2010 time  16:37:57 )

cisco01#sh bootv
Image  Filename   Version     Date                    Status
1      image-1    1.3.7.18    12-Jan-2014  18:02:59   Not active
2      image-2    1.3.7.18    12-Jan-2014  18:02:59   Active*

Wenn wir jetzt mit dem alten Bootloader die Firmware hochladen gibt es folgende Fehlermeldung:

cisco01#copy tftp://192.168.1.2/sx300_fw-14088.ros image
09-Apr-2014 08:06:49 %COPY-N-TRAP: The copy operation was completed successfully, aggregated (1)
09-Apr-2014 08:07:09 %COPY-I-FILECPY: Files Copy – source URL tftp://192.168.1.2/sx300_fw-14088.ros destination URL flash://image
!!!!!!!!
Copy: SW code file is over sized

Man muss erst den Boot-Loader auf den Switch übertragen:

cisco01#copy tftp://192.168.1.2/sx300_boot-13506.rfb boot
09-Apr-2014 08:06:42 %COPY-I-FILECPY: Files Copy – source URL tftp://192.168.1.2/sx300_boot-13506.rfb destination URL flash://BOOT
!!!!!!!!
Copy: 393232 bytes copied in 00:00:07 [hh:mm:ss]

Jetzt den Switch neu starten und wieder über SSH verbinden:

cisco01#reload

cisco01#sh ver
SW version    1.3.7.18 ( date  12-Jan-2014 time  18:02:59 )
Boot version    1.3.5.06 ( date  21-Jul-2013 time  15:12:10 )

Second Try für die Übertragung vom Image:

cisco01#copy tftp://192.168.1.2/sx300_fw-14088.ros image
12-Jan-2014 18:07:49 %COPY-I-FILECPY: Files Copy – source URL tftp://192.168.1.2/sx300_fw-14088.ros destination URL flash://image
!!!!!!!!
Copy: 7364601 bytes copied in 00:01:59 [hh:mm:ss]

cisco01#sh bootv
Image  Filename   Version     Date                    Status
1      image-1    1.4.0.88    06-Aug-2014  16:55:55   Not active
2      image-2    1.3.7.18    12-Jan-2014  18:02:59   Active*

Boot Image auswählen:
cisco01#boot system image-1

Switch neu starten:
cisco01#reload

Mixed Linux Loadbalancer für VMware Horizon (View) und Alcatel OmniPCX

Erstes Einsatzszenario: Um die Redundanz unserer VMware Horizon (View) Umgebung zu gewährleisten, wurde ein Setup mit zwei View Connection Servern gewählt. Diese werden auf den VSphere Servern mit einer „Anti Affinity Rule“ betrieben. Somit ist sichergestellt, daß die beiden Connection Server nie auf dem gleichen ESX Host laufen.
Linux-Loadbalancer-01
Selbst erlebt: Viele Systemhäuser und Adminstratoren verwenden bei mehreren Connection Servern DNS Round Robin. Zum Beispiel: view.domaine.local wird auf die beiden A-Records view1.domaine.local und view2.domaine.local aufgelöst. Somit bekommen die Clients bei jeder DNS Anfrage den nächsten DNS Eintrag zu view.domaine.local. Zur Lasterverteilung kann man das gelten lassen, aber ansonsten: Geht gar nicht! Wenn ein Server ausfällt sind 50% der Clients nicht mehr erreichbar. Man stelle sich das bei über 300 virtuellen PCs vor. Das sind 150 Anrufe bei der EDV Abteilung 🙂 Also: Ein Loadbalancer muss her. Da hat man zwei Dinge auf einmal: Lastverteilung und Redundanz, denn wenn ein „Realserver“ ausfällt, wird dieser sofort von der Lastverteilung ausgeschlossen. Ich habe mich für den Keepalived entschieden, denn dieser arbeitet perfekt mit IPVSadm zusammen. Hier die Config für die VMware View Server als Realserver:

Die Anfragen werden mittels Direkt Routing weitergeleitet. Kein NAT! Hierzu muß auf dem Windows Realserver ein Loopbackdevice mit der Shared IP installiert werden. Im Loadbalancer Blog wird ganz gut erklärt wie das bei Server 2008 gemacht wird.
Linux-Loadbalancer-02
Der Client wird über den Loadbalancer zum Realserver weitergeleitet, arbeitet aber nach dem Verbindungsaufbau direkt mit dem Realserver weiter. Genau das wollen wir.
Linux-Loadbalancer-03
Nun zum zweiten Einsatzszenario: Unsere Telefonanlage besteht aus zwei Knoten an zwei Standorten mit zwei unterschiedlichen IP Subnetzen. Nur die aktive Knoten stellt den TCP/IP Connector auf Port 2555 für Estos bereit. Schwenkt bei einem Netzwerkausfall die Anlage den aktiven Knoten, ist Estos bis zur manuellen Anpassung der Konfiguration offline. In diesem Anwendungsfall kann man den Loadbalancer super zur Redundanz „missbrauchen“, denn er erkannt ja wenn ein Realserver ausgefallen ist und benutzt diese Verbindung nicht mehr. In unserem Fall wird somit immer der aktive Knoten angesprochen. Wegen den beiden unterschiedlichen Subnetzen und weil ich ungerne ein Loopback im Linux von Alcatel einrichten will (Supportverlust) kommt nur NAT in Frage. Hier muß man einige Dinge unter Linux beachten. Im Linuxkernel (Sysctl) müssen folgende Einträge aktiviert werden:
net.ipv4.ip_forward=1
net.ipv4.vs.conntrack=1

In den meisten Dokus wird das MASQUERADING global auf dem Interface aktiviert:
iptables -t nat -A POSTROUTING -o eth0

Diese Einstellung würde aber das Direct Routing sofort unbrauchbar machen. Es dürfen lediglich die Pakete zu den Realservern mit NAT maskiert werden:
iptables -t nat -A POSTROUTING -o eth0 -d <realserver1-ip> -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth0 -d <realserver2-ip> -j MASQUERADE

Diesen folgenden Abschnitt einfach unter die Einträge vom Direkt Routing in der bestehenden Konfigurationsdatei kopieren und anpassen:

Sieht leicht aus, aber ich musste einige Zeit in die Recherche und Tests inverstieren. Aber hat man dieses Setup einmal eingerichtet und verstanden, kann man es immer wieder für sicherlich viele weitere Anwendungsfälle implementieren. Bei uns wird durch den Loadbalancer die Round Robin Verteilung der Anfragen auf die Realserver und Redundanz gewährleistet. Redundanz – gutes Stichwort: Die so konfigurierte Master Linux-VM muss man einfach clonen und mit der gleichen Konfiguration als Backup laufen lassen. Dafür einfach den Hostnamen und die IP-Adresse von Loadbalancer-1 inkrementieren und den Eintrag „Master“ durch „Backup“ in der Konfigurationsdatei ersetzen. Die beiden Loadbalancer sollten ebenfalls mit einer „Anti Affinity Rule“ betrieben werden. Damit ist der Loadbalancer mittels VRRP ebenfalls hochverfügbar. Linux. Einfach. Kostet nix. Geht. Sie können ja mal Preise für einen redundanten Hardware-Loadbalancer anfragen 😉

pfSense mit OpenVPN und Active Directory AUTH

Dies ist eine kurze Doku wie man unter pfSense ein SSL VPN mit OpenVPN und Authentifizierung gegen Active DIrectory einrichtet. Die Clientsoftware kann man direkt von der Firewall exportieren und auf dem Client (z.B. Win7 oder MAC) installieren. Das Tutorial richtet sich eher an erfahrene Admins die OpenVPN schon einmal eingerichtet haben und die Software sowie die Prozedur der Zertifikatserstellung kennen. Es geht lediglich darum wie man unter pfSense den OpenVPN Server mit LDAP Auth konfiguriert und wie man die User-Zertifikate erzeugt und auf dem Client einrichtet.
Als erstes bindet man Active Directory ein. SSL verschlüsselte Abfragen funktionieren zwar im Test der LDAP Verbindung wunderbar, aber im Einsatz mit OpenVPN schlägt die Abfrage fehl. Hoffentlich wird dieser Bug bald behoben. System -> User Manager -> Servers
pfsense-openvpn-authserver
Nun muß man im System -> Cert Manager für den entsprechenden User ein Zertifikat erzeugen  welches den Windows Benutzernamen als CName enthält:
pfsense-openvpn-certcreate
Danach muß man den OpenVPN-Server konfigurieren VPN -> OpenVPN:
pfsense-openvpn-openvpnserver
Die Settings und Zertifikate für den Client lassen sich mit dem Package „OpenVPN Client Export Utility“ bequem exportieren System -> Packages:
pfsense-openvpn-openvpnexport1
VPN -> OpenVPN -> Client Export:

pfsense-openvpn-openvpnexport
Der erzeugte Installer mit Config und Certs enthält sogar die aktuelle Version des OpenVPN Clients:
pfsense-openvpn-client-dialin

Ubuntu: fehlerhafter Cronjob für Amavis/Razor2 sa-sync

Ubuntu/Debian führt folgenden Cronjob aus:
Cron <amavis@mail> test -e /usr/sbin/amavisd-new-cronjob && /usr/sbin/amavisd-new-cronjob sa-sync

Sie erhalten folgende Fehlermeldung:
Use of uninitialized value $type in concatenation (.) or string at /usr/lib/perl5/Mail/SpamAssassin/Conf/Parser.pm line 699.
config: unknown conf type ! at /usr/lib/perl5/Mail/SpamAssassin/Conf/Parser.pm line 699.

Es handelt sich um einen Schreibfehler in der Datei „Razor2.pm“. Einfach mit einem Editor den Fehler in Zeile 118 korrigieren „DURATION“:
vi /usr/lib/perl5/Mail/SpamAssassin/Plugin/Razor2.pm

razor2_typo

Amavisd-new nach SpamAssassin Update neu starten

Nach einem erfolgreichen Update mit „sa-update“ muß man Amavisd neu starten damit das Update auch angewendet werden kann. Amavis läd aus Performancegründen den Spamassassin komplett in den Speicher. Ich habe ein kleines Script geschrieben das den Dienst Amavis neu startet wenn es ein erfolgreich durchgeführtes Update gegeben hat. Die Updates werden von Apache.org und Heinlein Support gezogen. Wenn einer dieser Channels ein Update angeboten hat greift der Neustart.

Einfach in „/opt/sa-update.sh“ speichern und über einen Cronjob aufrufen.