MunkiWebAdmin2 in early testing

[Gregory Neagle]

https://github.com/munki/mwa2

MWA2 is a major rethink of web-based administration of Munki.

All reporting has been removed from MWA2 — consider using Sal or MunkiReport-PHP for reporting. Both are excellent.

MWA2 focuses on web-based editing of manifests and pkginfo files.

If you decide to play around with this: please do not point it at a production Munki repo.

-Greg

[Gregory Neagle]

We’ve already had some contributions and some bug fixes: https://github.com/munki/mwa2/commits/master

Issue list is here: https://github.com/munki/mwa2/issues

Looking for any and all feedback at this point, but here are some specifics that would be helpful:

1) How hard/easy is it to setup the demo? (Answering this one might help others decide whether or not they have time to test MWA2)

2) Usability issues: could you see yourself (or your team) using this to edit manifest and pkginfo files?

3) Performance: acceptable? Too slow? If too slow: how many manifests do you have? How many pkginfo files do you have? What is the connection between your demo/testing machine and the Munki repo?

4) UI issues: is there anything that is confusing or counterintuitive? Are there operations that don’t work as expected?

5) Data loss/munging: are there any operations or workflows that lead to manifest files or pkginfo files being deleted/destroyed/corrupted?

Thanks for any feedback!

-Greg

[Gregory Neagle]

Another note unless it’s not clear: when using the demo setup you can update to the latest MWA2 code by cd’ing into the mwa2 directory and doing a `git pull`.

-Greg

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.
To post to this group, send email to munk...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Joe Wollard]

On Jan 12, 2016, at 9:11 PM, Gregory Neagle <gregn...@mac.com> wrote:

We’ve already had some contributions and some bug fixes: https://github.com/munki/mwa2/commits/master

Issue list is here: https://github.com/munki/mwa2/issues

Looking for any and all feedback at this point, but here are some specifics that would be helpful:

1) How hard/easy is it to setup the demo? (Answering this one might help others decide whether or not they have time to test MWA2)

A++ on this. It's basically just a matter of running a script. Compared to the previous version, setting up the demo was a breeze.

2) Usability issues: could you see yourself (or your team) using this to edit manifest and pkginfo files?

Seems useful. Forms/widgets for the basic and intermediate operations and aceEditor for access to the raw plist in the browser seems to cover all the bases nicely.

I noticed some code stubs in there for running makecatalogs in the browser as well - I'm a fan of that eventual functionality ;)

3) Performance: acceptable? Too slow? If too slow: how many manifests do you have? How many pkginfo files do you have? What is the connection between your demo/testing machine and the Munki repo?

N/A

4) UI issues: is there anything that is confusing or counterintuitive? Are there operations that don’t work as expected?

Aesthetics could use some polish (I'll send a PR if I come up with anything), but functionally the UI makes sense to me. 

5) Data loss/munging: are there any operations or workflows that lead to manifest files or pkginfo files being deleted/destroyed/corrupted?

No death or accidental dismemberment of any manifests or pkgsinfo files observed to date.

Thanks for any feedback!

-Greg

On Jan 7, 2016, at 4:52 PM, Gregory Neagle <gregn...@mac.com> wrote:

https://github.com/munki/mwa2

MWA2 is a major rethink of web-based administration of Munki.

All reporting has been removed from MWA2 — consider using Sal or MunkiReport-PHP for reporting. Both are excellent.

MWA2 focuses on web-based editing of manifests and pkginfo files.

If you decide to play around with this: please do not point it at a production Munki repo.

-Greg

--
You received this message because you are subscribed to the Google Groups "MunkiWebAdmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-web-adm...@googlegroups.com.
Visit this group at https://groups.google.com/group/munki-web-admin.

[Erik Gomez]

It's really nice to see you back.

--

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.

[Joe Wollard]

Reports of my death are greatly exaggerated ;)

Sent from my iPhone

[Matt Cahill]

On Wednesday, 13 January 2016 15:12:01 UTC+13, gregn...@mac.com wrote:

We’ve already had some contributions and some bug fixes: https://github.com/munki/mwa2/commits/master

Issue list is here: https://github.com/munki/mwa2/issues

Looking for any and all feedback at this point, but here are some specifics that would be helpful:

1) How hard/easy is it to setup the demo? (Answering this one might help others decide whether or not they have time to test MWA2)

Super easy to set up, made a local copy of my repo and ran the script. Excellent.

2) Usability issues: could you see yourself (or your team) using this to edit manifest and pkginfo files?

 Seems like it could be very useful, especially as it makes munki more accessible for the uninitiated admins in the team.

 

3) Performance: acceptable? Too slow? If too slow: how many manifests do you have? How many pkginfo files do you have? What is the connection between your demo/testing machine and the Munki repo?

 

Runs perfectly well on my macbook pro, maybe I have a small repo ;)

4) UI issues: is there anything that is confusing or counterintuitive? Are there operations that don’t work as expected?

Rendering of the UI elements in the edit panes is a little strange on chrome for me 

e.g. Text boxes seem to be as small as possible meaning they have to be resized using the handle to see the contents (single line boxes are ok).

The details pane is larger than the "frame" that contains it meaning you have to scroll horizontally to see the last little bit of the contents.

Text boxes can be resized horizontally which blocks out all titles.

5) Data loss/munging: are there any operations or workflows that lead to manifest files or pkginfo files being deleted/destroyed/corrupted?

Nothing broken so far 

Thanks for any feedback!

-Greg

What is the intended workflow around git? Would I be able to configure a git push to a review branch on save?

Looking great so far.

Cheers

Matt

[Gregory Neagle]

On Jan 14, 2016, at 9:06 PM, Matt Cahill <cahill...@gmail.com> wrote:

What is the intended workflow around git? Would I be able to configure a git push to a review branch on save?

The current code does something very, very simple: it git adds and commits the changed file (or git rms and commits a deleted file) No branching.

The intent is to provide a bit of an audit trail (who made this change and when), and to provide a way to recover from mistakes (by using git to revert to an older version of a file or retrieve a deleted file).

Nothing so grand as review branches; that would complicate things like makecatalogs: you make a change to a pkginfo file; it gets committed to a review branch. makecatalogs would then _ignore_ the change until someone moved it from review to master. So now MWA2 needs to be even more git-aware and be able to switch git branches… it rapidly gets pretty complex and then it doesn’t meet _your_ needs exactly so more complexity is added to abstract more stuff so local admins can customize more…

Something to consider for the future, I suppose, if the need and desire (and coding talent) is there…

-Greg

[Matt Cahill]

Thanks Greg. 

Just to clarify I wasn't thinking of the requirement to add advanced git management to mwa2 per se, just the ability to add a simple push up to gitlab or similar. I suppose the particular branch would be irrelevant really just a push to origin after the commit would be required for mwa2 to work for us.

We keep our repo on a gitlab server and any push events to that repo trigger a pull on the munki server via a web hook. As a result we'd need mwa2 to work on it's own copy of the repo and push any changes to gitlab where they'd subsequently go live. If it worked directly on the live repo any changes made there would get wiped out by the next push to the gitlab repo.

I'll see if I can prototype it using the demo.

Cheers

Matt

[Clayton Burlison]

1) The demo script has made testing this extremely easy. Thank you.

2) This has been a almost perfect drop in replacement for Joe Wollard's Mandrill and seeing as how I might be the only person running Mandrill in production yes I will be using switching to MWA2 eventually.

3) Performance has been fantastic. ~500 manifests, ~700 pkinfo files. And MWA2 was running on a test server locally and most scans took less than one second. When I mounted over SMB and tested the performance was also quite snappy however when deployed to production it will be running locally on the server hosting my munki repo.  

4) Everything is pretty straight forward. All the operations I have tested work properly. The only UI related note I have is when items with long names or strings appear the line wrapping is less than idea. My manifest is a flat directory structure so no issue there however I have some pkginfo files with long names and long versions which creates horizontal scrolling. 

Mandrill got around this "issue" by having the editor UI in a separate window from the listings. I'm not sure how much effort a change like this might be however it might be beneficial. Another idea would be to make the two window elements, listing and editors, collapsable (not sure the repercussions of that either). If you want to see screen shots of Mandrill without spinning it up for a test: https://www.dropbox.com/sh/apgzwes0rl17u0m/AAB3f7huUKD7OOjoMshJ0UpNa?dl=0 

5) Data loss/munging: Haven't found any yet. Tried most of the daily operations a few times with out issue. I'm kind of curious what would happen with more than on Munki Admin modifying the same file at the same time. However, in my environment that will never be an issue. IE - jane and jim both have the same manifest open for editing. jim clicks save. what happens to jane's save.

--Cheers, Clayton

[Gregory Neagle]

On Jan 14, 2016, at 9:06 PM, Matt Cahill <cahill...@gmail.com> wrote:

4) UI issues: is there anything that is confusing or counterintuitive? Are there operations that don’t work as expected?

Rendering of the UI elements in the edit panes is a little strange on chrome for me 

Any significant difference from Safari or Firefox?

e.g. Text boxes seem to be as small as possible meaning they have to be resized using the handle to see the contents (single line boxes are ok).

This is normal, if I understand your description properly. You can scroll or resize to view additional contents if desired.

The details pane is larger than the "frame" that contains it meaning you have to scroll horizontally to see the last little bit of the contents.

Same as issue 6? https://github.com/munki/mwa2/issues/6

Text boxes can be resized horizontally which blocks out all titles.

Same as issue 16? https://github.com/munki/mwa2/issues/16

-Greg

[Matt Cahill]

On 23/01/2016, at 1:23 PM, Gregory Neagle <gregn...@mac.com> wrote:

On Jan 14, 2016, at 9:06 PM, Matt Cahill <cahill...@gmail.com> wrote:

4) UI issues: is there anything that is confusing or counterintuitive? Are there operations that don’t work as expected?

Rendering of the UI elements in the edit panes is a little strange on chrome for me 

Any significant difference from Safari or Firefox?

Safari and Chrome render the view very similarly. Firefox seems to be more generous with it’s minimum vertical text box size so the whole thing seems less squished up to the top.

e.g. Text boxes seem to be as small as possible meaning they have to be resized using the handle to see the contents (single line boxes are ok).

This is normal, if I understand your description properly. You can scroll or resize to view additional contents if desired.

This is true and works as described for me. I was just wondering in case there is a way to take up all of the vertical space available in any given browser window?

The details pane is larger than the "frame" that contains it meaning you have to scroll horizontally to see the last little bit of the contents.

Same as issue 6? https://github.com/munki/mwa2/issues/6

Yes issue 6 matches what I saw.

Text boxes can be resized horizontally which blocks out all titles.

Same as issue 16? https://github.com/munki/mwa2/issues/16

Yeah issue 16 matches too.

cheers

Matt

-Greg

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---

You received this message because you are subscribed to a topic in the Google Groups "munki-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/munki-dev/o_cSDHNIOCA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to munki-dev+...@googlegroups.com.

[Mike Solin]

I’m really hopeful that someone figures out how to run this on a Windows server (preferably with IIS).  It sounds excellent, and would be really useful in our environment.

Thanks, Greg!

Mike

--

mi...@mikesolin.com / @flammable

http://mikesolin.com

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.

[Ronald Carter]

Mike,

It should be posible you can setup Python and PHP under Windows with IIS I just setup MunkiReport-PHP on IIS. the Apache config will need some work to convert to IIS and should probably stick to SQLite for testing.

[Graham]

You could run Docker on your Windows server:

https://docs.docker.com/engine/installation/windows/

And run MWA2 as a Docker container:

https://hub.docker.com/r/grahamrpugh/mwa2/

Cheers

Graham

[Mike Solin]

Very interesting!  Thanks, everyone.  I’ll start experimenting soon.

Mike

-- 

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

[Gregory Neagle]

Some significant feature additions this weekend:

Mass-deletion of pkginfo items, and mass-editing of pkginfo catalogs.

You use checkboxes in the pkginfo list to select the pkginfo items you are interested in, then click a gear menu:

Mass deletion:

Here’s the current interface for editing the catalogs — you specify catalogs to add and catalogs to remove from the selected pkgsinfo (it’s OK if you add a catalog and it already exists in a certain pkginfo file —  it will not be duplicated, and it’s OK if you tell it to remove a catalog that doesn’t exist in a specific pkginfo file)

I’m considering the use of http://harvesthq.github.io/chosen/#multiple-select to make those multiple-select fields easier to use and more visually appealing.

Since these new features can make mass changes, please do not test on your production Munki repo.

I’ve also overhauled the logging; if you upgrade an existing install you will find all console logging messages will stop. To get them going again, copy the LOGGING dictionary from settings_template.py to your active settings file.

-Greg

[Gregory Neagle]

On Feb 1, 2016, at 10:33 AM, Gregory Neagle <gregn...@mac.com> wrote:

I’m considering the use of http://harvesthq.github.io/chosen/#multiple-select to make those multiple-select fields easier to use and more visually appealing.

Which results in:

[Vaughn Miller]

I like the looks of that!

--
You received this message because you are subscribed to the Google Groups "munki-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-discus...@googlegroups.com.
To post to this group, send email to munki-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/6CE1C2FE-4D02-4E75-9836-1E8414246416%40mac.com.

[Graham]

Nice to see some of the Munki-Do features being added to MWA2 in a well-designed interface - I think the bulk features will be popular. 

I like the look of the second add/remove interface more than the first, but does that mean you have to type in the name of a catalog to add it to either field?

Does removing pkginfo files also remove packages? There's a feature in Munki-Do where you can remove "orphaned" packages, i.e. packages that are no longer associated with pkginfo files.

Cheers

Graham

--

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 Feb 1, 2016, at 8:46 PM, Graham <g.r....@gmail.com> wrote:

Nice to see some of the Munki-Do features being added to MWA2 in a well-designed interface - I think the bulk features will be popular. 

I like the look of the second add/remove interface more than the first, but does that mean you have to type in the name of a catalog to add it to either field?

Try the demo here: http://harvesthq.github.io/chosen/#multiple-select

Does removing pkginfo files also remove packages?

It can...

There's a feature in Munki-Do where you can remove "orphaned" packages, i.e. packages that are no longer associated with pkginfo files.

No feature like that in MWA2 yet.

Next bit I think I’ll work on might be an advanced search for manifests, replacing some of the functionality lost from MWA(1).

To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/CALBk4gmGWcgDR7vV%3DVCRvRo4bdQMG%3DHJEtmuuHAqu674QyBZ7w%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

<PastedGraphic-14.png>

[Graham]

The demo for multiple-select is excellent. I'd definitely vote for including it.

The checkbox for pkg removal - also excellent. Probably negates the need for an "orphaned" packages removal method.

I'd like to ask for better git support (the ability to commit and push, and git branching), and the ability to restrict access to edit certain manifests based on logged in user. I should be able to fork and PR these features though, if there's interest for them.

Cheers,

Graham

[Gregory Neagle]

On Feb 2, 2016, at 7:21 AM, Graham <g.r....@gmail.com> wrote:

The demo for multiple-select is excellent. I'd definitely vote for including it.

Well, good, because I already did. :-)

The checkbox for pkg removal - also excellent. Probably negates the need for an "orphaned" packages removal method.

I'd like to ask for better git support (the ability to commit and push, and git branching), and the ability to restrict access to edit certain manifests based on logged in user. I should be able to fork and PR these features though, if there's interest for them.

I have no idea what those are or how they work (and I did take a look at munki-do), so I would do poor job of implementing them.

I’d consider accepting a PR, but only if the features were explained/documented well enough that I understand them (at a minimum).

Cheers,

Graham

On Tue, Feb 2, 2016 at 12:21 AM Gregory Neagle <gregn...@mac.com> wrote:

On Feb 1, 2016, at 8:46 PM, Graham <g.r....@gmail.com> wrote:

Nice to see some of the Munki-Do features being added to MWA2 in a well-designed interface - I think the bulk features will be popular. 

I like the look of the second add/remove interface more than the first, but does that mean you have to type in the name of a catalog to add it to either field?

Try the demo here: http://harvesthq.github.io/chosen/#multiple-select

Does removing pkginfo files also remove packages?

It can...

<PastedGraphic-13.png><PastedGraphic-13.png>