ClientIdentifier/Manifest question

[Chris George]

Apologies again for what likely is a n00b question. I'm trying to wrap my mind around the easiest implementation of ClientIdentifiers and manifests for our implementation. Right now, we are using DeployStudio to push out InstaDMG created images that include the local MCX settings. We aren't running with an OpenDirectory infrastructure. We are using and joining machines to Active Directory, but without extensions. My goal is to avoid having to write manifests for every single machine. While it is doable - I only have a little over a hundred machines - it's additional work when there are very few truly unique machines. Most can be broken down into groups of machines that are similar to each other.

Out of the box, I understand I could create unique manifests identifying machines by short name, FQDN, serial number, or if specified at the client, the ClientIdentifier. I could also leverage the site_default manifest. I could also nest manifests.

I'm thinking as a post-deployment script in DeployStudio, I could do a defaults write and specify the same ClientIdentifier on all machines that share similar characteristics (i.e. "MacLab," "GraphicsLab," "PublicRelations" etc.) and then any "outliers" I could create unique manifests for and change their clientidentifer manually. Not sure that this is a good idea or not.

I could instead use the site_default manifest coupled with a list of conditionalitems, such as hostname BEGINSWITH "GraphicsLab-", but that too could get a little complex, and seems rather "flat" and somewhat inflexible.

I understand the "best way" for you may not be the "best way" for everyone. That said, does anyone have any recommendations based on the information above? Is the "best way" just to bite the bullet and create individual manifests, nesting where applicable?

[Joe Wollard]

I organize my manifests into directories for groups. Each directory contains a template manifest and a 'group' manifest. The template includes the group manifest and otherwise represents the manifest that I would expect machines within that given group to have. To be clear, nothing but included_manifests is specified in the template; the group manifest contains the actual software listings.

Then on the client side, I have a first boot script that changes the ClientIdentifier to <group>/<hostname>. It also sends that information to a little php script I wrote on the server that takes care of copying these templates to the appropriate locations. In this way, I have the benefit of having one manifest for each machine combined with the the ability to manage their software from one single manifest, but I never have to create any manifests manually aside from the group and group template.

Another, and probably much easier way to go about this is to simply use the group concept and then create machine-specific manifests on an as-needed basis. The trick is finding the best way to determine what group a machine belongs to in your environment. For me, I've added a custom app top my DeployStudio workflow that allows me to select the appropriate group from a drop down list. For you, maybe you can infer the group based on subnet, model, other.

[MiqViq]

Joe, thanks for your info.

I am planning to do the same kind of reorganization for my manifests.

Howeve, DS Runtime is very limited what type of apps one can run in it.
For example, plainold AppleScript does not seem to work...

How did you build that helper app for choosing group, is it PyObjC or native Cocoa?
Can you share the source for it?


- MiqViq

[Tim Schutt]

Hey Chris,

IMO, you are better off creating unique manifests per machine and then embedding application bundles that are customized per department rather than conditional items in the site_default. We have about 250 machines in munki right now, and the majority are pretty unique. If you use something like MunkiWebAdmin and just make the manifest creation part of your deployment workflow, it's not bad - not saying that unique is the way to go for you, but I've found it to be easier than the conditional stuff.

However, here's something that may help with your Deploy Studio workflow. We have a small bash script that we use to set up machines in both offices (where they may be unique) and Labs (where every machine is the same). The script looks for information in the 4th computer information field in the DS Hostname form (that we have at the beginning of all of our workflows), and if it finds nothing there it will then look at the machine name and set the Client Identifier to that value.

That way if you have a lab, just throw the ClientIdentifier in the 4th field. If you don't, make a unique manifest named the machine name.

The one caveat with this method is a machine will ALWAYS have a ClientIdentifier, so it will never look to the site_default. We embed that as the first item in our machine manifests every. single. time.

Doesn't really address the organizational issues you're pondering, but may help with one step along the way.

Hope it's helpful.

Tim.

Script follows (not the most elegant, but it does the job):

#! /bin/bash

### This script checks for a value in the fourth custom field set by ARD/DeployStudio

### and then the computer name (in the Sharing prefpane).

### If a value exists in the custom field, it sets the Client Identifier in 

### ManagedInstalls.plist to that value, other wise it sets the ClientIdentifier to

### the Computer Name.

SYSCLIENTID=$(scutil --get ComputerName)

CUSTCLIENTID=$(defaults read /Library/Preferences/com.apple.RemoteDesktop Text4)

if [ -n "$CUSTCLIENTID" ]

then

defaults write /Library/Preferences/ManagedInstalls ClientIdentifier $CUSTCLIENTID

else

defaults write /Library/Preferences/ManagedInstalls ClientIdentifier $SYSCLIENTID

fi

exit 0

[Joe Wollard]

On Jan 20, 2013, at 1:39 AM, MiqViq <miq...@gmail.com> wrote:

> Joe, thanks for your info.
>
> I am planning to do the same kind of reorganization for my manifests.
>
> Howeve, DS Runtime is very limited what type of apps one can run in it.
> For example, plainold AppleScript does not seem to work...
>
> How did you build that helper app for choosing group, is it PyObjC or native Cocoa?

It's native objective-c/cocoa.

> Can you share the source for it?

I've had an offline discussion about this with another community member, and I'm glad that others are interested. Of course, I'd be happy to, but before I do I need to clean things up a bit so that it becomes a little more obvious where and how to use it outside of my own environment.

I'll reply to this thread when I've got something on GitHub.

[Joe Wollard]

Sorry it's taken me so long, but here's my not-very-cleaned-up code for Munki Manifest Selector and its corresponding DeployStudio script. If you find it useful enough to find bugs or to have feature requests, please report those on GitHub, not here.

https://github.com/buffalo/Munki-Manifest-Selector

Happy munki'ing/deploying,

-- Joe

On Tue, Jan 22, 2013 at 4:10 AM, Nicolas Michel <nicolas...@gmail.com> wrote:

Dear Cedric

I don't have actually Munki in prod, but I plan to so I have to answer to this question for myself.
So I'll give my opinion and I hope if I say a stupid think, someone will tell it.

As you say, Munki give you ability to have either a ClientIdentifiers for each computer or  some ConditionalItems.

Personally, I think there's no interest in a deployment solution that is not  centralized.
In case of changes, if I have to connect to a computer to add a software in the ConditionalItems.plist manually,
I'll stop with munki and install the soft manually.

In an other hand, centralized means "in one point".
Having an inventory here, a directory there, and a list of ClientIdentifiers and manifest in a 3th place looks to be the way to have inconsistencies.
So the most elegant solution for me is to use the directory.
AD, OD or whatever, It's still a directory. You can create computer groups, isn't it ?

Why don't you make a short bash script that will ask AD,
It check for computer groups and if your client is in the "Mac-Photoshop-CS5" group,
then your script write a line in the local ConditionalItems.plist

I didn't made script for AD from few year, but I suppose it's still in the same way,
you can either use dscl or ldapsearch. The script can be handled and deployed by Munki and once it's done,
all you'll have to do is to keep your AD clean, which is a good think, no ?

My 2 cents

Nicolas Michel

--

Joe Wollard

[Nick McSpadden]

I am totally trying this out, thanks Joe!  This looks like a huge time saver for me, rather than having to create separate workflows for every single different manifest.

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

--
--

Nick McSpadden

Client Systems Manager

Schools of the Sacred Heart, San Francisco

[Joe Wollard]

Excellent! I've only compiled this on mountain lion, but I know it runs on my lion DS NetBoot set. However, I can always provide a compiled download via Dropbox if that would help anyone out.

---

Joe Wollard

[Anthony Hunt]

Hi Joe,

Sorry to resurrect this post from a while ago.  I like your management method for managing your clients.  I wondered if you might share your insight into how your script creates the manifests?

I was thinking about how your DS booted client creates it's manifest before "attaching" to it.  My machines live in a sub folder called "machines".  I guess your passing the client name from DS to a php script (via http?) which creates an empty manifest?

Any clues to this part of your setup would be really useful.  My set up is currently nested groups would like to move it to individual clients then nested groups and getting this part of the DS deployment working would be the icing on the cake.

Really brilliant DS tool by the way!

Thanks,

Anthony.

[Joe Wollard]

On Sun, Oct 20, 2013 at 3:59 PM, Anthony Hunt <ant....@gmail.com> wrote:

Hi Joe,

Sorry to resurrect this post from a while ago.  I like your management method for managing your clients.  I wondered if you might share your insight into how your script creates the manifests?

A simple copy operation. I have a directory representing departments/scopes of machines, each one with a manifest in it called 'generic'. The Munki Manifest Selector app that I wrote (specifically for my environment, but if it suits yours as well, all the better) contains a drop down list representing each of these directories. Once the tech clicks "Okay" to confirm their selection, the app performs a GET request to a PHP script on the server and provides the techs selection as well as a unique identifier for the machine. The selection is expected to be an existing directory within $repo/manifests/. The PHP script looks for a manifest in that directory called 'generic' and copies it to $unique_identifier (for example). That's pretty much it.

 

I was thinking about how your DS booted client creates it's manifest before "attaching" to it.  My machines live in a sub folder called "machines".  I guess your passing the client name from DS to a php script (via http?) which creates an empty manifest?

See above; the 'generic' manifest would be more aptly named 'template', and contains everything I expect that department/scope to have.

 

Any clues to this part of your setup would be really useful.  My set up is currently nested groups would like to move it to individual clients then nested groups and getting this part of the DS deployment working would be the icing on the cake.

Really brilliant DS tool by the way!

Thanks,

Anthony.

--

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

--

Joe Wollard

[Nathan Felton]

It's kinda eerie that this thread was brought alive again as my co-workers and I were just discussing this functionality of Munki this week. We were curious if the community, most notably the Munki Developers, would be willing to potentially change the order of precedence for a client looking for manifests. We would be interested in seeing it work pretty much exactly the way Chris was originally asking about at the start of this thread.

Our scenario:

We deploy around 300 computers with Munki, with growing interest from other departments and groups on campus. Currently, we have been using munki-enroll (https://github.com/edingc/munki-enroll) to create machine specific manifests and having them include area/lab/department specific manifests. While this works, I find it to be a bit messy and unnecessary as we now have about 290 manifests that do not have any additional software beyond what is in the included area/lab/department specific manifest. 

We would like to be able to only need our core manifests (about 7) for each area/lab/department and configure our clients with a ClientIdentifier. If a machine needs any special or additional software, we would like to be able to create a machine specific manifest that would "overrule" the ClientIdentifier.

If the order of precedence changed from:

ClientIdentifier, FQDN, "Short" hostname, Serial Number, "site_default"

to

FQDN, "Short" hostname, Serial Number, ClientIdentifier, "site_default"

we would be able to achieve this configuration without (from what I can tell) effecting anyones current munki configuration.

I may be missing something completely in this thought process, so let me know what your thoughts are. Is anyone currently using a configuration in their environment that this change would drastically effect their current setup?

Nathan Felton

@n8felton

[Gregory Neagle]

Sorry, I am not interested in this change.

If a ClientIdentifier is set, that's what Munki will request from the Munki server. Full stop. Explicit configuration should always override automatic configuaration. See below for more.

On Oct 23, 2013, at 4:59 PM, Nathan Felton <n8fe...@gmail.com> wrote:

It's kinda eerie that this thread was brought alive again as my co-workers and I were just discussing this functionality of Munki this week. We were curious if the community, most notably the Munki Developers, would be willing to potentially change the order of precedence for a client looking for manifests. We would be interested in seeing it work pretty much exactly the way Chris was originally asking about at the start of this thread.

Our scenario:

We deploy around 300 computers with Munki, with growing interest from other departments and groups on campus. Currently, we have been using munki-enroll (https://github.com/edingc/munki-enroll) to create machine specific manifests and having them include area/lab/department specific manifests. While this works, I find it to be a bit messy and unnecessary as we now have about 290 manifests that do not have any additional software beyond what is in the included area/lab/department specific manifest. 

We would like to be able to only need our core manifests (about 7) for each area/lab/department and configure our clients with a ClientIdentifier. If a machine needs any special or additional software, we would like to be able to create a machine specific manifest that would "overrule" the ClientIdentifier.

If the order of precedence changed from:

ClientIdentifier, FQDN, "Short" hostname, Serial Number, "site_default"

to

FQDN, "Short" hostname, Serial Number, ClientIdentifier, "site_default"

we would be able to achieve this configuration without (from what I can tell) effecting anyones current munki configuration.

Not true.

I have some dual boot machines. The primary partition has no ClientIdentifer set, and so gets the manifest named the same as its "short" hostname.

The secondary partition has a ClientIdentifer set, pointing to an alternate manifest.

Your proposed change would break this -- when booted from the secondary partition, Munki would still use the "short hostname" manifest, ignoring the ClientIdentifier I set.

-Greg

[Nate Walck]

I have to agree with Greg on this one. Specific client configuration should always overrule the automatically "discovered" manifests.

If looking through a list of 270 manifests is tedious or seems wasteful, you will change your mind if you ever *do* need to assign software to one machine or a bunch of individual machines. It is hard to predict the future and what seems unnecessary now may be useful in the future. A great example of this is some crappy software that is one license key per machine. You could script the customization of the individual, serialized packages and then assign each package to each machine that it belongs to. I had one manifest for a whole lab and I got stuck breaking out manifests out for each machine and assigning the software. Yea it wasn't fun. I didn't think it would be useful until it was all of a sudden useful.

I guess my point is, it doesn't make sense to change the functionality of munki for everyone just to have a cleaner manifests folder. Text editors like Sublime Text (among others) make finding the manifest you want almost effortless, so I no longer mind having 800 manifests in one directly.

Nate

Nathan Felton wrote:

        <mailto:munki-dev%2Bunsu...@googlegroups.com>.

        For more options, visit https://groups.google.com/groups/opt_out.




    --
    Joe Wollard

    --
    You received this message because you are subscribed to the Google
    Groups "munki-dev" group.
    To unsubscribe from this group and stop receiving emails from it,
    send an email to munki-dev+...@googlegroups.com

    <mailto:munki-dev%2Bunsu...@googlegroups.com>.

    For more options, visit https://groups.google.com/groups/opt_out.




--
Nathan Felton

@n8felton <https://www.twitter.com/n8felton>

[Nathan Felton]

Thank you for your responses. I had not considered either of your scenarios and I value your insight. Nate's comment about having pre-existing manifests potentially being useful in the future when I least expect it makes sense, even if I don't feel it is needed in my environment.

While I now understand your environments would not benefit from this being a core change to munki, could this instead potentially become a configuration option, allowing it to be a choice of the admin deploying Munki? One idea could be to allow the MangedInstalls.plist to contain an array with the preferred order of precedence. This would allow for an additional client explicit configuration to override the current built-in automatic configuration.

<key>mainifest_precedence</key>

<array>

   <string>ClientIdentifer</string>

   <string>FQDN</string>

   <string>short_hostname</string>

   <string>serial_number</string>

   <string>site_default</string>

</array>

Perhaps if the key does not exist in ManagedInstalls.plist, the "default" would be for Munki to operate as it does today. If the key does exist however, it changes the order of precedence to the order defined in the array.

I would be willing to attempt to write a patch to help implement some form of this functionality, but I do not want to make the attempt if there is little or no chance of it being pulled into the existing code. If this were a feature request only I was interested in, I would accept it and move on, but it appears there are others interested in a similar functionality; otherwise, munki-enroll or this email chain may not exist.

Thank you for your time.

--

Nathan Felton

@n8felton

[A.E. van Bochoven]

Most of the licensed software we distribute has either a campus license or uses a license server. 

We use clientidentifiers (we only have a handful) to distinguish between managed machines and self-maintained systems.

We use conditional items for adding packages to specific machines (based on serial number). 

-Arjen

[Gregory Neagle]

I think you'd be better off implementing some sort of dynamic manifests/ClientIdentifiers, either client-side ala:

https://code.google.com/p/munki/wiki/WPKGlikeDynamicManifestsWithoutCGI

https://code.google.com/p/munki/wiki/DynamicClientConfigurationsViaPreflightScripting

or by implementing something server-side; a CGI or PHP app or web app that returns the desired manifest to the client.

-Greg

[Nathan Felton]

After exploring the use of the dynamic manifests mentioned in the links, I found that it is difficult to use client-side dynamic manifests in our environment due to their reliance on the preflight script, which is also used by MunkiReport-PHP which we wish to also use in our environment. Due to this conflict, rather than attempt to code some form of server-side CGI, I decided to attempt to move forward with modifying the behavior of the munki code to allow for the configuration of the manifest precedence rather than attempt to continue to code workarounds to the root problem.

I have modified the updatecheck.py code so that it will allow a sysadmin to set the manifest precedence via the "ManifestPrecedence" preference in ManagedInstalls. By default, the code is backwards compatible so that munki will behave as it always has, so long as the "ManifestPrecedence" setting is not set. I ask that you consider testing this updated code with your current (test) environment to ensure its backwards comparability while still enabling the functionality that myself and others in the community would be interested in using. This update can be found at my dev clone of munki at https://code.google.com/r/n8felton-munki/source/detail?r=9416ef0e84372bbed5382f936ec1d0bff829b566

The intended workflow is to enable this setting via an array, such as

sudo defaults write /Library/Preferences/ManagedInstalls ManifestPrecedence -array ShortHostname FQDN SerialNumber ClientIdentifier SiteDefault

This will allow a client's "ClientIdentifer" to be overridden by another manifest defined in the array. This would be set at deployment time, so that in the future if there was a need for a client specific manifest, there would be no need to reconfigure the client's configuration, you would only need to create the client specific manifest on the munki repository. Additionally, if one of the options is not set, such as "SiteDefault", munki will not attempt to look for that manifest.

I have tested this in my environment to the best of my ability and I would appreciate someone taking a look at it for potential implementation into the core sourcecode of munki.

[Steve Yuroff]

I like this idea a lot.  I've decided that my 3 manifests for the organization is not the ideal way, but 1 manifest/client makes for many unnecessary, redundant manifests.  Asking "is there any manifest special for this client? If yes, use it, if not, fall back to broader use case manifest" would be great.