9.4 Enabling Requests for Mastership

The procedures in this section use the command line. On Windows, you can use the ACL editor and the Properties Browser. For more information, see the MultiSite online help:

  1. Click Start > Programs > Rational ClearCase Administration > MultiSite Help.

  2. On the Contents tab of the Help Contents Window, click Administrator Tasks > Enabling Requests for Mastership > To enable requests for mastership.

Prerequisites

  1. Ensure that the replica is self-mastering. See Transferring Mastership of a Replica Object.

  2. Ensure that the feature level of the replicas in the VOB family is the correct value, and that the VOB family's feature level is the correct value. For instructions, see Chapter 5, ClearCase Feature Levels.

Adding Developers to the Access Control List

  1. At each replica, add the appropriate people to the replica's access control list.

  2. 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 UNIX), a member of the 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 UNIX, 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, but do not include spaces between access levels. 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

Deny Requests for Specific Objects

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

  2. 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.

Enable Requests at the Replica Level

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

  2. 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 (UNIX), or a member of the ClearCase administrators group (Windows). Also, the replica must master its own replica object.

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

After you enable requests for mastership, inform the appropriate developers about mastership requests and how and when to use them. Working On a Team in the Working in Base ClearCase part of Developing Software describes the procedures developers must use to request mastership.

NOTE: The reqmaster command is a cleartool subcommand as well as a multitool subcommand, so developers who will request mastership do not have to install MultiSite software on their client hosts. On Windows, developers can request mastership from the Find Checkouts window, the Merge Manager, and the Version Tree Browser.