Activity dashboard

[theWizard]

@Tom-Elliott
Dashboard is back and working ok, picture i posted is still relevant tho not sure why it says no data returned.

[Tom Elliott]

@theWizard Could be two reasons.

Node’s aren’t updated to the latest (a bit changed in how we get data).

Node’s cannot communicate to the DB (unlikely if they worked in the past).

That’s about it.

[theWizard]

@Tom-Elliott
Two nodes are the same rc version as server the rest are not, yep they worked fine previously.

[Tom Elliott]

@theWizard Please try updating all nodes to the most recent version?

[Tom Elliott]

This is what I’m seeing just so people don’t think I’m crazy. Both of my nodes (as well as the GUI server) are on the same version. This was the case for RC-20 since first through the latest released and is also the case for what I’m working on currently (working-RC-21).

[Tom Elliott]

Oh and my nodes (the two you see there) ARE on the latest RC-20. – SVN 6011.

[Tom Elliott]

For the RC-21 I’ve added the schema updates to enable the ability for the user to select what an appropriate timeout value can be.

There’s now three settings.

FOG_URL_AVAILABLE_TIMEOUT. This is a definition set in milliseconds (thousandths of a second). This is the timeout to wait to see if a URL is available or not. The reason milliseconds is used here is because it should not take an incredibly long time to get a response, unless your network is extremely bogged down. It is defaulted to 500ms.

FOG_URL_BASE_CONNECT_TIMEOUT. This is the definition set in seconds. This is the connection timeout for “regular” checks. It could use the “Available_timeout” as well, but for more clarity I have set this to a “seconds” based with a default of 15. This just ensures we have the link and can establish the startup of the item it’s to process.

FOG_URL_BASE_TIMEOUT. This is the definition set in seconds. This is the actual timeout of the link doing stuff. Because of it’s methodology, it has a much longer value. It is defaulted to 86400 seconds or the equivalent of 1 day.

[theWizard]

@Tom-Elliott
Ijust updated server and all nodes to latest RC21 6014 but still nothing.

[Tom Elliott]

@theWizard Mind running a few tests to see why those nodes are seeing “A valid database connection could not be made”?

On the main server (the one that gives you the GUI without issue):
Can you ensure the bind-address is commented in the /etc/mysql/my.cnf (or whatever file it is)?

To find the file run:

sudo -i #enter password for user when prompted.
cd /etc/mysql
grep -rl 'bind-address' .

The grep command will show you any file that contains the phrase. Open any/all of them and search for bind-address. If the line it’s running on is started with a # or it shows up before the bind-address text it is already commented. If it’s not commented already add the # to the start of the line, save the file and restart the mysql service.

Please also check ufw is disabled with ufw disable. (For now it’s simplest to just start with that. If you want to enable UFW protections let us know and we can try to give you the ports you need to allow. (I doubt it’s related to UFW because you’d probably be having a hard time connecting to the GUI to begin with.)

One the nodes (one at a time of course).

Validate the /var/www/fog is a symlink to /var/www/html/fog by running:
ls -lh /var/www/
If it is a link already it will probably display something along the lines of:

lrwxrwxrwx 1 root root    18 Jul    8 15:30 fog -> /var/www/html/fog

If it doesn’t have the -> displayed, it will likely look as:

drwxr-xr-x 1 root root    18 Jul 4.0k 15:30 fog

If it doesn’t have the link, please run:

(You may want to run the same checks above on the main server too.)

# Removes the fog gui folders.
rm -rf /var/www/{html/,}fog

# Ensures we don't copy older files back accidentally.
rm -rf /home/*.BACKUP

Rerun the installer and things should cleanup a bit better.

[theWizard]

@Tom-Elliott
Thanks followed your instructions, the directory was not symlinked on server but even after and checking again i still have same results nothing has changed.

[Tom Elliott]

@theWizard From the nodes, can you open the /opt/fog/.fogsettings file.

Get the snmysqluser and snmysqlpass (I’m guessing they’re set to fogstorage?) variables.

From a terminal on one (or all of the nodes if you’d like) run:

mysql -u'<snmysqluser>' -p'<snmysqlpass>' -h'fogserver' fog

It should connect, if it doesn’t then we need to see why.

[theWizard]

@Tom-Elliott
Your on to something i get access denied

[theWizard]

@theWizard
Ok for some strange reason the user that was setup in mysql for the nodes to connect to the database has gone without a trace so makes sense they were not able to connect, i added the user back in using workbench and all seems to be ok again.

@Tom-Elliott Thank you for your patience and suggestions getting me on the right track, you can mark this one as a non issue.

[Tom Elliott]

So all is working properly after checking those things and making the correct changes where required?

[theWizard]

@Tom-Elliott
Yep i ran through your instructions and made any relevant changes but the thing that fixed it was adding the user back to mysql, not sure why it disappeared though.