Creating a Gold Copy of Adobe CQ – Part 2 of 5 – Custom Configurations

by | Oct 22, 2013 | Adobe CQ, Web Content Management | 0 comments

In the previous post on this series, Creating a Gold Copy of Adobe CQ Part 1 we mentioned the 4 major areas of configurations that System Administrators must deal with when recovering a crashed instance of Adobe CQ.

In this post, I will be covering the first of the four major areas, custom configurations. In this set of configuration we will review how to better integrate CQ into the underlying Java Virtual Machine (JVM) and Operating System, as well as configurations that need to integrate with other systems (like: dispatcher,  mappings and clustering).

Custom Configurations

You need to start with the crx-quickstart folder used in part 1 of this series. This folder will become our Gold Copy at the end of all 5 posts:

  1.  create Operating System user: create an specific operating system to perform all CQ related actions. These users should be consistent across all environments. a good name for these users could be cqauthor for all author instances and cqpublish for all publish instances ($ adduser cqauthor). If you are going to set the logs folder outside CQ’s installation folder (crx-quickstart) then you will also need to grant full access for these users to such linked folders ($ ln -s <targeted folder> logs)
  2. create destination folder: It is a good idea to make this folder consistent across all environments. A good CQ installation folder could be /opt/cq-author for author instances and /opt/cq-publish for publish instances
  3. test JDK: Always test the JDK installed in your system by executing > java -version;
  4. unpack CQ5.5: copy quickstart jar and license files into the targeted folder and rename jar file to cq-quickstart-p.jar ($ mv cq-quickstart<date>.jar cq-quickstart-p.jar). Don’t install CQ by executing the jar file ($ java -jar cq-<run mode>-<port number>.jar); if you do you will need to provide run mode and port number in the jar file name itself. Unpack ($ java -Xmx512m -jar cq-quickstart-p.jar -unpack)
  5. provide run-mode and port number: set CQ_PORT and CQ_RUNMODE according to the targeted environment
    CQ_RUNMODE=author,localhost. When setting port number make sure all servers have required ports opened. Also ti’s customary to use even numbers for author instances (4502, 4504, etc) and odds for publishers (4503, 4504, etc). For run-modes always provide the generic run-mode (author or publish) plus at least one specific such as QA, production and others. The more specific you get the more granular configurations you will be able to provide.
  6. set JVM options: provide default options and any custom you know are required
    -server: VM tuned for server applications; will start up slower but will run faster
    -Xmx: assigns the maximum size the heap can grow. Minimum possible value is 1024m. This value should be set to a 60% of the targeted OS available free memory ($ free -t -m)
    -XX:MaxpermSize: assigns the maximum size the “non-heap” or “perm area” can grow. Minimum possible values is 256M. This value should be set to a 25% of the targeted OS available free memory
    -Djava.awt.headless: Headless mode enables a JVM to perform Abstract Windowing Toolkit (AWT) operations on a machine that does not have a display, keyboard or mouse. Since most of the times you install/run CQ via a SSH connection then you must set this value to true Temporary directory used by JVM and java classes to create temporary files. If not set then default Operating System’s temp folder is used
  7. create start script for each and every instance and save a copy of such files
  8. install servicePack, hotfixes and feature packs: Policy dictates that for every new project with no already developed custom application (“starting from scratch”) you must install latest service pack and hotfixes available. As for the hotfixes most of the times they are privately available and you must request them through an Adobe care ticket. If you are creating a gold copy for an already running system then you have to options: 1) keep the Service Pack number and hotfixes already installed since the application is already running after all (not recommended) or 2) perform thorough tests of the application running with latest available Service Pack and hotfixes, if issues are found then the application must be updated
  9. Remove Geometrixx Web site: For lower environments such as CI, QA and others it’s okay to have these demo websites but not for production; such demo sites must be removed.
  10. Change admin user password: every new installation comes with an admin user set to the default password: admin. This password needs to be changed for security reasons.
  11. configure forward, reverse and flush agents: By default “admin” user is used to connect to other instances and perform replications between CQ instances and dispatcher. It’s a best practice to create a new user, specific for replication operations, and update all replication agents; also, deactivate agents that are not in use.
  12. mappings configuration: if multiple domains are going to be served by same CQ instances then CQ mappings need to be created and rewrite rules need to be added to Webservers.
  13. clustering: configure cluster nodes and make sure fail over and sticky connections are set
  14. dipatcher configuration: for those instances behind webservers a dispatcher need to be configured.


Need a bit more info on how Armedia can help you?

Feel free to schedule a 30-minute no-obligations meeting.


Submit a Comment

Your email address will not be published. Required fields are marked *