Basic Persistent groups and 1.3.0RC16

[george1421]

With the release of 1.3.0RC16 basic persistent groups have been added to the system via a plugin. The developers were kind enough to write a plugin wrapper for the mysql trigger I created in this post: https://forums.fogproject.org/topic/6902/fog-1-3-persistent-groups

Please understand that persistent groups are not officially supported by the developers since they only wrote the plugin wrapper for the sql trigger. With the use of this plugin wrapper its no longer necessary to go into mysql and paste in the trigger as it was defined in the link above. This plugin is already installed in RC16 and should be added the norm way plugins are added into fog.

This plugin started out as a need to have persistent groups in FOG. I was a bit confused about the built in grouping in fog when I started using it as many others. I would create a group in fog, set a parameter for that group, press OK and the parameter would disappear. After banging my head against the wall thinking that I was doing something wrong I reached out to the developers to say something was broken with fog groups. The developers explained how FOG groups really worked. (These are my words not theirs), The groups in FOG are what I might call set groups, in that you can assign hosts to a group and then key in a parameter and then that parameter is copied to all hosts in the group. That setting does not stick in the group definition. If you add a host later to the group the setting I created yesterday will not be applied to this new host when its added to the group. This is not what I needed for my FOG environment. I have 3 or 4 classes of computers, each of these classes have their own specific OU settings, their own combination of snapins and other unique settings. I wanted to add a new computer to the CAD group and have all of the settings specific to the CAD group applied to that new system. The same would go for the production class and the office class. Each have their own individual characteristics.

Since I didn’t know how to program in FOG or create plugins I reverted back to something I’m quite familiar with SQL. I though that if I could create a sql trigger that when a host is added to a specific template group that database trigger event could then update the inserted host with a predefined host template. I could do this without having to program fog or change the programming in any way. This hack is done outside of the scope of fog and its management control since it executed at the database level.

Before we get started here we need to get some terminology defined.
Host template := is a non deployable host where you set the predefined values you want copied to your destination hosts. At this time a template host may only be associated with a single template group.

Template group := is a group that is associated with a single template host. A template group can contain many hosts, but may only be associated with a single template host.

The way the sql trigger works is when you add a new host to a template group, the sql trigger fires and erases all existing snapin, location, (and and) parameters from the new host and then copies the settings from the template host to the new host. Understand the way the trigger works is that it only fires when the host is first added to the group. If you change a parameter in the template host, this value is NOT automatically copied to all hosts in the template group. If this is what you need you should use the traditional fog (set) groups for this. Also note when you remove a host from a template group the settings are not removed from the new host. So in a way the template groups and template hosts are a set only group (which functions the same way as the traditional FOG groups, except the settings are remembered in the template host).

[george1421]

This post is deleted!

[george1421]

Removing Persistent Groups

If you need to stop the persistent group copy function, just remove the Persistent Group plugin, the plugin uninstall code will also remove the sql trigger stopping the update on insert action. Removing the plugin will not remove the persistent group or its members or remote the host template. You can turn back on persistent groups by simply reinstalling the plugin, which will recreate the sql trigger and restart the persistent group function.

[george1421]

Conclusion

That’s pretty much it for persistent groups. You may now treat the persistent group the same as all other FOG groups. Just be aware when you assign a target host to a persistent group, all current settings of the target host will be replaced with the values saved in the host template.

Please post any feedback to this tread.

[george1421]

Setting up the Template Group

The template group is a specially named group. When target hosts are added to the Template Group, the sql trigger fires and updates the target host with the settings copied from the Host Template created in the above step.

To create the template group

1. Go to Group Management -> Create new group
2. Group Name: TemplHost01 (this name must match EXACTLY the name you entered for the host template. Its best to copy and paste the host template name here to ensure accuracy. Case IS important, if the template group name does not match exactly the host name the sql trigger will ignore the host insertion and the settings will not be copied)
3. The group kernel, kernel args, and primary disk are not used since those settings are copied over from the host template. You may leave these fields blank.
4. Template group setup is now done.

While this feature is not part of the basic persistent groups in RC16. The sql trigger will be updated to include any groups the host template is a member of. It is VERY important to note, DO NOT make the host template a member of the template group of the same name. Doing so will cause an update loop. Unexpected things happen when a trigger fires upon itself during an update. You don’t want to go there so just be sure to NOT make the host template a member of its management template group.

[george1421]

Setting up the Host Template

In this section we will create a template host where we will hang all of our configuration on. The template host in this context is just a manually registered host with a unique (impossible) mac address. This host will never be used directly for pxe booting or configuring a target host so we will pick a mac address that is unique to your install.

From the perspective of configuring the host template system we will treat it like any other host. We can connect snapins, assign AD parameters, customize fog modules. Everything you can define for a regular host you can do to this host template (except boot it).

To create the host template (hint: its the same process as manually registering a host)

1. Go to Host Management -> Create New Host
2. Host Name: TemplHost01 (this name can be anything as long as its locally unique)
3. Primary MAC: 00:00:00:00:00:01 (The host record MUST contain a mac address, we’ll just set it to a locally unique value.
4. Fill out the remainder of TemplHost01 as you see fit for your site.
5. When the settings are correct for your site press the ADD button
6. After the TemplHost01 has been registered you may now continue configuring this host by adding printers, snapins, and service settings.
7. This concludes setting up the host template.

[theWizard]

Is there any way of getting the snapins associated with the defaulttemplate host to launch when machines are deployed using quick reg auto pop ?
I set the group to defaulttemplate but the snapins never get launched, or @Developers is it possible to add a snapins selection to the auto pop section this would make imaging machines for us 100% automated at least on a per room basis.

[george1421]

@theWizard Is there any way of getting the snapins associated with the defaulttemplate host to launch when machines are deployed using quick reg auto pop ? I set the group to defaulttemplate but the snapins never get launched, or @Developers is it possible to add a snapins selection to the auto pop section this would make imaging machines for us 100% automated at least on a per room basis.

First I have to say the persistent group function is not an officially supported function of FOG 1.3.0. It is a user supplied hack to give FOG some kind of persistent group ability.

Just for clarity, it does work correctly when you assign the host to the template group via the web gui?

I don’t believe that the quick reg allows you to pick a group assignment. The trigger to activate the persistent group is the host being added to the template group. This is done at the database level and not via the web gui. So it should activate as soon as a host is added to the template group.

[Tom Elliott]

@george1421 It should allow you to add the host to a group. I haven’t played with it in a while though (to be honest).

I can’t remember if the groups are listed in a select box or it just presents a text box. Pretty sure it’s just a text box in which case it would accept comma separated.

Note: (NOT , space e.g. 11, 1) but must be: 11,1

[george1421]

@Tom-Elliott Well if that is the case and the host is added to the template group the db trigger should fire and add in everything that is associated with the host template. The only thing I could think might go wrong is the db trigger fires too soon and the host hasn’t been fully updated yet. The group assignment should (hopefully) be the last thing the quick reg does, that way the host is already defined before the trigger fires. I can say I never tested the trigger with a quick reg since we never do quick reg any more.

[Tom Elliott]

@george1421 The trigger will only happen the moment the host is “officially” stored in the database. That means it doesn’t matter where it’s added in the the process, rather when the DB actually get’s the new entry. (which would be after the host is “saved”)

[theWizard]

@george1421
Yep you can select a group in quick reg ( drop down list ) which i set to the defaulttemplate group so expected the trigger to fire and launch the snapins too but unfortunately while everything else works and the image starts deploying the snapins don’t get launched, if i check the host the snapins are assigned to it but they never got launched
@Tom-Elliott I wonder if it would be simpler if possible at all just to add a drop down for snapins to the quick reg section ?

[george1421]

@theWizard I’m just wanting to confirm here (since I don’t use snapins at all).

When you quick reg a machine, you add the machine to the host template group. All of the host template settings get assigned to the host, including snapins. If you go and look at the host you just auto registered the snapins ARE assigned to that new quick reg host?? But after imaging the fog client doesn’t install the snapins as it would if you assigned the snapin (singly) post imaging??

Right now its not clear if the issue is with the db trigger, or the fog client not picking up the snapins, or there is another table that needs to be set to trigger the snapins to install.

[theWizard]

@george1421
It’s not the fog client, when the imaging task fires after doing the auto reg the snapins don’t get launched at all. If i launched it as a standard deploy there would be an imaging task and snapins task in the queue but using auto reg even with group set to host template group the snapins task does not get created only the imaging task BUT the snapins are assigned to the host if you check in the gui.

[george1421]

@theWizard Ah, that is what I thought. The snapin assignments are being made (host X has these snapins assinged) but this snapins are not creating the task to actually deploy them.

<edit>or to say it the same exact way again</edit> Or to say it another way the snapin assignments exist but the task to install them is missing.

Ideas Tom?? I would ass-u-me that the trigger will need to create the snapin deploy task. That would sound logical if it was a quick reg and deploy or done from the gui.

[theWizard]

@george1421 Exactly yes no task to install the snapin is created.

[Tom Elliott]

@theWizard Mind giving a shot with the RC 36 build?

I think the problem was the host was not “known” to have the snapins at that point. The associations were made, but the original object did not have the new items embedded. I’m currently addressing this by “loading” the new stuff, but I think I’ll be rethinking this once I get home. For now, however, this should do what you need it to now.

[theWizard]

@Tom-Elliott I updated to RC36 but same result, if i check the host the snapins are assigned to it and the image is deploying but there is no task for the snapins at all.

[Tom Elliott]

@theWizard This is validated under Task->Active Snapin Tasks?

[theWizard]

@Tom-Elliott Yep just checked again and no snapin tasks at all