Assign default group, bundle or package branch to new computers

[bruienne]

I've been doing auto-enrollment with our Macs successfully by adding them to the Unit appropriate for the Mac's location. The remaining issue standing in the way of a fully automated workflow from writing the image to a Munki-controlled bootstrap is applying a certain "standard" load of tools for us - Centrify for AD binding and Trend Micro AV. I don't think there's currently a configuration option to assign a standard group, bundle(s) or package(s). Would this be a welcome option for others, perhaps on a per-Unit basis? I'm decently familiar with the code at this point but I'm not quite sure what the most logical way would be to implement something like this.

Anyone have suggestions/feedback/plans?

Thanks,

Pepijn.

[Ricky Chilcott]

Hi Pepijn,

I saw your code snippet to enroll Macs via a rudimentary API from the PSU Mac Admins Conference. Do you plan on doing a pull request for this code? 

I think it should be per unit, and it could live in one of two places.  We've talked for a LONG time about having some sort of User/System/Unit based settings and an appropriate admin panel for each.  That's never been done because a) it's a lot of work, b) there's not a clear way on how to do it and c) we're not sure the full scope of what needs to be customized.  If we were to add that functionality, it would be a clear place for this setting.  See: https://github.com/jnraine/munkiserver/issues/89 https://github.com/jnraine/munkiserver/issues/5 https://github.com/jnraine/munkiserver/issues/100

The other location it could live is just having a default_group_id attribute on each Unit which could then be set.  Of course, your auto-enrollment code would look for a group_id to be provided, and if it's not, fall back to default_group_id.  

Do you anticipate that setting ONLY effecting auto-enrollment?  When you create computers manually, the UI could default to a specified group too.

Ricky Chilcott

ri...@rickychilcott.com

--
You received this message because you are subscribed to the Google Groups "munkiserver-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munkiserver-d...@googlegroups.com.
To post to this group, send email to munkise...@googlegroups.com.
Visit this group at http://groups.google.com/group/munkiserver-dev.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[bruienne]

Heya Ricky, thanks for watching my PSU Mac Admins talk, I hope I did right by the Munkiserver project =)

You're right, my "API" is rudimentary and I've considered a number of methods. I was mostly concerned with app security and best practice. Obviously it's easy to wrap a simple if statement around the needed methods. I also considered using the "before_filter :except => []" construct but that was not always as reliable, probably because I didn't get the flow of parameters and inheritance quite right. I can submit a pull request once I flesh out the basic auto-configure parameter-based method a bit more for a few other likely candidates. Right now I have it working for automatic package uploading (about to release a first version of an import tool that I wrote, using that) and for auto-enrolling new computers from an installer PKG.

As for default settings, I agree with the per-Unit setup. As a first attempt adding a default_group_id would probably have the least impact, with just the need for an additional DB column and some UI integration. I'm still in learning mode on Rake et al., but I can give that a shot and/or take any pseudo code queues from others who are more skilled.

It would definitely be worth to expose a default group on the GUI side since there'll always be a need to manually enter a computer record and having it entered into a default group would be very helpful by eliminating the need to assign some basic package branches or bundles to it.

Thanks for the feedback.

Pepijn.

[Ricky Chilcott]

Pepjin, Are you based in the US?  I'd be interested in talking through some of these ideas with you and figuring out how best to do it.  If you are, we could do a Google Hangout sometime.

Jordan and I talked a long while ago about each User in munkiserver having a API key and that this API key mechanism would be your authentication mechanism and we could re-use the existing permissions code for authorization for each API key.

Also, one challenge that we face is that most APIs will return JSON or XML, but most code that would utilize the API (like deploy studio, a package installer, or other command line tools) are written in shell -- making it impossible to parse.  perhaps we could develop some mechanism to return executable shell code that would allow you to populate a shell variable for parsing.  Think JS/JSON and callback functions.  Maybe that needs more explanation.  Just spit balling here.

Lastly, I'm not sure if the API should be inline with existing controllers or whether it should be in separate API controllers. Thoughts?

Ricky Chilcott

ri...@rickychilcott.com

[Gregory Neagle]

On Jun 30, 2013, at 3:21 PM, Ricky Chilcott <ri...@rickychilcott.com> wrote:

Also, one challenge that we face is that most APIs will return JSON or XML, but most code that would utilize the API (like deploy studio, a package installer, or other command line tools) are written in shell -- making it impossible to parse. 

Two approaches that come to mind:

1) Recommend people use Python, Ruby, or some other language with decent JSON and XML support to work with the API.

2) Use the XML flavor known as "plist" -- people using shell can use `defaults` or `PlistBuddy` to read and write plists.

-Greg

[Pepijn]

I'm in EDT, so any time between 9 AM and 4 PM is generally fine, caveat the upcoming July 4th break in the latter part of this week.

As for the question on what to return from an API, I think Greg's points are the ones I would make. I know from experience that JSON/XML parsing is very easy with Python, same with Ruby. Parsing plists as an alternative can be done with the shell tools Greg highlights, and one could indicate which flavor the response should be quite easily in the request. I've tinkered with some of the response formatting Rails can do and it seems pretty trivial.

I've been reading through various "how to add an API to your Rails app" posts and articles and I think that for clarity's sake separate API controller(s) would be smart, tell me if something like this pseudo-code makes sense:

class ComputersAPIController < ComputersController

  *override existing methods for API use*

Generally the API methods would pretty much perform the same actions, sending back requested data in one of the supported data formats; json, xml/plist.

We can discuss in more detail in a call.

Thanks,

Pepijn.

[Ricky Chilcott]

I'm in EDT, so any time between 9 AM and 4 PM is generally fine, caveat the upcoming July 4th break in the latter part of this week.

Cool.  The week after I'll plan to setup a time with you to pair on the project -- or at least talk about some stuff that we could realistically implement.

As for the question on what to return from an API, I think Greg's points are the ones I would make. I know from experience that JSON/XML parsing is very easy with Python, same with Ruby. Parsing plists as an alternative can be done with the shell tools Greg highlights, and one could indicate which flavor the response should be quite easily in the request. I've tinkered with some of the response formatting Rails can do and it seems pretty trivial.

I wasn't thinking about Plist when I wrote my first email.  Since we already have Plists being generated for the munki repo stuff, let's continue to use it.  I think we should support the API in both JSON and Plist. I can't imagine standard XML would ever be needed by anyone and I'm not volunteering to do any work with other formats like SOAP/WSDL :)

I've been reading through various "how to add an API to your Rails app" posts and articles and I think that for clarity's sake separate API controller(s) would be smart, tell me if something like this pseudo-code makes sense:

class ComputersAPIController < ComputersController

  *override existing methods for API use*

Generally the API methods would pretty much perform the same actions, sending back requested data in one of the supported data formats; json, xml/plist.

We can discuss in more detail in a call.

I'm torn.  The current inlining of an API keeps all the logic, instance variables, etc, the same.  However, there is a lot of complexity here, and the API won't need to be that complex that quickly.  So, I think we should implement in new controllers (maybe using something like RABL).

Your method would work, but from a security standpoint, we only want those controllers doing EXACTLY what we need them to do, no more, no less.

Ricky