FOG 2.0 - Persistent Group Settings

[JJ Fullmer]

So currently, and correct me if I’m wrong, when you set up a group, unless you have members in it it doesn’t save any settings. And if you have some hosts in it the settings are saved in the group settings, but you have to hit updated on everything for it apply to hosts in the group. This is already a very powerful tool and an excellent feature, I just think that it could be enhanced a little.
Instead of having to manually update whenever you add a new host to a group, make it so adding a host to a group automatically adds, removes, and or deploys corresponding snapins, printers, active directory settings, and everything else except for the image (which maybe there could be an option or prompt for). Also make it so settings can be saved to a group without any members in it.

This way as you move computers around or as you are making your initial FOG setup, the group functionality automatically automates group membership. It already kind of does this when you image a computer in a group, but I would like to see it happen whenever you add a computer to a group.

Another crazy cool but probably too complicated feature possibility is to make the active directory connection 2 way. So that if a host is added to fog and already in an active directory OU that is linked to an exisiting group, it is automatically added to the corresponding group. But that one might be more work than it’s worth.

[Wayne Workman]

I disagree. I like it exactly how it is.

If I set a setting on my “ALL BUILDING COMPUTERS” group for joining to AD, That’s cool, because at that moment, I want to make sure all building computers are set to join to AD using whatever credentials I put in.

However, later on, when I’m updating an image and I disable domain joining for a particular computer - so that it does not join the domain when I deploy an image to it, and so I can update and re-upload without mucking up my image, I definitely do not want groups to just automatically re-tick the join domain checkbox.

There are other examples, too. I don’t want any changes made to the group functionality.

[JJ Fullmer]

@Wayne-Workman So you wouldn’t want the ability to move a host into a group and then know it is configured as it should be with one click?
I see your point in where it could cause problems, so perhaps it needs an off switch. I just really like automating things.

[Tom Elliott]

While I’m all for making “automation automated”, the idea of groups is to give ultimate control over a mass of objects. Groups are not intended to automate the processes, but rather update hosts in an all inclusive setup.

[JJ Fullmer]

@Tom-Elliott said:

Groups are not intended to automate the processes, but rather update hosts in an all inclusive setup.

Well I just want to automate updating hosts in an all inclusive setup. It’s just an idea really. As it is it feels a little clunky. Maybe there’s an intermediate. Like when you add hosts to a group you have a prompt that asks if you want to update them with the group settings and that just runs an update all for each group setting and deploys snapins for the new members?
I’m just lazy…err I mean, driven by efficiency, and don’t want to miss something when putting hosts into a group with all the settings I want for them.

[Tom Elliott]

@Arrowhead-IT While understandable, where do we stop?

Remember, hosts can be in any number of groups. So you’d constantly have to remember which setting is which and if that’s correct. Doing this method, you can kind of forget one or the other a little more.

[JJ Fullmer]

@Tom-Elliott That is a good point, well maybe at least we could make it so you don’t have to have a member in the group for settings to save?
While setting up the infrastructure before adding existing computers from active directory, not being able to save the settings for each group before getting hosts in fog is a bit of a hindrance.

[Wayne Workman]

@Arrowhead-IT You could probably script it with a crontab task. You can call the php page that does the group updating via CLI, and you can also pass URL variables to it as well, I believe. You could have a config file for each group.

Or… you could make a snapin that hooks into the “add to group” process, with another table to hold group settings.

either way - I don’t really want this sort of thing forced on me. The way it works now just makes sense. I’m able to explain it really well to people as well.

[Junkhacker]

i’ve been thinking about groups and i had an idea about a way to somewhat implement what you’re talking about. if we had a special type of group, a “master” group type. here’s how it would work:

• hosts are only allowed to belong to 1 “master group.”
• any changes made to a master group get rolled down to all hosts in the group
• any host added to a master group gains the settings set in the master group

there are 2 ways i can think of this being implemented. either

1. hosts in a master group cannot have settings that differ from their master group, except for their name and mac (master groups settings are stored just like the settings for a host, and the groups settings are substituted for the normal setting that would be looked up for the hosts)
2. hosts can have different settings than the master group, but risk those settings getting overwritten whenever a change is made to the group (master group settings are stored like hosts and overwrite the settings of hosts whenever there’s a change to the group, or those settings get applied to hosts if they’re added to the group. )

having master groups like this would allow you to register a computer, join it to a master group, and have all of it’s setting ready for you to deploy (i.e. AD settings, image, printers, and snapins).

[JJ Fullmer]

What if you forget the automation part of my feature request and focus on the persistent part. As I’m utilizing groups more and more I would really like it if I didn’t have to manually select snapins and printers everytime. It is convenient to be able to add the same things but I’d like to have a static template type of thing. Every host in this group needs these snapins type of thing. Maybe I’ll just make it a plugin at some point if I ever get any extra time

[Wayne Workman]

@Arrowhead-IT said:

What if you forget the automation part of my feature request and focus on the persistent part. As I’m utilizing groups more and more I would really like it if I didn’t have to manually select snapins and printers everytime. It is convenient to be able to add the same things but I’d like to have a static template type of thing. Every host in this group needs these snapins type of thing. Maybe I’ll just make it a plugin at some point if I ever get any extra time

That’s a much better approach.

But I’d say that “templates” should be a special kind of group - it’s just a group that you can actually save settings to. Then - when you want those applied you’d just go to that group and click an “Apply” button with the settings you previously put in already there for each of the settings areas.

I suppose we could create a fake host for each template - and have the template groups auto-load settings from the fake hosts - just as the regular hosts auto-load their own settings from the DB.

Still a far cry from being done though.

[Tom S]

The current Group Settings in FOG to do not directly update a host. Rather when a host asks for things like printers or etc, the server combines the groups and host settings together and passes to the host. The host will always take priority over group so that if a group has a default printer and a host another. The host default printer wins

-T

[george1421]

@Junkhacker I’ve been meaning to respond to Junkhacker’s post for… about 13 days now.

I agree this would be a very useful function. Along the same lines as Wayne pointed out. If we could twist the groups a bit to make the settings persistent. In the Host detail record, have a template (or group) field. To where you can link the host to a template record. Beyond that something could be setup like how some of the front ends for nagios works. In these there is a template list, and then when a template is selected the data fields update to the template settings. If you want to override a template setting you just uncheck the inheritance check box and enter a device specific setting. (I’d include a picture, but I have no clue how this editor handles picture imports)

That is a nice to have feature, but having a persistent group template would help out. In my case based on different image types I have workstations going into different OUs. This is also the case where I have the same image that is deployed at different sites. These sites have their own computers OU. Right now I have to image the computers to a transfer OU and then manually move them into the right container. I could do this on the windows/unattend.xml file if I could get fog variables into the FOS deployment environment (different feature request).

I’m a bit confused on comment of Tom S, his post implies there is some level of group persistence. If this is the case, why can’t we see the persistent settings when we review the group. Or are only bits of the group properties persistent?

[Joe Schmitt]

@george1421

@Tom-S and I designed a new style of groupings for hosts in fog 2.0 awhile back (while not completely “hashed out”, it seems to fit what everyone in this thread has been asking for).

The basic concept is to introduce a hierarchy of priorities. An example hierarchy would look like:

 -> host
---> group 1
-------> group 2

With the above example, host specific settings will supersede all groups, group 1 will supersede group 2, and so on. We could easily add a button to make an on-demand overwrite of hosts settings with group settings, essentially “clearing” individual host overloads. A group wouldn’t need to define every possible setting, just the ones you want. So with this approach groups are persistent, you can have multiple groups, and you can still override specific settings per-host.

[george1421]

@Jbob I was so excited until you said fog 2.0…

I can see the “hierarchy of priorities” will work something like how the GPO policies are applied in that higher level groups can overwrite settings of lower level groups. SO that will work just fine.

But again no joy for use who need it today with the 1.3(ish) release. Fog 2.0 sounds really nice.

[Wayne Workman]

@george1421 said:

But again no joy for use who need it today with the 1.3(ish) release. Fog 2.0 sounds really nice.

We could probably hack something together.