Initial Imaging of MacBooks.

[Yehuda Alexandroff]

I have a combination of deploy studio and munki for imaging computers.  I first install Munki, and name the computer, using deploy studio and then Munki installs the rest of the software.  These are student computers who belong to a manifest called students.  The problem is that any installs that I make mandatory there, then become mandatory for all the students in the field, interrupting the normal flow of things.  Right now, to avoid this problem, I end up logging in and adding the software I want through Managed Software Center manually. What I'd like to do is have a manifest for onboarding new or repaired computers and then moving them to the student manifest at the end.  I'd love some suggestions.

Thanks,

Yehuda

---

To unsubscribe from future mailings, please click here.

Note that we will still be able to send you certain communications without your express consent where CASL does not apply, CASL exemptions apply, or your consent is implied.

[Gregory Neagle]

> On Jan 26, 2016, at 6:38 AM, Yehuda Alexandroff <yalexa...@bialik.ca> wrote:
>
> I have a combination of deploy studio and munki for imaging computers. I first install Munki, and name the computer, using deploy studio and then Munki installs the rest of the software. These are student computers who belong to a manifest called students. The problem is that any installs that I make mandatory there, then become mandatory for all the students in the field, interrupting the normal flow of things.

What does "interrupting the normal flow of things” mean?

[Nick McSpadden]

Pardon if I misunderstand, but is the issue that you don't want students to be notified of updates in the future via Managed Software Center popping up? 

If you want to turn off students getting MSC popping up, you can use SuppressUserNotification in the preferences plist:
https://github.com/munki/munki/wiki/Preferences#suppressusernotification

This will allow you to apply updates in the background that are marked as unattended_installs, and it won't bother users during the day (or night) with update notifications. The downside, of course, is that you'll need to find time to apply the few updates that can't be installed unattended (such as anything that requires a restart).

--
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/D278792A-1112-47F2-84D4-DBF9200267CC%40mac.com.

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

--

--
Nick McSpadden
nmcsp...@gmail.com

[Adam M. Anklewicz]

Yehuda,

I think I'm reading your email slightly differently than Nick or Greg, maybe I'm right, maybe I'm wrong.

You have them going to a manifest called Students, and you want to add some items to some computers, but not all, right?

You can do a embedded manifest with a condition (based on serial number or hostname or something else), and that embed has that custom software for that user. That's how I used to do it at LBDS. Now at CPC I have each client with its own manifest and each of those are embedded in a master manifest.

Adam

--
Adam M. Anklewicz

ad...@anklewicz.com
http://www.anklewicz.com

To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/CAJySx-mhOK_xHXeb%2BRT-fRX8Xb9CpyH9RidZJKwrpseexemogg%40mail.gmail.com.

[Yehuda Alexandroff]

Let's say I put an updated Forticlient installer into the student manifest.  I want Munki to install it as part of imaging the machine.  I also have a printer that I'm adding to the students manifest as optional.  I think (maybe I'm wrong) that in order to install the printer, the students with the old version of Forticlient will have to update Forticlient before they can install the printer.  This isn't always convenient.  I was hoping to have two different manifests, one for students and one for onboarding, for example, and have the computer moved from one manifest to the other after imaging automatically.

I'm not sure if I'm making myself clear.  Right now all of my manifests are set up according to computer name, with one main manifest that has included manifests for the different user groups, such as students, teachers, office, admin, etc.

Thanks.

[Mr. Alan Siu]

Let's say I put an updated Forticlient installer into the student manifest.  I want Munki to install it as part of imaging the machine.  I also have a printer that I'm adding to the students manifest as optional.  I think (maybe I'm wrong) that in order to install the printer, the students with the old version of Forticlient will have to update Forticlient before they can install the printer.  This isn't always convenient.

That said, students shouldn't have to do anything unless Forticlient requires a logout or reboot (maybe it does), because you can make it an unattended_install and just have it upgrade in the background.

Also, does the printer actual require Forticlient?

P.S. Are these desktop computers or laptops? If they're desktops, one way to avoid bothering the user is to have Munki run once a day (at night or early morning) when school is not in session.

Alan Siu

Client Systems Analyst

St. Ignatius College Preparatory

--

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/c9d756c6-e79b-4098-89d4-6c020adec217%40googlegroups.com.

[Erik Gomez]

You are correct that if there are any pending installs during the time of an optional install, the user will have to install all of them. This is a design decision but it helps encourage users to stay updated (carrot approach). 

Can the fortinet install be done unattended? If so, it will install during the next munki auto run. 

Sent from my iPhone

--

[Yehuda Alexandroff]

Laptops and Forticlient needs a restart.

[David Ross]

On 1/26/16 10:41 AM, Nick McSpadden wrote:
> If you want to turn off students getting MSC popping up, you can use
> SuppressUserNotification in the preferences plist:
> https://github.com/munki/munki/wiki/Preferences#suppressusernotification
>

Is there a way to do this in a manifest or am I missing something obvious?

David

[Mr. Alan Siu]

I'm not sure if this is the best way to do it, but you can create a .nopkg that runs the command

defaults write /Library/Preferences/ManagedInstalls SuppressUserNotification -bool TRUE

and make that a managed install in the manifest. 

Alan Siu

Client Systems Analyst

St. Ignatius College Preparatory

David

--
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/56AA85EB.9020907%40davidrossconsultant.com.

[Gregory Neagle]

While I understand the appeal of nopkg items, I think most of the time a psuedo-payload-free package is a better approach. You can use it in contexts other than Munki, and it leaves a receipt, which can remove the need to write an installcheck_script or have your  script create a fake receipt you can check with an installs array.

https://managingosx.wordpress.com/2015/05/20/pseudo-payload-free-pkgs-with-pkgbuild/

https://github.com/munki/munki-pkg#payload-free-packages

Receipts also let you do versioning — if you improve your script you can build a new package with a higher version, making it easy to install the fix with Munki.

-Greg

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

[Mr. Alan Siu]

That's pretty cool. I think I read that last year before I could understand it, but it makes sense to me now. Thanks for the reminder.

Alan Siu

Client Systems Analyst

St. Ignatius College Preparatory

To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/034C34D1-B371-447E-8F3E-D11F0AB28F29%40mac.com.

[David Ross]

I was thinking of the ability for some manifest/packages to not notify
and others do. For the people I work with they'd rather it just happen
"magically" for most things. So either when an item is not blocked or
when they are logged out.

David

[Mr. Alan Siu]

What you're looking for, then, is unattended_install, which is a key for each package on the Munki server and has nothing to do with client configuration.

More info here:

https://github.com/munki/munki/wiki/Supported-Pkginfo-Keys

Alan Siu

Client Systems Analyst

St. Ignatius College Preparatory

--
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/56AAFCEB.70904%40davidrossconsultant.com.

[Gregory Neagle]

And here: https://github.com/munki/munki/wiki/Pkginfo-Files#unattended-installs-and-uninstalls

-Greg

To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/CANWfAiO%2Bpfs5Zg4aCSmGtEVzLu1ivwjF2xLG-vw9kgSXRB1h8Q%40mail.gmail.com.