Sanity checks for Adobe CQ5 installations
In this blogpost I give an overview of some basic checks you can do after you have done a (production) installation of CQ5.x . The checks can mostly be done via the browser, and will give you very quickly an rough idea whether you are almost done, or still need to start.
1. Admin screens
The following urls should not be accessible:
If these pages are accessible, then you have to revisit the security settings mentioned in this document :
Go to the site, and try these two urls :
If you see the page changed, that will give you an indication that the basic OSGi-configuration is not done, you can find these settings in this document :
3. Basic error-handling
Go to your site and go to a non existing url/page :
This should result is a decent errorpage, and it should not redirect to the sling login screen.
Here a document that explains how to customize the error-pages
4. Removal of Geometrixx
Go to your site (external and internal) to this url :
This should result in a error-not-found page, and not showing the default Geometrixx website.
Here a document that describes how to remove the default Geometrixx website.
5. Default users
Go to your CQ5-instances (author+publish) and try to login with the default password of the default users provided with CQ5 (admin/author).
The expected result is that the passwords are changed for these user-accounts or that you can’t login with those.
6. Dispatcher and caching
For the blogpost I just used Jmeter to generate some simple load on the website. When you are able to generate some load on your installation it is much easier to see whether particular settings are working. And it will give you a first idea on the load on the machines.
Begin with some very simple urls, like :
Now you can check your dispatcher and loadbalancer (if installed) if they are working as it should be. You should be seeing entries in the log-file.
When caching is configured on the dispatcher, you can easily verify that by changing the url to http://yourwebsite/homepage?a=b . Because the dispatcher doesn’t cache pages with a ? in it, all these requests will handled by the publish instance. And therefore the throughput will go down a lot.
Here you can find some basic dispatcher documentation:
Here some handy documentation around performance and the general knowledge base.