Versionshinweise: Kumulatives Oak-Fixpack für AEM 6.2

Fehlerbehebungen für das OAK-Repository werden über Oak Cumulative Fix Packs (OCFP) bereitgestellt, die voll unterstützt sind, ähnlich wie die standardmäßigen Cumulative Fix Packs. Ein Oak Cumulative Fix Pack ist unabhängig (keine Abhängigkeiten). Sie müssen sich nicht über das Suchen/Auflösen von Abhängigkeiten kümmern.

Installieren Sie das neueste kumulative Fixpack für Ihre AEM-Version, um Ihre Bereitstellung aktualisiert zu halten.

Bei Bedarf kann ein Diagnose-Build auf dem neuesten OCFP vor der offiziellen Verfügbarkeit des nächsten OCFP zu Validierungszwecken zur Verfügung gestellt werden. Voraussetzung ist, dass Sie den letzten OCFP ausführen. Ein Diagnose-Build bietet nur die gleiche Qualitätssicherung wie ein Hotfix, daher bietet es nicht die gleiche Qualitätssicherung wie ein kumulatives Fixpack, Service Pack oder Produkt-Release. Alle offiziellen OAK-Fehlerbehebungen werden über Oak Cumulative Fix Packs (OCFP) bereitgestellt, die voll unterstützt sind.

Weitere Informationen zu CFP und anderen Arten von Releases finden Sie unter Maintenance Release Vehicle.

Der Oak Cumulative Fix Pack 1.4.8. (und höhere Versionen) beinhaltet Indexdefinitionen. Vor der Implementierung von Oak 1.4.8+ CFP empfehlen wir,das unten stehendeVerfahren zur Vorbereitung des entsprechenden Index während eines Wartungsfensters durchzuführen, da die Indexierung sehr ressourcenintensiv sein kann. Dies ist ein einmaliges Verfahren (Sie brauchen es nicht erneut auszuführen, wenn Sie dies bereits bei der Anwendung einer vorherigen Oak CFP 1.4.8 oder höheren Version gemacht haben).

Wichtig: Zur Erstellung von Indizes sollte das Oak- Limit auf einen höheren Wert eingestellt werden, z. B. 200000. Dies erfordert auch einen ausreichend großen Heap. 

1. Installieren Sie das Indexdefinitionspaket NPR-14064, das Indexdefinitionen mit asynchronem neuen Index enthält (es sollte den neuen Index nicht sofort erstellen). ist.
2. Für Mongo: Beenden Sie alle AEM-Instanzen außer 1.
3. Besuchen Sie diese URL:
   
4. /system/console/jmx/org.apache.jackrabbit.oak%3Aname%3Dasync%2Ctype%3DPropertyIndexAsyncReindex
   
5. Rufen Sie startPropertyIndexAsyncReindex() auf, um mit der Indizierung zu beginnen.
6. Überwachen Sie die Protokolldateien für diese Protokollnachricht:
   22.02.2017 11:34:32.602 *INFO* [aysnc-index-update-async-reindex] org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate [async-reindex] Reindexing abgeschlossen für Indizes: [/oak:index/externalId*(0), /oak:index/externalPrincipalNames*(0), /oak:index/repMembers*(51)] in 1.085 s
   
7. Überprüfen Sie, ob die Indizes erfolgreich erstellt wurden, indem Sie die folgenden Eigenschaften überprüfen
   • reindexCount=1
   • async="async-reindex" würde gelöscht (damit wird der Index wieder auf synchrone Indizierung wechseln)
8. Dies sollte für diese drei Indizes überprüft werden (kann auch überprüfen, dass die folgende Abfrage keine Ergebnisse hat: //element(*, oak:QueryIndexDefinition)[@async = "async-reindex"]
   • /oak:index/repMembers
   • /oak:index/externalPrincipalNames

   • /oak:index/externalId

9. Hinweis: Der Indexaufbau kann gestoppt werden.  Gehen Sie zu dieser URL:
   /system/console/jmx/org.apache.jackrabbit.oak%3Aname%3Dasync%2Ctype%3DIndexStats

Während des Prozesses der asynchronen Neuindizierung wird ein Repository-Kontrollpunkt erstellt. Nachdem die Indizierungsaufgabe abgeschlossen wurde, muss sie wie unten beschrieben freigegeben werden, um später die reibungslose Revision-Speicherbereinigung zu ermöglichen:

1. Öffnen Sie zunächst den 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. Den „listCheckpoints()“-Vorgang aufrufen.
4. Die Kontrollpunktzeile mit der „name=async-reindex“-Eigenschaft suchen.
5. Kopieren Sie seinen ID-Wert in die Zwischenablage
   Auf MongoMK wird er so aussehen: r1234567aaaa-0-1
   Auf TarMK wird er so aussehen: 6eac07d0-fe27-4d16-82f8-6d5da4cefd67
6. Dann den „releaseCheckpoint()“-Vorgang öffnen.
7. Fügen Sie die kopierte ID als p1 ein und klicken Sie auf „Invoke“,
8. Dieser Schritt wird den Prüfpunkt freigeben.
   

Oak 1.4.7 führt eine Änderung im Synchronisierungsverhalten von externen Gruppenmitgliedschaften (z. B. von LDAP) ein:

Das Zuordnen einer externen Gruppe zu einer vorhandenen lokalen Gruppe ist nicht mehr möglich. Die lokale Gruppe muss durch den IDP-Synchronisierungsprozess erstellt werden und kann nicht mehr mit anderen externen IDPs geteilt werden.

Dies ist erforderlich, um die Grenzen zwischen lokal bestehenden und externen Gruppenmitgliedschaften zu gewährleisten und um die Grenzen zwischen mehreren IDPs zu gewährleisten.

Die Verbindung zu einem IDP erfolgt über die jetzt vollständig geschützte Eigenschaft „rep: externalId“ für Gruppen und Benutzer. Weitere Informationen und Migrationslösungen finden Sie unter: https://issues.apache.org/jira/browse/OAK-4397

• Bei Versionen vor Oak 1.4.5 kann es aufgrund eines bekannten Problems (OAK-4538, behandelt in Oak 1.4.5) passieren, dass AEM nicht kontrolliert gestoppt werden kann. In diesem Fall muss der Abbruch des JVM-Prozesses erzwungen werden.
• Wenn Sie Oak LDAP-Integration verwenden, funktioniert die LDAP-Benutzersynchronisation nach dem Anwenden des neuesten Oak-Hotfixes nicht mehr.  Um dies zu beheben, wechseln Sie zu /system/console/configMgr und aktualisieren Sie von Ihrer „LDAP Identity Provider“-Konfiguration die Eigenschaft „Benutzerdefinierte Attribute“.  Aktualisieren Sie die Eigenschaft mit allen LDAP-Attributen, die in der Synchronisierungskonfiguration verwendet werden.  Diese Eigenschaften können beispielsweise folgendermaßen lauten: cn, sn, givenName, mail

• Versionshinweise zu AEM 6.2
• AEM-Produktseite
• Dokumentation zu AEM 6.2
• Abonnieren Sie Adobe-Prioritäten-Produkt-Updates