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

[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.

[Sebastian Roth]

@Tom-Elliott You know the code a lot better than I do! And I am sure you are right about it failing (blank page) if query is called before DB object being properly initialized. But that’s my point. It should be initialized before and it usually does in most cases. But if it does not, it would be awesome so see an error message straight away. Not sure if it’s possible but we might be able to add a kind of fail-proof check right after initializing and dump an error message in case something went wrong (driver not installed, whatever).

[Sebastian Roth]

Re-reading the thread I saw this…

@Stefan-Kaegi said:

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’.

Are you sure the installer propagated the web interface files properly? Could you please post the output of the following commands:

ls -al /var/www
...
ls -al /var/www/html
...
ls -al /var/www/html/fog
...

[Tom Elliott]

@Sebastian-Roth I think where the issue resides in this is I do display an error. But if the files are not calling properly, or not the right files for the version, things like this would occur and I have no way to specify these as issues as things are happening in a totally unpredictable fashion.

[Stefan Kaegi]

root@FOGAGH01:~# ls -al /var/www/
total 28
drwxr-xr-x  6 www-data www-data 4096 Nov  4 09:11 .
drwxr-xr-x 12 root     root     4096 May 12  2014 ..
drwxr-xr-x 10 www-data www-data 4096 Nov  4 09:11 fog
drwxr-xr-x 10 root     root     4096 Oct 22 10:16 fog.backup
drwxr-xr-x 11 www-data www-data 4096 Jul  8 08:45 fog.prev
drwxr-xr-x  3 www-data www-data 4096 Jul 16 09:59 html
-rw-r--r--  1 www-data www-data   43 Jul 16 15:47 index.php

root@FOGAGH01:~# ls -al /var/www/html/
total 12
drwxr-xr-x  3 www-data www-data 4096 Jul 16 09:59 .
drwxr-xr-x  6 www-data www-data 4096 Nov  4 09:11 ..
drwxr-xr-x 11 www-data www-data 4096 Jul 16 09:59 fog

root@FOGAGH01:~# ls -al /var/www/html/fog/
total 52
drwxr-xr-x 11 www-data www-data 4096 Jul 16 09:59 .
drwxr-xr-x  3 www-data www-data 4096 Jul 16 09:59 ..
drwxr-xr-x  3 www-data www-data 4096 Jul 16 10:00 client
drwxr-xr-x  3 www-data www-data 4096 Jul 16 09:59 commons
-rw-r--r--  1 www-data www-data 1406 Jul 16 09:59 favicon.ico
drwxr-xr-x  3 www-data www-data 4096 Jul 16 09:59 fogdoc
-rw-r--r--  1 www-data www-data  278 Jul 16 09:59 index.php
drwxr-xr-x  9 www-data www-data 4096 Jul 16 09:59 lib
drwxr-xr-x 10 www-data www-data 4096 Jul 16 09:59 management
drwxr-xr-x  4 www-data www-data 4096 Jul 16 09:59 mobile
drwxr-xr-x  4 www-data www-data 4096 Jul 16 09:59 service
drwxr-xr-x  3 www-data www-data 4096 Jul 16 09:59 status
drwxr-xr-x  3 www-data www-data 4096 Jul 16 09:59 wol

[Sebastian Roth]

Thanks for posting this. Please check your apache DocumentRoot setting: grep DocumentRoot /etc/apache2/*/*

Seams a bit like thinks got mixed up. See the timestamps of /var/www/html/fog… It’s Jul 16. From the error messages we saw in the apache error log this is the one being currently used and probably what you will see when grepping for DocumentRoot. But the newest date (Nov 4) is /var/www/fog. And I guess this directory is from a newer trunk install but is not being used.

If I remember right Ubuntu changed from /var/www to /var/www/html not that long ago. Tom changed the installer to reflect this and maybe it ran into some condition on your system to also change this at some point.

My advice:

• Backup all the stuff in /var/www by moving it (mv /var/www /var/www.bak && mkdir /var/www && chown www-data:www-data /var/www)
• Update FOG to latest trunk (cd path/to/trunk && svn up)
• Comment the wget command in the installer script as done before
• Run the installer
• Check DocumentRoot setting (see above) and compare with what you see in /var/www

I really hope this will get us one step further. I am very sorry that it took us so long to find out about those different fog directories in /var/www…

[Stefan Kaegi]

Seems like moving /var/www did the trick. After rerunning the installer I finally could update the database schema. And I can also access the webinterface again. I can even run the installer now with the wget command.
Thanks everybody for your patient and your help.
Stefan

[Sebastian Roth]

@Stefan-Kaegi Thanks a lot for reporting back so quickly and for being patient & willing to try out things! What an odyssey. I hope this thread might help others too.