eZtip: Errors can be misleading...what happens when the DB is dead

I recently received an email from an eZ community member stating after an abnormal system reboot that their working eZ Publish install was reduced to responding with "Error / kernel (1) Access denied"My suspicion was that there was an issue with the database. More than likely it had not successfully started when the system was brought up again.

I tested this theory by stopping the database in my local development environment and accessing the associated eZ Publish site. Manually editing the settings/siteaccess/eng/site.ini/append.php to turn on debugging confirms the problem and gives an insight into what is happening:

Connection error: Couldn't connect to database.Please try again later or inform the system administrator.Can't connect to local MySQL server through socket'/var/run/mysqld/mysqld.sock' (2)

One of the main concepts of eZ publish is that there is always a user associated with an access. If a specific user is not logged in then the special "anonymous user" is utilised. The anonymous user exists and must be retrieved from the database so that the roles that are associated with it can be access and the permissions system can determine if the user has access to the requested resource.

Warning:

User not found, returning anonymous

Warning:

Anonymous user not found, returning NoUser

Because the database is not accessible the Anonymous user cannot be retrieved so the system creates a "dummy" eZUser object (NoUser) and returns that. (This behavior can bee seen in the eZUser:instance method in kernel/classes/datatypes/ezuser/ezuser.php)

As NoUser does not exist and has no role information associated with it, not that any could be retrieved, the system responds with the access denied message.

Now I'm sure that at some point eZ Publish raised an error on database connectivity issues instead of attempting to continue. Having a poke through the source code I found kernel/error/errors.php contains:

Interestingly this constant doesn't appear anywhere else within the source. I wonder why it is no longer used?

As eZ Publish is pretty much useless when database access is not present the system should raise a specific DB error error when access cannot be established. (Of course this could be overridden for each siteaccess). At the very least this would give the site owners a better indication of where to start looking for solutions.

I've raised an issue here. I can't think of any reasons why this isn't a good idea.

Update: The Admin siteaccess does display a the following error when the DB is not accessible:kernel::50

No database connection could be made, the system might not behave properly.

In the preface to the current Admin interface specification the last paragraph caught my eye:A overview of user task need a dashboard, where she can follow here own content, approval and other tasks she might do on a regular basis.I recently saw a demo of the latest version of the bug tracking system JIRA 4.0 by Atlassian. It used an OpenSocial dashboard to allow users to customise their homepage to access and interact with information that was important to them. The system not only displays JIRA widgets but any OpenSocial widgets (and those from other Atlassian products). You can check out a video of it in action here and more information on how Atlassian is using OpenSocial here.

What is OpenSocial? From the official site:OpenSocial defines a common API for social applications across multiple websites. With standard JavaScript and HTML,
developers can create apps that access a social network's friends and update feeds. Google personal home page is an example of an OpenSocial da…

The following presentation was given on 24 July 2012 to the DevOps Brisbane group. Some of the technical detail about Vagrant is outdated but I think it provides a good overview of why moving to a "Infrastructure as code" setup makes a lot of sense.