Notes de mise à jour : module correctif cumulé Oak AEM 6.2

Les correctifs du référentiel Oak sont fournis dans les jeux de correctifs Oak Cumulative Fix Packs (OCFP). Ils sont intégralement pris en charge, à l’instar des jeux de correctifs cumulés standard. L’ensemble de correctifs cumulatif Oak est autonome (pas de dépendances). Ne vous souciez pas de la recherche/résolution des dépendances.

Installez le dernier groupe de correctifs cumulatifs pour votre version d’AEM afin de maintenir votre déploiement à jour.

Si nécessaire, une version de diagnostic sur le dernier plan de travail peut être rendue disponible pour la validation avant la disponibilité officielle du prochain OCFP. La condition préalable est d’avoir le dernier OCFP en cours d’exécution. Une version de diagnostic fournit le même niveau d’assurance qualité qu’un correctif ; par conséquent elle ne fournit pas le même niveau d’assurance qualité qu’un pack cumulatif de correctifs, un service pack ou la version de sortie d’un produit. Tous les correctifs Oak officiels sont publiés en tant qu’OCFP, fourni avec la prise en charge intégrale.

Pour plus d’informations sur CFP et d’autres types de sorties, voir Maintenance Release Vehicle.

Le pack de correction cumulée Oak 1.4.8 (et au-delà) contient des définitions d’index. Avant de déployer le CFP Oak 1.4.8+, il est recommandéde suivrela procédure de prédéploiement ci-dessous, afin de préparer l’index correspondant lors d’une période de maintenance, car l’indexation peut nécessiter de nombreuses ressources. C’est une procédure unique (pas besoin de l’appliquer à nouveau si vous l’avez déjà fait lors de l’application d’un précédent Oak CFP ayant une version >= 1.4.8).

Important : Pour la création des index, la limite du paramètre Oak doit être définie à une valeur supérieure, par exemple 200 000. Cela nécessite également suffisamment de segments de mémoire (tas). 

1. Installez le pack de définition d’index NPR-14064, qui contient les définitions d’index avec réindexation asynchrone (il ne doit pas générer tout de suite de nouvel index).
2. Pour Mongo : arrêtez toutes les instances AEM sauf 1.
3. Accédez à cette URL :
   
4. /system/console/jmx/org.apache.jackrabbit.oak%3Aname%3Dasync%2Ctype%3DPropertyIndexAsyncReindex
   
5. Invoquez startPropertyIndexAsyncReindex() pour commencer l’indexation.
6. Surveillez les fichiers journal à l’affût de ce message :
   22.02.2017 11:34:32.602 *INFO* [aysnc-index-update-async-reindex] org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate [async-reindex] Reindexing completed for indices: [/oak:index/externalId*(0), /oak:index/externalPrincipalNames*(0), /oak:index/repMembers*(51)] in 1.085 s
   
7. Vérifiez que les indices ont été créés correctement en vérifiant les mises à jour des propriétés suivantes :
   • reindexCount=1
   • Async="async-reindex" sera supprimé (l’index bascule vers l’indexation synchrone).
8. Faites cette vérification pour ces trois indices (vous pouvez également vérifier que cette requête n’apporte aucun résultat : //element(*, oak:QueryIndexDefinition)[@async = "async-reindex"]).
   • /oak:index/repMembers
   • /oak:index/externalPrincipalNames

   • /oak:index/externalId

9. Remarque : la génération d’index peut être arrêtée.  Allez à :
   /system/console/jmx/org.apache.jackrabbit.oak%3Aname%3Dasync%2Ctype%3DIndexStats

Au cours du processus de réindexation asynchrone, un point de contrôle de référentiel est créé. Une fois la tâche d’indexation terminée, elle doit être libérée comme décrit ci-dessous, afin de garantir le bon fonctionnement du nettoyage de la mémoire par la suite :

1. Tout d’abord, ouvrez le CheckpointManager MBean :
   MongoMK -
   /system/console/jmx/org.apache.jackrabbit.oak%3Aname%3DDocument+node+store+
   checkpoint+management%2Ctype%3DCheckpointManger
2. TarMK -
   /system/console/jmx/org.apache.jackrabbit.oak%3Aname%3DSegment+node+store+
   checkpoint+management%2Ctype%3DCheckpointManger
3. Appeler l’opération listCheckpoints(),
4. Recherchez la ligne de point de contrôle avec la propriété "name=async-reindex",
5. Copiez la valeur de son identifiant dans le presse-papier
   sur MongoMK, cela ressemble à ceci : r1234567aaaa-0-1
   sur TarMK, cela ressemblera à ceci : 6eac07d0-fe27-4d16-82f8-6d5da4cefd67.
6. Ensuite, ouvrez l’opération releaseCheckpoint (),
7. Collez l’ID copié en tant que p1 et cliquez sur « Invoquer ».
8. Cette étape libérera le point de contrôle.
   

Oak 1.4.7 introduit une modification du comportement de synchronisation des appartenances à des groupes externes (par ex., de LDAP) :

Le mappage d’un groupe externe à un groupe local existant n’est plus possible. Le groupe local doit être créé par le processus de synchronisation IDP et ne peut plus être partagé avec d’autres IDP externes.

Cela est nécessaire pour garantir les frontières entre les appartenances à des groupes établis localement et les appartenances externes, ainsi que pour garantir les frontières entre plusieurs IDP.

Le lien vers un IDP est établi par le biais de la propriété « rep: externalId » entièrement protégée sur les groupes et les utilisateurs. Pour plus de détails et des solutions de migration, consultez : https://issues.apache.org/jira/browse/OAK-4397.

• Pour les versions antérieures à Oak 1.4.5, en raison d’un problème connu (OAK-4538, corrigé dans la version Oak 1.4.5), il peut arriver qu’AEM ne puisse pas être arrêté correctement. Dans ce cas, la fin du processus jvm doit être forcée.
• Si vous utilisez l’intégration LDAP d’Oak, après avoir appliqué le dernier correctif Oak, la synchronisation LDAP des utilisateurs ne peut plus fonctionner.  Pour remédier à ce problème, accédez à /system/console/configMgr et mettez à jour la propriété « Fournisseur d’identité LDAP » de votre configuration « Attributs personnalisés ».  Mettez à jour la propriété avec tous les attributs LDAP utilisés dans la configuration de synchronisation.  Par exemple, ces propriétés peuvent être : cn, sn, givenName, mail.

• Notes de mise à jour d’AEM 6.2
• Page produit AEM
• Documentation AEM 6.2
• Abonnez-vous à Mises à jour de produits prioritaires Adobe.