Come migrare config.xml di Weblogic per più macchine?

Question

il nostro team di sviluppo si sviluppa un'applicazione J2EE che gira su Weblogic 10.3. Ogni macchina di sviluppo gestisce la propria copia di application server Weblogic 10.3. dominio Weblogic del ambiente di sviluppo è stato inizialmente creato su una macchina e poi copiati su tutte le macchine che utilizzano lo strumento di configurazione di Weblogic (bea10 / wlserver_10.3 / common / bin / config.cmd).

Ogni macchina di sviluppo ha la propria copia di Config.xml. Tutte le frasi d'accesso (quelle per JDBC origini dati, ecc) in questo file sono criptati e la crittografia a quanto pare utilizza un seme diverso su ogni macchina in quanto la stessa password ha diverse forme crittografati su macchine diverse.

Il problema è che ogni tanto un po 'config.xml ha bisogno di aggiornamento (per esempio quando viene aggiunto un nuovo EJB) e devono essere applicate su tutte le macchine gli aggiornamenti. Come dobbiamo fare per fare questo? Se abbiamo appena messo il file in CVS e aggiornare le altre macchine da lì le password criptate su ogni macchina otterrebbe sovrascritto. Ciò si traduce in brutte paddingexceptions quando il server tenta di decifrare la passphrase originariamente criptati su un'altra macchina.

C'è un compito formica (non sono riuscito a trovare uno) o un meccanismo simile che si sarebbe preso cura di fondere correttamente le variazioni di config.xml senza sovrascrivere le password criptate? O è possibile specificare in qualche modo le frasi d'accesso in chiaro e cifrare al primo avvio (ho un debole ricordo che questo era possibile nelle versioni precedenti ma non in 10.3).

Come fanno i team di sviluppo che lavorano su Weblogic gestire questa situazione?

BR,

Marko

Answer 1

  

[...] Ogni macchina di sviluppo ha il suo   copia di Config.xml. Tutti i   passphrase (quelli per JDBC   origini dati, ecc) in questo file sono   criptato ...

Sì, WebLogic Server crittografa tutte le password in chiaro memorizzate nel file XML di configurazione del dominio (s). Questo per impedire l'accesso alle informazioni sensibili. Quando le password vengono immesse utilizzando la console di amministrazione o di scripting strumenti, sarà automaticamente criptati prima di essere memorizzati nei file XML di configurazione (s).

  

... e la crittografia   a quanto pare utilizza un seme diverso su   ogni macchina in quanto la stessa password   ha diverse forme crittografati   diverse macchine.

Il crittografare utility (dalle Oracle WebLogic utilità Java Server), la documentazione dice:

  

Il weblogic.security.Encrypt di crittografare le stringhe in chiaro per l'utilizzo con WebLogic Server. L'utilità utilizza il servizio di crittografia della directory corrente, oppure il servizio di crittografia per una directory principale del dominio WebLogic Server specificato.

     

Nota: Una stringa crittografata deve essere stato crittografato dal servizio di crittografia nel dominio di WebLogic Server in cui verrà utilizzato. In caso contrario, il server non sarà in grado di decriptare la stringa.

Questa non è menzionato nella documentazione, ma, per quanto ne so, Weblogic utilizza file di password sale del dominio (SerializedSystemIni.dat) per cifrare la stringa di testo in chiaro.

  

[...] Se abbiamo appena messo il file in CVS e aggiornare le altre macchine da lì le password criptate su ogni macchina otterrebbe sovrascritto.

Si può scegliere di usare password in chiaro nel config.xml memorizzato nel VCS (se questo non è un problema). In realtà, prima di WebLogic Server 9.0, le password otterrebbe crittografati durante il riavvio successivo. A partire da WebLogic Server 9.0, utilizzando password in chiaro nei file di configurazione è "pienamente" supportato solo per il dominio dello sviluppo e Weblogic non si ri-crittografare le password. In entrambi i casi, ciò permetterebbe alle persone di controllare il file di configurazione, senza problemi.

  

C'è un compito formica (non sono riuscito a trovare uno) o un meccanismo simile che si sarebbe preso cura di fondere correttamente le variazioni di config.xml senza sovrascrivere le password criptate? ...

Non sono sicuro che questo risponde direttamente alla tua domanda, ma Oracle WebLogic Server fornisce noreferrer attività Ant per la maggior parte (se non tutti) i suoi Utilità Java. Forse troverete qualcosa di utile lì (controllare il Configurazione di un server di dominio WebLogic Utilizzando la wlconfig Ant Task )

  

O è possibile specificare in qualche modo le frasi d'accesso in chiaro e cifrare al primo avvio (ho un debole ricordo che questo era possibile nelle versioni precedenti ma non in 10.3).

Come ho scritto in precedenza, questo è stato il comportamento di "default" prima di Weblogic Server 9.0. Non so se è possibile forzare questo comportamento per le versioni successive. Naturalmente, si può sempre usare formica e crittografare per farlo, ma, onestamente, se si consente alle persone di vedere password in chiaro una volta, non vedo proprio il punto di cifrandoli dopo i fatti.

Answer 2

Vorrei usare qualcosa come mercuriali o git, e utilizzare la funzionalità di esportazione / importazione, in modo che i cambiamenti vengono spostati nelle diff, non in file completi.

istruzioni brevi

Bene, se si è bloccato con CVS (mi dispiace, condivido il vostro dolore in una certa misura), si potrebbe prendere in considerazione la creazione di un repository CVS di diff. Per esempio. quando viene effettuata una nuova versione del file di configurazione, il nuovo file viene diffed al vecchio file e il file diff viene aggiunto il repo, altri host checkout dal CVS e patch del file di configurazione.

E 'un hack, ma dovrebbe funzionare.

Answer 3

Personalmente mi piacerebbe guardare in WLST fare gli aggiornamenti del dominio di massa. E 'molto semplice, anche se non si ha esperienza con Python o WLST

1. attivare la registrazione per un dominio (interfaccia di amministrazione via web)
2. fare le modifiche in un dominio (interfaccia web di amministrazione)
3. attivare le modifiche (interfaccia di amministrazione via web)
4. si dovrebbe ottenere uno script python nella cartella di dominio predefinito
5. per ogni ambiente
   1. connettersi al server di amministrazione con WLST
   2. applicare lo script
   3. dominio riavvio o server gestiti, se necessario

Al momento l'azienda per cui lavoro fa una cosa simile a ciò che si descrive - hack in giro con i file di dominio WebLogic e quindi distribuire gli stessi file con piccole modifiche a tutti i nostri ambienti. Nel corso degli anni abbiamo finito con una confusione assoluta. Non è solo la strada da percorrere.

Answer 4

L'abbiamo fatto usando WLST. Usiamo una sorta di semplice dichiarativa "modello di dominio" in python che è piuttosto astratta (vale a dire che non specifica la configurazione dei diversi server di un cluster, nei nostri ambienti tutti i nodi devono essere identici). Questo modello è abbastanza breve (2-3 pagine per grandi applicazioni che hanno 30 + pool di connessioni, un gruppo di JMS roba e alcuni provider JMS stranieri). Dopo di che, abbiamo 2 script: prima crea un dominio vuoto nel enviornment bersaglio, il secondo si applica il modello di dominio. Per raccogliere le modifiche che gli sviluppatori fanno nell'ambiente "master" abbiamo uno script che passa attraverso la configurazione del dominio e fornisce il file del modello. Utilizzando un diff su quei file di modello possiamo vedere quello che è stato modifiche.

Questo appare come un quadro pesante, ma in realtà fa risparmiare un sacco di tempo in cui dobbiamo gestire gli ambienti di sviluppo, test, staging e produzione per oltre 100 applicazioni.

Per i casi più piccole semplicemente copiando i file e usando lo stesso SerializedSystemIni.dat dovrebbe fare. Basta fare in modo che il nome di dominio rimane lo stesso, regolare le indirizzi / porte. Se si desidera utilizzare SerializedSystemInit.dat diversa, è piuttosto facile da fare anche questo, sulla base di questo codice ( http://gustlik.wordpress.com/2008/08/06/decryption-of-configuration-passwords-in-weblogic/ ) E ' abbastanza facile da scrivere un programma di utilità che decodificare la password con SerializedSystemIni.dat originali e codificare con uno nuovo. Questo dovrebbe fare il trucco.