Wie Weblogic config.xml auf mehrere Maschinen zu migrieren?

StackOverflow https://stackoverflow.com/questions/1503964

Frage

unser Entwicklungsteam entwickelt eine J2EE-Anwendung, die 10.3 auf Weblogic läuft. Jede Entwicklungsmaschine läuft seine eigene Kopie von Weblogic 10.3 Anwendungsserver. Die Weblogic Domain-Entwicklungsumgebung wurde zunächst auf einer Maschine erstellt und dann auf allen Maschinen kopiert mit Weblogic Konfigurationstool (bea10 / wlserver_10.3 / common / bin / config.cmd).

Jede Entwicklungsmaschine verfügt über eine eigene Kopie von config.xml. Alle Passwörter (die für JDBC-Datenquellen etc.) in dieser Datei werden verschlüsselt und die Verschlüsselung verwendet offenbar einen anderen Samen auf jeder Maschine, da das gleiche Passwort verschiedene verschlüsselte Formen auf verschiedene Maschinen hat.

Das Problem ist, dass jeder einmal in einer Weile config.xml aktualisiert muss (zum Beispiel, wenn ein neues EJB hinzugefügt wird) und die Updates müssen auf allen Maschinen angewandt werden. Wie sollen wir gehen über das tun dies? Wenn wir nur die Datei in CVS setzen und aktualisieren Sie die anderen Maschinen von dort die verschlüsselten Passwörter auf jeder Maschine erhalten würde überschrieben. Dies führt zu hässlichen paddingexceptions, wenn der Server der Passwörter zu entschlüsseln versucht, die ursprünglich auf einem anderen Rechner verschlüsselt.

Gibt es eine Ant-Task (ich nicht finden konnte) oder einem ähnlichen Mechanismus, der Pflege richtig Zusammenführung der Änderungen in config.xml nehmen würde die verschlüsselten Passwörter ohne zu überschreiben? Oder ist es möglich, irgendwie die Passwörter im Klartext angeben und verschlüsseln sie auf dem ersten Start (Ich habe eine schwache Erinnerung, dass dies in früheren Versionen möglich war, aber nicht in 10.3).

Wie arbeiten Entwicklungsteams auf Weblogic damit umgehen?

BR,

Marko

War es hilfreich?

Lösung

  

[...] Jede Entwicklungsmaschine verfügt über eine eigene   Kopie von config.xml. All die   Paßphrasen (die für JDBC   Datenquellen etc.) in dieser Datei sind   verschlüsselte ...

Ja, WebLogic Server verschlüsselt die alle Passwörter im Klartext in seiner Domäne XML-Konfigurationsdatei gespeichert (s). Dies ist für den Zugriff auf vertrauliche Informationen zu verhindern. Wenn Passwörter eingegeben Tools Administrationskonsole oder Scripting, wird es automatisch verschlüsselt, bevor sie in den XML-Konfigurationsdateien gespeichert werden (s).

  

... und die Verschlüsselung   anscheinend verwendet einen anderen Samen auf   jede Maschine seit dem gleichen Passwort   hat verschiedene verschlüsselte Formen auf   verschiedene Maschinen.

Über die verschlüsseln Dienstprogramm (von dem Oracle WebLogic Server Java Dienstprogramme), sagt die Dokumentation:

  

Die weblogic.security.Encrypt verschlüsselt unverschlüsselt Strings für die Verwendung mit WebLogic Server. Das Dienstprogramm verwendet den Verschlüsselungsdienst des aktuellen Verzeichnisses oder den Verschlüsselungsdienst für ein bestimmtes WebLogic Server-Domäne-Stammverzeichnis.

     

Hinweis: Eine verschlüsselte Zeichenfolge durch den Verschlüsselungsdienst in der WebLogic Server-Domäne verschlüsselt worden sein, wo sie verwendet werden soll. Wenn nicht, wird der Server nicht in der Lage sein, um die Zeichenfolge zu entschlüsseln.

Dies ist nicht in der Dokumentation erwähnt, aber AFAIK, verwendet Weblogic die Kennwort Salz Datei Domain (SerializedSystemIni.dat) für die klare Textzeichenfolge zu verschlüsseln.

  

[...] Wenn wir nur die Datei in CVS setzen und die anderen Maschinen aktualisieren von dort die verschlüsselten Passwörter auf jedem Rechner bekommen würden überschrieben.

Sie können wählen, Passwörter im Klartext in der config.xml in Ihrem VCS gespeichert verwenden (wenn dies kein Problem ist). Eigentlich vor dem WebLogic Server 9.0, würden die Passwörter beim anschließenden Neustart verschlüsselt erhalten. Ausgehend von WebLogic Server 9.0 unter Verwendung von Klartext-Passwörtern in den Konfigurationsdateien ist „voll“ für Entwicklung Domain nur dann unterstützt, und Weblogic wird die Passwörter nicht erneut verschlüsseln. In beiden Fällen würde diese Menschen erlauben, die Konfigurationsdatei ohne Probleme zu überprüfen.

  

Gibt es eine Ant-Task (ich nicht finden konnte) oder ein ähnlicher Mechanismus, die Pflege richtig Zusammenführung die Änderungen in config.xml nehmen würde die verschlüsselten Passwörter nicht überschreiben? ...

Ich bin nicht sicher, dies beantwortet Ihre Frage direkt, sondern Oracle WebLogic Server bietet Ant Aufgaben für die meisten (wenn nicht alle) seine Java Dienstprogramme. Vielleicht werden Sie etwas Nützliches dort (check out Konfigurieren eine WebLogic Server Domain Mit der wlconfig Ant-Task )

  

Oder ist es möglich, irgendwie die Passwörter im Klartext angeben und auf dem ersten Start zu verschlüsseln (ich eine schwache Erinnerung habe, dass dies in früheren Versionen möglich war, aber nicht in 10.3).

Wie ich oben schrieb, war dies das „default“ Verhalten vor dem Weblogic Server 9.0. Ich weiß nicht, wenn Sie dieses Verhalten für eine spätere Versionen erzwingen. Natürlich könnte man immer Ameise und zu verschlüsseln , es zu tun, aber, ehrlich gesagt, wenn man die Leute erlaubt einmal Passwörter im Klartext zu sehen, ich sehe sich nach den Fakten nicht wirklich den Punkt verschlüsselt wird.

Andere Tipps

würde ich so etwas wie Mercurial oder Git, verwenden und die Export / Import-Funktionalität nutzen, so dass die Änderungen in diffs bewegt werden, nicht in vollständigen Dateien.

Kurzanleitung

Nun, wenn Sie mit CVS stecken (Es tut mir leid, ich Ihren Schmerz zu einem gewissen Grad teilen), man bedenkt, könnte eine CVS-Repo von diffs zu schaffen. Z.B. wenn eine neue Version der Konfigurationsdatei vorgenommen wird, wird die neue Datei an die alte Datei diffed und die Diff-Datei wird auf dem Repo hinzugefügt, Check-out andere Rechner von cvs und die Config-Datei patchen.

Es ist ein Hack, aber sollte funktionieren.

Persönlich würde ich in WLST aussehen Massen Domain-Updates zu tun. Es ist wirklich einfach, auch wenn Sie keine Erfahrung mit Python oder WLST hat

  1. wiederum auf die Aufnahme für eine Domain (admin Web-Interface)
  2. Sie Ihre Änderungen auf einer Domain (admin Web-Interface)
  3. aktivieren Änderungen (admin Web-Interface)
  4. Sie sollten ein Python-Skript in Ihrem Standard-Domain-Ordner erhalten
  5. für jede Umgebung
    1. eine Verbindung zum Admin-Server mit WLST
    2. gelten Skript
    3. restart-Domäne oder verwalteten Server bei Bedarf

Derzeit ist das Unternehmen für die ich arbeite hat eine ähnliche Sache, was Sie beschreiben - Hack um mit WebLogic-Domäne-Dateien und dann die gleichen Dateien mit kleinen Optimierungen an alle Umgebungen einsetzen. Im Laufe der Jahre haben wir mit einem absoluten Chaos endete. Es ist einfach nicht der Weg zu gehen.

Wir haben es WLST verwenden. Wir verwenden eine Art von einfachen deklarativen „Domain-Modell“ in Python, die eher abstrakt ist (das heißt, es ist nicht festgelegt, die die Konfiguration von verschiedenen Servern in einem Cluster, in unserer Umgebung alle Knoten müssen identisch sein). Dieses Modell ist ziemlich kurz (2-3 Seiten für größte Anwendungen, die mehr als 30-Verbindungspools, ein Bündel von JMS Sachen und einige ausländische JMS-Provider haben). Danach haben wir zwei Skripte: erstellt zunächst eine leere Domäne in dem Ziel enviornment gilt die zweite das Domänenmodell. So sammeln Sie die Änderungen, die Entwickler in der „Master“ Umwelt tun haben wir ein Skript, das die Domänenkonfiguration geht durch und gibt die Modelldatei. Mit Hilfe eines diff auf diesen Modelldateien können wir sehen, welche Änderungen gegeben hat.

Das sieht wie ein Schwergewicht Rahmen, aber es spart wirklich viel Zeit, wenn wir die Entwicklung verwalten haben, Test, Staging und Produktionsumgebungen für über 100 Anwendungen.

Für kleinere Fälle nur die Dateien zu kopieren und unter Verwendung der gleichen SerializedSystemIni.dat tun sollten. So stellen Sie sicher, dass Ihre Domain-Namen gleich bleibt, stellen Sie die Adressen / Ports. Wenn Sie verschiedene SerializedSystemInit.dat verwenden möchten, ist es ziemlich einfach, dass auch zu tun, basierend auf diesem Code ( http://gustlik.wordpress.com/2008/08/06/decryption-of-configuration-passwords-in-weblogic/ ) ist es ganz einfach, ein Programm zu schreiben, das Passwort mit original SerializedSystemIni.dat und codieren mit einem neuen dekodieren. Dies sollte den Trick tun.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top