Orchestrator

VRO Authentifizierung zurücksetzen

/var/lib/vco/tools/configuration-cli/bin/vro-configure.sh reset-authentication

vCO/vRO Appliance mehr Java Heap

Die Appliance ist etwas “mager” mit Java Heap ausgestattet. Darum:

  • /usr/lib/vco/app-server/bin/setenv.sh editieren
  • Zeile beginnend mit MEM_OPTS auf MEM_OPTS=“-Xmx6144m -XX:MaxPermSize=256m -Xss256k -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=90 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/core/” ändern
  • Neustart

Bei mir hat die Appliance 4 CPUs und 8GB RAM bekommen.

vCO/vRO Workflows in der WebGUI ohne vorbelegte Parameter

WFs in der WebGUI sind mit den Parametern des Objektes vorbelegt, bei dem der WF als Kontext Action gestartet wurde. Meistens jedenfalls :-)

Sollte dies nicht der Fall sein, liegt es an einer “fehlerhaften Registrierung” des vCenters im Orchestrator. Die Registrierung (der String) muss exakt gleich wie in der WebGUI sein. D.h. incl. Groß/Kleinschreibung. Darum erst in die WebGUI gehen, vCenter Instanz auswählen und schauen, wie die Registrierung aussieht und genau so verwenden. Das vCenter kann ja auch mittels IP registriert sein…

VCO / VRO als WebGUI Extension registrieren

Es kommt immer wieder die Frage, was man im WF Register … extension als External address … angibt. Hier reicht nicht die IP oder FQDN der VCO Instanz aus, sondern incl. https und Port, wie im Screenshot…

Dabei ist wichtig, sowohl die vCenter Plugin Konfiguration, wie auch die oben stehende Extension Registrierung mit FQDN und nicht mit IP vorzunehmen. Ansonsten werden bei WFs, die über die WebGUI aufgerufen werden die Parameter nicht vorbelegt…

Keine vCenter/AD etc. Workflows in Libraries Pfad vorhanden

Wenn eine vRO 6.x Appliance ausgerollt wird, kann es vorkommen, dass nach der vollständigen Konfiguration des Orchestrators unterhalb des Library Pfades keine Workflows bzw. nur sehr wenige vorhanden sind. Trotz installierten vCenter- oder AD Plugin sind z.B. dafür keinerlei Workflows da.

Das Problem wird meist durch die Umkonfiguration der vRO Datenbank hervorgerufen (PostgreSQL → SQLServer).

Die Lösung ist simpel. In der Konfigurationsoberfläche gibt es den Punkt “Troubleshooting”.

In diese Oberfläche wechseln und dort “Reset current version” auswählen. Danach die Appliance neu starten. Dadurch werden beim Neustart alle Plugins neu installiert und sieh da - alle Workflows sind wieder da….

ERR_SSL_WEAK_SERVER_EPHEMERAL_DH_KEY bei vCO/vRO Aufruf

Die meisten Brwoser haben inzwischen auf Schwachstellen in der SSL/TSL Verschlüsselung reagiert und unsichere Schlüsselgruppen verbannt. Dazu zählt auch der Diffie-Hellman Schlüsselaustausch mit zu kurzer Länge, der vor allem auch die Logjam Attacke ermöglichte.

Das führt dazu, dass aktuell bei Aufruf der vCO Konfigurations- oder Übersichtsseite der Fehler “ERR_SSL_WEAK_SERVER_EPHEMERAL_DH_KEY” angezeigt wird und die entsprechende Seite nicht geladen werden kann.

Es gibt zwei Lösungsmöglichkeiten:

  • Den Brwoser dazu zu bringen, diese Schlüssel doch zu akzeptieren (gibt's mehr als genug Anleitungen dafür), das halte ich aber für sehr problematisch
  • Den Orchestrator dazu bringen, diese unsicheren Schlüssel nicht mehr zu nehmen.

Der zweite Weg ist recht einfach. Für den App-Server muss in der Konfig-Datei server.xml nur nach ciphers gesucht werden. Bei der vCO/vRO Appliance liegt die Datei unter /etc/vco/app-server und bei einer Windows Installation sollte diese unterhalb von …\app-server\conf liegen. Da die Konfigurationsseite mit einem separatem Server ausgeliefert wird, muss ebenfalls /var/lib/vco/configuration/conf/server.xml editiert werden.

Originalinhalt:

... scheme="https" secure="true" sslEnabledProtocols="TLSv1, TLSv1.1, TLSv1.2" strategy="ms"
 
ciphers="TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_CBC
_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA"/>

Ändern in

... scheme="https" secure="true" sslEnabledProtocols="TLSv1, TLSv1.1, TLSv1.2" strategy="ms"
 
ciphers="TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA"/>

Das war alles…

vCO - externe SQLServer Datenbank

Wenn vCO in größeren Umgebungen verwendet wird, soll eine externe DB genutzt werden. Ich bevorzuge SQLServer. Die entsprechende DB soll dann auf ALLOW_SNAPSHOT_ISOLATION und READ_COMMITTED_SNAPSHOT gesetzt werden. Der einfachste Weg:

ALTER DATABASE TEST
SET READ_COMMITTED_SNAPSHOT ON
WITH ROLLBACK IMMEDIATE;
GO
ALTER DATABASE TEST
SET ALLOW_SNAPSHOT_ISOLATION ON;
GO

WinRM für PowerShell Plugin einrichten

Für Windows 2008 R2 ist eine ganze Menge Handarbeit nötig: schubis_anleitung_winrm_mit_w2k8r2.pdf

Bei Windows 2012 und PowerShell 3 geht dies wesentlich einfacher mit Enable-PSRemoting. siehe Technet Artikel

Das Enable-PSRemoting aktiviert den WinRM Dienst und und - das ist so ziemlich das wichtigste - setzt die ACLs via SDDL. Möchte man nun einem Nutzer Rechte geben, nutzt man der Einfach halber lieber winrm configSDDL default.

Nach dem Beenden des Kommandos wird der SDDL String ausgegeben:

Diesen SDDL String kann man wiederum dazu nehmen, die Berechtigung auf verschiedenen Server Auszurollen:

Ggf. muss Orchestrator noch als Trusted Host hinzugefügt werden.

Set-Item wsman:\localhost\Client\TrustedHosts vco-server -Concatenate -Force

Wenn man dann noch aus dem vCO Basic Authentication verwenden möchte, muss man dies auf dem Zielsystem noch einschalten.

winrm set winrm/config/service/auth @{Basic="true"}
winrm set winrm/config/service @{AllowUnencrypted="true"}
winrm set winrm/config/client/auth @{Basic="true"}
winrm set winrm/config/client @{AllowUnencrypted="true"}

Es wäre zu schön. wenn dies reichen würde. Auch in den GPOs muss Basic Auth eingeschaltet werden. gpedit.msc → Computer Configuration → Administrative Templates → Windows Components → Windows Remote Management (WinRM) Bei Client und Server die Basic Authentication einschalten. Danach sehen die winrm config Abfragen auch etwas anders aus:

C:\Windows\system32>winrm get winrm/config/service/auth
Auth
    Basic = true [Source="GPO"]
    Kerberos = true
    Negotiate = true
    Certificate = false
    CredSSP = false
    CbtHardeningLevel = Relaxed
 
C:\Windows\system32>winrm get winrm/config/client/auth
Auth
    Basic = true [Source="GPO"]
    Digest = true
    Kerberos = true
    Negotiate = true
    Certificate = true
    CredSSP = false

Danach muss, wie im Win2K8R2 Dokument beschrieben, noch Kerberos konfiguriert werden. Wer die 6er vSphere Appliance einsetzt → /usr/java/jre-vmware/lib/security/ (steht auch bei der aktuellen Doku von VMware falsch drin….)

krb5.conf
[libdefaults]
default_realm = DOMAIN.DE
udp_preference_limit = 1
[realms]
DOMAIN.DE = {
kdc = DC-01.DOMAIN.DE
default_domain = DOMAIN.DE
}
[domain_realm]
.domain.de=DOMAIN.DE
domain.de=DOMAIN.DE

Resourcen

Meine Infos rund um Orchestrator hole ich vor allem von Jörg Lew, Freund und oft schon rettender Helfer. Auf seiner Seite www.vcoportal.de gibt es sehr viele und nützliche Infos rund um Orchestrator und dessen Plugins.

Eine weitere Sammlung beherbergt www.vcoteam.info. Dort gibt es ebenfalls eine Menge Beispiele.

Und natürlich die Seiten der VMware Community unter http://communities.vmware.com/community/vmtn/server/vcenter/orchestrator. Dort ist besonders der Artikel und die Beispiele von Christophe Decanini über VCD Blocking Tasks und deren Verarbeitung hilfreich.

Anmelden des vCO Clients schlägt mit einer java.jms.JMSException fehl

Bei mir ist meist für das Problem die FireWall bei einer Windows vCO Installation dran schuld gewesen.

Meist schalte ich diese einfach aus. In Kundenumgebungen ist dies aber nicht immer möglich. Schuld an dem Fehler sind die geblockten Ports 8286 und 8287, die so nicht in den vCO Requirements drin stehen…

Übrigens hilft nicht, “Notify me” bei der Firewall einzuschalten, um geschlossene Ports mitzubekommen. Bei mir gabs nie einen Hinweis aufs Blocken :-(

Plugins

vCenter Orchestrator kann mit div. Plugins erweitert werden.

Ich habe bisher mit fogenden gearbeitet:

vCloud Director Plugin Konfiguration

Falls es Probleme bei der Konfiguration des vCloud Director Plugins gibt, ist meist das Zertifikat schuld ;-)

Nutzt man z.B. Shared Session für die Nutzer und bekommt immer wieder die Meldung, das der Nutzer XY nicht angemeldet werden kann, ist meist das Zertifikat des vCD nicht geladen bzw. nicht mehr gültig.

Einfach kontrollieren, indem man auf Zertifikate geht, dort bei Download from URL die vCD IP oder Hostnamen eintragen, Zertifikat abrufen und speichern.

Das war bisher immer das Problem, wenn die Anmeldung nicht funktionierte….

vCO Appliance "vergisst" FQDN

Wer das Problem hat, dass die vCO Appliance nach einem Reboot den falschen Hostnamen hat, sollte die Datei /opt/vmware/share/vami/vami_set_hostname wie in KB Article 2012535 beschrieben, editieren.

Migration Windows vCO auf vCO Appliance

  1. Download und Deploy der Appliance
  2. Netzwerk konfigurieren
  3. als root/vmware anmelden
  4. Datei /opt/vmware/share/vami/vami_set_hostname editieren
  5. unter http://vcoip/ “Orchestrator Configuration” das Defaultpasswort ändern (für Nutzer vmware)
  6. auf der Console die Netzwerkeinstellungen überprüfen und korrigieren (bei mir hat er den Hostnamen als erster DNS Server eingetragen :-( )
  7. alle Plugins installieren, die man im Source vCO hatte
  8. Konfiguration im Source vCO exportieren
  9. Orchestrator Configuration mit vmware / password starten
  10. Konfiguration im Target vCO importieren
  11. unter Network die IP Adresse der vCO Appliance auswählen und speichern
  12. ggf. noch den vCenter FQDN bei “Lizenzen” eintragen, wenn dort “localhost” verwendet wurde

Stolperfalle bei XML mit J4X einlesen

Ich hatte einen simplen Task in einen Workflow mit zu gießen. Dieser bestand aus folgenden Workflows:

  1. Generieren von Dummy XML Dateien und Weitergabe des Dateiinhaltes als String
  2. XML Content des Strings mit J4X bearbeiten und bestimmte Inhalte von Elementen als OUT Parameter weitergeben
  3. die OUT Parameter als IN Parameter für einen SQL Workflow zum Wegschreiben in eine DB nutzen

Alles lief wunderbar bis auf den ersten Test des Workflows :-(

Mandatory field not set” war die Fehlermeldung… Doch wieso das? Ausufernde Debugmeldungen zeigten, dass alle Parameter gesetzt waren und der Workflow direkt zwischen den Workflows 2 und 3.

Es hat eine ganze Weile gebraucht, bis ich das Problem erkannt hatte. Deshalb der Artikel - es kann jedem passieren :-)

Um die Lösung vorneweg zu nehmen - es lag an der automatischen J4X Konvertierung.

Ich möchte es anhand eines Beispiels zeigen. Folgende XML Datei ist zu bauen:

<dummyxml>
  <foo_elem>foo</foo_elem>
  <bar_elem></bar_elem>
</dummyxml>

So kann man diese mittels J4X so generieren (ein Weg von vielen):

var xmldoc = new XML();
xmldoc = <dummyxml></dummyxml>;
 
xmldoc.foo_elem = "foo";
xmldoc.bar_elem = "";

Dieses XML kann man im Orchestrator ganz einfach anzeigen mittels

System.log("my XML Doc:\n" + xmldoc);

ergibt

2012-03-24 21:44:37.030] [I] my XML Doc:
<dummyxml>
  <foo_elem>foo</foo_elem>
  <bar_elem/>
</dummyxml>

Nun noch flink den Parameter ausgelesen und zur Sicherheit ausgegeben

var foo = xmldoc.foo_elem;
System.log("Value of foo is '" + foo + "'");

ergibt wie erwartet

[2012-03-24 21:48:48.498] [I] Value of foo is 'foo';

Ist doch alles fein - warum die Aufregung? Meine Folgeworkflow mag String Parameter und das ist das Problem! Durch die automatische J4X Konvertierung sehe ich im Log String aber die Variable ist vom Typ XML.

Mein Test:

var foo = xmldoc.foo_elem;
System.log("Value of foo is '" + foo + "'; Type is " + typeof foo);

ergibt

[2012-03-24 21:54:54.459] [I] Value of foo is 'foo'; Type is xml

Und nicht wie erwartet String. Da ich mit J4X nicht vertraut bin, habe ich verschiedene Möglichkeiten getestet. Mal in einer Tabelle zusammengefasst:

Wertabfrage Wert Result Typ
xmldoc.foo_elem foo xml
xmldoc.foo_elem.text() foo xml
xmldoc.foo_elem.data() foo xml
new String(xmldoc.foo_elem) foo object
new String(xmldoc.foo_elem.text().toString()) foo object
new String(xmldoc.foo_elem.toString()) foo object

Erwartet wurde von mir aber String. Auch Workflow 3 erwartet String Parameter.

Da meine XML Dateien sehr einfach aufgebaut sind und auch nicht so groß, habe ich dann mittels DOM meine “String” Werte bekommen…

var document = XMLManager.fromString(xmldoc.toString()).getDocumentElement();
var foo = document.getElementsByTagName("foo_elem").item(0).textContent;

ergibt dann

[2012-03-24 22:35:44.635] [I] Value of foo is 'foo'; Type is string

Damit gehts.

Hat jemand eine bessere Idee?

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International