ESF Update Scope: ESF Update All Reaches Only the ESCWA Process, esfupdate Reaches Directory Server and Running Regions
In Rocket Enterprise Server 12.0 on UNIX, ESF caches are not refreshed immediately when users, groups or resources change. The ESCWA ESF Update All button applies only to the ESCWA process, while the esfupdate utility can target Directory Server and running servers with finer control. [1] [2] [3]
Read the full briefing
Scope: Rocket Enterprise Developer / Enterprise Server 12.0 for Eclipse on UNIX, External Security Facility (ESF) and Enterprise Server Common Web Administration (ESCWA).
Security changes are not applied to ESF caches immediately
When users, groups, or resources are changed through ESCWA, the changes are not applied to the ESF caches immediately. Clicking ESF Update All and confirming the prompt applies them to the ESCWA process: ESF flushes its cached information and recomputes stored results such as group membership, and the caches refill as subsequent security requests are processed (Restricting ESCWA with ESF).
The same page carries a caution that defines the scope of that button: an ESF update applies only to the ESCWA process and might be resource intensive. To notify other processes, such as running enterprise server regions, of changes to security data, the esfupdate command-line utility is used.
The three update entry points
The documentation describes the Update mechanism as a way to notify running processes of changes to security data in External Security Managers. Each process flushes its own caches when it next processes an ESF request (Additional ESF notes). Three entry points are documented:
- ESCWA Security Facility Configuration page, ESF Update All button: applies only to the ESCWA process.
- MFDS administration user interface, Update All button: makes basic update notifications.
esfupdatecommand-line utility: Rocket Software recommends it for submitting update requests because it provides more control of the request contents and destination.
esfupdate syntax
The documented syntax is:
esfupdate [options] update-type [entity-name](To Update Security Manager Changes Using esfupdate)
Options and their documented meaning:
-a action: the update action, one ofadd,delete,modify, orother. The default ismodify.-u userand-p password: the username or secret location, and the password or secret location, for binding to Directory Server.-m host[:port]: the location of Directory Server. The default islocalhost:86.-r server: the name of the server or servers to update. This can include wildcards.-M: updates the Directory Server.-v: displays version information and exits.-h: displays syntax information and exits.
The update-type is one of user, group, resource, users, groups, resources, or all. The entity-name must be supplied when the update type is user, group, or resource, and is otherwise omitted.
Targeting behavior and credentials
Several documented defaults determine where a notification goes:
- If neither
-Mnor-ris specified, update notifications are sent to Directory Server and all running servers. - If user and password are not supplied,
esfupdateattempts to bind to Directory Server anonymously. - If user is supplied but not the password, a password prompt is issued.
For a user entity, when name mapping is in use, the short name (the Enterprise Server userid) can be supplied. With MLDAP ESM Module version 2.5.27 (Enterprise Server 5.0), 2.7.9 (Enterprise Server 7.0), or 2.8.0 or later, the long name (ESM username) can also be used.
Documented examples
The following notifies the Directory Server and any running Enterprise Server that the user SAFU has been modified, binding to Directory Server as the SYSAD user. The page notes this could mean that the user's Mainframe Subsystem Support user attributes, such as user priority, changed, or that the user was added to or removed from a group:
esfupdate -u CN=SYSAD -p SYSAD user SAFUThe following obtains the bind credentials from a secret and updates everything:
esfupdate -u mfsecret:admin/username -p mfsecret:admin/password allESCWA-side update settings
Security changes can be implemented from ESCWA or with the esfupdate utility (Implementing Security Manager Changes). The ESCWA procedure distinguishes two cases. To update regions with security manager changes without affecting the security managers used by Directory Server, the Use all groups option is checked on the ESCWA Security Facility Configuration page and applied, which retrieves the latest security information from the external security manager. To update the security managers used by Directory Server, the Update when external Security Manager properties change check box is checked on the MF Directory Server tab of the Security page (To Update Security Managers using ESCWA).
Takeaway
An ESCWA ESF Update All refreshes only the ESCWA process. Running regions and Directory Server are notified through esfupdate, whose -M and -r options narrow the destination and whose update types (user, group, resource, their plurals, or all) narrow the content.