Remove requirement to use LaunchDaemon for triggered resets

[wegotoeleven]

Hey!

We have a use case whereby we don't use the LaunchDaemon to schedule the resets, because:

• the password reset is triggered by a Jamf Pro policy immediately followed by a recon; we collect the local admin password and validate it with an EA, so this needs to be up to date as soon as possible after the reset has occurred.
• we prefer to set the schedule using a policy frequency, and
• we then have the ability to flush the Jamf Pro logs and reset the password the next time the Mac checks in.

Using the LaunchDaemon interferes with this, so typically we've been repackaging your package to remove the LaunchDaemon, which removes notarisation and stuff on the package (which is bad).

Therefore, I'm proposing adding a check somewhere to determine whether or not the LaunchDaemon should be used. My initial thoughts are something like:

• Remove the LaunchDaemon from the package
• Add a condition in the postinstall that checks for a new key in the preferences file, something like: <key>UseLaunchDaemon</key> <false/>
• Create the LaunchDaemon from within the postinstall, if the UseLaunchDaemon key is set to true. If this value is set to false, then it's not created.

Obviously this is one of many ways to accomplish this, but the main aim here isn't to break anyone else's workflows with any changes that I'm suggesting. Appreciate thoughts and feedback!

[wegotoeleven]

I.e something like:

: '
-------------------------
| macOS LAPS Preinstall |
-------------------------
| Performs postinstall actions of loading
| the launchDaemon macOSLAPS uses to run scheduled
| runs and forces it to run
------------------------------------------------------------
| Created: Richard Purves - https://github.com/franton
| Last Update by: Joshua D. Miller - [email protected]
| Last Updated: April 26, 2022
------------------------------------------------------------
'

# Find config locations
if [ -e "/Library/Managed Preferences/edu.psu.macoslaps" ]; then
    PREFERENCE_FILE="/Library/Managed Preferences/edu.psu.macoslaps.plist"
elif [ -e "/Library/Preferences/edu.psu.macoslaps" ]; then
    PREFERENCE_FILE="/Library/Preferences/edu.psu.macoslaps.plist"
fi

# Check if we should install a LaunchDaemon. If the config doesn't exit, is empty or not false (i.e. -gt 0) then setup
# the LaunchDaemon (i.e. default behaviour)
USE_LAPS_DAEMON=$(/usr/bin/defaults read $PREFERENCE_FILE UseLaunchDaemon 2>/dev/null)
if [ -z $USE_LAPS_DAEMON ] || [ $USE_LAPS_DAEMON -gt 0 ]; then

    # Path to the LaunchDaemon
    LAPS_DAEMON="/Library/LaunchDaemons/edu.psu.macoslaps-check.plist"

    # Setup the LaunchDaemon
    /usr/bin/defaults write $LAPS_DAEMON label -string edu.psu.macoslaps-check
    /usr/bin/defaults write $LAPS_DAEMON ProgramArguments -array-add "/usr/local/laps/macOSLAPS"
    /usr/bin/defaults write $LAPS_DAEMON StartInterval -int 5400
    /usr/sbin/chown root:wheel $LAPS_DAEMON
    /bin/chmod 644 $LAPS_DAEMON

    # Load the LaunchDaemon into root services using BootStrap
    /bin/launchctl bootstrap system $LAPS_DAEMON

    # Force the LaunchDaemon to restart so a run can happen after installation
    /bin/launchctl kickstart -k system/edu.psu.macoslaps-check
fi

# Set Correct Permissions for /etc/paths.d/laps
/bin/chmod 744 /etc/paths.d/laps

exit 0

Essentially, if the pref file can't be read, or the UseLaunchDaemon preference isn't set, or it is set to true (bool, aka 1), then the default experience occurs where the LaunchDaemon is created. This would only be skipped if the UseLaunchDaemon preference is set to False (bool, aka 0).

Open to thoughts and suggestions, and to be clear, we're happy repackaging this if necessary!

[wegotoeleven]

Actually--come to think if it--it would probably be better to move the LaunchDaemon and macOSLAPS binary to different component packages (the preinstall and postinstall scripts would live in the launchd component package), and then build a distribution package with them both inside. Doing this, you can also set OS/architecture compatibility as distribution packages are more flexible.

Again, nothing would logically change for the majority of people, but for those who don't want the LaunchDaemon, they simply install the package alongside a ChoiceChanges XML file.

[joshua-d-miller]

The latest release allows you to not install the LaunchDaemon if you so choose. Please use the 3.0.2 release of macOSLAPS. Thanks!