Preventing Secondary hubs from propagating changes to security.cfg

Document ID : KB000073868
Last Modified Date : 16/03/2018
Show Technical Document Details
With hub 7.92 HF1 we have added the ability to prevent secondary hubs from propagating security.

The configuration defined in this doc is now the recommended best practice for all domains
  • By Default, changes to security.cfg are propagated from any hub.
  • There are circumstances where a secondary hub's security.cfg file can be corrupted.
  • This is then propagated across all other hubs removing all ACL's and thus wiping out the security configuration across the whole estate.
Two configuration keys affect this behavior:
  • Set secure_callbacks_from_primary_hub_only in security.cfg. Default: no
    • This value is changed with the hubsec_setup_put callback.​
      • Key = secure_callbacks_from_primary_hub_only
      • value = yes
        • When the key is set to yes:
          • The primary hub propagates security changes to all hubs in the domain. When this value is set to no, a hub only propagates security changes to nearby hubs. Nearby hubs are hubs that are one level away.
          • A secondary hub rejects security updates from other version 7.92HF1 and above secondary hubs. Updates from pre-7.92HF1 secondary hubs and primary hubs are accepted. Accepting updates from pre-7.92HF1 hubs eases an incremental upgrade.
          • A user cannot make security-related callbacks on a secondary hub. Security-related callbacks include:  
            • user_change_password
            • user_delete
            • user_edit
            • user_new
            • probe_delete
            • probe_new
            • profile_delete
            • profile_delete_ex
            • profile_put
            • profile_put_ex
            • profile_users_set
            • hubsec_delete
            • hubsec_edit
            • hubsec_new
            • hubsec_restore
            • hubsec_setup_put
            • hubsec_update
          • When a probe is installed, the secondary hub receives a request to add a probe to the security file, this request is forwarded to the primary hub. The primary hub then executes the request and propagates the security file update to all the other hubs in the domain.
          • When secure_callbacks_from_primary_hub_only is disabled, the primary hub propagates the change to all other hubs before disabling it in itself.
  • Set security_config_propagation in hub.cfg. Default: yes
    • When the key is set to yes, the hub can propagate updates to security.cfg to all other hubs in the domain.
    • When the key is set to no, the hub cannot propagate updates that it receives.
    • The primary hub ignores the value of this key, and propagates updates even when the key is set to no.
    • This value must be explicitly set in each hub.cfg file. Restart the hub for the change to take effect.
  • The following configuration is recommended for all domains:
    • Set secure_callbacks_from_primary_hub_only to yes.
    • Set security_config_propagation to no.
    • This combination ensures that:
      • Security updates propagate from the primary hub only.
      • Security updates propagate to all the hubs in the domain, regardless of the proximity to the primary hub.