Upgrade Forgerock OpenDJ / DS

Deux scénarios de migration / upgrade seront étudiés :

  • upgrade "en place" d'un annuaire en version inférieure
  • ajout dans la topologie de réplication d'un annuaire en version supérieure.

Dans cet exemple, on va procéder à une migration de la version OpenDJ 3.5.1 à la version DS 6.5.

Environnement

L'environnement de test est le suivant :

3 serveurs : dj1.id-num.com, dj2.id-num.com, dj3.id-num.com.

Dans un premier temps, seuls les serveurs dj1 et dj2 sont installés, en mode multi-maîtres :

  • O.S. CentOS 7
  • Java jre 1.8
  • OpenDJ 3.5.1, avec 2 annuaires répliqués
  • Schéma de données custom avec attributs et classes d'objets spécifiques
  • Annuaire installé dans le répertoire /opt/opendj
  • Index créé sur le serveur dj2, sur l'attribut company

Script d'installation

L'installation sur les 2 serveurs a été faite avec le script suivant :

#!/bin/sh
#
# Installation Forgerock OpenDJ 3.5.1
#
#---------------------------------------
LDAPPORT=1389
PASS=ldapMaster
REPLADM=replicationAdmin
REPLPASS=replicationPassword
ADMINPORT=4445

HOST1=dj1.id-num.com
HOST2=dj2.id-num.com
HOST3=dj3.id-num.com

JAVAHOME=/opt/jre1.8.0_144
BASEDN="o=example"
BASEDIR=/opt/opendj
BINDIR=${BASESDIR}/bin
export JAVA_HOME=${JAVAHOME}
export OPENDJ_JAVA_HOME=${JAVAHOME}

${BASEDIR}/setup \
  --cli \
  --baseDN ${BASEDN} \
  --addBaseEntry \
  --ldapPort ${LDAPPORT} \
  --adminConnectorPort ${ADMINPORT} \
  --rootUserDN cn=Directory\ Manager \
  --rootUserPassword ${PASS} \
  --acceptLicense \
  --no-prompt \
  --noPropertiesFile

Script de réplication

La réplication est mise en place entre les serveurs dj1 et dj2, via la commande :

${BINDIR}/dsreplication enable \
--host1 ${HOST1} --port1 ${ADMINPORT} \
--bindDN1 "cn=Directory Manager" \
--bindPassword1 ${PASS} \
--replicationPort1 8989 \
--host2 ${HOST2} --port2 ${ADMINPORT} \
--bindDN2 "cn=Directory Manager" \
--bindPassword2 ${PASS} \
--replicationPort2 8989 \
--adminUID ${REPLADM} \
--adminPassword ${REPLPASS} \
--baseDN ${BASEDN}   \
--trustAll \
--no-prompt

On peut ensuite lancer l'init, pour tous les serveurs de la topologie :

${BINDIR}/dsreplication \
initialize-all \
--adminUID ${REPLADM} \
--adminPassword ${REPLPASS} \
--baseDN ${BASEDN}  \
--hostname $(hostname) \
--port ${ADMINPORT} \
--trustAll \
--no-prompt

On vérifie, avec l'option status :

${BINDIR}/dsreplication status \
--adminUID ${REPLADM} \
--adminPassword ${REPLPASS} \
--port ${ADMINPORT} \
--trustAll \
--no-prompt


Suffix DN            : Server              : Entries : Replication enabled : DS ID : RS ID : RS Port (1) : M.C. (2) : A.O.M.C. (3) : Security (4)
---------------------:---------------------:---------:---------------------:-------:-------:-------------:----------:--------------:-------------
cn=Directory Manager : dj2.id-num.com:4445 :         :                     :       :       :             :          :              : 
o=example            : dj1.id-num.com:4445 : 45      : true                : 14774 : 27576 : 8989        : 0        :              : false
o=example            : dj2.id-num.com:4445 :         : true                : 29513 : 481   : 8989        : 0        :              : false

Schéma spécifique

Le schéma est modifié avec l'ajout de 2 attributs et une classe d'objet :

dn: cn=schema
changetype: modify
add: attributeTypes
attributeTypes: ( partneruid-oid NAME 'partneruid' SUP name X-ORIGIN 'user Defined' )
attributeTypes: ( company-oid NAME 'company' SUP name X-ORIGIN 'user Defined' )
-
add: objectclasses
objectClasses: ( partnerperson-oid NAME 'partnerPerson' SUP inetorgperson MUST ( company ) MAY ( partneruid) )

Version OpenDJ / DS

On peut vérifier la version actuelle avec la commande :

/opt/opendj/bin/dsconfig --version
3.5.1 (revision 23b322a7502f029b6d3725212c162de36f038122)

Upgrade "en place"

Il faut tout d'abord vérifier la trajectoire de migration supportée.

Pour Directory Services 6.5, sorti fin 2018, la migration est supportée depuis la version OpenDJ 2.6 et supérieure.

La version de Java est également à vérifier : Java 8 ou 11 pour DS 6.5. Nous utilisons une version 8 ce qui convient donc.

Forgerock recommande de faire une sauvegarde physique du serveur à upgrader, en arrêtant l'annuaire et en faisant un backup de toute l'arborescence :

/opt/opendj/bin/stop-ds
tar zcf opendj-3.5.tgz opendj

Note : l'upgrade en place nécessite d'arrêter l'instance d'annuaire qui va être migrée.

Procédure de migration

La procédure est simple ; elle consiste essentiellement à :

  • extraire l'archive de la nouvelle version au dessus de l'ancienne
  • lancer la commande upgrade
  • vérifier et éventuellement adapter le paramétrage.

En détail :

cd /opt
unzip /path/to/Software/Forgerock/DS-6.6.0.zip
Archive:  DS-6.6.0.zip
   creating: opendj/legal-notices/third-party-licenses/
   creating: opendj/template/extlib/
   creating: opendj/template/setup-profiles/
.../...
   creating: opendj/template/setup-profiles/IDM/repo/6.5/
   creating: opendj/template/setup-profiles/IDM/repo/6.5/schema/
replace opendj/snmp/mib/rfc2605.txt? [y]es, [n]o, [A]ll, [N]one, [r]ename: y

Répondre "A" pour écraser / remplacer les anciennes versions de fichiers.

Lancer ensuite l'upgrade :

/opt/opendj/upgrade

>>>> OpenDJ Upgrade Utility

 * OpenDJ configuration will be upgraded from version
 3.5.1.23b322a7502f029b6d3725212c162de36f038122 to
 6.5.0.e2a029a050cc6908fd144a6ca9c687e01ad56ea3
 * OpenDJ data will be upgraded from version 6.0.0 to
 6.5.0.e2a029a050cc6908fd144a6ca9c687e01ad56ea3
 * See '/opt/opendj/logs/upgrade.log' for a detailed log of this operation

>>>> Preparing to upgrade

  OpenDJ 5.5.0 changed the indexing algorithm for JSON equality matching
  rules. All JSON based attribute indexes must be rebuilt which may take a
  long time. Do you want to rebuild the indexes automatically at the end of
  the upgrade? (yes/no) [no]: yes

  OpenDJ 6.5.0 changed the indexing algorithm for replication metadata. Its
  index must be rebuilt which may take a long time; without a working index
  every server start will take longer than normal. Do you want to rebuild the
  index automatically at the end of the upgrade? (yes/no) [no]: yes

  The upgrade is ready to proceed. Do you wish to continue? (yes/no) [yes]: 

>>>> Performing upgrade

  Adding configuration for schema providers...........................   100%     
  Adding configuration entry 'dn: cn=Core Schema,cn=Schema
  Providers,cn=config'................................................   100%     
  Removing top configuration entry for matching rules.................   100%     
  Removing configuration for syntaxes.................................   100%

.../...
  Replacing schema file '02-config.ldif'..............................   100%     
  Archiving concatenated schema.......................................   100%     
  Migrating replication changelog files to 6.5.0 format...............   100%     

>>>> OpenDJ configuration was successfully upgraded from version
3.5.1.23b322a7502f029b6d3725212c162de36f038122 to
6.5.0.e2a029a050cc6908fd144a6ca9c687e01ad56ea3


>>>> OpenDJ data was successfully upgraded from version 6.0.0 to
6.5.0.e2a029a050cc6908fd144a6ca9c687e01ad56ea3


>>>> Performing post upgrade tasks

  Rebuilding index(es) '[.caseIgnoreJsonQueryMatch,
  .caseExactJsonQueryMatch,
  ds-sync-hist.changeSequenceNumberOrderingMatch]' for base dn(s)
  '[o=example]'.......................................................   100%     

>>>> Post upgrade tasks complete

Les logs de la migration se trouvent dans $DSHOME/logs/upgrade.log.

On peut ensuite démarrer l'instance, via la commande bin/start-ds

L'annuaire est bien passé en version supérieure :

/opt/opendj/bin/dsconfig --version
6.5.0 (revision e2a029a050cc6908fd144a6ca9c687e01ad56ea3)

Post Upgrade

Si on part d'une version inférieure à la version 5.5, Forgerock rcommande de donner des privilèges spécifiques au compte de réplication. Les privilèges à ajouter sont les suivants :

  • bypass-lockdown
  • monitor-read
  • server-lockdown

Ceci peut être fait en LDIF. Dans notre cas, le compte utilisé est replicationAdmin :

dn: cn=replicationAdmin,cn=Administrators,cn=admin data
changetype: modify
add: ds-privilege-name
ds-privilege-name: bypass-lockdown
ds-privilege-name: monitor-read
ds-privilege-name: server-lockdown

La modification n'est à faire qu'une seule fois, les données étant répliquées.

L'upgrade peut ensuite être fait pour tous les serveurs de la topologie.

Ajout d'un nouveau serveur dans la topologie

Dans cette option, on va ajouter un nouveau serveur dans la topologie de réplication. Ceci peut donc être fait sans interruption de service.

Installation de DS 6.5

L'installation ds DS 6.5 se fait quasiment de la même manière que OpenDJ 3.5. Les seules différences : pas d'option --cli et l'option --hostname qui est obligatoire.

LDAPPORT=1389
PASS=ldapMaster
REPLADM=replicationAdmin
REPLPASS=replicationPassword
ADMINPORT=4445

HOST1=dj1.id-num.com
HOST2=dj2.id-num.com
HOST3=dj3.id-num.com

JAVAHOME=/opt/jre1.8.0_144
BASEDN="o=example"
BASEDIR=/opt/opendj
BINDIR=${BASESDIR}/bin
export JAVA_HOME=${JAVAHOME}
export OPENDJ_JAVA_HOME=${JAVAHOME}
/opt/opendj/setup \
  --hostname ${HOST3} \
  --baseDN ${BASEDN} \
  --addBaseEntry \
  --ldapPort ${LDAPPORT} \
  --adminConnectorPort ${ADMINPORT} \
  --rootUserDN cn=Directory\ Manager \
  --rootUserPassword ${PASS} \
  --acceptLicense

A ce stade, on a donc un annuaire en mode "standby". Nous pouvons l'inclure dans le domaine de réplication.

Ajout dans la réplication

Forgerock recommande d'utiliser la commande dsreplication du nouveau serveur pour l'ajouter dans une topologie de réplication existante.

La commande pour configurer une nouvelle réplication utilise maintenant l'option configure plutôt que enable :

${BINDIR}/dsreplication configure \
--host1 ${HOST1} --port1 4445 \
--bindDN1 "cn=Directory Manager" \
--bindPassword1 ${PASS} \
--replicationPort1 8989 \
--host2 ${HOST3} --port2 4445 \
--bindDN2 "cn=Directory Manager" \
--bindPassword2 ${PASS} \
--replicationPort2 8989 \
--adminUID ${REPLADM} \
--adminPassword ${REPLPASS} \
--baseDN ${BASEDN}   \
--trustAll \
--no-prompt

Initialisation de la réplication

On peut maintenant lancer l'initialisation de la réplication sur un seul serveur. Avec l'option initialize plutôt que initialize-all il faut préciser les serveurs sources et destinations :

${BINDIR}/dsreplication initialize \
--adminUID ${REPLADM} \
--adminPassword ${REPLPASS} \
--baseDN ${BASEDN}  \
--hostSource ${HOST1} \
--portSource ${ADMINPORT} \
--hostDestination ${HOST2} \
--portDestination ${ADMINPORT} \
--trustAll \
--no-prompt

On peut ensuite vérifier :

Suffix DN : Server              : Entries : Replication enabled : DS ID : RS ID : RS Port (1) : Delay (ms) : Security (2)
----------:---------------------:---------:---------------------:-------:-------:-------------:------------:-------------
o=example : dj1.id-num.com:4445 : 2025    : true                : 14774 : 27576 : 8989        : N/A        : false
o=example : dj2.id-num.com:4445 : 2025    : true                : 29513 : 481   : 8989        : 0          : false
o=example : dj3.id-num.com:4445 : 2025    : true                : 706   : 30128 : 8989        : 0          : false

Une fois que l'on a ajouté le nouveau serveur, il faut éventuellement paramétrer les éléments propres à l'instance (par exemple les index) qui sont positionnés via l'utilitaire dsconfig.

Adaptations et différences

On peut trouver quelques différences entre OpenDJ 3.5 et DS 6.5. A première vue, on peut citer :

  • les options des commandes dsconfig ou dsreplication
  • les fichiers de définition du schéma qui ont migré de DJ_HOME/config/schema à DS_HOME/db/schema

Synthèse

Nous avons vu que deux possibilités sont offertes pour faire un upgrade, de manière assez simple.

L'upgrade "en place" est intéressant pour récupérer toute la configuration spécifique de l'instance (paramètres positionnés par l'utilitaire dsconfig et qui ne sont pas répliqués). Dans ce cas, on garde le même serveur, et donc la même version d'O.S., de java, et d'adresse IP.

Cependant, ceci nécessite d'arrêter l'une des instances de la topologie de réplication.

L'ajout d'une nouvelle instance peut se justifier si on veut changer de version d'O.S. et/ou limiter au maximum les interruptions de service. Cela permet aussi d'adapter les scripts aux nouvelles versions d'outils (même si l'environnement de Test est fait pour cela). Par contre, ceci implique de reprendre le paramétrage de la configuration.

Méthode Avantages Inconvénients
Upgrade en place Pas de changement d'adresse IP
Récupération de la configuration
Arrêt de l'instance
Ajout d'une nouvelle instance Possibilité de monter de version d'O.S.
Pas d'arrêt de serveur
Possibilité de tester les outils
Nouveau serveur à provisionner
Nouvelle adresse IP à gérer
Pas de récupération du paramétrage spécifique

 

Catégorie