Force Install After Date Documentation

[Ricky Chilcott]

We've been working on implementing the force_install_after_date key in MunkiServer and everything is working great.  Dates are always a hard thing to work with, utc, local time, timezones... very frustrating.  The code appears to act as expected, but there is one line in the documentation that is a little confusing. http://code.google.com/p/munki/wiki/PkginfoFiles#Force_Install_After_Date

The line: The date specified here is evaluated in local time, so all timezone specific information is stripped and ignored, to us, should read: The date specified here is evaluated in utc time.  Does that seem more accurate?

For example: When the time in the pkginfo file is 2011-08-11T12:00:00Z, for me it shows August 8th, 2011 at 4 AM in the GUI, therefore the time in the pkginfo file should be UTC time, which will be converted to local time. I am in EST, therefore if I wanted to force an install at midnight, my time, I would write 2011-08-11T8:00:00Z.

Ricky Chilcott

[Rob Middleton]

The documentation matches the design intent. If it isn't working as designed that's a problem.

To suit companies with worldwide presence, a forced install date of 2011-08-12T12:00:00Z should do a forced install at midday (localtime) anywhere in the world. This will only be at midday UTC if your timezone is +0000. This ensures that local IT staff are on hand if the user requires assistance or advice.

Perhaps if you can explain what you are seeing in more detail the people who implemented it may chime in. Specifically - the relevant part of your pkginfo file & the extract from the ManagedInstall log file indicating what time the forced install notifications are being displayed in the GUI.

Rob.

[Greg Neagle]

MunkiServer may be doing something here to confuse matters.

With a plain vanilla web server as the munki repo, an item with a force_install_after_date of 2011-08-11T12:00:00Z will cause a forced logout (if needed) at noon local time on August 11, 2011. In other words, the implied time zone info is ignored -- all installs happen at the relative local time.

For an organization like Google with clients all around the globe, this is the only implementation that makes sense -- it would be too difficult to support if a forced install at noon in NYC took place at 5pm in London and 2am in Sydney. (I may have the times slightly off, but you get the idea).

If that's not what you are seeing, then the differing behavior is caused by something MunkiServer is doing.

-Greg

[Ricky Chilcott]

Ok... last night, I must have stayed up too late.  I see now that it does work as documented.  Thanks for the clarification.  Should be in our MunkiServer master branch soon.

Ricky

[John Randolph]

On Fri, Aug 12, 2011 at 1:45 PM, Ricky Chilcott <ri...@rickychilcott.com> wrote:

Ok... last night, I must have stayed up too late.  I see now that it does work as documented.  Thanks for the clarification.  Should be in our MunkiServer master branch soon.

Ricky

Sorry about the misleading format that looks like it's expressing zulu time. We decided it was simpler to put up with that, but use the standard <date> container type, then to define the value as a <string> and enforce a date/time format, sans timezone, that would be non-standard.

--
John Randolph -- Google New York -- Corp Platforms Eng

[Phil Monroe]

Hi everyone,

So I have been working with Ricky on implementing Force Install After
Date for Munkiserver and for some reason, this is not working as
documented for me. I have catalog being built correctly, but it still
seems to show the incorrect date in the GUI. It may be something with
my setup, so here is some stats for my computer, the catalog plist I
am using, the output of running managedsoftwareupdate --auto with a
munkicommon.verbose level manually set to 10 (on line 469 of
managedsoftwareupdate), and a screenshot of the Managed Software
Update GUI.

MacBookPro2,2
Mac OS X Lion 10.2
2.33 GHz Intel Core 2 Duo
Python 2.7.1
Munki 0.8.0 Build 1290

---------------------------
Catalog Plist Snippet
Full version ( https://gist.github.com/dc3adab96cc3035e8d5c )

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://
www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<array>
<dict>
<key>RestartAction</key>
<string>RequiredLogout</string>
<key>catalogs</key>
<array>
<string>1-Staging.plist</string>
</array>
<key>description</key>
<string>FireFix automatically updates Firefox to the latest nightly
version. No user intervention is required, everything is fully
automated.
Downloads Firefox nightly build from web server
Mounts the disk image
Creates a backup of the previous version on disk
Copies the new nightly build to its default location
Option to launch the new version of Firefox
Option to undo latest install and revert to last version
Option to show the change log for past week
Preserves the user's search plugin settings
Makes backups of bookmarks and cookie</string>
<key>display_name</key>
<string>Nightly</string>
<key>force_install_after_date</key>
<date>2011-08-14T10:00:00Z</date>
<key>installer_item_hash</key>

<string>b748bfce92badb610f80d38f91dda4cf2dec86d1e177b4fe75ee9a05471f2fa9</
string>
<key>installer_item_location</key>
<string>3-Nightly-8.0a1.dmg</string>
<key>installer_item_size</key>
<integer>37118</integer>
<key>installer_type</key>
<string>copy_from_dmg</string>
<key>installs</key>
<array>
<dict>
<key>CFBundleIdentifier</key>
<string>org.mozilla.nightly</string>
<key>CFBundleName</key>
<string>Nightly</string>
<key>CFBundleShortVersionString</key>
<string>8.0a1</string>
<key>minosversion</key>
<string>10.5</string>
<key>path</key>
<string>/Applications/Nightly.app</string>
<key>type</key>
<string>application</string>
</dict>
</array>
<key>items_to_copy</key>
<array>
<dict>
<key>destination_path</key>
<string>/Applications</string>
<key>source_item</key>
<string>Nightly.app</string>
</dict>
</array>
<key>minimum_os_version</key>
<string>10.4.0</string>
<key>name</key>
<string>Nightly</string>
<key>uninstall_method</key>
<string>remove_copied_items</string>
<key>uninstallable</key>
<true/>
<key>version</key>
<string>8.0a1</string>
</dict>
</array>
</plist>

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

"managedsoftwareupdate --auto" output

Performing preflight tasks...
Manifest base URL is: http://localhost:3000/
Manifest base URL is: http://localhost:3000/
Getting manifest client_manifest...
/Library/Managed Installs/manifests/client_manifest.plist already
exists and is up-to-date.
Using manifest: 00:17:f2:d7:c9:63.plist
**Checking for installs**
** Processing manifest client_manifest.plist for managed_installs
Catalog base URL is: http://localhost:3000/catalogs/
Getting catalog 1-Staging.plist...
/Library/Managed Installs/catalogs/1-Staging.plist already exists and
is up-to-date.
* Processing manifest item Nightly for install
Looking for detail for: Nightly, version latest...
Considering 1 items with name Nightly from catalog 1-Staging.plist
Considering item Nightly, version 8.0a1 with minimum os version
required 10.4.0
Our OS version is 10.7
Found Nightly, version 8.0a1 in catalog 1-Staging.plist
Looking for application Nightly with bundleid: org.mozilla.nightly,
version 8.0a1...
Getting info on currently installed applications...
Skipped app PrinterProxy with path /Users/phil/Library/Printers/
Brother HL-2170W series.app
Skipped app test with path /Users/phil/Library/Developer/Xcode/
DerivedData/test-evvajgqgkwvjcbdygllrgmwpbewt/Build/Products/Debug/
test.app
Skipped app Gorilla with path /Users/phil/Library/Developer/Xcode/
DerivedData/Gorilla-hctrpcmtdkllfwavhibrvyfntjbq/Build/Products/Debug/
Gorilla.app
Skipped app Gorilla with path /Users/phil/Development/gorilla-old/
Gorilla.app
Skipped app PrinterProxy with path /Users/phil/Library/Printers/
Lexmark 2500 Series.app
Did not find this application on the startup disk.
Need to install Nightly
Download base URL is: http://localhost:3000/pkgs/
Package name is: 3-Nightly-8.0a1.dmg
Download URL is: http://localhost:3000/pkgs/3-Nightly-8.0a1.dmg
Downloading to: /Library/Managed Installs/Cache/3-Nightly-8.0a1.dmg
Downloading 3-Nightly-8.0a1.dmg from 3-Nightly-8.0a1.dmg
/Library/Managed Installs/Cache/3-Nightly-8.0a1.dmg already exists and
is up-to-date.
**Checking for removals**
** Processing manifest client_manifest.plist for managed_uninstalls
Catalog base URL is: http://localhost:3000/catalogs/
**Checking for managed updates**
** Processing manifest client_manifest.plist for managed_updates
Catalog base URL is: http://localhost:3000/catalogs/
** Processing manifest client_manifest.plist for optional_installs
Catalog base URL is: http://localhost:3000/catalogs/
No change in InstallInfo.
The following items will be installed or upgraded:
+ Nightly-8.0a1
FireFix automatically updates Firefox to the latest nightly
version. No user intervention is required, everything is fully
automated.
Downloads Firefox nightly build from web server
Mounts the disk image
Creates a backup of the previous version on disk
Copies the new nightly build to its default location
Option to launch the new version of Firefox
Option to undo latest install and revert to last version
Option to show the change log for past week
Preserves the user's search plugin settings
Makes backups of bookmarks and cookie
Forced install for Nightly at 2011-08-14 10:00:00 +0000
Skipping install of Nightly because it's not unattended.
Forced install for Nightly at 2011-08-14 10:00:00 +0000
Performing postflight tasks...
postflight stderr: % Total % Received % Xferd Average Speed
Time Time Time Current
Dload Upload Total Spent
Left Speed

0 0 0 0 0 0 0 0 --:--:-- --:--:--
--:--:-- 0
0 22291 0 0 0 0 0 0 --:--:-- 0:00:01
--:--:-- 0
100 22291 0 0 100 22291 0 11107 0:00:02 0:00:02
--:--:-- 11128
100 65024 100 42733 100 22291 21103 11008 0:00:02 0:00:02
--:--:-- 21144

----------------------------------------
Screenshot of the Managed Software Update GUI
http://bit.ly/ovZkWh

Phil Monroe

> > is a little confusing. <http://code.google.com/p/munki/wiki/PkginfoFiles#Force_Install_After_...>
> >http://code.google.com/p/munki/wiki/PkginfoFiles#Force_Install_After_...
>
> > The line: *The date specified here is evaluated in local time, so all
> > timezone specific information is stripped and ignored*, to us, should
> > read: The date specified here is evaluated in *utc time*.  Does that seem

[Phil Monroe]

On Aug 11, 11:57 pm, Ricky Chilcott <ri...@rickychilcott.com> wrote:
> We've been working on implementing the force_install_after_date key in MunkiServer and everything is working great.  Dates are always a hard thing to work with, utc, local time, timezones... very frustrating.  The code appears to act as expected, but there is one line in the documentation that is a little confusing.http://code.google.com/p/munki/wiki/PkginfoFiles#Force_Install_After_...

[Greg Neagle]

Hey Phil -- the screenshot link has expired.

What are are contents of /Library/Managed installs/InstallInfo.plist?

-Greg

[Rob Middleton]

https://s3.amazonaws.com/monroemedia/Screen+Shot+2011-08-14+at+9.49.22+PM.png

[Phil Monroe]

/Library/Managed installs/InstallInfo.plist

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

<key>managed_installs</key>

<array>

<dict>

<key>RestartAction</key>

<string>RequiredLogout</string>

<key>description</key>

<string>FireFix automatically updates Firefox to the latest nightly version. No user intervention is required, everything is fully automated.

Downloads Firefox nightly build from web server

Mounts the disk image

Creates a backup of the previous version on disk

Copies the new nightly build to its default location

Option to launch the new version of Firefox

Option to undo latest install and revert to last version

Option to show the change log for past week

Preserves the user's search plugin settings

Makes backups of bookmarks and cookie</string>

<key>display_name</key>

<string>Nightly</string>

<key>force_install_after_date</key>

<date>2011-08-14T10:00:00Z</date>

<key>installed</key>

<false/>

<key>installed_size</key>

<integer>37118</integer>

<key>installer_item</key>

<key>name</key>

<string>Nightly</string>

<key>version_to_install</key>

<string>8.0a1</string>

</dict>

</array>

<key>managed_updates</key>

<array/>

<key>optional_installs</key>

<array/>

<key>processed_installs</key>

<array>

<string>Nightly</string>

</array>

<key>processed_uninstalls</key>

<array/>

<key>removals</key>

<array/>

</dict>

</plist>

[Greg Neagle]

I wonder if this is a Lion issue?  I saved your InstallInfo.plist to /Library/Managed Installs/InstallInfo.plist and immediately launched MSU.app and saw the expected time and date:

This machine is running 10.6.8, however.

[Ricky Chilcott]

It may be... I took this screenshot in 10.6.8 showing that with a plist showing the following:

<key>display_name</key>

<string>Aurora</string>

<key>force_install_after_date</key>

<date>2011-08-14T10:00:00Z</date>

My 10.6.8 client is working fine.

When I copy the ManagedInstalls.plist file to a Lion machine... it does what Phil's does.  Phil's image is from a fresh install, as is mine -- very few customizations have happened on mine, so I doubt it's something on our side. Anyone have a Lion box that has been using this successfully?

Ricky

On Aug 15, 2011, at 12:47 AM, Greg Neagle wrote:

I wonder if this is a Lion issue?  I saved your InstallInfo.plist to /Library/Managed Installs/InstallInfo.plist and immediately launched MSU.app and saw the expected time and date:

<PastedGraphic-1.png>

[Rob Middleton]

On 15/08/2011, at 2:47 PM, Greg Neagle wrote:

I wonder if this is a Lion issue?  I saved your InstallInfo.plist to /Library/Managed Installs/InstallInfo.plist and immediately launched MSU.app and saw the expected time and date:

Looks like a Lion difference. The convert NSDate to string in 10.6 returns time string in local timezone. In 10.7 that resultant string is in the +0000 zone.

This example however seems portable:

>>> d = NSDate.date()

>>> print d.descriptionWithCalendarFormat_timeZone_locale_('%z',None,None)

+1000

>>> 

as opposed to print str(d) which returns different strings on 10.6 vs 10.7.

Rob.

<PastedGraphic-1.png>

[Greg Neagle]

A fix is in r1292.

-Greg