<![CDATA[Full Registration, causing rogue snapins to apply]]>Server
  • FOG Version: Pull version 57
  • OS: Ubuntu 14.04
Client
  • Service Version: 11.2
  • OS: Win 7
Description

Registering hosts through the PXE menu is causing the same snapins to apply even though they are not the ones being told to associate. Here is what I mean

I go to Full Reg a machine. Image ID, location ID, Hostname, stick and work. When it comes time for snapins, we apply 3 for every machine. Those 3 get applied, but then about another 4-5 snapins get applied as well in the background. When we go to deploy this image it will not complete due to the confusion I suppose. Now if w go into the GUI, and remove the extra ones, and update, it sticks and go through fine. But for some reason if Reg thru PXE, more than the set snapins are getting assigned. Here is a SS of one I Registered today:

0_1474654028045_upload-b99b4c4e-ea20-45ae-aef4-5fef5095644f

This only ones that should be showing are 1-TS-140, 2-InstallScript1, and 2-InstallScript3 The other appear as associated as well.

As a side note, those extra ones, were machines imaged when my earlier snapin issue were occurring within the past week.

]]>http://forums.fogproject.org/topic/8638/full-registration-causing-rogue-snapins-to-applyRSS for NodeSun, 10 May 2026 01:42:36 GMTFri, 23 Sep 2016 18:09:05 GMT60<![CDATA[Reply to Full Registration, causing rogue snapins to apply on Mon, 03 Oct 2016 15:06:52 GMT]]>@Tom-Elliott All nodes at RC-11, It back to assigning recently used snapin associations from recent image deployments

0_1475507131758_upload-32d5e685-9979-44a5-844e-e07b3c6cd59b

Nothing has changed here. Just going about day-to-day operation. Tried with same host name, and never before used host name, same result.

]]>http://forums.fogproject.org/post/80122http://forums.fogproject.org/post/80122Mon, 03 Oct 2016 15:06:52 GMT<![CDATA[Reply to Full Registration, causing rogue snapins to apply on Mon, 03 Oct 2016 15:01:26 GMT]]>@adukes40 What’s happening again? All nodes are at the same version?

]]>http://forums.fogproject.org/post/80120http://forums.fogproject.org/post/80120Mon, 03 Oct 2016 15:01:26 GMT<![CDATA[Reply to Full Registration, causing rogue snapins to apply on Mon, 03 Oct 2016 14:14:05 GMT]]>@Tom-Elliott Its doing it again.

]]>http://forums.fogproject.org/post/80108http://forums.fogproject.org/post/80108Mon, 03 Oct 2016 14:14:05 GMT<![CDATA[Reply to Full Registration, causing rogue snapins to apply on Tue, 27 Sep 2016 20:42:43 GMT]]>@adukes40 had me remote in. We found about 3200 + hosts that hadn’t been properly removed. The older db crud was still left over though which was why it seems to be “rogue” items. Removed the “bad” hosts and all seemed to correct itself.

I’m going to resolve for now.

]]>http://forums.fogproject.org/post/79772http://forums.fogproject.org/post/79772Tue, 27 Sep 2016 20:42:43 GMT<![CDATA[Reply to Full Registration, causing rogue snapins to apply on Tue, 27 Sep 2016 19:27:30 GMT]]>There other I am seeing is sometimes the 1- snapins remove themselves from association after an image. I am looking at two hosts, where that just happened. 1- removes itself, but 2- and 3- always stay.

]]>http://forums.fogproject.org/post/79764http://forums.fogproject.org/post/79764Tue, 27 Sep 2016 19:27:30 GMT<![CDATA[Reply to Full Registration, causing rogue snapins to apply on Tue, 27 Sep 2016 19:24:16 GMT]]>@Wayne-Workman I say simplest would be to truncate snapinAssoc snapinJobs and snapinTasks then rrapply

]]>http://forums.fogproject.org/post/79763http://forums.fogproject.org/post/79763Tue, 27 Sep 2016 19:24:16 GMT<![CDATA[Reply to Full Registration, causing rogue snapins to apply on Tue, 27 Sep 2016 19:13:47 GMT]]>@adukes40 This is probably because your DB is still dirty. we need to figure out some queries that will clean it up.

]]>http://forums.fogproject.org/post/79761http://forums.fogproject.org/post/79761Tue, 27 Sep 2016 19:13:47 GMT<![CDATA[Reply to Full Registration, causing rogue snapins to apply on Tue, 27 Sep 2016 13:37:14 GMT]]>Ok, just tested this myself.

Soo… went to a machine. Registered it with snapin that wasn’t currently in the “rogue” list. When I check the snapins, the new snapin shows, along with the like 8 others, plus the 2 every machine gets. Which mean the next time a machines Regs thru PXE, it will be getting that snapin plus the other stuck in the loop.

]]>http://forums.fogproject.org/post/79729http://forums.fogproject.org/post/79729Tue, 27 Sep 2016 13:37:14 GMT<![CDATA[Reply to Full Registration, causing rogue snapins to apply on Tue, 27 Sep 2016 13:03:27 GMT]]>@Tom-Elliott Just had a Tech register a machine today. Same outcome all the previous snapins, plus a new one from the room they were in this morning.

Havent had time ti test anything else yet.

]]>http://forums.fogproject.org/post/79728http://forums.fogproject.org/post/79728Tue, 27 Sep 2016 13:03:27 GMT<![CDATA[Reply to Full Registration, causing rogue snapins to apply on Tue, 27 Sep 2016 11:58:23 GMT]]>@Tom-Elliott I will test some registrations today and see what happens. Getting bombed with early morning emails at the moment.

]]>http://forums.fogproject.org/post/79727http://forums.fogproject.org/post/79727Tue, 27 Sep 2016 11:58:23 GMT<![CDATA[Reply to Full Registration, causing rogue snapins to apply on Tue, 27 Sep 2016 11:57:18 GMT]]>@adukes40 So I’m just guessing, that Snapin D in your case was probably that one item?

]]>http://forums.fogproject.org/post/79726http://forums.fogproject.org/post/79726Tue, 27 Sep 2016 11:57:18 GMT<![CDATA[Reply to Full Registration, causing rogue snapins to apply on Tue, 27 Sep 2016 11:53:45 GMT]]>@Tom-Elliott

Database changed
mysql> DELETE FROM snapinAssoc WHERE saHostID NOT IN (SELECT hostID FROM hosts);
Query OK, 0 rows affected (0.02 sec)

mysql> DELETE FROM snapinAssoc WHERE saSnapinID NOT IN (SELECT sID FROM snapins);
Query OK, 1 row affected (0.01 sec)

mysql>

]]>http://forums.fogproject.org/post/79725http://forums.fogproject.org/post/79725Tue, 27 Sep 2016 11:53:45 GMT<![CDATA[Reply to Full Registration, causing rogue snapins to apply on Tue, 27 Sep 2016 11:48:07 GMT]]>@adukes40 It’s a single statement.

DELETE FROM snapinAssoc WHERE saHostID NOT IN (SELECT hostID FROM hosts);

You can also try:
DELETE FROM snapinAssoc WHERE saSnapinID NOT IN (SELECT sID FROM snapins);

]]>http://forums.fogproject.org/post/79724http://forums.fogproject.org/post/79724Tue, 27 Sep 2016 11:48:07 GMT<![CDATA[Reply to Full Registration, causing rogue snapins to apply on Tue, 27 Sep 2016 11:43:17 GMT]]>@Tom-Elliott You mean the DELETE mysql statement?

And the (SELECT hostID FROM hosts) sections is part I just run in the command correct? Im not actually getting hostID from the hosts table?

]]>http://forums.fogproject.org/post/79723http://forums.fogproject.org/post/79723Tue, 27 Sep 2016 11:43:17 GMT<![CDATA[Reply to Full Registration, causing rogue snapins to apply on Tue, 27 Sep 2016 11:40:17 GMT]]>@adukes40 I believe the issue was the same as before I figured out the issue with the random disassociations/associations.

The working-RC-11 side of things had a bug in how it was interpreting code. Basically it wasn’t cleaning up for the next loop cycle. This caused random pieces of data to get inserted/removed unexpectedly.

I suspect you had more random associations due to this which are only showing up as you register new hosts.

If you run the mysql statement before, my guess is you’ll see quite a few items being cleaned up.

]]>http://forums.fogproject.org/post/79722http://forums.fogproject.org/post/79722Tue, 27 Sep 2016 11:40:17 GMT<![CDATA[Reply to Full Registration, causing rogue snapins to apply on Tue, 27 Sep 2016 11:36:16 GMT]]>@Tom-Elliott Here is the Process that we are doing that seems to be causing it to happen (haven’t done the cli command yet)

  1. Image random machine with snapin A, B, and C
  2. image completes
  3. Go to register new machine with snapin D, B and C
    (B and C are on every host)
  4. New machine now has snapins A, B, C, and D

Now here is what I do not know, and can try to test today

I am unsure if the snapins being added are also machines that have been registered thru PXE, and those are the ones get stuck in this oddity. If I add snapins manually, thru the GUI, it seems to work fine.

]]>http://forums.fogproject.org/post/79721http://forums.fogproject.org/post/79721Tue, 27 Sep 2016 11:36:16 GMT<![CDATA[Reply to Full Registration, causing rogue snapins to apply on Tue, 27 Sep 2016 10:42:36 GMT]]>I cannot replicate.

My steps to try to replicate were to make some “rogue” snapins that had no real definitions.

You might try:

DELETE FROM snapinAssoc WHERE saHostID NOT IN (SELECT hostID FROM hosts);

in a mysql cli shell.

]]>http://forums.fogproject.org/post/79717http://forums.fogproject.org/post/79717Tue, 27 Sep 2016 10:42:36 GMT<![CDATA[Reply to Full Registration, causing rogue snapins to apply on Mon, 26 Sep 2016 19:50:50 GMT]]>@Tom-Elliott Registered new machine today. The stuck associations still happen, and a couple more have made their way into the list now on top of the ones from last time.

ON RC-11

]]>http://forums.fogproject.org/post/79679http://forums.fogproject.org/post/79679Mon, 26 Sep 2016 19:50:50 GMT<![CDATA[Reply to Full Registration, causing rogue snapins to apply on Sat, 24 Sep 2016 20:43:34 GMT]]>The issue it think was a problem with the object not being truly deleted. It would create the item in the db and any prior associations but would fail to link the Mac. This left the hostname in the system as well as any other associations that were created, even accidentally.

Im pretty sure this is fixed now though

]]>http://forums.fogproject.org/post/79630http://forums.fogproject.org/post/79630Sat, 24 Sep 2016 20:43:34 GMT