Anda di halaman 1dari 235

Table Of Contents

01 - Install & Start an Author Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1


What is an Author instance? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Start the Author instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
Graphical Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
Command Line Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
Once CQ has started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
Start and Stop CQ5 Using Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6

02 - Edit a Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1


To Edit a Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

03 - Browse Related Application/Server Interfaces . . . . . . . . . . . . . . . . . . . . 3-1


How to browse the CRX interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
How to use the Adobe Web Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4
How to use CRXDE Lite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6

04 - Create & Download a CQ Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1


Why do I need CRX content packages? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
To create , build, and download a CRX package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2

05 - Automating Package Manager with cURL . . . . . . . . . . . . . . . . . . . . . . . . 5-1


Using cURL to automate content package management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

06 - Configuring OSGi Bundles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1


EXERCISE 4.1 - Configuring OSGi Bundles: The Version Manager . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
Runmodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7
Setting Runmodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7
Configurations per run mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7
Configurations For Different Runmodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8
Additional Information on Runmodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8
Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8

07 - Set up Replication Agents; 2 Publish Instances . . . . . . . . . . . . . . . . . . . 7-1


Installing two Publish Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
Publish instances folder structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
Replication agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
How do I access and configure Replication Agents? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4
Settings Tab Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5

CQ 5.6 Advanced Developer Training Student Workbook | iii


Transport Tab Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6
Proxy Tab Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8
Extended Tab Configuration Parameters: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9
Triggers Tab Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10
How to Monitor Replication Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-12

08 - Activate a Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

09 - Add a Reverse Replication Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1


Access the Author Agents settings like . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2
Test Reverse Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3

10 - Add the Dispatcher to the IIS WebServer . . . . . . . . . . . . . . . . . . . . . . . . 10-1


How does the Dispatcher plug into IIS? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2

11 - Add the Dispatcher to the Apache WebServer . . . . . . . . . . . . . . . . . . . 11-1


How does the Dispatcher plug into Apache? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-2

12 - Configure the Dispatcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-1


Configuring the dispatcher.any file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-1
To configure the Dispatcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2
Complete the Dispatcher configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-11
Configuring the Dispatcher Flush Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-14

13 - Optimize the TarJournal PM on Author Instance . . . . . . . . . . . . . . . . . 13-1


Manually optimizing journaled tar pm files using CRX Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-1
Automatically optimizing tar files using workspace.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-2

14 - Development Models for Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-1


Creating an online backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-2

15 - Using cURL for Automated Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-1

16 - Cluster Two CQ Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-1


Clustering Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-2
Cluster Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-3
Manual Cluster Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-4
Steps for Manual Slave Clonning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-5
Testing the Clustering Instance via Content Page modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-8
Verifying the Repository configuration via CRXs GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-10

17 - Creating Custom Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-1


Create the Logging Logger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-2
Create the Logging Writer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-4
Using custom runmodes with Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-6
Create a CRX Logger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-9

iv | iv CQ 5.6 Advanced Developer Training Student Workbook


18 - User Administration and Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-1
Users and Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-1
Accessing User Administration with the Security Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-2
To create a Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-4
Managing Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-4
Manage Access Rights for different Websites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-5
Manage Access Rights for Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-6
Manage replication privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-7
Deny access rights to consoles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-8
To create a new user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-9
Adding a User and a Group to a Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-11
Switching to somebody elses identity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-12
Deleting Users or Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-13

19 - Integrate with LDAP for Users and Groups . . . . . . . . . . . . . . . . . . . . . . 19-1


EXERCISE 19.1 Installing a local LDAP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-2
LDAP Installation instructions for Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-2
LDAP Installation instructions for MAC OS X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-2
EXERCISE 19.2 - Setting up/configuring the LDAP server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-3
Configuring CQ5 for LDAP Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-8
EXERCISE 19.3 Configure CQ to integrate with LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-9
Configure repository.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-9
Configure ldap_login.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-10
LDAP Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-12
EXERCISE 19.4 - Assigning Rights to Users imported from LDAP into CRX . . . . . . . . . . . . . . 19-12
Purge Users in LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-13
EXERCISE 19.5 Purge User007 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-13
Synchronize the CRX with LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-16
EXERCISE 19.6 Synchonize the CRX with LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-16

20 - Enable Single Sign On in CQ5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-1


Enable CQ5s CRX To Accept Trusted Credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-1
Add SSO Authorization in addition to LDAP (Author2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-2
Set Up The SSO Authentication Handler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-4

21 - Development Models for Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-1


Author Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-2
Publish Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-2
Performance Optimization Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-2
Planning for Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-2
Stay Relevant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-3
Agile Iteration Cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-3
Basic Performance Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-4
To monitor Page response times: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-4
To monitor Component based timing: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-6
To find long lasting requests/responses: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-7
To view timing statistics for Page rendering: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-9

22 - Security Checklists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-1


CRX Security Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-1
Installation Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-1
Issues with Cross-Site Request Forgery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-2
CQ Security Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-3

CQ 5.6 Advanced Developer Training Student Workbook | v


Disable WebDAV & Debug Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-5
Disable Debug Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-5

23 - Find Unclosed JCR Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-1


Finding Unclosed Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-1

Appendix - A - Configuring the CQ 5.5 Dispatcher on MacOS X . . . . . . . . . A-1


Installing the Dispatcher module into Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2
Configuring httpd.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Configuring the Dispatcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Update the publish instance port number on the dispatcher.any file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

vi | vi CQ 5.6 Advanced Developer Training Student Workbook


Adobe System Admnistrator Training Student Exercise Workbook
Version CQ5620130405

1996-2013. Adobe Systems Incorporated. All rights reserved. Adobe, the Adobe logo, Omniture,
Adobe SiteCatalyst and other Adobe product names are either registered trademarks or trademarks
of Adobe Systems Incorporated in the United States and/or other countries.

All rights reserved. No part of this work may be reproduced, transcribed or used in any form or by
any meansgraphic, photocopying, recording, taping, Web distribution or information storage and
retrieval systemswithout the prior and express written permission of the publisher.

Disclaimer

Adobe reserves the right to revise this publication from time to time, changing content without notice.

CQ 5.6 Advanced Developer Training Student Exercise Workbook vii


Chapter 1 Notes

1-8 | Chapter 1 CQ 5.6 System Administrator Training Student Workbook


Chapter 1 Notes

CQ 5.6 System Administrator Training Student Workbook Chapter 1 | 1-9


02
Edit a Page

Goal

The following instructions explain how to use the CQ5 Author Console to load and edit a page. This
is important because you will use the Websites Administrator Console to create and publish content
throughout the course. In addition, you should understand the interfaces used by your author
community.

To successfully complete and understand these instructions, you will need:

A running CQ5 author instance

What are the available Author (sub-)?

CQ5 uses a web-based graphical user interface, so all you need is a web browser to access the CQ5
console. The graphical user interface is divided into various web-based sub-consoles, where you
can access all of the CQ functionality:

CQ 5.6 System Administrator Training Student Workbook Chapter 02 | 2-1


Chapter 2 Notes

CQ 5.6 System Administrator Training Student Workbook Chapter 02 | 2-7


Chapter 2 Notes

2-8 | Chapter 02 CQ 5.6 System Administrator Training Student Workbook


03
Browse Related Application/
Server Interfaces

Goal

The following instructions explain how to browse the application/server interfaces associated with a
CQ5 installation. This will enable you to use their administrative/configuration capabilities. To suc-
cessfully complete and understand these instructions, you will need:

A running CQ5 Author instance

What interfaces exist?

A typical CQ5 installation consists of a Java Content Repository (CRX), and a Launchpad (Apache
Felix/Apache Sling) application. They each have their own Web interface allowing you to perform
expected administrative/configuration tasks.

How to browse the CRX interface

1. Enter the URL http://localhost:4502/crx/explorer in your favorite Web browsers address bar.

CQ 5.6 System Administrator Training Student Workbook Chapter 03 | 3-1


Chapter 3 Notes

CQ 5.6 System Administrator Training Student Workbook Chapter 03 | 3-9


Chapter 3 Notes

3-10 | Chapter 03 CQ 5.6 System Administrator Training Student Workbook


04
Create & Download a CQ
Package

GOAL

The following instructions explain how to create a CQ package that will combine all elements of the
Training project, minus all jpegs. This is a good example of packaging application content, which you
could then distribute to team members for review. To successfully complete and understand these
instructions, you will need:

A running CQ5 Author instance

The completed Training project with appropriate extensions

Why do I need CRX content packages?

Packages can include content and project-related data. A package is a zip file that contains the
content in the form of a file-system serialization (called filevault serialization) that represents the
content from the repository as an easy-to-use-and-edit representation of files and folders. Content
packages are a good way to, among other things, package application content, which you could then
distribute to team members for review.

CQ 5.6 System Administrator Training Student Workbook Chapter 14 | 4-1


Chapter 04 Notes

4-6 | Chapter 14 CQ 5.6 System Administrator Training Student Workbook


Chapter 04 Notes

CQ 5.6 System Administrator Training Student Workbook Chapter 14 | 4-7


05
Automating Package Manager
with cURL

GOAL

An HTTP service interface is available and allows for managing packages using command-line
clients like cURL or wget or automated scripts. In this way, you can automate content package
management through the use of scripts.

In this exercise, you will learn the cURL syntax for content package management. To successfully
complete and understand these instructions, you will need:

A running CQ5 Author instance

Optional: cURL HTTP client (if necessary you can download cURL from
http://curl.haxx.se/download.html)

Using cURL to automate content package management

Following Package Manager operations are currently supported from the command line:

printing the help screen

listing packages

CQ 5.6 System Administrator Training Student Workbook Chapter 05 | 5-1


removing packages

building packages

installing packages

uninstalling packages

downloading packages

uploading packages

creating packages

deleting packages

performing a dryrun installation

previewing packages

listing package contents

rewrapping packages

To trigger the above operations, simply send requests using the command line client to the CRX
repository. The response is sent back in XML format.

1. To get the help screen: Use the following command in a command line terminal window (e.g.
Putty):

curl -u admin:admin http://localhost:4502/crx/packmgr/service.jsp

You should get the following response:

5-2 | Chapter 05 CQ 5.6 System Administrator Training Student Workbook


Chapter 5 Notes

5-8 | Chapter 05 CQ 5.6 System Administrator Training Student Workbook


Chapter 5 Notes

CQ 5.6 System Administrator Training Student Workbook Chapter 05 | 5-9


06
Configuring OSGi Bundles

As a best practice, Adobe recommends that OSGi bundles be configured by defining nodes in the
repository. This allows you to easily deploy the application configurations to multiple environments
by placing these nodes in CRX content packages.

On a simple level, this can just be a case of moving a CRX content package to a new environment,
uploading it to the repository, and importing its contents. Alternatively, the package can be activated
using the tools section of the CQ5 Admin Console. However some consideration should be given to
managing this process, to ensure that your applications can be deployed efficiently and without any
problems.

Considerations for deploying applications to other environments

Make sure your application code is separate from the configuration, as you may need
to use different configurations with the same application for different environments.
Creating separate packages makes it easy to deploy the appropriate configuration for each
environment.

Make sure your application code does not depend on specific content, as this may not be
present in all environments.

Code packages will be created in the development environment, and will then travel from
development, to test, then to production. Content will generally travel from production,
to test and then to development to be used as test content, so separate packages and
processes may be needed.

CQ 5.6 System Administrator Training Student Workbook Chapter 06 | 6-1


8. Add the following properties to the node you just created:

Create Version on Activation

o Name: versionmanager.createVersionOnActivation
o Type: Boolean
o Value: true

Enable Purging

o Name: versionmanager.purgingEnabled
o Type: Boolean
o Value: true

Purge Paths

o Name: versionmanager.purgePaths
o Type: String
o Value: /content

Implicit Versioning paths

o Name: versionmanager.ivPaths
o Type: String
o Value: /

Max Version Age

o Name: versionmanager.maxAgeDays
o Type: String
o Value: 30

Max Number Versions

o Name: versionmanager.maxNumberVersions
o Type: String
o Value: 3

CQ 5.6 System Administrator Training Student Workbook Chapter 06 | 6-5


Run modes
CQ has built-in author or publish runmodes (Do NOT remove these!). You can add additional custom
runmodes if required. For example, you can configure runmodes for:

Environment: local, dev, test, prod

Location: berlin, basel, timbuktu

Company: acme, partner, customer

Special system type: importer

Setting Run modes


It is possible to define specific run-mode(s) a specific instance should run on. By default an author
instance runs on run-mode author and a publish instance runs on run-mode publish. It is possible to
define several run-modes for one instance, for example author, foo and dev. These run-modes have
to be set as VM options. For example, from the command line:

java -Dsling.run.modes=author,foo,dev -Xmx1024m -jar cq-quickstart-5.6.0.jar

or in the start script:

# default JVM options


CQ _ JVM _ OPTS=-Dsling.run.modes=author,foo,dev

or by adding entries to the crx-quickstart/conf/sling.properties file, for example:

sling.run.modes=author,dev,berlin

Configurations per run mode


To create separate configuration settings per run mode, folder names in the form

config.<runmode> are used, e.g. config.publish:


/apps/myapp/config.publish

For systems with run modes publish and berlin:

/apps/myapp/config.publish.berlin

CQ 5.6 System Administrator Training Student Workbook Chapter 06 | 6-7


Configurations For Different Run modes
Some examples of configuration settings that may be needed for different run modes:

Different mailserver configurations per location:

config.basel/com.day.cq.mailer.DefaultMailService

config.berlin/com.day.cq.mailer.DefaultMailService

En-/Disabling debugging per environment:

config.prod/com.day.cq.wcm.core.impl.WCMDebugFilter

config.dev/com.day.cq.wcm.core.impl.WCMDebugFilter

Additional Information on Run modes


When using different configurations for separate run modes, the following apply:

Partial configurations are not supported.

The configuration with the most matching run modes wins.

To avoid unexpected results:

Always set all properties to avoid confusion.

Use a type indicator (e.g. {Boolean}, {String}, etc.) in every property.

Deployment
In addition to manual deployment of packages, you can automate deployment with the Package
Manager API. For more details, see:

http://dev.day.com/docs/en/crx/current/how_to/package_manager.html#Package%20Manager%20
HTTP%20Service%20API

You can also activate packages in the Tools section of the WCM user interface to install them on all
publish servers. We will be using configurations with run modes later in this course.

6-8 | Chapter 06 CQ 5.6 System Administrator Training Student Workbook


Chapter 4 Notes

CQ 5.6 System Administrator Training Student Workbook Chapter 06 | 6-9


Chapter 4 Notes

6-10 | Chapter 06 CQ 5.6 System Administrator Training Student Workbook


07
Set up Replication Agents; 2
Publish Instances

Goal

Configure Replication Agents so that they replicate/activate content to Publish instances. Content
replication allows administrators to specify subsets of content, usually in author instances, that will be
automatically replicated to other repositories, mainly publish instances, elsewhere in a distributed
environment. Replication can also take place when content entered by site visitors in publish
instances has to be replicated into author instances This is important, because Replication agents are
central to CQ as the mechanism used to:

Publish (activate) content from an author to a publish environment

Explicitly flush content from the Dispatcher cache

Return user input (for example, form input) from the publish environment to the author
environment (under control of the author environment)

A replication Agent is a distinct point-to-point connection between a start point (current instance)
and a specified target instance (usually a Publish instance). Youll need to specify in your environment
as many Replication Agents as target instances you want to address. You need to create an agent
because content replication has a clearly defined goal (as opposed to discrete tasks) and requires no
continuous direct supervision or control.

CQ 5.6 System Administrator Training Student Workbook Chapter 07 | 7-1


The purpose of the Triggers tab is to configure the agents to start replication automatically as soon
as certain conditions occur.

Now we want to setup a second Delivery Agent, pointing to our second Publish instance. We can
create a new Delivery Agent from scratch and modify the settings accordingly.

But since our second Delivery Agent differs from the default one only by its destination instance, we
can simply copy the Default Agent to reuse all other settings. To do this,

1. Return to the Tools pane.

2. Select the Default Agent.

3. Choose Copy to copy the Default Agent and Paste the new agent.

4. Open the new agent and click on Settings to show the details for that agent.

5. Give the new agent an appropriate name, for example Publish 2.

6. Select the Transport Tab and set the URL to the correct values for the second Publish instance.
In our case, http://localhost:4505/bin/receive?sling:authRequestLogin=1. Also make sure that
the User and Password are correct for the second Publish instance.

7. Click OK to save the settings.

For a detailed description of Replication Agents, please consult the online documentation
URL http://dev.day.com/docs/en/cq/current/deploying/configuring_cq.html#Replication Agents .

Now that the second Replication Agent is set up, we can test page activation:

1. Go back to the CQ administrative console and open the Websites panel.

2. Browse to the page Geometrixx Demo Site > English > Products in the navigation panel.

3. Create a new page and open it.

4. Add some text, image, any component you like on your page.

5. In the floating Sidekick panel, select the Page tab (the second tab).

6. Click Activate Page and confirm the activation.

CQ 5.6 System Administrator Training Student Workbook Chapter 07 | 7-11


Chapter 5 Notes

7-14 | Chapter 07 CQ 5.6 System Administrator Training Student Workbook


Chapter 5 Notes

CQ 5.6 System Administrator Training Student Workbook Chapter 07 | 7-15


08
Activate a Tree

Goal

From the Websites tab you can activate the individual pages. When you have entered, or updated, a
considerable number of content pages - all of which are resident under the same root page - it can be
easier to activate the entire tree in one action. You can also perform a Dry Run to emulate an
activation and highlight which pages would be activated.

The following instructions explain how to browse the application/server interfaces associated with a
CQ5 installation. This will enable you to use their administrative/configuration capabilities. To
successfully complete and understand these instructions, you will need:

A running CQ5 Author instance

A running CQ5 Publish instance (if not available activation gets queued)

To activate a complete tree of your website:

1. Access the Tools tab in CQ administrative console.

2. Click on Replication - the folder will expand.

3. Then double-click on Activate Tree.

4. The following page will open.

CQ 5.6 System Administrator Training Student Workbook Chapter 08 | 8-1


Chapter 6 Notes

8-4 | Chapter 08 CQ 5.6 System Administrator Training Student Workbook


Chapter 6 Notes

CQ 5.6 System Administrator Training Student Workbook Chapter 08 | 8-5


09
Add a Reverse Replication Agent

Goal

Replication Agents are used to propagate content from an Author instance to a Publish instance. This
kind of content replication occurs in a one way direction only. In a default environment, the Publish
instances are located behind a firewall which prevent Publish instances to send the User Generated
Content on their instances directly to an Author instance. In order to propagate such a content to all
Publish instances, we need to pull that content from the Publish server and spread it via the regular
mechanisms (Default Replication Agents).

In this exercise, we setup 2 Reverse Replication Agents, one for each installed Publish instance. The
settings of a Reverse Replication Agent are very similar to the ones of a Delivery Agent, which eases
our setup work. In on out-of-the-box installation, theres already such an agent configured, pointing
to a local Publish instances repository.

The following instructions explain how to create and configure Replication Agents. To successfully
complete and understand these instructions, you will need:

A running CQ5 Author instance

Two running CQ5 Publish instances

CQ 5.6 System Administrator Training Student Workbook Chapter 09 | 9-1


3. Copy and paste the default Reverse Replication Agent and adapt its settings.
Feel free to rename both Reverse Replication Agents accordingly. Make sure, each of them are point-
ing to the desired Publish instance.

Test Reverse Replication

During previous exercise, we replicated the entire Geometrixx > English website. There exists a page,
GeoBlog which is perfectly suitable for our test. It consists of a blog, where every visitor can leave a
comment. Since a visitor is connected with one Publish instance at a time, the Reverse Replication
Agent is responsible to retrieve the entered content (comment, reply) to be redistributed again to all
enclosed recipient Publishers. Feel free to test with other forms as well if desired.

1. On Publish 1, navigate to page http://localhost:4503/content/geometrixx/en/blog.html . The


GeoBlog page appears.

2. Enter a new comment or reply to an existing one of your choice.

3. After a few seconds (default : 5), your comment should be visible on the Author instance, as well
as on the other Publish instance, too. Check it !

Congratulations! You have successfully activated two Reverse Replication Agents and tested them.

CQ 5.6 System Administrator Training Student Workbook Chapter 09 | 9-3


Chapter 9 Notes

9-4 | Chapter 09 CQ 5.6 System Administrator Training Student Workbook


Chapter 9 Notes

CQ 5.6 System Administrator Training Student Workbook Chapter 09 | 9-5


10
Add the Dispatcher to the IIS
WebServer

Goal

The Dispatcher is Adobes caching and/or load balancing tool. Using the Dispatcher also helps protect
your application server from attack. Therefore, you can increase protection of your CQ instance by
using the Dispatcher in conjunction with an industry-strength web server.

The CQ Dispatcher is a Web server module. A version is available for Apache Web Server, Microsoft
Internet Information Server and iPlanet. While the installation of the CQ Dispatcher depends on the
Web server, the configuration is the same on all servers:

Install the supported web server of your choice according to their own documentation.

Install the CQ Dispatcher module appropriate to the chosen web server and configure the
web server accordingly.

Configure the Dispatcher.

Integrate with CQ to update the cache when the content in CQ changes.

In this exercise we will install the Dispatcher into an IIS web server.

CQ 5.6 System Administrator Training Student Workbook Chapter 10 | 10-1


Extract disp_iis.dll, disp_iis.ini, disp_iss.pdb and dispatcher.any into the executable
directory of the selected website under IIS.

i.e. <IIS_INSTALLDIR>/scripts

Configure the Virtual Directory

Open Administrative Tools, then select IIS Manager.

Select your site in the tree, then from the context menu (usually right mouse click) select
Add Virtual Directory.

Enter the alias scripts and the physical path of the directory created above (C:\Inetpub\
scripts).

Register the ISAPI filter

Select Features View

Open the feature ISAPI Filters in the view

Click Add and enter the following settings:

Filter name: CQ
Executable: the path to disp_iis.dll (C:\Inetpub\scripts)

Click OK to save

Register the ISAPI handler

Open the feature Handler Mappings in the view

Click Add Script Map and enter the following settings:

Request Path: /scripts/disp_iss.dll


Executable: the path to disp_iis.dll (C:\Inetpub\scirpts)
Name: CQ

Click OK to save

Open the feature Configuration Editor

Select system.webServer\handlers from section drop down list

Select the first row (Collection at the top) and then click on the three dots button (at the
far right)

The Collection Editor will appear, select the handler CQ

CQ 5.6 System Administrator Training Student Workbook Chapter 10 | 10-3


Change the value of the allowPathInfo flag to true

Close the Collection Editor and click Apply

Register the json extension

Open the feature MIME Types in the view

Click Add and enter the following settings:

File name extension: json


MIME type: application/jason

Click OK to save

3. Place the (example) configuration file disp_iis.ini into the same directory as the DLL disp_iis.dll.
The basic format of the .ini file is as follows:

10-4 | Chapter 10 CQ 5.6 System Administrator Training Student Workbook


Chapter 10 Notes

10-6 | Chapter 10 CQ 5.6 System Administrator Training Student Workbook


Chapter 10 Notes

CQ 5.6 System Administrator Training Student Workbook Chapter 10 | 10-7


11
Add the Dispatcher to the
Apache WebServer

Goal

The Dispatcher is Adobes caching and/or load balancing tool. Using the Dispatcher also helps protect
your application server from attack. Therefore, you can increase protection of your CQ instance by
using the Dispatcher in conjunction with an industry-strength web server.

The CQ Dispatcher is a Web server module. A version is available for Apache Web Server, Microsoft
Internet Information Server and iPlanet. While the installation of the CQ Dispatcher depends on the
Web server, the configuration is the same on all servers:

Install the supported web server of your choice according to their own documentation.

Install the CQ Dispatcher module appropriate to the chosen web server and configure the
web server accordingly.

Configure the Dispatcher.

Integrate with CQ to update the cache when the content in CQ changes.

In this exercise we will install the Dispatcher into an Apache web server.

CQ 5.6 System Administrator Training Student Workbook Chapter 11 | 11-1


Chapter 11 Notes

11-8 | Chapter 11 CQ 5.6 System Administrator Training Student Workbook


Chapter 11 Notes

CQ 5.6 System Administrator Training Student Workbook Chapter 11 | 11-9


12
Configure the Dispatcher

Goal

Now that we have integrated the CQ Dispatcher with the web server, we must configure the Dispatcher
so that it can find its associated Publish instances, knows which pages to cache and where to cache
them.

In this exercise we will configure the CQ Dispatcher with appropriate settings to cache pages as
desired, and we will define a Dispatcher Flush agent to invalidate the cache in response to content
update. To successfully complete and understand these instructions, you will need:

A running CQ5 Author instance

A running CQ5 Publish instance

A web server with Dispatcher installed

Configuring the dispatcher.any file

By default the CQ Dispatcher configuration is stored in a file named dispatcher.any. You can change
the name and location of the configuration file. If you do so, make sure to configure the module with
the new name/location. The dispatcher.any file is independent of the Web server and operating
system, so the following instructions are appropriate to both, IIS and Apache. The only difference
between the two configurations is the usage of the property /homepage, which is used only by IIS.

CQ 5.6 System Administrator Training Student Workbook Chapter 12 | 12-1


Chapter 12 Notes

CQ 5.6 System Administrator Training Student Workbook Chapter 12 | 12-15


Chapter 12 Notes

12-16 | Chapter 12 CQ 5.6 System Administrator Training Student Workbook


13
Optimize the TarJournal PM on
Author Instance

Goal

As data is never overwritten in a tar file, the disk usage increases even when only updating existing
data. When optimizing, the TarJournal1 Persistence Manager copies data that is still used from old
tar files into new tar files and deletes the old tar files that contain only old or redundant data.

This exercise will show you multiple ways to optimize the TarJournal PM. To successfully complete
and understand these instructions, you will need:

A running CQ5 Author instance

Manually optimizing journaled tar pm files using CRX Console

To optimize tar files using the CRX console:

1. In the CRX Console, log in as administrator.

2. Click Repository Configuration.

CQ 5.6 System Administrator Training Student Workbook Chapter 13 | 13-1


Chapter 13 Notes

13-4 | Chapter 13 CQ 5.6 System Administrator Training Student Workbook


Chapter 13 Notes

CQ 5.6 System Administrator Training Student Workbook Chapter 13 | 13-5


14
Development Models for Teams

Your company will probably have a backup policy that you will need to follow, additional
considerations of what to backup and when include:

How critical the system and data is.

How often changes are made to either the software or data.

Volume of data; capacity can occasionally be an issue, as can the time needed to perform
the backup.

Whether your backup can be made while users are online; and if possible, what is the
performance impact.

The geographical distribution of users; i.e. when is the best time to backup (to minimize
impact)?

Your disaster recovery policy; are there guidelines on where the backup data has to be
stored (e.g. offsite, specific medium, etc).

There are 2 major backup options:

Cold backup done while the system is not running

Hot or online backup done while the system is running

CQ 5.6 System Administrator Training Student Workbook Chapter 14 | 14-1


To perform a cold backup, make a file system copy of the repository folder, which can
be found at <CQ5 install folder>/crx-quickstart/repository, to a
destination folder selected as the backup target. To do perform a cold backup you
must first stop your instance and restart once the copy process is finished.

You can also perform a hot or online backup while the system is running and being
used normally in a normal read-write mode. Backup files are saved in the ZIP
compression format. Backup files can be created, downloaded, and removed.

Often a full backup is taken at regular intervals (e.g., daily, weekly, or monthly) with
incremental backups in between (e.g., hourly, daily, or weekly).

Creating an online backup

This backup method creates a backup of the entire repository, including CQ5 or other applications
deployed into it. This method lets you create and later restore the entire repository and
applications running on it, including content, version history, configuration, software, hotfixes,
custom applications, log files, search indexes, and so on.

This method works as a hot or online backup, so you can perform this backup while the repository
is running. The repository is usable while the backup is running, however performance of the
repository will decrease. This method works for the default, TarPM-based CRX instances.

Backup files are saved in the ZIP compression format. By default, they are saved in the parent folder
of the folder where the quickstart .jar is running. You can change the location where CRX saves
backup files.

14-2 | Chapter 14 CQ 5.6 System Administrator Training Student Workbook


Chapter 14 Notes

CQ 5.6 System Administrator Training Student Workbook Chapter 14 | 14-5


Chapter 14 Notes

14-6 | Chapter 14 CQ 5.6 System Administrator Training Student Workbook


Chapter 13 Notes

CQ 5.6 System Administrator Training Student Workbook Chapter 15 | 15-3


Chapter 13 Notes

15-4 | Chapter 15 CQ 5.6 System Administrator Training Student Workbook


16
Cluster Two CQ Instances

A cluster is formed of two or more live servers linked together. Therefore, if one node fails, the other
nodes are active and accessible for your applications and there is no system interruption. This allows you
to recover and re-start failed nodes easily. New nodes can also be added to an existing cluster, allowing
for simple extensibility.

Clustering is beneficial for:

Increased availability

When a server breaks down, or becomes unavailable, the cluster agent relays requests to the
servers that are still running. Service continues without interruption.

Increased performance
Clustering increases system performance and availability even when nodes fail.

While all servers in the cluster are active, you can use their combined computational power.
Therefore, this solution improves performance during normal use. However, if one server breaks
down you lose its performance, so the overall application performance may suffer.

CQ 5.6 System Administrator Training Student Workbook Chapter 16 | 16-1


Goal

The following instructions describe how to set up a cluster in CRX (or CQ) with two cluster nodes on two
separately networked servers. To successfully complete and understand these instructions, you will
need:
2 running CQ5 Author instances

Clustering Options

One of the most significant new features within CQ5.4 is in the way CRX Clustering is performed. The
shared nothing clustering feature was introduced such that two separate instances of CQ5.4 can run at
the same time without having to share the file-system (e.g. SAN). Both instances are synchronized and
changes made on either one of the instance are replicated to the other one.

In this mode, all the three main storage areas (workspaces, data store, and journal) are stored locally on
each cluster, and synchronized fully over the network.

Shared Nothing mode of active clustering complements the existing clustering over a shared
filesystem, and provides system administrators and developers with more flexibility in choosing their
high availability and load balancing architecture:

Shared Nothing for simple setup, no dependency on network filesystem implementation


and configuration.

Shared filesystem clustering for managing state of the system on the central networked
filesystem.

Mixed deployments, where workspace data and journal are in shared nothing mode,
and data store is not in shared nothing mode then the shared filesystems can be used to
optimize disk space requirements for large deployments.

Shared Nothing clustering largely simplifies cloud deployments, as the need to provision and configure
a shared network filesystem for all nodes is removed. Graphical User Interfaces for joining cluster now
only requires a URL to an existing cluster node instead of a path to the shared filesystem.

Share Nothing mode of operation is implemented or enhanced in the following three persistence
modules:

Enhanced: TarPM, which can work in shared nothing mode.

16-2 | Chapter 16 CQ 5.6 System Administrator Training Student Workbook


Chapter 16 Notes

CQ 5.6 System Administrator Training Student Workbook Chapter 16 | 16-11


Chapter 16 Notes

16-12 | Chapter 16 CQ 5.6 System Administrator Training Student Workbook


17
Creating Custom Log Files

Goal

Various CQ5 log files provide detailed information about the current system state. In addition to the
default system log files you can also create and customize your own log files. They can help you
better track messages produced by your own applications and to separate them from the default log
entries.

CQs logging system is based on SLF4J (Simple Logging Facade for Java), consisting basically of 2
elements, a Logging Logger and a Logging Writer. The Writer persists the data provided by the Logger
to a configurable location. Usually, it is a file. The Logger collects data from different components
inside CQ, filters them by requested severity level and redirects the output to configured Writer.

In CQ, we can configure logging for the 2 major interfaces, CQ and CRX independently. Usually, were
more interested what happens under CQs cover. In particular cases, we can also setup a higher
verbosity level for the CRX module.

In this example, we will generate a new log file and monitor only messages produced by a specific set
of CQ5 modules. To successfully complete and understand these instructions, you will need:

A running CQ5 Author instance

There are 2 ways to configure the CQs Logging system : using the Apache Felix web console and CRX.
Adobe recommends to configure everything in CRX and use Apache web console as a viewer only.
The exercise describes both ways.

CQ 5.6 System Administrator Training Student Workbook Chapter 17 | 17-1


As an advanced topic, we also configure logging for CRX, to monitor its processes.

To create a custom log file with a specified log level:

First, we create the configuration in CRX, then we review it in the Apache Felix console. A first view
of possible configuration modules in Apache (http://localhost:4502/system/console/configMgr)
shows us 2 possible configurations : single modules and factory modules. The difference is, a single
module exists only once in CRX, while from a factory module can be created several modules. As an
example, the module Apache Sling Logging Configuration is a singleton module, while Apache
Sling Logging Logger Configuration is a factory module, used to create as many logger modules as
required of the same type.

Create the Logging Logger

In this first example, we create a new logger module based on a factory module (Apache Sling Logging
Logger Configuration) using CRX. It should log protocol messages generated by the modules org.
apache.felix and com.day, filtering out messages with Log severity higher than Debug.

1. Open CRXDELite (http://localhost:4502/crx/de/ ) so that you can define a new configuration for
the custom log file.

2. If the folder /apps/geometrixx/config.author doesnt already exist, do the following:

Right click on the /apps/geometrixx folder and choose Create...Create Node

o Name: config.author
o Type: sling:Folder

Save.

3. Using the same steps as described in Step 2, create a subnode of /apps/geometrixxx/config.


author. Use the values:

Name: org.apache.sling.commons.log.LogManager.factory.config-TRAINING

Type: sling:OsgiConfig

17-2 | Chapter 17 CQ 5.6 System Administrator Training Student Workbook


Chapter 17 Notes

CQ 5.6 System Administrator Training Student Workbook Chapter 17 | 17-11


Chapter 17 Notes

17-12 | Chapter 17 CQ 5.6 System Administrator Training Student Workbook


The online documentation http://dev.day.com/content/docs/en/cq/current/administering/security.
html contains more information related to Users and Groups Management.

Congratulations! You have successfully created users and groups and learned to manage those users
and groups. Adobes best practices suggest that permissions and privileges be granted and denied on
a group basis. Groups tend to remain stable, whereas users come and go more frequently.

18-14 | Chapter 18 CQ 5.6 System Administrator Training Student Workbook


Chapter 18 Notes

CQ 5.6 System Administrator Training Student Workbook Chapter 18 | 18-15


Chapter 18 Notes

18-16 | Chapter 18 CQ 5.6 System Administrator Training Student Workbook


19
Integrate with LDAP for Users
and Groups

LDAP (the Lightweight Directory Access Protocol) is used for accessing centralized directory services.
This helps reduce the effort required to manage user accounts as they can be accessed by multiple
applications. One such LDAP server is Active Directory. LDAP is often used to achieve Single Sign On,
which allows a user to access multiple applications after logging in once.

LDAP authentication is required to authenticate users stored in a (central) LDAP directory such as
Active Directory. This helps reduce the effort required to manage user accounts. User accounts can
be synchronized between the LDAP server and CRX, with LDAP account details being saved in the
CRX repository. This allows the accounts to be assigned to CRX groups for allocating the required
permissions and privileges.

CRX uses LDAP authentication to authenticate such users, with credentials being passed to the LDAP
server for validation, which is required before allowing access to CRX. To improve performance,
successfully validated credentials can be cached by CRX; with an expiry timeout to ensure that
revalidation does occur after an appropriate period.

When an account is removed from the LDAP server validation is no longer granted and so access to
CRX is denied. Details of LDAP accounts that are saved in CRX can also be purged from CRX.
Use of such accounts is transparent to your users, they see no difference between user and group
accounts created from LDAP and those created solely in CRX.

You can configure LDAP authentication as a JAAS (Java Authentication and


Authorization Service) module. In this chapter, we will explore integration with an LDAP server and
importing users and groups into the CQ5 instance from the LDAP server.

CQ 5.6 System Administrator Training Student Workbook Chapter 19 | 19-1


Configuring CQ5 for LDAP Authentication
CQ5 LDAP configuration information, as presented here and in the documentation, will need to be
adapted to the specifics for your directory server; such as authentication information for logging in to
the directory server, the name of object classes and attributes.

The Java Authentication and Authorization Service (JAAS) works on the basis of LoginModules. In
a JAAS configuration file you can define a sequence of login modules. An incoming request will be
accepted by the first defined login module for authentication. If the login module cannot authenticate,
the request will be passed on to the next login module in the list of definitions.

In this configuration, the first login module that we will configure is the native CRXLoginModule,
which tries to authenticate using CRXs local users:

com.day.crx.core.CRXLoginModule sufficient;

Only if the user of the request cannot be found among the local CRX users, the request will be handed
over to the next login module, which is the LDAP login module:

com.day.crx.security.ldap.LDAPLoginModule required

The LDAP login module will connect to the LDAP server and try to perform a bind
using the given credentials..

To integrate with an LDAP server, you must modify the CRX repository.xml file to configure the
integration. Authenticated users will not be able to log into any workspace when sync mode is set
to none and the default security configuration of CRX is used. As a result, if you want to use sync
mode, you need to set the WorkspaceAccessManager class to

org.apache.jackrabbit.core.security.simple.SimpleWorkspaceAccessManager

In addition, we will also need to remove the existing <LoginModule> element, as this LoginModule
points to the onboard CRX authentication manager.

The LDAP login module requires some configuration parameters, such as host, port and authenticated
user of the LDAP server, which LDAP attribute to translate to a CRX user id, where to find groups,
users, etc. Read the commented section of the ldap_login.conf to understand their meaning.

The LDAP module also has an autocreate feature. If enabled, users that were successfully
authenticated on the LDAP server will be imported as local users in CRX. We will use autocreation
for this class.

19-8 | Chapter 19 CQ 5.6 System Administrator Training Student Workbook


6. Try to log in to CQ5 wit user002. It should work without problems. In case of difficulties, dont
forget to clear the browser cache or close all browser windows and try again.

Additional Steps
You can also make sure that users are added to an appropriately permissioned group, for example,
the contributors group, when they first log in. You can do this by making a change to the ldap_login.
conf file.

7. Add the line



autocreate.user.membership=contributor

to the LDAPLoginModule.

8. Restart CQ5 and try logging in with a different user.

CQ 5.6 System Administrator Training Student Workbook Chapter 19 | 19-19


Chapter 19 Notes

19-20 | Chapter 19 CQ 5.6 System Administrator Training Student Workbook


Chapter 19 Notes

CQ 5.6 System Administrator Training Student Workbook Chapter 19 | 19-21


20
Enable Single Sign On in CQ5

GOAL

The goal here is to setup the Single Sign On (SSO) authentication for CQ5. There are 2 different
possibilities to use SSO in CQ: in conjunction with LDAP and without. In most situations, you may
want to install SSO along with LDAP. This exercise shows both ways to do it. Since we have 2 Author
instances installed on our machines, we can respect both configurations. The instance Author1 is
installed without LDAP, while Author2 is connected to a running LDAP server.

To successfully complete and understand these instructions, you will need:

A running CQ5 Author instance


A second running CQ5 Author instance configured to use LDAP
LDAP server up and running

Enable CQ5s CRX To Accept Trusted Credentials

First, lets have a look what we need to configure on Author1 to work with SSO. This instance
authenticates its users solely using CRX.

Before SSO can be enabled for CQ5, the underlying CRX instance needs to be configured to accept
the trusted credentials provided by CQ WCM. To do this, we configure CRXs repository.xml.

1. In the file system where Author1 is installed, open the file <cq-install-dir>/crx-
quickstart/repository/repository.xml .

CQ 5.6 System Administrator Training Student Workbook Chapter 20 | 20-1


Chapter 20 Notes

CQ 5.6 System Administrator Training Student Workbook Chapter 20 | 20-7


Chapter 20 Notes

20-8 | Chapter 20 CQ 5.6 System Administrator Training Student Workbook


21
Development Models for Teams

Goal

The following instructions explain how to monitor Page response times, in addition to finding slow
Page responses. This will allow you to create a more robust/scalable CQ application, even with
limited hardware. To successfully complete and understand these instructions, you will need:

A running CQ5 Author instance

An Adobe provided rlog.jar tool (already installed with your CQ5 instance -<install dir>/
crx-quickstart/opt/helpers)

What performance optimization concepts should I consider?

A key issue is the time your Web site takes to respond to visitor requests. Although this value will vary
for each request, an average target value can be defined. Once this value is proven to be both
achievable and maintainable, it can be used to monitor the performance of the Web site and indicate
the development of potential problems.

The response times you will be aiming for will be different on the author and publish environments,
reflecting the different characteristics of the target audience:

CQ 5.6 System Administrator Training Student Workbook Chapter 21 | 21-1


Author Environment

This environment is used by authors entering, and updating content, so it must cater for a small
number of users who each generate a high number of performance intensive requests when updating
content pages and the individual elements on those pages.

Publish Environment

This environment contains content which you make available to your users, where the number of
requests is even greater and the speed is just as vital, but since the nature of the requests is less
dynamic, additional performance enhancing mechanisms can be leveraged, such as thatthe content
is cached orload-balancing is applied.

Performance Optimization Methodology

A performance optimization methodology for CQ projects can be summed up to five very simple
rules that can be followed to avoid performance issues from the get go. These rules, to a large degree,
apply to Web projects in general, and are relevant to project managers and system administrators to
ensure that their projects will not face performance challenges when launch time comes.

Planning for Optimization

Around 10% of the project effort should be planned for the performance optimization phase. Of
course, the actual performance optimization requirements will depend on the level of complexity of
a project and the experience of the development team. While your project may ultimately not require
all of the allocated time, it is good practice to always plan for performance optimization in that
suggested range.

Whenever possible, a project should first be soft-launched to a limited audience in order to gather
real-life experience and perform further optimizations, without the additional pressure that follows a
full announcement.

Once you are live, performance optimization is not over. This is the point in time when you
experience the real load on your system. It is important to plan for additional adjustments after the
launch.

Since your system load changes and the performance profiles of your system shifts over time, a
performance tune-up or health-check should be scheduled at 6-12 months intervals.

21-2 | Chapter 21 CQ 5.6 System Administrator Training Student Workbook


Simulate Reality

If you go live with a Web site and you find out after the launch that you run into performance issues
there is only one reason for that: Your load and performance tests did not simulate reality close
enough.

Simulating reality is difficult and how much effort you will reasonably want to invest into getting
realdepends on the nature of your project. Real means not just real code and real traffic,
but also real content, especially regarding content size and structure. Keep in mind that your
templates may behave completely different depending on the size and structure of the repository.

Establish Solid Goals

The importance of properly establishingperformance goals is not to be underestimated. Often, once


people are focused on specific performance goals, it is very hard to change these goals afterwards,even
if they are based on wild assumptions.

Establishing good, solid performance goals is really one of the trickiest areas. It is often best to collect
real life logs and benchmarks from a comparable Web site (for example the new Web sites
predecessor).

Stay Relevant

It is important to optimize one bottleneck at a time. If you do things in parallel without validating the
impact of the one optimization, you will lose track of which optimization measure actually helped.

Agile Iteration Cycles

Performance tuning is an iterative process that involves, measuring, analysis, optimization and
validation until the goal is reached. In order to properly take this aspect into account, implement
anagile validation process in the optimization phase rather than a more heavy-weight testing process
after each iteration.

This largely means that the administrator implementing the optimization should have a quick way to
tell if the optimization has already reached the goal, which is valuable information, because when the
goal is reached, optimization is over.

CQ 5.6 System Administrator Training Student Workbook Chapter 21 | 21-3


Basic Performance Guidelines

Generally speaking, keep your uncached html requests to less than 100ms. More specifically, the
following may serve as a guideline:

70% of the requests for pages should be responded to in less than 100ms.

25% of the requests for pages should get a response within 100ms-300ms.

4% of the requests for pages shouldget a response within 300ms-500ms.

1% of the requests for pages shouldget a response within 500ms-1000ms.

No pages should respond slower than 1 second.

The above numbers assume the following conditions:

measured on publish (no authoring environment and/or CFC overhead)

measured on the server (no network overhead)

not cached (no CQ-output cache, no Dispatcher cache)

only for complex items with many dependencies (HTML, JS, PDF, ...)

no other load on the system

There are a certain number of issues that frequently contribute to performance issues which mainly
revolve around (a) dispatcher caching inefficiency and (b) the use of queries in normal display
templates. JVM and OS level tuning usually do not lead to big leaps in performance and should
therefore be performed at the very tail end of the optimization cycle.

Your best friends during a usual performance optimization exercise are the request.log, component
based timing, and last but not least - a Java profiler.

To monitor Page response times:

1. Navigate to and open the file request.log located at <CQ5_install_dir>/crx-quickstart/logs.

2. Request a Page in author that utilizes your Training Template and Components.

e.g. /content/training_site/english/training_company

21-4 | Chapter 21 CQ 5.6 System Administrator Training Student Workbook


Chapter 21 Notes

CQ 5.6 System Administrator Training Student Workbook Chapter 21 | 21-11


Chapter 21 Notes

21-12 | Chapter 21 CQ 5.6 System Administrator Training Student Workbook


22
Security Checklists

CRX Security Checklist

Installation Settings
Determine the Security Level - Make sure that there is no alow Access Control Entry on the root node
(/) for the principal everyone. This would allow everyone to read/write/etc content.

Switch from Low to High Security - To switch from low to high security, you need to remove all access
control policies for the principal everyone on the root node. This will deny the default read/write access
to content available to any logged-in user. After this you will be able to configure authorization for your
repository groups and users according to your needs

CQ 5.6 System Administrator Training Student Workbook Chapter 22 | 22-1


Passwords

Change the CRX Admin Password - Before you use CRX productively, we recommend that you change
the default passwords. The default password for the admin account is admin.
Password protect the Anonymous account.

Issues with Cross-Site Request Forgery

To address known security issues with Cross-Site Request Forgery (CSRF) in CRX WebDAV and Apache
Sling you need to configure the Referrer filter.

The referrer filter service is an OSGi service that allows you to configure:

which http methods should be filtered

whether an empty referrer header is allowed

and a white list of servers to be allowed in addition to the server host.

By default, all variations of localhost and the current host names the server is bound to are in the white
list.

- File System Security

Prohibit illegitimate write access to CRX installation - Write access to files in a CRX installation or its
backups must only be allowed to users whose role in CRX is that of an admin. Write access to the
installation folders allows users to reconfigure CRX through OSGi configuration files, which allows
immediate rights elevation to admin.

Prohibit illegitimate read access to log files - Log files can potentially disclose information that reveals
attack vectors. As such, access to read log files must only be granted to trusted entities.

- Securing HTTP Communication

As with any application available on the internet, any confidential information must be secured on a
transport level.

The need for this will vary depending on the content stored in your system.

To ensure that the system cannot be compromised, the following should be secured through SSL for any
CRX system, irrespective of the content in the system.

Access to the OSGi Console

22-2 | Chapter 22 CQ 5.6 System Administrator Training Student Workbook


Access by the admin user

Access to user information

Inter-system communication if it goes over the public internet.

- Sanity Checks prior to Go-Live

- Securing HTTP Communication

As with any application available on the internet, any confidential information must be secured on a
transport level.

The need for this will vary depending on the content stored in your system.

To ensure that the system cannot be compromised, the following should be secured through SSL for any
CRX system, irrespective of the content in the system.

Access to the OSGi Console

Access by the admin user

Access to user information

Inter-system communication if it goes over the public internet.

- Sanity Checks prior to Go-Live

CQ Security Checklist

Various areas are impacted and you should review all (in detail, the following list is meant to provide an
introductory overview) to see which can be used to help protect your implementation:

Change Default Passwords


An out-of-the-box installation of CQ includes various accounts to enable you to administrate
and use the instance.
In particular, we strongly recommend that after installation you change the passwords for the
privileged (admin) account(s).

Configure replication and transport users


Create users with specific, restricted access rights for building replication content (Author
environment) and for receiving content (Publish environments) instead of using the admin
user.

CQ 5.6 System Administrator Training Student Workbook Chapter 22 | 22-3


Disable WebDAV
CRX and CQ come with WebDAV support that lets you display and edit the repository
content. Setting up WebDAV gives you direct access to the content repository through your
desktop.
WebDAV should be disabled on the publish environment.

Restrict Access via the Dispatcher


The Dispatcher filter can be used to allow or deny external access to specific areas of CQ To
protect your instance you should configure the Dispatcher to restrict external access as far as
possible.

Protect against Cross-Site Scripting (XSS)


Cross-site scripting (XSS) allows attackers to inject code into web pages viewed by other
users. This security vulnerability can be exploited by malicious web users to bypass access
controls.
CQ applies the principle of filtering all user-supplied content upon output. Additionally, a
web application firewall can be configured to add protection.

Preventing Denial of Service (DoS) Attacks


A denial of service (DoS) attack is an attempt to make a computer resource unavailable to
its intended users. This is often done by overloading the resource.
There are a few methods that can be used with CQ to help prevent such attacks.

Default Access to User Profile(s) is everyone


By default, everyone (the built-in group) has read access to all user profile(s).
If such access is not appropriate for your installation you can change these default settings.

Issues with Cross-Site Request Forgery (CSRF)


This is a security issue from the CRX Security Checklist, that is also appropriate to CQ.
To address known security issues with (CSRF) in CRX WebDAV and Apache Sling you can
configure the Referrer filter.

Disable the CQ WCM Debug Filter on production systems


This is useful when developing as it allows the use of suffixes, but should be disabled on a
production instance to ensure performance and security.

Clickjacking
Configuring your webserver can help prevent clickjacking.

22-4 | Chapter 22 CQ 5.6 System Administrator Training Student Workbook


Chapter 22 Notes

CQ 5.6 System Administrator Training Student Workbook Chapter 22 | 22-7


Chapter 22 Notes

22-8 | Chapter 22 CQ 5.6 System Administrator Training Student Workbook


Chapter 23 Notes

23-4 | Chapter 23 CQ 5.6 System Administrator Training Student Workbook


Chapter 23 Notes

CQ 5.6 System Administrator Training Student Workbook Chapter 23 | 23-5


Appendix - A
Configuring the CQ 5.5
Dispatcher on MacOS X

The following instructions describe how to configure the Adobe CQ 5.5 Dispatcher on a Mac OS X
version 10.[6-7].X, and the Apache web server 2.2 that comes already installed on Mac OS X. This
section provides instructions that replace Exercise 9 - Add the Dispatcher to the Apache WebServer

You may want to make sure the Apache Web Server already installed in your MacOS X is up and
running in your system. Enter your system preferences, then click on sharing and then start your
Web Sharing by selecting its checkbox.

CQ 5.6 System Administrator Training Student Workbook Chapter 05 | A-1


Congratulations! You have successfully configured the CQ Dispatcher with the Apache Web server
already installed on your Mac OS X, cached pages in the Web server document root and accessed
activated content pages from the Web server.

CQ 5.6 System Administrator Training Student Workbook Chapter 05 | 7


Appendix - A Notes

8 | Chapter 05 CQ 5.6 System Administrator Training Student Workbook


Appendix - A Notes

CQ 5.6 System Administrator Training Student Workbook Chapter 05 | 9