Enabling requests for mastership

To enable requests for mastership for the replicas in a VOB family, you must verify the feature level, add developers to the access control list, specify any objects for which you want to deny requests, and then enable requests at the replica level for each replica in the VOB family.

1. Verify that the feature level of each replica in the VOB family is the correct value, and that the VOB family’s feature level is the correct value. For instructions, see Feature levels.
2. At each replica, add the appropriate people to the replica’s access control list.

   multitool reqmaster –acl –edit vob-selector
   

   A replica’s access control list (ACL) contains a list of users at other sites who are allowed to request mastership of branches and branch types mastered by that replica. To modify this file, you must be VOB owner, root (on Linux® and the UNIX® system), a member of the DevOps Code ClearCase administrators group (on Windows), or have write permissions on the ACL.

   The vob-selector specifies a VOB family, and the ACL for your current replica is changed.

   An access control list contains lines of the following form:

   identity-specification access-level,...
   

   identity-specification is one of the following:

   Everyone

   Everyone in all domains.

   Domain:domain

   Everyone in the specified domain.

   Group:domain /group

   Everyone in the specified group in domain. You can use a slash ( / ) or backslash ( \ ) between domain and group.

   User:domain /username

   A specific user in a particular domain. You can use a slash ( / ) or backslash ( \ ) between domain and username.

   On Windows, domain is the name of a Windows domain (for example, purpledoc). On Linux and the UNIX system, domain is an NIS domain name (for example, purpledoc.com). If someone who can request mastership has user names in multiple domains, you must specify all the identities in the ACL.

   access-level is one or more of the following:

   Read

   Allow read access on ACL

   Write

   Allow write access on ACL

   Change

   Allow requests for mastership

   Full

   Allow requests for mastership and read/write access on ACL

   Separate multiple access levels with a comma and no white space. The identity specification and associated access levels must appear on the same line.

   For example, the following ACL specifies that susan can modify the ACL, and jcole and kumar can request mastership:

   User:purpledoc.com/susan Read,Write
   User:purpledoc/susan Read,Write
   User:purpledoc.com/jcole Change
   User:purpledoc/jcole Change
   User:purpledoc.com/kumar Change
   User:purpledoc/kumar Change
   

   The following ACL gives msadm full permissions and allows everyone to request mastership:

   User:purpledoc.com/msadm Full
   User:purpledoc/msadm Full
   Everyone Change
   

3. At each replica, deny requests for mastership of specific objects. By default, requests are allowed for all branches and branch types.

   For example:

   multitool reqmaster –deny branch-pname

   Denies requests for mastership of the specified branch.

   multitool reqmaster –deny branch-type-selector

   Denies requests for mastership of the specified branch type.

   multitool reqmaster –deny –instances branch-type-selector

   Denies requests for mastership of all instances of the specified branch type.

   For you to allow or deny mastership requests for a branch or branch type, your current replica must master it. You can allow or deny mastership requests for all instances of a branch type even if your current replica does not master the type.

   If the branch type is a global type, its mastership request setting is stored in the administrative VOB and applies to all local copies of the branch type.

4. At each replica, enable requests for mastership at the replica level.

   multitool reqmaster –enable vob-selector
   

   The vob-selector specifies a VOB family, and your current replica is enabled for mastership requests. You must enter this command on the VOB server host.

   To enable or disable permission at the replica level, you must be the VOB owner, root (Linux and the UNIX system), or a member of the DevOps Code ClearCase administrators group (Windows). Also, the replica must master its own replica object.

   In an administrative VOB hierarchy, you enable requests for mastership in the VOB replicas linked to the administrative VOB. You do not have to enable requests in the administrative VOB replica unless it contains elements that are developed serially.