Most ClearCase sites have only a single ClearCase machine, but some of the larger sites will have multiple VOB servers and view servers. The license server should also be confined to these machines. These ClearCase machines should be considered the property of the ClearCase Administrator, and the ClearCase Administrator should get root access to these systems.
The ClearCase Administrator's $HOME directory should not be placed on the same area or system as other user's $HOME directories. It should be placed upon one of the ClearCase servers in a separate physical disk than where the VOBs or Views are stored. Such a setup help keeps the ClearCase Administrator's files from being modified.
It is highly recommended that the ClearCase Administrator's shell be Kornshell, and that the Kornshell be the default shell for all users. The ClearCase Administrator's account name should be named after the project. This way, if there are more then one project, you can setup a ClearCase Administrator for each project.
The setup of the ClearCase user's HOME directory should look something like this:
| Directory or File | Description |
|---|---|
| .profile | Used by Kornshell as Login Resource File. This should be the standard .profile on your system |
| env | The Env file. This is what the user execute to get a shell containing the ClearCase environment |
| environment | The Environment File. This is what Kornshell sets the ENV variable too when loaded. This file contains the aliases and functions that make ClearCase a bit easier to use. |
| bin | Directory used to store all of the shell and Perl scripts used in the ClearCase environment |
| bin/aix4 | In a multiple machine type environment, there may be some executables or even shell scripts that are machine specific. These directories contain the machine specific binaries and shell scripts used in the ClearCase environment. |
| bin/hpux9 | |
| bin/solaris | |
| bin/sunOS | |
| clearstart | root of the ClearStart data file tree |
| magic | Directory that contains the customized magic files used on this site |
| menus/ | Directory that contains the menus for the utilmenu program |
| triggers | Directory that contains all the scripts and programs used by triggers |
| triggers/mktrtype | Directory that contains the scripts that actually build the triggers in the various VOBs |
The ClearCase Administrator's manual refers to several various types of ClearCase servers, but in most small and medium sites, these are all usually on the same machine which is sometimes genericly refered to as the ClearCase Server. The following are the various types of servers that a ClearCase site might have. Most of these servers can be the same system as the VOB Server with no degregation of service.
One of the servers mentioned here, The View Server, is not mentioned in the ClearCase manual. However, my personal experience has taught me that views should be distributed from a server machines just as VOBs are.
One of the first concepts that most beginning ClearCase Administrators have to grasp is that the VOBs are stored in one area, and the VOB tag is the mount point on the client machine. Most ClearCase users will never realize that there is such a beast as the VOB Server since the files stored in ClearCase appear magically on their system. As far as the ClearCase user is concerned, the files stored in ClearCase are locataed on their machine.
There are other reasons why storing all views in a single location is a good idea. In many sites, the user's $HOME directory are not stored on the local machine, but instead on another server. If this server becomes too busy, access to ClearCase could be slowed. Also many sites have a policy that users are suppose to backup their own $HOME directory which usually means it never does get backed up. Keeping all the views together makes backups easier. It is also easier to rebuild the view registery if all the views are in a single known location. In sites with a single ClearCase server, views may simply be stored on the same system as VOBs.
Unfortunately, there is no way in ClearCase to set as a default where views are stored. Instead, most sites rely on their own version of a mkview shell function or shell script that calls the Cleartool mkview and forces the view directory to be stored on the View Server. If a site uses ClearStart to start and define their view, making sure that all views are stored on the View Server is easier.
The ClearCase Administrator's manual recommends to split your licenses between systems and have multiple ClearCase License Servers, so if one License Server goes down, the other licenses on the other License Server will still be available. However, if you keep your licenses on the same system as you VOB server, this is unnecessary. If your license server did happen to crash, then your VOBs are down anyway, and it wouldn't matter if licenses were unavailable.
If your site has a dedicated license server machine that serves licenses for a variety of software, then this system could serve as the License Server.
Sometimes, because of the way the local network itself is setup, it might be necessary to have more than a single ClearCase Registry. Remember that the directory where the VOBs and Views are stored must be able to be NFS mounted as read/writeable on all the ClearCase client systems. In some networks, there may not be a standard description on how the VOBs directories are to be mounted. For example, if the VOBs are kept on a system called "vobserv", one client machine might insist that the directory where the VOBs are stored should be mounted like this:
While another client machine might insiste that the directory where the VOBs are stored should be mounted like this:
In this case, because one machine insists on using /nfs and another insists on using /net as the NFS mount points, you will have to have two different ClearCase Registry Servers to handle this problem. One for the systems that insist on the mount point of /nfs and the other for the systems that insist on the mount point of /net.
If you do plan on Link and Standard installaitons, then do not download the ClearCase Release CDRom on any of your other ClearCase Servers. Some sites have a very highspeed Application Server that might be a good candidate for the ClearCase Release Server in this situation.
Under the "Standard" installation the ClearCase command line tools are installed on the local machine and so are most shared libraries. This takes about 20 to 30 megs of diskspace to install. Unfortunately, the GUI files and HyperHelp files are accessed from the ClearCase Release Server. If you are like most sites, and install the ClearCase Release on the same system that is serving as your VOB or View server, you will find running the GUI will slow down you and the access to your VOBs.
Under the "Full Copy" installation, all ClearCase files are stored on the user's machine. Unfortunately, this might take anywhere between 90 to 110megs of diskspace. However, it is probably the best way to install ClearCase, and if diskspace is available, the way to install it. Otherwise, you might prefer the "Mounted" method.
Under this method, the ClearCase files (except for the files needed to modify the Kernel and to start up ClearCase daemons) are linked back to the installation area on the ClearCase Release Server. Although less than a single meg is needed for this type of installation, if the release area is on the same system that is also attempting to serve your VOBs, you will find running certain ClearCase tasks will greatly slow down your network and your access to the VOBs
Under this method, the ClearCase files are completely installed on another system via the Full Copy Installation method, then that area will be mounted on the client machine being installed using the Mounted method. This method is prefered over the Linked Installation method. If done correctly, you can configure the systems to mount to other ClearCase areas on other client machines.
Sometimes little used ClearCase machines (like a machine sitting in a demo room) will use the Mounted installation to another user's ClearCase system.
Basically, a Mounted Installation is very similar to size and operation of the Linked installation, but a Mounted installation does not have to access the disk on the ClearCase Release Server. Since almost all sites use the same system to store their VOBs as their ClearCase release, this can be a very advantage.
The name of the VOB directory on the VOB server should match mounting point on the user's machine with an additional extension of *.vbs on the end. You should also setup one additional VOB to be used exclusively for the Administration VOB. This VOB should be called "AdminVOB". The following is an example of how two projects would be setup on the same VOB server. Note that they both have their own AdminVOB, and each project also has its own ClearCase Administrative user:
| VOB STORAGE AREA | VOB MOUNT POINT (tag) |
| /net/vobstore/demos/src.vbs | /demos/src |
| /net/vobstore/demos/bin.vbs | /demos/bin |
| /net/vobstore/demos/lib.vbs | /demos/lib |
| /net/vobstore/demos/include.vbs | /demos/include |
| /net/vobstore/demos/AdminVOB.vbs | /demos/AdminVOB |
| Name of ClearCase Administrator for project DEMOS: demos | |
| VOB STORAGE AREA | VOB MOUNT POINT (tag) |
|---|---|
| /net/vobstore/somed/src.vbs | /somed/src |
| /net/vobstore/somed/bin.vbs | /somed/bin |
| /net/vobstore/somed/lib.vbs | /somed/lib |
| /net/vobstore/somed/include.vbs | /somed/include |
| /net/vobstore/somed/AdminVOB.vbs | /somed/AdminVOB |
| Name of ClearCase Administrator for project SOMED: somed/I> | |