RC10 Broken Items on upgrade

[adukes40]

@Tom-Elliott I have no tasks currently. I cant do all machine, but I can take a machine and push all snapins to it, or at least attempt to.

[Tom Elliott]

@adukes40 to clean up bad tasks then just run mysql command like:

update tasks set taskStateID=5 where taskStateID < 4;
Truncate table snapinJobs;
Truncate table snapinTasks;

Then the dashboard should look better I hope.

[Tom Elliott]

@adukes40 yes one machine all snapins would be best.

[adukes40]

@Tom-Elliott mysql> update tasks set taskStateID=5 where taskStateID < 4;
Query OK, 0 rows affected (0.00 sec)
Rows matched: 0 Changed: 0 Warnings: 0

mysql> Truncate table snapinJobs;
Query OK, 0 rows affected (0.04 sec)

mysql> Truncate table snapinTasks;
Query OK, 0 rows affected (0.08 sec)

But still shows 476 on dashboard

[Tom Elliott]

@adukes40 Can you change the < 4 to =3?

[adukes40]

@Tom-Elliott mysql> update tasks set taskStateID=5 where taskStateID=3;
Query OK, 0 rows affected (0.00 sec)
Rows matched: 0 Changed: 0 Warnings: 0

Still same.

[Wayne Workman]

@adukes40 So back to this client updating thing - I want you to try something.

Remote into an affected computer. Sync the time on that computer with an NTP server - so it’s as accurate as it can be. Enable client updating on the server, and on the host, open services and restart the FOGService. See if it updates or not. If it’s a failure with the same error, go ahead and turn off client updating on the server again - and post the log from that host please so we can see if there was anything different.

[adukes40]

@Wayne-Workman My only concern with that is, I go to turn on the auto updating, and the NIC get hammered like last time. there is no getting back in to turn it off, until 6pm, when the student machines shutdown and takes the strain off the NIC and lets the GUI load. Then I would have to shut the NIC off. I wanted to leave that on to work on this Hashing issue with snapins. Later I can work on the client stuff.

[Wayne Workman]

@adukes40 Ok then, we can put it off till later. But - it may be fair to say that with the latest client you may not have snapin issues.

[adukes40]

@Wayne-Workman The Master image still has 11.2 on it, I have tried manually installing 11.5 on the machines as well. doesn’t seem to matter. just complains about the hash not existing. and of course it does not in the snapin mgmt. I have tried imaging and having it auto run, deploying it as a single snapin, or assigning all snapins to it and telling it to deploy.

And the machines I’m testing with, is within a second of the server time. All machine near me all say 11:14 as does the server. OO and just noticed the file size in snapin mgmt shows 0.00, as someone in another thread mentioned.

[Tom Elliott]

@adukes40 Is snapin replication enabled and working?

[adukes40]

@Tom-Elliott What is this setting:

FOG_SNAPIN_LOCATION_SEND_ENABLED It is not checked on my end

also the snapin replicator says

[09-16-16 9:20:44 am] | I am the only member

[adukes40]

OK, in the other snapin hash thread, he checked on the hash value of the snapin on different nodes. I just tried the same. Running the sha512sum command on the snapin on the master returns a value. However, on the node the ps1 file no longer exists. I deleted this snapin all together from FOG. I re-added it. So what happened was, it removed it from the master and all nodes, but is not replicating out the newly made one. I checked on two nodes, not there. Restarted the FOGSnapinReplicator on the Master, and still do not see it on the nodes.

Hope this helps some

Also the individual node snapin replicator log, shows up with looks like replicated snapins, but on the node I am part of just shows a bunch of code.

set ftp:sync-mode/sunsolve.sun.com on
set net:max-retries 10
set net:timeout 30
set xfer:max-redirections 10
set xfer:verify-command /usr/share/lftp/verify-file
set cmd:prompt "lftp \S\? \u\@\h:\w> "
set cmd:term-status/rxvt “\e[11;0]\e]2;\T\007\e[11]”
set cmd:term-status/screen \e_\T\e\
set cmd:term-status/xterm “\e[11;0]\e]2;\T\007\e[11]”
set dns:order “inet6 inet”
set file:charset ANSI_X3.4-1968
set ftp:auto-sync-mode “icrosoft FTP Service|MadGoat|MikroTik”
set ftp:list-options -a
set ftp:sync-mode/ftp.idsoftware.com on
set ftp:sync-mode/ftp.microsoft.com on
set ftp:sync-mode/sunsolve.sun.com on
set net:max-retries 10
set net:timeout 30
set xfer:max-redirections 10
set xfer:verify-command /usr/share/lftp/verify-file

[Tom Elliott]

The client issues aside, we figured out the issue with snapin hashes. Poor logic.

I’ve also fixed the snapins not replicating.

Also fixed a location issue that went more or less unknown for a while.

Also fixed the logs continuously rewriting.

[Wayne Workman]

Cross-linking similar threads, and to give this thread a bump. Also moving this to bug reports.

This thread has a bunch of stuff in it - and I don’t like that, but it does also have the client updating bug in it.

https://forums.fogproject.org/topic/8636/fog-client-is-not-updating
https://forums.fogproject.org/topic/8561/rc10-broken-items-on-upgrade
https://forums.fogproject.org/topic/8556/gui-not-responsive
https://forums.fogproject.org/topic/8616/updating-fog-client

[Joe Schmitt]

The issue with client updating has been found and a patch is being worked on. The patch will not require any additional work to be done on your side, just a simple server update once ready.

[Joe Schmitt]

https://forums.fogproject.org/topic/8645/fog-client-auto-updating-hotfix