FOGImagereplicator not working
-
@Tom-Elliott said in FOGImagereplicator not working:
@Neil-Underwood Please give this a shot:
sudo -i service FOGImageReplicator stop service FOGSnapinReplicator stop service FOGMulticastManager stop service FOGPingHosts stop service FOGScheduler stop sleep 10 service FOGImageReplicator starts service FOGSnapinReplicator start service FOGMulticastManager start service FOGPingHosts start service FOGScheduler start
Ubuntu is realy strange. If there’s a pid file, but the process died, it will fail to allow the next item to startup (at least not properly). Restart appears to make it not remove the lock, at least in my experiences.
Also, if you’re running from a GUI 14.04, make sure when you go into sudo on the terminal, you first jump up to root with
sudo -i
. The normal terminal window (even if you are logged in to the Ubuntu system as root) will not source all the paths as needed. This is what I’ve seen, of course I have been wrong.#wiki worthy
-
@Tom-Elliott said in FOGImagereplicator not working:
@Neil-Underwood Please give this a shot:
sudo -i service FOGImageReplicator stop service FOGSnapinReplicator stop service FOGMulticastManager stop service FOGPingHosts stop service FOGScheduler stop sleep 10 service FOGImageReplicator starts service FOGSnapinReplicator start service FOGMulticastManager start service FOGPingHosts start service FOGScheduler start
Ubuntu is realy strange. If there’s a pid file, but the process died, it will fail to allow the next item to startup (at least not properly). Restart appears to make it not remove the lock, at least in my experiences.
Also, if you’re running from a GUI 14.04, make sure when you go into sudo on the terminal, you first jump up to root with
sudo -i
. The normal terminal window (even if you are logged in to the Ubuntu system as root) will not source all the paths as needed. This is what I’ve seen, of course I have been wrong.I tried this with no success. Did it twice to make sure. The first time I stopped FOGImageReplicator and FOGSnapinReplicator they both complained about no existing process, but agreed to close anyway. The second time I did it they did not complain but the outcome was the same.
Looking more closely at all my log files, I see that only servicemaster.log is current. Everything else hasn’t changed since March/April. Looking at multicast.log I see something that looks very wrong:
[04-04-16 9:08:19 am] * No tasks found! [04-04-16 9:08:29 am] * No tasks found! [04-04-16 9:08:39 am] * No tasks found! [04-04-16 9:08:49 am] * No tasks found! [04-04-16 9:08:59 am] * No tasks found! [04-04-16 9:09:09 am] * No tasks found! [04-04-16 9:09:19 am] | This is not the master node [04-04-16 9:09:29 am] | This is not the master node [04-04-16 9:09:39 am] | This is not the master node [04-04-16 9:09:49 am] | This is not the master node [04-04-16 9:09:59 am] | This is not the master node [04-04-16 9:10:09 am] | This is not the master node [04-04-16 9:10:19 am] | This is not the master node [04-04-16 9:10:29 am] | This is not the master node [04-04-16 9:10:39 am] | This is not the master node [04-04-16 9:10:49 am] | This is not the master node [04-04-16 9:10:59 am] | This is not the master node [04-04-16 9:11:09 am] | This is not the master node [04-04-16 9:11:19 am] | This is not the master node [04-04-16 9:11:29 am] | This is not the master node [04-04-16 9:11:39 am] | This is not the master node [04-04-16 9:11:49 am] | This is not the master node [04-04-16 9:11:59 am] | This is not the master node [04-04-16 9:12:09 am] | This is not the master node [04-04-16 9:12:19 am] | This is not the master node [04-04-16 9:12:29 am] | This is not the master node [04-04-16 9:12:39 am] | This is not the master node [04-04-16 9:12:49 am] | This is not the master node
Not sure how this box lost master node status. It’s never been changed. That is a bit worrisome though. I feel like there are multiple issues with this setup.
-
Here’s another side-effect of whatever is ailing my server here:
All of the nodes now show (#!db) instead of whatever it’s supposed to show (version number I think?)
Could it be a corrupt database that’s causing all of this? -
Looking at that picture, this issue is possibly related: https://forums.fogproject.org/topic/7825/db/17
-
@Wayne-Workman said in FOGImagereplicator not working:
Looking at that picture, this issue is possibly related: https://forums.fogproject.org/topic/7825/db/17
You know, that prompted me to look at class.config.php and I think the DATABASE_HOST value is wrong, but I really don’t know. Can you verify this is correct? Should the “p:” be in there proceeding the IP address?
define('DATABASE_HOST','p:127.0.0.1');
I tried changing it and removing the “p:” and nothing seemed to change (after restarting php, mysql & apache just to be sure)
-
@Neil-Underwood so, for the main server that hosts the DB, that is correct. For all nodes, it is wrong.
-
OK, so now I’m seeing that I can’t connect to the master storage node DB from the remote storage nodes. I know as much about SQL commands and permissions as my left shoe. How do I fix this? And how in the heck did it break in the first place?
-
@Neil-Underwood said in FOGImagereplicator not working:
w do I fix this? And how in the heck did it break in the first place?
Probably the server is only allowing local connections. There’s stuff about that in here:
https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_MySQL“Enable Remote MySQL Access”
-
@Wayne-Workman said in FOGImagereplicator not working:
@Neil-Underwood said in FOGImagereplicator not working:
w do I fix this? And how in the heck did it break in the first place?
Probably the server is only allowing local connections. There’s stuff about that in here:
https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_MySQL“Enable Remote MySQL Access”
I must have overlooked the part about remote access because I visited this page earlier this morning. I fixed the remote permissions and now everything is able to see the DB. Thanks for that. I did do an OS upgrade that probably changed mysql versions. I’m betting that’s what screwed it up.
The mystery of where my log info is going still remains, however.
Also, on the dashboard the replicator appears to be working, based on the graph. But running jnettop from the master storage node doesn’t show any replication activity. If I can get my logs working again I’m certain I can figure out what the problem is.
-
@Neil-Underwood sometimes it takes a hot second for replication to kick in, even if the log says it’s going. Just be patient. Tomorrow morning you’ll be able to tell if everything is right or not.
Also, the logs might be fixed by re-running the installer on all the nodes, since it can now actually communicate with the DB.
-
OK so I’m updated to 8215 now and everything seems to be able to see each other. It looks like the main server is pushing our the smartinstaller.exe to all the clients and that’s the activity I’ve been seeing on the graph. Hard to catch that using jnettop at first.
Thanks for all the assistance with this. I’ll open a separate thread for the log issue and another for the bzImage problem.
One more quick question though. What are these values used for?
startrange='192.168.19.10' endrange='192.168.19.254'
-
@Neil-Underwood DHCP Server if FOG is to be the dhcp server.
It defines the start and end range of DHCP.
-
@Tom-Elliott said in FOGImagereplicator not working:
@Neil-Underwood DHCP Server if FOG is to be the dhcp server.
It defines the start and end range of DHCP.
Got it. So this does not apply to my setup then. Must have been defined a long time ago when I was playing with that. Thanks!