Munki + Mountain Lion 10.8 DP3 + preflight ManagedInstalls.plist changes == broken

494 views
Skip to first unread message

Justin McWilliams

unread,
May 1, 2012, 3:01:12 PM5/1/12
to munk...@googlegroups.com
I've filed a Radar Bug with Apple about this, but I figured it'd be
worth bringing up again on this list in case anyone has ideas. If
anyone has experience in the area of CFPreferencesCopyAppValue and/or
CFPreferencesAppSynchronize some confirmation of this problem would be
appreciated. FWIW, everything seems to work fine on 10.8 DP2.

The problem we see in Simian is that the preflight script performs
auth and stores a cookie in AdditionalHttpHeaders in the "private"
plist, which then isn't correctly loaded by Munki so auth fails on
subsequent HTTP requests (everything after preflight).
CFPreferencesAppSynchronize doesn't seem to reload the prefs. I'm not
sure how we could even effectively work around this problem since
CFPreference* methods take MCX into consideration as well, so it's not
as easy as reading the public/private plists using plistlib or
something...



BACKGROUND:

Munki uses CFPreferencesCopyAppValue to read sysadmin-configured
preferences. To my knowledge, this function should look first in MCX,
then in /Library/Preferences/BUNDLE_ID.plist, and finally in
/private/var/root/Library/Preferences/BUNDLE_ID.plist (where
BUNDLE_ID is the name you pass to CFPreferencesCopyAppValue). This
has been working well for almost 2 years, on Leopard, Snow Leopard,
Lion, and early developer previews of Mountain Lion. I'm also under
the impression that CFPreferencesAppSynchronize(BUNDLE_ID) can be
called to reload or refresh preferences that may have been changed on
disk directly.

PROBLEM EXPERIENCED:

However, starting with Mountain Lion 10.8 Developer Preview 3, the
CFPreferences* methods seem unreliable. I can make changes to my
"private" preferences plist file, and CFPreferencesCopyAppValue does
not immediately see these changes. CFPreferencesAppSynchronize also
does not seem to refresh them. Subsequent calls to CFPreferences*
methods yield no new data, even in separate processes. Arbitrarily, a
minute or two later, the new values I've written to the private plist
are seen just fine by CFPreferencesCopyAppValue. This leads me to
believe there's some sort of caching problem.

STEPS TO REPRODUCE:

- write the public and private plist to disk.
- verify they exist with ls
- using a text editor, write a new value, Foo=Bar, to the private plist
- call "CFPreferencesCopyAppValue" with the "ManagedInstalls" bundle
ID, attempting to read "Foo".
- notice the value is not returned
- call CFPreferencesAppSynchronize with the "ManagedInstalls" bundle
ID, ensuring the latest preferences are synced.
- notice CFPreferencesCopyAppValue still does not return the value of Foo.

FURTHER TROUBLESHOOTING:

Furthermore, possibly related, if I delete the plist, "defaults read
<private plist>" will still output contents for some period of time!
Then when I recreate a new plist, "defaults read <private plist>"
immediately starts failing with "Domain /path/to/plist does not
exist". ls and cat confirm it's there, but defaults still sees
nothing. Then wait some period of time (1 min?) and defaults reads it
just fine.

On Fri, Apr 27, 2012 at 9:29 AM, Greg Neagle <gregn...@mac.com> wrote:
> Probably worth filing a bug with Apple as well, but most likely we'll have to work around the issue in a future release.
>
> -Greg
>
> On Apr 27, 2012, at 6:18 AM, Justin McWilliams wrote:
>
>> On Fri, Apr 27, 2012 at 9:09 AM, Greg Neagle <gregn...@mac.com> wrote:
>>> Is it an issue new to the 0.8.2 series of releases, or one that's probably been there all along?
>>>
>>> IOW, is this an issue introduced by changes made since 0.8.1 was released?
>>
>> Dating back to Dec 2010, when munkicommon.reload_prefs() was added.
>> On ML CFPreferencesAppSynchronize doesn't function predictably.  I'm
>> hoping to find more time today to debug it further, but it's either
>> overwriting changes in the private plist or simply not reloading it.
>>
>> So yea, 0.8.1 has the same bug, which means moving forward with 0.8.2
>> is fine with me.  We'll just have to make sure to cut a fixed 0.8.3
>> before ML retails.
>>
>>> Sent from my iPhone
>>>
>>> On Apr 27, 2012, at 5:58 AM, Justin McWilliams <og...@google.com> wrote:
>>>
>>>> We found an issue with Mountain Lion compatibility in this version
>>>> (related to reloading the secure plist), but I don't think that's
>>>> worth holding up a release since it's not due out for .... 2+ months?
>>>> I'll start a new thread about that.

Greg Neagle

unread,
May 1, 2012, 3:05:58 PM5/1/12
to munk...@googlegroups.com
If Apple ends up saying "works as designed" or does not recognize this as a bug, the only workaround that occurs to me is to special case 10.8, not use the CFPreferences* methods, but rather read the files directly, and declare that MCX support is not available under 10.8.

-Greg

Justin McWilliams

unread,
May 1, 2012, 3:09:27 PM5/1/12
to munk...@googlegroups.com
On Tue, May 1, 2012 at 3:05 PM, Greg Neagle <gregn...@mac.com> wrote:
> If Apple ends up saying "works as designed" or does not recognize this as a bug, the only workaround that occurs to me is to special case 10.8, not use the CFPreferences* methods, but rather read the files directly, and declare that MCX support is not available under 10.8.

So, we cannot manually read MCX settings using a different API or
something? I must admit, I have near zero experience with MCX in
general let alone programmatic interaction with it...

Greg Neagle

unread,
May 1, 2012, 3:12:31 PM5/1/12
to munk...@googlegroups.com

Justin McWilliams

unread,
Jun 18, 2012, 11:23:41 AM6/18/12
to munk...@googlegroups.com
The response we received from Apple was basically that we should not
rely on the files on disk at all. Always use CFPreferences* API
calls, or "defaults" CLI. We ported Simian preflight/postflight over
to using CF and we'll be releasing a new build soon.

On Mon, Jun 18, 2012 at 10:05 AM, Michael Domino
<m1cha3...@gmail.com> wrote:
> I'm also seeing exactly this problem with my app, only on Mountain Lion,
> it's perfectly stable wrt CFPreferences api usage on 10.5 - 10.7.

Rob Middleton

unread,
Jun 18, 2012, 5:37:55 PM6/18/12
to munk...@googlegroups.com
For munki we could always move (or have an additional) preflight from managedsoftwareupdate to supervisor.

Thus preference values could be set before the main process is spawned.

Justin McWilliams

unread,
Jun 18, 2012, 5:52:18 PM6/18/12
to munk...@googlegroups.com
On Mon, Jun 18, 2012 at 5:37 PM, Rob Middleton <rrmid...@gmail.com> wrote:
> For munki we could always move (or have an additional) preflight from managedsoftwareupdate to supervisor.
>
> Thus preference values could be set before the main process is spawned.

That wouldn't help. In 10.8 preferences are all cached by a
preference daemon, and the point at which it reads from/writes to disk
is not reliable, and not tied to the process that execution
time/lifespan/etc.

Nate W

unread,
Jun 21, 2012, 3:07:04 PM6/21/12
to munk...@googlegroups.com
I started another pass of ML DP4 testing in lieu of the coming release.  I've noticed this behavior in the following situation:

1.  Apply Base Image, bind to AD/OD
2.  OD Preferences get refreshed on Firstboot (DeployStudio firstboot script)
3.  On boot, the preferences are *physically* present, but Munki cannot read them (It throws an error saying that the default SoftwareRepoURL "nodename nor servname provided, or not known"
4.  Upon reboot, the settings are still not read by Munki. 

Nate

Greg Neagle

unread,
Jun 21, 2012, 5:40:34 PM6/21/12
to munk...@googlegroups.com
On Jun 21, 2012, at 12:07 PM, Nate W wrote:

3.  On boot, the preferences are *physically* present,

What does this mean?
How are you verifying that the expected values are being set by MCX?

but Munki cannot read them (It throws an error saying that the default SoftwareRepoURL "nodename nor servname provided, or not known"
4.  Upon reboot, the settings are still not read by Munki. 

> python
>>> import CoreFoundation
>>> print CoreFoundation.CFPreferencesCopyAppValue("SoftwareRepoURL", "ManagedInstalls")
>>> print CoreFoundation.CFPreferencesAppValueIsForced("SoftwareRepoURL", "ManagedInstalls")




Nate Walck

unread,
Jun 21, 2012, 6:22:08 PM6/21/12
to munk...@googlegroups.com
In regards to #3, I do defaults read /Library/Managed Preferences/ManagedInstalls and note that everything I've set with MCX is present as expected. 

It would be more accurate to say Munki seems to be only using /Library/Preferences/ManagedInstalls.plist and trying to connect to the default http://Munki/repo instead of the repo i have set in MCX which I confirmed is there as stated above.  The behavior is different from Lion in that it works as expected on 10.7 but not 10.8. 

Nate

Sent from my iPad

Greg Neagle

unread,
Jun 21, 2012, 6:24:04 PM6/21/12
to munk...@googlegroups.com
What about the output from the Python commands?

Sent from my iPhone

Nate Walck

unread,
Jun 21, 2012, 6:25:22 PM6/21/12
to munk...@googlegroups.com
I will give those a try tomorrow and get back to you. 

Nate

Sent from my iPad

Justin McWilliams

unread,
Jun 22, 2012, 12:33:19 PM6/22/12
to munk...@googlegroups.com
http://code.google.com/p/munki/source/detail?r=12b3957a532495dd16c80dc18d1781a659ee538c

I've submitted a change we've been using for a few weeks now on 10.6,
10.7 and 10.8. If your preflight/postflight scripts are in Pyhon then
this may help you.

- Justin

Nate

unread,
Jun 25, 2012, 7:58:14 AM6/25/12
to munk...@googlegroups.com
Output from the python commands for reading preferences via CFPreferences:

print CoreFoundation.CFPreferencesCopyAppValue("SoftwareRepoURL", "ManagedInstalls")

print CoreFoundation.CFPreferencesAppValueIsForced("SoftwareRepoURL", "ManagedInstalls")
False

More info:

.GlobalPreferences.plist com.apple.loginwindow.plist ssh.plist
ManagedInstalls.plist com.apple.screensaver.plist
com.apple.MCX.plist nawalck
sh-3.2# pwd
/Library/Managed Preferences

sh-3.2# defaults read /Library/Managed\ Preferences/ManagedInstalls SoftwareRepoURL


So the preference has been placed there by MCX and contains the managed value, but it appears that CFPreferences is not reading it correctly?

Nate

Jim Zajkowski

unread,
Jun 25, 2012, 10:10:12 AM6/25/12
to munk...@googlegroups.com
Somewhere (and I can't remember where) MCX was listed as deprecated for MoLo.

--Jim

Greg Neagle

unread,
Jun 25, 2012, 11:23:37 AM6/25/12
to munk...@googlegroups.com
It may or may not be deprecated, but MCX is still _implemented_ in Mountain Lion.

-Greg

Greg Neagle

unread,
Jun 25, 2012, 11:35:55 AM6/25/12
to munk...@googlegroups.com

On Jun 25, 2012, at 4:58 AM, Nate wrote:

Output from the python commands for reading preferences via CFPreferences:

print CoreFoundation.CFPreferencesCopyAppValue("SoftwareRepoURL", "ManagedInstalls")

print CoreFoundation.CFPreferencesAppValueIsForced("SoftwareRepoURL", "ManagedInstalls")
False

This means that the value is _not_ coming from MCX.

I can replicate your results with Local MCX on 10.8. mcxquery shows this:

ManagedInstalls
    SoftwareRepoURL                                munki (Computer Group)                always  http://munki.foo.com/repo

Yet:

# python
>>> import CoreFoundation
>>> print CoreFoundation.CFPreferencesCopyAppValue("SoftwareRepoURL", "ManagedInstalls")
>>> print CoreFoundation.CFPreferencesAppValueIsForced("SoftwareRepoURL", "ManagedInstalls")
False

I tried converting the MCX to a profile and applying it at the computer level as a profile. The managed settings show up in the output of system_profiler, but still don't seem to apply.

-Greg

Nate

unread,
Jun 25, 2012, 12:05:13 PM6/25/12
to munk...@googlegroups.com
I ran mcxquery and it showed that the settings were applied via MCX.  Doing -computerOnly showed that ManagedInstalls was indeed set with the expected settings.

So it looks like the breakdown here is that CFPreferences changed in 10.8.  It is no longer reading the MCX-applied settings.  Awesome!  I hope the updated documentation shows this change.

Nate

Greg Neagle

unread,
Jun 25, 2012, 12:14:49 PM6/25/12
to munk...@googlegroups.com
On Jun 25, 2012, at 9:05 AM, Nate wrote:

So it looks like the breakdown here is that CFPreferences changed in 10.8.  It is no longer reading the MCX-applied settings. 

I think that is too broad a conclusion with the evidence at hand.

It looks more to me that preferences in /Library/Preferences are being handled differently in ML with regards to MCX.

Still investigating.

-Greg

Greg Neagle

unread,
Jun 25, 2012, 1:04:57 PM6/25/12
to munk...@googlegroups.com
This all behaves as expected for user-level preferences:

(Working as a local user and not root)
# python
>>> import CoreFoundation
>>> print CoreFoundation.CFPreferencesCopyAppValue("askForPassword", "com.apple.screensaver")
1
>>> print CoreFoundation.CFPreferencesAppValueIsForced("askForPassword", "com.apple.screensaver")
True

Then, still working as a local user, I checked the ManagedInstalls preferences:

>>> print CoreFoundation.CFPreferencesCopyAppValue("SoftwareRepoURL", "ManagedInstalls")
>>> print CoreFoundation.CFPreferencesAppValueIsForced("SoftwareRepoURL", "ManagedInstalls")
True

So it appears that CFPreferences behaves differently for _root_ in ML.
The net effect, though, is that this method will not be useful with Munki in Mountain Lion. Unless a workaround is found, using MCX or profiles to manage Munki preferences in Mountain Lion will not be useful.

I don't plan to spend much time on this issue, as I don't need and don't use this feature -- I'll leave it to others.

-Greg

Nate

unread,
Jun 25, 2012, 1:12:29 PM6/25/12
to munk...@googlegroups.com
So the specific case for this is that you cannot use MCX or Profiles to manage Munki preferences in 10.8.  Is that correct?  Or am I missing something else here?  Since Munki runs as root, you can't depend upon the MCX settings to be read.

That about sum it up?

Nate

Greg Neagle

unread,
Jun 25, 2012, 1:17:25 PM6/25/12
to munk...@googlegroups.com
On Jun 25, 2012, at 10:12 AM, Nate wrote:

So the specific case for this is that you cannot use MCX or Profiles to manage Munki preferences in 10.8.  

Or more generically, it looks like you can't use MCX or profiles to manage _root_'s preferences.

Is that correct?  Or am I missing something else here?  Since Munki runs as root, you can't depend upon the MCX settings to be read.

That about sum it up?

I think so. This explains why there is a new management mechanism for the loginwindow; MCX management of loginwindow options would also be affected by this issue, and a quick test on a ML test box seems to confirm this.

Profile management of the loginwindow (using a profile generated by Profile Manager) uses a different mechanism.

-Greg

Greg Neagle

unread,
Jun 25, 2012, 2:43:22 PM6/25/12
to munk...@googlegroups.com
On Jun 25, 2012, at 10:17 AM, Greg Neagle wrote:

On Jun 25, 2012, at 10:12 AM, Nate wrote:

So the specific case for this is that you cannot use MCX or Profiles to manage Munki preferences in 10.8.  

Or more generically, it looks like you can't use MCX or profiles to manage _root_'s preferences.

This is almost certainly due to the transition to /usr/sbin/cfprefsd, which is new for Mountain Lion.

-Greg
Reply all
Reply to author
Forward
0 new messages