HP-UX Whitelisting Version A.01.02 Release Notes (766165-001,March 2014)

For a WLI database archive to be internally consistent, the archive must contain all files residing
under /etc/wli. These files must not have any intervening updates.
The database is updated through the wliadm, wlicert, wlisys, and wlisyspolicy commands.
The database can be restored from archive only with WLI security mode set as maintenance.
The security mode is cached within kernel space, not read from the database. The security
mode in effect can only be determined by:
% wlisyspolicy -g
To switch to maintenance mode:
% wlisyspolicy -s mode=maintenance -k <admin_key>
The command might return a message that a reboot is necessary. Following reboot, query once
more with wlisyspolicy to verify maintenance mode is in effect.
To restore the WLI database from archive:
% su root
# rm -r /etc/wli
If deletion fails for any file, reboot the system with a kernel that does not contain WLI.
# tar -xf /tmp/wlikeydb.tar
Or use an equivalent archive restore operation.
If the WLI database has been severely damaged, switching to maintenance mode might not be
possible. To maintain the highest possible security, the security mode defaults to restricted
if the initialization value cannot be read from the WLI database.
If the system cannot be switched to maintenance mode using wlisyspolicy, a kernel must
be booted that does not contain the WLI components.
To rebuild the kernel without wli:
# kcmodule wli=unused
# shutdown -r
Following reboot, all WLI file access policies and resource protections are disabled. After restoring
the WLI database, the WLI kernel can be rebuilt and rebooted:
# kcmodule wli=static
# shutdown -r
HP Serviceguard
WLI has no associated processes in user or kernel space. Therefore, failover packaging is not
required for WLI by itself. However, a product that accesses files protected by WLI access policies
might need some adjustments to its failover packaging.
WLI does not affect device special files with the exception of /dev/mem and /dev/kmem. A
failover package does not need modification for WLI services with regard to the transitioning of
communication and storage links between nodes. The
WLI database contains certain files unique to each platform that cannot be shared among cluster
nodes. The WLI database must also reside on the root file system, which is mounted early following
the kernel initialization phase of boot. Because the WLI database is not sharable among nodes,
successful product failover depends on WLI administrative command operations being executed
identically on each node following the initial installation.
Veritas Storage Foundation CFS is not supported by WLI. Policies assigned to files residing on CFS
file systems are not enforced.
The shared library functions in /opt/wli/lib/libwliapi.so are not supported on HP
Serviceguard clusters in this release.
14 Troubleshooting and known issues