In one drupal instance I run it from debian package using dbconfig-common, thus my database access data are stored in dbconfig.php file and are fetched from settings.php via require_once function.

When trying to access Site Status and Update Sites tabs in multisite_maintenance configuration page I get this message:

Fatal error: require_once() [function.require]: Failed opening required 'dbconfig.php' (include_path='.:/usr/share/php:/usr/share/pear') in /etc/drupal/5/sites/all/modules/multisite_api/multisite_api.module(524) : eval()'d code on line 93

Everything else on the site works. I also checked the access rights to dbconfig.php - nothing wrong there.

Comments

dalin’s picture

dalin
he/him
Primary language English
Location 🇲🇽, 🇨🇦, 🌍
CreditAttribution: dalin commented

Interesting setup. Is this path to this other file relative or absolute? I would recommend trying an absolute path (ie. /foo/bar/dbconfig.php instead of ./bar/dbconfig.php )

charmer’s picture

charmer CreditAttribution: charmer commented

It is absolute because dbconfig.php and settings.php reside in the same place (i.e. root directory to a drupal site). This is a standard Debian solution to handle databases via packages, so when you install 'drupal5' package, instead of

$db_url = 'mysql://username:password@localhost/databasename'; in settings.php, there is a call 

require_once('dbconfig.php');
if (!isset($dbserver) || empty($dbserver))
        $dbserver='localhost';
$db_url = "$dbtype://$dbuser:$dbpass@$dbserver/$dbname";
$db_prefix = '';

that fetches data from dbconfig.php that looks like this:

<?php
##
## database access settings in php format
## automatically generated from /etc/dbconfig-common/drupal5.conf
## by /usr/sbin/dbconfig-generate-include
## Mon, 04 Aug 2008 17:11:18 +0200
##
## by default this file is managed via ucf, so you shouldn't have to
## worry about manual changes being silently discarded.  *however*,
## you'll probably also want to edit the configuration file mentioned
## above too.
##
$dbuser='neco_cz_admin';
$dbpass='admin';
$basepath='';
$dbname='neco_cz_db';
$dbserver='';
$dbport='';
$dbtype='mysql';

So far I haven't encountered a module that would conflict with this call, everything I use works with this setup. Maybe this is related to checking other sites' db configuration?

dalin’s picture

dalin
he/him
Primary language English
Location 🇲🇽, 🇨🇦, 🌍
CreditAttribution: dalin commented
Status: Active » Fixed

Yes that all looks pretty straightforward, but that is a relative path, not absolute. Please replace
require_once('dbconfig.php');
with something like
require_once('/home/john_doe/public_html/my_site/sites/my_site.com/dbconfig.php');
I believe that should fix it.

The problem being that
sites/some_other_site_that_is_not_the_current_site/
is not seen by php and so neither is your dbconfig file.

charmer’s picture

charmer CreditAttribution: charmer commented
Status: Fixed » Active

Well,

You're right, it was not absolute path, but why does it work when multisite_maintenance fetches db access data from settings.php that is also in sites/some_other_site_that_is_not_the_current_site/ ?

When I changed the path to absolute (which already is more of an inevitable workaround than a fix) at _ALL_ test sites on the server, then yes, the fatal error in question disappeared.

But, it seems that multisite_maintenance still can't parse db_url from dbconfig.php so as a result I only see ://:@localhost/ in Site Status tab, thus no DB is reachable and I can't use any functionality the module provides.

So my question is - would it be worth your time support this kind db access setup in your module's code?
If not, would you be willing to give me some pointers as to what changes in what functions would be necessary to better detect dbconfig.php and correctly recognize the access to databases set up by this file?

Thanks in advance

dalin’s picture

dalin
he/him
Primary language English
Location 🇲🇽, 🇨🇦, 🌍
CreditAttribution: dalin commented
Project: Multisite Maintenance » Multisite API
Version: 5.x-1.x-dev » 5.x-2.0

Hmmm,
$db_url is built by reading settings.php into an array, remove any ini_set statements, implode the array, and then evaluate it. Perhaps eval() can't handle includes?

This all happens in _multisite_api_eval_file()

Patches welcome.

Routh’s picture

Routh CreditAttribution: Routh commented
Assigned: Unassigned » Routh
Status: Active » Needs review

I have just taken over development of this module. I will be reviewing this issue and looking to patch the code to repair. I am tagging this so that all followers know I have acknowledged the problem.