Getting Munki To Install Updates without Users Getting Involved

896 views
Skip to first unread message

Eric Dannewitz

unread,
Jan 14, 2016, 3:28:31 PM1/14/16
to munki-discuss
We've been using munki for about 2 years now. Works great mostly. The big issue I have is trying to keep student laptops updated. When they are in the charging cart, they are in sleep mode, and when they are on, we don't particularly want the students having to deal with the dialog box to install updates.

Is there a way to have Munki install updates in the background and not involve or show the user anything other than maybe if they need to reboot due to an update?

Thanks!

Nick McSpadden

unread,
Jan 14, 2016, 3:34:35 PM1/14/16
to munki-...@googlegroups.com
Use unattended_installs on your items and turn on "SuppressUserNotifications" in the client preferences plist. All updates that can be installed silently (i.e. don't require reboot or logout, and with no active blocking applications) will be installed whenever Munki runs in the background.

--
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/c0ac970f-092f-4ac4-be95-6e2be9b1c1f7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



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

Mr. Alan Siu

unread,
Jan 14, 2016, 3:38:03 PM1/14/16
to munki-...@googlegroups.com
Yeah, I'd love to hear others' thoughts on this as well. I also have laptop carts that won't update when the lids are closed... and the lids are usually closed. They are also not hardwired, so any kind of wake-on-LAN solution wouldn't work (not to mention the added trouble of making sure people plug in the network cable anyway).

A sort-of workaround I've put in place is a custom package I call "A Munki More Frequent" that basically puts in a new LaunchDaemon that checks about three times every hour instead of once an hour to make sure at least the unattended installs go in. I have both the SuppressUserNotification and SuppressLoginwindowInstall flags so as not to interrupt the students while they're working.

But that still leaves me manually launching up Managed Software Center on all the laptops individually periodically to take care of the major logout/reboot updates.

I don't know if there really is a solution, but I'd love to hear it if there is...


Alan Siu
Client Systems Analyst
St. Ignatius College Preparatory

On Thu, Jan 14, 2016 at 12:23 PM, Eric Dannewitz <edann...@rdschool.org> wrote:

--

Eric Dannewitz

unread,
Jan 14, 2016, 3:55:11 PM1/14/16
to munki-discuss
So is this a setting I put in the /Library/Preferences/ManagedInstalls.plist ?

Thanks Nick!

Mr. Alan Siu

unread,
Jan 14, 2016, 4:00:11 PM1/14/16
to munki-...@googlegroups.com


Alan Siu
Client Systems Analyst
St. Ignatius College Preparatory

Eric Dannewitz

unread,
Jan 14, 2016, 4:05:25 PM1/14/16
to munki-discuss
So I have SuppressUserNotifications = 0 already on my ManagedInstalls.plist

Where is the unattended_installs? Is that in the manifests or catalogs?

Gregory Neagle

unread,
Jan 14, 2016, 4:07:02 PM1/14/16
to munki-...@googlegroups.com
On Jan 14, 2016, at 1:05 PM, Eric Dannewitz <edann...@rdschool.org> wrote:

So I have SuppressUserNotifications = 0 already on my ManagedInstalls.plist

Which means it’s off: IE, notifications will not be suppressed. Is that what you want?


Where is the unattended_installs? Is that in the manifests or catalogs?

Eric Dannewitz

unread,
Jan 14, 2016, 4:08:24 PM1/14/16
to munki-...@googlegroups.com
I want it to also install any updates it can……

Gregory Neagle

unread,
Jan 14, 2016, 4:09:58 PM1/14/16
to munki-...@googlegroups.com
On Jan 14, 2016, at 1:08 PM, Eric Dannewitz <edann...@rdschool.org> wrote:

I want it to also install any updates it can……



On Jan 14, 2016, at 1:06 PM, Gregory Neagle <gregn...@mac.com> wrote:


On Jan 14, 2016, at 1:05 PM, Eric Dannewitz <edann...@rdschool.org> wrote:

So I have SuppressUserNotifications = 0 already on my ManagedInstalls.plist

Which means it’s off: IE, notifications will not be suppressed. Is that what you want?



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

Erik Gomez

unread,
Jan 14, 2016, 6:05:38 PM1/14/16
to munki-...@googlegroups.com
You want it on though. 

0=Off
1=On

Sent from my iPhone
--
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.

Eric Dannewitz

unread,
Jan 14, 2016, 6:07:46 PM1/14/16
to munki-...@googlegroups.com
No, because then it is disruptive during class. Ideally, if it just installed updated or new software in the background that is what we want

Sent from my iSomething
--
Eric Dannewitz
Redwood Dayschool
You received this message because you are subscribed to a topic in the Google Groups "munki-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/munki-discuss/us3uKLI1BXc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to munki-discus...@googlegroups.com.

To post to this group, send email to munki-...@googlegroups.com.

Erik Gomez

unread,
Jan 14, 2016, 6:24:12 PM1/14/16
to munki-...@googlegroups.com
So you don't want to suppress user notifications?

One of us is confused and I think it's you. 

Sent from my iPhone

Mr. Alan Siu

unread,
Jan 14, 2016, 6:26:36 PM1/14/16
to munki-...@googlegroups.com
On the client machine, you want:

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

That means user notification will be suppressed (i.e., the user will not be bothered, either while logged in or at the login window).

On the Munki server, for as many applications and packages as you can, you want unattended_install to be true, which means it can be updated without bothering the user.


Alan Siu
Client Systems Analyst
St. Ignatius College Preparatory

Eric Dannewitz

unread,
Jan 14, 2016, 7:23:43 PM1/14/16
to munki-...@googlegroups.com
Oops, my bad, I was looking at a servers config. The student machines are set correctly


Sent from my iSomething
--
Eric Dannewitz
Redwood Dayschool

Eric Dannewitz

unread,
Jan 14, 2016, 7:24:06 PM1/14/16
to munki-...@googlegroups.com
Ok, I will do that. Thanks


Sent from my iSomething
--
Eric Dannewitz
Redwood Dayschool

Adam M. Anklewicz

unread,
Jan 15, 2016, 8:23:38 AM1/15/16
to munki-...@googlegroups.com
This discussion reminds me of a topic that came up some time ago. About running updates while the lids are closed and the laptops are sitting in a cart. I never implemented this, but there was a lot talk on MacEnterprise in February.

Mr. Alan Siu

unread,
Jan 15, 2016, 1:13:22 PM1/15/16
to munki-...@googlegroups.com
That's a good find. For those of us who are less-seasoned Mac admins, is there a NoSleep for dummies?

Munki-Overnight seems fairly straightforward, but I'm having trouble wrapping my head around how to install NoSleep:


Alan Siu
Client Systems Analyst
St. Ignatius College Preparatory

Gregory Neagle

unread,
Jan 15, 2016, 1:50:35 PM1/15/16
to munki-...@googlegroups.com
Since it’s a kernel extension it needs to be signed… so I’m guessing unless you are willing to turn off kernel protections on your fleet, you _aren’t_ going to be able to install it any longer.

Happy to to be proven wrong about this.

-Greg

Mr. Alan Siu

unread,
Jan 15, 2016, 1:55:49 PM1/15/16
to munki-...@googlegroups.com
Good to know. I haven't upgraded our entire fleet of computers up to El Capitan, but with SIP in place going forward, I have a feeling this sort of thing may just not be feasible. I'd love to hear otherwise...


Alan Siu
Client Systems Analyst
St. Ignatius College Preparatory

Gregory Neagle

unread,
Jan 15, 2016, 1:56:38 PM1/15/16
to munki-...@googlegroups.com
I made a poor assumption. It (https://github.com/integralpro/nosleep/releases/download/v1.4.0/NoSleep-1.4.0.dmg) does appear to be signed:

pkgutil --payload-files /Volumes/NoSleep\ Extension/NoSleep.pkg
 <snip>
./System
./System/Library
./System/Library/Extensions
./System/Library/Extensions/NoSleep.kext
./System/Library/Extensions/NoSleep.kext/Contents
./System/Library/Extensions/NoSleep.kext/Contents/Info.plist
./System/Library/Extensions/NoSleep.kext/Contents/MacOS
./System/Library/Extensions/NoSleep.kext/Contents/MacOS/NoSleep
./System/Library/Extensions/NoSleep.kext/Contents/_CodeSignature
./System/Library/Extensions/NoSleep.kext/Contents/_CodeSignature/CodeResources

…but will have to be repackaged to install the kext into /Library/Extensions/ in order for the installation to succeed on El Capitan.

Mr. Alan Siu

unread,
Jan 15, 2016, 2:01:48 PM1/15/16
to munki-...@googlegroups.com
Thanks! I'll do some testing on that.


Alan Siu
Client Systems Analyst
St. Ignatius College Preparatory

Mr. Alan Siu

unread,
Jan 15, 2016, 3:09:48 PM1/15/16
to munki-...@googlegroups.com
Interesting. I installed it to test on an El Capitan machine, and it installed to the /System/Library/Extensions directory just fine.

Apparently, according to this Ars Technica article, that's normal behavior, even with SIP on:
You can add things to /System/Library/Extensions, but you can’t change anything there, because /System/Library/Extensions/* is listed


Alan Siu
Client Systems Analyst
St. Ignatius College Preparatory

bryan...@gmail.com

unread,
Jan 20, 2016, 11:29:38 AM1/20/16
to munki-discuss
Our solution was to modify Munki itself.

On every restart, Munki will check and install any updates. This way teachers can have students simply restart laptops periodically to ensure all updates are installed.

We push dozens of packages, most of which are unattended, but some aren't. But we also have user notifications suppressed on student computers because we never want Munki popping up when a student is using the computer. Kindergartners wouldn't know what to do anyway :)

So the install-on-restart is the one sure way a teacher can be sure a student's computer is fully up-to-date.

We've been using this method for two years now with almost 14,000 Macs and it's worked great.

Bryan

Gregory Neagle

unread,
Jan 20, 2016, 11:32:39 AM1/20/16
to munki-...@googlegroups.com
It’s possible to implement this behavior without changing Munki itself.

Simply make sure “/Users/Shared/.com.googlecode.munki.checkandinstallatstartup” exists at startup. This could be created by a LaunchDaemon at startup. It would then, in turn, cause Munki to run at startup and check for and install any available updates.

-Greg

On Jan 20, 2016, at 8:29 AM, bryan...@gmail.com wrote:

Our solution was to modify Munki itself.

On every restart, Munki will check and install any updates. This way teachers can have students simply restart laptops periodically to ensure all updates are installed.

We push dozens of packages, most of which are unattended, but some aren't. But we also have user notifications suppressed on student computers because we never want Munki popping up when a student is using the computer. Kindergartners wouldn't know what to do anyway :)

So the install-on-restart is the one sure way a teacher can be sure a student's computer is fully up-to-date.

We've been using this method for two years now with almost 14,000 Macs and it's worked great.

Bryan



On Thursday, January 14, 2016 at 2:38:03 PM UTC-6, Mr. Alan Siu wrote:
Yeah, I'd love to hear others' thoughts on this as well. I also have laptop carts that won't update when the lids are closed... and the lids are usually closed. They are also not hardwired, so any kind of wake-on-LAN solution wouldn't work (not to mention the added trouble of making sure people plug in the network cable anyway).

A sort-of workaround I've put in place is a custom package I call "A Munki More Frequent" that basically puts in a new LaunchDaemon that checks about three times every hour instead of once an hour to make sure at least the unattended installs go in. I have both the SuppressUserNotificationand SuppressLoginwindowInstall flags so as not to interrupt the students while they're working.

But that still leaves me manually launching up Managed Software Center on all the laptops individually periodically to take care of the major logout/reboot updates.

I don't know if there really is a solution, but I'd love to hear it if there is...


Alan Siu
Client Systems Analyst
St. Ignatius College Preparatory

On Thu, Jan 14, 2016 at 12:23 PM, Eric Dannewitz <edann...@rdschool.org> wrote:
We've been using munki for about 2 years now. Works great mostly. The big issue I have is trying to keep student laptops updated. When they are in the charging cart, they are in sleep mode, and when they are on, we don't particularly want the students having to deal with the dialog box to install updates.

Is there a way to have Munki install updates in the background and not involve or show the user anything other than maybe if they need to reboot due to an update?

Thanks!

-- 
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/c0ac970f-092f-4ac4-be95-6e2be9b1c1f7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

bryan...@gmail.com

unread,
Jan 20, 2016, 12:44:27 PM1/20/16
to munki-discuss
Unfortunately I don't remember why that was working for us when I tried it two years ago. Maybe .. does that method present the status window showing the progress of downloads and installs? 

Regardless, I should revisit the issue and take another look - we've been operating off the old "if it's not broke, don't fix it" mentality, but if we can get the same result without changing munki that'd be much better :)

Bryan

Gregory Neagle

unread,
Jan 20, 2016, 12:45:48 PM1/20/16
to munki-...@googlegroups.com
On Jan 20, 2016, at 9:44 AM, bryan...@gmail.com wrote:

Unfortunately I don't remember why that was working for us when I tried it two years ago. Maybe .. does that method present the status window showing the progress of downloads and installs? 

It does, yes. It’s the same file that triggers the “Bootstrap” mode: https://github.com/munki/munki/wiki/Bootstrapping-With-Munki

Mr. Alan Siu

unread,
Jan 21, 2016, 2:28:21 PM1/21/16
to munki-...@googlegroups.com
Thanks, Adam, for sending me down the rabbit hole a bit. I wasn't able to get Munki Overnight to work, but NoSleep seems to be a good solution.

Eric, I work at a school as well and have laptop carts that are annoying to update. This is the work-in-progress solution I've got so far:

As I work out the kinks, I'll update that post or make a new one. Hope that helps, though.


Alan Siu
Client Systems Analyst
St. Ignatius College Preparatory

On Fri, Jan 15, 2016 at 5:22 AM, Adam M. Anklewicz <ad...@anklewicz.com> wrote:

Eric Dannewitz

unread,
Jan 21, 2016, 2:42:10 PM1/21/16
to munki-...@googlegroups.com
I do follow your blog there with my RSS reader, and have marked that. We haven’t tested it out yet with our laptop carts but are worried about the extra drain in power and also the heat that it might be generated by not having them go to sleep. Most of our laptops now have SSDs in them so hopefully heat won’t be an issue, but we haven’t discussed how to monitor the heat in a cart yet. Power draw we can manage as we have a meter that we can hook up to see what the draw is how they are (asleep) and with the no sleep thing applied.



Mr. Alan Siu

unread,
Jan 21, 2016, 2:44:21 PM1/21/16
to munki-...@googlegroups.com
Yeah, all of our laptops (even our old MacBook Pros) have SSDs in them. As I mentioned before, this is a work-in-progress, so checking heat build-up is going to be a big thing for me over the next couple of days.


Alan Siu
Client Systems Analyst
St. Ignatius College Preparatory

Eric Dannewitz

unread,
Jan 21, 2016, 2:45:31 PM1/21/16
to munki-...@googlegroups.com
Indeed. And also how much more power the cart uses as well.....

We just don't have anything to monitor heat so.....can't really test it yet.


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



--
Eric Dannewitz
Tech Mage
Redwood Day School

Erik Gomez

unread,
Jan 21, 2016, 7:33:51 PM1/21/16
to munki-...@googlegroups.com
I would be less concerned about heat and more concerned if students don't properly plug them in to charge. If the machine is low on power and attempts to update, you may find out the machine is no longer bootable. 

Sent from my iPad

Mr. Alan Siu

unread,
Jan 22, 2016, 11:08:32 AM1/22/16
to munki-...@googlegroups.com
In my experience, Munki's fairly smart about not running updates if the battery is low. I don't know what the threshold is, but I've definitely gotten a warning that I need to click through to continue if there's a logout/reboot update and are on low battery.


Alan Siu
Client Systems Analyst
St. Ignatius College Preparatory

Mike Solin

unread,
Jan 22, 2016, 11:30:09 AM1/22/16
to munki-...@googlegroups.com
Does running Munki via the CLI result in the same warning?  Some of the scripts for running Munki on laptops with the lid closed check for a certain battery percentage before continuing the installation.

We tried this over the summer, with limited success.  I’m trying to move away from laptop carts entirely, since they’re so difficult to manage.

Gregory Neagle

unread,
Jan 22, 2016, 11:42:34 AM1/22/16
to munki-...@googlegroups.com
On Jan 22, 2016, at 8:30 AM, Mike Solin <mi...@mikesolin.com> wrote:

Does running Munki via the CLI result in the same warning? 

No, as command-line managedsoftwareupdate runs are not interactive.

It might make sense to add warnings (and possibly make managedsoftwareupdate not do updates when the battery percentage drops below a certain threshold) but there would be an interesting UI/UX problem to solve: 

1) MSC.app warns the battery percentage is too low to continue safely.
2) User clicks “Install anyway” (or whatever the phrasing is)
3) managedsoftwareupdate decides the battery percentage is too low and skips the install

We’d need to craft a way for MSC.app to communicate to managedsoftwareupdate that, for that specific run, to ignore battery level.

It’s been 6-7 years of Munki use and the need has not yet come up to implement something like this...

Mr. Alan Siu

unread,
Jan 22, 2016, 11:48:36 AM1/22/16
to munki-...@googlegroups.com
I don't know the actual Python code that would do this, but I would imagine one way to implement this would the creation of an extra flag that MSC could invoke when calling managedsoftwareupdate... something like /usr/local/munki/managedsoftwareupdate --auto --batteryoverride


Alan Siu
Client Systems Analyst
St. Ignatius College Preparatory

Gregory Neagle

unread,
Jan 22, 2016, 11:51:40 AM1/22/16
to munki-...@googlegroups.com
That would be a _start_, but the actual implementation would be more complicated than that, since MSC.app is running as a user, and managedsoftwareupdate is running as root.

I’m not currently motivated to work on this, but of course would review a PR.

-Greg

pmsau...@sonic.net

unread,
Nov 8, 2016, 9:01:15 PM11/8/16
to munki-discuss


On Thursday, January 14, 2016 at 1:07:02 PM UTC-8, Gregory Neagle wrote:

On Jan 14, 2016, at 1:05 PM, Eric Dannewitz <edann...@rdschool.org> wrote:

So I have SuppressUserNotifications = 0 already on my ManagedInstalls.plist

Which means it’s off: IE, notifications will not be suppressed. Is that what you want?


Where is the unattended_installs? Is that in the manifests or catalogs?



On Thursday, January 14, 2016 at 1:00:11 PM UTC-8, Mr. Alan Siu wrote:


Alan Siu
Client Systems Analyst
St. Ignatius College Preparatory

On Thu, Jan 14, 2016 at 12:55 PM, Eric Dannewitz <edann...@rdschool.org> wrote:
So is this a setting I put in the /Library/Preferences/ManagedInstalls.plist ?

Thanks Nick!

On Thursday, January 14, 2016 at 12:34:35 PM UTC-8, Nick McSpadden wrote:
Use unattended_installs on your items and turn on "SuppressUserNotifications" in the client preferences plist. All updates that can be installed silently (i.e. don't require reboot or logout, and with no active blocking applications) will be installed whenever Munki runs in the background.

On Thu, Jan 14, 2016 at 12:23 PM, Eric Dannewitz <edann...@rdschool.org> wrote:
We've been using munki for about 2 years now. Works great mostly. The big issue I have is trying to keep student laptops updated. When they are in the charging cart, they are in sleep mode, and when they are on, we don't particularly want the students having to deal with the dialog box to install updates.

Is there a way to have Munki install updates in the background and not involve or show the user anything other than maybe if they need to reboot due to an update?

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

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



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

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

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

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

For more options, visit https://groups.google.com/d/optout.
Sorry to be bumping an old thread but I've inherited a Munki installation that I'm doing my best to get spun up on quickly. There are installs that I need to be able to push silently, but the unattended_installIs key is being ignored; optional installs show up in the Software area of MSC, managed installs show up in the Updates area, and nothing gets installed without the user taking action to make it happen.

Is there a config setting at the server end that could be causing this key to be ignored? I haven't been able to find it yet in the docs or FAQ's.

Philip Saunders
Rodan + Fields

Gregory Neagle

unread,
Nov 8, 2016, 9:07:37 PM11/8/16
to munki-...@googlegroups.com
Please share a pkginfo file showing your attempt to set unattended_install

It might be instructive to see the ManagedSoftwareUpdate.log. 

Sent from my iPhone

pmsau...@sonic.net

unread,
Nov 9, 2016, 12:17:26 PM11/9/16
to munki-discuss
Attached. Thanks very much! — P
EnableSSH.pkginfo
ManagedSoftwareUpdate.log

Mr. Alan Siu

unread,
Nov 9, 2016, 12:20:00 PM11/9/16
to munki-...@googlegroups.com
I'm not seeing EnableSSH anywhere in that .log file. All I'm seeing is it not being able to connect to the Munki server.

Nov 09 2016 05:07:12 -0800 WARNING: Client is configured to use the default repo, which is insecure. Client could be trivially compromised when off your organization's network. Consider using a non-default URL, and preferably an https:// URL.
Nov 09 2016 05:07:12 -0800 ERROR: managedsoftwareupdate: server check for http://munki/repo failed: [Errno 8] nodename nor servname provided, or not known



Alan Siu
Client Systems Analyst
St. Ignatius College Preparatory

To unsubscribe from this group and stop receiving emails from it, send an email to munki-discuss+unsubscribe@googlegroups.com.

To post to this group, send email to munki-...@googlegroups.com.

Gregory Neagle

unread,
Nov 9, 2016, 12:21:27 PM11/9/16
to munki-...@googlegroups.com
...and if it can't connect to the Munki server, not much else is going to happen.

-Greg

pmsau...@sonic.net

unread,
Nov 9, 2016, 12:22:39 PM11/9/16
to munki-discuss
And yet it is showing up in the Updates area of MSC when a Mac with ssh off invokes managedsoftwareupdate either by launching MSC or from the CL.

pmsau...@sonic.net

unread,
Nov 9, 2016, 12:26:41 PM11/9/16
to munki-discuss
...or did you mean the log from the *client* machine? The log attached above is from the server. — P

Gregory Neagle

unread,
Nov 9, 2016, 12:28:28 PM11/9/16
to munki-...@googlegroups.com
If you want to debug what's going when managedsoftwareupdate runs on a client you need the ManagedSoftwareUpdate.log from a client.

There is no useful managedsoftwareupdate process on the _server_: a Munki server is a simple Web server.

-Greg

Gregory Neagle

unread,
Nov 9, 2016, 12:32:07 PM11/9/16
to munki-...@googlegroups.com
On Nov 9, 2016, at 9:22 AM, pmsau...@sonic.net wrote:

And yet it is showing up in the Updates area of MSC when a Mac with ssh off invokes managedsoftwareupdate either by launching MSC or from the CL.

Yes, that will happen. "unattended_install" does not mean "never show this update to users". It means "install it if possible without notifying the user".

A manual run of MSC or managedsoftwareupdate _will_ display pending unattended_installs.

Background runs of managedsoftwareupdate will install unattended_installs.


"[Munki] will also display the update in Managed Software Update if the update is still available at the time Managed Software Update is invoked."

-Greg

pmsau...@sonic.net

unread,
Nov 9, 2016, 12:34:18 PM11/9/16
to munki-discuss
ManagedSoftwareUpdate 2.log

Mr. Alan Siu

unread,
Nov 9, 2016, 12:35:02 PM11/9/16
to munki-...@googlegroups.com
Yes, the client machine is the one that should be looking at the logs for.

If you are making your server a client as well of itself, make sure you give it an actual client identifier. Otherwise it's a security risk:


That is not a good setting to have on your server.


Alan Siu
Client Systems Analyst
St. Ignatius College Preparatory

To unsubscribe from this group and stop receiving emails from it, send an email to munki-discuss+unsubscribe@googlegroups.com.

To post to this group, send email to munki-...@googlegroups.com.

pmsau...@sonic.net

unread,
Nov 9, 2016, 12:35:27 PM11/9/16
to munki-discuss
So there's no way to QA this except to wait for the scheduled background run? — P

Mr. Alan Siu

unread,
Nov 9, 2016, 12:35:54 PM11/9/16
to munki-...@googlegroups.com
Looks good:

Nov 08 2016 17:43:30 -0800     Running installcheck_script for EnableSSH
Nov 08 2016 17:43:30 -0800     everything seems as it should be, no install needed
Nov 08 2016 17:43:30 -0800     EnableSSH version 0.1 (or newer) is already installed.


Alan Siu
Client Systems Analyst
St. Ignatius College Preparatory

To unsubscribe from this group and stop receiving emails from it, send an email to munki-discuss+unsubscribe@googlegroups.com.

To post to this group, send email to munki-...@googlegroups.com.

Mr. Alan Siu

unread,
Nov 9, 2016, 12:36:25 PM11/9/16
to munki-...@googlegroups.com
You can manually invoke a background run on the client by running

sudo /usr/local/munki/managedsoftwareupdate --auto


Alan Siu
Client Systems Analyst
St. Ignatius College Preparatory

To unsubscribe from this group and stop receiving emails from it, send an email to munki-discuss+unsubscribe@googlegroups.com.

To post to this group, send email to munki-...@googlegroups.com.

pmsau...@sonic.net

unread,
Nov 9, 2016, 1:27:17 PM11/9/16
to munki-discuss
 That was the magic bullet. I was doing it right but QA'ing it wrong. I owe you a beer. — P
Reply all
Reply to author
Forward
0 new messages