force quit MSU to cancel forced installs

[scottlep]

We frequently use an install_by date to attempt to force users to do their pending updates. It seems that many of our users have figured out that they can can still get around doing a forced update by Force Quitting the Managed Software Update app. Besides doing updates as an unattended_install, can you think of any other way to keep users from bucking the system by using Force Quit and forcing them to do the pending updates?

Thanks,

Scott

[Gregory Neagle]

I'm not sure what exactly you mean.

When a forced install date approaches, a background process (running as root) notifies the user at decreasing intervals.

If the date passes, the background process (eventually) kills the loginwindow, which then allows Munki to run at the loginwindow as root to do the install. At this point, all the user can do is power down the machine. But at power up, the install should try again.

Force quitting MSU.app will not prevent installs from happening.

-Greg

[scottlep]

Somehow, some of our users seem to be able to keep bypassing the forced updates for an extended period of time when they are notified. I can see in my Munki Reports server when they are being notified. It seems like they are just force quitting when then get prompted that they will be forced to log out to do the update. Any ideas?

Thanks,

Scott

[Nick McSpadden]

Make the update unattended and/or suppress user notification - thus the updates will install silently without user interaction.  I've found that with very few exceptions, there's almost nothing I install that requires a user's attention.

Sent from my iPhone

[Justin McWilliams]

They could be killing the logouthelper process.  But they would have to do this hourly.  Collect logs and have at closer look.  Or ask one of them ;)

[Rob Middleton]

Are those computers:
- running a recent ver of Munki?
- were restarted after any Munki upgrade that changed launchd jobs?

- are you using the right key in pkg info, the paraphrase in your email won't work.
- any complicating factors such as fast user switching?
- are your users too smart to be managed ;)

The design is that only root can stop a "forced install after date" and only if they know what they are doing.

[Gregory Neagle]

Thanks for the report. I'm going to be away from the office for a few days, so will not have a chance to look into this until next week.

Does `sudo launchctl list` show a "com.googlecode.munki.logouthelper" job?

When the logouthelper is doing its job, you should see messages in the Munki log (normally at /Library/Managed Installs/Logs/ManagedSoftwareUpdate.log) similar to this:

com.googlecode.munki.logouthelper: Warning user of 5 minutes until forced logout

com.googlecode.munki.logouthelper: Forced logout in 60 seconds

com.googlecode.munki.logouthelper: Beginning forced logout

Do you see any "com.googlecode.munki.logouthelper" messages in the Munki log?

-Greg

On Jan 9, 2013, at 7:05 PM, Nick Rodriguez <somel...@gmail.com> wrote:

It appears that we are also having a similar issue.  We are now running munkitools-0.8.4.1693.0.  Currently any packages that have an overdue force_install_after_date set and require a logout, do not actually force the logout.  I have created a new overdue nopkg package to test.  MSU will pop up periodically to remind me to logout to have it install, but for the past two days I have been able to avoid the logout by clicking Later.

Nick

[Justin McWilliams]

Do packages set to force a reboot/restart actually force successfully?  Meaning, is this problem limited to packages which require _logout_ specifically?

On Wed, Jan 9, 2013 at 10:05 PM, Nick Rodriguez <somel...@gmail.com> wrote:

It appears that we are also having a similar issue.  We are now running munkitools-0.8.4.1693.0.  Currently any packages that have an overdue force_install_after_date set and require a logout, do not actually force the logout.  I have created a new overdue nopkg package to test.  MSU will pop up periodically to remind me to logout to have it install, but for the past two days I have been able to avoid the logout by clicking Later.

Nick

On Friday, December 21, 2012 11:43:13 AM UTC-8, scottlep wrote:

[Hugh Burt]

Hello Everyone

All of a sudden Munki on my machine I use for testing, fails to run.  I have uninstalled it and re-installed to no avail.

I am using version munkitools-0.8.3.1679.0 and the mac is running 10.8.2. The log shows :- 

Jan 10 2013 09:09:56 +0000 ### Starting managedsoftwareupdate run: manualcheck ###

Jan 10 2013 09:09:56 +0000 Starting...

Jan 10 2013 09:09:56 +0000 ### Beginning managed software check ###

Jan 10 2013 09:09:56 +0000 Checking for available updates...

Jan 10 2013 09:09:56 +0000     Getting manifest client_manifest...

Jan 10 2013 09:09:56 +0000     Using manifest: testing

Jan 10 2013 09:09:56 +0000     **Checking for installs**

Jan 10 2013 09:09:56 +0000 ERROR: Unexpected error in updatecheck:

Jan 10 2013 09:09:56 +0000 Traceback (most recent call last):

  File "/usr/local/munki/managedsoftwareupdate", line 648, in main

    updatecheckresult = updatecheck.check(client_id=options.id)

  File "/usr/local/munki/munkilib/updatecheck.py", line 2593, in check

    installinfo)

  File "/usr/local/munki/munkilib/updatecheck.py", line 1898, in processManifestForKey

    cataloglist = manifestdata.get('catalogs')

AttributeError: '__NSCFArray' object has no attribute 'get'

Anyone any ideas?   Thanks.

[Hannes Juutilainen]

This looks like a broken manifest. Do you have a manifest called "testing". What does that contain?

--

Hannes Juutilainen

[Hugh Burt]

It was indeed something wrong with the manifest.  The log had me thinking that there was something wrong with the Munki installation itself.

Thanks for the prompt reply.

 

-----------------------------------------------------------------------

“Weaseling out of things is important to learn. It’s what separates
us from the animals.....except the weasel” ~ Homer Simpson

---

From: Hannes Juutilainen <hjuuti...@mac.com>
To: munk...@googlegroups.com
Sent: Thursday, 10 January 2013, 9:28
Subject: Re: [munki-dev] Munki fails to update?

[Nick Rodriguez]

YPCMC11116:munki nrodriguez$ sudo launchctl list | grep munki

- 0 com.googlecode.munki.managedsoftwareupdate-manualcheck

- 0 com.googlecode.munki.managedsoftwareupdate-install

- 0 com.googlecode.munki.managedsoftwareupdate-check

- 1 com.googlecode.munki.logouthelper

I see no reference to com.googlecode.munki.logouthelper in the log.  Upon MSU notification, it generates the following:

Jan 10 2013 09:09:05 -0800     The following items will be installed or upgraded:

Jan 10 2013 09:09:05 -0800         + forceinstalltest-1.0

Jan 10 2013 09:09:05 -0800             testing

Jan 10 2013 09:09:05 -0800            *Logout required

Jan 10 2013 09:09:05 -0800 ###    End managed software check    ###

Jan 10 2013 09:09:05 -0800 ### Beginning unattended installer session ###

Jan 10 2013 09:09:05 -0800 Processing installs

Jan 10 2013 09:09:05 -0800     Skipping install of forceinstalltest because it's not unattended.

Jan 10 2013 09:09:05 -0800 ###    End unattended installer session    ###

Jan 10 2013 09:09:05 -0800 Finishing...

Jan 10 2013 09:09:05 -0800 Saving application inventory...

Jan 10 2013 09:09:05 -0800     Performing postflight tasks...

Jan 10 2013 09:09:06 -0800     postflight stdout: Postflight report submmitted for YPCMC11116.

Jan 10 2013 09:09:06 -0800 ### Ending managedsoftwareupdate run ###

Jan 10 2013 09:09:06 -0800 Notifying user of available updates.

Jan 10 2013 09:09:06 -0800 LastNotifiedDate was 2013-01-10 16:03:29 +0000

Nick

[Justin McWilliams]

On Thu, Jan 10, 2013 at 12:46 PM, Nick Rodriguez <somel...@gmail.com> wrote:

YPCMC11116:munki nrodriguez$ sudo launchctl list | grep munki

- 0 com.googlecode.munki.managedsoftwareupdate-manualcheck

- 0 com.googlecode.munki.managedsoftwareupdate-install

- 0 com.googlecode.munki.managedsoftwareupdate-check

- 1 com.googlecode.munki.logouthelper

There is no logouthelper code path which exits with 1, so this is likely a Python crash of some sort: https://code.google.com/p/munki/source/browse/code/client/logouthelper

Can you find a logouthelper traceback anywhere in system.log?

[Nick Rodriguez]

I see several instances of the following in my system.log

Jan 10 09:09:07 YPCMC11116 coreservicesd[25]: Application App:"Managed Software Update" [ 0x0/0x475475]  @ 0x0x7ff129312d30 tried to be brought forward, but isn't in fPermittedFrontASNs ( ( ASN:0x0-0x473473:, ASN:0x0-0x1001:) ), so denying.

Jan 10 09:09:07 YPCMC11116 WindowServer[87]: [cps/setfront] Failed setting the front application to Managed Software Update, psn 0x0-0x475475, securitySessionID=0x186a4, err=-13066

Jan 10 09:09:07 YPCMC11116 Managed Software Update[45538]: Managed Software Update finished launching.

Jan 10 09:09:07 YPCMC11116 Managed Software Update[45538]: MSU GUI version: 3.5.2.1690

Jan 10 09:09:07 YPCMC11116 coreservicesd[25]: Application App:"Managed Software Update" [ 0x0/0x475475]  @ 0x0x7ff129312d30 tried to be brought forward, but isn't in fPermittedFrontASNs ( ( ASN:0x0-0x473473:, ASN:0x0-0x1001:) ), so denying.

Jan 10 09:09:07 YPCMC11116 WindowServer[87]: [cps/setfront] Failed setting the front application to Managed Software Update, psn 0x0-0x475475, securitySessionID=0x186a4, err=-13066

Jan 10 09:09:08 YPCMC11116 com.apple.launchd[1] (com.googlecode.munki.logouthelper[45542]): Exited with code: 1

[Justin McWilliams]

Nothing else for PID 45542?

[Nick Rodriguez]

No, nothing else in the log.  However I'm also testing on a OS X 10.7 client and do see this:

Jan 10 12:26:14 YPCMC08527 com.googlecode.munki.logouthelper[1847]: Traceback (most recent call last):

Jan 10 12:26:14 YPCMC08527 com.googlecode.munki.logouthelper[1847]:   File "/usr/local/munki/logouthelper", line 29, in <module>

Jan 10 12:26:14 YPCMC08527 com.googlecode.munki.logouthelper[1847]:     from munkilib.updatecheck import discardTimeZoneFromDate

Jan 10 12:26:14 YPCMC08527 com.googlecode.munki.logouthelper[1847]: ImportError: cannot import name discardTimeZoneFromDate

Jan 10 12:26:14 YPCMC08527 com.apple.launchd[1] (com.googlecode.munki.logouthelper[1847]): Exited with code: 1

Jan 10 12:26:16 YPCMC08527 Managed Software Update[1845]: Managed Software Update finished launching.

Jan 10 12:26:16 YPCMC08527 Managed Software Update[1845]: MSU GUI version: 3.5.2.1690

[Justin McWilliams]

discardTimeZoneFromDate was renamed to subtractTimeZoneOffsetFromDate in this change:

https://code.google.com/p/munki/source/detail?r=cc67bb8ca134c2782b15fb1c32ca8fa811a74f3d&path=/code/client/munkilib/updatecheck.py

I'll update logouthelper now....

[Justin McWilliams]

Fix is submitted: https://code.google.com/p/munki/source/detail?r=5d901765a109395a1c2ea9fcf9174c55b361ea7c

Since this was broken on Dec 18th, 0.8.4.[1691-1693].0 all have this problem.  0.8.4.1694.0 should be free of this bug, so please test logouthelper with that build and let us know!

- Justin

[Nick Rodriguez]

I have confirmed that logouthelper is now functioning properly.  I am now being notified at the regular intervals of when the forced restart action will occur.

Thanks,

Nick

[scottlep]

Sorry for just getting back to this thread. Been crazy busy here. We are running v0.8.3.1634 of Munki which seems to have the logoouthelper issue. I see that current available version on the Munki Dev site is 0.8.3.1679. Where are you guys downloading 0.8.4.1694 that is mentioned above?

Thanks,

Scott

[Gregory Neagle]

http://munkibuilds.org/

Sent from my iPhone

[EG]

When, running sudo managedsoftwareupdate --installonly with packages that require a logout/restart, is the expected behavior to not attempt to logout the current user and/or restart?

[Gregory Neagle]

On Jan 28, 2013, at 2:04 PM, EG <eriknico...@gmail.com> wrote:

When, running sudo managedsoftwareupdate --installonly with packages that require a logout/restart, is the expected behavior to not attempt to logout the current user and/or restart?

Yes. You are running it manually. You are expected to do the right thing. This is similar to running /usr/sbin/softwareupdate -- Apple's utility will tell you a restart is needed, but it's up to you to do the right thing.

-Greg

--
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/groups/opt_out.