Storing admin notes

[Greg Neagle]

I was discussing this topic with Joe Wollard, and thought it might be nice to get a wider opinion base.

Joe wants to be able to store admin notes in pkgsinfo files and manifests. I've done this sort of this occasionally as well; all you need to do is pick a dictionary key that isn't being used by munki and use that.

The only issues are: problems may happen in the future if the munki development team decides to use a key you are using, and if you switch admin tools (munkiserver, Simian, MunkiAdmin, MunkiFace, etc) it would be nice if they were using the same keys to store notes.

So I'd like to propose officially reserving the key "notes" in both pkgsinfo files and manifests for use for admin notes. Munki itself won't use this field for anything, but administrators (and makers of Munki administration tools) are encouraged to use this key to store notes.

Any objections, comments, or better ideas?

Any other keys/fields we should reserve? I sometimes store the name of the primary user of a manifest in a field in the manifest -- do others?

-Greg

[Anurag Mohanty]

I like the idea of a having a notes field in pkginfos, it would be great if manifests had something similar as well.
Cheers,
-- Anurag

[Greg Neagle]

In case it's not clear -- there's really nothing stopping you from adding and using a notes field to pkginfo files and manifests right now. My email was more of an attempt to get the munki community to agree on a standard.

-Greg

[A.E. van Bochoven]

I like the idea of reserving a key for custom additions, but I would propose to reserve an 'admin' key containing a dict in pkginfo and manifests. 'notes' could be a dictionary item, and 'primary user' another. Although this makes it a little bit more difficult to get at the desired information, it prevents clutter in the the top level namespace.

Arjen

[Greg Neagle]

While a nice idea, I think that's too complex to get traction, especially since Munki itself will never use it.

<key>notes</key>
<string>Some random string</string>

Is easy for both hand-editing and for admin tools to support.

-Greg

[Bernstein, Gary]

I like these ideas. Currently I create a KCPA Notes key and put a primary key in there, but having that be its own thing would be better.

-Gary

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
-- "The reward for work well done is the opportunity to do more."

-- "I tried, but it didn't work" is a lot better than "I wish I'd tried."

Gary R. Bernstein
Interim Assistant Director of FAA IT Services
College of Fine and Applied Arts
University of Illinois - Urbana-Champaign
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

[Hannes Juutilainen]

I like this too. And +1 for reserving 'notes' key in both pkginfo and manifest files.

I would also suggest a following best practice: If admin tools need to store something in pkginfo files, use reverse dns naming scheme and take one top level item and do what you like with it.

So if MunkiAdmin needed to store some custom information in pkginfo files, It should create com.github.hjuutilainen.munkiadmin key and store everything under it.

--
Hannes Juutilainen

[Joe Wollard]

That was more along the lines of what I proposed in the discussion Greg and I had, but that was to avoid future conflicts if munki ever decided to use a "notes" key in the future. If munki reserved this key right now, then all of the admin tools could safely use it. If they can all use it, there's no penalty or work involved with migrating to a different admin tool.

---
Joe Wollard

[Greg Neagle]

On Feb 28, 2012, at 10:22 AM, Joe Wollard wrote:

> That was more along the lines of what I proposed in the discussion Greg and I had, but that was to avoid future conflicts if munki ever decided to use a "notes" key in the future. If munki reserved this key right now, then all of the admin tools could safely use it. If they can all use it, there's no penalty or work involved with migrating to a different admin tool.
>

Exactly. (or migrating from _no_ admin tool other than a text editor!)

[Aaron Hall]

On Tue, 28 Feb 2012, Hannes Juutilainen wrote:

> I would also suggest a following best practice: If admin tools need to
> store something in pkginfo files, use reverse dns naming scheme and
> take one top level item and do what you like with it.
>
> So if MunkiAdmin needed to store some custom information in pkginfo
> files, It should create com.github.hjuutilainen.munkiadmin key and
> store everything under it.

We might take a page from the e-mail RFCs and reserve any key starting
with "X-" for local admin use, and just say that Munki itself will never
look at any such key.

This is somewhat the same proposal as yours, I grant, and I grant the
reserve-dns scheme is so common as to almost be native in the Mac admin
world. OTOH, "X-MunkiAdmin-Foo" is less to type, and might (like in
e-mail) be a fruitful proving ground for ideas.

- Aaron

--
Aaron Hall <aaron...@washburn.edu>
Asst. Systems & Network Administrator
Washburn University
785-670-2305

[Rob Middleton]

<key>notes</key>
<dict>whatever structure you want, or just a string
</dict>

With makecatalogs to strip out this key entirely (?). Then you can choose not to expose such information on every client (the pkgsinfo directory does not need to be on your web server, or can be there but with no access).

Rob.

[Greg Neagle]

Hmm. I originally thought the munki tools could just ignore these notes keys, but there's something to the idea of having makecatalogs strip them out. This, then moves it from a convention to official support, though.

-Greg

[Heig Gregorian]

Thought I'd take a stab at this...

http://code.google.com/r/theheig-conditionals/source/detail?r=dcf0f91fe86b7f2c18c38704e76eba01a6053e4d&name=makecatalogs

--Heig

[Joe Wollard]

Nice! Thanks, Heig

--

Joe Wollard

[Heig Gregorian]

Of course this couples nicely (I think) with another addition to 'makepkginfo':

http://code.google.com/r/theheig-conditionals/source/detail?r=6d45a7108bfb0eb9d796406fbfde03d7e4600f00&name=makepkginfo

Sent from my iPhone

[Joe Wollard]

I assume Python takes care of encoding any xml characters before writing the plist. If not, there's a bug, but if so, this looks good!

--

Joe Wollard

[Heig Gregorian]

Yes it does...the same way that pre/postinstall_script and pre/postuninstall_scripts are handled.

--Heig

[Greg Neagle]

To be pedantic about it: the library that writes the plist takes care of the encoding. In this case it's FoundationPlist, which calls Apple's NSPropertyListSerialization methods; but it could be the Python plistlib in its place.

-Greg