Storage Node: Database Connection Unavailable

[Wayne Workman]

@atessin Great job triaging the issue, it’s good to see that. Are you aware that the storage nodes do not have a web UI for administration? All the things done with storage nodes use the master server’s web interface.

Does the storage node actually image? Does it work?

Have you tried this link on the storage node? What does it say?
http://node_ip/fog/service/getversion.php

[atessin]

@Wayne-Workman I wasn’t aware that there is not an interface for the storage node, but that does make sense.

I have not yet tried imaging to see if it’s working yet, but I can test that today.

I did try the getversion.php for the storage node and it returns “A valid database connection could not be made"1.5.5”. That is the same data that is displayed for the storage node under Fog Configuration > Kernel Versions on the primary server.

[Sebastian Roth]

@atessin said in Storage Node: Database Connection Unavailable:

I can manually connect to the database from the storage node using the mysql cli and the credentials found in the config.class.php file

Sorry to say this but if you can connect from storage node to the master node using the mysql cli and settings from config.class.php then the storage node should also be able to connect through PHP. Have you used the fogstorage user for testing? Double check the information in the config again.

[atessin]

@Sebastian-Roth Yes, I have used the fogstorage mysql user for all testing. I’ve checked those configs several times. Below are screenshots showing the configs and results:

Storage Node config.class.php:

Storage Node CLI mysql connect:

Primary FOG (FOG Configuration > Kernel Versions):

[Sebastian Roth]

@atessin Ok you are right here! Can we do a remote session to try and find out what’s wrong. I’d suggest using tcpdump to see what exactly is going on but it’s not easy to explain all that here in the forums. See the chat bubble…

[Sebastian Roth]

Turns out SELinux was enabled on the storage node and therefore it didn’t want to do the connection. This reminds me that we should add more detailed error output on DB errors. Would have been easy if it would just display the SQLSTATE[HY000] [2002] Permission denied it was running into.

[george1421]

@Sebastian-Roth As part of the installer execution path, shouldn’t we check to see if selinux is currently enabled on the FOG server?

I’m not a bash programmer but this seems to give me the answer if selinux is enabled or not under Centos 7.5 .

sestatus|grep -e "SELinux status"| awk '{print $3}'

At least if the installer can trap the incorrect setting, alert the installer and then abort the install until its fixed that would eliminate the follow on problems.

[Wayne Workman]

@george1421 IMHO, if SELinux is set to enforcing, I think the installer should set it to permissive mode and just inform the user of this. When somebody comes up with a working SELinux policy, then that can change.

[Jeffrey Boulais]

I’m having the same issue as is show in atessin’s screenshot of the “FOG Configuration” screen, but SELinux doesn’t appear to be my issue. I’ve run the 'sestatus|grep -e “SELinux status”| awk ‘{print $3}’ and it returned “disabled”.

[Sebastian Roth]

@Jeffrey-Boulais Well than probably the database credentials are not correct. Check /var/www/html/fog/lib/fog/config.class.php for the DB credentials and then try using those to connect with the command line client: mysql -u root -p

[Sebastian Roth]

@george1421 @Wayne-Workman I just pushed a change to check for SELinux and firewall, inform the user and ask if it should be disabled. Hope we won’t see those issues anymore. Or at least then we can say… told you so.

[Wayne Workman]

@Sebastian-Roth Will the installer’s -y switch ‘just do it’ ? The automated tests depend on this option.

EDIT: Nevermind, I see you have it taken care of.

[george1421]

@Sebastian-Roth Well done. If we can filter these issue out at the beginning it will make support easier trying to figure out why this isn’t working…

[Tom Elliott]

@george1421, @Sebastian-Roth the only thing I foresee and maybe missed. Selinux won’t automatically be disabled because you made the change to the config file, it would require a reboot of the machine first. I would also, suggest changing from disabled to permissive. Disabling forces the file system to be unsupported and require being reestablished should you turn selinux back on. Placing into permissive mode keeps the file system contexts active and does not hinder usage. Plus you enter the command setenforcing 0 to switch selinux into permissive mode for the current running session which doesn’t require immediate reboot.

DERP — Don’t mind me, I’m dumb. Looked again and see you do have it set to permissive and do run the setenforce command.