Host don't inherit group settings on add?

[rbaldwin]

Server

• FOG Version: Running Version 1.3.1-RC-2 SVN Revision: 6052
• OS: Ubuntu 14.04

I haven’t updated in a few weeks, but checking the change log I didn’t see any changes related to groups, I’ll update later today and confirm if the issue is still present.

Description

Adding a host to a group, the new host doesn’t inherit group settings. Is this intended?

ie: I have a group called P50, which has custom Kernel Arguments and Primary Disk settings. I register a new Lenovo P50, I add it to the group. The new P50 has no settings for Kernel Arguments or Primary Disk. I must edit and re-save the group for the new host to receive those settings.

Another unrelated bug, when I edit a group the “Primary Disk” setting is always empty. If I enter something and save the changes, it is saved to the group members, but the setting remains blank if I reopen the group for edit.

[george1421]

I don’t understand your specific issue here. FOG Groups are not persistent by default. You can thing about FOG groups as being a way to apply a specific setting to a number of devices at the same time. The group does not remember the setting for when some future host add.

[Wayne Workman]

@rbaldwin FOG Group settings are not persistent by default. The way they work is allowing you to apply permanent settings to all the members of the group, not the group itself. New members of the group don’t have past settings because they were not members of the group when the past settings were applied.

To me, this is natural, and I prefer this approach. With this approach, absolutely nothing is done without the administrator explicitly doing it.

Now, what really surprises me is why @george1421 didn’t tell you about the persistent groups plug-in that he himself created, which is available in the latest FOG release, which is 1.3.3 currently.

[Tom Elliott]

I confirmed the issue on updating kernelDevice not returning the value stored to all hosts in the group. This is fixed for the 1.3.4 tree. As for the “adding a host should get the items I set all the time”, both @george1421 and @Wayne-Workman are correct.

The group “feature” is just meant to be a means to update a group of hosts en-mass. While I certainly understand the “confusion” the reason it doesn’t update the hosts in the group automatically is because hosts can belong in multiple groups at the same. This way you could setup a full lab for specified settings in group, and add one of those hosts (or more of course) to another group to apply “specialized” settings.

For example:
You have classroom with 20 computers in it. Each of those computers need say a “room” printer associated to it. One of those computers is the teacher machine and needs a “confidential” printer for reports or whatever. (Let’s say that confidential printer needs to be on all teachers printers.)

Add the full room to one group to apply it’s settings. Apply the one computer to the group to the “confidential” printer group and apply the printer ONLY to that host.

Hopefully that makes sense on the “principle” behind groups.

You can achieve, however, the idea of “persistent groups” with the plugin @Wayne-Workman told you about.

[Wayne Workman]

@Tom-Elliott Another example:

You have a lab of 30 computers. 8 of them are Dell, 22 are Lenovo. You have an image that works on the dells, and an image that works on the Lenovos, but not an image for both yet.

You’d make three groups. ONe for the dells, one for the lenovos, and one for all 30 of them.

Use the dell group to apply the Dell image to all the dells. Use the Lenovo group to apply the Lenovo image to all the Lenovos. Use the bigger classroom group to apply Active Directory settings, Snapin Settings, Printer Settings, and whatever else.

Another example:
You have a building with 500 computers. 250 of them are Dell Optiplex 7010 models. The rest are other models. For this, you could have two or more groups. One group for all Optiplex 7010 models, and one group called “Blah-blah-Building” for every computer in the building. You’d use the building group to deploy updates for things like Chrome, and you’d use the model-specific group to do mass re-imaging when that time comes.