during boot. To enable
Following WLI installation the system reboots and WLI is initially in maintenance mode. Verify the DLKM to be signed is unloaded:
IMPORTANT: This procedure must be performed as root user. Root user authority is required to load and unload DLKMs.
1.Unload the DLKM:
#kcmodule ciss=unused
2.Sign the DLKM:
#wlisign -a -k /home/admin1/adminpriv /usr/conf/mod/ciss
3.Load the DLKM:
#kcmodule ciss=loaded
A root user needs to repeat these steps if usr/conf/mod/ciss is replaced by software update.
Signing with an authorized user key is also sufficient. The key does not require WLI administrator authority.
NOTE: Granting dlkm capability to the authorizing key or to the dlkm is not necessary.
6.6 Loading unsigned DLKMs
The following example demonstrates how a WLI administrator can dynamically load /usr/ conf/mod/bigdlkm into the kernel domain, without writing a signature. The current state of the DLKM is unused, and the administrator owns administrator key adminpriv with extracted public key adminpub. Because WLI capabilities are not granted to keys automatically, the administrator must grant dlkm capability to adminpriv with wlicert:
%cd /home/admin1
%wlicert
The key adminpriv granted dlkm capability to itself.
An administrator key must also be used to sign /usr/sbin/kcmodule, the command that loads the unsigned DLKM. Granting dlkm capability to the command is not necessary:
%wlisign -a -k adminpriv /usr/sbin/kcmodule
The wliwrap command now executes kcmodule as a child process. Because WLI does not affect
%su root
#wliwrap
In this example, the wliwrap command temporarily added dlkm capability to the kcmodule process.
6.6 Loading unsigned DLKMs 31