How to Script Power Manager Licensing
A recipe showing how to apply a licence to Power Manager using a script.
Power Manager’s licensing is certificate based. This means your licence is represented by a certificate file1 and that file needs to be applied to Power Manager to work.
Typically, a licence is applied by following the steps included with the purchase or at licensing support. This approach uses the graphical Power Manager application and the menu item:
- Power Manager.app > Scheduler (menu) > Licence Options…
This is the recommended approach.
What if you have many computers to apply a licence to? What if you want to automate the applying of the licence?
Command Line Approach
Power Manager supports applying the licence using the included command line tool
pmctl
. The requests associated with licensing all begin with legal.
. This set of requests include calls to query, apply, and remove licences from Power Manager.
On macOS, the pmctl
command is in the application bundle. Before trying the commands below, launch Terminal.app
and change into the Tools
directory using the command:
cd "/Applications/Power Manager.app/Contents/Tools/"
Querying the Licence
The command for querying, or viewing, the current licence is:
./pmctl legal.licence
This command will return details of who the current licence was issued to and when that licence expires. The state
value of the response can be used to check if Power Manager is in a licensed
, demonstration
, or expired
state.
Applying a Licence
The command to apply a licence is:
./pmctl "legal.license" "pem=(text:file:///Users/you/Desktop/licence.pem)"
This command assumes a licence file exists on your desktop at:
/Users/you/Desktop/licence.pem
The legal.license
request requires administrator credentials. This is because the request affects every user of the computer.
Avoiding Credentials
If the legal.license
request requires the entering of credentials, how can a script be written without needing interaction? Here we return to the perennial topic of
writing scripts without passwords.
For this recipe, we are going to assume the script can be run as root
/superuser
. This ability is available to administrators in most managed environments. If elevated privileges are not available, investigate the
client certificate approach.
Let’s look at the compete script and then work through what the arguments and flags do. The following script must be run as the root
/superuser
user to work:
#!/bin/bash
cd "/Applications/Power Manager.app/Contents/Tools/"
./pmctl -verbose -as-file-configuration "legal.remove" "legal.license" "pem=(text:file:///Users/you/Desktop/licence.pem)" "scheduler.setenabled" "enabled:boolean=true"
This script is doing more than just calling legal.license
. There are extra requests to ensure the robust handling of edge cases and possible problems.
The requests being made are:
legal.remove
Remove any previously applied licences. This is not essential but it avoids errors when the script attempts to apply a duplicate licence. Without this request, multiple runs of the script may return an error.
legal.license
Apply the licence stored in the URL
file:///Users/you/Desktop/licence.pem
. The URL is read, treated as text, and passed tolegal.license
as thepem
parameter.scheduler.setenabled
Ensure the scheduler is re-enabled after the licence is applied. When removing the licence with
legal.remove
, the scheduler may be disabled if the demonstration period had expired.
The flags being passed to pmctl
are:
-verbose
Increase the verbosity of output to help debug the script. This will ease finding mistakes or unexpected behaviour. Verbose output from
pmctl
is optional.-as-file-configuration
Issue the requests via the file configuration method. This method provides less immediate feedback but it avoids interaction.
The requests are written to a file with specific permissions.
pmctl
then sends aHUP
signal to the scheduler’s daemon processuk.co.dssw.powermanager.pmd
. The signal causes the scheduler to read the file and perform the requests.Sending a
HUP
signal to theuk.co.dssw.powermanager.pmd
process requiresroot
privileges and proves to the scheduler that the caller must be at least an administrator of the computer.
So when this script is run, pmctl
prepares a file and asks Power Manager to read it. Request errors and responses are not shown by pmctl
because the request is happening outside of the scope of pmctl
. See Power Manager’s
log output in case of problems.
The file is an X.509 PEM encoded certificate. ↩︎