In this blog­post I give an overview of some basic checks you can do after you have done a (pro­duc­tion) instal­la­tion 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 fol­low­ing urls should not be accessible:

http://yourwebsite/system/console

http://yourwebsite/system/sling/cqform/defaultlogin.html

http://yourwebsite/crx/de/index.jsp

http://yourwebsite/etc/packages.html

If these pages are acces­si­ble, then you have to revisit the secu­rity set­tings men­tioned in this document :

http://dev.day.com/docs/en/cq/current/deploying/security_checklist.html#Restrict%20Access%20via%20the%20Dispatcher

2. OSGi-configuration

Go to the site, and try these two urls :

http://yourwebsite/somepage?wcmmode=edit

http://yourwebsite/somepage?debug=layout

If you see the page changed, that will give you an indi­ca­tion that the basic OSGi-configuration is not done, you can find these set­tings in this document :

http://​dev​.day​.com/​d​o​c​s​/​e​n​/​c​q​/​c​u​r​r​e​n​t​/​d​e​p​l​o​y​i​n​g​/​c​o​n​f​i​g​u​r​i​n​g​_​o​s​g​i​.​h​tml

3. Basic error-handling

Go to your site and go to a non exist­ing url/page :

http://yourwebsite/notthispage

This should result is a decent error­page, and it should not redi­rect to the sling login screen.

Here a doc­u­ment that explains how to cus­tomize the error-pages

http://​dev​.day​.com/​d​o​c​s​/​e​n​/​c​q​/​c​u​r​r​e​n​t​/​d​e​v​e​l​o​p​i​n​g​/​c​u​s​t​o​m​i​z​i​n​g​_​e​r​r​o​r​_​h​a​n​d​l​e​r​_​p​a​g​e​s​.​h​tml

4. Removal of Geometrixx

Go to your site (exter­nal and inter­nal) to this url :

http://yourwebsite/content/geometrixx

This should result in a error-not-found page, and not show­ing the default Geometrixx website.

Here a doc­u­ment that describes how to remove the default Geometrixx website.

http://​dev​.day​.com/​d​o​c​s​/​e​n​/​c​q​/​c​u​r​r​e​n​t​/​d​e​p​l​o​y​i​n​g​/​i​n​s​t​a​l​l​i​n​g​_​c​q​.​h​tml

5. Default users

Go to your CQ5-instances (author+publish) and try to login with the default pass­word of the default users pro­vided with CQ5 (admin/author).

The expected result is that the pass­words are changed for these user-accounts or that you can’t login with those.

http://​dev​.day​.com/​d​o​c​s​/​e​n​/​c​q​/​c​u​r​r​e​n​t​/​d​e​p​l​o​y​i​n​g​/​s​e​c​u​r​i​t​y​_​c​h​e​c​k​l​i​s​t​.​h​tml

6. Dis­patcher and caching

For the blog­post I just used Jme­ter to gen­er­ate some sim­ple load on the web­site. When you are able to gen­er­ate some load on your instal­la­tion it is much eas­ier to see whether par­tic­u­lar set­tings are work­ing. And it will give you a first idea on the load on the machines.

Begin with some very sim­ple urls, like :

http://yourwebsite/homepage

http://yourwebsite/homepage/about-my-company.html

Now you can check your dis­patcher and load­bal­ancer (if installed) if they are work­ing as it should be. You should be see­ing entries in the log-file.

When caching is con­fig­ured on the dis­patcher, you can eas­ily ver­ify that by chang­ing the url to http://yourwebsite/homepage?a=b . Because the dis­patcher doesn’t cache pages with a ? in it, all these requests will han­dled by the pub­lish instance. And there­fore the through­put will go down a lot.
Here you can find some basic dis­patcher documentation:

http://​dev​.day​.com/​d​o​c​s​/​e​n​/​c​q​/​c​u​r​r​e​n​t​/​d​e​p​l​o​y​i​n​g​/​d​i​s​p​a​t​c​h​e​r​.​h​tml

Doc­u­men­ta­tion

Here some handy doc­u­men­ta­tion around per­for­mance and the gen­eral knowl­edge base.

http://​dev​.day​.com/​d​o​c​s​/​e​n​/​c​q​/​c​u​r​r​e​n​t​/​h​o​w​t​o​/​p​e​r​f​o​r​m​a​n​c​e​_​m​o​n​i​t​o​r​.​h​tml
http://​dev​.day​.com/​c​o​n​t​e​n​t​/​k​b​/​h​o​m​e​/​c​q​5​.​h​tml

Twit­ter: @heervisscher