Specific OU's during host registration
Developers and fellow ridiculously smart people,
I am trying to find a way to be able to create a question within the “Full Host Registration” to be able to ask what OU I would like to put it in, so this question has 2 parts to it.
- Can there be an option to create the option to choose an OU like you do an image or Snapin?
- Can we export some sort of data from our active directory that would populate the Database in FOG so that when using the ? feature, it would bring up our OU’s and fill the “Orginizational Unit (Blank for Default)” slot for the Host?
I know this is a lot to ask for, but I am always looking for a way to save myself some time and this would be a HUGE time saver.
@tom-elliott thank you so much! You are a rockstar. I look forward to 1.6!
Something like that.
I also have to build new init’s to take into account the ou stuff during registration.
So I finished making the plugin for 1.6.
I haven’t tested it, but that’s why I love the FOG Community.
I’d ask you to switch to the 1.6 branch, but it’s in heavy development and many things likely do not work as expected. My work on the new plugin should make sure things are operationally capable based on looking over everything.
Essentially I just added a hook for the hostname changer when it gets checked from the client. The hook is then used in the OU plugin to alter the host adou field based on the associated host’s OU.
If we were to parse this, location might site? If so does each site have its own IP address range?
What about floor, what is unique about the floor?
The same for place?
The idea here is to find something unique about each specific OU.
I guess a logical question might be how many OUs are we talking about?
@george1421 it is setup as location - floor - Place
@chris-whiteley Well it depends on what you mean by easy? Everything has trade-offs.
Can you provide what your AD structure looks like and how you might calculate the OU?
@tom-elliott Would this request be closer in design to the plugin for managing windows keys? I don’t know what was involved with that plugin, but on the surface it sounds like a similar task.
@george1421 I guess I could look at that as well. I just want the easiest way to do it I guess. (Even though it won’t be super easy :) )
@chris-whiteley Lets look at this from another direction.
Can the target OU be calculated during deployment? I have a complex OU structure [image][hwclass][site][domain] (ou=soe,ou=desktop,ou=nyc,dc=domain,dc=com) that is calculated during image deployment, and I use a post install script to update the unattend.xml file with the proper OU placement. I let the unattend.xml file connect the computer to AD and not FOG.
I would love to chat with you and get help on this. I am not so savvy with too much being in the weeds of linux/database stuff, but I would certainly love to know how to do this. Any time you have I am more than willing to sit and chat.
I think this is easily possible and has been thought about by at least me and I’m sure other developers.
The process seems confusing but ultimately it’s pretty simple.
The simplest method, I think, would be to do something similar with location plugin but for OU’s. I specifically point out location plugin as it does have interaction with the init’s. Seeing as Active Directory is kind of a strong component of the functionality fog provides, I don’t think adding an OU Plugin checking system similar to Locations would be a bad idea.
The only thing I’d like to see is the OU system be a plugin that takes over the OU structures currently available in fog. (FOG Global Settings -> Active Directory, and hosts/groups).
I’d even say, likely, the simplest method to do this would be first to copy the current location plugin and rename it for OU’s.
Of course the things that need to be well thought out:
Database Tables (Likely ou and ouAssoc – just as a quick element).
Structure of the OU table might be: <id, name, description, createdBy, createdTime, ou>
Structure of the OU Assoc table might be: <id, hostID, ouID>
Page would need to be able to add/edit, of course (default elements commonly available.
If you need help with making this a realization, please don’t hesitate to hit me up. Just understand I’m working on getting 1.6.0 along with fixing bugs for 1.5.X series. I’d recommend making the plugin for 1.6 (which you can hit me up on chat so I can walk you through what to do). This is because it’s going to be quite a significant change from 1.5.x and earlier methods of doing things.