Persistent Groups - Snapins added to host but not deployed

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.

GeorgeBells

@george1421

This is the output for mysql - After inserting that file, restarting the apache server, uninstalling and reinstalling the plugin

george1421

@georgebells it appears that the file hasn’t been replaced on the server for some reason.

When you view the /var/www/fog/lib/plugins/persistentgroups/class/ directory does persistentgroupsmanager.class.php have a different date than the rest of the files?

GeorgeBells

@george1421

It does, it has todays date.

george1421

@georgebells Well once that file is updated you need to uninstall and reinstall the plugin. When you uninstall that plugin it will drop that trigger from mysql. When you add the plugin back in via the web ui it will recreate that trigger. The updated file from the google drive has the changes made to the create trigger command. You don’t reinstall FOG because it will overwrite the patched file I sent you.

Persistent Groups - Snapins added to host but not deployed

271

11.7k

17.1k

154.7k