FOG 2.0 - Persistent Group Settings

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