Eternus LT20 S2 Default Password

Für den Fall, dass ich wieder einmal einen Fujitsu Eternus LT20 S2 Bandwechsler konfigurieren muss. Hier das Default Kennwort für den administrativen Zugang: adm001

Warum es kein Windows 9 geben wird…

Microsoft überraschte mit der Ankündigung, dass ihr kommendes Betriebssystem nicht Windows 9 heißen wird, sondern statt dessen Windows 10. Es wurde viel spekuliert über diesen Versionssprung. Als möglicher Grund hierfür wurde beispielsweise genannt, dass die Zahl 9 in Japan als Unglückszahl gilt.
Es sieht nun aber so aus, als habe Microsoft hierfür ganz pragmatische Beweggründe gehabt. Ein Microsoft (?) Entwickler äußerte sich zu dem Thema auf Reddit.
Generationen von Software Entwicklern verwendeten einen simplen Codeschnipsel zur Unterscheidung der unterschiedlichen Windows Versionen.

if(version.StartsWith("Windows 9")) { /* 95 and 98 */ } else {

Was lange Jahre funktionierte, würde nun mit einer Einführung von Windows 9 einiges an Konfusion und Ärger auslösen.

Granuläre Passwortrichtlinien in Active-Directory

Eine Passwortrichtlinie für die Domäne einzuführen ist nicht weiter schwer und lässt sich schnell mit einer Gruppenrichtlinie bewirken. Was aber erst auf den zweiten Blick auffält ist, daß man nur eine Richtlinie für die gesamte Domäne haben kann. Eine Beschränkung auf OU oder Nutzergruppen ist damit nicht möglich. Auch mehrere verschieden gestaltete Richtlinien für unterschiedliche Nutzergruppen kann man so nicht realisieren.

Seit Server 2008 gibt es jedoch einen Weg, unterschiedliche Passwort Richtlinien für unterschiedliche Gruppen einzuführen. Die sogenannte Fine Grained Password Policy.

Ermöglicht wird dies durch die Einführung neuer ADS Objektklassen seit Server 2008.

Voraussetzungen

  • Der Functional Level der Domäne muss mindestens Server 2008 sein.
  • Richtlinien können nur auf Nutzergruppen angewendet werden, nicht auf OU.

Weiterlesen

Brocade FOS und JAVA

Zur Verwaltung von Brocade SAN Switches benötigt man auf dem Client das Java Runtime Environment (JRE). Dies funktionierte jahrelang recht gut, doch in jüngerer Vergangenheit hatte Oracle die Sicherheit verschärft. Dies ist zwar prinzipiell eine gute Idee, aber ein echtes PITA wenn man unterschiedliche Versionen und Anwendungen mit dieser JRE verwalten muss. Beim Zusammenspiel mit des Brocade Fabric OS (FOS) und Java gibt es viele Fallstricke.

  • FOS fordert ab Version 6.3 eine Mindestversion des JRE
  • Oracle hat das JRE ab Version 7 Update 21 (7u21) mit einem hart codierten Verfallsdatum ausgestattet.
  • Software Zertifikate mit veralteter Signatur oder zu geringer Schlüssellänge werden nicht mehr unterstützt.
  • FOS Zertifikate haben ein Ablaufdatum

Das alles endet in einem Sumpf aus Updates und Warnungen. Applikationen seien nicht mehr vertrauenswürdig und dürfen daher nicht mehr gestartet werden. An dieser Stelle brachte mich der lesenswerte Blogartikel von Erwin van Londen weiter. Weiterlesen

ICMP Ping auf Windows Firewall aktivieren

Windows Systeme ab Version 7 und Server ab 2008 haben in den Standard Firewall-Einstellungen ICMP aus Sicherheitsgründen deaktiviert. Das hat zur Folge dass diese Systeme auch nicht mehr auf Echo Requests (PING) antworten. Während einige der Debug Methoden von ICMP als kritisch für die Sicherheit einzustufen sind, ist die PING Funktion (ICMP Typ 8) in der Fehleranalyse sehr wertvoll. Man kann diese selektiv an der Firewall freischalten, ohne alle anderen ICMP Funktionen zu aktivieren.

netsh firewall

Der herkömmliche netsh firewall Befehl ist veraltet, aber er funktioniert noch. Dennoch sollte man künftig nur noch den neuen advfirewall Befehl anwenden.

PING erlauben:

netsh firewall set icmpsetting 8

PING verbieten:

netsh firewall set icmpsetting 8 disable

 

netsh advfirewall

netsh advfirewall firewall add rule name="ICMP Allow incoming V4 echo request" protocol=icmpv4:8,any dir=in action=allow

Danach antworten die oben genannten Server- und Desktop Systeme auf Ping Anfragen, ohne alle anderen ICMP Funktionen zu erlauben.

Die Regel kann mit folgendem Befehl wieder deaktiviert werden:

netsh advfirewall firewall delete rule name="ICMP Allow incoming V4 echo request" protocol=icmpv4:8,any dir=in

Links

ESXi iSCSI Troubleshooting

Für jemanden, der hauptsächlich im FibreChannel Protokoll zu Hause ist, dem bereitet iSCSI immer wieder Spaß und Kurzweil. So geschehen in der vergangenen Woche, als wir ein verzwicktes Phänomen bei der Einbindung eines iSCSI Targets hatten. Auch wenn es eine gute Fingerübung für Troubleshooting war, so brachte es einige graue Zellen zum Rauchen.

Das Szenario

  • Zwei ESXi 5.5 Server mit je 2x1Gbit LAN Adapter für iSCSI
  • je 2 Kernelports in unterschiedlichen Subnetzen (10.0.0.x und 10.0.1.x) unabhängig von Management Network und VM-Network (192.168.1.x)
  • keine Jumboframes (MTU 1500)
  • zwei LAN Switches für Redundanz
  • 2 Datacore Server mit SANsymphony-V 10 und je 2 x 1Gbit für iSCSI Frontend Ports [FE]
Host iSCSI1 iSCSI2
ESX4 10.0.0.14 (vmk4) 10.0.1.14 (vmk5)
ESX5 10.0.0.15 (vmk4) 10.0.1.15 (vmk5)
SDS1 10.0.0.31 10.0.1.31
SDS2 10.0.0.32 10.0.1.32

 

DatacoreiSCSI2

Das Phänomen

Bei der Konfiguration des Software iSCSI Adapters kam jeweils nur für einen Kernelport eine iSCSI Verbindung zustande. Das Verhalten war auf beiden ESXi Servern gleich. Weiterlesen

Windows Updates automatisch deinstallieren

Erst kürzlich hatte Microsoft große Probleme mit einigen Patches des August Patch-Days. Es kam dabei zu Problemen mit den folgenden Sicherheitsupdates:

  • KB2982791
  • KB2970228
  • KB2975719
  • KB2975331

Insbesondere ersteres sogte auf einigen Systemen für den gefürchteten Bluescreen of death (BSOD). Die Patches wurden von Microsoft kurz danach zurückgerufen. Glück für jene, die mit Sicherheitspatches immer ein wenig warten. Andererseits sollten kritische Sicherheitslücken immer sehr zeitnah gestopft werden. Und genau dies tun zum Beispiel WSUS Server. Hier kann man einstellen, daß kritische Sicherheitspatches automatisch für die Installation genehmigt werden, was dazu führt dass eine große Anzahl Systeme mit den problematischen Updates versorgt wurde. Weiterlesen

Reset root password CentOS Appliance

Dies ist wieder einmal ein sehr gutes Beispiel, warum man den Zugang zu Server Konsolen unbedingt schützen muss. Das betrifft natürlich nicht nur Virtuelle Server, jedoch ist hier der Missbrauch besonders einfach, da die Konsolen über LAN erreichbar und nicht mit einer Tür verschlossen sind.

Kennt hier jemand root?

Eine etwas ältere PanoLogic Appliance (Zero-Client Manager) eines Kunden sollte aktualisiert werden. Die Firma gibt es inzwischen nicht mehr und das Produkt wird weder vertrieben noch unterstützt. Dennoch wird es noch oft produktiv eingesetzt. Für die Arbeiten an der Appliance benötige ich den root Login. Leider konnte sich niemand an den root Login erinnern, oder wer diesen gesetzt haben könnte. Der Default Login “password” wurde verändert. Eine Kollektion weiterer möglicher Passworte wurde durchprobiert – jedoch ohne Erfolg. Folglich musste ein Weg gefunden werden, das Kennwort neu zu vergeben. Die Panomanager Appliance basiert auf einem CentOS 2.6.18. Das Verfahren ist geradzu erschreckend simpel.

Einfach zu einfach

Wer erstmal Zugang zur Konsole hat, dem stehen alle Türen offen. Weiterlesen

DataCore SANsymphony-V 10 – possible data corruption

DataCore meldet ein mögliches Treiber-Problem mit dem erst kürzlich veröffentlichten SANsymphony-V 10. Ein entsprechender Customer Alert würde heute versendet:

Potential for Data Corruption – Hotfix Available
In SANsymphony-V 10.0.0.0 we changed the way we work in order to support VMware Thin Provisioning Thresholds. In doing so, we have seen that there is now the potential for a timing issue to take place that can cause data corruption. In order to protect against the possibility of corrupting data, we have redesigned and tested a new driver. The revised driver will be included in SANsymphony-V 10.0 Update1, which we are hopeful will be released in early September, and we suggest holding back any upgrades to SSV10 until that update is available. If you already have customers running SSV 10.0 there is a Hotfix we can provide to protect against this until Update1 is released. Please open an incident and contact support requesting this hotfix for those customers, and when Update1 is released please upgrade as soon as possible after its release.

Es wird nicht genau erklärt, welcher Treiber problematisch ist und unter welchen Umständen. Die Haupaussage ist jedoch, man solle mit der Migration auf SSY10 abwarten bis das Update 1 veröffentlicht wurde. Interne Quellen hatten dies für Oktober 2014 angekündigt, möglicherweise wurde es jetzt aufgrund der Wichtigkeit auf September vorgezogen.

Ich konnte bis jetzt in der Testumgebung mit VMware und SSY10 keine negativen Auswirkungen sehen, obwohl diese unter Last arbeitet. Dennoch hat sich die Zurückhaltung bei der Migration von produktiven DataCore Umgebungen auf neue Hauptversionen wieder einmal bestätigt. Im Labor immer die neuste Version – beim Kunden das erste Update abwarten. ;-)

Datacore SANsymphony-V 10: Purge Disk und gezielte Wiederherstellung

Eine der neuen Funktionen von SANsymphony-V 10 ist die gezielte Wiederherstellung (targeted recovery) von Storage-Allocation-Units (SAU) einer defekten Disk. Mit Hilfe des neuen Purge-Wizards können gezielt die fehlenden SAUs vom Spiegelserver kopiert werden, ohne ein Full Recovery des gesamten Storage Pools zu fahren.

Ich werde hier kurz demonstrieren wie dies in der Praxis abläuft.

Das Szenario

  • 2 Datacore Server mit lokalen Disks
  • 1 SSD mit 256 GB (Tier 1)
  • 2 SAS mit je 146 GB (Tier 2)
  • 2 SATA mit je 1 TB (Tier 3)
  • Auto Tiering mit 10 % reserved space pro Tier
  • 1 vDisk (mirrored), präsentiert an 2 ESX Server

vorher

Die Top Tiers sind zu 90% gefüllt (10% reserviert).

SSY10_smartRec01Action !

Die Platte SAS_2 wird per Hot-Unplug ;-) hart entfernt. Augenblicklich geht der Diskpool in den Fehlermodus. Die Physical Disk wird mit einem Fehlersymbol markiert.

SSY10_smartRec02Sobald eine Disk als ausgefallen gemeldet ist, kann der Purge Assistent im Kontextmenü aktiviert werden. Unter normalen Umständen ist dieser nicht wählbar. Es folgt eine Vorprüfung der Voraussetzungen zum Purge. In der Regel kann der Assistent mit ‘Next’ fortgesetzt werden.

Nach Abschluss des Purge Assistenten wird die fehlende (defekte) Disk nicht mehr angezeigt und die verbleibenden Disks im Pool erscheinen wieder. Der Kopiervorgang beginnt.

SSY10_smartRec03 Man erkennt im folgenden Bild deutlich, dass die wiederhergestellten SAUs zunächst auf den reservierten Bereichen der Top Tiers abgelegt werden – beginnend mit Tier 1, dann Tier 2 usw.

Ein Grund mehr für die neue Tier Reservierung. Denn würde man SAUs zunächst auf einem niederen Tier ablegen, könnte dies den Recovery Vorgang unnötig bremsen.

Wieder aktiv

SSY10_smartRec04Der Vorgang ist abgeschlossen. Alle Reservierungen sind ausgeschöpft, so dass die restlichen SAUs nun auf SATA (Tier3) abgelegt wurden.

SSY10_smartRec05In der Folge werden die Reservierungen wieder befreit, so dass noch mehr kalte SAUs auf den SATA Speicher wandern (nicht dargestellt). Der Diskpool ist wieder zu 100% funktionsfähig. Dazu mussten nur 136 GB vom Spieglserver geladen werden. Über die 1 Gbit Mirrorleitung der Demo-Umgebung war dies in weniger als einer halben Stunde erledigt.

Willkommen zurück

Die zuvor entfernte Disk SAS_2 wurde dem System wieder zurückgegeben. Da die darauf ligenden Daten inzwischen wertlos sind, muss das Volume im Datenträger-Manager gelöscht werden. Datacore erhält somit eine “neue” leere Disk. Im Bild unten befindet sie sich im Status Reclaimation. Man erkennt auch, dass inzwischen ein Teil der Reservierung auf der SSD befreit wurde.

SSY10_smartRec06Am Ende der Prozedur sind wieder alle Reservierungen frei und SAUs wurden von Tier 3 (SATA) auf den freien Raum auf Tier 2 (SAS_2) verschoben.

SSY10_smartRec07Die Verteilung ist sehr Ähnlich zur Anfangssituation vor dem provozierten Plattencrash.