Upgraded from 1.2.0 to Trunk, broke FOG

[netman86]

It was suggested that upgrading to ‘trunk’ would solve an issue I’m having with Fog.

I followed the ‘wget’ procedure (super complex! ) here:
https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk

When it got to the section where I should browse to <host>/fog/management to set up the database, that webpage is completely blank.
Finishing the install script does nothing, the whole interface refuses to render, now.

A quick search here had me check the .fogsettings file, where I noticed my SQL password was wrong- it appears to have truncated a $2 out of the password I had used for sql root. (possibly a bug?)
fixed the password and restarted the install with the same outcome.

I then went back into .fogsettings and removed the $2 from the password field and saved- then changed the root pw to match what is in .fogsettings and re-ran the install for trunk again and am still getting a blank page, so I’m fairly certain this isn’t password related.

If I look in the apache2 error log file, when I hit the blank page for DB setup, I’m getting the following error:
PHP Fatal error: Class ‘System’ not found in /var/www/html/fog/commons/init.php on line 78

A quick search for that error came up with nothing. Suggestions welcome!

[ch3i]

Moved to Developers/Bug Reports

[Wayne Workman]

@netman86 Try updating your OS.

For Ubuntu and Debian it’s

apt-get update
apt-get upgrade

for red hat, cent os, and Fedora 21 and older it’s

yum update -y

For Fedora 22 and newer, it’s:

dnf update -y

[Tom S]

Yes that may be a bug or something Tom E needs to look into. When you use $ it stands for a variable so when it was supplied in the fogsettings file, $2 represented the variable 2 which was probably null and that is why it was truncated. The password for the db is stored in more than one place in FOG. Try {your webroot}/fog/lib/fog/config.php. This is where the installer writes it for use by PHP.

As with anytime in upgrading/updating you should make a backup of your sql files so that in case of an emergency you can always revert to where you had left. If you have not done so, please do.

So check that config file and make sure it is correct, and try and run the installer script again without using the password with the $ in it. That does make for a secure password, but can make for some other headaches down the road.

[Tom Elliott]

I’ve changed the password interpreters for .fogsettings to use single quotes vs. double quotes. Double quotes allow the expansion of variables. $2 is usually the second cli argument of a function and/or script. So if it is not set, it is most likely null. Hopefully using single quotes will correct this, though the checkers i have only work with double quotes. This is likely not a 100% fix but should operate a bit better for your needs.

[netman86]

Thanks- Caught me off guard is all, I use randomly generated passwords whenever possible so you never know what might come up

I just generated a different one that didn’t involve the $ character as a workaround on my end.

[Wayne Workman]

@netman86 said:

Thanks- Caught me off guard is all, I use randomly generated passwords whenever possible so you never know what might come up

I just generated a different one that didn’t involve the $ character as a workaround on my end.

Please do not use password generators that are online… or on applications that run on internet connected devices… how do you know that the website/app isn’t logging the passwords it generates? I would never trust it.

[Tom Elliott]

As I’m setting the password variables in .fogsettings with single quotes as opposed to double quotes, this should be resolved even with $2 or other funny symbols that may have a different meaning in bash/csh/ksh/zsh/tsh/etc… shells. Hopefully this helps. I’m just solving for now. If you see the issue again, please just let us know.