Nonpreserving and permissions-preserving replicas
The term non-preserving refers to both non-preserving replicas and replicas that preserve permissions but not identities.
Each non-preserving replica in a VOB family must manage its own rolemaps and policies and the bindings of controlled objects to rolemaps. The behavior described below is designed to make it possible to manage ACLs and their effective permissions independently at each non-preserving replica.
Mastership differences
A non-preserving replica can modify the role bindings in any rolemap and the permissions granted in any policy, regardless of mastership of the policy/rolemap. However, it cannot switch a rolemap from implementing one policy to another policy unless it masters the rolemap and both policies. Also, a non-preserving replica must master any policy it removes. A non-preserving replica may modify the binding of a controlled object to its rolemap without mastering the object. Because it is possible to modify every rolemap and policy at a non-preserving replica, an administrator might be tempted to use the same rolemaps and policies at every replica and manage them independently. However, most administrators create separate rolemaps and policies at each replica. Using separate rolemaps/policies at each non-preserving replica makes it obvious that the protection is being managed independently of the other replicas. The other replicas' rolemaps/policies will be visible in a non-preserving replica.Mapping policy principals and rolemap roles to a non-preserving replica
When creating a non-preserving replica or importing mkpolicy and mkrolemap oplogs to a non-preserving replica, the principals in the policy and the roles in the rolemap will be modified. If a principal in a policy has multiple User and Group entries, they will be replaced by a single User and Group entry for the account creating the non-preserving replica or running the syncreplica import. Similarly for rolemaps, multiple User and Group entries in a role will be replaced by a single User and Group. The resulting permissions in the policy's principal will be the union of the permissions for the multiple User and Group entries. For example, if one User had Read rights and another had Change rights, these will be mapped to Change. The combination Read, Change, and AclWrite will be mapped to Change and AclWrite. Example of policy in mastering replica:policy "pol-01"
2012-11-20T14:09:53-05:00 by Tester Tester (tester0.user@qvml087)
master replica: original@/tmp/vob-03
owner: tester0
group: user
contents:
vob ACL:
User:at1.com/tester0 Full
Group:at1.com/aclgrp1 Read
element ACL:
User:at1.com/tester2 AclWrite,Change
User:at1.com/tester9 Read
Group:at1.com/aclgrp5 Change
Owner-User: Full
User:at1.com/tester10 Delete
Group:at1.com/aclgrp3 Read
Owner-Group: Change
User:at1.com/tester1 Change
Role:READER Read
User:at1.com/tester8 mod-hlink
User:at1.com/tester6 mod-label
User:at1.com/tester3 mod-props
policy ACL:
Role:admin Full
User:at1.com/tester0 Full
Group:at1.com/aclgrp15 Read
User:at1.com/tester6 lock,Change
Group:at1.com/aclgrp6 Change
User:at1.com/tester5 chmaster
User:at1.com/tester7 read-info
rolemap ACL:
User:at1.com/tester20 Read
Role:READER Read
Group:at1.com/aclgrp6 chmaster
Group:at1.com/aclgrp5 Delete
User:at1.com/tester0 Full
Owner-Group: Read
policy "pol-01"
2012-11-20T14:09:53-05:00 by Tester Tester (tester0.user@qvml087)
master replica: original@/tmp/vob-03
owner: tester17
group: user
contents:
vob ACL:
User:at1.com/tester17 Full
Group:at1.com/user Read
element ACL:
Owner-User: Full
Owner-Group: Change
Role:READER Read
User:at1.com/tester17 mod-label,Delete,AclWrite,Change
Group:at1.com/user Change
policy ACL:
Role:admin Full
User:at1.com/tester17 Full
Group:at1.com/user Change
rolemap ACL:
Role:READER Read
Owner-Group: Read
User:at1.com/tester17 Full
Group:at1.com/user chmaster,Delete
rolemap "role-01"
2012-11-20T14:10:27-05:00 by Tester Tester (tester0.user@qvml087)
master replica: original@/tmp/vob-03
owner: tester0
group: user
implements policy: pol-01
contents:
Role:READER
User:at1.com/tester1
User:at1.com/tester5
Group:at1.com/aclgrp10
User:at1.com/tester4
User:at1.com/tester3
Role:admin
User:at1.com/tester0
Group:at1.com/aclgrp3
User:at1.com/tester6
User:at1.com/tester7
rolemap "role-01"
2012-11-20T14:10:27-05:00 by Tester Tester (tester0.user@qvml087)
master replica: original@/tmp/vob-03
owner: tester17
group: user
implements policy: pol-01
contents:
Role:READER
User:at1.com/tester17
Group:at1.com/user
Role:admin
User:at1.com/tester17
Group:at1.com/user
Rolemap and policy oplog behavior
In a non-preserving replica, creating or updating a policy or rolemap will generate oplogs. However, only the creation oplogs will be replayed by other replicas—modification oplogs will not be replayed. (It is not safe to replay modifications because they are possible on non-mastered objects.) When any other replica imports a policy or rolemap creation oplog generated at a non-preserving replica, it will substitute the credentials of the account running multitool syncreplica -import for User and Group entries.Replay of changes to object-rolemaps bindings
Non-preserving replicas' changes of object-rolemap bindings with protect -chrolemap are not replayed at other replicas. This enables the non-preserving replica to move objects to other rolemaps' protection independently of other replicas. The oplogs are generated although they are ignored in routine operation (however, they are useful for some recovery operations).Protection of new objects
For controlled objects, new object creation oplogs include a reference to the controlling rolemap assigned during creation. For elements, the oplog also identifies the parent directory element and its rolemap.
During replay at a non-preserving replica, except for elements, the new object is bound to the same controlling rolemap as shown in the oplog.
Element creation oplogs are handled specially. Because the rolemaps used at the non-preserving replica are likely to be different than those at other replicas, the rolemap bound to a new element is not the rolemap assigned at the generating replica. Instead, HCL VersionVault binds the new element to the new element's parent directory element's rolemap, as known to the importing replica. If the generating replica had different rolemaps bound to the parent directory element and to the new element, a warning message is added to the event record on the import event. This message is stored in the event history, you can see it with cleartool lshistory element
For example, replica A uses rolemap A1 to protect the parent directory element (PDE). Non-preserving replica B uses rolemap B1 to protect that same element. Replica A makes a new element and catalogs it into the PDE, binding the new element to rolemap A1. During replay at replica B, the new element is instead bound to rolemap B1, the rolemap that controls the PDE at replica B.
Example #2: As before, with the addition of rolemap A2. During mkelem, replica A binds the new element to A2 instead of A1 (e.g. mkelem -rolemap), because the new element is supposed to be protected differently than its parent. During replay at replica B, the new element is still bound to B1 (the rolemap controlling the PDE), because A2 is not suitable for use in replica B and VersionVault does not know how to find a better rolemap to substitute for A2.