La version 12.2.1.3 de Oracle WebLogic Server introduit une nouvelle fonctionnalité qui permet de modifier à chaud la configuration d’un serveur via un simple fichier XML : Temporary Configuration Overriding.
L’objectif est simple : Modifier la configuration d’un ou plusieurs serveurs Weblogic du domaine à partir d’informations contenues dans un simple fichier xml. Ce fichier doit être placé dans le sous-répertoire optconfig du domaine. Ce répertoire n’existe pas par défaut, il faut le créer. Ce fichier XML constitue une surcharge du fichier config.xml du domaine.
Outre le côté assez rapide de la mise en oeuvre, cette fonctionnalité présente l’avantage de limiter dans le temps la modification qui est apportée aux serveurs. En effet, il est obligatoire d’indiquer dans le fichier une date et une heure d’expiration au-delà desquelles la modification sera annulée pour revenir à la configuration originale. Ceci peut être très pratique par exemple pour activer temporairement des flags de debug sur un serveur comme le montre le fichier ci-dessous :
[pastacode lang= »markup » manual= »%3C%3Fxml%20version%3D’1.0’%20encoding%3D’UTF-8’%3F%3E%0A%3Cdom%3Adomain%0A%20xmlns%3Adom%3D%22http%3A%2F%2Fxmlns.oracle.com%2Fweblogic%2Fdomain%22%0A%20xmlns%3Af%3D%22http%3A%2F%2Fxmlns.oracle.com%2Fweblogic%2Fdomain-fragment%22%0A%20xmlns%3As%3D%22http%3A%2F%2Fxmlns.oracle.com%2Fweblogic%2Fsituational-config%22%20%3E%0A%20%20%20%3Cs%3Aexpiration%3E%202019-05-22T19%3A24-08%3A00%20%3C%2Fs%3Aexpiration%3E%0A%20%20%3Cdom%3Aname%3Ewls12213Domain%3C%2Fdom%3Aname%3E%0A%20%20%3Cdom%3Aserver%3E%0A%20%20%20%20%3Cdom%3Aname%3Ems2%3C%2Fdom%3Aname%3E%0A%09%3Cdom%3Aserver-log%3E%0A%09%09%3Cdom%3Astdout-severity%20f%3Acombine-mode%3D%22replace%22%3EDebug%3C%2Fdom%3Astdout-severity%3E%0A%09%3C%2Fdom%3Aserver-log%3E%0A%20%20%20%20%3Cdom%3Aserver-debug%3E%0A%09%09%20%20%20%20%20%20%3Cdom%3Adebug-http%20f%3Acombine-mode%3D%22replace%22%3Etrue%3C%2Fdom%3Adebug-http%3E%0A%20%20%20%20%20%20%3Cdom%3Aclass-loader%20f%3Acombine-mode%3D%22replace%22%3Efalse%3C%2Fdom%3Aclass-loader%3E%0A%20%20%20%20%3C%2Fdom%3Aserver-debug%3E%0A%20%20%3C%2Fdom%3Aserver%3E%0A%20%20%3C%2Fdom%3Adomain%3E » message= »Exemple de fichier de configuration » highlight= » » provider= »manual »/]
Les détails du fonctionnement de cette nouveauté sont disponible dans cette documentation.
Voilà pour le fonctionnement, quelques remarques maintenant.
Le répertoire optconfig est scruté régulièrement par les serveurs, toutes les 5 secondes par défaut. Le délai entre 2 lectures du répertoire n’est modifiable que par WLST :
[pastacode lang= »python » manual= »connect(…)%0Aedit()%0AstartEdit()%0AdomainConfig()%0Aas%3Dcmo.lookupServer(‘AdminServer’)%0Aas.setSitConfigPollingInterval(30)%20%0Asave()%0Aactivate()%0Adisconnect() » message= »Modification du délai entre 2 lectures du répertoire optconfig » highlight= » » provider= »manual »/]
Cette fonctionnalité est active par défaut et il n’est pas possible de la désactiver.
Évidement, seuls les paramètres dynamiques de la configuration, c’est à dire ne nécessitant pas de redémarrage sont pris en compte par cette fonctionnalité.
C’est la classe weblogic.management.provider.internal.situationalconfig.SituationalConfigManagerImpl qui est en charge de cette fonctionnalité.
On est en droit de se demander si cette nouvelle fonctionnalité constitue une faille de sécurité ou non. En effet, toute modification à chaud de la configuration des serveurs effectuées avec les autres outils (console ou WLST par exemple) nécessitent de s’authentifier. Pas celle-là. Oracle a été sollicité sur ce point et a répondu officiellement que cette fonctionnalité ne constitue en rien une faille de sécurité.
Conclusion
Ca sent la fonctionnalité développée pour les environnements cloud !
Elle est intéressante par exemple dans le cadre du support quand il est nécessaire d’activer temporairement certains paramètres comme les flags de debug. Je trouve dommage qu’elle soit active par défaut et qu’on ne puisse pas la désactiver.
Son mode de fonctionnement justifie encore un peu plus la nécessité d’avoir un utilisateur dédié pour lancer les instances WebLogic et que lui-seul puisse avoir un droit en écriture sur le répertoire du domaine et ses sous-répertoires.