Hope This Helps

Problem:
Ich hatte das Problem, dass bei einem Sophos-Cluster des Upgrade des Slave-Nodes nicht durchlief. Der Node bliebt immer im Status "Up2Date" hängen und erst ein Neustart brachte ihn wieder in den normalen aber unaktuellen Zustand.
Nachdem ich eine Log-Files überprüft hatte, war klar, dass entweder das Update-File defekt oder nicht vollständig auf den Slave-Node übertragen wurde, aber das System der Meinung war, dass das alles in Ordnung ist.

Lösung:
Man muss nun das Update-File manuell auf den Slave-Node übertragen und das Upgrade dann manuell starten.
Hier die nötigen Schritte dafür:

Nötige Vorbereitungen:
- Update-Dateien bei Sophos ermitteln für späteren Download: Sophos UTM v9 Up2Date
- SSH- und ROOT-Zugang über die Webshell aktivieren und eventuell Kennwort neu setzen (loginuser/root)

Upgrade manuell durchführen:
1.) SSH-Verbindung zum aktuellen Master-Node herstellen und mittels loginuser anmelden
2.) ROOT-Rechte anfordern mittels:

su

3.) Ins Verzeichnis tmp wechseln:

cd /tmp

4.) Die zuvor ermittelte Update-Datei mittels wget herunterladen:

wget ftp://ftp.astaro.com/UTM/v9/up2date/u2d-sys-9.705007-706009.tgz.gpg

5.) Die heruntergeladene Update-Datei auf den Slave-Node übertragen (kann auch mit mehreren Updates durchgeführt werden):

scp u2d-sys-9.705007-706009.tgz.gpg loginuser@198.19.250.1:/tmp

6.) Nach erfolgreichem Kopiervorgang auf den Slave-Node wechseln:

 ha_utils ssh

7.) Hier ebenfalls Root-Rechte anfordern:

su -

8.) Ins Verzeichnis tmp wechseln:

cd /tmp

9.) _Die Update-Datei jetzt in den Update-Folder des Nodes verschieben und eventuell defekte Dateien vorher darin löschen:

mv u2d-sys-9.705007-706009.tgz.gpg /var/up2date/sys/u2d-sys-9.705007-706009.tgz.gpg

10.) Überprüfen, ob das Update in den Ordner sys kopiert wurde:

cd /var/up2date/sys

11.) Jetzt den Update-Vorgang auf dem Slave-Node manuell starten:

/sbin/auisys.plx --rpmargs --force

12.) WICHTIG: Nach erfolgreichem Update muss die Update-Datei auf Master und Slave gelöscht werden, sonst erfolgt eine Meldung eines angeblich neuen Updates.

Problem:
Bei neuen HP Switchen ist standardmäßig die neue WebGUI aktiv. Diese ist mir persönlich zu bunt und unübersichtlich. Ich bevorzuge die traditionelle Ansicht. Leider muss ich das immer umständlich bei jedem Login über "Launch Traditional GUI" umstellen.

Lösung:
Man kann die "traditional WebGUI" dauerhaft aktivieren. Dazu muss man nur die CLI verwenden:

1.) An CLI als Admin anmelden (per Telnet/SSH)
2.) Befehl "config" eingeben (enter config mode (config)# )
3.) Befehl "web-management interface traditional" eingeben (enable traditional interface)
4.) Befehl "write memory" eingeben (save config to memory)

FERTIG!

Problem:
Der Switch HP OfficeConnect 1920S ist ein sehr günstiger Full-Gigabit PoE Switch. Man muss ein paar Abstriche am Gerät machen, aber an sich ein sehr guter Switch. Für mich sind folgende Punkt etwas störend, aber für den Zweck der Switche akzeptabel:

- kein Consolen-Port (serieller Anschluss)
- Stromkabel kein Kaltgerätestecker - ist nur für den direkten Anschluss an der USV geeignet.
- Only Web-Managed

Mein Problem war, dass der Switch nur Web-Managed ist und keinen Zugriff per Telnet oder SSH bietet. Da ich kein Freund von GUIs bei Switchen bin wollte ich Telnet und/oder SSH-Zugriff haben um auf die CLI zugreifen zu können.
Per Default leider nicht möglich, aber man kann es über einen kleinen Umweg aktivieren!

Lösung:
ACHTUNG: Diese Lösung funktioniert nur bis Firmeware PD.02.08 - mit der Version PD.02.09 hat HP diese Möglichkeit unterbunden (Danke Benjamin für den Hinweis!)
1.) Firmware-Update auf die aktuelle Version über die GUI (bei mir PD.02.06)
2.) Eine aktuelle Start-Config exportieren über Maintenance -> Backup and Update Manage
3.) Die exportierte Config editieren und folgende Zeile VOR der Zeile "configure" setzen

ip telnet server enable

Beispiel Startup-Config von mir:

!Current Configuration:
!
!System Description "HPE OfficeConnect Switch 1920S 48G 4SFP PPoE+ (370W) JL386A, PD.02.06, Linux 3.6.5-a07f8920, U-Boot 2012.10-00118-g3773021 (Oct 11 2016 - 15:39:54)"
!System Software Version "PD.02.06"
!System Up Time "0 days 0 hrs 6 mins 39 secs"
!Additional Packages HPE QOS,HPE IPv6 Management,HPE Routing
!Current SNTP Synchronized Time: SNTP Client Mode Is Disabled
!
vlan database
exit
ip telnet server enable
configure
time-range Schedule-1
exit
time-range Schedule-2
exit
no username guest
line console
exit
line telnet
exit
line ssh
exit
!
exit

4.) Neue Startup-Config speichern und über die GUI als Startup-Config importieren (Maintenance -> Backup and Update Manage)
5.) Switch rebooten
6.) Telnet auf die Switch-IP ausführen (Default: Telnet 192.168.1.1)
7.) Mit folgenden Zeilen SSH aktivieren:

enable
configure
crypto key generate rsa
crypto key generate dsa
exit
ip ssh server enable
ip ssh protocol 2
write memory confirm
quit

8.) Wer möchte kann Telnet auch wieder deaktivieren mit dem Befehl:

ip telnet server disable

Kleiner Tipp am Rande: Wenn man die Startup-Config hochlädt, dann werden Kennwörter und sonstige Konfigurationen wieder verworfen! Also bitte erste Telnet/SSH aktivieren und dann Switch konfigurieren!

Quelle für die Hilfe:
Switches 'HPE OfficeConnect 1920S' - Enable SSH / TFTP Services

Obwohl ich die Proxy-Funktion der SOPHOS SG135 nicht verwende oder lizensiert habe, meldet sich plötzlich das System und ist der Meinung, das ein Zertifikat ablaufen würde. Folgende Mail habe ich hier erhalten:

1 certificate(s) will expire within the next 30 days:
Proxy CA

--
System Uptime : 0 days 12 hours 12 minutes
System Load : 0.35
System Version : Sophos UTM 9.500-9

Please refer to the manual for detailed instructions.

Wie kann das sein? Welches Zertifgikat ist das hier genau? Ist es doch das SSL-VPN-Zertifikat?
Man kann das genau identifizieren mit den nachfolgenden Schritten:

1.) Man schaut mittels WINSCP auf die Sophos unter /var/log/fallback.log und sucht den Timestamp, an dem die Nachricht generiert wurde. Das sieht dann in etwa so aus:

2017:05:10-09:17:01 SOPHOS_UTM [daemon:info] notify_expiring_certs.pl: INFO - certificate REF_CaMatCukLghXvygo2 will expire
2017:05:10-09:17:01 SOPHOS_UTM [daemon:info] notify_expiring_certs.pl: INFO - notified about 1 certificates, which will expire

Wichtig ist hier die angegebene REF_xxxxxxx, die man sich kopiert.

2.) Von der UTM-Shell aus gibt man dann den folgenden Befehl ein:

cc get_affected_objects REF_CaMatCukLghXvygo2

Wobei die REF_xxxxxx die vorher kopierte ist!

3.) Das nun angezeigte REF_Objekt nortiert man sich und geht in die Web-Konsole der UTM unter Support -> Advanced -> Resolve REF_ und gibt hier das REF_Objekt an und erhält den Namen des Zertifikats zurück.

Sollte es sich wirklich um das PROXY CA-Zertifikat handeln, dann kann man dieses ganz einfach in der Web-Konsole unter Network-Protection -> Filtering Options -> HTTPS CAs erneuert werden.

Wenn man diese Funktion aber NICHT lizensiert hat, dann kann es trotzdem sein, dass die UTM das Zertifikat anmahnt und das kann sehr nervig sein. Ich habe hier nur eine Lösung gefunden und die ist nicht schön, funktioniert aber!

1.) Man meldet sich auf der Web-Konsole an
2.) Man navigiert zu Web Protection -> Filtering Options -> HTTPS CAs

Jetzt kommt der Trick:
Man klickt nochmals auf den Reiter "HTTPS CAs" und nun ist der Button "Regenerate" für einige sekunden klickbar. Schnell klicken und das war es schon! Nicht schön, funktioniert aber!

Quelle: Sophos UTM: Certificate expiry notification