Forums / Install & configuration / Broken site - mysql authentication failed?

Broken site - mysql authentication failed?

Next topic

Author	Message
Cefn Hoile	Thursday 22 September 2005 3:53:20 am A colleague just pointed out that the site at http://that.labs.bt.com has broken. It has been running for some time, but now I get Fatal error: Call to a member function on a non-object in /var/www/html/that.labs.bt.com/ezpublish/kernel/common/eztreemenuoperator.php on line 180 Fatal error: eZ publish did not finish its request I think this may be because the username and password that the scripts were using to access the mysql database could have been revoked or changed. Therefore any data requests are coming back empty, when they shouldn't. How can I set the correct database config in ezpublish? How can I verify that ezpublish has the correct database config? I think this was originally configured by an interactive install, and since the index page won't load, I'm not sure now where to set this right. When I try to run the cron jobs I get this... /usr/local/php-cli/bin/php -C runcronjobs.php Error initializing script: database error: Access denied for user: 'root@localhost' (Using password: YES). ...as if the username and password stored in settings/site.ini is not being accessed. I have verified the username, password and database name which are stored in the site.ini file by interactive login to mysql. If there's a better approach - for example to just install the latest version over the current one (3.5.1) then I'll consider that too. But I suspect this could make things worse still if the current one is not properly configured.
Cefn Hoile	Thursday 22 September 2005 7:55:49 am OK, I couldn't work out how to do it manually, but went through the following procedure which worked OK in the end. index.php will take you through a setup sequence if you change CheckValidity in settings/override/site.ini.append to true. This will then recreate the original interactive setup session when you next visit index.php and this sesson will prompt you for mysql mail and admin account information. To get the site to function again I had to choose the same templating settings (in my case the 'forum' template), and this process then ended up writing mysql username and password information into settings/siteaccess/forum and settings/siteaccess/forum_admin in files called site.ini.append.php I suppose this was where the original values were, and could potentially have been edited, but I couldn't find that at the time - assumed it would be in some sitewide config. One key thing to remember is to choose not to add any capabilities when you configure it, and to ask it to preserve data without adding any.

Author

Message

Thursday 22 September 2005 3:53:20 am

A colleague just pointed out that the site at http://that.labs.bt.com has broken. It has been running for some time, but now I get

Fatal error: Call to a member function on a non-object in /var/www/html/that.labs.bt.com/ezpublish/kernel/common/eztreemenuoperator.php on line 180
Fatal error: eZ publish did not finish its request

I think this may be because the username and password that the scripts were using to access the mysql database could have been revoked or changed. Therefore any data requests are coming back empty, when they shouldn't.

How can I set the correct database config in ezpublish?

How can I verify that ezpublish has the correct database config?

I think this was originally configured by an interactive install, and since the index page won't load, I'm not sure now where to set this right.

When I try to run the cron jobs I get this...

/usr/local/php-cli/bin/php -C runcronjobs.php
Error initializing script: database error: Access denied for user: 'root@localhost' (Using password: YES).

...as if the username and password stored in settings/site.ini is not being accessed. I have verified the username, password and database name which are stored in the site.ini file by interactive login to mysql.

If there's a better approach - for example to just install the latest version over the current one (3.5.1) then I'll consider that too. But I suspect this could make things worse still if the current one is not properly configured.

Cefn Hoile

Thursday 22 September 2005 7:55:49 am

OK, I couldn't work out how to do it manually, but went through the following procedure which worked OK in the end.

index.php will take you through a setup sequence if you change CheckValidity in settings/override/site.ini.append to true.

This will then recreate the original interactive setup session when you next visit index.php and this sesson will prompt you for mysql mail and admin account information.

To get the site to function again I had to choose the same templating settings (in my case the 'forum' template), and this process then ended up writing mysql username and password information into settings/siteaccess/forum and settings/siteaccess/forum_admin
in files called site.ini.append.php

I suppose this was where the original values were, and could potentially have been edited, but I couldn't find that at the time - assumed it would be in some sitewide config.

One key thing to remember is to choose not to add any capabilities when you configure it, and to ask it to preserve data without adding any.