Heute hat mir (auf dem Bild) ein (großartiger) IT-Admin bei einem (großartigen) Kunden-Unternehmen „einfach so“ ein T-Shirt geschenkt. Es ist der Wahnsinn.
Danke Säge, wir (ich bin ja nicht alleiue hier) haben laut gelacht und uns wahnsinnig gefreut 😂😍
Das Upgrade auf vCenter 8.0 bleibt manchmal „kommentarlos“ bei 80% stehen und bewegt sich nicht mehr. Auch nach einiger Zeit nicht. Die neue Appliance wurde aber erfolgreich installiert und botet (scheinbar) auch fehlerfrei.
Man kann die neue virtuelle vCenter-Appliance aber im Inventar sehen, pingen und auch die Konsole öffnen.
Lösung
Was die Ursache für diesen Effekt ist, wissen wir auch nicht genau. Aber man kann die Installation und Datenmigration problemlos über die VCSA-Oberfläche der „neuen“ vCenter-Instanz fortsetzen. Man öffne:
https://<temporäre-vcenter-adresse>:5480
und melde sich mit dem „frisch „alten“ root-Kennwort dort an.
Die zugehörige (temporär) IP-Adresse zeigt die Konsole ja an.
Wenn man dem Assistent dann dort weiter folgt, läuft das Setup (in aller Regel) problemlos durch.
Wenn man im Fehlerfall einen Linux-Server debuggen muss, kann es sein das die (gut gemeinte) Default Sysctl Konfiguration dem Admin die Konsole „vollmüllt“.
Die Fehlermeldungen die der Kernel in die Konsole ausgibt sind zwar in der Regel wichtig und sollten WIRKLICH gelesen werden, helfen bei der Fehlersuche und vor allem -behebung natürlich nicht. Es wäre also schön wenn man die Meldungen temporär deaktivieren könnte.
Lösung
Temporäre Abhilfe (bis zum nächsten boot) schafft dmesg. Mit dieser Zeile unterbindet man alle ungewollten Nachrichtenausgaben:
dmesg -n 1
Wobei es in aktuellen Linux-distributionen (Debian, Ubuntu, Fedora …) noch schneller geht:
dmesg -D
-D = Disable. Was einen Alias zu -n 1 darstellt. Der Parameter -E = Enable schaltet die Augabe wieder ein. Ein Reboot ist nicht notwendig.
Manchmal ist ja gar nicht die Technik schuld, sondern die bedienende Entität. Oder anders ausgedrück: Dumme User, oder DAUs („Dümmste anzunehmede User“). Ich habe letzte Woche einen wie ich finde großartige neue Bezeichnung aus dem medizinischen Bereich gelernt: Morbus Bahlsen. Glücklicherweise nicht für mich, sondern für einen „Patienten der der seine verpflichtende Corona-Impfung mit religiösem Eifer abzulehnen suchte“ 🤦♂️
Schön zu erfahren, welche Bezeichnungen andere Berufsgruppen für diesen Zustand haben. Der Vollständigkeit halber hier die in unserem direkten Umfeld einge gebräuchlichen Bezeichner 😁
Morbus Bahlsen Im Medizinerdeutsch eine scherzhafte Umschreibung für Debilität bzw. Dummheit. Die Bezeichnung leitet sich von einem deutschen Keks-Hersteller ab und ist aus umgangssprachlichen Ausdrücken wie „einen an der Waffel haben“ bzw. „weicher Keks“ abgeleitet.
PEBCAK / EIFOK / ZBuS DER Klassiker. The „Problem Exists Between Keyboard And Chair“. Das gemeldete Problem reduziert sich eindeutig auf die Zone „zwischen Tastatur und Stuhl“. Im Beamtendeutsch (auch staatliche Instanzen haben zynische Admins) auch gerne „ZBuS“ genannt, das „Problem befindet sich zwischen Bildschirm und Stuhl“. Aus der amerikanisch-akademischen Gemeinschaft um „Error In Front Of Keyboard“ bereichert.
BDU Die aggressivste variante, für unbelehrbare Nutzer Vorbehalten. „Brain Dead User“ oder auch „Brain Dead Unit“ (je nach Verhalten). Auf gut Deutsch: Das dinf „Hirntote Benutzer“
ID10T Der Klassiker, das Wort „Idiot“ in L33tSP34K. Gerne als „Comment“ im AD für ganz bestimmte Objekte genutzt. Eine gute Anamnese ist bei der Fehlersuche hilfreich!
Layer-8 Fehler Das OSI-Schichtmodell endet eigentlich mit dem 7. Layer, der Anwendungsschicht. Irritierenderweise wurde bei der offiziellen Standartisierung der „8. Layer“, also der Anweder, ignoriert. Jeder Admin weiss aber um diese besonders fehleranfällig Komponente.
InstRes User Aus dem Maschinenbau: „Instructions Resistant“ oder auch „Resistent gegen Anleitungen“. Im Akademisch-Schulischen Bereich auch als „Bildungsresistent“ genannt.