MCX Bluetooth and Wifi controls are just really broken

[dayglojesus]

Affects: managedmac::mcx::bluetooth managedmac::mcx::wifi

This is a long standing bug in Apple's MCX implementation and we use MCX to control the state of these antennas. We should be able to fix this insofar as the Puppet module is concerned with some supplementary code.

[dayglojesus]

The current methodology for controlling these antennas is simply broken. MCX is not reliable and other means of controlling these will need to be employed.

[dayglojesus]

Controlling these antennas is pretty easy, but you know what sucks? State cannot be enforced without MCX and the MCX features for this are broken.

[loyaltyarm]

You can do this using execs, which I am working with at the moment:

https://gist.github.com/loyaltyarm/069c7fab1386c9d7f3fd

One issue I'm personally having using this though, is that my execs are not run in the order the are listed. I know this might be because Puppet wants you to use relationships to specify ordering, and those don't seem to be included in the execs class...reference: https://docs.puppetlabs.com/puppet/3.8/reference/lang_relationships.html

Any thoughts?

[dayglojesus]

My comment here...

Controlling these antennas is pretty easy, but you know what sucks? State cannot be enforced without MCX and the MCX features for this are broken.

... says it all.

Controlling the antennas is easy (using Execs or whatever). Enforcing policy is difficult. I don't think stringing together Puppet exec resources is the right solution, but you should be able to do this using the subscribe => Exec['whatever'] notation. It's a bit different passing this in YAML-ese but it looks like this...

managedmac::execs::commands:
  disable_bluetooth:
    command: /usr/bin/defaults write /Library/Preferences/com.apple.Bluetooth ControllerPowerState '0'
  unload_bluetooth_service:
    command: /bin/launchctl stop com.apple.blued
    subscribe: Exec[disable_bluetooth]