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.



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


  • Senior Developer

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



  • @Tom-Elliott Its doing it again.


  • Senior Developer

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



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


  • Senior Developer

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


  • Moderator

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



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



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



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


  • Senior Developer

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



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


  • Senior Developer

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



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


  • Senior Developer

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



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


  • Senior Developer

    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.



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


  • Senior Developer

    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


Log in to reply
 

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.