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

Les corrections du référentiel Oak sont fournis par les sets de correction Oak Cumulative Fix Packs (OCFP). Ils sont intégralement pris en charge, à l'instar des modules correctifs cumulés standards. 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 génération de diagnostic fournit le même niveau d’assurance qualité qu’un correctif urgent, elle ne fournit pas le même niveau d’assurance qualité qu’un pack cumulatif de correctifs, un pack service ou la publication d'un produit. Tous les correctifs officiels Oak seront publiés en tant qu'OCFP, qui inclut un service d'assistance complet.

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 Oak 1.4.8+ CFP, nous vous recommandons de suivre la procédure de pré-déploiement ci-dessous pour préparer l'index correspondant lors d'une fenêtre de maintenance, l'indexation nécessitant beaucoup de 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 construire des index, le paramètre Oak -Dupdate.limit doit avoir une valeur plus élevée, par exemple 200000. Cela nécessite également assez de 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. Consultez cet url :
   /system/console/jmx/org.apache.jackrabbit.oak%3Aname%3Dasync%2Ctype%3DPropertyIndexAsyncReindex
4. Faites recours à startPropertyIndexAsyncReindex() pour commencer l'indexation.
5. 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
   .
6. 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).
7. 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

8. 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 de la manière décrite ci-dessous, afin de garantir une récupération des ordures de révision ultérieure :

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

Le mappage d’un groupe externe vers 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 internes.

Le lien vers un fournisseur IDP est effectué 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 de 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 version d'AEM 6.2
• Page produit AEM
• Documentation AEM 6.2
• Abonnez-vous à Mises à jour de produits prioritaires Adobe.