Associate all new hosts with Snapin

[fry_p]

Hi All,
I wanted to either ask about or request a feature to include a snapin association with all newly registered hosts.

I think it would be a useful resource for fog users. I can go into more detail if needed but I would think this would be useful

Please let me know your thoughts. It could be like a checkbox on the snapin creation page.

Thanks!
fry_p

[george1421]

Are you asking about persistent groups? In that you create a group with specific settings and then when you register a new host you make it a member of that group and all of the settings from that group are applied to the newly registered host?

[fry_p]

@george1421 I want to re-visit this in the near future when we aren’t super busy at work. I will look into persistent groups too. Just wanted to not leave you hanging.

[george1421]

@fry_p https://forums.fogproject.org/topic/8836/basic-persistent-groups-and-1-3-0rc16

At least read over it to understand how it works. Tom built the trigger into a fog plugin so its easier to implement.

[fry_p]

@george1421 I think I misunderstood the meaning of persistent groups off the bat. This is certainly something that can help me with my use case. I am a little embarrassed I didn’t know about this a long time ago to be honest. I got scolded for remote work this holiday weekend already, so I will look into implementing this on Tuesday if it isn’t busy. Thank you for the info!

[fry_p]

I will try to get to this during the coming week. Been crazy at work and am having a rough time right now otherwise. I haven’t been as active here as I would like to be tbh

[p4cm4n]

@george1421
I apologize for ‘hijacking’ this thread, although I believe my request is very similar to @fry_p
Almost as a template would work, which I would expect would almost work similarly in fogserver backend as persistent groups would. I do understand how the persistent groups work, however, as I noticed along with others had mentioned when I’d tried it on that thread, the basic issue we ran into was that the settings weren’t deployed per se to the machines. We’d still have to go deploy those to the machines.

What I was thinking about over the course of the last few months after persistent groups didn’t work for me specifically, was something along the line of a template.

Three methodologies I’d thought of:

1. Quick Register - an option to use a template, similarly setup to how a group would be setup. In QuickReg, you can do quite a few options, but for me the ability to add one more - a template would be awesome. Say for example, if I were to choose template (4) then snapins (x,y,z) / AD OU / prodkey / even numbering scheme would be beneficial. these snapins would be assigned at image, so with zero touch, the settings would auto-deploy.
2. full Registration - Similarly, during the B&W console where you type in your preferred settings for a machine, yet another line (do you want to associate a template with host (y/N/?) - where the template for the remainder of the modifications - group, product key, AD, snapins - would then auto populate.
   these snapins would be assigned at image, so with zero touch, the settings would auto-deploy.
3. template setup very identical to groups. But host agnostic where it isn’t assigned to any one host - quite opposite of groups where templates are literally only used for the initial setup of a machine, not long term management

I’m grateful for the features and uses we have as it is. I just know that as I setup new machines at different sites (my use case is as an MSP working in schools - 27 currently deployed fogservers, most with minimal hosts, but makes initial large deployments a breeze - but for my use case, I could bring a crummy laptop in with fog installed, and re-image a cart full of laptops very quickly. join to domain, install snapins, yadda yadda. the labor intensive part to me is still the ‘adding’ them to fog. my choices are to install the client pre-image, which then associates with fog so i can add as a group - OR the more likely scenario for me, boot, f12, pxe, fullreg, hostname, no group (at this point is almost useless to join to group), assign snapins 1-12, deploy, reboot, f12, pxe, move to next machine.

while i’m already multitudes faster than my cohorts on the Apple side of things (no MDM because of funding oddities with our clients) where they have to carbon copy clone 4 machines at a time with external hard drives - i can reimage a lab in 15 minutes…the only issue because the initial adding, which for summer projects and the like make this tedious.

also/or the ability to add snapins to quickreg. so certain snapins are assigned in quick reg, so that those snapins are auto-deployed when imaging takes place as well. that would work for me too.

[george1421]

@p4cm4n said in Associate all new hosts with Snapin:

the basic issue we ran into was that the settings weren’t deployed per se to the machines. We’d still have to go deploy those to the machines.

Can you explain this a bit more? I can tell you the plugin creates a database trigger that copies settings from the template system to the newly added host to the group. This is done on a database level via a hack. What may be missing is to inform the application layer that a database has been made. I don’t know so I’m only guessing a the moment. I’m not saying the hack is perfect so I need to understand what is missing.

1. …but for me the ability to add one more - a template would be awesome

So the inventory system should then ask what / if there should be a default group assigned to the newly registered computer?

2. full Registration - do you want to associate a template with host (y/N/?)

You have to remember that fog 1.x.x doesn’t have the concept of templates, that is only created by the hack (plugin). So the concept of associate a template is not accurate, but if it was posed as “do you want to associate with a default group” Then it would be in line with the FOG design. I know its semantics but we can’t reference a feature in the main code that isn’t in the main code base.

3. template setup very identical to groups…

Yes the function is very similar. The hack had to integrate into FOG without changing the FOG code base. In fog “Groups” should be thought about as configuration “set” groups because once the “set” is approved the group “itself” doesn’t actually contain any values. So new members added to the group will not know what has been set before. That is why I created the persistent groups db trigger.

OR the more likely scenario for me, boot, f12, pxe, fullreg, hostname, no group (at this point is almost useless to join to group), assign snapins 1-12, deploy, reboot, f12, pxe, move to next machine.

Just so I understand the “uselessness to join a groug” is in regards to assigning to the group doesn’t start the snapins for deployment? (Understand, I’m trying to understand the root of the problem here).

also/or the ability to add snapins to quickreg. so certain snapins are assigned in quick reg, so that those snapins are auto-deployed when imaging takes place as well. that would work for me too.

I can look into the code for the quick reg, if it can be done in the full registration, there shouldn’t be a reason why it can’t be done in quick reg (again said without looking at the code).

I can see validity in your requests here. Ideally the right answer is to add persistent groups to the code base and make it a built in feature. Unfortunately that is not on the roadmap for the 1.x.x line of code and FOG 2.x.x is still a few years off I fear.

But surely keep the good ideas coming. I would like to understand what is missing with the persistent groups plugin hack.

[p4cm4n]

@george1421
yes. so ideally, with the ‘hack’ method with persistent groups - lets say i would go the route i understand.
create template host and template group.
assign template host to template group, assign properties to template host.
add additional hosts to group.

even so, lets say i do full reg. it asks if i want to associate to a group. this is awesome and will effectively get the settings that i need - however, when it asks if i want to deploy the image, and i hit yes, the machine gets imaged. nothing that was ‘set’ is actually ‘deployed’ but rather with the sql hack/trigger, its just a property of the host - but the sql function hasn’t actually ‘pushed’ those settings because maybe it doesn’t know its been changed?

i ran into the issue and as i read through your post for basic persistent groups, other people were having the same issue. so i gave up and scrapped the idea.

i do think code wise it would probably be easy to implement for quick reg.

[george1421]

@p4cm4n said in Associate all new hosts with Snapin:

assign template host to template group, assign properties to template host.

No don’t do this because it will create a loop. The names have to be exactly the same that is all.

Every host added to the template group will cause the database trigger to fire copying the host template settings over to the host just added to the group.

nothing that was ‘set’ is actually ‘deployed’ but rather with the sql hack/trigger, its just a property of the host

Its possible that the settings are made in the database but because of database caching the FOG application may not see the changes until the cache is refreshed. So are you saying that the settings on the template host are not being copied over (like OU or some other parameter field) or is this a question about the snapins not installing?