Home
Administering
Learn how to administer the product.
Administering HCL VersionVault MultiSite
Learn to configure and manage the HCL VersionVault MultiSite environment to support development activities at different locations.
Implementation planning
Before you install and use HCL VersionVaultHCL Compass MultiSite, you need to plan your implementation.
MultiSite use model
There are different aspects of your MultiSite use model that affect the implementation and deployment of a MultiSite environment.
Identities and permissions strategy for VOB replicas
A replica can preserve identities and permissions, preserve permissions only, or preserve neither identities nor permissions (nonpreserving).
Synchronization of identities and permissions information
When update packets are imported at a given replica, the identities and permissions information that is preserved is dependent on the properties of that replica.

Administering
Learn how to administer the product.
- Administering HCL VersionVault
  Learn about performing administrative tasks for an HCL VersionVault community including managing software licenses, user and group accounts, VersionVault server and client hosts, shared data, and the network that connects them.
- Administering platforms for HCL VersionVault
  Learn how to perform HCL VersionVault administrative tasks on supported platforms.
- Administering HCL VersionVault MultiSite
  Learn to configure and manage the HCL VersionVault MultiSite environment to support development activities at different locations.
  - Introduction
    HCL VersionVault MultiSite adds a powerful capability to HCL VersionVault. With MultiSite, developers at different locations can use the same HCL VersionVault versioned object base (VOB). For HCL VersionVault, each location (site) has its own copy (replica) of the VOB. At any time, changes made in one replica can be sent in update packets to other replicas. You can manage replicas by using the command-line tools.
  - MultiSite operation
  - Implementation planning
    Before you install and use HCL VersionVaultHCL Compass MultiSite, you need to plan your implementation.
    - MultiSite installation
      MultiSite is installed as an optional product component during the HCL VersionVaultHCL Compass installation.
    - MultiSite licensing
      A MultiSite license is required to access an object in a replica by a MultiSite command or GUI, by an HCL VersionVaultHCL Compass command or GUI, or by a standard operating system command.
    - Shipping server use with HCL VersionVault
      The shipping server is installed when you install HCL VersionVault MultiSite.
    - HCL VersionVault use model
      Before development work is started in any VOB, the project manager and administrator must define the HCL VersionVault use model. For example, the project manager must specify the branches, labels, and triggers that are used for development and integration work.
    - MultiSite use model
      There are different aspects of your MultiSite use model that affect the implementation and deployment of a MultiSite environment.
      - Type of administration
        You must decide how much control the individual sites will have over their replicas. Your choices are centralized administration, individual administration, or some combination of the two.
      - MultiSite, time, and time zones
        In MultiSite, time stamps are stored in Universal Coordinated Time (UTC) and are printed to reflect the local time.
      - Time rules in config specs
        Time rules in config specs are not absolute. The version selected by a time rule can change after an update packet is imported at your replica.
      - Mastership strategy
      - Identities and permissions strategy for VOB replicas
        A replica can preserve identities and permissions, preserve permissions only, or preserve neither identities nor permissions (nonpreserving).
        Identities- and permissions-preserving replicas
        Identities- and permissions-preserving replicas maintain the same user and group identities and permissions on elements, and changes to identities or permissions are synchronized among them.
        Permissions-preserving replicas
        Permissions-preserving replicas maintain the same permissions on elements, and changes to permissions are synchronized among the other replicas in the family that preserve permissions, including those that preserve both identities and permissions.
        Nonpreserving replicas
        Nonpreserving replicas ignore identities and permissions changes made at other replicas and maintain their own identities and permissions information for elements.
        Synchronization of identities and permissions information
        When update packets are imported at a given replica, the identities and permissions information that is preserved is dependent on the properties of that replica.
        Requirements for replicas that preserve identities and permissions
        The sites of replicas that preserve both identities and permissions must support the same set of user and group accounts (at least for the accounts that can be assigned to VOB elements). The user and group names and numerical IDs (UID/GIDs on Linux® or the SIDS on Windows®) must be the same across sites.
        Gathering identities information
        If you plan to create one or more identities- and permissions-preserving VOB replicas, you must ensure that the user and group information defined on the exporting and importing sites are coordinated appropriately. Otherwise, you could encounter import failures due to permissions problems.
        Running protectvob on identities-preserving replicas
        If you run protectvob on a VOB replica that preserves identities, you must follow some additional steps to prevent metadata divergence or synchronization problems among replicas in the VOB family.
      - Managing rolemaps, policies, and object-rolemap bindings
        There are several administrative consequences arising from the differences between policy mastership and rolemap mastership, and also from the replication mode of the VOB family.
      - Group selection in replicas according to feature level
      - Synchronization
        The main factors to consider when planning replica synchronization are method, scheduling, and pattern.
      - Synchronization pattern
        The synchronization pattern for a family defines which replicas exchange update packets and the direction of exchange.
      - Synchronization schedule
        The synchronization schedule for a family defines when replicas in the family send and receive updates. The schedule is affected by many factors, including the rate of development at different sites, the connections among sites, and whether you use MultiSite as a backup strategy.
      - Use of MultiSite for VOB backups
        You can use MultiSite as part of your VOB backup strategy.
      - Scrubbing parameters for replicas
        When a command makes a change to a replica, an entry is recorded in the replica’s operation log. Also, when you export an update packet, an export_sync record is created for each target replica. These records are used by the recoverpacket command to reset a replica’s epoch number matrix.
      - Path names that contain spaces
        On computers running Windows™, if the path name of a receipt handler or a shipping order contains spaces, DOS short name resolution must be enabled for the file system on which the receipt handler or shipping order is located. This property is enabled by default. If this property is not enabled, the shipping server cannot invoke the receipt handler or process the shipping order.
    - Responsibilities of MultiSite administrators
      The MultiSite administrator must perform the tasks described in this topic.
  - MultiSite command set
    This section summarizes the commands for HCL VersionVault MultiSite and HCL VersionVault that display HCL VersionVault MultiSite information. There are a series of MultiSite commands and API functions that display or modify MultiSite information.
  - Packet transportation methods and configuration
    The method you choose for transporting packets between replicas depends on connectivity. If your replicas do not have IP connectivity, you must use a file-based transport method. If your replicas have connectivity, you can use the store-and-forward facility.
  - Feature levels
    Feature levels allow different replica hosts in a VOB family to run different versions of HCL VersionVault. You can raise the feature level of either a single replica host or an entire VOB family.
  - Creating VOB replicas
    Before creating a replica, you must make decisions about branching, mastership, identities and permissions preservation, and method of packet delivery.
  - Replica synchronization
    Replica synchronization uses the same export-transport-import procedure that is used during replica creation.
  - Administering replicas
  - Using MultiSite for VOB backup and interoperability
    You can use HCL VersionVault MultiSite to back up a VOB and to provide access to VOBs in a heterogeneous network.
  - Troubleshooting MultiSite operations
    When you encounter a situation where running an HCL VersionVault MultiSite command produces an unexpected result, or produces a warning or error message, the information in this section can assist you in troubleshooting the problem.

Synchronization of identities and permissions information

When update packets are imported at a given replica, the identities and permissions information that is preserved is dependent on the properties of that replica.

When an update packet is imported at a permissions-preserving replica, identities information is ignored. When an update packet is imported at a nonpreserving replica, identities and permissions information is ignored. At both kinds of replicas, the information remains in the oplog entries so that it can be transmitted to replicas that preserve identities and permissions or permissions only. For example:

A new element is created at replica A, which preserves identities and permissions.
Replica A sends an update packet to replica B, which is nonpreserving.
The new element is created at replica B. Its owner is the VOB owner of replica B and its group is the VOB’s primary group.
Replica B sends an update packet to replica C, which preserves identities and permissions.
The new element is created at replica C. Its owner is the original creator and its group is the original creator’s group.

Elements created at a nonpreserving or permissions-preserving replica always get the importing VOB’s owner and group when they are imported, regardless of whether the importing replica preserves identities.

Whenever a replica exports sync packets, it includes any identities/permission oplogs from any replicas, regardless of their preserve mode. It is the receiving replica whose mode determines whether identity/permission information is applied locally or not.

Have feedback?
Google Analytics is used to store comments and ratings. To provide a comment or rating for a topic, click Accept All Cookies or Allow All in Cookie Preferences in the footer of this page.