[Rev 4201] blank page when trying to install/update database schema

[Sebastian Roth]

Thanks for the information. This definitely seams like an un-initialized DB object. I am kind of new in the Developers Team and still catching up with all the details. Didn’t know about debugging needs to be switched on to see possible errors when loading the MySQL library. Would you please edit your /var/www/html/fog/lib/fog/FOGBase.class.php (change false to true

<?php
abstract class FOGBase {
    protected $debug = true;
...

Then reload the page and see what you get.

[Tom Elliott]

@Stefan-Kaegi This isn’t possible. Are you really sure you’re updated?

I ask because you report the Rev number, but what is the version in your cloud?

[Stefan Kaegi]

That’s how I update:

cd /root/
svn checkout https://svn.code.sf.net/p/freeghost/code/trunk
cd trunk/bin/
./installfog.sh

How can I see which version my cloud has?
I updated today to Rev 4270. Seems like I have a new problem now. The Fog Installer stops at the following point:

....
 * Enabling apache and fpm services on boot....................OK
 * Creating SSL Certificate....................................OK
 * Creating auth pub key and cert..............................OK
 * Resetting SSL Permissions...................................OK
 * Setting up SSL FOG Server...................................OK
 * Restarting Apache2 for fog vhost............................OK
 * Changing permissions on apache log files....................OK
 * Backing up database.........................................Failed!

I added the line ‘protected $debug = true;’ to my FOGBase.class.php in section ‘abstract class FOGBase’
Now my Apache error log shows:

[Mon Nov 02 09:46:50 2015] [error] [client 172.30.34.61] PHP Fatal error:  Cannot redeclare FOGBase::$debug in /var/www/html/fog/lib/fog/FOGBase.class.php on line 5
[Mon Nov 02 09:46:50 2015] [error] [client 172.20.60.31] PHP Fatal error:  Cannot redeclare FOGBase::$debug in /var/www/html/fog/lib/fog/FOGBase.class.php on line 5
[Mon Nov 02 09:46:50 2015] [error] [client 172.20.60.31] PHP Fatal error:  Cannot redeclare FOGBase::$debug in /var/www/html/fog/lib/fog/FOGBase.class.php on line 5

Line 5 is where i added the line.

[Stefan Kaegi]

My changed FOGBase.class.php file:
FOGBase.class.php

[Sebastian Roth]

@Stefan-Kaegi said:

I added the line ‘protected $debug = true;’ to my FOGBase.class.php in section ‘abstract class FOGBase’

PHP is not happy if you add another variable with the same name. Just change the value from ‘false’ to ‘true’. Don’t worry about it being ‘public’ or ‘protected’. This was changed by Tom at some point. Just change its value and see what you get.

[Stefan Kaegi]

I changed FOGBase.class.php as you described. Here is my Apache Error Log as it looks now:
error.log

[Sebastian Roth]

If something goes wrong with the database connection you should be seeing this on the web interface (top left). Like this:

[Stefan Kaegi]

I don’t see anything on the webinterface. Still a blank page.

[Sebastian Roth]

I am kind of lost with this. Apache error log tells us that it cannot issue a query from a null object which means that the DB object is not properly initialized. But why don’t you see any errors from the inizialisation code?? @Tom-Elliott Any ideas?

The “Backing up database” issue should be solved as far as I know. Please update and try again. After running the installer your changes in /var/www/html/fog/lib/fog/FOGBase.class.php will be lost. You might want to enable debug again and see what you get.

[Stefan Kaegi]

I updated again to Rev 4278 . But the Installer stills stopps at ‘Backing up database’.

[Sebastian Roth]

Wohoo, didn’t pay enough attention when reading this. I had a different issue in mind but it’s unrelated (https://forums.fogproject.org/topic/5972/rev-5020-upgrade-error), sorry for that.

“Backing up database” is done via wget requesting a database export from the web interface. Sure this is not working in your case as we still haven’t tracked down the real cause of your grumpy DB connection. So you need to modify the installer script I am afraid. Open trunk/bin/installfog.sh in an editor and see if you can find this lines (should be around 440):

...
            dots "Backing up database"
            if [ -d "$backupPath/fog_web_${version}.BACKUP" ]; then
                if [ ! -d "$backupPath/fogDBbackups" ]; then
                    mkdir -p $backupPath/fogDBbackups >/dev/null 2>&1
                fi
                wget --no-check-certificate -O $backupPath/fogDBbackups/fog_sql...
            fi
            errorStat $?
...

Simply add a comment sign (#) in front of the wget command, save the file and run the installer again. I hope this time it’ll run till the end.

[Tom Elliott]

@Uncle-Frank said:

?
…

Or maybe update? I added back the db dump code and have the installer using that instead of the php native versions. This should operate as it isn’t passing the db lines into memory. I could be wrong though.

[Tom Elliott]

This doesn’t make sense. The sqldump code is not the problem. It is the Config.class.php. It’s failing to download the file because it cannot access the db, which seems to be the trend throughout this entire post.

[Stefan Kaegi]

After commenting out the wget line the installer run till the end. I didn’t need to change FOGBase.class.php after running the installer. ‘public $debug’ was still set on ‘true’. The Apache Error Log File still looks the same:

[Tue Nov 03 12:00:04 2015] [error] [client 172.20.60.23] PHP Fatal error:  Call to a member function query() on null in /var/www/html/fog/lib/fog/FOGCore.class.php on line 310
[Tue Nov 03 12:00:04 2015] [error] [client 172.30.60.49] PHP Fatal error:  Call to a member function query() on null in /var/www/html/fog/lib/fog/FOGCore.class.php on line 310
[Tue Nov 03 12:00:04 2015] [error] [client 172.20.60.56] PHP Fatal error:  Call to a member function query() on null in /var/www/html/fog/lib/fog/FOGCore.class.php on line 310

[Sebastian Roth]

@Tom-Elliott said:

This doesn’t make sense. The sqldump code is not the problem. It is the Config.class.php. It’s failing to download the file because it cannot access the db, which seems to be the trend throughout this entire post.

Good point! But why don’t we see any other error messages related to the DB connection??

[Wayne Workman]

Is there a DB password set? If so, is the installer correctly reading the password? For instance, special characters like single quotes can totally screw up the reading of the password from /opt/fog/.fogsettings.

[Tom Elliott]

@Sebastian-Roth because it is being returned as null, there isn’t anything to connect.

[Sebastian Roth]

@Tom-Elliott said:

because it is being returned as null, there isn’t anything to connect.

Sure! But why don’t we see an error when enabling debug in FOGBase class? We need to have it show errors in case the connection goes wrong. Otherwise we just don’t know… Very hard to debug this kind of stuff with users going forth and back about apache log and all that.

[Stefan Kaegi]

A mysql password ist set. Here is my .fogsettings file:
fogsettings

[Tom Elliott]

@Sebastian-Roth that’s what I mean. The reason the screen goes blank is it is attempting to use a method that is not available. Debug works if the item still has all the methods available to it. In this particular case, there is no method available to the defined item. So php is failing entirely, as it never gets to use the method as it is not available, at all.

I think maybe visibility is needed?

Let use fogbase as the example. I define all the variables using a reference rather than making a copy of the already existing object. So for all purposes of understanding I can muster.

The DB variable, which makes our connection to the DB available to the entirety of fog. If an item is called requiring the use of an object that hasn’t been instantiated, but calls a method that obviously needs instantiation first, you will get a fatal error on php.

Most of the time this is not the problem, but every once in a while weird things can happen. Only methods that are properly instantiated can access it’s relevant methods.

So DB->query(‘some query’) called before the DB variable has been givin the object it requires will cause blank screen.

I can try to test every possible case but it’s not always so simple either.