Installation einer Offline Root CA

Aufgrund eines Fehlers und wahrscheinlich, weil ich nicht aufgepasst habe, habe ich bei der Migration von ESXi auf Hyper-V eine VM gelöscht, auf der meine Offline CA gespeichert war. Natürlich hatte ich ausgerechnet von diesem Zertifikat keine Datensicherung des privaten Schlüssels. Da in der Root CA auch noch ein Designfehler vorhanden war bzgl. der CRL, habe ich mich dazu entschieden, ein neues Root Zertifikat zu erstellen und die vorhandenen Designfehler zu korrigieren.

Da sieht man mal wieder, wie wichtig eine vernünftige Planung, auch in einer Testumgebung ist und das man natürlich die Datensicherung, gerade von kritischen Geräten nicht vergessen sollte 😉

Die Grundkonfiguration lässt sich mit folgenden Schritten schnell erledigen:

  1. 1. Standard-Installation von Windows Server 2008 R2 Enterprise Edition (Aktivierung auch gleich erledigen)
  2. Primären DNS-Suffix eintragen
  3. Unter C: ein Verzeichnis ADCS mit zwei Unterverzeichnissen “Database” und “Logs” anlegen
  4. Serverrolle Active Directory Zertifikatsdienste (Active Directory Certificate Services) installieren
  5. Bei Rollendiesten “Zertifizierungsstelle” auswählen
  6. Installationstyp “Eigenständig
  7. Zertifizierungsstellentyp “Stammzertifizierungsstelle
  8. Privater Schlüssel “Neuen privaten Schlüssel erstellen
  9. Kryptografiediensteanbieter: “RSA#Microsoft Key Storage Provider
    1. Schlüsselzeichenlänge “4096” (meine Empfehlung)
    2. Hashalgorithmus “SHA1
  10. Allgemeiner Name dieser Zertifizierungsstelle “F1NaLByte Root Authority” (denkt euch euren eigenen aus 😉 )
  11. Gültigkeitsdauer, da es sich um eine Offline Root CA handelt, kann diese zwischen 20 und 30 Jahren liegen. Wenn dieses Zertifikat kompromitiert werden sollte, verliert es ohnehin seine Gültigkeit.
  12. Zertifikatdatenbank, auswählen des im Vorfeld angelegenten Database-Verzeichnis für die Datenbank und Logs-Verzeichnis für die Logs.

Restliche Abfragen mit Standardwerten bestätigen. Daraufhin ist die Rolle installiert.

Konfiguration Sperrlistenverteilungspunkt

Nun müssen die Sperrlisteninformationen angepasst werden, dass ist wichtig! Hier sind zunächst alle Einträge mit “ldap” und “file” zu löschen, siehe Bild.

Das ganze sollte, nach geänderter Konfiguration, folgendermaßen aussehen:

Eintragen einer verfügbaren URL

Konfiguration Stelleninformationen

Zuletzt sollte ebenfalls der Zugriff auf die Stelleninformationen angepasst werden.

Konfiguration des Zugriffs auf die Stelleninformationen

Veröffentlichung der Sperrliste

Nächster Schritt ist die Konfiguration für das Veröffentlichungsintervall der Sperrliste. Da ich mit dieser Root CA nur meine Sub CA autorisiere, kann das Intervall ziemlich hoch eingestellt werden. Dies sollte aber im Einzelfall betrachtet werden. Bei Ausstellung von mehrere SubCA, sollte man das Intervall entsprechend der Anforderungen anpassen. In meinem Fall habe ich mich für 2 Jahre entschieden.

 

Konfiguration der Zertifikatssperrliste
Zertifikatssperrliste Konfiguration

Nun muss noch die Zertifikatssperrliste veröffentlicht werden: Veröffentlichung der Zertifikatssperrliste

Ist der “File-Pfad” nicht verändert worden, so befindet sich die veröffentlichte Sperrliste nun an folgendem Ort: “C:WindowsSystem32CertSrvCertEnroll

Speicherort der Sperrliste

Diese beiden Dateien können nun mit dem Root- Zertifikat exportiert werden. Die beiden Dateien müssen unter der konfigurierten URL auf dem Webserver zur Verfügung gestellt werden.

Damit ist die Konfiguration der Offline Root CA abgeschlossen und alle notwendigen Dateien stehen zur Verfügung. Der nächste Schritt wäre die Erstellung einer untergeordneten Online CA (SubCA) die, beispielsweise, im Active-Directory veröffentlicht ist.

Schemaerweiterung für SCCM2012

Die Installation der derzeitig, frei verfügbaren System Center Configuration Manager 2012 Beta 2 ist in Vorbereitung. Dazu wurde gerade eine Schemaerweiterung auf einem Domänencontroller erfolgreich abgeschlossen (Successfully extended the Active Directory schema).

Vorgehen erfolgte nach folgendem TechNet-Artikel: SCCM Schemaerweiterung TechNet

Nach der Schemaerweiterung muss noch der Container “System Management” angelegt werden, dieser wird durch die Schemaerweiterung nicht automatisch angelegt.

  • Zum Anlegen des Containers “System Management” ADSI-Edit mit Domänenrechten starten.
  • Rechtsklick Container “System” ->Neu->Objekt
  • Auswahl von “Container”
  • Name: System Management

Mit diesem Vorgehen ist der Container System Management nun vorhanden. Siehe auch TechNet-Artikel

Im nächsten Schritt muss dem Computerobjekt, auf dem der SCCM installiert ist, Schreibende Berechtigung auf den Container eingerichtet werden.

 

VM aus dem SCVMM entfernen ohne Löschen der VHD`s

Bei der Migration einer Debian-Maschine wurden nur die vmdk-Files in vhd transferiert. Danach bekamm ich vom SCVMM einen Timeoutfehler (Error 3101) angezeigt. Die Maschine wurde zwar im Hyper-V-Manager erstellt, aber ohne Konfiguration der Hardware. Da die VHD`s nun vorhanden waren, wollte ich diese nicht löschen oder einen Neustart versuchen.

So konnte ich im Hyper-V-Manager die Hardware hinzufügen und die VM danach starten und die restlichen SChritte aus dem vorherigen Artikel durchführen und die Migration war abgeschlossen.

Leider übernahm der SCVMM-Manager auch durch Aktualisierung nicht, dass die VM nun Lauffähig war. Hier blieb nur die Option “Auftrag wiederholen” und “Löschen”Leider bietet der SCVMM keine Möglichkeit, nur den Eintrag zu löschen. Hierbei muss der Umweg über die Datenbank gegangen werden.

  1. Beenden des Virtual Machinge Manager Service.
  2. Aufrufen des SQL Management Studio, auf dem Server auf dem die SCVMM DB (Default: VirtualManageDB) abgelegt ist
  3. Öffnen der Datenbank und erweitern der Tabelle
  4. Rechtsklick auf tbl_WLC_VObject und z.B. die “obersten 200 Zeilen bearbeiten”.
  5. In der Spalte “ObjectState” könnt ihr den Status der VM sehen. dort sucht ihr euch den Status der VM raus, die ihr entfernen wollt, in meinem Beispiel Status 310.
  6. Mit dem Skript aus dem Artikel “RemoveMissingVMs”  werden alle VMs aus der SCVMM Datenbank entfernt, die den angegebenen Status anzeigen.
  7. Ihr könnt das Skript in SQL auf die bestehende Tabelle anwenden.
  8. Nachdem das Skript ausgeführt wurde, sieht die Ausgabe z.B. so aus:

Danach könnt ihr das SQL Server Management Studio schließen und den Dienst “Virtual Machine Manager” starten. Sobald sich die SCVMM-Konsole öffnet, fällt euch die fehlende VM auf. Diese wird durch Aktualisieren des Hosts wieder angezeigt und mit dem korrekten Status importiert.

Weitere Artikel:

Linux-Migration V2V ESXi to Hyper-V (SCVMM 2008 R2)

Die Migration eines Linux-Host ist im Grunde ähnlich, wie das bereits beschriebene vorgehen, zur Migration einer Windows-VM.

Allerdings gibt es hier einige Konfigurationseinstellungen, die noch angepasst werden müssen. Zunächst einmal sind die VM`s, auf dem ESXi mit einem SCSI-Drive als Bootdevice ausgestattet, Dies wird von Hyper-V nicht unterstützt.

Weiterhin solltet ihr der VM beim erstellen noch eine zusätzliche Legacy-Netzwerkkarte zuweisen, um auf jeden Fall Netzwerkzugriff zu erhalten, da die Integrationscomponents nicht vom SCVMM eingebunden werden.

Nachdem ihr die Migration der Linux-VM vorgenommen habt und diese auf dem Hyper-V-Host startet, könnte es zu Fehlermeldungen kommen, gerade wenn ihr z.B. mehrere Partitionen im System hattet.

Um dies zu vermeiden, solltet ihr zunächst unter /etc/dev schauen, ob dort die IDE-Devices erkannt wurden (zu erkennnen an hda1, hda2, hdc1 usw.) Sollte dies der Fall sein, könnt ihr in mit “mcedit /etc/fstab” in die fstab gehen und dort die devices von sda1-x durch hda1-x ersetzen.

Nach einem Reboot sollten nun auch die Partitionen wieder eingebunden werden und der Boot sollte normal verlaufen.

Um nun noch die Integrationsdienste zu aktivieren, müsst ihr die Datei modules aufrufen “mcedit /etc/initramfs-tools/modules”. Dort tragt ihr folgende Werte pro Zeile ein:

  • hv_vmbus
  • hv_storvsc
  • hv_blkvsc
  • hv_netvsc

Danach aktualisiert ihr durch “update-initramfs –u” den Kernel. Nach einem Reboot sollten die Integrationtools mitstarten und ihr könnt die VM mit den Funktionen des Hyper-V/SCVMM-Manager nutzen.

Migration V2V ESXi to Hyper-V (SCVMM 2008 R2)

So, nachdem die Regeneration der Serverhardware am Wochenende abgeschlossen wird, ist es Zeit die VM`s langsam vom ESXi zum Hyper-V zu verschieben.

Dazu habe ich den ersten ESXi durch eine Server 2008 R2 Installation mit der Roller Hyper-V ersetzt. Da der erste Hyper-V auch gleichzeitig ein virtuelle Maschine mit dem ISCSI-Target als SAN inne hat, wurde auf die Servercore-Installation verzichtet, da ich den RAID-Controller im Laufenden Betrieb managen möchte.

Eine V2V Migration über den SCVMM funktioniert nur mit einigen Vorraussetzungen, die vorher beachtet werden müssen. Hier sei angemerkt, dass der VMware Converter von VMware wesentlich Leistungsfähiger ist, als der Converter im SCVMM 2008 R2.

Solltet Ihr die ESXi-Hosts ohne vSphere Center betreiben, empfehle ich euch, für eine Übergangszeit, den vSphere-Center-Server zu installieren, dieser ist ja für 60 Tage kostenlos. Damit ist eine Migration wesentlich einfacher, da so auch die ESXi Hosts im SCVMM verwaltbar werden.

Eine Migration der VM`s vom ESXi, die in der Hardware Version 7 erstellt wurden und möglicherweise noch mit dem SCSI-Controller VMware Paravirtual ausgestattet sind, ist nicht ohne vorherige Maßnahmen möglich. Um bei diesen VM`s eine V2V Migration per SCVMM zu ermöglichen, ist zunächst ein Zwischenschritt über den VMware Converter notwendig. Die Freeware Version reicht aus.

Über den VMware Converter konvertiert ihr die Maschine unter der Angabe eines anderen Namens (z.B. Zusatz “N”) auf den gleichen Host. Dabei wählt ihr als Hardware-Version “4” und als SCSI-Controller LSI Logic. Nach Abschluss der Migration könnt ihr die neue VM nun, nach der genannten Anleitung, auf einen Hyper-V Host migrieren.

Um eine Migration einer ausgeschalteten VM über den SCVMM vorzunehmen, sind folgende Punkte zu beachten:

1. Falls vmxnet (2)(3)-Netzwerkkarten verwendet werden, diese deinstallieren und durch E1000 Kompatible Netzwerkkarten mit der gleichen Konfiguration ersetzen

2. Nach einem Neustart Deinstallation der VMware-Tools

3. Die VM muss im ausgeschalteten Zustand sein, um eine Migration per SCVMM vornehmen zu können.

4. Im SCVMM V2V-Migration auswählen. In Bibiliotheksfenster werden die ausgeschalteten VM`s angezeigt. Hier wählt ihr die zu migrierende VM aus.

5. Danach wählt ihr noch den neuen Host und die Netzwerkkarten aus (ich verbinde die Karten noch nicht, sondern wähle nur das Netzwerk aus).

6. Nun beginnt die Migration. Zunächst wird die Konvertierung der vmdk-Files in vhd-Dateien vom SCVMM vorgenommen, dass kann je nach Größe der zu migrierenden VM einige Zeit dauern.

7. Nach Abschluss der Migration könnt ihr die VM starten und die Netzwerkkonfiguration vornehmen.

8. Prüft die Ereignisanzeige auf FEhler oder ähnlichem. Sollte euch nichts negatives auffallen, könnt ihr nun die Alte VM auf dem ESX(i) Host löschen.

 

 

Schiesserei Bonnerstraße Ecke Marktstraße

Ja, so kann’s gehen. Eben saß ich noch im Auto mit Jessy vom HBF Köln und wir lachten so ein wenig über das Schauspiel, welches sich vor uns abspielte und scherzten darüber, dass man gar kein Fernsehen schauen muss.
So fuhr ich danach Richtung Wohnung und kam aber nur bis zur Kreuzung Marktstraße/Bonner Straße neben dem Rewe. Vor mir versperrten ca. 5 Polizeiwagen die Kreuzung. Trassier Band tat das übrige. Nicht mal die Straßenseite dürften Fußgänger wechseln… Was war passiert?
Ein Mitbürger hat sich wohl eine Schiesserei mit der Polizei geliefert. Zunächst war er in der Markthalle und versuchte sein Auto zu erreichen um damit zu fliehen. Dabei Schoss er wohl auf die Polizei und er zurück. Trotzdem erreichte er sein Fahrzeug und versuchte über die Bonner Straße Richtung Autobahn zu fliehen. Allerdings waren die Kreuzungen bereits gesperrt und vermutlich dass SEK vor Ort. Als er über die Kreuzung fuhr, wurde mehrmals auf das Fahrzeug geschossen. Eine Kugel traf den Fahrer und dieser verlor die Kontrolle und kam an Bordsteinkante zum Stehen.

Schwer verletzt wurde der Fahrer mit dem Krankenwagen ins Krankenhaus gebracht. Die Kreuzung blieb bis auf weiteres gesperrt, da die Spurensicherung noch nicht vor Ort war.
Busse blockierten die Zufahrt von der Schönhauser Straße vom Rheinufer kommend, dumm nur, dass ich hinter dieser Barriere stand. Aber der Busfahrer war so freundlich und lies mich doch wieder abziehen.

RAM Upgrade Powerserver

Für meinen Hauptserver auf Intel Xeon Basis habe ich durch Zufall noch schöne 2 x 16G DDR Module von Hynix erstanden. Diese sind heute bei mir angekommen und wurden erst mal mit MemCheck geprüft. Test erfolgreich bestanden. Nun ist aber SChluss mit Serverhardware. Aber 32GB aufgeteilt in 2 16GB Riegel, dass ist schon was feines 🙂

MemCheck Hynix 32GB (2x16GB)
MemCheck Hynix 32GB (2x16GB)

Vorbereitung RAID Benchmark Dell Perc 5 (LSI 8408E) vs Adaptec 51245

Für das geplante SAN und die anschließende Servermigration werde ich einige Benchmarks durchführen. Geplant ist der Einsatz von 6 x Samsung SpinPoint HM640IJ (7.200RPM, 16MB Cache, 640GB) an einem Adaptec 51245.
Derzeitig befinden sich noch ein Dell Perc 5/i und ein Dell Perc 6/i im Einsatz. Beide werden unter gleichen Voraussetzungen in den nächsten Tagen einem Benchmark unterzogen. Möchte sehen, wie die Performance ist und ob die RAID-Controller mit den genannten Festplatten überhaupt Unterschiede in der Performance zeigen. Anbei eine kleine Übersicht über die Unterschiede zwischen den Controllern.

Feature Vergleich RAID Controller
Controller Dell Perc 5/i (LSI 8408E) Dell Perc 6/i Adaptec 51245
CPU Intel IOP333 I/O ROC (LSI-1078) ROC 1,2 GHz Dual-Core
RAID-Level 0, 1, 5, 10, 50 0, 1, 5, 6, 10, 50, 60 0, 1, 1E, 5, 5EE, 6, 10, 50, 60
Ports 8x SATA/SAS 8x SATA/SAS 1 x ext. SFF-8088 / 3 x int. SFF-8087
BBU Yes Yes Yes
Cache 256MB Memory (Max. 512) Integrated 256MB DDRII Integrated 512MB DDRII
Maximum Drivenumber 256 256 256
Online Capacity Expansion Yes Yes Yes
Dedicated and Global Hot Spares Yes Yes Yes
SATA NCQ Support No Yes Yes

Serverhardware Regeneration

Aufgrund der bereits genannten, bevorstehenden Wechsel der Virtualisierungslösung wird auch die Serverhardware nach und nach durch neue Hardware ersetzt.

Den Anfang machte der Austausch des Dell PE1950, dieser war mit 2 Intel Xeon 5140, 8GB RAM, eine Perc 5/I mit 2 x 1TB Samsung Spinpoint F3 im RAID 1, einem DRAC5-Controller ausgestattet und wurde bei eBay verkauft.

Aus dem erzielten Erlös wurde folgender Server gekauft:
1 x Intel Serverbarebone SR1625URR 190€
1 x INTEL AXXGBIOMOD (2 x 1GBit) 50€ (aus USA importiert)
1 x Intel E10G42BTDA 10GBit 51€
1 x Intel AXXRMM3 (Remotemanagement Karte) 35€
1 x Intel Xeon E5507 134€
2 x 4GB Kingston KVR1333D3D4R9S/4G (1333/ECC/Reg) 55€
2 x 8GB Kingston (1066/ECC/Reg) 100€
2 x 4GB RAM 75€

Daraus ergibt sich eine Summe von 690€. Ich denke für diesen Preis habe ich da einen sehr ordentlichen Server zusammengestellt.
Wie ihr seht, fehlt dem Server allerdings ein RAID-Controller. Das liegt daran, dass der zweite Austausch der Server gleichzeitig ein SAN werden soll und der o.g. Server als reiner Virtualisierungshost und als Backup-System dienen soll.
Der zweite Server ist derzeit noch in Arbeit. Allerdings bin ich mir noch nicht sicher, ob ich dazu mein bestehendes System (Supermicro X7DVL-E mit 2x Xeon L5410 und 16GB RAM) lediglich erweitere oder dieses System ebenfalls austausche.
Das virtuelle SAN soll seinen Platz im folgenden Gehäuse finden, einem Chenbro RM234, welches Platz für 12x 2,5″ SAS/SATA-Festplatten bietet und auf bis zu 24 Plätze erweitert werden kann.Servergehäuse Chenbro RM234 für bis zu 24 x 2,5" SATA/SAS Festplatten

Ein paar Bilder von den gekauften Komponenten findet ihr in der Mediathek.

Migrationsvorbereitung ESXi zu Hyper-V

In nächster Zeit liegen bei mir doch noch so einige Projekte an. Zunächst steht ein Wechsel der Virtuellen Maschinen von ESXi zu Hyper-V an. Gründe liegen vor allem in den benötigten Features.
Der ESXi bringt viele Features mit, die ich von Hause aus nicht benötige. Features die ich benötige sind wiederrum nur in den Lizenzpflichtigen Versionen enthalten (z.B. vMotion).
Aufgrund der Lizenzrechtlichen Geschichte und der ausreichenden Features von Hyper-V werde ich meine derzeitigen Virtuellen Maschinen nach und nach zu Hyper-V migrieren.