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.