|
|
Follow these steps to plan and create each new VOB:
Log on to the VOB host. Make sure the host meets the criteria laid out in VOB Server Configuration Guidelines in this chapter. If possible, log on as a user who is a member of the same primary group as all other users who will need access to the VOB.
NOTE: The identity of the user who creates a VOB (user ID, primary group, and umask on UNIX; user ID and primary group on Windows) is used to initialize VOB access permissions. If a VOB is created by a user whose primary group is not the same as the primary group of other users who must access the VOB, you will need to edit the VOB's supplementary group list before those users can access VOB data. See also the protect and protectvob reference pages.
Choose a location for the VOB storage directory. You can use an existing server storage location, create a new server storage location, or use any other directory that has the proper characteristics for good VOB storage as described in Creating VOB Storage Locations.
Choose a VOB-tag. A VOB-tag is a globally unique name by which all clients can refer to a VOB. A VOB-tag should indicate what the VOB contains or is used for. VOB tags exhibit syntactic differences on UNIX and Windows hosts because they must conform to the network naming conventions of each platform.
On UNIX hosts, each ClearCase client mounts the VOB as a file system of type MVFS, so the VOB-tag must be the full pathname of a mountable file system, for example:
/vobs/flex
This pathname usually includes a local mount point (/vobs in the example above) and the name of a mountable file system (/flex in the example above). Unless there is a compelling reason to do otherwise, all clients should mount the VOB at the same local mount point.
On Windows hosts, each ClearCase client host uses the VOB-tag as though it were the name of a Windows directory. In a Windows network, a VOB-tag is the VOB's registered name and also its root directory. A Windows VOB-tag must have exactly one backslash (\), which must be the first character of the VOB-tag (for example, \vob_project2). When activated with the cleartool mount command, a VOB-tag appears as a subdirectory under each view-tag visible on the dynamic-views drive (drive M by default).
Create the VOB. This example explains how to create a VOB using the cleartool command line. You can also create VOBs using various GUI tools on UNIX or Windows.
The following command creates a VOB on Windows with the VOB-tag flex whose storage is in the directory shared as vobstore on a host named pluto, and then returns location and ownership information about the newly created VOB.
cleartool mkvob -tag \flex \\pluto\vobstore\flex.vbs
Host-local path: c:\vobstore\flex.vbs
Global path: \\pluto\vobstore\flex.vbs
VOB ownership:
owner vobadm
group dvt
Whenever you create a VOB, you are prompted to enter a comment, which is stored in an event record (as the event "create versioned object base") in the new VOB's database.
To create a Unified Change Management Project VOB, which can store UCM objects such as baselines, projects, and streams, add the -ucmproject option when you run mkvob.
By default, VOBs are created as private VOBs. Specify -public on the mkvob command line to make a public VOB. Public VOBs can be mounted one at a time using the cleartool mount command, or as a group using the command cleartool mount -all. If you specify -public on the mkvob command line, you are prompted to enter the ClearCase registry password. This password is normally established when ClearCase is installed at a site. If you need to create or change this password, see the rgy_passwd reference page.
In many cases, the VOB-creation process is now complete. The following sections describe special cases and optional adjustments you may want to make to the new VOB.
NOTE: Before any user can access a new VOB on a client host, the following conditions must be met:
The user must have a working view.
To be accessed from a dynamic view, the VOB must be mounted.
To be accessed from a snapshot view, appropriate elements of the VOB must be loaded into the snapshot view.
If you want a VOB to use global types defined in an administrative VOB, you must link the client VOB to the administrative VOB. On Windows, if you use the VOB Creation Wizard to create the VOB, you can specify the administrative VOB at the time of VOB creation. To link a VOB to an administrative VOB after you have created the client VOB, see Linking a Client VOB to an Administrative VOB.
UNIX users can use standard UNIX remote host access methods (telnet, for example, and the X Window System) to access a remote host for purposes of creating a VOB.
If you are using Windows and want to create a view or VOB on a remote machine, ClearCase must have access to information stored in the remote machine's registry. Remote access to the Windows Registry can be restricted by setting security on the key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\Winreg
By default, this key is not present on Windows workstations. This allows the underlying security on the individual keys to control access.
On Windows server hosts, the key is preset by default and may prevent workstations from reading the server's registry. When this is the case, if you are on a remote workstation and attempt to create views or VOBs on the server, the creation fails with the error Invalid argument.
To work around this problem, either remove the key or modify the security on it.
The ClearCase Doctor program, which runs as part of the installation, warns you if the registry key will prevent you from creating views or VOBs on this machine, and optionally can fix it.
This section discusses changes that you may need to make to a new VOB's ownership information.
Access-control issues may arise when all prospective users of the VOB do not belong to the same group. (For detailed information on the topic of user identity and ClearCase access rights, see Chapter 3, Understanding ClearCase Access Controls.)
In organizations where all ClearCase users are members of the same group, all VOBs and views must also belong to the common group. A VOB or view belongs to the principal group of its creator and is fully accessible only to those users who are in the VOB creator's group.
The commands in Step #1-Step #3 here are sufficient to create a VOB in such a situation.
If your organization has multiple user groups, there are special considerations when members of different groups share a VOB:
Users can create an element only if their primary group is in the VOB's group list. If members of more than one group need to create elements, you must add the primary groups of all these users to the VOB's group list. Use the cleartool protectvob command.
If members of more than one group need read access to an element, you must grant read access (and, for a directory, execute access) to others for that element. You must also grant read and execute access to others for all directories in the element's path, up to and including the VOB root directory. Use the cleartool protect command to change permissions for an element.
Users cannot change an element (by checking out a version and checking in a new version), unless they belong to the element's group. The element's group does not have to be the user's primary group; it can be any group the user belongs to.
Note that to create an element, you must be able to check out the containing directory. Thus, a user can create an element only if both of the following are true:
The user's primary group is in the VOB's group list.
Any of the user's groups is the group of the containing directory.
The output from the mkvob command (Step #3 on here) includes a global (networkwide) pathname for the VOB storage directory. This pathname is derived heuristically; that is, it's an intelligent guess. Depending on the accuracy of the guess, you may have some more work to do before the VOB will be accessible to all ClearCase hosts.
Two of the most common reasons this guess can be wrong are unique to UNIX clients.
There may be a global pathname that all ClearCase client hosts can use to access the VOB storage directory, but mkvob's heuristically derived pathname is not the right one. These are the most common reasons:
Use of a nonstandard automount program
Use of a home-grown (perhaps manual) scheme for mounting file systems around the network
In this case, use the mktag command to correct mkvob's guess. For example:
There may be no single global pathname for the VOB storage directory. The most common reason is that the VOB must be accessible to hosts with different operating systems (for example, UNIX and Windows) which have different conventions for global pathnames. In this case, you must partition your network into multiple network regions; each region must have a single global pathname to VOB storage. For background information, see Chapter 26, Administering Regions.
Another possible reason is that the VOB host is a UNIX computer that has multiple network interfaces, each with its own host name. Because only one VOB-tag per region can be associated with a given host storage path, a VOB that has storage on a host with multiple network interfaces must have a tag in each region where the host name is listed if clients in each region need access to the VOB.
If a host named pluto is in region ccregion1, then the mkvob command in Step #3 on here created the VOB-tag in that region. If pluto has a second network interface that uses the host name pluto2, you must make pluto2 a member of a different region, and then create a VOB-tag in that region before clients in the region can access the VOB created in that step.
NOTE: Your -gpath value may need to take into account the use of a nonstandard automount program or other mounting idiosyncrasies within each network region.
This example used the same VOB-tag even though it was initially created in a different region. This is a practice that we encourage you to follow.
By default, the viewroot and VOB file systems are mounted with setUID and setGID disabled; this is the recommended configuration. However, if any hosts at your site must mount these file systems with setUID and setGID enabled (for example, if you run setUID tools from a VOB), you must configure your release area with the site_prep script to allow this. When ClearCase is installed on these hosts, the viewroot and VOB file systems are mounted accordingly. (Alternatively, you can run the change_suid_mounts script on an individual host to enable honoring of setUID programs in VOBs mounted on that host. However, this setting does not persist across installs, and you must stop and restart ClearCase on the host after running the script.) For more information, see the discussion of site_prep in the Installation Guide for the ClearCase Product Family.
As described in the discussion of Creating Remote Storage Pools on UNIX Hosts, you can take advantage of UNIX symbolic links to create remote storage pools on a UNIX VOB server host. Typically, you don't add remote storage pools to a VOB until a disk-space crisis occurs. But as you gain more experience with how your group uses ClearCase and how VOBs grow, you may want to add remote storage pools when you first create a VOB. This approach can help to postpone the disk-space crisis, perhaps even avoid it altogether.
See Creating Remote Storage Pools on UNIX Hosts for the procedure.
|
|
Feedback on the documentation in this site? We welcome any comments!
Copyright © 2001 by Rational Software Corporation. All rights reserved. |
