Whitelisting of Kext's about macinbox HOT 6 CLOSED

@egandro please take a look at the --user-script feature I added in PR #27 and let me know if that would address your request.

from macinbox.

The user script you want would look something like:

#!/bin/bash

cat << EOF | /usr/bin/sqlite3 "${1}/private/var/db/SystemPolicyConfiguration/KextPolicy"

PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
INSERT INTO kext_policy VALUES('xxxxxxxxxx','com.xxx.yyy.zzz,1,'Example, Inc.',1);
COMMIT;

EOF

To determine what values you need to insert into the KextPolicy database, first install the kexts on a running system and permit them to be loaded, and then run this command:

echo ".dump kext_policy" | sqlite3 /private/var/db/SystemPolicyConfiguration/KextPolicy

from macinbox.

Sure, @egandro, I'd be happy to consider a PR that adds such a feature, thought it does does seem like it may contradict the macinbox design philosophy:

[T]his tool is also intended to the do the least amount of configuration possible. Nothing is done that could instead be deferred to a provisioning step in a Vagrantfile or packer template.

I think I'm willing to make an exception here, since macinbox already knows how to update the kext whitelist, and there's a clear benefit to getting the kext whitelisted before the first boot.

On the other hand, I wonder if it would be better to make this mechanism more generic; basically, a way for the user to specify a custom script that is run after the macOS installer finishes, and is provided with the path to the newly-installed OS so that it can make any modifications it wants.

from macinbox.

I think yes - if we provide some cool examples.

from macinbox.

I've merged the PR to master: bcc8f9f

from macinbox.

Tagged and released: https://github.com/bacongravy/macinbox/tree/v3.3.0

from macinbox.