Persistent Groups - Snapins added to host but not deployed

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

[GeorgeBells]

@george1421 Alright no worries - Let me know.

I should have time to test today

[GeorgeBells]

@george1421 Hi George, sorry to pester. Have you any update for this?

[george1421]

@georgebells I can’t seem to find the right logic in the code to make this happen as it should. Until I can find the rights solution in the code go ahead and use my patched file for the sql trigger. I know that works.

Basically what is happening is the code is running too fast for the trigger because its an asynchronous action.

[GeorgeBells]

@george1421 I’ve just tried that new plugin file, unfortunately it doesn’t seem to have made any difference.

I’ve renamed the original file, downloaded and placed new one in the same location and uninstalled/reinstalled the plugin through FOG.

Then imaged a machine, it hasn’t created any queued tasks under the host and I can’t see that the snap-ins have been installed or are being installed

[george1421]

@georgebells Just to confirm, when you registered the host you added it to the group that is for the host template? AND you have snapins allocated to that host template?

[GeorgeBells]

@george1421 Yeah that’s all good - I’ve not touched the groups since making your change.
The snapins do get associated to the new host, just not tasked to installed.

[george1421]

@georgebells Well I guess I need to try that fix on another dev server to prove the script can be copied. I’ll get back and post later today because I know the script worked because it created the install tasks.

When I was testing I went through registration and selected the template group and then at the end told the computer to deploy at the end if inventory. Upon reboot I powered off the target computer, when into the web ui and inspected the task for both deploy and snapin deploy. Everything was there. Then I powered up the vm and let it deploy.

[GeorgeBells]

@george1421 Any progress on this? Sorry to pest, I do appreciate the work you are putting into this

[george1421]

@georgebells I haven’t had a lot of bandwidth to look into this, but I just tested the updated php code from my earlier post on our production FOG server and it installs what it should. I need to test to see if it creates the snapin tasks correctly, but I also need to create a few fake snapins because we don’t use snapins on my campus so that will take a bit more time than I have at the moment.

I installed the updated php code as outlined below
rebooted the apache server
went into the web ui and uninstalled the persistent group plugin
reinstalled the persistent group plugin
logged into the mysql server as root and attached to the fog database
expanded my putty window very wide
ran this sql command show CREATE TRIGGER persistentGroups;

I reviewed the sql program near the bottom and saw the “patched” code

        INSERT INTO `printerAssoc` (`paHostID`,`paPrinterID`,`paIsDefault`,`paAnon1`,`paAnon2`,`paAnon3`,`paAnon4`)
            SELECT @myHostID as `paHostID`,`paPrinterID`,`paIsDefault`,`paAnon1`,`paAnon2`,`paAnon3`,`paAnon4`
            FROM `printerAssoc` WHERE `paHostID`=@myTemplateID;

        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`,`stCompleteDate`,`stSnapinID`,`stReturnCode`,`stReturnDetails`)
                SELECT @mysjID as `stJobID`,1 as `stState`,@sjDate as `stCheckinDate`,STR_TO_DATE('00,00,0000','%d,%m,%Y') as `stCompleteDate`,`saSnapinID` as `stSnapinID`,0,''
                FROM `snapinAssoc` WHERE `saHostID`=@myHostID;
        END IF;

        INSERT INTO `moduleStatusByHost` (`msHostID`,`msModuleID`,`msState`)
            SELECT @myHostID as `msHostID`,`msModuleID`,`msState`

This is what was inserted

        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`,`stCompleteDate`,`stSnapinID`,`stReturnCode`,`stReturnDetails`)
                SELECT @mysjID as `stJobID`,1 as `stState`,@sjDate as `stCheckinDate`,STR_TO_DATE('00,00,0000','%d,%m,%Y') as `stCompleteDate`,`saSnapinID` as `stSnapinID`,0,''
                FROM `snapinAssoc` WHERE `saHostID`=@myHostID;
        END IF;

Or if you see this line

SET @sjDate = (SELECT NOW());

for sure the patch is installed.

(I still need to confirm this works on my production server)
In my home testing when I registered the computer I assigned it to the persistent group and selected deploy image right from the registration program.

I powered it off after registration and confirmed the tasks were created using the fog server web ui

I powered on the vm and it began imaging. That is where I stopped.