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



  • Hi,

    I updated my Debian wheezy system via ‘apt-get update && apt-ger upgrade’. After that I also updated to the new subversion (4201) of fog.
    When I run ‘./installfog.sh’ everything looks ok. But when I try to update the database schema via ‘http://172.30.40.25/fog/management’ I only see a blank page. I tried to skip the database update and finish the installation. But all i can see now when going to ‘http://172.30.40.25/fog’ or ‘http://172.30.40.25/fog/management’ is a blank page. Hard refreshing the page didn’t help.

    Debian GNU/Linux 7.9 (wheezy)
    fog svn 4201

    Thanks for your help.
    Stefan



  • @Sebastian-Roth said:

    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…

    This worked for me! I had very similar issues!

    Thanks!!


  • Developer

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



  • 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


  • Developer

    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…



  • 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
    

  • Senior Developer

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


  • Developer

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

  • Developer

    @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).


  • Senior Developer

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



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


  • Developer

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


  • Senior Developer

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


  • Moderator

    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.


  • Developer

    @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??



  • 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
    

  • Senior Developer

    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.


  • Senior Developer

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


  • Developer

    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.



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


Log in to reply
 

396
Online

39.3k
Users

11.0k
Topics

104.6k
Posts

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.