LocalOnlyManifest Idea

[Brian Warsing]

I was hoping to begin a discussion about the idea of a LocalOnlyManifest.

I cannot say for certain whether or not this subject has been broached before, but I'd like to hear everyone's thoughts.

Fact: You can insert a package name into the managed_installs array in the SelfServeManifest, but the item will be ignored if the software title is not offered as an optional_install somewhere amidst the client's assigned manifests.

I find myself wanting to manage a LocalOnlyManifest -- that is, a manifest managed not at the Munki Web Server level, but locally the client's machine.

Why would I want this?

The contents of a LocalOnlyManifest could be determined programmatically or managed by another agent (Puppet, Chef).

The SelfServeManifest functions in a similar capacity, so without looking at the code base, I am optimistic that such a feature would be possible to implement without a large set of changes.

If it looks plausible, would such a feature implementation be welcome?

Am I overlooking anything or oversimplifying the problem?

Thanks,

—
B.

[Gregory Neagle]

Manifest URLs can be file://localhost URLs, so you can implement a “LocalOnlyManifest” today with zero code changes.

-Greg

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
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.
To post to this group, send email to munk...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nate]

If I am understanding Brian correctly, I believe this would be another manifest similar to SelfServeManifest that munki would check in *addition* to the manifest found on the server. This would allow someone using config management to tell munki to install something without injecting it into SelfServeManifest (which is fiddly at best).

Would you be opposed to something like this so long as someone else wrote the code? ;)

Nate

[Gregory Neagle]

See also https://groups.google.com/d/msg/munki-dev/QKCoFmdUeXc/m9KNAhLJSMYJ (and I see Mr Warsing you participated in that thread!)

-Greg

On Sep 22, 2015, at 8:41 AM, Brian Warsing <daygl...@gmail.com> wrote:

[Gregory Neagle]

Let’s see first if what Brian wants can be achieved with no code changes to Munki.

-Greg

[Nate]

I'll let Brian confirm if I am on the right track or not, but we inject items into SelfServeManifest as well and it is not ideal for the reason he described.

Nate

[Brian Warsing]

> On Sep 22, 2015, at 8:43 AM, Gregory Neagle <gregn...@mac.com> wrote:
>
> Manifest URLs can be file://localhost URLs, so you can implement a “LocalOnlyManifest” today with zero code changes.

Right, but I was hoping to use a LocalOnlyManifest to augment the whatever existing assigned manifest presently is.

The major objective for me is to grant admins a quick way of adding software assignments on a per-machine basis.

So, rather than having admins create a new manifest, upload, etc. for a machine that maybe requires 1 or 2 extra apps, we would use a LocalOnlyManifest which added these extras.

—
B.

[Nate]

I love that idea. We currently allow users to managed the state of their own machine via config management, so it would be pretty sweet if they could make sure that X application was installed on every machine they use.

Nate

—
B.

[Gregory Neagle]

I have a hard time understanding how creating a new manifest and somehow getting it onto the client machine is easier than creating a new manifest and putting it in the Munki repo.

-Greg

[Brian Warsing]

On Sep 22, 2015, at 8:47 AM, Gregory Neagle <gregn...@mac.com> wrote:

See also https://groups.google.com/d/msg/munki-dev/QKCoFmdUeXc/m9KNAhLJSMYJ (and I see Mr Warsing you participated in that thread!)

Haha! This isn't quite the same thing, but there is similarity on idea of a Local manifest.

My main point was that creating a Puppet provider was probably not required.

—

B.

[Nate]

One is done server side and one is done client side. With this, LocalOnlyManifest would be a bridge between the config management tool and munki, locally.

It would be better to write this out locally on the machines than distribute it globally across every munki server we have. It is far more efficient to write the file out to 1-5 machines than however many servers you have. I will always have more servers than one end user will have machines.

As Brian said, it is two different ways of handling it, both in a similar vein. Doing it on the server side is the least efficient from a config management point of view.

This could also allow some nifty tricks for interaction between munki and an arbitrary outside process.

Nate

[Mike Dodge]

I agree with Nate. This would allow a lot of people the ability to make small customizations without the need of giving them munki server access.

[Brian Warsing]

> On Sep 22, 2015, at 9:07 AM, Nate <nate....@gmail.com> wrote:
>
> One is done server side and one is done client side. With this, LocalOnlyManifest would be a bridge between the config management tool and munki, locally.
>
> It would be better to write this out locally on the machines than distribute it globally across every munki server we have. It is far more efficient to write the file out to 1-5 machines than however many servers you have. I will always have more servers than one end user will have machines.
>
> As Brian said, it is two different ways of handling it, both in a similar vein. Doing it on the server side is the least efficient from a config management point of view.
>
> This could also allow some nifty tricks for interaction between munki and an arbitrary outside process.

Wow. Excellent summary.

It's difficult to definitively ascribe the value of this, but there is an overhead to creating a manifest.

I see this as another level of Self-Service.

A "bridge" as Nate phrased it.

—
B.

[Gregory Neagle]

So what is preventing a user from using this to grant himself/herself access to any and all software available from your Munki repo?

SelfServeManifest contents are filtered against optional_installs; if something is not in optional_installs for a machine, it will be ignored if it’s in the SelfServeManifest:

https://github.com/munki/munki/blob/master/code/client/munkilib/updatecheck.py#L3081-L3085

I’m not opposed to this idea, but I do think a lot more thinking-it-through needs to be done.

-Greg

[Brian Warsing]

> On Sep 22, 2015, at 9:36 AM, Gregory Neagle <gregn...@mac.com> wrote:
>
> So what is preventing a user from using this to grant himself/herself access to any and all software available from your Munki repo?

If they're admin, nothing -- I don't know that there would be any reasonable way to prevent this.

Of course, if they're an admin, they'd have access to the catalogs directory which would provide them ample information on how to pillage software.

—
B.

[as...@siprep.org]

So is the idea proposed for a LocalOnlyManifest that it would still be a subset of optional installs (as Greg rightly points out—if it's not a subset, then anyone can grant herself access to anything)?

And then the person would carry around this self-serve manifest on a thumb drive to all the machines she uses?

I'd love to hear more about the use cases here. So if I'm a user who has a laptop and uses a desktop, too. One day, I get a second desktop, and I create a manifest for myself of all I usually install and then instead of launching up Managed Software Center and installing those items, I copy the manifest file to a certain location on the new machine and then wait for Munki to install that stuff?

I might be misunderstanding this.

[Brian Warsing]

> On Sep 22, 2015, at 9:49 AM, as...@siprep.org wrote:
>
> So is the idea proposed for a LocalOnlyManifest that it would still be a subset of optional installs

No. Completely distinct from optional_installs.

> (as Greg rightly points out—if it's not a subset, then anyone can grant herself access to anything)?

Yes.

> And then the person would carry around this self-serve manifest on a thumb drive to all the machines she uses?

Potentially, but more likely the file would be managed in some other way (Puppet, Chef, script?).

> I'd love to hear more about the use cases here. So if I'm a user who has a laptop and uses a desktop, too. One day, I get a second desktop, and I create a manifest for myself of all I usually install and then instead of launching up Managed Software Center and installing those items, I copy the manifest file to a certain location on the new machine and then wait for Munki to install that stuff?

Yes. That scenario would be possible in the proposed feature, but only if the user were an administrator.

—
B.

[as...@siprep.org]

Since this seems to be predicated on "SelfServeManifest [being] ...fiddly at best," wouldn't it make more sense to see if there's a way to make SelfServeManifest less fiddly? That could extend the functionality beyond LocalOnlyManifest but also help with LocalOnlyManifest (since you could use Chef to modify the SelfServerManifest file directly).

[Gregory Neagle]

Not sure exactly what’s “fiddly” about modifying the SelfServeManifest. I think the bigger problem for Brian is the one he mentioned in his original post:

"Fact: You can insert a package name into the managed_installs array in the SelfServeManifest, but the item will be ignored if the software title is not offered as an optional_install somewhere amidst the client's assigned manifests.”

…and presumably he mentions this because he wants to include software that is _not_ in optional_installs.

-Greg

[Brian Warsing]

On Sep 22, 2015, at 10:05 AM, as...@siprep.org wrote:

Since this seems to be predicated on "SelfServeManifest [being] ...fiddly at best," wouldn't it make more sense to see if there's a way to make SelfServeManifest less fiddly?

It's not simply awkward to manage the SelfServeManifest, it requires that the software titles you insert be available as optional_installs.

This implies to me that the SelfServeManifest is purpose-built -- it is to record ephemeral installations by end users.

A LocalOnlyManifest would not be a user-controllable manifest.

—

B.

[Erik Gomez]

It sounds like there are potentially two requests and a caveat to at least one of them. 

1. Manifest that can be configured via "desired state".

2. Manifest that can be manipulated. 

These two could potentially be interchangeable, but this will also allow software packages to be added outside of what is currently available to the machine/user. 

If this does happen, I would prefer an option to disable this (this being adding options outside of what they have available) entirely. I don't want someone being able to install $expensivesoftware outside of our internal control, especially in an automated fashion. 

Sent from my iPhone

[Nick McSpadden]

Theoretically, anyone with admin access already _can_ by simply looking at the catalog.  Munki doesn't really enforce restrictions on available software in a technical sense.

--

--
Nick McSpadden
nmcsp...@gmail.com

[Erik Gomez]

Sure and that's definitely a great counter argument, but this is significantly easier and could be easily automated. 

Nate - get to coding! :) 

Sent from my iPhone

[Gregory Neagle]

Accessing the catalog can indeed help an admin user find installer_items. It doesn’t cause Munki to install them. This may or may not be an important difference, but if it’s not important, then there is a lot of unimportant code in Munki around performing installations; special code for handling Adobe products; support for dependencies; pre- and postinstall_scripts, etc.

-Greg

[Nick McSpadden]

Personally, I think the risk of a user installing software from Munki not in the manifest is less of an issue than the benefit of being able to manage instantaneous munki installs from a client-side configuration, managed by a config management tool.  

[Gregory Neagle]

On Sep 22, 2015, at 11:59 AM, Nick McSpadden <nmcsp...@gmail.com> wrote:

Personally, I think the risk of a user installing software from Munki not in the manifest is less of an issue than the benefit of being able to manage instantaneous

instantaneous?

Is there a feature expectation here I missed?

[Brian Warsing]

> On Sep 22, 2015, at 11:59 AM, Nick McSpadden <nmcsp...@gmail.com> wrote:
>
> Personally, I think the risk of a user installing software from Munki not in the manifest is less of an issue than the benefit of being able to manage instantaneous munki installs from a client-side configuration, managed by a config management tool.

To add to Nick's sentiment...

I less worried worried about a user automating the installation of a bunch of software on a computer I can control, than harvesting an entire catalog, taking it home and distributing on the web.

Which is more probable?

—
B.

[tackyy]

> The contents of a LocalOnlyManifest could be determined programmatically or managed by another agent (Puppet, Chef).

> It's not simply awkward to manage the SelfServeManifest, it requires that the software titles you insert be available as optional_installs.

So how does Puppet/Chef or another agent know what’s available? It seems to me if the manifest the client is using has “Foo" and “Bar" in it the outside agent or user wouldn’t be able to know that "Baz" exists in order to add it to a LocalOnly. ManagedSoftwareUpdate doesn’t download the all catalog (if my MSU logs are any indication). So all couldn’t be used for discovery.

I don’t see a way around hitting up the server for some answers. And if this is really a local override of the repo… eventually we’re going to want to manage all these overrides. So it all comes back to the server eventually. And it seems that per-machine manifests are already way ahead of us here.

tack

[Gregory Neagle]

I am less worried about that, too. My organization employs adults that we generally trust and can fire (or otherwise discipline) if they do something wrong/illegal/etc.
But my worries aren’t important here — I’m not the only person using Munki. If we add a feature like this, what is the response to other Munki admins who ask how they can turn it off?

-Greg

[MiqViq]

Without any further thinking I would say that to enable a new feature admin has to intentionally enable (or disable) it from Munki prefs with a specific key/value.

- MiqViq

[Gregory Neagle]

This. If I want to add a particular piece of software to a specific machine, I edit that specific machines’s manifest on the server.

I don’t see “ability to easily add software to a specific machine” as a compelling reason to add this functionality. Enabling Puppet to manage things seems more compelling.

[Gregory Neagle]

Right, but if what we are doing is trying to prevent an admin user from making unauthorized use of this feature, said admin user could just add the specific key/value to Munki’s preferences.

You’ve just made it a little less convenient.

-Greg

[MiqViq]

Then let's use encrypted preference files ;-)

- MiqViq

[Erik Gomez]

Perhaps I wasn't clear: I really like this idea. I just want an option where the user can't add arbitrary items they don't have access to. 

I have no problem with them automating Foo and Bar, but I don't want them being able to install Baz unless they already have it available to them. 

If that specifically can be managed in the munki prefs, I'm all for it. 

Sent from my iPhone

[Brian Warsing]

> On Sep 22, 2015, at 12:08 PM, Gregory Neagle <gregn...@mac.com> wrote:
>
> This. If I want to add a particular piece of software to a specific machine, I edit that specific machines’s manifest on the server.

I truly get this, I do, but...

What if you needed to grant somebody within your org the ability to do one-off installations, but you could not grant them access to the Munki repo?

Instead, you gave them an interactive script that could populate a LocalOnlyManifest with software titles available in which ever catalogs were available.

—
B.

[Nate]

Let me make sure I am understanding everything and we have covered the cases.

Could I not modify the client manifest on disk and get at the software I want anyways? Isn't this possible today? 

You scope what software a client can get using catalogs. If it is in the catalog, they can install it, regardless of what you have in their manifest (as one could modify the manifest today to get software).

Could I not also add other catalogs to my manifest and munki could then cache them? You would need to know the catalog names, so this isn't really feasible.

This would not add any more risk than exists today as far as I can tell. It is just another manifest that is listed on disk which essentially gets merged with whatever the server hands out.

Nate

[Brian Warsing]

Erik,

To be clear, the proposal is not to make the LocalOnlyManifest user-controllable.

It would be local and only administrators would have the ability to manipulate its contents, not users.

This is hardly different than the conditions now.

Case in point, if I were to do what Greg reminded me I could in the first reply, that is use a "file://localhost" in the ManifestURL preference, I could automate the installation of whatever was in the catalog.

So, I am not sure that there any effective difference other than the fact that a LocalOnlyManifest would be used to augment the existing assigned client_manifest.

Otherwise, if somebody wanted to automate the installation of a bunch of software using a manifest they carried around on their thumb drive, I am pretty sure they'd be able to do it anyway.

—

B.

[Brian Warsing]

> On Sep 22, 2015, at 12:25 PM, Nate <nate....@gmail.com> wrote:
>
> Let me make sure I am understanding everything and we have covered the cases.
>
> Could I not modify the client manifest on disk and get at the software I want anyways? Isn't this possible today?
>
> You scope what software a client can get using catalogs. If it is in the catalog, they can install it, regardless of what you have in their manifest (as one could modify the manifest today to get software).
>
> Could I not also add other catalogs to my manifest and munki could then cache them? You would need to know the catalog names, so this isn't really feasible.
>
> This would not add any more risk than exists today as far as I can tell. It is just another manifest that is listed on disk which essentially gets merged with whatever the server hands out.

Correct AFAICT.

—
B.

[tackyy]

It’s still a LOT of tooling around the very few instances where per-machine manifests and optional_installs don’t cover it. It seems like the best thing to do is give that person an admin acct on their mac, an installer and an entry in the Ledger of Scary Power Users.

tack

[Mike Dodge]

if someone has physical access, you have already lost. There has to be some level of trust between you and your co-workers/users. With enough time someone would be able to reverse engineer how munki works and download every piece of software. The all catalog would give you enough information to find any other catalogs and now you know all the necessary information to download all available software. I think managing server or client manifests are as equally secure.  

[Gregory Neagle]

So what’s wrong with this approach?

https://groups.google.com/forum/#!msg/munki-dev/QKCoFmdUeXc/m9KNAhLJSMYJ

It seems to offer exactly what you are asking for.

-Greg

[Brian Warsing]

The interactive script example I provided was a little on-the-nose.

I do see the potential for a a scripted solution like, munki_do.py, but I have to wonder why it needs to be external?

The overarching theme of that thread was: "How do I use Puppet to install packages using Munki?"

I am not asking Puppet to install packages; I want Munki to install packages

But, I do want Puppet to configure and control state.

Part of the state I wish to control is a LocalOnlyManifest.

Why? The argument, no matter how you look at, comes down to convenience and ease of use.

The way I see it, this is functionality that is already present, waiting to be unlocked.

It doesn't present any significant difference in security, other than providing a well-defined behaviour for what is already possible.

I could tell you exactly how I intend to use and I am still not certain it it would persuade.

In all this, I still think the bridge analogy is the best way to describe the idea.

—

B.

[Gregory Neagle]

On Sep 22, 2015, at 1:27 PM, Brian Warsing <daygl...@gmail.com> wrote:

On Sep 22, 2015, at 1:06 PM, Gregory Neagle <gregn...@mac.com> wrote:

On Sep 22, 2015, at 12:25 PM, Brian Warsing <daygl...@gmail.com> wrote:

Instead, you gave them an interactive script that could populate a LocalOnlyManifest with software titles available in which ever catalogs were available.

So what’s wrong with this approach?

https://groups.google.com/forum/#!msg/munki-dev/QKCoFmdUeXc/m9KNAhLJSMYJ

It seems to offer exactly what you are asking for.

The interactive script example I provided was a little on-the-nose.

I do see the potential for a a scripted solution like, munki_do.py, but I have to wonder why it needs to be external?

The overarching theme of that thread was: "How do I use Puppet to install packages using Munki?"

I am not asking Puppet to install packages; I want Munki to install packages

But, I do want Puppet to configure and control state.

Part of the state I wish to control is a LocalOnlyManifest.

So do that.

The munki_do script (or its logical descendant) would then _use_ that manifest.

Why? The argument, no matter how you look at, comes down to convenience and ease of use.

The way I see it, this is functionality that is already present, waiting to be unlocked.

So start implementing it. You can do it initially with NO code changes to Munki. Once you work out more of the details, it might make sense to merge it into Munki “natively”. But we’ll see.

It doesn't present any significant difference in security, other than providing a well-defined behaviour for what is already possible.

I could tell you exactly how I intend to use and I am still not certain it it would persuade.

Until I see why the ideas behind “munki_do” are not sufficient to get started, I will take the path of “less work for me”. Even if you did persuade me this needs to be in Munki itself, I probably would not write the code, but would leave it to you or the Facebook folk to implement (hint: you should do it)

[Brian Warsing]

On Sep 22, 2015, at 1:33 PM, Gregory Neagle <gregn...@mac.com> wrote:

I could tell you exactly how I intend to use and I am still not certain it it would persuade.

Until I see why the ideas behind “munki_do” are not sufficient to get started, I will take the path of “less work for me”. Even if you did persuade me this needs to be in Munki itself, I probably would not write the code, but would leave it to you or the Facebook folk to implement (hint: you should do it)

But, I already filed the feature request. Isn't that like a sacred trust or something? ;)

—

B.

[Nate]

https://github.com/munki/munki/pull/520

Nate

[Brian Warsing]

Wow. Nice. I will start testing ASAP.

Thanks, Nate.

—

B.

[bryanzak]

Our help desk staff do not have access to the munki servers and so don't have access to manifests.

But, they do have ARD and remote access to client computers.

So for example, a user requests Google Earth. Yes, it's an optional install, but for whatever reason they can't (won't?) do it themselves (or maybe the request is to add it to five classroom computers or an entire lab or something).

If our help desk could use a script to add Google Earth to this idea of a "local manifest" that would be an interesting use case and would provide a benefit to us.

[Mike Pullen]

I do this kinda thing with munki-conditionals. I (or any of our net admins) assign machines to WGM groups, then I have a munkiconditional script that parses group membership to app manifests: for example, there's a manifest that installs GoogleEarth; i make that an included manifest for that machine if the machine (or a group of which the machine is a member of) is a member of the "munkiapp_googleearth" WGM group. (My OD-based munkiconditionals script is at https://github.com/mikep345678/munkiconditionals/blob/master/munkiconditionals.sh if you're interested.)

You could do the same with a local manifest, or text file, or even just touch a file (e.g., something like touch /Library/Managed\ Installs\munkiconditionals/munkiapp_googleearth) then build a munki-conditional script to parse the local manifest or file or to check for existence of files. You must be consistent with your manifest names and however you tag that machine, but otherwise it should be cake.

(FWIW, am hoping to eventually be able to move my munkiconditionals to AD groups instead of OD groups (we're golden-triangled but are trying to quit), but nested computer groups don't work the same way in AD as in OD so I've back-burnered that project for a while...)

Mike

[chymb]

We also use conditionals with a local manifest plist.

We use them to make certain software available as "Optional Installs" but could presumably make them "Managed Installs".

[Mike Solin]

In your example, I’d control their machine with ARD, with them on the phone.  Open Managed Software Center for them, find the application on the Software tab, then click Install.  Show them how to do it.

We have manifests structured so that every Mac has an individual manifest.  Every individual manifest gets a “core software” manifest that includes Flash Player, Java, etc.  Labs also get the “labs” manifest.  Additionally, every lab also has a manifest for the entire room.  We can easily add an application to an entire lab by modifying that manifest.  Since our labs don’t change often, it’s less work for me to create them by hand (we use Munki Enroll for faculty/staff machines, which change names much more often).

This discussion regarding the ‘all' catalog misses an important point: if you switch your Munki server to SSL and basic authentication, your users cannot access the catalogs without the correct username and password.  This raises the requirements for accessing your repo outside of Munki - not only do they need to have a basic familiarity of how a Munki repository is set up, they need to figure out your username/password to gain access.

If they’re not admins, you can do a reasonable job of protecting the username and password:

https://github.com/munki/munki/wiki/Using-Basic-Authentication#protecting-the-password-from-local-users

Yes, everything can be reversed somehow - Target disk mode, or another boot disk, will allow your users to check “ignore permissions on this drive” for the primary boot disk, read the contents of that file, reverse the base64, login to your Munki repo, download the ‘all' catalog, then _potentially_ install software (assuming they correctly include any preinstall scripts, postinstall scripts, other packages required, etc.).  If someone’s going to all of that trouble, though, they probably know they’re doing something they’re not supposed to.  Notify IT Security and/or HR.

If you’re concerned about ExpensiveApplicationX being installed on people’s computers, use MunkiReport’s inventory feature to track which computers have it installed, regardless of how they got it.  The AppVersions report is a good use for this, but you can build your own dashboard module, too.

I’m not the target audience for the requested feature (we don’t use Puppet, Chef, or Ansible) but I honestly don’t see how this solves a problem that couldn’t already be solved with nesting manifests inside machine-specific manifests (or possibly using conditionals).

Mike

-- 

mi...@mikesolin.com / @flammable
http://mikesolin.com

[Mike Solin]

And actually, you can prevent the Target disk mode / other boot disk scenario by enabling firmware passwords.  That, and removing admin permissions from your users, should effectively prevent them from reading /private/var/root/Library/Preferences/ManagedInstalls.plist.

Mike

-- 

mi...@mikesolin.com / @flammable
http://mikesolin.com

[bryanzak]

I suspect the most common problem is that the Help Desk can't remote in if the teacher isn't at their computer to give permission.

And (in my admittedly contrived example) that'd be tedious for the HD to do for a request to load something on a set of lab computers.

I'm not saying this particular local manifest idea is super important to us, just that we would probably find some value in it.

Bryan

[Gregory Neagle]

On Sep 24, 2015, at 6:02 AM, bryanzak <brya...@mac.com> wrote:

I suspect the most common problem is that the Help Desk can't remote in if the teacher isn't at their computer to give permission.

And (in my admittedly contrived example) that'd be tedious for the HD to do for a request to load something on a set of lab computers.

Why wouldn’t you just add the software to the machine’s manifest on the server?

I'm not saying this particular local manifest idea is super important to us, just that we would probably find some value in it.

Bryan

On Thursday, September 24, 2015 at 2:24:12 AM UTC-5, Mike Solin wrote:

In your example, I’d control their machine with ARD, with them on the phone.  Open Managed Software Center for them, find the application on the Software tab, then click Install.  Show them how to do it.

[nate....@gmail.com]

If a user is an admin, they can easily get the pass from the munki config and it is trivial to download any catalog they want. 

If this manifest is only writable as an admin, it is equally secure, so there is no additional risk.

Nate

[bryanzak]

I would, but the help desk staff can't.

With 8,000 staff and 14,000 Macs in Munki sometimes it's easier for the Help Desk to just push whatever app they want via ARD. That's fine, that gets things done. But unless that app happens to be in the managed_updates it means it won't get any future updates

Bryan

[Erik Gomez]

So this will now only benefit admin users and "desired state" configurations?

Sent from my iPhone

[Brian Warsing]

> On Sep 24, 2015, at 7:43 AM, bryanzak <brya...@mac.com> wrote:
>
> That's fine, that gets things done. But unless that app happens to be in the managed_updates it means it won't get any future updates

Nor would you be able to audit, record or re-apply that same configuration.

—
B.

[Brian Warsing]

> On Sep 24, 2015, at 8:07 AM, Erik Gomez <eriknico...@gmail.com> wrote:
>
> So this will now only benefit admin users and "desired state" configurations?

Admin users, yes. Local Admins only.

"Desired state" configurations?

What do you mean exactly?

If you are implying that this feature would only benefit people using state management tools, I would strongly disagree.

—
B.

[Gregory Neagle]

But unless you capture that LocalOnlyManifest it's still hard to audit, record, or re-apply this configuration.

This is why it's unlikely I'll actually use this feature in my environment.

Sent from my iPhone

[Brian Warsing]

Yes. Absolutely, but it can be done, programmatically.

—
B.

[nate....@gmail.com]

Munki won't manage the permissions on this file. You the admin can allow anyone or no one the ability to edit it, that is your design decision for your own infrastructure. 

Nate