Sophos UTM 220 A/S HA – Up2date failed on slave

Gestern 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! 😉

Samuel Heinrich
Senior Network Engineer at Selution AG (Switzerland)
Arbeitet in Raum Basel (Switzerland) als Senior Network Engineer mit über 15 Jahren Erfahrung im Bereich Netzwerk

1 thought on “Sophos UTM 220 A/S HA – Up2date failed on slave

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.