LinkedIn emplea cookies para mejorar la funcionalidad y el rendimiento de nuestro sitio web, así como para ofrecer publicidad relevante. Si continúas navegando por ese sitio web, aceptas el uso de cookies. Consulta nuestras Condiciones de uso y nuestra Política de privacidad para más información.
LinkedIn emplea cookies para mejorar la funcionalidad y el rendimiento de nuestro sitio web, así como para ofrecer publicidad relevante. Si continúas navegando por ese sitio web, aceptas el uso de cookies. Consulta nuestra Política de privacidad y nuestras Condiciones de uso para más información.
Targets AEM admins and developers and can be applied to all AEM versions
I will start us off with an introduction to Service Packs and Cumulative Fix Packs Briefly mention Security Bulletins Provide general information about Package Share Vanshika will Introduce our new AEM tools Jaideep will talk about how to set up a new AEM project using Adobe Maven Archetype or Lazybones We will conclude with a Q&A session
Jumping straight into AEM patches Adobe releases two types of fix packs : Service Packs and Cumulative Fix Packs SPs include both improvements and bug fixes CFPs consist of fixes Both fix packs are cumulative – the higher patch version includes the lower patch versions In terms of naming convention, as of AEM 6.3, we specify SP and CFP within the product version as shown on the slide
This is a diagram representing the maintenance release roadmap Starting with 6.4 SPs are released quarterly And CFPs are released after 4 SPs have been released Moving on to 6.3 – there is a bit of a change SP 3 , which is due to release September 12th, will be the last service pack for 6.3 And CFPs will continue to be released every 8 weeks In terms of 6.2 Not much happening as there are no SP released And CFPs are released every 8 weeks Last, but not least, for 6.1 CFP17 is scheduled for October and CFP18 is scheduled for January CFP 18 is the last maintenance release for 6.1 As it has reached end of core support as of May 31st of this year (2018) The end of extended support is scheduled for May 31st of 2020 Contact the sales team to purchase an extended support maintenance contract as we do not provide support for end of life versions Also, if using 6.1 or lower, we highly advise to upgrade
The Security Bulletin is how Adobe releases important information about security vulnerabilities that could affect Adobe products Use the link on the slide to subscribe to receive email notifications for security updates Currently, the most recent security board was released on August 14th regarding cross-site scripting vulnerabilities that affect all AEM versions Do review the security board and take the corrective actions provided by Adobe
Package Share is how Adobe provides patches and there are two ways to access it The first way is to click the link on the slide, this is a direct link to Package Share And the second way is from within an AEM instance Within the CRX/DE admin console, click the package share icon in the top menu Link or CRX/DE you will be prompt with a Sign In form If you have an Adobe ID and proper permissions to access Package Share you would log in and be able to access the packages available For new users: An Adobe ID must be created and validated through email verification And an email should be sent to email@example.com requesting access to Package Share
Lastly regarding package share, when viewing a package, there is an Assets tab which allows you to download the patch directly onto your filesystem
I will now cover some some best practices when installing patches Always take a full backup before installing patches Do not uninstall patches as oftentimes there will be unintended side effects and issues, instead, if the patch has to be reverted, perform a rollback or restore While installing patches, check that all dependencies are met, when the package is uploaded, if dependencies are missing you will see red text regarding dependencies Do not install patches using /crx-quickstart/install filesystem directory as there is a higher chance that the package will be uninstalled inadvertently During package install, monitor log files during to confirm when the patch has completely installed There will be a lot of UNREGISTERING and REGISTERED logs during patch install These logs will typically stop and this is when we can safely assume the patch has completely installed
Moving on to working with Packages
By default, permissions to work with packages are not provided The /etc/packages path requires full permissions And the same permissions need to be applied to the package content nodes We suggest to apply permissions to groups and not directly to users
Package actions are also available in CURL command I have listed a couple of them on this slide For more information, review the listed resource
Packages are configurable One such configuration is Access Control handling This determines how the package ACs are handled on install Ignore ignores the packaged ACs – this also is the default value Overwrite applies the ACs provided in the package and also removes existing ACs Merge adds ACs from the package at the end of the list MergePreserve merges the ACs and preserves the order Clear - deletes all Acs This is all in terms of package content nodes
I just covered that packages can modify access controls which can be the difference between a working and non-working AEM instance We suggest to validate package content before installing AEM 6.4 now comes with a package validation tool built in This tool allows us to validate the package content to see if it modifies overlaid files and/or access controls To access the tool, in Package manager, click More and Validate
Validate Package popup will appear
The Package validation tool has three validation options: The OSGi Package Imports option: Confirms that OSGi bundle dependencies are satisfied by the AEM instance The Overlays option: Checks if the package contains any files that are already overlaid in the destination AEM instance And the ACLs option: Reviews which permissions are being modified, how they will be handled such as merge or overwrite, and if the current permissions will be impacted
For more details, review the resource listed – the documentation provides details on what each check returns and how to resolve each conflict
Packages are not installing This is commonly caused by PauseInstallation nodes There should be no nodes under “/system/sling/installer/jcr/pauseInstallation” before or after package installation Constraint Violation Exception thrown while installing a package Check the path stated in the error and correct the node primary type (protected node) No Packages Visible in AEM Package Manager This issue mainly occurs when one of the packages has a special character in the package name Navigate to /crx/packmgr/list.jsp Find the offending package and delete it from /etc/packages/ directory using CRX/DE When uploading an asset package it is observed that a high number of workflows have been triggered To solve this, deactivate the Workflow Launcher component in the OSGi components admin console This will ensure that no workflows start when uploading the asset package Be sure to turn the workflow launcher on after asset package upload is completed
Now lets talk about AEM Tools
Some of you may be familiar with the AEM Stuff blog which had various tools to help verify multiple aspects of AEM instances Adobe has been granted permission to internalize and maintain the source code from AEM Stuff Existing tools include: Bundle Version Checker tool designed to compare OSGi bundle versions across instances This tool combines the AEM Stuff’s OSGi Sanity Checks into a single tool OSGi Configuration Diff tool designed to compare OSGi configurations across instances And Node Diff tool which compares query results between instances Some of the tool names are slightly different from AEM Stuff
TRANSITION TO VANSHIKA : I will now handoff to Vanshika who will be introducing our new AEM Tools
Hi , Myself Vanshika Agarwal , Working as a software engineer for AEM sustenance team Adobe India. These three utility tools were newly developed and added on helpx documention for the customers to troubleshoot OOTB instances,. These tools will help validate issues with configurations, node deletions and component changes on aem instances. All the tools are accessible at the url mentioned below
Coming to the tool CPC This tool basically compares version of packages between aem instances . This will help to validate packages added/deleted/changed after upgrading an instance . It will help troubleshoot issues related to package versions/ installations.
Demo for this tool:-
This tool analyses the activity logs generated after a package is installed on aem instance. and helps to validate nodes that gets deleted after a package installation. It helps to know what all nodes got deleted and that will help to validate any useful nodes that got deleted as part of custom package installation . There might be nodes in OOTB which gets removed as part of installation. This will help to look into such issues . Demo for the tool :-
This tools helps to compare OSGi components b/w aem instances. It helps to troubleshoot issues related to changes in component as part of OSGi bundles version bumps which otherwise might be overlooked. Demo for the tool ;-
In short, the tools added on helpx will help to validate issues in aem instances and come to a concrete conclusion about the root cause which otherwise makes it difficult and time consuming as well.
Now I pass on to Jaideep who will be taking you through Maven Archtype/Lazybones concept.
TRANSITION TO JAIDEEP:
In a Terminal window, run these two commands: curl -s "https://get.sdkman.io" | bash source ~/.sdkman/bin/sdkman-init.sh Once sdkman is installed, you can use it to install lazybones with the following command: sdk install lazybones
Windows :- https://bintray.com/pledbrook/lazybones-templates/lazybones#files