Customizing Managed Software Center

[Gregory Neagle]

NOTE: this post is about Munki 2, which is in-development code for the next major release of Munki. It is not production ready. Do not deploy on your fleet unless you like pain and suffering.

The new Managed Software Center application for Munki 2 will support some customization. Specifically, you will be able to specify custom banner images, custom sidebar content, and a custom footer.

I think these should be downloaded from the Munki repo, so that admins can easily highlight new things without having to install anything on local machines.

My current thought is that the admin will create a set of html (or html-like) files in a directory, then zip this directory and upload it to the repo with a specific name.

The Munki client will check a predefined URL to download this file and expand the contents into a directory that MSC.app will use for the custom contents.

Does anyone see an issue with this approach?

-Greg

[tackyy]

Why serve it up as a zip? If munki gets served up via http why not just serve up the html and images that way? If compression is a factor then we can use http 1.1 gzip. Then would be we could use the devtools in the browsers to work with this content. If clients are having problems with a specific asset we can inspect it as it exists on the server.

-tack

> --
> 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/d/optout.

[Gregory Neagle]

On Mar 27, 2014, at 9:02 AM, tackyy <tac...@gmail.com> wrote:

> Why serve it up as a zip? If munki gets served up via http why not just serve up the html and images that way?

How will the client (managedsoftwareupdate) know what files to request? You could have one banner image or 100 (or zero!)...

Certainly the footer and sidebar could be just files, but since the banners could be an arbitrary number of files, it just seems simpler overall to zip it all up.

-Greg

[Nate]

I like this approach. I assume munki will hash the zip to check for changes much like it does with dmgs.

Works for me.

Nate

[Gregory Neagle]

It would use the same methods it currently uses to download content, and does not rely on hashes.

https://code.google.com/p/munki/source/browse/code/client/munkilib/fetch.py#556

-Greg

[Josh Malone]

+1

Like!

thumb->up();

Sounds like this will be much easier to brand than the current MSU
app. Much appreciated.

-Josh

[tackyy]

"What file to request" is really "what file goes with what". Somewhere there has to be a file or config that tells the client that. It may as well be the specially named thing MSC looks for instead of a zip.

As far as that's concerned, there could be a special tag in the html files that works kinda like update_for so munkitools could build that file/config. The html files themselves would have the links to the relevant assets (relative paths) so munkitools would only have to care about the html.

tack

[Gregory Neagle]

Sounds like you are proposing a lot of complexity. 

Sent from my iPhone

[Greg Coan]

I like this approach.

[Erik]

I don't think anyone would agree with me, but it would be somewhat nice to be able to point the client (maybe via preferences) to point to specific banners.

This would allow an admin to customize munki on a per-site basis.

[Greg Coan]

I believe this would work fine via manifests using Greg's .zip method.  Different files in .zips for different sites.

[tackyy]

Well, maybe I’m getting bogged down with specifics. It seems to me that MSC and munki will have to keep track of what content goes to what piece of software, banner, campaign etc anyway. That part of it is inescapable. Zip or no zip it’s going to be there.

So thinking of it that way, zip adds a layer of complexity. It’s another step and piece of software that can break and if MSC is going to have to load an asset from a local path anyway, it might as well be a URI over http.

tack

[Bart Reardon]

If you want to avoid a zip then the only way I can see is with a manifest of some sort.

Currently there are three things I would want to modify:

  the banner and what they link to

  the sidebar links and what they link to

  the footer links and what they link to

you could have all these in a single xml or plist in sections. MSC would then know how manny banners there are, how many links etc avoiding a zip and avoiding the potential for an admin to mess up the current templates (if that was the thinking). Also makes testing/changing things a whole lot easier.

So, my thought would be to have another subfolder in the munki repo for holding the assets and a single manifest plist for telling MSC how many assets and where they are. It can then populate as necessary and any missing details stay as the current defaults.

[A.E. van Bochoven]

Just one manifest (plist) in a fixed location that describes where the assets can be found. Assets could be pulled from another server (maybe its easier for some folks to point the banners to some CMS site where they can change the banner)

-Arjen

[tackyy]

Oh, good point. If you have non-technical managers tweaking manifests in MWA, they may want to tweak the banners as well. And I don’t want to BECOME the CMS.

What if such a plist could point to a zip if that’s how you want to roll, or URI’s if you want something beefier but don’t want to add all that functionality into munki/msc?

tack

[David Iwanicki]

put the banners in a sub-folder and have MSC iterate thru the contents... I wrote a Quartz Composer project which did this, and had the marketing people just upload new content to that folder to change out elements on the "billboard"

[Bart Reardon]

how?

depending on the web server the client won't have access to a list of contents so how do you know when to stop iterating? for i=1 until 404 i++; http get banner(i).png? also how do you notify MSC what URL a banner should link to, if any?

for a single plist you just have the banners called whatever you want in a dictionary of items plus any associated links and under that you have another dict for the sidebar and another for the footer. All that will be needed on the server then is a known plist and the banner png assets. no zip files and no potential for pain with mucking about with html templates.

[Ken Elliott]

Perhaps even part of the client manifest.

[Gregory Neagle]

On Mar 27, 2014, at 1:04 PM, David Iwanicki <david.i...@gmail.com> wrote:

put the banners in a sub-folder and have MSC iterate thru the contents...

We can't assume a web server that allows directory listings; in fact my recommendation is to _not_ allow directory listings via HTTP/S on your production Munki repo.

So we can't iterate through a directory's contents; we must know (or be able to discover) all the needed URLs.

-Greg

[Gregory Neagle]

So it sounds like people want something I had not considered: a way to customize MSC.app per client: one client might see one set of banners, have one sidebar, and one footer; another client would have a different set of banner images (and URLs), a different sidebar, and a different footer.

The obvious way to handle this is a new key and value set in the client manifest.

We could avoid the need to use a zip file (though I don't really see the big deal), but it increases the complexity of the values in the client manifest.

IE:

<key>client_web_assets</key>

<string>myorg_assets.zip</string>

vs:

<key>client_web_assets</key>

<dict>

<key>banners</key>

<array>

<dict>

<key>image</key>

<string>banner1.png</string>

<key>target_url</key>

<string>detail-Firefox.html</string>

</dict>

<dict>

<key>image</key>

<string>banner2.png</string>

<key>target_url</key>

<string>category-Productivity.html</string>

</dict>

<dict>

<key>image</key>

<string>banner3.png</string>

<key>target_url</key>

<string>developer-MyOrg.html</string>

</dict>

</array>

<key>sidebar</key>

<string>myorg_sidebar.html</string>

<key>footer</key>

<string>myorg_footer.html</string>

</dict>

or similar. Certainly the latter is far more flexible, but at a cost of fairly high complexity.

-Greg

On Mar 27, 2014, at 11:56 AM, A.E. van Bochoven <ne...@mac.com> wrote:

Just one manifest (plist) in a fixed location that describes where the assets can be found. Assets could be pulled from another server (maybe its easier for some folks to point the banners to some CMS site where they can change the banner)

-Arjen

On 27 Mar 2014, at 19:51, Bart Reardon <bart.r...@gmail.com> wrote:

If you want to avoid a zip then the only way I can see is with a manifest of some sort.

Currently there are three things I would want to modify:

  the banner and what they link to

  the sidebar links and what they link to

  the footer links and what they link to

you could have all these in a single xml or plist in sections. MSC would then know how manny banners there are, how many links etc avoiding a zip and avoiding the potential for an admin to mess up the current templates (if that was the thinking). Also makes testing/changing things a whole lot easier.

If changing some files, then editing a complex manifest without error is "a whole lot easier" than changing some files in a (possibly version controlled) directory and zipping it up.

So, my thought would be to have another subfolder in the munki repo for holding the assets

That's the plan.

[Joe Wollard]

So we can't iterate through a directory's contents; we must know (or be able to discover) all the needed URLs.

But something server-side could. Something like makecatalogs, for example. It could iterate over a directory (I kind of like the idea of having another top-level directory such as mscinfo/) and spit out a plist containing an array of files and their paths relative to that mscinfo directory. That would take care of telling MSC which assets to download, and it could even periodically check the etag of each asset to see if anything has changed. The challenge would then become knowing where to put which assets. There are three places that can currently be customized; banner, sidebar, and footer. It seems reasonable to me to expect MSC to iterate over files that are prefixed with one of those key words and display them in a web view/image view in the appropriate location in the GUI, and assume that everything else will be referenced by one of the prefixed ones.

An example footer:

footer.html

some_footer_image.png (<-- used by footer.html, but downloaded and otherwise ignored by MSC)

Example banners:

banner_clickableKittens.html <-- 1st banner

banner_companyLogo.png <-- 2nd banner

kittens.png <-- image displayed in the 1st banner via plain ol' html

Example sidebar...I think you get it by now so I'm not going to drill it in any more.

I'm not interested in fighting for this idea a great deal, but I'd be happy to expand on it if I'm not being clear about something.

 

-Greg

[Joe Wollard]

Or this. This is good.

Joe Wollard

[Bart Reardon]

> If changing some files, then editing a complex manifest without error is "a whole lot easier" than changing some files in a (possibly version controlled) directory and zipping it up.

Depends on what the contents of the html files will be but I find having defined key value pairs much easier to deal with than an unstructured html. With key value pairs your data is there and its format is strict and you let MSC deal with the formatting, plus you don't have to parse the html first and remove unwanted tags etc. That's the messy bit I was referring to.

I'm not aware of your intentions with how the sidebar and footer html is going to be though so it's hard to comment. I feel though that munki is already complex plists that we're all used to dealing with so why not continue with that.

[Gregory Neagle]

On Mar 27, 2014, at 3:52 PM, Joe Wollard <joe.w...@gmail.com> wrote:

Or this. This is good.

Which is good? First option? Second option? Both? Hybrid alien love child?

[Joe Wollard]

Or this. This is good.

Which is good? First option? Second option? Both?

The 2nd.

 

Hybrid alien love child?

Um, very yes. What other nature-defying Python tricks can you do?!

--

Joe Wollard

[Gregory Neagle]

On Mar 27, 2014, at 3:53 PM, Bart Reardon <bart.r...@gmail.com> wrote:

> If changing some files, then editing a complex manifest without error is "a whole lot easier" than changing some files in a (possibly version controlled) directory and zipping it up.

Depends on what the contents of the html files will be but I find having defined key value pairs much easier to deal with than an unstructured html.

??? You are going to have to author the html anyway. The banner stuff, the sidebar, the footer will all be html.

With key value pairs your data is there and its format is strict and you let MSC deal with the formatting, plus you don't have to parse the html first and remove unwanted tags etc.

No HTML parsing. That's the WebView's job.

That's the messy bit I was referring to.

I'm not aware of your intentions with how the sidebar and footer html is going to be though so it's hard to comment.

Same as all the other html currently displayed in the MSC.app web view.

I feel though that munki is already complex plists that we're all used to dealing with so why not continue with that.

Adding complexity unnecessarily is rarely a good thing.

[Gregory Neagle]

On Mar 27, 2014, at 3:57 PM, Joe Wollard <joe.w...@gmail.com> wrote:

Or this. This is good.

Which is good? First option? Second option? Both?

The 2nd.

At least your vote is clearer. For the record, I dislike #2. Too complex.

-Greg

[Bart Reardon]

> ??? You are going to have to author the html anyway. The banner stuff, the sidebar, the footer will all be html.

exactly. It's going to be up to the admins to write the html.

I can write html and follow rules though based on what's expected but I know people that can't (no-one on this list I'm sure). I just see it as removing potential future pain when someone copies and pastes something they exported to html from Word and wonders why it look odd in MSC.

Maybe that's and edge case though and all munki admins are good admins.

From what I see the design of MSC needs to be strict. You know what links on the side and in the footer need to look like. What you don't know is what they say or link to, so only give people access to change what they say and link to....i.e. key value pairs.

[Gregory Neagle]

Perhaps some more concrete examples are needed. Here's the current footer html inside MSC.app:

<div class="bottom-links">

    <ul class="list" role="presentation">

        <li><a target="_blank" href="http://www.apple.com">Apple</a></li>

        <li><a target="_blank" href="http://www.google.com">Google</a></li>

        <li><a href="updates.html">Updates</a></li>

    </ul>

</div>

You'd author a replacement. It's up to you what you put in it; I don't care. If you make something ugly and non-functional, that's on you.

Here's the current sidebar:

                    <div class="sidebar">

                        <div class="chart titled-box quick-links">

                            <h2>Quick Links</h2>

                            <div class="content">

                                <ol class="list">

                                    <li class="link user-link"><a href="#">Welcome</a></li>

                                    <li class="link user-link"><a href="#">Support</a></li>

                                    <li class="separator"><hr/></li>

                                    <li class="popup">

                                        <div class="select links">

                                            <label>

                                                <span></span>

                                                <select id="category-selector" onchange="category_select()">

                                                    ${category_items}

                                                </select>

                                            </label>

                                        </div>

                                    </li>

                                    <li class="link"><a href="http://www.apple.com/osx/whats-new/">What's new in Mavericks</a></li>

                                    <li class="link"><a target="_blank" href="http://www.apple.com">Apple</a></li>

                                    <li class="link"><a target="_blank" href="http://google.com">Search Google</a></li>

                                    <li class="link"><a target="_blank" href="http://bing.com">Search Bing</a></li>

                                    <li class="separator"><hr/></li>

                                    <li class="link"><a target="_blank" href="http://www.apple.com/support/">Apple support</a></li>

                                    <li class="link"><a target="_blank" href="http://www.apple.com/support/mac/">Mac</a></li>

                                    <li class="link"><a target="_blank" href="http://www.apple.com/support/osx/">OS X</a></li>

                                    <li class="link"><a target="_blank" href="http://www.apple.com/support/mac-apps/">Mac Apps</a></li>

                                </ol>

                            </div>

                        </div>

                    </div>

Here's the current banner section:

                <div class="showcase ${hide_showcase}">

                    <div class="stage" onClick='stageClicked();'>

                        <img href="http://www.apple.com" alt="Branding" src="static/branding.png" />

                        <img href="detail-GoogleChrome.html"  alt="Branding" src="static/branding1.png" />

                        <img href="developer-Google.html" alt="Branding" src="static/branding2.png" />

                    </div>

                </div>

So you'd need three html files and some number of images; of course if you do something really strange you might need other things as well.

I don't think I'm going to worry about corner protectors, railings and outlet guards -- it's the admin's responsibility to create something that works.

-Greg

[Gregory Neagle]

On Mar 27, 2014, at 4:08 PM, Bart Reardon <bart.r...@gmail.com> wrote:

> ??? You are going to have to author the html anyway. The banner stuff, the sidebar, the footer will all be html.

exactly. It's going to be up to the admins to write the html.

I can write html and follow rules though based on what's expected but I know people that can't (no-one on this list I'm sure).

Then they shouldn't try to customize MSC.app. (And therefore it's important that the defaults be serviceable out-of-the-box.)

I just see it as removing potential future pain when someone copies and pastes something they exported to html from Word and wonders why it look odd in MSC.

They should spend some more learning time and try again.

Maybe that's and edge case though and all munki admins are good admins.

I'm not interested in making it foolproof. If someone else wants to take the time to write a "Managed Software Center Customizer" application that makes it foolproof, great.

From what I see the design of MSC needs to be strict. You know what links on the side and in the footer need to look like.

Who am I to dictate it? I'll make some examples, but if people want to try to embed an HTML5 movie or add flashing text, what do I care? Why should I stop them? Maybe it will be great and useful for their environment.

What you don't know is what they say or link to, so only give people access to change what they say and link to....i.e. key value pairs.

Too limiting, and more work for me.

[tackyy]

Along those lines, but fewer keys to support in client manifest:

<key>client_web_assets</key>

<dict>

<key>base_href</key>

<string>http://munki.example.com/web_assets/</string>

<key>web_asset_manifest</key>

<string>assets.plist</string>

</dict>

Editing client manifest every time we want to swap out an image WOULD be suboptimal and needlessly complex. But we could point to a file we can edit in a central location and have in our repo’s SCM. And this allows people to manage the banner/web bits outside of munki if they want something more powerful but without having to add that support inside munki itself.

FWIW I don’t see the plist file itself as very complex. It’s just another page. And you can validate it with plutil.

tack

[Gregory Neagle]

On Mar 27, 2014, at 4:20 PM, tackyy <tac...@gmail.com> wrote:

Along those lines, but fewer keys to support in client manifest:

<key>client_web_assets</key>

<dict>

<key>base_href</key>

<string>http://munki.example.com/web_assets/</string>

<key>web_asset_manifest</key>

<string>assets.plist</string>

</dict>

Editing client manifest every time we want to swap out an image WOULD be suboptimal and needlessly complex.

included_manifests is your friend there. No need to invent yet another inclusion mechanism.

But we could point to a file we can edit in a central location and have in our repo’s SCM. And this allows people to manage the banner/web bits outside of munki if they want something more powerful but without having to add that support inside munki itself.

FWIW I don’t see the plist file itself as very complex. It’s just another page. And you can validate it with plutil.

plutil tells you if it's a valid plist (or not). It doesn't tell you if it's valid to _Munki_.

[Bart Reardon]

<blink>give people enough rope and they will hang themselves with it</blink>

I see your points and position. I must admit that when I first saw MSC I wondered if customisation would consist of hosing modified templates in the munki repo so if this is the direction then it's no surprise or bother to me.

So..if that's the way it will be customised then that's fine. I do like the idea of hosting different content depending on client manifest though.

[Joe Wollard]

I'm assuming these are all being displayed in a NSWebViews, (not sure what else it would be if you're rendering html in them), so are there any tricks that anyone knows of to grab an offline cache of the contents of an NSWebView so it can be rendered when the server isn't available? If so, this seems like the simplest and most flexible option to me; no manifests, no zip archives to create, just client-side cache management. Just three files to initially request by MSC; banner.html, sidebar.html, and footer.html

To address the request for different content for different manifests/manifest groups, that could still be done with subfolders where the subfolder name would map to the value specified in the <theoretical-key-here> within the manifest.

Deceptively simple? This project looks *close* to being helpful: http://nshipster.com/nsurlcache/

Joe Wollard

[Gregory Neagle]

On Mar 27, 2014, at 4:25 PM, Joe Wollard <joe.w...@gmail.com> wrote:

I'm assuming these are all being displayed in a NSWebViews, (not sure what else it would be if you're rendering html in them), so are there any tricks that anyone knows of to grab an offline cache of the contents of an NSWebView so it can be rendered when the server isn't available?

That's precisely what is and will be happening. The resources are all local. All the HTML is local _now_. Look in ~/Library/Caches/com.googlecode.munki.ManagedSoftwareCenter/html

If so, this seems like the simplest and most flexible option to me; no manifests,

How, then, do we serve different content to different clients?

no zip archives to create, just client-side cache management. Just three files to initially request by MSC; banner.html, sidebar.html, and footer.html

What about the (variable number of) banner images? They must also be downloaded and cached. And no, I don't want to parse the html in  banner.html, sidebar.html, and footer.html to see what other resources I might need to cache.

[Bart Reardon]

> are there any tricks that anyone knows of to grab an offline cache of the contents of an NSWebView so it can be rendered when the server isn't available?

I'd presume it would be done the way it currently is where HTML content would sit in ~/Library/Caches/com.googlecode.munki.ManagedSoftwareCenter/html/ and MSC renders it from there.

[Gregory Neagle]

On Mar 27, 2014, at 4:31 PM, Bart Reardon <bart.r...@gmail.com> wrote:

> are there any tricks that anyone knows of to grab an offline cache of the contents of an NSWebView so it can be rendered when the server isn't available?

I'd presume it would be done the way it currently is where HTML content would sit in ~/Library/Caches/com.googlecode.munki.ManagedSoftwareCenter/html/ and MSC renders it from there.

Or symlinked there like the static content and the icons.

[Joe Wollard]

I wasn't clear - I realize it's all stored client-side now, but the problem we're trying to figure out is _what_ should be gathered and cached by MSC on the client. My thought with this was to leave this to the WebView. It already knows how to do caching of the page and its associated assets, but how much control does the 'not-employed-by-apple' programmer have over that? The only additional requirement this would impose on admins is the need to specify a full url to images/scripts/css instead of relative paths.

[Gregory Neagle]

On Mar 27, 2014, at 4:35 PM, Joe Wollard <joe.w...@gmail.com> wrote:

I wasn't clear - I realize it's all stored client-side now, but the problem we're trying to figure out is _what_ should be gathered and cached by MSC on the client. My thought with this was to leave this to the WebView.

Too late.

mangedsoftwareupdate needs to download all the content _before_ MSC.app runs. MSC.app downloads nothing. Ever. 

It already knows how to do caching of the page and its associated assets, but how much control does the 'not-employed-by-apple' programmer have over that? The only additional requirement this would impose on admins is the need to specify a full url to images/scripts/css instead of relative paths.

That's precisely what is and will be happening. The resources are all local. All the HTML is local _now_. Look in ~/Library/Caches/com.googlecode.munki.ManagedSoftwareCenter/html

If so, this seems like the simplest and most flexible option to me; no manifests,

How, then, do we serve different content to different clients?

no zip archives to create, just client-side cache management. Just three files to initially request by MSC; banner.html, sidebar.html, and footer.html

What about the (variable number of) banner images? They must also be downloaded and cached. And no, I don't want to parse the html in  banner.html, sidebar.html, and footer.html to see what other resources I might need to cache.

[Joe Wollard]

Well then...never mind :)

Too bad OS X doesn't come with wget or you could obtain the same behavior in managedsoftwareupdate, and curl is of no help with crawling and archiving without being wrapped in additional scripts. :-/

--

Joe Wollard

[Gregory Neagle]

Still not getting the extreme aversion to simply zipping up a directory. Presto: a web archive.

What am I missing?

-Greg

[Joe Wollard]

On Thu, Mar 27, 2014 at 7:41 PM, Gregory Neagle <gregn...@mac.com> wrote:

Still not getting the extreme aversion to simply zipping up a directory. Presto: a web archive.

What am I missing?

Yeah....um, after vetting this with you and learning more about the processes, I have absolutely no argument to support an aversion to the archive approach.

--

Joe Wollard

[Joe Wollard]

One thing that still isn't clear to me about the archive approach is how MSC will know how to find content for the banner/side/footer. Subfolders within the archive?

--

Joe Wollard

[Samuel Keeley]

I would think that keeping this generally in line with the way munki handles other items it downloads would make it work better.  By this, I mean that the .zip (or whatever else) would be defined in a pkginfo, with a special type, and be contained in catalogs.  Then, in a new manifest key, the name defined in the pkginfo would be defined.

I assume that the key in the manifest would be a string, not an array, as you would only have one customization, but perhaps not.

The reason for this would be to make a versioning and testing workflow work just like any other package in munki.  If I were to create a new customization with the currently proposed method, I would need to modify manifests to test it, specifying the new filename, which would become pretty tedious.

Instead, if it was imported to the repo and added to a testing catalog with a version, simply adding that testing catalog to the client manifest would allow much more rapid testing, and moving it into production would be as simple as changing the catalogs it is in.

This would still allow machines to have different customizations, as they would be defined by the customization's name in the manifest.

Samuel Keeley

[Gregory Neagle]

Why does it need to be subfolders? Archive content is unzipped to a specific place, therefore all the URLs are relative to the local root. So if the zip archive is unzipped to client_assets (accessible from the html root):

client_assets contains:

apple.png

        chrome.png

footer.html

google.png

showcase.html

sidebar.html

showcase.html contains:

                <div class="showcase ${hide_showcase}">

                    <div class="stage" onClick='stageClicked();'>

                        <img href="http://www.apple.com" alt="Apple" src="client_assets/apple.png" />

                        <img href="detail-GoogleChrome.html"  alt="GoogleChrome" src="client_assets/chrome.png" />

                        <img href="developer-Google.html" alt="Google" src="client_assets/google.png" />

                    </div>

                </div>

-Greg

[Joe Wollard]

Ah, so the filename becomes the important part. Makes sense.

[Gregory Neagle]

Keep in mind that the more complex the implementation, the less likely you'll see an implementation soon...

-Greg

[Gregory Neagle]

Yes, certain filenames would have to be expected for the showcase (banner), sidebar and footer. html within those files could refer to other arbitrarily named resources.

-Greg

[tackyy]

Because you have to dev those html files. So you want to dev them in git/svn. And use chrome/ff/safari devtools in the process.

If that’s the case it might as well be the same git/svn you have your munki repo in. And chrome/ff/safari aren’t going to render zip files.

tack

[Joe Wollard]

So don't archive them before you've tested them ;-)

[Gregory Neagle]

zip is a transport mechanism. The client will still be rendering unarchived files.

-Greg

[Bart Reardon]

I have no aversion to the zip file idea (extreme or otherwise). I prefer coke but pepsi is fine as well and, just like that analogy, at the end of the day the end result will be the same anyway.

[Erik]

I would prefer Sam's thought process at the sake of implementation time.

[tackyy]

Right. Just because I see it as simpler from a workflow perspective to dev the files in the repo with web dev tools and serve them up just like any other web page without an extra zip step doesn’t mean I’m going to stop using munki if we end up with zips. Munki is still awesome and being able to customize MSC is a welcome step forward, whichever way it goes.

tack

[Gregory Neagle]

Convince me the added complexity is worth it.

You can easily have a testing/production workflow for the customizations.

Testing a customization should not be an extended affair; you should be able to test a customization in a few minutes (or seconds!) on a single machine.

That machine would have

<key>client_assets</key>
<string>testing.zip</string>

You'd create your new customization files and upload them to the server as "testing.zip". You'd test. Happy?

cp testing.zip production.zip

Etc.

I'm not _opposed_ to Sam's idea, but:

Now we need to update makepkginfo to create these. We need to make sure there's no unexpected interaction with other pkginfo items/types. One that immediately occurs to me: admin names the client customization the same as an existing software item -- maybe there's a new version of Office the org wants to highlight, so they create a new customization named "Office2014", not thinking that it will conflict with the "Office2014" pkginfo for the actual Office 2014 installer package...

So I need to be convinced that additional complexity is actually worth it. So far, I'm not convinced.

-Greg

On Mar 27, 2014, at 5:05 PM, Erik <eriknico...@gmail.com> wrote:

> I would prefer Sam's thought process at the sake of implementation time.
>

[Gregory Neagle]

On Mar 27, 2014, at 5:03 PM, Bart Reardon <bart.r...@gmail.com> wrote:

 I prefer coke but pepsi is fine as well 

No it isn't!

[Tim Sutton]

I'm definitely in favor of the client simply downloading a zip file via the same "get resource if changed" mechanism used everywhere else in Munki. I'd be very much ok if it simply looks in a fixed location for a zip and uses it if it exists.

I also had had the thought of the possibility of different resources for different clients, and imagined a mechanism in which the client first tries to fetch a zip file named after its manifest, then included_manifests, etc. and eventually falling back to site_default. This would also make it easy to test modifications on a test manifest without affecting other production clients (although I imagine there are many other ways to do this, ie. using the local cache).

But besides the fact that this would result in a lot of useless requests, it's potentially confusing to configure and document, and it could be difficult to follow the search order as included manifests are potentially recursed into. 

So, having talked myself out of that idea, if it were decided to be still useful to have this capability, perhaps an additional manifest key like "resource_archive_path" that is simply a repo-relative path (or possibly a full path with a URL scheme) is more practical and clear. Although again, only one archive can be chosen, so there is still potential for confusion in the "manifest inheritance". It would probably make sense for it to be the first one it finds in parsing manifests and just stop there.

If the mechanism is simple, the implementation should be as well, and could easily come from one of us and Greg can focus on other things.

Tim

[Gregory Neagle]

So what about sites that choose not to customize at all? Should all their clients make a useless request for http://munki/client_assets/assets.zip (or whatever)?  Is that a big deal?

-Greg

[Tim Sutton]

Good point. I guess not, given that now clients are potentially making many more requests to check the icon assets.

Tim

[Nate Walck]

I say start simple and add complexity as needed. I think 98% of everyone would be well served with one .zip file with custom branding in it.

Nate

[Bart Reardon]

Ha...at least it's not Dr Pepper...yech! (ducks)

anyway, I agree with what Nate said earlier and start simple and if that's a zip file of stuff then awesome because it's already a huge step forward. I'm sure the urgent needs and use cases will find their way to the top of the issues list soon enough.

Bart

[A.E. van Bochoven]

On 27 mrt. 2014, at 23:37, Gregory Neagle <gregn...@mac.com> wrote:

So it sounds like people want something I had not considered: a way to customize MSC.app per client: one client might see one set of banners, have one sidebar, and one footer; another client would have a different set of banner images (and URLs), a different sidebar, and a different footer.

The obvious way to handle this is a new key and value set in the client manifest.

We could avoid the need to use a zip file (though I don't really see the big deal), but it increases the complexity of the values in the client manifest.

IE:

<key>client_web_assets</key>

<string>myorg_assets.zip</string>

Putting everything in a zip just moves the complexity to the zip file. (You still need a way to define which urls link to which banners)

I would be in favor of this approach, if you need the web assets in more manifests, you can move them to an included manifest. 

I see that it adds some complexity to the munki client, because it has to download/check all separate files instead of one zip, but unpacking/verifying a zip adds complexity as well. (but maybe you already have this in place?)

If you choose the first option, could you make it so that we can add the second one in the future? I would propose something like

<key>client_web_assets</key>

<dict>

<key>zip_archive</key>

<string>my_assets.zip</string>

</dict>

That way we/I could add things to the dict in the future.

There’s one more thing: it would be nice if the url parser can detect full urls as well so we could host the web_assets on another server than the munki server.

I can see people in the communication department to be in charge of the webassets, so something like this could work:

<key>client_web_assets</key>

<dict>

<key>zip_archive</key>

<string>https://com.dept.server.org/munki/my_assets.zip</string>

</dict>

-Arjen

-- 
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/d/optout.

-- 
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/d/optout.

-- 
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/d/optout.

-- 
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/d/optout.

-- 
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/d/optout.

-- 
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/d/optout.

-- 
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/d/optout.

[Marnin]

I agree with Nate.

Marnin

[Gregory Neagle]

On Mar 28, 2014, at 1:38 AM, A.E. van Bochoven <ne...@mac.com> wrote:

On 27 mrt. 2014, at 23:37, Gregory Neagle <gregn...@mac.com> wrote:

So it sounds like people want something I had not considered: a way to customize MSC.app per client: one client might see one set of banners, have one sidebar, and one footer; another client would have a different set of banner images (and URLs), a different sidebar, and a different footer.

The obvious way to handle this is a new key and value set in the client manifest.

We could avoid the need to use a zip file (though I don't really see the big deal), but it increases the complexity of the values in the client manifest.

IE:

<key>client_web_assets</key>

<string>myorg_assets.zip</string>

Putting everything in a zip just moves the complexity to the zip file. (You still need a way to define which urls link to which banners)

No, that's in the showcase/banner HTML. Did you see the html I posted earlier?

I would propose something like

<key>client_web_assets</key>

<dict>

<key>zip_archive</key>

<string>my_assets.zip</string>

</dict>

That way we/I could add things to the dict in the future.

There’s one more thing: it would be nice if the url parser

There IS NO URL PARSER. I don't want to write one. There is only the WebView.

can detect full urls as well so we could host the web_assets on another server than the munki server.

I can see people in the communication department to be in charge of the webassets, so something like this could work:

<key>client_web_assets</key>

<dict>

<key>zip_archive</key>

<string>https://com.dept.server.org/munki/my_assets.zip</string>

</dict>

I'm not interested in supporting this additional complexity at this time.

[A.E. van Bochoven]

On 28 mrt. 2014, at 14:08, Gregory Neagle <gregn...@mac.com> wrote:

<key>client_web_assets</key>

<string>myorg_assets.zip</string>

Putting everything in a zip just moves the complexity to the zip file. (You still need a way to define which urls link to which banners)

No, that's in the showcase/banner HTML. Did you see the html I posted earlier?

I did see that, but I was unsure if you would create that on-the-fly based on the snippet you sent. The answer is no apparently.

I thought there was going to be some logic in the client, but if there’s just 3 html files and some images in the zip, I’m fine with that. 

It’s easy to host the images somewhere else and point to them in the html:

                <div class="showcase ${hide_showcase}">

                    <div class="stage" onClick='stageClicked();'>

                        <img href="http://www.android.com"  alt="Branding" src="http://img580.imageshack.us/img580/3214/cnabanner00.png" />

                    </div>

                </div>

-Arjen

[Gregory Neagle]

On Mar 28, 2014, at 6:44 AM, A.E. van Bochoven <ne...@mac.com> wrote:

On 28 mrt. 2014, at 14:08, Gregory Neagle <gregn...@mac.com> wrote:

<key>client_web_assets</key>

<string>myorg_assets.zip</string>

Putting everything in a zip just moves the complexity to the zip file. (You still need a way to define which urls link to which banners)

No, that's in the showcase/banner HTML. Did you see the html I posted earlier?

I did see that, but I was unsure if you would create that on-the-fly based on the snippet you sent. The answer is no apparently.

It's definitely no.

Logic in the client means _more_ limitations. Simpler is better and more flexible.

but if there’s just 3 html files and some images in the zip, I’m fine with that. 

It’s easy to host the images somewhere else and point to them in the html:

                <div class="showcase ${hide_showcase}">

                    <div class="stage" onClick='stageClicked();'>

                        <img href="http://www.android.com"  alt="Branding" src="http://img580.imageshack.us/img580/3214/cnabanner00.png" />

                    </div>

                </div>

Sure, with the risk that if your externally-hosted images aren't available, your client looks crappy.

-Arjen

[Erik]

Here's the main problem I have with the zip idea.

Let's say each site already has their own zip and I decide to add one banner. This means I have to create around 12 new archives. If I want to add a banner to just a few, I again have to create a new archive per-site. With zips, I'm probably going to have to document what banners are in what zip and make sure I keep the archives intact. If you add more admins/sites into this equation, I can see this feature being a mess.

If we have them in a pkginfo/manifest, we can iterate and manipulate what the client sees quickly. I do see some issues if we use manifest though (banners referenced in two manifests, etc), but I still think it is a better approach. Testing is always going to be easy, but maintaining these zips sounds like a logistical nightmare.

All of this aside - this isn't a must have feature. I'm perfectly content with how MSC looks right now and I'd rather we focus on other things. Let's keep it simple for now and change it later.

[Gregory Neagle]

On Mar 28, 2014, at 6:49 AM, Erik <eriknico...@gmail.com> wrote:

Here's the main problem I have with the zip idea.

Let's say each site already has their own zip and I decide to add one banner. This means I have to create around 12 new archives.

Yes. How long could that possibly take? zipping a directory of a few html files and some images should be very fast.

If I want to add a banner to just a few, I again have to create a new archive per-site. With zips, I'm probably going to have to document what banners are in what zip and make sure I keep the archives intact. If you add more admins/sites into this equation, I can see this feature being a mess.

Keep each "sites" set of customization files in a git repo. Don't manage the zip archives; manage the files. Create the zip archives as needed and upload them to the server. That could even be done in a git post-commit hook if you really wanted to automate things.

If we have them in a pkginfo/manifest, we can iterate and manipulate what the client sees quickly. I do see some issues if we use manifest though (banners referenced in two manifests, etc), but I still think it is a better approach. Testing is always going to be easy, but maintaining these zips sounds like a logistical nightmare.

No more so that maintaining a bunch of stuff in manifest files. Now you get to maintain all the customization files still, but instead of a simple zip operation (which can be automated), you _also_ get to edit one or more manifest files (which could also be automated, but this is significantly more difficult).

I still see it as adding unneeded complexity for no good reason.

And since I'm the one doing the coding, you have to convince me to add additional complexity. So far, no-one has.

All of this aside - this isn't a must have feature. I'm perfectly content with how MSC looks right now and I'd rather we focus on other things. Let's keep it simple for now and change it later.

Or you all admit I was right all along... :-)

[Erik]

On Friday, March 28, 2014 8:59:23 AM UTC-5, gregn...@mac.com wrote:

On Mar 28, 2014, at 6:49 AM, Erik <eriknico...@gmail.com> wrote:

Here's the main problem I have with the zip idea.

Let's say each site already has their own zip and I decide to add one banner. This means I have to create around 12 new archives.

Yes. How long could that possibly take? zipping a directory of a few html files and some images should be very fast.

If I want to add a banner to just a few, I again have to create a new archive per-site. With zips, I'm probably going to have to document what banners are in what zip and make sure I keep the archives intact. If you add more admins/sites into this equation, I can see this feature being a mess.

Keep each "sites" set of customization files in a git repo. Don't manage the zip archives; manage the files. Create the zip archives as needed and upload them to the server. That could even be done in a git post-commit hook if you really wanted to automate things.

Damn.

If we have them in a pkginfo/manifest, we can iterate and manipulate what the client sees quickly. I do see some issues if we use manifest though (banners referenced in two manifests, etc), but I still think it is a better approach. Testing is always going to be easy, but maintaining these zips sounds like a logistical nightmare.

No more so that maintaining a bunch of stuff in manifest files. Now you get to maintain all the customization files still, but instead of a simple zip operation (which can be automated), you _also_ get to edit one or more manifest files (which could also be automated, but this is significantly more difficult).

I still see it as adding unneeded complexity for no good reason.

And since I'm the one doing the coding, you have to convince me to add additional complexity. So far, no-one has.

All of this aside - this isn't a must have feature. I'm perfectly content with how MSC looks right now and I'd rather we focus on other things. Let's keep it simple for now and change it later.

Or you all admit I was right all along... :-)

I can't argue now.

 

[Greg Coan]

On Friday, March 28, 2014 9:49:48 AM UTC-4, Erik wrote:

Here's the main problem I have with the zip idea.

Let's say each site already has their own zip and I decide to add one banner. This means I have to create around 12 new archives. If I want to add a banner to just a few, I again have to create a new archive per-site. With zips, I'm probably going to have to document what banners are in what zip and make sure I keep the archives intact. If you add more admins/sites into this equation, I can see this feature being a mess.

Personally I don't see how that's any different than maintaining / updating an html repo of 1234.jpg's somewhere.  If you are going to customize MSU for different sites its going to *have* to managed/documented/updated by someone.  If you are going to allow multiple admins to do that as well the same issues apply.

I agree with your last comment though.  There are probably other issues more important :-) 

[Stu Harrop]

The dead horse can't be beat any more.  Greg was right all along.  I would say once Munki 2 is officially released, and there is still a sore point using a zipped set of files then it can be reviewed again.

--

[Erik]

There is a key difference. An admin can view the file and it's technically already documented.

pkginfo/manifest contains:

<banner>banner1.jpg<banner>
<banner>banner2.jpg<banner>
<footer>footer_site1<footer>
<sidebar>sidebar_site2<sidebar>

Git pretty much resolves my problem with this though.

[Joe Wollard]

I'm back to muddy the waters again. I might be in the minority here, but I actually like web development. As such, I keep thinking about how the App Store's web content is fairly dynamic and how this implementation doesn't really allow that kind of behavior...not to mention, adding that behavior in a cached client-side environment would be rough. So, what if we scratched most of what we've talked about (keeping the zip notion in mind, which I'll address in a bit).

Why don't we just add a few keys to the client-side ManagedInstalls that tell MSC where to start? Like, mscBannerURL, mscSidebarURL, and mscFooterURL. Why do this? Well, let's say I don't want MSC to cache anything, instead opting to serve pages from my web server dynamically. When MSC makes the request, it could pass along the ClientIdentifier as an argument, so I can decide what content to show in the server-side logic. I'm sure there are other GET params that could be passed to make things even more interesting, but I'll keep it simple for now.

So what about people who don't want to host this content and want to use the zip archive method we've been talking about? When managedsoftwareupdate runs, it might do something like this:

 - are the msc* keys present in ManagedInstalls?

    - no? - load the default content originally bundled with MSC

    - yes?

        - does the url end with a .zip extension?

           - yes? - download and decompress the zip if needed, and tell MSC where to find the files

           - no? - tell MSC to grab the files from the hosted URL instead.

If MSC is using NSURL, I don't think it will care if it's told to load items from the local disk (file://) or web (http://|https://). MSC could be 'told' where to load the files via its own cfprefs domain, which managedsoftwareupdate would write to when needed.

This _seems_ like it's very simple in terms of coding, it provides a ton of flexibility in terms of content delivery, and provides more flexibility in where the content should be hosted.

Let the shooting begin - aim, fire!

[Gregory Neagle]

On Mar 28, 2014, at 8:42 AM, Joe Wollard <joe.w...@gmail.com> wrote:

I'm back to muddy the waters again. I might be in the minority here, but I actually like web development. As such, I keep thinking about how the App Store's web content is fairly dynamic and how this implementation doesn't really allow that kind of behavior...not to mention, adding that behavior in a cached client-side environment would be rough. So, what if we scratched most of what we've talked about (keeping the zip notion in mind, which I'll address in a bit).

Why don't we just add a few keys to the client-side ManagedInstalls that tell MSC where to start? Like, mscBannerURL, mscSidebarURL, and mscFooterURL. Why do this? Well, let's say I don't want MSC to cache anything, instead opting to serve pages from my web server dynamically. When MSC makes the request, it could pass along the ClientIdentifier as an argument, so I can decide what content to show in the server-side logic. I'm sure there are other GET params that could be passed to make things even more interesting, but I'll keep it simple for now.

All of MSC.app's content is locally-based. The html is generated dynamically from templates and information in /Library/Managed Installs.

I see no non-complex way to mix-and-match. Sure, you can have image URLs point to external resources and so on, but the main HTML rendered by MSC.app is locally generated. Therefore at _least_ the showcase, sidebar and footer html bits will have to be downloaded locally so they can be added to the main html of the page that is being generated locally.

If we have to download something, what difference does it make if it's a zip file containing those three files (which then refer external resources if you like) or 100 files: the three html files plus a bunch of included resources? I don't have to care -- MSC.app can do the same thing in either case.

So what about people who don't want to host this content and want to use the zip archive method we've been talking about? When managedsoftwareupdate runs, it might do something like this:

 - are the msc* keys present in ManagedInstalls?

    - no? - load the default content originally bundled with MSC

    - yes?

        - does the url end with a .zip extension?

           - yes? - download and decompress the zip if needed, and tell MSC where to find the files

           - no? - tell MSC to grab the files from the hosted URL instead.

Look at all that complexity!

If MSC is using NSURL, I don't think it will care if it's told to load items from the local disk (file://) or web (http://|https://). MSC could be 'told' where to load the files via its own cfprefs domain, which managedsoftwareupdate would write to when needed.

This _seems_ like it's very simple in terms of coding,

Code is on Google Code. Fork it and show us a sample implementation.

it provides a ton of flexibility in terms of content delivery, and provides more flexibility in where the content should be hosted.

Let the shooting begin - aim, fire

[Josh Malone]

I'm not seeing the problem either. The zip file has my vote.

On Mar 27, 2014 7:41 PM, "Gregory Neagle" <gregn...@mac.com> wrote:

Still not getting the extreme aversion to simply zipping up a directory. Presto: a web archive.

What am I missing?

-Greg

On Mar 27, 2014, at 4:40 PM, Joe Wollard <joe.w...@gmail.com> wrote:

Well then...never mind :)

Too bad OS X doesn't come with wget or you could obtain the same behavior in managedsoftwareupdate, and curl is of no help with crawling and archiving without being wrapped in additional scripts. :-/

On Thu, Mar 27, 2014 at 7:37 PM, Gregory Neagle <gregn...@mac.com> wrote:

On Mar 27, 2014, at 4:35 PM, Joe Wollard <joe.w...@gmail.com> wrote:

I wasn't clear - I realize it's all stored client-side now, but the problem we're trying to figure out is _what_ should be gathered and cached by MSC on the client. My thought with this was to leave this to the WebView.

Too late.

mangedsoftwareupdate needs to download all the content _before_ MSC.app runs. MSC.app downloads nothing. Ever. 

It already knows how to do caching of the page and its associated assets, but how much control does the 'not-employed-by-apple' programmer have over that? The only additional requirement this would impose on admins is the need to specify a full url to images/scripts/css instead of relative paths.

That's precisely what is and will be happening. The resources are all local. All the HTML is local _now_. Look in ~/Library/Caches/com.googlecode.munki.ManagedSoftwareCenter/html

If so, this seems like the simplest and most flexible option to me; no manifests,

How, then, do we serve different content to different clients?

no zip archives to create, just client-side cache management. Just three files to initially request by MSC; banner.html, sidebar.html, and footer.html

What about the (variable number of) banner images? They must also be downloaded and cached. And no, I don't want to parse the html in  banner.html, sidebar.html, and footer.html to see what other resources I might need to cache.

--
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/d/optout.

--
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/d/optout.

--

Joe Wollard

--
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/d/optout.

[Josh Malone]

On Mar 28, 2014 11:42 AM, "Joe Wollard" <joe.w...@gmail.com> wrote:
>
> I'm back to muddy the waters again. I might be in the minority here, but I actually like web development. As such, I keep thinking about how the App Store's web content is fairly dynamic and how this implementation doesn't really allow that kind of behavior...not to mention, adding that behavior in a cached client-side environment would be rough. So, what if we scratched most of what we've talked about (keeping the zip notion in mind, which I'll address in a bit).

Would it not be possible for people who want live, "dynamic" content in msc to just use frames in the html content in the zip file? I think it should be up to the web developer to find a way if he/she wants something more complex.

-Josh

[Joe Wollard]

Yeah, I think that would be fine. The reason I suggested additional URL keys on the client manifest was an attempt to build on an existing concept (think SoftwareUpdateServerURL). However, this was also working under the assumption that the header, sidebar and footer were individual WebViews, and 'frames' in their own way. It seems that there's only one WebView, which makes it clear why the last suggestion I made would have added, not reduced complexity.

--

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/d/optout.

--

Joe Wollard

[Joe Wollard]

s/client manifest/ManagedInstalls

--

Joe Wollard

[Bart Reardon]

Some preliminary testing of the zip bomb idea got me thinking about sidebar links and some gotchas.

<a href="...

will open a web page inside the MSC application. This I am finding really handy and will use if for our internal user documentation, which will obviously only work when online (I'm thinking of including an initial static page with some JS that detects online status then enables external to MSC links etc etc...hurrah for flexibility). The issue I found with testing is if a web page contains a download MSC craps out when you click the download link. For example, some of our online documentation is in downloadable word format (don't ask) but clicking on the link does nothing for the user.

This is what's recorded in the log:

2014-03-31 17:05:31.929 Managed Software Center[53371:303] Provisional load error: Error Domain=WebKitErrorDomain Code=102 "Frame load interrupted" UserInfo=0x618000660ec0 {NSErrorFailingURLStringKey=http://foo.com/Content/Mac-SetupAppleMail.docx, NSLocalizedDescription=Frame load interrupted, NSErrorFailingURLKey=http://foo.com/Content/Mac-SetupAppleMail.docx}

<a target="_blank" href="...

Will open the link in the default browser where this isn't an issue obviously. 

I guess where I'm going with this is, is there a way to open a web page inside MSC where clicking on a file link initiates a download? I can work around whatever is or isn't possible and incorporate it into planned links in the sidebar (and banner and footer) but may be worth keeping in mind.

Bart

[Joe Wollard]

I guess where I'm going with this is, is there a way to open a web page inside MSC where clicking on a file link initiates a download? I can work around whatever is or isn't possible and incorporate it into planned links in the sidebar (and banner and footer) but may be worth keeping in mind.

This would likely be a function of the headers sent by your server rather than something you could do on the client side. Specifically, the Content-Disposition header is a good place to start: http://en.wikipedia.org/wiki/List_of_HTTP_header_fields 

[Bart Reardon]

Presume I don't have access to modify the web server behaviour or content (because I don't).

This works fine in Safari proper (or firefox or chrome for that matter). What I'd like to know is if you couldm from within MSC, trigger the default browser to download a clicked link or have the webview within MSC process the download.

It's ok if it can't be done. I'll just open these pages external from MSC. I just thought the ability to view a page within MSC is very useful for support documentation.

[Gregory Neagle]

MSC.app will never be a full browser implementation.

Even if adding file download capability wasn't too much work, we'd also need to add some UI to track download progress and to help the user understand _where_ the downloaded file was saved to, etc.

I think if you need to do anything more that display an HTML page you should send the URL to the default browser using the target="_blank" mechanism.

-Greg

[Gregory Neagle]

In the case where the admin doesn't follow the advice below:

http://code.google.com/p/munki/source/detail?r=ae1290714358

Causes non-displayable content to be forwarded to the user's default browser. So in Bart's original case, http://foo.com/Content/Mac-SetupAppleMail.docx would get redirected to Safari, Firefox or Chrome (or whatever).

-Greg

[Bart Reardon]

love your work.

I'll have to post you a box of tim-tams or something as thanks.

[nbalonso]

I am with Tim Sutton and I like the idea of a zip download only if changed, using the manifest fallback principle and trying to get http://munki/client_assets/site_default.zip as last resource.

Logging errors for any asset not found is not an issue for me.

[David Iwanicki]

Any final decision on implementing customization of MSC? I personally just want to change the sidebar links to point to our internal help desk.

David

[Gregory Neagle]

On Apr 14, 2014, at 1:45 PM, David Iwanicki <david.i...@gmail.com> wrote:

Any final decision on implementing customization of MSC? I personally just want to change the sidebar links to point to our internal help desk.

You will be able to do this.

David

On Thursday, March 27, 2014 11:44:20 AM UTC-4, gregn...@mac.com wrote:

NOTE: this post is about Munki 2, which is in-development code for the next major release of Munki. It is not production ready. Do not deploy on your fleet unless you like pain and suffering.

The new Managed Software Center application for Munki 2 will support some customization. Specifically, you will be able to specify custom banner images, custom sidebar content, and a custom footer.

I think these should be downloaded from the Munki repo, so that admins can easily highlight new things without having to install anything on local machines.

My current thought is that the admin will create a set of html (or html-like) files in a directory, then zip this directory and upload it to the repo with a specific name.

The Munki client will check a predefined URL to download this file and expand the contents into a directory that MSC.app will use for the custom contents.

Does anyone see an issue with this approach?

-Greg

[David Iwanicki]

I took your advice and pulled a clone. I've made some changes to implement an approach for this which should be light-weight yet flexible. Please take a look:

https://code.google.com/r/davidiwanicki8-customization-msc/

-----

Added modifications to allow for use of custom branding/banners, sidebar, and footer for Managed Software Center. Custom versions of the footer, showcase, and sidebar templates are triggered by a new key in ManagedInstalls.plist: CustomMSC (BOOL). If CustomMSC is YES, custom templates from /path/to/Managed Installs/custom_templates/ will be used instead of the default templates bundled in the app. 

Requirements: 

1. defaults write /Library/Preferences/ManagedInstalls.plist CustomMSC -bool YES 

-or-

<code language="xml">

                <key>CustomMSC</key>

<true/>

                </code>

2. The following must exist in /path/to/Managed Installs/custom_templates:

footer_template.html

showcase_template.html

sidebar_template.html

You can copy the default templates from the .app bundle and make desired changes.

3. (optional) /path/to/Managed Installs/banners/

a symlink to this location is created to expose it in the app’s html cache - replace “static” with “banners” in showcase_template.html to use graphics from this location instead.

“branding.png” format: 1158x200, 72px, RGB, Alpha channel supported. No pattern matching on name, images are iterated by being listed in the showcase <div> of showcase_template.html

Customization can be deployed via Munki as a package containing /custom_templates and /banners folders with your desired html and pngs inside, and a postinstall script to set the state of CustomMSC. reverting to default behavior is as simple as setting CustomMSC to NO or false (or just deleting the key).

-----

[Gregory Neagle]

Thanks, but that's not the direction I'm going.

-Greg

[Gregory Neagle]

That came off more brusque than intended.

It's always a good idea to discuss any proposed code changes with me or in this forum before writing actual code; that way you avoid going in a direction that's not compatible with what I'm working on/have planned, or work on code that I currently have in flux. It's just too hard for me to navigate multiple branches all changing code in the same places.

Right now all of MSC.app is in flux, so anyone submitting patches against it is likely to be denied. (nbalonso got lucky: he was working on something far away from things I was working on, and his changes were neat and easily integrated. More importantly, they were almost exactly what I was planning to do eventually.)

-Greg

[David Iwanicki]

No worries here - I came up with a solution I liked for my situation and thought I would share the approach I took.

David

[nbalonso]

For the record, when I made a comment about Greg's reply being cold I wasn't laughing at Greg nor David. I was identifying myself with the situation.

I believe that at some point all of us have had an eureka moment, sat in front of a keyboard, wrote some lines of code that in the end don't get used. All in all they usually are learning experiences.

Sorry for the off-topic.

Regards,
Noel

[Daniel Warren]

I understand that MSC.app will never be a fully functional browser.  With that being said are their any plans for it to support PHP e.g. will munki report php ever be accessible within the app?

-Dan W.

[Gregory Neagle]

On Jun 3, 2016, at 8:19 AM, Daniel Warren <dwa...@natickps.org> wrote:

I understand that MSC.app will never be a fully functional browser.  With that being said are their any plans for it to support PHP e.g. will munki report php ever be accessible within the app?

I have no idea what you are trying to accomplish.

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

[Gregory Neagle]

On Jun 3, 2016, at 8:19 AM, Daniel Warren <dwa...@natickps.org> wrote:

I understand that MSC.app will never be a fully functional browser.  With that being said are their any plans for it to support PHP

Also: no browsers need to support PHP: that's done on the server side. The server sends HTML, CSS and JavaScript to the browser.

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

[Warren, Daniel]

I have two links that I've added to the sidebar that I would like to open within MSC.  Both are internal one to our munki report php login page and another to our internal helpdesk.  Both of these links will open in an external web browser, but do not load within munki.  I have other links that will load, but those two are the only ones that are internal.  Munki report is on the same server as the munki repo.  Both of these sites use php hence my conclusion that it might be the issue.  Forgive me I am limited in my exposure to HTML

--

Daniel W Warren
Application Distribution Specialist
Natick Public Schools
(508)-647-6400 x1728

[A.E. van Bochoven]

The issue you are seeing is probably caused by ATS (Application Transport Security), you might try if this build fixes your issue:

https://munkibuilds.org/2.7.0.2763/munkitools-2.7.0.2763.pkg

-Arjen

[Warren, Daniel]

Thanks that did the trick.  Sorry to confuse everyone and assume it was something that it was not.

-Dan