Download als PDF FileGestern bei einem Kunden ein Update von zwei Sophos UTM 220 gemacht, welche im A/S HA Betrieb laufen. Normalerweise funktioniert so ein Update im HA problemlos, zuerst wird der slave hochgepatched, reloaded und sobald dieser wieder „active“ ist, macht das System einen Failover und upgraded den Master.
Nun, nachdem ich den Up2Date Prozess über den Webadmin angestossen habe, fand ich folgendes Szenario vor:
Jegliche Versuche den Prozess nochmals über den Webadmin anzustossen schlugen fehl. Über das GUI konnte man das Problem nicht mehr lösen.
Let’s troubleshoot
-> SSH aktiviert
-> mit loginuser eingelogged
-> sudo su
loginuser@ssl:/home/login > sudo su root's password: Sorry, try again. root's password: ssl:/home/login #
Nun wie weiter? Ein hilfreicher KB Artikel aus der Sophos KB hierzu:
„Performing a Sophos UTM Up2Date from the command line“
http://www.sophos.com/de-de/support/knowledgebase/115382.aspx
Es scheint so als müsse man zuerst da Patch File downloaden. Dazu drei Varianten:
Simple way:
Via Webadmin hochladen, das File sollte sich danach im Verzeichnis /var/up2date/sys befinden
The Linux way:
Man läd das file mit „wget“ vom astaro FTP Server
ssl:/etc/up2date # wget ftp://ftp.astaro.com/UTM/v9/up2date/u2d-sys-9.107027-107033.tgz.gpg
--2014-01-24 02:54:32-- ftp://ftp.astaro.com/UTM/v9/up2date/u2d-sys-9.107027-107033.tgz.gpg
=> `u2d-sys-9.107027-107033.tgz.gpg'
Resolving ftp.astaro.com... 79.125.108.166
Connecting to ftp.astaro.com|79.125.108.166|:21...
The Sophos Way:
Man benutzt das Builtin Up2date Script „audld.plx“
ssl:/home/login # audld.plx -level d Starting Up2Date Package Downloader -output gekürzt-
Sobald man im Besitz des Upgrade Files ist, kann man den Prozess mit „auisys.plx“ anstossen. Es empfiehlt sich das Script vorher mit dem Parameter „auisys.plx -simulation“ auszufüheren, dabei wird das Update simuliert und auf allfällige Probleme hingewiesen.
ssl:/var/up2date/sys # auisys.plx -simulation Starting Up2Date Package Installer Simulation mode enabled! ssl:/var/up2date/sys # Searching for available up2date packages for type 'man9' There are no 'man9' packages available for installation Searching for available up2date packages for type 'ohelp9' There are no 'ohelp9' packages available for installation Searching for available up2date packages for type 'cadata' There are no 'cadata' packages available for installation Searching for available up2date packages for type 'sys' Installing up2date package version 9.107033 Verifying up2date package signature Unpacking installation instructions ---output gekürzt--- Searching for available up2date packages for type 'geoip' There are no 'geoip' packages available for installation Searching for available up2date packages for type 'ipsbundle' There are no 'ipsbundle' packages available for installation Would do a reboot now Up2Date Package Installer finished, exiting
Sounds good, let’s go
ssl:/var/up2date/sys # auisys.plx
Update der Master Node lief sauber durch, reboot erfolgte am Ende:
Achtung: Beim Reboot erfolgte ein Failover auf die Slave Appliance, diese war in einem nicht betriebsfähigem Zustand, die Konsequenz daraus was eine 5 Min Downtime, solange bis die Master Node wieder hoch kam und wieder aktiv wurde!
Zwischen Etappe erreicht. Nur wie löst man jetzt das Problem mit der slave node, dafür sollte man Zugriff auf diese haben! Leider hat die Slave Appliance keine aktiven IP Interfaces, auf welche man direkt ssh einloggen könne, es gibt allerdings einen Umweg über den HA Link über welchen der Master mit dem Slave synchoniesiert (in der Regel ETH3).
let’s investigate
Die IP war schnell rausgefunden:
ssl:/home/login # netstat Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State ---output gekürzt--- udp 0 0 node2:60660 node1:syslog ESTABLISHED ssl:/var/up2date/sys # ping node1 PING node1 (198.19.250.1) 56(84) bytes of data. ssl:/var/up2date/sys # ssh loginuser@node1 loginuser@node1's password:
Unglücklicherweise wurde das heruntergeladene Up2Date File nicht auf den slave (node1) repliziert:
node2:/var/up2date/sys # ls -lha -rwxrwxrwx 1 loginuser root 128M Dec 18 14:44 u2d-sys-9.106017-107033.tgz.gpg node1:/var/up2date/sys # ls node1:/var/up2date/sys #
Hier wird es etwas tricky, da die slave node keine aktiven IP Interfaces hat und keine default Route über den HA Link besitzt, fallen die erwähnten Wege aus, das File auf die node zu transferieren.
Möglicherweise könnte man eine 0.0.0.0/0 route auf den HA Peer Link zur aktiven Node konfigurieren, damit diese Internet Zugriff erlangt… Aber da ich remote auf der Box drauf war und diese sich 40km in einem produktiven Umfeld befindet, hab ich mich für einen sicheren Weg entschieden.
Node2 (Master) ist im Besitz des Files, dieses liegt dort im /var/up2date/, via SSH ist es möglich über „scp“ Files zu transferieren. Es gilt folgende Dinge zu beachten:
– Lese Rechte des Loginusers im auf die Datei von node2 (master) im Dir /var/up2date
– Schreibrechte des Users auf node1 (slave)
Da ich kein Linuxguru bin, sondern Netzwerkler hab ich mich für den Dirty way entschieden
The Dirty way:
node2:/var/up2date/sys # chmod 777 u2d-sys-9.106017-107033.tgz.gpg node2:/var/up2date/sys # chown loginuser u2d-sys-9.106017-107033.tgz.gpg node2:/var/up2date/sys # ls -lha -rwxrwxrwx 1 loginuser root 128M Dec 18 14:44 u2d-sys-9.106017-107033.tgz.gpg
Somit sollten jegliche Permission gesetzt sein und man kann das File via scp kopieren. Beispiele zum Kopieren mit scp gibt es hier:
http://www.hypexr.org/linux_scp_help.php
Examples
Copy the file „foobar.txt“ from a remote host to the local host
| $ scp your_username@remotehost.edu:foobar.txt /some/local/directory |
Adaptiert bedeutet dies:
node1:/var/up2date/sys # scp loginuser@node2:/var/up2date/sys/u2d-sys-9.106017-107033.tgz.gpg u2d-sys-9.106017-107033.tgz.gpg
Anmerkung: Man kann sich den „dirty way“ ersparen, wenn man das File mit dem root User kopiert, allerdings erfordert das die Einrichtung des SSH Root Logins, dh. das Importieren des SSH Fingerprints der Node1 (slave)… good luck! 😉
Nachdem nun Node1 (slave) endlich im Besitz des Up2Date Files war, konnte ich den Prozess auch dort anstossen:
ssl:/var/up2date/sys # auisys.plx
Starting Up2Date Package Installer
Searching for available up2date packages for type 'man9'
There are no 'man9' packages available for installation
ssl:/var/up2date/sys # ls
u2d-sys-9.106017-107033.tgz.gpg
ssl:/var/up2date/sys # Searching for available up2date packages for type 'ohelp9'
There are no 'ohelp9' packages available for installation
Searching for available up2date packages for type 'cadata'
There are no 'cadata' packages available for installation
Searching for available up2date packages for type 'sys'
Installing up2date package version 9.107033
.....
9.107033/./update9.107033post_start OK
Running syncing step 0 OK
Running syncing step 1 OK
Successfully installed Up2Date package
Searching for available up2date packages for type 'geoip'
There are no 'geoip' packages available for installation
Searching for available up2date packages for type 'ipsbundle'
There are no 'ipsbundle' packages available for installation
Initiating reboot
Up2Date Package Installer finished, exiting
Broadcast message from root (Wed Jan 22 23:30:00 2014):
Kurz darauf im Webadmin:
Sieht schon Mal viel versprechen aus!
E Voila!
Fazit: Die Alternative wäre gewesen vor Ort zu fahren, HA auszulösen, USB CDRom an node1 (slave) anzuschliessen und mit dem ISO die Firmware neu zu installieren, um danach HA wiederherzustellen.
PS:
/thx to fel1x für die Nachhilfe in Sachen Linux Syntax! 😉
Gratulation zu dem Beitrag!! Hat mir sehr geholfen, Danke!!