Added LocalOnlyManifest feature #520

Merged
merged 1 commit into from Oct 26, 2015

Projects

None yet

4 participants

@natewalck
Contributor

Added the feature discussed here: https://groups.google.com/forum/#!topic/munki-dev/lgnBUFyMfAo

The feature is basic right now and only handles managed_install and managed_uninstalls. As this is not self-service, it behaves more like the main manifest than selfservemanifest.

I'd like to be able to specify the catalog in LocalOnlyManifest and use conditionals as well, but I wanted to get this basic version out first before complicating it too much.

@gregneagle
Contributor

Doesn't the local only manifest get deleted after a Munki run because of this code:
https://github.com/munki/munki/blob/master/code/client/munkilib/updatecheck.py#L2629-L2655
?

@natewalck
Contributor

I had considered that and added it to the exceptions list, but it was still disappearing. Perhaps something else was going on when I was testing it.

@gregneagle
Contributor

Seems pretty important to address, I'd think.

@natewalck
Contributor

Ah, I think what I ended up doing was stashing it in /Library/Managed Installs. I assume it should go into /Library/Managed Installs/manifests?

@gregneagle
Contributor

Probably, though we risk namespace collision. Some admin will have a LocalOnlyManifest named "foo" and a server manifest named "foo" and wonder why things aren't working. I guess we can't protect people from every mistake.

@natewalck
Contributor

Since we are using a key with an arbitrary value, should I make a global for the LocalOnlyManifest name, or just read the preference again to add it to the Exceptions list?

@gregneagle
Contributor

I'd look at the MANIFESTS dictionary...

@natewalck
Contributor

Instead of adding it to the Exceptions list, I added it to MANIFESTS. Seems to behave as desired.

@keeleysam
Member

Why not skip reading preferences and just have it with a static reserved name?

@gregneagle
Contributor

We want the admin to opt in.

@keeleysam
Member

So have a boolean preference to enable the behavior instead of the manifest name?

@gregneagle
Contributor

Manifest name is fine, though.

@keeleysam
Member

But if you use a static name for it then there's going to be less of a worry about namespace collision

@gregneagle
Contributor

But if the admin can choose the name, they are in control. If we pick a static name someone is already using for a (server-based) manifest, we'll cause a problem. I think it's fine as-is.

@natewalck
Contributor

I updated the code to throw an error if this edge case happens and ignore the LocalOnlyManifest. This should make it more obvious what the problem is.

@gregneagle
Contributor

Nice. By that time the "LocalOnlyManifest" has been overwritten by the manifest retrieved from the Munki server, but at least the poor admin has some idea what is going on.

@dayglojesus
Contributor

Works like a charm.

@natewalck
Contributor

Looks like this is working as expected. Will this be merged or abandoned?

@gregneagle
Contributor

I'll merge it if one of you will write documentation and also post to munki-dev about how to test it/use it.

@gregneagle
Contributor

<...crickets...>

@natewalck
Contributor

Thats fine, I'll write up some docs and add a diff for them (and email munki-dev/discuss)

@gregneagle gregneagle merged commit f7f4b70 into munki:master Oct 26, 2015
@gregneagle
Contributor

Merged!

@dayglojesus
Contributor

Had not checked my Gmail until now. Thanks,

@dayglojesus
Contributor

@natewalck Can I help with that documentation?

@natewalck
Contributor

Sure thing! Let me know if you need anything.  

Nate

On Mon, Oct 26, 2015 at 2:41 PM, Brian Warsing notifications@github.com
wrote:

@natewalck Can I help with that documentation?

Reply to this email directly or view it on GitHub:
#520 (comment)

@dayglojesus
Contributor

I added the prefs key and blurb to the wiki under Preferences.

Do we need more?

@gregneagle
Contributor

I think the feature needs its own wiki page.

@dayglojesus
Contributor

Under which heading? Was the level of detail in the blurb sufficient? Anything missing?

@gregneagle
Contributor

Move most of the "blurb" to its own page and link to it from the Preferences page.
In its own page you can talk about use case and give examples.

@gregneagle
Contributor

"This example ensures Firefox remains installed and GoogleChrome remains uninstalled, overriding any other references to these packages in site_default."

I do not believe this is accurate.

@dayglojesus
Contributor

LocalOnlyManifest will not take precedence over server-side manifest?

@dayglojesus
Contributor

Also, under which heading do you want the new page?

@natewalck
Contributor

It only supports installs at the moment.

On Tue, Oct 27, 2015 at 10:11 AM, Greg Neagle notifications@github.com
wrote:

"This example ensures Firefox remains installed and GoogleChrome remains uninstalled, overriding any other references to these packages in site_default."

I do not believe this is accurate.

Reply to this email directly or view it on GitHub:
#520 (comment)

@gregneagle
Contributor

"LocalOnlyManifest will not take precedence over server-side manifest?"

Try it.

There is no concept of precedence in manifest processing. If an item is listed in managed_installs in one manifest and managed_uninstalls in another manifest, the result may not be what you expect.

@natewalck
Contributor

Oh I lied. 

It behaves exactly as if you had the installs and uninstalls set on the server.

On Tue, Oct 27, 2015 at 10:13 AM, Brian Warsing notifications@github.com
wrote:

Also, under which heading do you want the new page?

Reply to this email directly or view it on GitHub:
#520 (comment)

@gregneagle
Contributor

"Also, under which heading do you want the new page?"

Create the page. We'll worry about where it appears in the index/TOC later.

@dayglojesus
Contributor

Re: "no ... precedence", I'll take your word for it, but let me ask... If I have a SelfServeManifest that specifies install Firefox and a server-side one that specifies uninstall Firefox, which one wins?

@gregneagle
Contributor

I do not remember and do not promise that the current behavior will always remain so. It's an admin error and the result is undefined and should not be relied upon.

@gregneagle
Contributor

Actually, now that I read your question again, that's a simple answer. Items that are explicitly listed as managed_installs or managed_uninstalls are NOT in the final optional_installs list offered to the user; therefore they cannot be chosen for install. If they are in the SelfServeManifest's managed_installs list and the admin later adds them to a managed manifest's managed_installs or managed_uninstalls: I do not remember the specific behavior here and would have to look at the code: but the intention would be that the SelfServeManifest entries would be ignored. The intention is that the admin's managed choices "filter" what is available for optional install.

Since I did not write the implementation for LocalOnlyManifest, I don't know how or if any of that implementation interacts with server-side manifests, but there is no lower-level generic handling of manifest "precedence".

@dayglojesus
Contributor

Interesting. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment