Persistent Groups - Snapins added to host but not deployed

[GeorgeBells]

Re: Associate all new hosts with Snapin

I read through the linked thread above, and it seems there may be a known issue with settings applied to a host via the use of the persistent group plugin are not actually deployed when imaging.

I’ve set up the plugin and my templates. Assigned a snap in and image - When registering a host it picks up the correct image and deploys, Snapins however are not. I cannot see any events under snapin history for the new host either

Is this something unavoidable? I can manually task snapins to be deployed via the group after imaging, but ideally snapins would be deployed as part of the imaging process

[GeorgeBells]

As far as I can tell, as mentioned previously the persistent groups plugin does apply the settings to the host but does not deploy them

I don’t know if it is possible to request any ‘fix’ for this?

[george1421]

@Developers

I’ve looked at the code for the persistent groups and snapins. It appears when the trigger runs it updates snapinsAssoc table to link the snapin to the host.

        INSERT INTO `snapinAssoc` (`saHostID`,`saSnapinID`)
            SELECT @myHostID as `saHostID`,`saSnapinID`
            FROM `snapinAssoc` WHERE `saHostID`=@myTemplateID;

What looks like its missing is the job/task to tell the client to do this. I’ve looked at the tables and this is what I see

I not so familiar with the snapin system, but It looks like an entry needs to be created in the snapinJobs and then in snapinTasks.

Do you know if that is what is needed to kick off a snapin deploy task? It has to be a bit more than just making the association like the plugin is doing today. Since I don’t use the snapins in my environment I can’t reverse engineer how they are deployed. When I associate a snapin with a host all I see the association in the snapinAssoc but nothing that tells the client to deploy the snapin.

Any Ideas?

[Tom Elliott]

@george1421 snapinJobs is the task table for snapins. snapinTasks are the individual snapins associated to the snapinJob.

Persistent groups wouldn’t create this entry, this is created by the host at the time a task is generated.

[george1421]

@tom-elliott Tom thank you for the reply. From what I understand the snapin association is being made in the snapinassoc table. But what is not happening is a snapin task is never running to deploy the snapin to the target computer. I would think something is missing that is needed to kickoff the deployment. Or does the fog client do that.

this is created by the host at the time a task is generated.

After thinking about this for a bit. What tells the host to create these entries? I think that is the bit I’m missing. The association table links the host with the snapin, but something needs to trigger the host to deploy the snapin.

[Sebastian Roth]

@georgebells said in Persistent Groups - Snapins added to host but not deployed:

When registering a host it picks up the correct image and deploys, Snapins however are not.

Do I get this right? You register a new host via the FOG iPXE menu saying yes to let it do a reboot and deployment directly, correct?

Just to poke into this a little more: Have you tried scheduling a “normal deployment” through the FOG web UI after the iPXE menu registration instead? Would that deploy the snapins as well?

[Tom Elliott]

@george1421 snapin tasks are exactly that, tasks. That means you need to task the host with a snapin task tasking: deploy, all snapins, and single snapin.

[george1421]

@tom-elliott Thank you for the explanation. I took that info a new FOG install and a bit of reverse engineering and I found the bit I was missing.

As I posted before this is the snapin section of the trigger that fires when a host is associated with a group.

        INSERT INTO `snapinAssoc` (`saHostID`,`saSnapinID`)
            SELECT @myHostID as `saHostID`,`saSnapinID` 
            FROM `snapinAssoc` WHERE `saHostID`=@myTemplateID;

This does does for sure link the new host to the snapins associated with the template host. But what it doesn’t do (as the OP posted) deploy the snapin to the target computer.

For that bit to work a new snapinJob must be scheduled and then a new snapinTask must be created for each snapin association that was just inserted.

So this is (yet untested) code I’ve come up with to modify to the persistent group Trigger that replaces the code above

        SET @myDBTest = (SELECT count(`saSnapinID`) FROM `snapinAssoc` WHERE `saHostID`=@myTemplateID LIMIT 1);
        IF (@myDBTest > 0) THEN
            INSERT INTO `snapinAssoc` (`saHostID`,`saSnapinID`)
                SELECT @myHostID as `saHostID`,`saSnapinID` 
                FROM `snapinAssoc` WHERE `saHostID`=@myTemplateID;

            SET @sjDate = (SELECT NOW());
            INSERT INTO `snapinJobs` (`sjHostID`,`sjStateID`,`sjCreateTime`)
                SELECT @myHostID as `sjHostID`,1 as `sjStateID`,@sjDate as `sjCreateTime`;

            SET @mysjID = (SELECT `sjID` FROM `snapinJobs` WHERE `sjCreateTime`=@sjDate);
            INSERT INTO `snapinTasks` (`stJobID`,`stState`,`stCheckinDate`,`stSnapinID`)
                SELECT @mysjID as `stJobID`, 1 as `stState`,@sjDate as `stCheckinDate`, `saSnapinID` as `stSnapinID`
                FROM `snapinAssoc` WHERE `saHostID`=@myHostID;
        END IF

I’ve run out of time at the moment to take this to finish, but I’ll get back to it a bit later tonight or tomorrow.

[Tom Elliott]

@george1421 I still am not understanding. Are you saying, simply because the host is joined to a group it should automatically deploy he snapins to the newly joined host?

[george1421]

@tom-elliott said in Persistent Groups - Snapins added to host but not deployed:

e host is joined to a group it should automatically deploy he snapins to the newly joined host?

The short answer is, Yes.

The bit longer answer is still, Yes.

While I surely don’t need to repeat the concept of persistent groups to you, I’ll explain it for those who may find this thread in the future.

The intent of a persistent group is to create a model/ideal/template host in FOG. That host may have specific kernels, inits, parameters, printers, snapins, etc. defined in that group. We might call that our baseline configuration for any new host we would add to that group.

So lets expand this a bit, lets say we have 2 FOG Groups, Finance and Purchasing. Each department uses the same computer hardware, but have different application requirements and different local printers. Now lets say I’m staging a new computer for the Finance department. When FOG is done imaging the computer and doing any post install things via the FOG Client, I want that new computer to look exactly like the other computers in the Finance department with its baseline applications and default printers defined (just for full disclosure I don’t use the snapin or printer subsystems of FOG so I might overstate the capabilities of each). So when I’m running through the full registration, one of the questions the registration script asks is if I want to associate the host with a specific group. At this point I would say Finance, and proceed with imaging.

With the current persistent group trigger, if the template host had Finance application snapins associated with the template host those associations would be copied over to the snapin association table like defined. But at the end of the imaging and FOG Client actions the applications would not be installed on the target computer. The snapin association was made, but the client was never told to install the software. This is the problem in the OP of this thread.

We are missing the step to tell the FOG Client to install the associated snapins.

Now with that said, I can also see a problem with this new approach in that its possible to deploy an already installed application to the same target host.

Side note is that while the focus is on Snapins, the Printers module also suffers from the same condition in that the associations are created but the client is never told to do the install.

[Tom Elliott]

@george1421 I guess where I am confused is the general point? Basically just adding a host to a group should not tell the group to deploy snapins, that’s the point of the tasking of things. Now if you are saying the host is being joined as a part of the host registration process, then you are correct. It should create the task and do the snapin install. Just joining to the group say from the GUI or API should not create a task. If you want to create a task after adding, then it should work properly.

[GeorgeBells]

@george1421 Thanks for looking into this - The changed code you’ve mentioned earlier, did you get a chance to fix whether this would work? It would be fantastic if it possible to have the persistent groups also task the host to deploy any snap-ins/printers etc etc.

@Tom-Elliott The general point is to register a brand new host, assign it to a group, which is linked to a host via persistent groups and not only have it assign snap-ins etc to the host but also create a task to deploy them… Registering, imagining and deploying all assigned snap-ins as part of the initial register process. We have a few pieces of software which I would like to be on every machine installed, but not included in the image due to the way they work, it being best to install after the machine name has changed and etc etc.

Thanks to both of you for the time you’ve spent on this so far.

[george1421]

@georgebells said in Persistent Groups - Snapins added to host but not deployed:

The changed code you’ve mentioned earlier, did you get a chance to fix whether this would work?

I did not have a chance to test this over the weekend. I will have a chance to test this tonight. I have the test scenerio setup I just need to deploy a system as is and then manually run the “fix”. If that works I can update the plugin code (not officially) and provide you with that patched file to test in your environment.

[Tom Elliott]

@george1421 my guess is the persistent group is not the issue. @GeorgeBells your post says during registering the host. The host does get the snapins associated, but for whatever reason the deployment associated on the registration is not creating the snapin deploy task as a part of the image package creation. This sounds like a bug in the image creation portion, likely because it may be trying to create the task before the snapins are actually available to the host.

[Sebastian Roth]

@georgebells said in Persistent Groups - Snapins added to host but not deployed:

not only have it assign snap-ins etc to the host but also create a task to deploy them…

May I ask again: Creating the task by saying yes to deploy right at the end of registration?

Just to see if it makes a difference, can you say no to deploy right at the end of registration but schedule a deploy through the web UI. Does it deploy snapins then?

I think Tom is on the right track with saying it could be a but in the code.

[george1421]

@sebastian-roth said in Persistent Groups - Snapins added to host but not deployed:

May I ask again: Creating the task by saying yes to deploy right at the end of registration?

(I realize the question was not directed towards me)
I can confirm that during full registration, if you associate snapins with the registering host it does schedule the snapin deployment (that is how I reverse engineered the answer). Since persistent templates are not part of the core FOG code, when you associate a the registering host with a group and that group is a host template the snapins that are associated with that template will be linked to the registering host, but no tasks will deploy the snapins. You will need to manually release these tasks in the web ui.

I do understand what the OP is after, he is after a zero touch deployment. I do the same thing but user a different app deployment tool. There are some applications that can’t be baked into the reference image such as AV or any application that creates a unique GUID to identify the client to the management console (if you installed these apps before image capture every imaged machine will have the same GUID). So post image deployment we need a way to deploy the snapins (apps) post image deployment without having to touch the the web ui.

So the idea is that you take a bare metal computer pxe boot into full registration, add the necessary fields, associate the new computer with a template group, then pick deploy at the end of imaging. FOG then should deploy the image, do what ever system renaming and connecting to AD that is necessary, then finally deploy the finish up GUID based apps and or departmental specific apps. All of this without human intervention. At least that is the goal.

[george1421]

@georgebells OK I have a proof of concept code for you to try.

Move the existing FOG sourced file out of the way

sudo mv /var/www/fog/lib/plugins/persistentgroups/class/persistentgroupsmanager.class.php /var/www/fog/lib/plugins/persistentgroups/class/persistentgroupsmanager.class.php.sav

download the file from the google drive and upload this file on the fog server to /var/www/fog/lib/plugins/persistentgroups/class/ as persistentgroupsmanager.class.php

https://drive.google.com/file/d/1kbZqDKegvnGymQ_iY8oJYRyXsLw-RZZU/view?usp=sharing

Once the file is in place. Uninstall the persistent group plugin and reinstall it. Nothing needs to be changed other than uninstall and reinstall.

Once you uninstall and reinstall the plugin the database trigger will be updated with the new code.

This file only addresses the snapins. I’m a bit brain dead at the moment to tackle the printer bits. I’ll work on that later.

At the moment the developers look at this request and patch as a niche solution and probably won’t be added to the main line code. They are positioning this patch much like the one off kernel builds I do to solve a specific niche problem. With that said FOG is opensource and anyone is welcome to modify the code for their own needs.

[GeorgeBells]

@george1421

Brilliant, thanks for that. I’m not in a position to test it out today but will be tomorrow, I’ll give it a try and get back to you.

[george1421]

This post is deleted!

[george1421]

@georgebells Hold up on that previous change. I went about the solution from the wrong end. Working on something more inline with what the developers would do.