This is a legacy guide for Power Manager v4, published 2010 – 2019, and is provided for reference only.
The latest guide is for Power Manager v5.10.6.

File Configuration

Power Manager’s engine provides a method of updating the configuration through flat files. This method can be used to distribute schedules, licence codes, and other settings where access to the Mac is restricted.

On launch, Power Manager’s engine looks for a configuration file in a specific location. If the file exists, and has changed since the last launch, then the enclosed set of requests are issued.

The configuration file can contain any valid pmdctl API request. This allows a configuration file to set up Power Manager precisely as desired, without needing a network connection.

Example 1.6. File Configuration Location

/Library/Application Support/Power Manager/Configuration/pmd.plist

pmd.plist is checked and loaded at launch.

We use the File Configuration method to support the creation of installers containing custom schedules and licence details.

Security

To ensure Power Manager’s security, the configuration file and the location must have specific ownership and access permissions set. The engine will not use a configuration file unless the security requirements are met:

Example 1.7. File Configuration Permissions and Layout

drwxr-xr-x root:wheel Configuration
-rw-r----- root:wheel Configuration/pmd.plist

Example 1.8. Setting the Correct Permissions

cd '/Library/Application Support/Power Manager/'

sudo mkdir Configuration
sudo cp ~/Desktop/pmd.plist Configuration/.

sudo chown -R root:wheel Configuration
sudo chmod 640 Configuration/pmd.plist
sudo chmod 755 Configuration

Shell script for setting the correct parent directory and file permissions.

Applying a Configuration File

The configuration file is automatically checked and applied when Power Manager’s engine is launched. This normally occurs when the Mac is powered on or restarted.

To avoid needing to restart the Mac each time the configuration file is updated, Power Manager’s engine supports a manual alternative.

The engine can be asked to check the configuration file by sending a Hang Up (HUP) signal. HUP is a UNIX signal. On receiving a HUP signal, the engine will check the configuration file for changes, and apply the contents if appropriate.

Example 1.9. Applying a Configuration with a HUP Signal

sudo killall -HUP pmd

Shell command for sending a Hang Up (HUP) signal to all pmd processes.

We use the HUP signal method to create configuration installers that do not need a restart.

File Format

The configuration file is binary or XML Property List formatted. The file’s root object must be an array.

The array contains dictionary items. Each dictionary item represents an API request.

The request dictionary has only two entries:

Table 1.2. Request Dictionary Format

KeyTypeValue
requeststringAPI request
parametersdictionaryparameter key/value pairs (optional)

Each request dictionary in the configuration file is read, encoded as an API request, and issued. If a request fails, the remaining requests in the configuration file are skipped.

Progress and errors are logged to the standard engine log.

Example 1.10. Example Configuration File

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<array>
    <dict>
        <key>request</key>
        <string>notifications.setnotifyperiod</string>
        <key>parameters</key>
        <dict>
            <key>seconds</key>
            <string>900</string>
        </dict>
    </dict>
    <dict>
        <key>request</key>
        <string>notifications.setwarningperiod</string>
        <key>parameters</key>
        <dict>
            <key>seconds</key>
            <string>10</string>
        </dict>
    </dict>
</array>
</plist>

Property list containing two requests: set the notification period to 10 minutes (900 seconds), and set the warning period to 10 seconds.