munkiimport (updates) with pre/postinstall scripts

[Kris Lou]

Hi all,

Greg's recent update to munkiimport reminded me of something.  

Is it possible for munkiimport to automatically include scripts on updated packages from previous versions?  I.E. Having the FF17 postinstall script be automatically carried over into the newly generated/imported FF18 pkginfo.  Or is it something that will always have to be manually attached?

Thanks,

Kris Lou
kl...@themusiclink.net

[Nate Walck]

I would like to have this as well. I am finding that not importing things such as  post-install scripts tend to add more work than should be needed for importing something as simple as Firefox. 

Perhaps a method to customize which keys get copied automatically?

Nate

Sent from iPhone

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

[Joe Wollard]

Or a switch? Something like --migrate-scripts or possibly a family of --migrate-<key> which would tell munkiimport to use the specified values from the  matching pkginfo with the highest version, if it's available, of course.

---

Joe Wollard

[Gregory Neagle]

Long post ahead. I've covered some of this topic in the past; hopefully this explains the situation more thoroughly...

This has been requested many times over the last year or so. Some enterprising people have even made passes at implementing this functionality:

Heig:

http://code.google.com/r/theheig-conditionals/source/browse?name=munkiimport-config-templates

http://code.google.com/r/theheig-conditionals/source/browse?name=munkiimport-configurables

Tim:

http://code.google.com/r/tim-munki/source/browse?name=munkiimport-more-pkginfo-keys

I think there was a least one other by Adam Reed.

I haven't been happy with any of these. There are some fundamental issues that need to be addressed.

1) makepkginfo discovers certain values from the pkg/diskimage itself. In an ideal world, it could discover everything needed for a working pkginfo. Many of the munki additions, like preinstall/postinstall_scripts, installs items, etc are designed to work around issues with pkgs.

2) #1 means that any workarounds/customizations required for version X of a package are not necessarily needed with version Y of a package -- and may actually do more harm than good.

3) So #2 means that if we aren't 100% confident when copying a key from an older version to a newer version, we should _ask_. But even better, we should give the admin all the info we have to help him/her make a good decision. When creating a new pkginfo, there are lots of choices available for a specific key's value:

a) makepkginfo's default value for a key

b) a value makepkginfo discovered while examining the pkg/dmg

c) a custom value added by an admin for a previous version of the pkg/dmg

d) a new custom value for the key.

4) So we need a way for the admin to be able to review at least 3b and 3c, and ideally 3a, 3b and 3c and choose between them or override them. Just because version X of pkg required a restart or needed a postinstall_script does _not_ imply that version Y needs these same things. The admin needs the right info to make the right choices.

5) None of the approaches so far provide any of the meta information needed by the admin. Frankly I'm not certain this is achievable with a command-line tool without being impossibly complex.

In another reply, Joe Wollard writes:

Or a switch? Something like --migrate-scripts or possibly a family of --migrate-<key> which would tell munkiimport to use the specified values from the  matching pkginfo with the highest version, if it's available, of course.

This just moves the problem -- the admin still needs to know which items have that "extra" info, and if it's appropriate or needed to copy it to a newer version of the pkg.

I'm still playing with approaches.

One approach would be to focus on the keys that are normally empty or set to something other than their default. If such a key is found in the prior pkg info, bring it to the admins attention and ask if they'd like it copied.

munkiimport currently has a list of keys that if present, are just copied: ['blocking_applications', 'unattended_install', 'unattended_uninstall', 'requires', 'update_for'] 

I'm not convinced making this list bigger is the right approach; at least not without per-key admin confirmation.

Ultimately, though, the direction I am leaning towards is a tool that is another level _above_ munkiimport.

This tool would use recipes we could freely share that would do the following:

1) Download the latest version of an item.

2) Make any modifications or do some programatic repackaging

3) Import into Munki and generate a good pkginfo item.

There are several starts at such a tool:

MagerValp's MacAutoPkg: http://code.google.com/p/macautopkg/

Jim Zajkowski's AutoMunki: https://github.com/jamesez/automunki

Adam Reed's AutoMunkiImporter:  http://neographophobic.github.com/autoMunkiImporter/index.html

Each have their strengths and weaknesses; I'm currently mostly playing with MacAutoPkg because it is written in Python, as is Munki. If you are more familar with Perl, you'll probably prefer Adam's tool; Jim's is a mix of Bash and Ruby and was designed for use with Jenkins (though it doesn't require that).

But I think what I'd like to move toward is a sort of "Meta-Munki". Munki is a set of tools you can use to manage your client machines; we're now trying to build better tools to manage our Munki servers.

-Greg

[EG]

This is what I had somewhat asked for a few days ago. What if a switch is added to the current Munkiimport that asks for confirmation of these keys? A simple y/n would suffice and might be of benefit until this "Meta-Munki" is fleshed out.

On Monday, January 28, 2013 6:45:42 PM UTC-6, gregn...@mac.com wrote:

I'm not convinced making this list bigger is the right approach; at least not without per-key admin confirmation.

-Greg

[Nate]

This is what I had somewhat asked for a few days ago. What if a switch is added to the current Munkiimport that asks for confirmation of these keys? A simple y/n would suffice and might be of benefit until this "Meta-Munki" is fleshed out.

This.  I think munkiimport is setup how Greg prefers to use it (after all, he did build it), but I think it would be worth giving us the flexibility of including other keys.  Maybe just go through some common keys when you run munkiimport and have it ask if you would like to be prompted to copy those keys over if present when importing packages.  All it would be is a list of keys to ask about, stored with the other munkiimport config.

I think of the Meta Munki thing as a way of automating other things that may need to be done, not just a key here or there in the pkginfos.  Per's macautopkg allowed more than just selecting a few pkginfo keys and that is what I'd be looking for in the additional tool.

Nate

--
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.

[Gregory Neagle]

On Jan 29, 2013, at 7:17 AM, Nate <nate....@gmail.com> wrote:

This is what I had somewhat asked for a few days ago. What if a switch is added to the current Munkiimport that asks for confirmation of these keys? A simple y/n would suffice and might be of benefit until this "Meta-Munki" is fleshed out.

This.  I think munkiimport is setup how Greg prefers to use it (after all, he did build it), but I think it would be worth giving us the flexibility of including other keys.  

You have _infinite_ flexibility. Fork munkiimport and make it do whatever you want.

Maybe just go through some common keys when you run munkiimport and have it ask if you would like to be prompted to copy those keys over if present when importing packages.  All it would be is a list of keys to ask about, stored with the other munkiimport config.

How would that list get populated? Manual edit of munkiimport's preferences, or do we have to write a new editor for that, too?

I think of the Meta Munki thing as a way of automating other things that may need to be done, not just a key here or there in the pkginfos.  

I think what people are _really_ asking for is this:

"I did a whole bunch of work getting the pkginfo for Foo-1.0 working correctly for me. Now Foo-1.1 has come out and I want to make sure that my new pkginfo contains anything useful/relevant from the previous pkginfo."

or rephrased:

"I've developed a recipe for making a pkginfo item for Foo. There's a new Foo. I want to use that recipe to make a new pkginfo for the new Foo."

That could be addressed by extending munkiimport, or it could be addressed with another tool.  MagerValp and Jim Z and Adam Reed have addressed it for themselves with the tools I mentioned yesterday.

We can discuss the meta-munki thing in a different thread, but I have many reasons for wanting to move that direction: #1:

munkiimport --recipe Firefox

Downloading Firefox.dmg from http://download.mozilla.org...

Importing Firefox.dmg...

Done.

Done correctly, we can remove the need for people to swap pkginfo files and ask about how to generate installs items and so on. The meta-munki will know how to do the right thing for anything we care to create recipes for. And people can_still_ make their own recipes.

Back to the current implementation of munkiimport.

The "helping" munkiimport does by grabbing stuff from a previous pkginfo was originally designed to help with NOT the above, but this:

1) New versions of a pkg need to have the exact same "name" key as previous versions. munkiimport helps with that by looking for older versions that "match" and suggesting the same name. This part is crucial.

2) If you use subdirectories inside your pkgs and pkgsinfo directories, munkiimport imports the pkg and pkginfo into the same subdirectory as a prior version of the pkg.

3) Many packages don't have usable display names or descriptions, so munkimport offers to copy these from a prior version of the pkg.

munkiimport copying the values of these keys: ['blocking_applications', 'unattended_install', 'unattended_uninstall', 'requires', 'update_for'] was a later addition. It wasn't well thought out, as it has the potential to cause problems when done without confirmation. Expanding the list just makes the problem worse.

[Nate]

With the more detailed description of meta-munki, I see where you are going with that.  I think such a tool would be great...we could have a recipe repo for people to use without worrying about the specific issues that exist with sharing pkginfo files.  I think the reason this is mentioned over and over is because we want it to be more automated. A meta-munki would fill that gap nicely.  

So I guess the take away is that if we want something to copy keys automatically RIGHT NOW, we can use any of those proposed solutions.  If we are patient, a meta-munki tool will be released that is much better then just adding the ability to copy X, Y or Z keys.

Sounds good to me.

Nate

[EG]

Only if the option is enabled by default. By adding a switch, the admin takes responsibility and will know that there is still _some_ verification that must be done manually.

[Gregory Neagle]

On Jan 29, 2013, at 10:00 AM, EG <eriknico...@gmail.com> wrote:

Only if the option is enabled by default. By adding a switch, the admin takes responsibility and will know that there is still _some_ verification that must be done manually.

Spell out specifically what you are proposing.

"adding a switch" is pretty vague.

-Greg

On Tuesday, January 29, 2013 11:33:49 AM UTC-6, gregn...@mac.com wrote:

On Jan 29, 2013, at 7:17 AM, Nate <nate....@gmail.com> wrote:

Expanding the list just makes the problem worse.

[EG]

/usr/local/munki/munkiimport --copypkginfo "Firefox-18.0.1" /path/to/installer_item

[Gregory Neagle]

So trying to fill in the blanks here.

--copypkginfo SOMENAME

Is SOMENAME a path to an existing pkginfo file, or is munkiimport expected to search catalogs for that item?

(My feeling is that if you already know you want to copy keys from a specific earlier pkginfo item, just open that in a editor and start copying!)

Which keys are implied to be copied when you specify --copypkginfo ? Is there more to --configure now, and you specify keys to be copied somewhere?

-Greg

On Jan 29, 2013, at 10:07 AM, EG <eriknico...@gmail.com> wrote:

/usr/local/munki/munkiimport --copypkginfo "Firefox-18.0.1" /path/to/installer_item

[Jeremy Reichman]

My personal feeling is that whatever the benefits of a meta-munki, munkiimport is already sort-of like a meta-make-kginfo tool. (How many layers do we need? It's turtles all the way down.)

The way munkiimport currently works in not carrying over keys/values that were explicitly for the previous version of a pkginfo does cause some real, human workflow problems (perhaps above the level of nuisance) where there is more than one Munki admin or perhaps a forgetful single Munki admin. I see and understand the potential for problems in carrying over settings that might no longer be relevant.

I like tools that solve problems that I have. I believe that munkiimport itself should carry over any normally unset keys/values that were however set in the previous version of the pkginfo. That would help both admin teams and individual admin. My preference is that it would be a default behavior. I don't believe in forking Munki, no thanks, I've been through the everyone-has-their-own-Radmind-scripts days.

Ultimately, yes, an admin should review the makepkginfo. Isn't the default for munkiimport to open the resulting pkginfo in the chosen text editor? That's the interface for the final review of all keys/values, not just the ones that appear as on-screen prompts.

Right now, in that final review, I have to know to manually look at the previous version of the pkginfo; munkiimport doesn't help me. I have to visually scan both versions or run a diff between them. Diffs sometimes don't work well because of the relative ordering of the keys, although this probably varies by diff tool. Once I have changes, I have to make a decision to move or not move.

If munkiimport carried the full set of normally-unset keys and values over from the previous pkginfo, at least my team and I would only be reviewing the current pkginfo. We'd have all of the information in front of us, pre-merged together with the new data that munkiimport dynamically determined about the latest pkg/dmg. From a workflow perspective, it's arguably easier to review the hotspots in this single pkginfo than it would be to open and merge in data from a previous pkginfo.

All of that said, I also generally have a feeling that scripting that should span versions of pkginfos probably ought to move out to a separate pkginfo, for modularity. However, since that might result in a nopkg with an install_check, that practice may not be the best pattern, either.

Thanks!

--
Jeremy

[Gregory Neagle]

On Jan 29, 2013, at 10:22 AM, Jeremy Reichman <jah...@jaharmi.com> wrote:

> My personal feeling is that whatever the benefits of a meta-munki, munkiimport is already sort-of like a meta-make-kginfo tool. (How many layers do we need? It's turtles all the way down.)
>
> The way munkiimport currently works in not carrying over keys/values that were explicitly for the previous version of a pkginfo does cause some real, human workflow problems (perhaps above the level of nuisance) where there is more than one Munki admin or perhaps a forgetful single Munki admin.

I don't disagree.

> I see and understand the potential for problems in carrying over settings that might no longer be relevant.

As the primary support person for Munki (as well as the primary developer) I'm not interested in solutions that trade one set of problems for another.

>
> I like tools that solve problems that I have. I believe that munkiimport itself should carry over any normally unset keys/values that were however set in the previous version of the pkginfo. That would help both admin teams and individual admin. My preference is that it would be a default behavior. I don't believe in forking Munki, no thanks, I've been through the everyone-has-their-own-Radmind-scripts days.
>
> Ultimately, yes, an admin should review the makepkginfo. Isn't the default for munkiimport to open the resulting pkginfo in the chosen text editor? That's the interface for the final review of all keys/values, not just the ones that appear as on-screen prompts.
>
> Right now, in that final review, I have to know to manually look at the previous version of the pkginfo; munkiimport doesn't help me.

That's something I'd like to fix. munkiimport _should_ help you with this.

> I have to visually scan both versions or run a diff between them. Diffs sometimes don't work well because of the relative ordering of the keys, although this probably varies by diff tool. Once I have changes, I have to make a decision to move or not move.
>
> If munkiimport carried the full set of normally-unset keys and values over from the previous pkginfo, at least my team and I would only be reviewing the current pkginfo.

Against what? How do you know which keys were generated from inspecting the pkg/dmg, which ones are makepkginfo's defaults, and which were copied from a previous pkginfo?

> We'd have all of the information in front of us, pre-merged together

Merging throws away data.

> with the new data that munkiimport dynamically determined about the latest pkg/dmg. From a workflow perspective, it's arguably easier to review the hotspots in this single pkginfo than it would be to open and merge in data from a previous pkginfo.
>
> All of that said, I also generally have a feeling that scripting that should span versions of pkginfos probably ought to move out to a separate pkginfo, for modularity. However, since that might result in a nopkg with an install_check, that practice may not be the best pattern, either.
>
> Thanks!
>
> --
> Jeremy
>

[Hannes Juutilainen]

Chiming in since I've been thinking about this a lot lately with MunkiAdmin. I call it "assimilating" a pkginfo with another. The current implementation looks like this when done manually:

--

Hannes Juutilainen

[Gregory Neagle]

Wouldn't this be better/more useful if you could actually _see_ what you were copying?

As an example: Munki can sometimes derive things like minimum_os_version and supported_architectures from the pkg itself.

In most cases, I'd think you'd want to keep what Munki found in the pkg itself, and _not_ copy the value from a prior pkginfo.

How is that info communicated to the admin? It probably should be.

-Greg

On Jan 29, 2013, at 10:29 AM, Hannes Juutilainen <hjuuti...@mac.com> wrote:

Chiming in since I've been thinking about this a lot lately with MunkiAdmin. I call it "assimilating" a pkginfo with another. The current implementation looks like this when done manually:

<Screen Shot 2013-01-29 at 20.22.12.png>

--

Hannes Juutilainen

On 29.1.2013, at 20.11, Gregory Neagle <gregn...@mac.com> wrote:

So trying to fill in the blanks here.

--copypkginfo SOMENAME

Is SOMENAME a path to an existing pkginfo file, or is munkiimport expected to search catalogs for that item?

(My feeling is that if you already know you want to copy keys from a specific earlier pkginfo item, just open that in a editor and start copying!)

Which keys are implied to be copied when you specify --copypkginfo ? Is there more to --configure now, and you specify keys to be copied somewhere?

-Greg

On Jan 29, 2013, at 10:07 AM, EG <eriknico...@gmail.com> wrote:

/usr/local/munki/munkiimport --copypkginfo "Firefox-18.0.1" /path/to/installer_item

--
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.
 
 

--
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.
 
 

[Heig Gregorian]

I won't try to promote my solution, as THE solution, especially since Greg has presented a few more items which alter the overall scope.  I will however say that what I had been working on provided the ability for one to create configuration files for use with munkiimport which would define which keys should be copied over from previous versions, which keys an admin should be prompted to confirm/modify, along with a few other pieces...  I wish I had received more community feedback on my endeavors while the iron was hot so to speak as I gladly would've made appropriate changes to satisfy the need.

You could call these configuration files "recipes" and with a bit more engineering with consideration to Greg's points, I'm pretty sure it could get the job done.

As a slight aside, one of my goals with adding additional pkginfo key options to makepkginfo and allowing munkiimport to essentially "access" them was to provide a method for automation.  I had hoped that perhaps a project such as Per's MacAutoPkg could gain benefit from these additions.

I'm still willing to lend my abilities to this endeavor.

--Heig

On Jan 29, 2013, at 10:29 AM, Hannes Juutilainen <hjuuti...@mac.com> wrote:

Chiming in since I've been thinking about this a lot lately with MunkiAdmin. I call it "assimilating" a pkginfo with another. The current implementation looks like this when done manually:

<Screen Shot 2013-01-29 at 20.22.12.png>

--

Hannes Juutilainen

On 29.1.2013, at 20.11, Gregory Neagle <gregn...@mac.com> wrote:

So trying to fill in the blanks here.

--copypkginfo SOMENAME

Is SOMENAME a path to an existing pkginfo file, or is munkiimport expected to search catalogs for that item?

(My feeling is that if you already know you want to copy keys from a specific earlier pkginfo item, just open that in a editor and start copying!)

Which keys are implied to be copied when you specify --copypkginfo ? Is there more to --configure now, and you specify keys to be copied somewhere?

-Greg

On Jan 29, 2013, at 10:07 AM, EG <eriknico...@gmail.com> wrote:

/usr/local/munki/munkiimport --copypkginfo "Firefox-18.0.1" /path/to/installer_item

--
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.
 
 

--
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.
 
 

[Hannes Juutilainen]

On 29.1.2013, at 20.41, Gregory Neagle <gregn...@mac.com> wrote:

Wouldn't this be better/more useful if you could actually _see_ what you were copying?

Absolutely yes. Though I haven't found a good way to do this yet.

As an example: Munki can sometimes derive things like minimum_os_version and supported_architectures from the pkg itself.

In most cases, I'd think you'd want to keep what Munki found in the pkg itself, and _not_ copy the value from a prior pkginfo.

How is that info communicated to the admin? It probably should be.

True.

--

Hannes

[Gregory Neagle]

On Jan 29, 2013, at 10:22 AM, Jeremy Reichman <jah...@jaharmi.com> wrote:

I don't believe in forking Munki, no thanks, I've been through the everyone-has-their-own-Radmind-scripts days.

BTW, too late:

Sites using Simian or MunkiServer don't use munkiimport. They import things into their repo with other code, specific to Simian and MunkiServer.

munkiimport is not really a core Munki tool.

-Greg

[Nate]

How about having munkiimport not copy *any* keys by default and require the admin to specify an option to automatically pull in all keys from previous versions that don't exist in the vanilla pkginfo that is generated.  This way, we protect people from their own ignorance when importing stuff via munkiimport yet allow admins who know that keys must be copied to specify an argument to tell it to do so.

Nate

[Gregory Neagle]

On Jan 29, 2013, at 10:54 AM, Hannes Juutilainen <hjuuti...@mac.com> wrote:

On 29.1.2013, at 20.41, Gregory Neagle <gregn...@mac.com> wrote:

Wouldn't this be better/more useful if you could actually _see_ what you were copying?

Absolutely yes. Though I haven't found a good way to do this yet.

As an example: Munki can sometimes derive things like minimum_os_version and supported_architectures from the pkg itself.

In most cases, I'd think you'd want to keep what Munki found in the pkg itself, and _not_ copy the value from a prior pkginfo.

How is that info communicated to the admin? It probably should be.

True.

And you have a GUI to work with.

Now imagine addressing the same issues using only a command-line interface.

This is not trivial.

-Greg

[Nate]

Sorry, all keys from the most recent version that do not exist in the vanilla pkginfo that is generated for the new version.  I didn't mean to say pull them in from ALL previous versions.  Only the most recent.

Nate

[Gregory Neagle]

If we went this route, I'd still want a way to know what exactly got copied.

Maybe a new key inserted into the pkginfo:

<key>copied_keys</key>

<array>

<string>postinstall_script</string>

<string>unattended_install</string>

</array>

Of course, then you might also want to know from _where_ they were copied:

<key>copied_keys</key>

<dict>

<key>source</key>

<string>Firefox--17.0.1</string>

<key>keys</key>

        <array>

        <string>postinstall_script</string>

        <string>unattended_install</string>

        </array>

</dict>

This gets complicated quickly.

-Greg

[Gregory Neagle]

Actually, in my suggestion below, source may not uniquely/accurately identify the source -- there can be multiple items in a catalog with the same name and version!

-Greg

[Gregory Neagle]

New example today illustrating some of the issues.

Microsoft released Office 2011 14.3.0 update today.

I downloaded the dmg, then ran:

munkiimport ~/Downloads/Office2011-1430UpdateEN.dmg

First issue: munkiimport was unable to find a matching pkginfo to use as a template from which to copy keys. This is because the pkg receipts are all new. So I had to pull up the 14.2.5 update and manually copy stuff.

But let's say a --copypkginfo key existed and I could say:

munkiimport --copypkginfo Office2011_update ~/Downloads/Office2011-1430UpdateEN.dmg

The things I wanted to copy were these:

name
I want to keep the name consistent on all Office 2011 updates, so copying this as-is is the right thing to do.

location (not really a key)
I want this update to be uploaded to the same subdirectory on the server as previous updates. munkiimport's current behavior would handle that.

blocking_applications
This assumes the list of blocking applications is actually the same as the previous update. It may not be. One possible change that occurs to me is that the blocking_applications I have for the 14.2.5 update do not list Microsoft Lync. We are now deploying that for some users. I bet it should be included in the list of blocking_applications.

installs
Now I don't really mean I want to copy the installs as-is -- the CFBundleShortVersion numbers would be all wrong. But they are nice as a template; I was pretty sure I could just update the CFBundleShortVersion numbers to 14.3.0. No way munkimport could know that/be expected to do that for me, though.

update_for
This package is still an update for Office2011, so that key can be copied unchanged and with high confidence.

requires
As it turns out, Office2011_update--14.3.0 requires Office2011_Update--14.2.3, just like the 14.2.5 did. So copying this over unchanged was OK. But again. munkiimport could not possibly know that was the case. What if the 14.3.0 update had required the 14.2.5 update to be installed first? This is another key the admin must have special knowledge to use correctly.

So out of those keys, only three (name, {location} and update_for) could be copied unchanged with a high degree of confidence.

munkiimport currently also copies blocking_applications and requires. In this case, copying these unchanged would result in a mostly-accurate pkginfo file, though this is mostly by chance.

In order to get a truly functional pkginfo file, Office updates really require installs items. munkiimport completely fails to help with this part of the task.

And Office updates are a frequent source of confusion and support requests on munki-dev and in the osx-server IRC channel. This is why I'm looking toward recipes -- recipes could address most or all of the above points.

-Greg

[EG]

I completely agree that the recipe idea is a great idea and once implemented will help with the confusion and lead to an all-around better environment for people who are learning how to use munki or need guidance.

All of your issues with the above keys are valid, but by making it a non-default value (requiring --copypkginfo), the admin is already assuming that they need to manually edit the pkginfo file itself. All this does is preload values that don't have to be copy/pasted or merged into the new pkginfo file.

Your premise is just slightly invalid. I know I absolutely need to do manual editing, which is why I'm calling the switch. If the admin(s) make an assumption and don't validate what munkiimport --copypkginfo brings in, it is just as much of an issue as not creating manual entries into the pkginfo to begin with.

[Gregory Neagle]

On Jan 29, 2013, at 12:28 PM, EG <eriknico...@gmail.com> wrote:

I completely agree that the recipe idea is a great idea and once implemented will help with the confusion and lead to an all-around better environment for people who are learning how to use munki or need guidance.

All of your issues with the above keys are valid, but by making it a non-default value (requiring --copypkginfo), the admin is already assuming that they need to manually edit the pkginfo file itself. All this does is preload values that don't have to be copy/pasted or merged into the new pkginfo file.

If they know they need to edit the pkginfo file anyway, there is _more_ info available to them if munkiimport does NOT copy pkginfo keys. There are the values from the prior pkginfo and there are the new values makepkginfo discovered for the new pkginfo.

Copying them destroys info.

Your premise is just slightly invalid. I know I absolutely need to do manual editing, which is why I'm calling the switch. If the admin(s) make an assumption and don't validate what munkiimport --copypkginfo brings in, it is just as much of an issue as not creating manual entries into the pkginfo to begin with.

So we agree there is a need for admin editing.

munkiimport's behavior now does not destroy information the admin can use when editing the pkginfo.

-Greg

On Tuesday, January 29, 2013 2:14:56 PM UTC-6, gregn...@mac.com wrote:

In order to get a truly functional pkginfo file, Office updates really require installs items. munkiimport completely fails to help with this part of the task.

And Office updates are a frequent source of confusion and support requests on munki-dev and in the osx-server IRC channel. This is why I'm looking toward recipes -- recipes could address most or all of the above points.

-Greg

[EG]

I absolutely see what you are talking about. I think there is a bit of miscommunication between myself and a few others with respect to this request. What I (and hopefully the others) want is the ability to copy the values that we are already creating manually. Hash checks, <installs> and most of the other items that munkiimport creates with every pkg/dmg/etc should absolutely never be overwritten from a previous pkginfo file. What should happen is the ability to append previous data. We are talking about adding data, not overwriting.

I've actually been thinking about a repository/wiki type website that is somewhat similar to your idea of "metamunki". I believe that pkginfo files should be uniform and all conform to the same layout. It's great that we can just place any value anywhere and Munki will know what to do with it but at the same time I want every pkginfo to be "clean". Implementing this idea could actually have the benefit of uniformity by having munki place these values in a specific order. I see too many pkginfos posted here that do not conform to my own layout.

What should munki should do with this command is look for the values that we most commonly do manually and ask the admin if it should be imported.

To answer your question from earlier:

     --copypkginfo SOMENAME

     Is SOMENAME a path to an existing pkginfo file, or is munkiimport expected to search catalogs for that item?

     Which keys are implied to be copied when you specify --copypkginfo ? Is there more to --configure now, and you specify keys to be copied somewhere?

In my mind, SOMENAME would be the equivalent of when we specify an item via manifestutil -> add-pkg "SOMENAME". Munki would have to search the catalogs to ensure that it gets the latest pkginfo file. Optionally, an admin could direct munki to the exact path of the particular pkginfo file if desired. I don't necessary think the latter would help with time but it would allow importing in the odd event that information needed to come from an earlier pkg.

--configure could definitely be an option for the admin to specify what values he/she would like upon importing via --copypkginfo, but I think if we all came together and discussed this further, we could figure out the values we all use on a daily basis.

On Tuesday, January 29, 2013 4:25:58 PM UTC-6, gregn...@mac.com wrote:

If they know they need to edit the pkginfo file anyway, there is _more_ info available to them if munkiimport does NOT copy pkginfo keys. There are the values from the prior pkginfo and there are the new values makepkginfo discovered for the new pkginfo.

Copying them destroys info.

So we agree there is a need for admin editing.

[Samuel Keeley]

This is XML plist, layout really does not matter.  Many of us who use tools like MunkiAdmin rarely even look at the XML.

Making munki move items around within the XML would introduce many more problems, and my preferred way to manually edit the XML is likely very different from yours and others.

A preferred formatting is fine, but not something that is worth coding, nor building into munkitools.

-sam

--
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.
 
 

--
Samuel Keeley

[Nate]

Ah yes, we do not want to copy ALL keys...just all optional keys.  Any keys that are generated by makepkginfo when pointed at the item should be ignored and only the option keys should be copied when --copykeys is called.  In most cases, these are keys such as unattended_install/uninstall, update_for, requires, installs, etc.  By diffing the pkginfo that makepkginfo generates and the most recent version from the repo, you can deduce which keys to copy.  Perhaps this is an over simplification?   

Nate

[Gregory Neagle]

On Jan 29, 2013, at 5:52 PM, EG <eriknico...@gmail.com> wrote:

I absolutely see what you are talking about. I think there is a bit of miscommunication between myself and a few others with respect to this request. What I (and hopefully the others) want is the ability to copy the values that we are already creating manually.

So we'd limit this only to keys Munki never generates on its own?

Hash checks, <installs> and most of the other items that munkiimport creates with every pkg/dmg/etc should absolutely never be overwritten from a previous pkginfo file. What should happen is the ability to append previous data. We are talking about adding data, not overwriting.

I've actually been thinking about a repository/wiki type website that is somewhat similar to your idea of "metamunki". I believe that pkginfo files should be uniform and all conform to the same layout. It's great that we can just place any value anywhere and Munki will know what to do with it but at the same time I want every pkginfo to be "clean". Implementing this idea could actually have the benefit of uniformity by having munki place these values in a specific order. I see too many pkginfos posted here that do not conform to my own layout.

Munki uses Foundation's methods for reading and writing plists; I have no control over the ordering of keys. If you want a "canonical" ordering for the keys, it would have to be the way Apple's tools do it. Right now, that appears to be in alphabetical order.

What should munki should do with this command is look for the values that we most commonly do manually and ask the admin if it should be imported.

To answer your question from earlier:

     --copypkginfo SOMENAME

     Is SOMENAME a path to an existing pkginfo file, or is munkiimport expected to search catalogs for that item?

     Which keys are implied to be copied when you specify --copypkginfo ? Is there more to --configure now, and you specify keys to be copied somewhere?

In my mind, SOMENAME would be the equivalent of when we specify an item via manifestutil -> add-pkg "SOMENAME".

That's completely different. manifestutil is simply adding a string to a manifest file. What that string ends up resolving to is handled by client logic and can and will change over time,

Munki would have to search the catalogs to ensure that it gets the latest pkginfo file. Optionally, an admin could direct munki to the exact path of the particular pkginfo file if desired.

That would probably require a different option flag.

I don't necessary think the latter would help with time but it would allow importing in the odd event that information needed to come from an earlier pkg.

--configure could definitely be an option for the admin to specify what values he/she would like upon importing via --copypkginfo, but I think if we all came together and discussed this further, we could figure out the values we all use on a daily basis.

On Tuesday, January 29, 2013 4:25:58 PM UTC-6, gregn...@mac.com wrote:

If they know they need to edit the pkginfo file anyway, there is _more_ info available to them if munkiimport does NOT copy pkginfo keys. There are the values from the prior pkginfo and there are the new values makepkginfo discovered for the new pkginfo.

Copying them destroys info.

So we agree there is a need for admin editing.

munkiimport's behavior now does not destroy information the admin can use when editing the pkginfo.

-Greg

[Gregory Neagle]

On Jan 29, 2013, at 6:56 PM, Samuel Keeley <sam.k...@gmail.com> wrote:

This is XML plist, layout really does not matter.  Many of us who use tools like MunkiAdmin rarely even look at the XML.

Making munki move items around within the XML would introduce many more problems,

And isn't going to happen. FoundationPlist writes out plists using Apple's methods. We're not going to reimplement that just to get some other arbitrary order of keys.

and my preferred way to manually edit the XML is likely very different from yours and others.

I stick with putting the keys in alphabetical order since that's how Apple's tools do it.

A preferred formatting is fine, but not something that is worth coding, nor building into munkitools.

I'll just say it will not happen.

No key order is guaranteed. Observed order currently appears to be alphabetical; Apple could change that behavior at any time.

-Greg

[Gregory Neagle]

On Jan 29, 2013, at 7:06 PM, Nate <nate....@gmail.com> wrote:

Ah yes, we do not want to copy ALL keys...just all optional keys.  Any keys that are generated by makepkginfo when pointed at the item should be ignored and only the option keys should be copied when --copykeys is called.  In most cases, these are keys such as unattended_install/uninstall, update_for, requires, installs

Copying installs keys is almost never wanted.

, etc.  By diffing the pkginfo that makepkginfo generates and the most recent version from the repo, you can deduce which keys to copy.  Perhaps this is an over simplification? 

Perhaps.