570843 - Turn off Bluetooth Setup Assistant automatically (with puppet?) for new mac images (build/talos)

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P5)

Description

[Lukas Blakk [:lsblakk] use ?needinfo]

BluetoothAutoSeekHIDDevices needs to be set as false in com.apple.Bluetooth.plist as it now comes set to true in the images made from the ref image.  This is possibly due to an upgrade in the imaging software IT is using.  Even though the ref image has this setting unchecked (System Preferences -> Bluetooth -> Advanced -> "Open Setup Assistant...") the images made from it end up having it checked which we don't want because on every reboot there will be focus taken from testing.

Comment 1

[Nick Thomas [:nthomas] (UTC+12)]

Could we just turn Bluetooth off in the ref image ? Hit this with bug 580800 today.

Comment 2

[Justin Dow [:jabba]]

We cannot turn it off in the reference image. Or rather, we can, but for some reason upon imaging a machine it all gets turned back on. I've been trying to turn it off manually on every machine that gets imaged, but perhaps some are getting missed? So it needs to be a post-image step or automated by puppet.

Comment 3

[Nick Thomas [:nthomas] (UTC+12)]

Ah, I didn't realize the imaging software was enabling Bluetooth, rather than just resetting the Assistant pref.

Comment 4

[Justin Dow [:jabba]]

At least I'm pretty sure that is what is happenening. When I'm back in the office next week, I'll be glad to give it a test again, since I don't remember for sure whether I tested the last time with bluetooth being completely off, or just disabling that assistant pref, so ping me next week and I'll see if I can round up a mini to test the theory on.

Also, if Bluetooth is completely off, does that need to be turned off on all minis/platforms for consistency?

Comment 5

[Nick Thomas [:nthomas] (UTC+12)]

Yeah probably. I bet we could do that with puppet!

Comment 6

[Armen [:armenzg]]

I have been poking at the ref machine and here are my investigations.

This is the most likely file:
/Library/Preferences/com.apple.Bluetooth.plist

There are few files that I have at sight too:
~/Library/Preferences/com.apple.PreferenceSync.plist

And very unlikely:
~/Library/Preferences/ByHost/com.apple.Bluetooth.blahblahblah.plist

I am not taking on this just putting this info up in case I or someone else
takes itl.

Comment 8

[Dustin J. Mitchell [:dustin] (he/him)]

I'll give this a shot.

Comment 9

[Dustin J. Mitchell [:dustin] (he/him)]

Blocking this on bug 608001, which will give me a cleanly imaged (and thus presumably broken) machine to compare with known-good machines.  Hopefully I can confirm Armen's observations and come up with a fix, and then learn how to get that set up in puppet.

Blocking bug 607780 because I want to get moz2-darwin9-slave08's bluetooth fixed with puppet before it goes back into (staging) service.

Comment 10

[Dustin J. Mitchell [:dustin] (he/him)]

Here's a fix:
  http://managingosx.wordpress.com/2006/02/10/managing-bluetooth-or-pesky-apple-preferences/

# turn off the Bluetooth KB/mouse dialog that comes up if no KB/mouse is found
`/usr/bin/defaults write /var/root/Library/Preferences/blued BluetoothAutoSeekHIDDevices -int 0`;

# restart the Bluetooth daemon
`/usr/bin/killall -HUP blued`;

Comment 11

[Dustin J. Mitchell [:dustin] (he/him)]

Huh, the newly-imaged machine has Bluetooth disabled (determined via the GUI), and also has BluetoothAuthoSeekHIDDevices set to 0:

moz2-darwin9-slave08:~ cltbld$ defaults read /Library/Preferences/com.apple.Bluetooth BluetoothAutoSeekHIDDevices
0

This comes from the puppet configs -- so someone already fixed this.

Justin suggests above that he's disabling bluetooth when re-imaging, so presumably Phong did so.

As an experiment, I re-enabled bluetooth, and uses 'defaults write' to set BluetoothAutoSeekHIDDevices to 1, then restarted.  Sure enough, a nice animated popup that's clearly eating some CPU cycles.  At this point I assumed there was a race condition: blued consulted the default before puppet could reset it.  Not so!

Now, the part that's over my head.  From staging-puppet:

dd72e2baa54236c9ef70052dbbd4d47d  /N/staging/darwin9-i386/test/Library/Preferences/com.apple.Bluetooth.plist

but after a puppet run on the slave, which seems to finish successfully:

moz2-darwin9-slave08:~ root# puppetd --test --server=staging-puppet.build.mozilla.org
info: Caching catalog at /var/puppet/state/localconfig.yaml
notice: Starting catalog run
notice: //Node[build]/base/osx/Exec[check-for-macports]/returns: executed successfully
notice: Finished catalog run in 2.56 seconds

moz2-darwin9-slave08:~ cltbld$ md5 /Library/Preferences/com.apple.Bluetooth.plist 
MD5 (/Library/Preferences/com.apple.Bluetooth.plist) = 6bd9f4f436c912bbf0c73c3200bd7aa1
moz2-darwin9-slave08:~ cltbld$ defaults read /Library/Preferences/com.apple.Bluetooth BluetoothAutoSeekHIDDevices
1

so the preference is still incorrect.  What part of the puppet config am I missing here?

Comment 12

[Armen [:armenzg]]

I think it is using the cache rather than actually updating.

You probably want to:
rm -rf /etc/puppet/ssl
and try sync and sign the new certificates with the master.

Comment 13

[Dustin J. Mitchell [:dustin] (he/him)]

(In reply to comment #12)
> I think it is using the cache rather than actually updating.

That makes sense

> You probably want to:
> rm -rf /etc/puppet/ssl
> and try sync and sign the new certificates with the master.

But this (along with a puppetca --clean on staging-puppet) was probably *not* the correct solution.  The slave just got a new certificate when it was re-imaged.  Anyway, doing the above gives me

moz2-darwin9-slave08:~ root# puppetd --test --server=staging-puppet.build.mozilla.org
warning: peer certificate won't be verified in this SSL session
notice: Did not receive certificate
notice: Set to run 'one time'; exiting with no certificate

I should probably read some puppet documentation..

Comment 14

[Dustin J. Mitchell [:dustin] (he/him)]

OK, the file is present on the staging masters, but is not in the puppet manifests.  So I need to figure out how to add them to the manifests.  Progress!

Comment 15

[Dustin J. Mitchell [:dustin] (he/him)]

Attachment: com.apple.Bluetooth.plist

[root@staging-puppet manifests]# find /N/staging/ -name '*Blue*.plist'
/N/staging/darwin9-i386/test/Library/Preferences/com.apple.Bluetooth.plist
/N/staging/darwin9-i386/build/Library/Preferences/com.apple.Bluetooth.plist

(not needed for darwin10)

Comment 16

[Dustin J. Mitchell [:dustin] (he/him)]

Attachment: m570843-puppet-manifests-r1.patch

manifests to install this and disable bluetooth on darwin9 and darwin10.  Tested in staging.  The .plist may not be required, as just disabling the service makes the dialog disappear, but it doesn't seem to hurt anything.

Comment 17

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 495525 [details] [diff] [review]
m570843-puppet-manifests-r1.patch

Looks good, congrats on passing your puppet initiation :)

Comment 18

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 495524 [details]
com.apple.Bluetooth.plist

I don't think I need to approve this if it's plist file needed and you've tested it in staging.

Comment 19

[Dustin J. Mitchell [:dustin] (he/him)]

I'll land this in an hour or so, when bug 616003 is seen to have settled in nicely.

Comment 20

[Dustin J. Mitchell [:dustin] (he/him)]

Comment on attachment 495525 [details] [diff] [review]
m570843-puppet-manifests-r1.patch

landed in 376d2f2436c2.

Comment 21

[Lukas Blakk [:lsblakk] use ?needinfo]

So the scope of this has been extended since we need puppet to manage this for the leopard/snowleopard talos images too.

Comment 22

[Dustin J. Mitchell [:dustin] (he/him)]

The build changes are in production.  I'll have a new patch shortly for test (it's just a copy/paste)

Comment 23

[Dustin J. Mitchell [:dustin] (he/him)]

Attachment: m570843b-puppet-manifests-r1.patch

the com.apple.Bluetooth.plist file is already deployed for darwin9*/test, so this is the only change required

Comment 24

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 496569 [details] [diff] [review]
m570843b-puppet-manifests-r1.patch

*stamp* -- awesome, land at your earliest convenience.

Comment 25

[Dustin J. Mitchell [:dustin] (he/him)]

Comment on attachment 496569 [details] [diff] [review]
m570843b-puppet-manifests-r1.patch

landed in b23b1603d625

deployed to production.