Full Registration, causing rogue snapins to apply

[adukes40]

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:

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.

[Tom Elliott]

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

[adukes40]

@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

[Tom Elliott]

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.

[adukes40]

@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.

[Tom Elliott]

@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.

[adukes40]

@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?

[Tom Elliott]

@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);

[adukes40]

@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>

[Tom Elliott]

@adukes40 So I’m just guessing, that Snapin D in your case was probably that one item?

[adukes40]

@Tom-Elliott I will test some registrations today and see what happens. Getting bombed with early morning emails at the moment.

[adukes40]

@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.

[adukes40]

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.

[Wayne Workman]

@adukes40 This is probably because your DB is still dirty. we need to figure out some queries that will clean it up.

[Tom Elliott]

@Wayne-Workman I say simplest would be to truncate snapinAssoc snapinJobs and snapinTasks then rrapply

[adukes40]

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.

[Tom Elliott]

@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.

[adukes40]

@Tom-Elliott Its doing it again.

[Tom Elliott]

@adukes40 What’s happening again? All nodes are at the same version?

[adukes40]

@Tom-Elliott All nodes at RC-11, It back to assigning recently used snapin associations from recent image deployments

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