Persistent Groups - Snapins added to host but not deployed

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

[GeorgeBells]

@george1421

Makes sense - Edited my previous response because I immediately realised this is likely the case, just to clarify incase I did word it wrong, I had been reinstalling just the plugin through the UI, not fog itself.

[george1421]

@georgebells well the plugin file has the right number of bytes to the size so I think its the same as the file on my production server.

[GeorgeBells]

@george1421

Interesting…

I’ve been going to the fog web management > plugins > installed plugins and uninstalling persistent groups…

I have then gone into install plugins, and reinstalled it.
I have also tried going to install plugins, deleting it, back to activate plugins, activating it and installing.

[GeorgeBells]

@george1421

Do you have any other advice on this? Haven’t had much chance to play around with it lately but hoping to revisit it soon