Understand how to properly manage an AEM Deployment
Agenda:
Service Packs and Cumulative Fix Packs
Security Bulletin
Package Share / Package Manager
AEM Tools
Maven Archetype and LazyBones
Resource:
https://helpx.adobe.com/customer-care-office-hours/aem/aem-managing-deployments.html
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
https://helpx.adobe.com/experience-manager/6-4/sites/deploying/using/maintenance-release-vehicle-definitions.html
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
https://helpx.adobe.com/security/products/experience-manager/apsb18-26.html
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 cuscare@adobe.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
https://helpx.adobe.com/experience-manager/kb/common-AEM-Curl-commands.html
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