Schlagwort-Archive: Server

ESXi, vSphere: Der Hardware-Überwachungsdienst antwortet nicht

Problem:
Verbindet man sich mit dem vSphere-Client auf einen ESXi Server und möchte sich den Hardwarestatus anzeigen lassen, erhält man folgende Fehlermeldung:
Hardware-ÜberwachungsdienstDer Hardware-Überwachungsdienst antwortet nicht; der Host ist nicht eingeschaltet.
Die Meldung ist natürlich recht irreführend, da der Host läuft und lediglich der Hardware-Überwachungsdienst nicht schnell genug antwortet.

Lösung:

Man verbindet sich per vSphere-Client auf Server und wählt direkt den betroffenen Host aus.
Dort öffnet man den Bereich „Konfiguration“ und dort das Sicherheitsprofil, das unter „Software“ zu finden ist.
Jetzt im oberen Bereich („Dienste“) die „Eigenschaften“ auswählen und den CIM-Server auswählen. Das ist normalerweise der letzte Eintrag in der Liste. Nun diesen Dienst neu starten (über den Punkt „Optionen“).
Danach den vSphere Client schließen, neu öffnen und die Verbindung wieder herstellen. Nun wieder den Reiter „Hardwarestatus“ öffnen und evtl. noch mal rechts oben auf „Update durchführen“ klicken.

Wenn das nicht hilft, kann man noch versuchen den Watchdog neu zu starten. Das ist in einem anderen Beitrag beschrieben.

SLES (SuseLeap): Runlevel ändern

Um den Standard-Runlevel im SLES oder SuseLeap zu ändern, muss man zunächst einmal wissen, dass Suse dazu übergegangen ist, den Runlevel mit systemd zu verwalten.
Zunächst einmal kann man weiterhin die Runlevel mit “init 3” und “init 5” wechseln. Aber hier gehts um den Level, der beim Starten aufgerufen wird.

Variante 1:
Welcher Level ist eingestellt?
systemctrl get-default

Den Runlevel entsprechend den Leveln 2,3,4 (mehrbenutzer, nicht grafisch) setzen:
systemctrl set-default multi-user.taget

Den Runlevel entsprechend 5 (mehrbenutzer, grafisch) setzen:
systemctrl set-default graphical.target

Prüfen kann man das dann wieder mit “systemctrl get-default”

Variante 2:
Den gesetzen Standardrunlevel prüfen:
ls –l /etc/systemd/system/default.target
Ergebnis:
/etc/systemd/system/default.target –> /usr/lib/systemd/system/graphical.target
Es ist also die grafische Oberfläche gesetzt.

Setzen der nicht grafischen Oberfläche:
ln –sf /usr/lib/systemd/system/multi-user.target  /etc/systemd/system/default.target

Prüfen der Einstellung:
ls –l /etc/systemd/system/default.target
Der Link sollte jetzt auf multi-user.target verweisen.

Virtual Connect Firmware Update ohne Downtime

Vorarbeiten:
Zunächst muss man klären, dass alle angeschlossenen Server/Storagesysteme redundant angebunden sind. Die Anbindung muss also jeweils über zwei Enet oder FC Module gegeben sein.

Danach öffnet man den OA (HP BladeSystem Onboard Administrator) und geht unter “Systems and Devices” auf “Rack Firmware”. Dort sieht man in der Übersicht die Version des OAs.
Dann klickt man links auf “Interconnect Bays”, um sich die Bezeichnungen anzeigen zu lassen. Klickt man die Module einzeln an, kann man sich unter “Information” die “Part Number” und die “Serial Number” anzeigen lassen.
Mit diesen Nummern sucht man sich jetzt bei HP  die passende Firmware: https://www.hpe.com/us/en/support.html
Dort unter “Product Support” –> “HPE Servers, Storage and Networking” dien entsprechenden Downloads holen.
1. HP BladeSystem c-Class Virtual Connect Support Utility
(VCSU)
2. Die Firmware an sich. In dem Ordner befindet sich eine *.bin Datei. Z.B. vcfwall445.bin im Ordner
HP BladeSystem c-Class Virtual Connect Firmware, Ethernet plus 48Gb 20-port and 816Gb 24-port FC Edition

Ferner legt man sich über den “Virtual Connect Manager” ein aktuelles Backup der Virtual Connect Domain an.

Das eigentliche Update:

OA:
Sollte ein OA Update notwendig sein, kann man das über die Weboberfläche durchführen. In der linken Spalte unter “Active Onboard Administrator” –> “Firmware Update”

Virtual Connect:
Für das eigentliche Update installiert man nun auf einem Server das VCSU. Jetzt öffnet man die CMD und begibt sich in das Verzeichnis, in dem das Utility installiert ist.
cd “C:\Program Files (x86)\Hewlett-Packard Company\Virtual Connect Support Utility\

Funktionsprüfung des Tools:
Mit folgendem Befehl erhält man eine Übersicht der eingebauten Module und der Firmware-Version:
vcsu –a version –i IP-DES-OA –u BENUTZERNAME –p *
Danach wird man nach dem Kennwort gefragt. Anschließend muss man noch den Benutzernamen und das Kennwort des Virtual Connect Domain Administrators eingeben.
Nach einer kurzen Wartezeit erhält man eine Tabelle mit den Angaben. Wenn das klappt, führt man einen “healthcheck” durch.
vcsu -a healthcheck -i <IP> -u <USER> -p <PWD>

Nach so viel Vorarbeit jetzt das eigentliche Update:

vcsu.exe –a update –i <IP> –u <USER> –p <PWD> –l C:\HP-Firmware\<firmwarename>.bin –vcu <USER> –vcp <PWD> –q –oe manual –of manual

Wichtig sind die beiden letzten “manual” Einträge. Nicht aus Versehen zu früh abschicken. Smile
Zur Erklärung, was wir dort tun:
-a update    Die “Action” ist “update”
-i    IP-Adresse des OA
-u, –p, –vcu, –vcp    Die beiden Benutzerkonten
-l     “location” – der Pfad zur Updatedatei
-q    “quiet” – das Tool fragt während des Updates nicht nach, ob wirklich aktualisiert werden soll
-oe    Aktivierung der VC-Enet Module (Ethernet)
-of     Aktivierung der VC-FC Module (Fibre Channel)

Was passiert jetzt während des Updates?
Das VCSU entpackt die *.bin Datei und schiebt die benötigte Firmware auf die einzelnen Module.
Da jetzt die Aktivierung auf “manuell” steht, ist die Firmware zwar für die Module verfügbar, aber sie wird erst nach einem Neustart der einzelnen Module aktiv.
Nachdem das VCSU jetzt fertig ist (kann schon recht lange dauern), öffnet man den OA und klickt im Bereich “Interconnect Bays” auf ein Modul. In der Übersichtsseite geht man jetzt auf “Virtual Buttons” und klickt auf “Reset”. So startet man mit zeitlichem Abstand die Module durch.
Am besten macht man sich pro Modul ein cmd-Fenster auf und pingt es per ping –t <IP> an. Dann sieht man, wann ein Modul neu startet.
ACHTUNG: Zwischen den Modulstarts ausreichend Zeit lassen. Mindestens 5 Minuten sollte man den Modulen schon gönnen!
Es bietet sich an ein Enet Modul und danach dann ein FC Modul zu starten. Dann das andere Enet und das zweite FC Modul.

Den Erfolg der Aktion sieht man dann entweder im OA unter “Rack Firmware” ganz unten im Bereich “Interconnect Firmware Information” oder wieder über das VCSU
vcsu –a version –i IP-DES-OA –u BENUTZERNAME –p *

Dataprotector: Linux Clients ohne rexec und rcp

Umgebung:
HP Dataprotector mit einem Linux Installationsserver und einem Windows Cell-Server.

Das Problem:
Wenn man im HP Dataprotector einen Linux-Client hinzufügen will, kommt eine Meldung, dass DP sich nicht über rexec und rcp am Client verbinden kann, um die Software zu installieren.
no-rexecec

Weiter oben im Fehlerprotokoll sieht man allerdings, dass zuerst eine ssh Verbindung probiert wird. Leider gelingt das nicht, weil man an dieser Stelle keine Anmeldedaten übergeben kann. Der Anmeldeversuch wird abgewiesen.

Lösung:
Um den Dataprotector Client zu installieren, benötigt man eine ssh-Verbindung OHNE Passwortauthentifizierung.

Erster Schritt:
Mit ssh vom Installationsserver zum Client verbinden.
Jetzt noch mal vom Client zum Installationsserver verbinden.
Dadurch werden die beteiligten Rechner gegenseitig schon mal in ssh zu den “known-hosts” hinzugefügt.
ACHTUNG:
Bitte einmal nur mit dem Hostnamen und danach noch mal mit dem FQDN verbinden. Z.B.:
’ssh linuxclient’ und danach noch mal ‘ssh linuxclient.domain.local’
Dataprotector verwendet beide Varianten!

Zweiter Schritt:
Im root home Verzeichnis in den Ordner .ssh wechseln.
Dort generiert man jetzt ein DSA Schlüsselpaar (private/public)
ssh-keygen –t dsa
Dadurch werden zwei Dateien generiert, die in der Regel ‘id_dsa’ und ‘id_dsa.pub’ heißen.
Den öffentlichen key (pub) kopiert man jetzt auf den Rechner, mit dem man sich ohne Kennwort verbinden möchte.
ssh-copy-id –i ~/.ssh/id_dsa.pub benutzer@hostname
oder
cat ~/.ssh/*.pub | ssh benutzer@hostname ‚umask 077; cat >>.ssh/authorized_keys‘
Als Test kann man jetzt probieren, ob man sich vom Installationsserver aus auf den Client ohne Passwort verbinden kann.

Dritter Schritt:
Auf dem Linux-Client noch inet aktivieren. Bei Suse im YAST unter Netzwerkdiensten xinet aktivieren. Dort muss sonst nichts weiter ausgewählt werden.

Viertens:
Jetzt sollte die Installation des Clients gelingen. Danach bitte noch folgendes prüfen:
Auf dem Client sollte in der /etc/services (meistens am Ende) folgender Eintrag vorhanden sein:
omni             5555/tcp    # DATA-PROTECTOR
Es darf auch kein anderer Dienst auf dem Port 5555 laufen, da dies der Standardport für Dataprotector ist.
Es ist NICHT möglich, den Port für einen Client im DP zu ändern.
Wenn dies notwendig sein sollte, muss der Port für alle Clients geändert werden.

Ein letzter Test:
Auf dem Cellserver (nicht dem Installationsserver) anmelden und versuchen, ob man eine Telnetverbindung auf Port 5555 aufbauen kann.
telnet clientname 5555
Wenn es Telnet auf dem Cellserver nicht gibt, kann man das auch alternativ mit einer Software wie Putty probieren.
Ich teste das gerne direkt vom Cellserver aus, da dieser Server die Verbindung später benötigt.

Canon ScanFront 330 und Netzwerk Shares

Will man mit einem Canon ScanFront (Canon imageFORMULA ScanFront 330) auf ein Netzwerkshare scannen will, kann es unter Windows 2008 und Windows 2012 zu Problemen kommen.
Wenn man nämlich seine Freigabe in der Oberfläche eingetragen hat und dann ein Dokument scannt, erhalt man einen „Systemfehler 53 (Netzwerkpfad nicht gefunden).

Okay … kennt man von Uraltclients, die mit verschlüsselter Übertragung im Netzwerk nicht klar kommen. Also habe ich mir das Ding näher angeschaut. Als Betriebssystem kommt ein WindowsCE zum Einsatz *hüstel*. Das erklärt mir einiges.

Die Lösung:
Wir benötigen: Einen Windows Rechner mit 32 bit und die Software „ScanfrontService„.
ACHTUNG: Funktioniert NICHT mit 64bit Windows!
Ich habe schlicht und ergreifend einen Windows 7 (x86) PC als virtuelle Maschine aufgesetzt und darauf dann die Software installiert, die man auf der Canon Homepage runterladen kann.
Der Scanfront Service installiert einen Dienst auf dem PC, der dann im Hintergrund mitläuft. Dieser PC ist jetzt der ScanFront Service Server. Zusätzlich muss man in der Geräte-Konfiguration des Canon ScanFront noch bei den Einstellungen den PC als „ScanFront Service Server“ eintragen.

Danach sollte man auch auf Netzwerkshares scannen können.
Alles in allem eine sehr spröde Angelegenheit und sehr wahrscheinlich der letzte Canon Scanner, den wir angeschafft haben.  🙂