Home

How do I

Soft - is your software and documentation
Asset - is something that must be protected
Management - is what we do
Enterprise - is the capability
Computing - is the power
Services - are what we provide


ClearCase and NAS devices “How do I” covers: (Last updated  11-Nov-09)

Ř  Root permissions – when using NAS devices, etc...

Ř  chown_pool/chown_container  - linux support for, etc...

Ř  protectvob – running on NAS devices, etc...

Ř  view_server processes – failure to start on NAS device issue, etc.

Ř  NFS – Linux issues,etc....

Ř  Storage locations – in conjunction with NAS devices

Table of Contents

ClearCase and NAS devices “How do I” covers: (Last updated  11-Nov-09) 1

Table of Contents. 1

Hints and Tips. 2

1.       How do I – understand the special considerations needed when installing and using ClearCase in a NAS environment. 2

Installation.. 2

Creating VOBs and Views. 2

Registering and Tagging of VOBs and Views in a UNIX NAS environment. 2

Re-protection of VOBs. 3

Fix_prot utility.. 3

Root permissions. 4

2.       How do I – understand about Root permissions on Network Attached Storage and ClearCase. 4

ProtectVOB. 5

3.       How do I - run cleartool protectvob for VOBs stored on NAS. 5

View server process. 6

4.       How do I – understand the view server process fails to start for views stored on NAS issue. 6

NFS. 6

5.       How do I – understand how the Linux NFS prevents creation of remote views on NAS problem has been fixed  6

6.       How do I – understand that VOB database corruption can occur if databases are stored on a Network Attached Storage device and the NAS runs out of disk space. 7

Storage Locations and.. 7

7.       How do I - find stranded view-private files in relocated directories. 7

8.       How do I – understand the “Must be run on server storage location's host” issue. 9

 

Hints and Tips

1.        How do I – understand the special considerations needed when installing and using ClearCase in a NAS environment.

Installation

If ClearCase is installed in a UNIX environment as root then:

a)    The VOB storage area on the NAS device has to be NFS exported root to the VOB server hosts

b)    The View storage are on the NAS device has to be NFS exported root to the View server hosts.

c)     The VOB and View storage areas should be NFS exported read write to all other UNIX ClearCase

Creating VOBs and Views

VOBs and Views must be created with the following minimum syntax for them to work in a NAS environment:

            VOBs:

            cleartool mkvob –tag <vob tag> -host <hostname> –hpath <path to .vbs directory> -gpath  <path to .vbs directory> <path to .vbs directory>

 

(i.e. cleartool mkvob –tag /vobs/samecs –host vobserver.sameces –hpath /net/samecs_nas/ccvobstore.samecs.vbs –gpath /net/samecs_nas/ccvobstore.samecs.vbs /net/samecs_nas/ccvobstore.samecs.vbs)

 

Views

cleartool mkview–tag <view tag> -host <hostname> –hpath <path to .vws directory> -gpath  <path to .vws directory> <path to .vws directory>

 

(i.e. cleartool mkview –tag samecs_dev_view –host viewserver.samecs –hpath /net/samecs_nas/ccviewstore.samecs_dev_view.vws –gpath /net/samecs_nas/ccviewstore.samecs_dev_view.vws /net/samecs_nas/ccviewstore.samecs_dev_view.vws)

Registering and Tagging of VOBs and Views in a UNIX NAS environment

VOBs and Views must be Registered and Tagged with a –host –gpath –hpath combination as a minmum to work in a NAS environment. 

 

Register as follows:

 

          VOBs:

            cleartool register –vob –host <hostname> -hpath <path to .vbs directory> <path to .vbs directory>

           

(i.e. cleartool register –vob –host vobserver.sameces –hpath /net/samecs_nas/ccvobstore.samecs.vbs /net/samecs_nas/ccvobstore.samecs.vbs

 

Views:

            cleartool register –view –host <hostname> -hpath <path to .vws directory> <path to .vws directory>

            (i.e. cleartool register –view –host viewserver.sameces –hpath /net/samecs_nas/ccviewstore.samecs_dev_view.vws /net/samecs_nas/ccvobstore.samecs_dev_view.vws

 

Tag as follows:

            VOBs:

cleartool mktag –vob  –tag <VOB tag> –host <hostname> -hpath <path to .vbs directory> <path to .vbs directory>

            (i.e. cleartool mktag –vob –tag /vobs/samecs –public –host vobserver.sameces –gpath /net/samecs_nas/ccvobstore.samecs.vbs /net/samecs_nas/ccvobstore.samecs.vbs

 

Views:

cleartool rmktag –view –tag <view tag> –host <hostname> -hpath <path to .vws directory> <path to .vws directory>

            (i.e. cleartool mktag –view –tag samecs_dev_view –host viewserver.sameces –gpath /net/samecs_nas/ccviewstore.samecs_dev_view.vws /net/samecs_nas/ccvobstore.samecs_dev_view.vws

Re-protection of VOBs

If you want to change the owner or primary group on a VOB there are a number of additional steps when the VOB is stored in a NAS environment. To change the owner/primary group combination on a VOB do the following:

 

            Run cleartool protectvob to change protection on the .vbs files:

 

            cleartool protectvob –chown gbush –chgrp samecs /net/samecs_nas/ccvobstore/samecs.vbs

 

This command will run ok but it will inform you that it has been unable to reprotect the remote storage (storage, derived object and source) pools on the NAS devices, this is the <VOB name>.vbs/s/sdft, <VOB name>.vbs/d/ddft and <VOB name>.vbs/c/cdft. To do this you must run the chown_pool utility from the NAS device. To do this, for example say a NetApp filer, you must export the Filers /vol/etc directory to a ClearCase host. Once you have done this copy the chown_pool and chown_container scripts from the /opt/rational/clearcase/etc directories into the /vol/etc directory. You then need to logon to the ClearCase host with access to the ../etc directory and from within this directory, as root, run the chown_pool command as follows. Note: TRhe chown_pool script calls the chown_container script:

 

            chown_pool <New VOB owner>.<new VOB primarygorup> <path to storage pools)

 

Note 1: You must repeat for the .vbs.s.sdft, .vbs/c/cdft and .vbs/d/ddft pools.

Note 2: If you get a message saying Don't know system of type Linux” when you run chown_pool edit the chow_pool and chown_container scripts as follows:

 

Don't know system of type Linux

Currently these utilities only run on UNIX®.

 

Change request (RFE) RATLC01020018 has been submitted to add support for the chown_pool and chown_container utilities to run on Linux.

chown_pool, and add the following lines into the cases statement:

Linux*)
CD=cd
FIND=find
ECHO=echo
SILENT_GREP="egrepp -q"
;;


chown_container, and add the following lines into the cases statement:

Linux*)
CHOWN=chown
CHMOD=chmod
ECHO=echo
SILENT_GREP="egrep -q"
AWK=awk
;;

Fix_prot utility

If there continue to be protection issues on VOBs and Views then use the fix_prot utility (/opt/rational/clearcase/etc/utils/fix_prot) to fix the permissions.  Note: If you accidentally run chown_pool aginst the .vbs directory rather that the storage pools it will corrupt the VOB, however, this can be fixed using fix_prot.

Root permissions

2.        How do I – understand about Root permissions on Network Attached Storage and ClearCase

This technote explains why the UNIX® or Linux® root account required permission on a Network Attached Storage (NAS) filer in order to create IBM® Rational® ClearCase® VOBs or Views, and how the functionality has been changed to no longer require root access.

 

Symptom

When creating a view with the storage residing on a Network Attached Storage (NAS) device, a warning followed by a pair of errors appear:

cleartool: Warning: Storage pathname "/net/filer/filer/views" may not reside on host "server".

cleartool: Error: Failed to record hostname "server" in storage directory "/net/filer/filer/views/my_view.vws".

cleartool: Error: Unable to create view "/net/filer/filer/views/my_view.vws".

 

Cause

The warning message is expected when NAS (or remote) storage is used, and can be safely ignored. It simply means that ClearCase noticed that the storage resides on an NFS mounted disk instead of a locally attached disk.

The errors are also expected, and are returned because the UNIX (or Linux) root account does not have the proper permissions on the NAS share to create the views.

Note: A similar error is displayed when attempting to create a VOB as well.

Here is a breakdown on why this is happening

1.     After the view/VOB storage is created using cleartool mkview | mkvob command, an RPC call is sent to the admin_server for additional clean up work.

2.     The admin_server records, in the .hostname file under the view/VOB storage directory, the hostname where the view_server or vob_server process is going to run.

3.     The admin_server is started by the albd_server, which runs as root on UNIX and Linux. Hence, the admin_server is also started by and runs as root.

4.     The admin_server fails when it tries to open the .hostname file in the view or VOB storage location because it is coming over NFS as nobody, since root access has not been granted to the NAS share.

5.     After the admin_server fails, control goes back to the cleartool command which proceeds to remove the files it created and prints the errors shown above.

6.     The view_server/vob_server host needs root access on the NAS device because the admin_server uses it to access the private files of the view/VOB, which are owned by the user who is creating the view/VOB.

7.     Since root comes across NFS as nobody, the admin_server fails to access some files of the view because of the restricted permissions.

Defect APAR IC40472 has been submitted to change this behavior so that root does not need to be granted access to the view/VOB storage on a NAS.

 

Resolving the problem

permission on the NAS share to create VOBs or Views.

That means the cleartool mkview and cleartool mkvob commands will execute successfully without root access on the NAS device.

This feature can be obtained in the following ClearCase UNIX and Linux patches (or later):

ClearCase 2003.06

clearcase_p2003.06.00-8

ClearCase 2002.05

clearcase_p2002.05.00-36


VOB Admin operations require root access

The cleartool mkvob command does not require root access after installing the aforementioned patches, however, there are VOB administration operations that still require root to run successfully, such as protectvob, space and dospace.

Notes:

 

Add root access on NAS

The VOB admin operations that are supported on the remote storage require the clients to have root access to the NAS share.

Give root permission to the NAS by adding the following line to the /etc/exports file on the NAS device:

/vol/ccvol/viewstg -root=unix_host

Where unix_host is the hostname of the UNIX (or Linux) server.

 

Protectvob failing on remote storage

Defect APAR PK20192, is open to investigate why cleartool protectvob may fail in a supported configuration for using a NAS device.

As detailed above, VOB administration commands, such as protectvob, must have root access on the remote storage to complete successfully. However, this defect is investigating cases where it is not working as expected.


This defect has been resolved in the following updates:

Windows/UNIX/Linux

7.0.1

7.0.1.0-RATL-RCC-IFIX01

7.0.0.1

7.0.0.1-RATL-RCC-IFIX04


WORKAROUND:

1.     Copy chown_pool and chown_container scripts from /opt/rational/clearcase/etc to the remote device.

IMPORTANT: These scripts currently do not run on Linux. Review technote 1258689 for details the associated workaround.

2.     Login as root on the VOB server

Change directory (cd) to the directory on the filer where the scripts were placed and run the script chown_pool

 

 

ProtectVOB

3.        How do I - run cleartool protectvob for VOBs stored on NAS

Hosting VOB storage on a NAS device is common practice when using Rational ClearCase, but there are some specific considerations with regards to changing protections on the VOB object.

You will need to reprotect the pools on the NAS device prior to running cleartool protectvob against the VOB.

Note: Defect APAR PK20192 has been submitted to resolve the differences in running protectvob on a NAS filer so the additional steps below are no longer required.

INSTRUCTIONS:

1.     Before running cleartool protectvob, you must first copy scripts from the VOB server to a directory on the NAS device.

IMPORTANT: These scripts currently do not run on Linux. Review technote 1258689 for details the associated workaround.

The scripts that you need to copy are:

/opt/rational/clearcase/etc/chown_pool /opt/rational/clearcase/etc/chown_container

Note: You can copy the scripts to any directory on the NAS device that you choose; the location of the scripts is insignificant, as long as they are locally on the NAS device.

2.     Login as root on the VOB server, change directory (cd) to the directory on the NAS device where the scripts were placed, and run the script chown_pool.

The syntax to reprotect a pool to a vobadm user and staff group is

chown_pool  vobadm.staff  /path/to/pool

Example:

#/usr/dir1/tools/chown_pool vobadm.staff sdft

Note: The protections on the pool will be changed accordingly. You must repeat this against each pool, respectively.

Now running cleartool protectvob will work the same for a VOB stored on a NAS device the same as it would for a VOB stored on a local disk.

Example:

cleartool protectvob –chown vobadm -chgrp staff /usr/lib/vob.vbs

Note: You will need to be logged in with account that has root access.

 

View server process

4.        How do I – understand the view server process fails to start for views stored on NAS issue

Why do attempts to create or start an IBM® Rational® ClearCase® view from Linux® that is stored on a Network Attached Storage (NAS) device results in the mkview or setview commands hanging indefinitely.

 

The cause is that the NFS mount option does not include the nolock parameter on the Linux server.


Example NFS mount options (without nolock):
rsize=32768,wsize=32768,hard,intr,rw,bg,nfsvers=3,tcp

Note:
This has been seen only on Linux systems with kernel 2.4 and 2.6. The implementation of the NLM network lock manager in the NFS appears to work differently on UNIX®.


This means that the volume form the NAS device was loaded with the Network Lock Manager (NLM) enabled causing the NLM to lock the view database which in turn disallows the view_server to startup.

 

Solution

The NFS mount option on Linux needs to include the nolock parameter to disable locking on the view storage. This will allow the view server process to Start.

Example NFS mount options (with nolock): rsize=32768,wsize=32768,hard,intr,rw,bg,nolock,nfsvers=3,tcp

NFS

5.        How do I – understand how the Linux NFS prevents creation of remote views on NAS problem has been fixed

Attempts to create a view from a Linux client on a server where NAS is used for view storage results in the following error:

$ cleartool mkview -tag <VIEWTAG> -host <HOST> -gpath <VIEW
STORAGE> -hpath <VIEW STORAGE> <VIEW STORAGE>
cleartool: Warning: Storage pathname "<VIEW STORAGE>" may not reside on host "<HOST>".
cleartool: Warning: Config spec OK, but unable to tell view server to load.
cleartool: Warning: View server should be restarted.
cleartool: Error: Set configuration spec of /usr/atria/default_config_spec failed: no configuration specification set
cleartool: Error: Unable to create view "/<VIEW STORAGE>".

 

Cause

The problem is with the NFS version that is used on Linux.

The current implementation of NFS for Linux does not allow for the creation of remote views (dynamic or snapshot).

Note: UNIX® operating systems will allow the creation of remote views on a NAS device.

Defect APAR IC47149 has been submitted to correct this behavior.

 

Resolving the problem

This defect has been resolved in the following update(s):

7.0.1

ClearCase

Version 7.0.1.1


7.0

ClearCase

Version 7.0.0.2


WORKAROUND:
Without the above update applied, create the views that are stored on the NAS from the Linux view server only.

6.        How do I – understand that VOB database corruption can occur if databases are stored on a Network Attached Storage device and the NAS runs out of disk space

This issue is being investigated under the following APARs:

APAR PK02305 (Solaris only) DB corruption when NETAPP runs out of disk space

IC60774 ClearCase Operations should not corrupt VOBs on low disk space

Note: If only the storage pools and not the database is being stored on the NAS device, corruption will NOT result should the filer run out of space.

 

Resolving the problem

There is no resolution for defect APAR PK02305.

Defect APAR IC60774 has been resolved and a fix is available in ClearCase versions 7.0.0.8 and 7.0.1.7.

Contact IBM Rational Technical Support immediately if you suspect that your Filer has run out of disk space and that your VOBs may be corrupt.

 

Related information

ClearCase supported NAS

Storage Locations and

7.        How do I - find stranded view-private files in relocated directories

Directories containing view-private files were relocated and the view-private files were stranded as the result of that operation.

 

Cause

The view-private files were not moved out of their relocated directories prior to the relocate operation. This information is documented in the IBM Rational ClearCase Administrator's Guide under the topic of Steps to take before relocating elements

 

Resolving the problem

You can use the cleartool recoverview command to gain access to those files.


Use the steps listed in the following example to minimize the risk of permanently losing the view-private files.

1.     Back up the view storage directory for the view. If the files are lost after running any of the below commands, this will be needed as the last possible resort for getting the files back.

2.     Navigate into the view storage directory for the view that has the missing view-private files:

>
cleartool lsview -l MyView
Tag: MyView
 Global path: \\server1\ccstg_d\views\MyView.vws
 Server host: server1
 Region: WindowsRegion
 Active: YES
 View tag uuid:ada010b0.477011d4.9de1.00:c0:4f:8b:b8:77
View on host: server1
View server access path: D:\ClearCase_Storage\views\MyView.vws
View uuid: ada010b0.477011d4.9de1.00:c0:4f:8b:b8:77
View owner: WinDomain\user1

>d:
>cd D:\ClearCase_Storage\views\MyView.vws

3.     Navigate into the .s directory:

>cd .s

4.     Look to see if the "lost+found" exists within the directory. If it does, skip to step 6.

>dir
...
10/29/2008  09:30 AM    <DIR>          lost+found

5.     Run cleartool recoverview -synchronize -vob ... -tag on the specific view:

>cleartool recoverview -synchronize -vob \test1 -tag MyView
Recovering stranded directory <2c002506.e4ef4cae.9304.67:62:21:58:f1:55>
Moved file \\server1\ccstg_d\views\MyView.vws\.s\lost+found\8000068649086488important.txt

6.     Look for the files that you are trying to recover and copy/rename those files to the desired location within the dynamic view.

>dir "lost+found"
Volume in drive D has no label.
Volume Serial Number is 1F09-79C9

Directory of D:\ClearCase_Storage\views\MyView.vws\.s\lost+found

10/29/2008  09:30 AM    <DIR>          .
10/29/2008  09:30 AM    <DIR>          ..
10/29/2008  09:26 AM                27 8000068649086488important.txt
              1 File(s)             27 bytes
              2 Dir(s)  11,505,147,904 bytes free

>copy 8000068649086488important.txt m:\MyView\test2\newdir\important.txt


Note: The file names will be renamed back to their original name as part of the above copy command.

7.     If after running cleartool recoverview you are unable to find the "lost+found" directory, the files or both, search within the .s directory structure for the document files.

8.     If you are unable to find the files after searching the entire .s directory structure, search the backup copy of the VWS for the files.

If you are unable to find the files after searching the entire .s directory structure within the backup copy, you will want to restore the VWS from the previous night's backup to a temporary location and search that copy's entire .s directory structure.

8.        How do I – understand the “Must be run on server storage location's host” issue

Attempts to make a view or VOB storage location (stgloc) on a Network Attached Storage (NAS) device results in the following error:

C:\>cleartool mkstgloc -vob -host NAS_svr -hpath \\NAS_svr\vob -gpath \\NAS_svr\vob NAS_stgloc \\NAS_svr\vob Advertise existing directory "\\NAS_svr\vob"?  [no] y
cleartool: Error: Must be run on server storage location's host.
cleartool: Error: Unable to create server storage location.

 

Cause

The NAS device is incorrectly specified as the HOST in the mkstgloc command.

When creating a storage location (stgloc) on a NAS server, the HOST (-host) specified must be the machine on which the server processes (VOB or view) will run.
Review the ClearCase Administrators Guide on the topic of Creating server storage locations on a NAS device for more information.

 

Resolving the problem

Use the name of a host (a machine with ClearCase installed at the proper patch level) that will serve as a ClearCase view or VOB server. The machine you run this command on MUST be the host that will be the view or VOB server.

C:\>cleartool mkstgloc -vob -host ccvobsvr1 -hpath \\NAS_svr\vob -gpath \\NAS_svr\vob NAS_stgloc \\NAS_svr\vob
Advertised existing Server Storage Location.
Host-local path: ccvobsvr1:\\NAS_svr\vob
Global path:     \\NAS_svr\vob

C:\>cleartool lsstgloc -long
Name: NAS_stgloc
Type: Vob
Region: clearcase_region
Storage Location uuid: fb3544ab.9d7c47e3.b097.25:49:20:a6:bd:ee
Global path: \\NAS_svr\vob
Server host: ccvobsvr1
Server host path: \\NAS_svr\vob

 


This website is published "as is". There is no warranty of any kind (express or implied) as to the operation of our site, the accuracy of the information or the services or products referred to on it. All warranties are excluded as far as permitted at law. Neither we nor any third party will be liable for any losses or damage that may result from use of the website or as a consequence of any inaccuracies in, or any omissions from, the information which it contains.