protectvob

Changes various properties of a VOB

Applicability

Product

Command type

VersionVault

cleartool subcommand

Platform

UNIX®

Linux®

Windows®

Synopsis

  • Change various properties of a VOB:
    protectvob [ –f/orce ] [ –cho/wn login-name ] [ –chg/rp group-name ]
    [ –add/_group group-name[,...] [ –del/ete_group group-name[,...] ]

    [ –ato/mic_checkin | –nato/mic_checkin ]

    [ –srfm | –nsrfm ]

    [ –evil_twin | –evil_twin_warn | –nevil_twin ]

    [ –evil_twin_case_sens | –nevil_twin_case_sens ]

    { vob-storage-dir-pname | pname-in-vob } ...

  • Disable or enable certain types of VOB access:
    protectvob [ –rem/ote_admin | –nrem/ote_admin ]

    [ –enable_acls ]

    [ –min_client_flevel client-flevel ]

    { vob-storage-pname | pname-in-vob } ...

Description

The protectvob command is used to change various properties of a VOB. Before executing this command, log in to the host where the VOB storage directory resides with the following credentials:
  • UNIX system or Linux: root
  • Windows: local administrator, VOB owner, or member of the VersionVault group
Execute this command only when there are no active users of the VOB; it stops and restarts the vob_server process, which prevents access to the storage pools.
Note: Enabling ACLs on a VOB (–enable_acls) is an irreversible operation: after ACLs have been enabled, they cannot be disabled.

Ownership and group membership. The protectvob command can be used to manage the ownership and group membership of the files and directories in a VOB by changing the OS-level permissions on files and directories within the VOB storage area. However, protectvob does not change permissions on the file .hostname; you must change its permissions manually after using protectvob. If you specify no options, protectvob checks pool permissions and offers to repair them.

This command also allows you to disable privileged VOB access by remote users and require any privileged user to be logged on to the VOB server host to perform a privileged operation (for example, modifying an object that is owned by another user or group).

Atomic checkin operations. The options -atomic and -natomic enable and disable atomic checkin operations. If atomic checkins are enabled, checkin must succeed for all elements specified by a checkin operation; else the checkin operation fails for all elements.

Evil twin management. Options of the form *evil* are used to manage evil twins, which are elements of the same name that have been created in different versions of the same directory element.

Replicated VOB: preventing metadata divergence. If you run protectvob -chown or protectvob -chgrp on a VOB replica that preserves identities, you must follow these steps to prevent metadata divergence among replicas in the VOB family:
  1. Stop synchronization among identities-preserving replicas in the family. Make sure that all update packets have been imported.
  2. Run protectvob -chown or protectvob -chgrp on all identities-preserving replicas in the family. You must use the same options and arguments in each command.
  3. Restart synchronization.
(A VOB's protection with respect to privileged access by remote users is never replicated. It must be set on each replica by a privileged user logged on to the VOB server host.)

Replicated VOB: enabling synchronous requests for mastership. Synchronous request for mastership (SRFM) allows a user to check out a file or directory that is not mastered at the user's VOB replica. A request for mastership of the branch is issued to the mastering replica synchronously with the checkout operation if SRFM has been enabled at the requesting replica. SRFM must be enabled at all replicas that are intended to support SRFM.

Restrictions

Identities

You must have one of the following identities:

  • root (UNIX® or Linux®)
  • Local administrator of the VOB server host (Windows®).
  • Member of the VersionVault administrators group (when using the -nremote_admin or -remote_admin options on Windows®.)
Note: You cannot use the -add_group option to add the VersionVault administrators group. This group already has rights to all VOB objects.

Locks

An error occurs if one or more of these objects are locked: VOB.

Mastership

(Replicated VOBs only) No mastership restrictions.

Options and arguments

Confirmation step

Default
protectvob asks for confirmation before changing the permissions in one or more storage pools.
–for/ce
Suppresses the confirmation step.

Changing VOB ownership

Default
None. You can use –chown by itself or in combination with –chgrp.
Note: On Windows®, a member of the Backup Operators or Administrators group can change ownership of any VOB with protectvob –chown. If you are the VOB owner, you can change ownership of that VOB by running protectvob –chown user as yourself, and then logging in as user and running protectvob –force vob-storage-pname with no other options.
–cho/wn user
Specifies a new VOB owner, who becomes the owner of all the VOB's storage pools and all of the data containers in them. user can be a login name or one of the following:

On UNIX® and Linux®, a numeric user ID. protectvob rebuilds the .identity subdirectory of the VOB storage directory, reflecting the new VOB owner's user ID, group ID, and additional groups (if any).

On Windows®, the numeric user ID displayed by versionvault-home-dir\etc\utils\creds username (this is not the same as the Windows® Security Identifier). protectvob rebuilds the Security Descriptor on the VOB root directory (on NTFS only) and the identity.sd and group.sd files in the VOB storage directory, reflecting the new VOB owner's user ID, group ID, and additional groups (if any).

–ch/grp group
Specifies a new principal group for the VOB. group can be a group name or one of the following:

On UNIX® and Linux®, a numeric group ID.

On Windows®, the numeric group ID displayed by versionvault-home-dir\etc\utils\creds –g groupname.

Maintaining the secondary group list

Default
None. You can use –add_group and –delete_group singly, or together.
–add/_group group[,...]
Adds one or more groups to the VOB's secondary group list. group can be a group name or one of the following:

On UNIX® and Linux®, a numeric group ID.

On Windows®, a numeric group ID displayed by versionvault-home-dir\etc\utils\creds –g groupname (Windows®).

You must enclose group names that contain spaces in double quotes.

–del/ete_group group[,...]
Deletes one or more groups from the VOB's secondary group list. group can be a group name or one of the following:

On UNIX® and Linux®, a numeric group ID.

On Windows®, the numeric group ID displayed by versionvault-home-dir\etc\utils\creds –g groupname. You must enclose group names that contain spaces in double quotes.
Note: Existing elements owned by group are not changed. Use cleartool protect –chgrp to change the group owner of such elements to a group that is in the VOB's secondary group list.

Enabling atomic checkin operations

Default
None.
–ato/mic_checkin
Enables atomic checkin operations. See the checkin reference page for information about atomic checkin operations.
–nato/mic_checkin
Disables atomic checkin operations.

Enabling synchronous requests for mastership

Default
None.
–srfm
Enables synchronous requests for mastership of unmastered branches.
–nsrfm
Disables synchronous requests for mastership of unmastered branches.

Enabling ACLs

Default
DefaultPolicy and DefaultRolemap
–enable_acls
Enables ACL authorization for the specified VOB.
MultiSite: The replica must master the VOB object. When this option is specified for a nonpreserving or a permissions-only preserving replica, only that replica becomes ACL-enabled. When this option is specified for an identity- and permissions-preserving replica, the other replicas become ACL-enabled after synchronization.

Setting the minimum client feature level

Default
None.
–min_client_flevel client-flevel
Sets the minimum client feature level that is necessary to access the specified VOB. This option may be used only for a VOB that has been raised to feature level 7 or greater. (Client feature level 7 is used by V8 and client feature level 8 is used by V8.0.1.)

Managing evil twins

Note: If the VOB is replicated, use these options at the replica that masters the VOB object; the management policy that you specify will be propagated to the other replicas accordingly.
Default
None.
–evil_twin
Prevents the creation of evil twins.
–evil_twin_warn
Issues a warning when an evil twin is created
–nevil_twin
Disables evil twin prevention or warnings of evil twin creation.
–evil_twin_case_sens
If evil twin prevention or warnings are enabled, specifies case-sensitive search for evil twins; for example, makefile and Makefile would not be considered evil twins.
–nevil_twin_case_sens
If evil twin prevention or warnings are enabled, specifies non-case-sensitive search for evil twins; for example, makefile and Makefile would be considered evil twins.

Specifying the VOB

Default
None.
vob-storage-pname
Local pathname of a VOB storage directory.
pname-in-vob
The pathname of the VOB tag (whether or not the VOB is mounted) or of any file system object within the VOB (if the VOB is mounted). It cannot be the pathname of the VOB storage directory.

Controlling privileged access by remote users

Default
None
-nrem/ote_admin
Disables privileged access by remote users. When a VOB is protected with this option, all privileged operations require the user to be logged on to the VOB server host with a privileged identity. Any request from a privileged user logged on to a remote host is treated as though it had been made by an ordinary user (it fails if a privileged identity is required).
-rem/ote_admin
Re-enables privileged access by remote users to a VOB protected or created with the -nremote_admin option.

These options are effective only when you are logged on to the VOB server host as a privileged user.

Examples

The UNIX system and Linux examples in this section are written for use in csh. If you use another shell, you may need to use different quoting and escaping conventions.

The Windows examples that include wildcards or quoting are written for use in cleartool interactive mode. If you use cleartool single-command mode, you may need to change the wildcards and quoting to make your command interpreter process the command appropriately.

In cleartool single-command mode, cmd-context represents the UNIX system and Linux shells or Windows command interpreter prompt, followed by the cleartool command. In cleartool interactive mode, cmd-context represents the interactive cleartool prompt.

  • On a UNIX® or Linux® system, make user jackson the owner of the VOB whose storage area is /usr/lib/vob.vbs. 
    cmd-context  protectvob -chown jackson /usr/lib/vob.vbs 
This command affects the protection on your versioned object base.
While this command is running, access to the VOB will be limited.
If you have remote pools, you will have to run this command remotely.
Pool "sdft" needs to be protected correctly.
Pool "ddft" needs to be protected correctly.
Pool "cdft" needs to be protected correctly.
Protect versioned object base "/usr/lib/vob.vbs"? [no]yes 
Do you wish to protect the pools that appear not to need protection? [no]no 
Protecting "/usr/lib/vob.vbs/s/sdft/0"...
Protecting "/usr/lib/vob.vbs/s/sdft/1"...
Protecting "/usr/lib/vob.vbs/s/sdft"...

...

Protecting "/usr/lib/vob.vbs/d/ddft"...
Protecting "/usr/lib/vob.vbs/d/ddft/0"...
...
Protecting "/usr/lib/vob.vbs/c/cdft"...
Protecting "/usr/lib/vob.vbs/c/cdft/2d"...
Protecting "/usr/lib/vob.vbs/c/cdft/35"...
...
VOB ownership:
 owner jackson
 group user
Additional groups:
 group doc
Change the owner and group of a remote VOB storage pool.
% rlogin ccsvr01
Password: 
<enter password>
% /opt/hcl/ccm/versionvault/etc/chown_pool jackson.user /vobaux/vega_src/s001
  • On a Windows® system, make user smg the owner of the VOB whose storage area is C:\vobs\docs.vbs. 
    cmd-context protectvob –chown smg c:\vobs\docs.vbs 
This command affects the protection on your versioned object base.
While this command is running, access to the VOB will be limited.
Pool “sdft" appears to be protected correctly.
Pool “ddft" appears to be protected correctly.
Pool “cdft" appears to be protected correctly.
Protect versioned object base “c:\vobs\docs.vbs"? [no]yes 
Do you wish to protect the pools that appear not to need protection? [no]no 
VOB ownership:
  owner smg
  group user
Additional groups:
  group Backup Operators
  • On a UNIX® or Linux® system, add one group to a VOB's group list, and remove another group. 
    cmd-context protectvob -add_group devel -delete_group doc /usr/lib/vob.vbs 
This command affects the protection on your versioned object base.
While this command is running, access to the VOB will be limited.
If you have remote pools, you will have to run this command remotely.
Pool "sdft" appears to be protected correctly.
Pool "ddft" appears to be protected correctly.
Pool "cdft" appears to be protected correctly.
Protect versioned object base "/usr/lib/vob.vbs"? [no]yes 
Do you wish to protect the pools that appear not to need protection? [no]no 
VOB ownership:
 owner jackson
 group user
Additional groups:
 group devel
  • On a Windows® system, add the group Doc Group to a VOB's group list. 
    cmd-context protectvob –add_group "Doc Group" c:\vobs\docs.vbs 
This command affects the protection on your versioned object base.
While this command is running, access to the VOB will be limited.
Pool "sdft" appears to be protected correctly.
Pool "ddft" appears to be protected correctly.
Pool "cdft" appears to be protected correctly.
Protect versioned object base “c:\vobs\docs.vbs"?  [no] yes 
Do you wish to protect the pools that appear not to need protection? [no] no 
VOB ownership:
  owner smg
  group user
Additional groups:
  group Backup Operators
  group Doc Group