Munki vs Absolute Manage (Also Manifest Hierarchy Questions/Suggestions/Best Practices)

[Cody Eding]

Hello everyone,

Now that we're past the beginning of this school year, we are already looking into our Mac software management for the 2013-2014 school year. Currently, our tech department supports Macs are four different school districts. Two of those districts are using Absolute Manage to handle software distribution, while the other two (smaller) districts are using Munki. In addition, I use Munki as part of our imaging workflow (to install all of the software automatically).

Absolute Manage was purchased and installed before I started my position here, while I implemented Munki for our smaller districts because they had no software management whatsoever. Recently, there has been a push from the higher ups to require the purchase of Absolute Manage to be part of our "technology consortium." After working extensively with both pieces of software for the past few months, I believe Munki is a better solution that Absolute Manage, but I need to show that to the higher ups. 

A good start would be to clean up my manifest structure to make it more flexible. Currently this is the kind of structure I have (reading left to right, the left manifiests are included in the furthest right manifest):

base --> district1_base --> district1_labA

base --> district1_base --> district1_staff

base --> district2_base --> district2_labA

base --> district2_base --> district2_staff

This is great if all of the computers are a homogenous environment (labs for instance). But, in one district, teachers are delivered speciality software on a per-computer basis. So, what I'd like to know, is whether or not this kind of setup is possible?

base --> district1_base --> district1_staff --> hostname

base --> district2_base --> district2_staff --> hostname

I would want the "hostname" manifest to be dynamically generated on first check in to the server. We have thousands of Macs I would want to potentially manage, so there's no way we could individually create records as the computers are imaged. Perhaps there is a way I could do this in a DeployStudio script rather than a Munki preflight check?

One more question: Is it possible to organize manifests in folders inside of the manifests folder on the server? For example:

manifests

---- district_1

--------- district1_labA

I really enjoy using Munki, and I'd like to keep using it. The community support is great (and better than the paid support of Absolute Manage) and I'd love to get to a point of contributing back to the community.

Thanks.

Cody

---

Cody Eding
Client Services Technician - Macintosh Deployment and Support

OAISD Technology Services

[Joe Wollard]

On Thu, Oct 18, 2012 at 8:14 AM, Cody Eding <cody....@gmail.com> wrote:

Hello everyone,

Now that we're past the beginning of this school year, we are already looking into our Mac software management for the 2013-2014 school year. Currently, our tech department supports Macs are four different school districts. Two of those districts are using Absolute Manage to handle software distribution, while the other two (smaller) districts are using Munki. In addition, I use Munki as part of our imaging workflow (to install all of the software automatically).

Absolute Manage was purchased and installed before I started my position here, while I implemented Munki for our smaller districts because they had no software management whatsoever. Recently, there has been a push from the higher ups to require the purchase of Absolute Manage to be part of our "technology consortium." After working extensively with both pieces of software for the past few months, I believe Munki is a better solution that Absolute Manage, but I need to show that to the higher ups. 

I feel your pain ;-)

 

A good start would be to clean up my manifest structure to make it more flexible. Currently this is the kind of structure I have (reading left to right, the left manifiests are included in the furthest right manifest):

base --> district1_base --> district1_labA

base --> district1_base --> district1_staff

base --> district2_base --> district2_labA

base --> district2_base --> district2_staff

This is great if all of the computers are a homogenous environment (labs for instance). But, in one district, teachers are delivered speciality software on a per-computer basis. So, what I'd like to know, is whether or not this kind of setup is possible?

base --> district1_base --> district1_staff --> hostname

base --> district2_base --> district2_staff --> hostname

Yes it is. I know there are more official methods of accomplishing this, and I believe Munki Server (https://github.com/jnraine/munkiserver) does this as one of its default installation scenarios. I'm accomplishing this via a little custom scripting. On my munki server, I placed a manifest-manager.php script which is capable of creating manifest plists which inherit from the "base" manifest that is appropriate for the client that called it. The clients call this script as part of a run-once boostrap script that I have on each machine. The conversation goes something like this:

client: "Hi, my name is 'foo' and my generic manifest is 'BarDept'"

server: "Hi "foo", your custom manifest is now located in 'BarDept_clients/foo'. Update your settings accordingly."

On the server side, the BarDept_clients/foo manifest automatically inherits from BarDept (and BarDept inherits from my "Core" manifest, and so on). Pretty handy when you need to install a chunk of software for an entire department _or_ a single user.

 

I would want the "hostname" manifest to be dynamically generated on first check in to the server. We have thousands of Macs I would want to potentially manage, so there's no way we could individually create records as the computers are imaged. Perhaps there is a way I could do this in a DeployStudio script rather than a Munki preflight check?

One more question: Is it possible to organize manifests in folders inside of the manifests folder on the server? For example:

manifests

---- district_1

--------- district1_labA

Yep. Just watch for duplicate manifest names. On the Munki client, the namespaces provided by that folder structure are not preserved. In other words, "district_1/labA" becomes "labA" on the client. So far I believe I'm the only one who has encountered this behavior (and I was kinda trying to see what I could break at the time), so it's not a huge issue.

 

I really enjoy using Munki, and I'd like to keep using it. The community support is great (and better than the paid support of Absolute Manage) and I'd love to get to a point of contributing back to the community.

Thanks.

Cody

---

Cody Eding
Client Services Technician - Macintosh Deployment and Support

OAISD Technology Services

--

Joe Wollard

[Cody Eding]

Thanks for the great response, Joe. It's much appreciated. I will look into the bootstrap script that assigns a new manifest name. 

One question though: I just did a test by sticking manifests in sub-folders and my test client no longer sees the manifest (404 error). Is this not the correct setup?

[Joe Wollard]

Something isn't quite right in your setup if you're getting a 404, it's just a question of 'what'.

If I understand correctly, you started off with something like...

• base
• district1_base  (included_manifests ["base"])
• district2_base  (included_manifests ["base"])
• district1_labA  (included_manifests ["district1_base"])
• district1_staff (included_manifests ["district1_base"])
• district2_labA  (included_manifests ["district2_base"])
• district2_staff (included_manifests ["district2_base"])

...and you want to change it to something like...

• base
• district1_base (included_manifests ["base"])
• district1/
• district1_labA  (included_manifests ["district1_base"])
• district1_staff (included_manifests ["district1_base"])
• district2_base (included_manifests ["base"])
• district2/
• district2_labA  (included_manifests ["district2_base"])
• district2_staff (included_manifests ["district2_base"])

Keep in mind that the paths in included_manifests are relative to the "manifests" directory, not the manifest itself. So if you wanted district1_staff to include district1_labA, the included_manifests path would be district1/district1_labA even though they are both in the same directory. Same goes for the client configuration. If a client needs to look at district1_staff, then...

/Library/Preferences/ManagedInstalls.plist

...

<key>ClientIdentifier</key>

<string>district1/district1_staff</string>

...

If this is what you've got, tell me what happens when you try to view the manifest in the subfolder using a standard browser? Do you still get a 404? If so, the problem isn't with your Munki configurations and you'd need to double check your paths and filenames to ensure they really are what you wanted them to be (e.g. look for typos).

--

Joe Wollard

[Cody Eding]

Gah. For whatever reason, I was thinking I could just move paths on the server without changing the preference files. Munki isn't THAT smart. My fault. 

Thanks, Joe.

[Joe Wollard]

True, it's not, but you could write a small script that remaps the ClientIdentifiers based on the current value. In that way, you could make Munki that smart ;-)

--

Joe Wollard

[Cody Eding]

Agreed, they're not the same. Absolute does much more. But, I'm speaking strictly from a software deployment standpoint and from the standpoint of our school districts, which do not necessarily want to stomach the cost of Absolute. Munki may not do everything that Absolute does, but it does work perfectly fine for it's purpose in our environment.

On Thursday, October 18, 2012 12:53:04 PM UTC-4, FTBZ wrote:

After working extensively with both pieces of software for the past few months, I believe Munki is a better solution that Absolute Manage.

This comment really made me laugh. Munki is an excellent software, but I don't think that you're comparing the same thing.

Florent B.