Unable to use log viewer from interface

[Hanz]

When I try to load the “Log Viewer” page, I’m greeted with a “There are no enabled storage nodes for this group” page.

Apache error log is insanely large as I’m getting:

[Thu Oct 15 18:49:51.394280 2015] [:error] [pid 1043] [client 10.73.98.207:50720] PHP Warning: mysqli::query(): Couldn’t fetch mysqli in /var/www/html/fog/lib/db/MySQL.class.php on line 64.

for just about every host it looks like (I’ve got close to 600 so far).

[Hanz]

Just curious if these sizes are normal. My error log fileis at around 250MB, while the access file is almost 700MB

[Wayne Workman]

@Hanz You can delete those.

You could even script a cron-tab event to blast those every day or week.

But those logs are really large, yes. Others are getting the exact same errors, look around in @Joseph-Hales thread here: https://forums.fogproject.org/topic/5925/after-update-to-svn-4928-web-pages-time-out-constantly

[Hanz]

Would this be considered a web timeout when it actually loads a page that states No storage nodes available in this group ?

[Tom Elliott]

What?

Can you please update?

[Hanz]

I’m currently running 4980

[Hanz]

This may be related but I have a new storage node named “travel” that is showing

FOG Configuration
FOG Version Information
Version: 4980

Fog-Server
Your verson of FOG is up to date.
Kernel Versions
Travel
MySQL does not appear to be running
Wharton
bzImage Version: 4.2.3
bzImage32 Version: 4.2.3
Ramage
bzImage Version: 4.2.3
bzImage32 Version: 4.2.3
VanElem
bzImage Version: 4.2.3
bzImage32 Version: 4.2.3

The "MYSQL does not appear to be running on the main page under “disk information” drop-down too.

[Hanz]

Wayne had me try to connect to mysql from new node manually with

mysql -u fogstorage -h 10.72.3.50 -p fs9694191133
it prompts for another password when I enter the above fs********** I get this error

ERROR 1045 (28000): Access denied for user 'fogstorage;@‘10.72.2.16’ (using password:YES)

if I try it with No password and just hit enter I get the same error, but (using password:NO)

[Hanz]

I updated another node to the 4980 from 4972 and the same " MYSQL does not appear to be running" issue

[Hanz]

Images and snapins are however being replicated correctly.

[Tom Elliott]

Based on the information you’re showing me here, the fogstorage password is not correct.

You may have to reset the mysql fogstorage user’s password as this seems to be your issue for right now.

[Hanz]

unfortunately the two nodes running 4972 are working correctly…The password is the same in all locations, so I don’t believe that is the issue.

[LJedi]

I am also seeing this issue too running version 4980. This was working before upgrading.

[Tom Elliott]

@Hanz said:

Wayne had me try to connect to mysql from new node manually with

mysql -u fogstorage -h 10.72.3.50 -p fs9694191133
it prompts for another password when I enter the above fs********** I get this error

ERROR 1045 (28000): Access denied for user 'fogstorage;@‘10.72.2.16’ (using password:YES)

if I try it with No password and just hit enter I get the same error, but (using password:NO)

This ?

[Hanz]

I would like to add that although the other two nodes (that are still running 4972) don’t have the MYSQL error on Main Page, but also can’t connect manually to db.

[Wayne Workman]

@Tom-Elliott I had him try your idea.

I can’t find the post… but,

You suggested installing FOG in normal mode on all storage nodes, and then editing /opt/fog/.fogsettings to point to the real master’s DB (mysql host, username, and password). I also instructed him to enable remote access to MySQL. He did these things, and it worked on all of his nodes except for one… and this one node was the one that had pre-existing problems as well.

[Sebastian Roth]

Is this issue solved?

[Hanz]

@Uncle-Frank No the problem is still present, and I the apache error log is throwing in lin 29 of /var/www/html/fog/lib/db/MySQL.class.php…which mentions the DATABASE_HOST, USERNAME ,AND PASSWORD…

The nodes that are working correctly as far as the main page not saying “MYSQL server not currently running” in place of the kernel ver.,
ERROR 1045 (28000): Access denied for user ‘fogstorage’@‘10.72.208.55’ (using password: NO) when trying to connect manually to db.
This is error msg. for two stating that “MYSQL server not currently running”
ERROR 2003 (HY000): Can’t connect to MySQL server on ‘10.7.3.50’ (113 “No route to host”)

They two nodes not working correctly are also missing the connection type= “MYSQL_ASYNC” line in /opt/fog/.fogsettings and line can’t be manually added, installer overwrites somehow.

[Sebastian Roth]

@Hanz said:

ERROR 2003 (HY000): Can’t connect to MySQL server on ‘10.7.3.50’ (113 “No route to host”)

Maybe this is just a typo but the IP address is quiet different to all the others you mentioned here in this thread so far (10.7. instead of 10.72.). This could explain the “No route to host” error.

ERROR 1045 (28000): Access denied for user ‘fogstorage’@‘10.72.208.55’ (using password: NO)

Are you sure about using an empty or no password here? Make sure the login credentials are correct in /var/www/html/fog/lib/fog/Config.class.php

They two nodes not working correctly are also missing the connection type= “MYSQL_ASYNC” line in /opt/fog/.fogsettings and line can’t be manually added, installer overwrites somehow.

This file is only used/written by the installer script. FOG itself uses the above mentioned Config.class.php when connecting to the database. The MYSQLI_ASYNC setting missing on those two nodes might mean that the version checked out is older?? Edit: According to what Tom said the ASYNC stuff might be missing in a newer version. Please check to see if you are running different versions (it’s not a real problem I think - but it would explain the missing setting):

cd /path/to/fog/trunk
svn info
...
Revision: xxxx
....

[Tom Elliott]

@Uncle-Frank I actually removed the async code as it was rather pointless to have. This is why those lines of code are removed. I’ve switched from async query to a prepare/execute/get_result.

I removed the async code for a few reasons.

1. It only ever operated on a single MySQL instance. Essentially there was absolutely no point in using async as we always had to wait for the single sql call to return data anyway.

2. Potential timing issues. Basically, it helps limit potential for a 0 id to return in that by the time the data was inserted it wouldn’t have been able to receive the id that was inserted this leaving it as 0 while in reality it just hadn’t returned by the time the insert code was referenced.

3. Prepared statements, while not currently setup properly, limit potential of sql injection attempts. While I am sanitizing input and output a great deal even without prepared statements, I think it helps better reduce the potential in case I missed something earlier in the scripts.