| Problem |
| After running cleartool rmview -uuid in an IBM® Rational® ClearCase® VOB, checkout references to the view are still appearing. This technote explains how to synchronize the view with the VOB in order to resolve this problem. |
| Solution |
| Use the cleartool recoverview command to try to resynchronize the view and the VOB(s) if the steps outlined in technote 1122515 do not yield positive results.
The recoverview command repairs a view database and the associated private storage area of a dynamic view. (A snapshot view has no private storage in the same sense as a dynamic view has which is why recoverview will not work on a snapshot view.) Typically, you use this command after a system crash or similar mishap (specifically related to the rmview -uuid scenario). 1. Open a command prompt 2. Issue the following recoverview command:
This command will try and resynchronize the view and the VOB to the status of the check outs. Review the ClearCase Reference Guide on the topic of recoverview (cleartool man recoverview) for more information.
IMPORTANT NOTE: Before proceeding, please understand that there is the possibility of losing view private files in said view as noted in the Reference Guide entry for recoverview. If the recoverview fails to resynchronize said view to the VOB, removing and recreating the view will be necessary.
If the references are still in the VOB after running recoverview, see technote 1146797. |
About running recoverview when referenced checkouts still exist in a VOB even after running cleartool rmview -uuid
What to do when cleartool rmview -uuid does not remove view references
| |||||||||||||
| Cause | |||||||||||||
| In ClearCase 7.0, defects APAR PK38852 and APAR PK50737 have been submitted to address the concern of rmview -uuid not removing all the references from the view. This behavior has been reported to occur when issuing cleartool rmview with or without the -uuid switch.
Attempts to remove a view results in the following error: %>cleartool rmview -force -vob /vobs/test -uuid c05adaeb.45aa11da.92b5.00:01:80:f7:8d:2c cleartool: Warning: Looking for a broken Config Record that might still have some references to the view. This might take a long time depending of the number of derived objects and configuration records within the VOB. Cause 2 The uuid typed in the command syntax is incorrect. Cause 3 In ClearCase 2003.06 defect APAR PK45597 has been opened to address the issue described below: When attempting to remove view references from a PVOB using cleartool rmview -uuid, a silent failure (with the tool claiming a successful removal) will occur if the view is associated with a UCM stream or activity mastered at a remote replica. | |||||||||||||
| Answer | |||||||||||||
| Defects APAR PK38852 and APAR PK50737 have been resolved in the following ClearCase 7.x updates; however, the update alone will not resolve the issue. The solution will not be complete until the updates are applied and the environment variable below is configured on the proper hosts. Note: The solution was implemented in this fashion to prevent unknown RPC calls being received by a lower versioned VOB or View server that would fill up with error logs regarding the unknown RPC calls. The following steps are required in order to eliminate the view removal issues.
Windows
UNIX/Linux
Note: If you are running the rmview command from the VOB server, the variable is still required to be set on the host. IMPORTANT: Do not use the -all option if you use the -uuid option unless ALL of your VOB servers are on the required fix mentioned above and have the variable set. 2003.06.00 Host Considerations There are no updates for 2003.06.00 servers or clients experiencing this issue.
WORKAROUND 1: To prevent this issue from occurring on Microsoft® Windows®, try using the graphical remove view functionality, instead of the command line interface as this issue is only known to occur with cleartool rmview with or without the -uuid switch. WORKAROUND 2: If after running the instructions described in technote 1122515 the VOB still holds checkouts to your dynamic views, attempt to run recoverview on the referenced view as instructed in technote 1127003. If checkout/checkin to the deleted view is blocking your work, the existing checkout can be converted to UNRESERVED by the element owner or VOB owner by using the following command: cleartool unreserve -view Review technote 1129391 for more information. Solution 2 Be sure to check the spelling of the UUID in the command. Given that this is a specific string that must be entered exactly as seen, it is best to copy and paste the uuid, rather than typing it manually. Solution 3 There is no solution for APAR PK45597 at this time. This issue will not prevent the removal of the view itself from the view server, but the references to the view will still be left in the PVOB's database. Workaround: The view can be removed using cleartool rmview -uuid at the site that masters the stream and/or activity the view is associated with. Determining the stream in question will be non-trivial unless view and stream names share a common naming convention (which is the default when joining a project). |
About the lost+found directory
Answer
Why Elements Are Moved to the VOB lost+found Directory
Removing Objects from lost+found
Determining the UCM component to which an element in lost+found belongs
Why Elements Are Moved to the VOB lost+found Directory
An object will be placed in a VOB's lost+found directory when the parent directory namespace has been removed (in which case there is no longer a context in which to show the object) or altered such that it's contents have no reference in a previous directory version. This can happen under the following circumstances:
1. The object's parent directory element is removed with rmelem and there are no other hardlinks to the object elsewhere in the VOB.
Example:
%>cleartool rmelem dir1
CAUTION! This will destroy the element, all its branches and versions,
including all data, meta-data and history, and will remove the element
from all directory versions that now contain it. Once you destroy the
element, there will be no way to restore it to its current state.
If you want to preserve the element, but remove references to it from
future directory versions, use the "rmname" command.
Element "dir1" has 1 branches, 2 versions, and is entered
in 1 directory versions.
Destroy element? [no] y
cleartool: Warning: Object "foo.c" no longer referenced.
cleartool: Warning: Moving object to vob lost+found directory as "foo.c.986de380d90b479db49316560deba2f2".
Removed element "dir1".
2. The parent directory is checked out, files and/or directories are added, and then the parent directory is unchecked out.
Example:
%>cleartool co -nc dir1
Checked out "dir1" from version "/main/7".
%>cleartool mkelem -ci -nc foo.c
Created element "foo.c" (type "text_file").
Checked in "foo.c" version "/main/1".
%>cleartool unco dir1
cleartool: Warning: Object "foo.c" no longer referenced.
cleartool: Warning: Moving object to vob lost+found directory as
"foo.c.c7592f61ab0b11db83b5000180f96245".
Checkout cancelled for "dir1".
3. The parent directory is checked out, files and/or directories are added, and then the file or directory has its name removed (rmname) before the parent directory is checked in.
Example:
%>cleartool co -nc dir1
Checked out "dir1" from version "/main/7".
%>cleartool mkelem -ci -nc foo.c
Created element "foo.c" (type "text_file").
Checked in "foo.c" version "/main/1".
%>cleartool rmname foo.c
cleartool: Warning: Object "foo.c" no longer referenced.
cleartool: Warning: Moving object to vob lost+found directory as
"foo.c.c7592f61ab0b11db83b5000180f96245".
Removed "foo.c".
When an object is moved to the lost+found root directory its OID (object ID) is appended to the original filename. For example:
Before: foo.c
After: foo.c.282d5d339cba4043905da6ca201e1f3d
If a directory element is moved to lost+found, all of the subdirectories and elements it contains are moved along with it (the directory structure is kept intact). Since these contents are not located in the lost+found root, however, they are not renamed in the manner described above.
Removing Objects from lost+found
Before taking any steps to clean out the VOB's lost+found, please make a backup of the VOB as a safeguard.
There are two possible ways to remove an object from the root of the lost+found:
1. The object can be moved to a new location in the VOB using the cleartool mv command
2. The object can be permanently deleted from the VOB.
# To move the object to a new location, check out the parent directory of the new location and use the cleartool mv
avoid checkin errors during a build in clearcase
You can check out, build, and check in during a build, however, the checked in version will not be seen during that build's session. An example makefile following the below logic will cause the existing build not to see newly checkedin files:
foo:
cleartool checkout -nc $@
build $@
cleartool checkin -nc $@
The build will checkout foo, build it, and check foo back in, but will warn that the newly checked in version is not selected by the view, with a warning such as the following:
cleartool: Warning: Version checked in is not selected by view.
Checked in "foo" version "/main/2".
If the object that is being checked in is a directory, the error will look like this:
cleartool: Warning: Operation "view_readdir_ext" failed: directory not selected in configuration specification.
cleartool: Warning: VOB updated, but view update of uncheckout of "directory_name" failed: directory not selected in configuration specification.
cleartool: Warning: Version checked in is not selected by view.
Checked in "directory_name" version "/main/9".
To avoid any possible problems, merely put off the checkin until the entire build has finished.
For example:
.c.o:
cleartool checkout $@
cc -c $<
all: foo checkin
foo: foo.o
cc -o $@ foo.o
checkin:
cleartool checkin -nc foo foo.o
convert a VOB to an AdminVOB
To change a VOB into an Administrative VOB, you must create an AdminVOB hyperlink from a client VOB to the VOB that you want to act as the AdminVOB.
Note: This can be used to change a newly created VOB or a VOB that was previously an AdminVOB into an AdminVOB.
Example:
There are presently 3 standard VOBs:
/vobs/dev1
/vobs/dev2
/vobs/dev3
To make /vobs/dev3 into an AdminVOB for /vobs/dev1 and /vobs/dev2:
1. Make sure all 3 VOBs are mounted and accessible.
2. Log in as the VOB owner.
3. Set a view and change directory (cd) into /vobs/dev1
%> cleartool setview sarge
%> cd /vobs/dev1
4. Make the AdminVOB hyperlink:
%> cleartool mkhlink -c "link to AdminVOB /vobs/dev3" AdminVOB
vob:/vobs/dev1 vob:/vobs/dev3
Created hyperlink "AdminVOB@40@/vobs/dev1".
5. A describe of the VOB, /vobs/dev1, will now show the hyperlink:
%> cleartool describe -long vob:/vobs/dev1
versioned object base "/vobs/dev1"
created 05-Mar-02.11:43:16 by Sarge(sarge.user@bunker)
VOB family feature level: 3
VOB storage host:pathname
"bunker:/export/home/sarge/store/dev1.vbs"
VOB storage global pathname
"/net/bunker/export/home/sarge/store/dev1.vbs"
database schema version: 53
VOB ownership:
owner atria.com/sarge
group atria.com/user
Additional groups:
group atria.com/army
Attributes:
FeatureLevel = 3
Hyperlinks:
AdminVOB@40@/vobs/dev1 -> vob:/vobs/dev3
rgy_upgrade
| This technote explains what happens as a result of running the IBM® Rational® ClearCase MultiSite® rgy_upgrade utility on a registry or VOB server. |
| Solution |
The utility rgy_upgrade is automatically run during an upgrade to 2003.06.14 or later to configure the ClearCase registry and VOB servers to support the new MultiSite synchronization manager and the MultiSite Administration WEB Console functionality. Note: This utility will be available after installing Service Release 4 (2003.06.14) or later on Windows® or patches multisite_p2003.06.00-6 or multisite_p2003.06.10-6 or later on UNIX® or Linux®. When the rgy_upgrade utility is run on a registry and or VOB server the following actions are taken:
Refer to the MultiSite Administration WEB Console and Synchronization Manager Documentation for mor details. |
Identify the snapshot view root location
| |||
| Answer | |||
| Unless the view was created in the default manner of having view storage directly under the view root, there is currently no command to use which can determine the location (of the view root). The cleartool lsview -long command only lists the view tag and view storage, not the view root. Change request (RFE) RATLC00606966 has been submitted to address this functionality. However, the decision was made by Product Management to exclude the resolution of this enhancement from future upgrades and releases due to the significant architectural changes required to implement the solution. Locating View Root Directories
This feature of Rational ClearCase allows you to store the view root in a location that is convenient as well as separate from the view storage, which is tracked by the application. ADVISORY: When managing view roots in this manner, it is recommended that you establish a convention for storing the view roots in a common path or central location to simplify administration.
Here are some methods for locating view root directories: UNIX/LINUX & WINDOWS
UNIX/LINUX ONLY
Note: ClearCase operations use information from this file. If this file is deleted or corrupted, the information must be regenerated for each snapshot view that is used. To do so, update the view with either of the following commands: cleartool update cleartool update -print
cleartool: Warning: Unable to register new snapshot view: The file access permissions do not allow the specified action. WINDOWS ONLY 1. The Snapshot view update tool presents a pull-down list of these views.
2. Edit View Properties displays the view root path:
|
Updating the Windows ClearCase ALBD Password
A utility to change user account passwords.
Michael Nellis (mrnellis@us.ibm.com), Senior Technical Service Specialist, IBM
In any IBM® Rational® ClearCase® environment that uses Microsoft® Windows®, ClearCase requires a Windows user account to start the ClearCase Atria Location Broker Daemon (ALBD) service. This article explains one way of changing the ALBD password, which you typically must do frequently for security.
One of the tasks of IBM® Rational® ClearCase® administrators when working in Microsoft® Windows® environments is managing the account required to start the IBM Rational ClearCase Atria Location Broker Daemon (ALBD) service. Most companies' security policies require that all account passwords must change periodically, typically about every 90 days, and the ClearCase password is usually no exception, of course. Changing the password every 90 days is relatively easy, but the fact that this change must now be propagated to tens, hundreds, or even thousands of Windows clients can make it a difficult and time-consuming task. There are numerous ways to automate this task, though, and each has its own pros and cons. This article explains one method (see Resources for an article about alternatives).
IMPORTANT NOTICE: Please read the license.txt file that is part of the zip package for this utility.
This utility is provided "as-is" and there is no support provided for this by IBM Rational. This utility may modify the Microsoft Windows registry settings as well as potentially change a Microsoft Service process definition. Changing these registry and service settings through the use of this utility involves some element of risk and may result in problems and errors occuring during the execution of Windows. Anyone running this utility needs to be aware of the potential risks.
Rational ClearCase has three services, or processes, that must run in the background on a Microsoft Windows platform:
- The lock manager (lockmgr)
- The credentials manager (cccredmgr)
- The ALBD service
The last one, the ALBD service, requires a Windows user account with ClearCase privileges to function properly. In the definition of this service, during ClearCase installation, the ClearCase administrator must specify the name of this privileged account, the password, the Windows domain, and the Windows group for this account. In some cases, only the password will ever change for this account. In other installations, there may be a requirement to change another or all of these values.
Note: To change these values, you need administrator's rights on the Windows client machine.
A utility to automate password changes
To make changing multiple ClearCase passwords easier, you can use a utility (ccalbdpw.exe) that resides on the client software. The utility reads a sitedefs.dat file on a network release area and simply updates the Windows registry information for the ALBD service. The utility must be executed using an account that has permission to change the registry values.
To use this utility, you follow this three-step process:
- Change the Windows ALBD service account password.
- Update the ClearCase network release area with the new password by copying the
sitedefs.datfile to theSETUPdirectory in the network release area. - Run the password update utility (
ccalbdpw.exe) on each client.
The ccalbdpw.exe utility reads the new password value from the SETUP\sitedefs.dat file and updates the Windows registry value. The new password value takes effect when you reboot the machine or when you stop and restart the ClearCase services.
Advantages of the using this utility
The advantages of this utility are that the password is secure and that the utility works with the existing ClearCase installation information on your workstation. If you prefer, you can modify the script for this utility to run on every reboot of a workstation and automatically pick up any changes.
To make maintenance tasks of the ALBD service account easier, this script also enables you to change this data in the Windows registry:
- Password
- ALBD service account name
- ALBD group name
- Path to the network release area
This script was designed to be used with Microsoft Systems Management Server (SMS) and other installation or upgrade tools. It also provides a detailed error message if a problem occurs.
Contents of the compressed utility file
This password change utility currently supports Rational ClearCase Windows version 2003.06 and version 7. The .zip file included as a download with this article contains these elements:
- A Windows executable file for the utility
- A
readme.txtfile with a detailed instructions and a complete listing of all error codes - A
license.txtfile that indicates that this is an as-is utility; therefore, does not include IBM Rational technical support
common issues/mistakes in IBM Rational ClearCase
I can't see the latest version of file.xyz.
A classic. Typically, either the version containing the desired changes is CHECKEDOUT to a different view, or the user is in a view whose config spec doesn't select the "latest" version the user is looking for. Often the problem is that the term "latest version" is ambiguous. Ask the user whether he means latest in production, QA, in his development sub-team, etc.
Officially, an Eclipsed element is obscured by a "view-private" object. A more user-friendly explanation, however, is that a dynamic view isn't able to delete the local copy of a file after the user checked it in. A third-party tool locking the local file and preventing ClearCase from deleting it during check-in usually causes this. Commonly, an Eclipse happens when using the ClearCase and MS Word integration, or with certain IDEs.
The solution for "un-eclipsing" an element is simple. Rename the local copy. After the element is renamed you will observe that the "Eclipsed" icon no longer appears in ClearCase Explorer.
What does "CHECKEDOUT but removed" mean?
(Hint: it's the converse of "Eclipsed.") This problem occurs if an element has been checked out and the checked out object is then deleted using Windows or UNIX/Linux commands (such as delete/rm or rmdir, or their GUI equivalents). Assuming the user wants the element back, the solution to this problem is to un-checkout the file or directory.
Another classic. There are several possible resolutions:
Make sure that the user created the element using Add to Source Control from the menu selection (or using the cleartool mkelem command).
Check in the element that was added, making sure the directory where the elements have been added has been checked in.
Make sure other users have a view with a config spec that allows their view(s) to see the new element.
Make sure other users have updated their snapshot views.
Why do I need to use branches? Why can't I just do all my work in the "main" branch?
Certainly, you can work in just the "main" branch. However, working in just one main-line branch limits a project by allowing ONLY checkouts from the baseline. This means that two people can't work on the same file at the same time without interfering with each other when it comes time to deliver their work. Do you really want to take the chance every time you try to deliver a bug fix to your team leader that you'll have to call up another developer and coordinate a bunch of unrelated (and probably incomplete) changes? If you use multiple branches, you can check out and check in to your heart's content and not worry about conflicting changes with another user until it makes sense to.
Why do I have to create a "label type" before I put the label on my element?
(This answer covers all of the metadata types in ClearCase.) Essentially, label types allow you to work easily with labels at either an individual (per-file) or group level. If you didn't have label types, you couldn't easily lock or delete a label; you'd have to lock or delete all the individual labels with the same name on every file they're applied to.
(UNIX) I set my directory to /devvob but I don't see any files or directories in it!
The most common causes of this behavior are: The VOB has not been mounted and/or the view has not been started or set.
The solution? Mount the VOB and/or set the view.
(Windows) I can't find the devvob directory!
The user probably hasn't mounted the VOB. The solution? Mount the VOB from the command line or from the Windows or ClearCase explorer.
I tried to edit the file but the error states that it's a "read-only" file system.
This error occurs when an element has not been checked out. The solution? Just check out the element.
I checked out a file but I accidentally deleted it. Is it gone? How do I get it back?
Well, unfortunately, the changes you made to the file while it was checked out are gone unless you have backup procedures in place that run very frequently and back up view-private files. Otherwise, you can't get the changes you made to the file back. You must treat this as a "Checked out but removed" problem.
Yes, ClearCase is integrated with MS Word versions 97, 2000, and XP. Activate the integration by clicking the Start button and go to Programs > Rational ClearCase Administration > Integrations > Microsoft Word Integration Configuration. Click on "Yes" to the displayed panes.
How can I see just Final Release Version 1.0.3 that is identified with the label "R1.0.3.FINAL"?
Create or modify a view and set the config spec to:
element * R1.0.3.FINAL. This label will show ONLY elements that have been labeled R1.0.3.FINAL.
How can I work at home when I can't get a ClearCase license?
There are two common ways to do so:
-
create a snapshot view on your laptop and synchronize with the latest work in the code repositories, or
-
use ClearCase Web to allow access to the repositories. This method of access provides the user with many of the capabilities that are available as if the user was connected to the development environment. The user can access ClearCase artifacts from any location that is Internet accessible if the administrator allows this.
How can I keep others from changing my work?
It depends on whom you mean by "others." If you mean people outside your primary or supplementary groups in Windows or UNIX/Linux, just remove "other" permissions on the things in ClearCase you want to protect. You use the cleartool protect chmod o-w command to do so.
If those you don't want to make changes are within any of your groups, however, you can't prevent them from making new versions of elements you own via ClearCase permissions. You must lock the elements you don't wish to be changed. To do so, use this command on the elements you wish to protect:
cleartool lock -nusers your-user-id command on the elements you want to protect. This will allow only you (and ClearCase administrators) to do anything to change this element.
Let's call him ET. Example: the user removes a file, typically using the command rmname, realizes his mistake and creates a new element with the same name -- we present you your Evil Twin. Versions of the older element still exist in the older versions of the directory. This creates much confusion when working with baselines before and after ET was created.
How to undo ET: If the user realizes the mistake, he should contact the ClearCase Admin to fix the problem. The ClearCase Admin should run a subtractive merge on the file's resident directory. If the user already recreated the element:
- rename the element
- run the subtractive merge
- checkout the recovered file
- edit the recovered file according to the changes in the renamed file
- last step: delete the renamed file so it does not cause any more problems.
How to prevent ET: There are solutions to the ET problem available from many locations, including here on the Rational Developer Network. These solutions are implemented as pre-operational triggers during a mkelem or add files to source control operation. This is probably the single most important trigger to have in a VOB.
What does "trivial merge" mean? How about "copy merge?"
These two terms are synonymous. Say you work on an element on one branch and merge your work back to another branch. If no one has changed the element on the other branch in the meantime (i.e. since you first began to work on the element on your branch), then there are no conflicts to resolve, and ClearCase can just "copy" your new version of the element back to the other branch. Hence the terms "copy merge" and "trivial merge."
How do I notify my team when a file has been checked in?
The solution is to apply a notification trigger to the VOB that will fire based on rules you define. The rules are implemented in a script fired by the trigger.
It's very easy to create an "edit" option -- or any other option, for that matter -- within a right-click menu in ClearCase Explorer. Just use the ClearCase Context Menu Editor (available under Rational ClearCase on the Start menu). The whole purpose of this tool is to extend the capabilities in the ClearCase "right-click" menus on elements. Just specify the new menu choice and what it should do (e.g. bring up FrontPage), and deploy this menu to every workstation needing it.
(This is only possible with snapshot views) If you want to change the structure of directories under ClearCase control, you have to do so through ClearCase. Otherwise, your local structure won't match that in the VOB, and the next update you do of your snapshot view will wreak havoc with your local environment. Perform your moves and renames using the ClearCase GUI or use the cleartool mv command, and ClearCase will assure that these changes are known and tracked.
Snapshot views are static windows into the repository. This means that if you want the window to change, then you must Update the View, or portions thereof. If ClearCase automatically updated the entire view every time, users wouldn't have the choice to narrow the load rules to reduce load times. You can choose whether all or part of a snapshot view is updated by altering the view's load rules. It is up to the user to take care and update the Snapshot view appropriately to keep up to date with the changes that occur in a dynamically changing environment.
Don't want to use the command-line interface for large file migrations? No problem. Here's how to move those files in your existing Windows environment.
- In ClearCase Explorer or Windows Explorer, move the files or folders to the VOB directory that will serve as the parent directory.
- Select the items to add to source control. Then right-click.
- We recommend that you select items farthest from the root of the directory tree: the Add to Source Control command for any given file or directory also adds any parent directories (up to the VOB root directory) that are not already elements.
- On the ClearCase shortcut menu, click Add to Source Control.
You can choose the version you want from within the merge tool, either graphically or via the command line.
About maximum groups on UNIX and Linux for use with ClearCase
The maximum number of groups a user can belong to on UNIX or Linux is 16.
The 16 group limitation is not controlled by ClearCase, rather by the architecture from which the RFC (Request for Comments) for RPC (Remote Procedure Call) Standards Track emanates.
The original RFC for RPC was RFC#1050 published in 1988 which had a limitation of 10 additional GID's:
9.2 UNIX Authentication
The caller of a remote procedure may wish to identify himself as he
is identified on a UNIX(tm) system. The value of the credential's
discriminant of an RPC call message is "AUTH_UNIX". The bytes of the
credential's opaque body encode the following structure:
struct auth_unix {
unsigned int stamp;
string machinename<255>;
unsigned int uid;
unsigned int gid;
unsigned int gids<10>;
};
This was updated and superseded by RFC#1831, published in 1995 which increased the number of additional GID's to 16.
APPENDIX A: SYSTEM AUTHENTICATION
The client may wish to identify itself, for example, as it is
identified on a UNIX(tm) system. The flavor of the client credential
is "AUTH_SYS". The opaque data constituting the credential encodes
the following structure:
struct authsys_parms {
unsigned int stamp;
string machinename<255>;
unsigned int uid;
unsigned int gid;
unsigned int gids<16>;
};
APAR PK10876 has been submitted to address this behavior.
Answer
This defect, APAR PK10876, has been resolved through use of a workaround in ClearCase 7.0.
WORKAROUND:
You will be required to use a wrapper utility to process any ClearCase commands when a user is a member of more than 16 groups.
DOCUMENTATION:
setgroup-swap
Allows users who are a member of more than 16 groups to use ClearCase commands.
Applicability
Product
Command type
ClearCase executable
Platform
UNIX and Linux
Synopsis
Use ClearCase functionality when user membership exceeds 16 groups.
Description
Due to the RPC limitation imposed by UNIX and Linux, users who are members of more than 16 groups cannot properly process RPC calls for ClearCase use. To work around this issue, you can use the setgroup-swap utility (found in the /opt/rational/clearcase/etc/utils directory) to work in conjunction with the CLEARCASE_GROUPS variable to define an ordered list of groups for ClearCase to package and process RPC calls in accordance with RFC#1831 guidelines and restrictions.
Restrictions
Identities
You must have one of the following identities:
* root (UNIX and Linux)
Note: This identity is required to chmod the setgroup-swap utility to apply the setuid permission. After that, no special identities are required.
Options and arguments
By default setgroup-swap does not have any options.
The only arguments that are required is the ClearCase command you wish to run.
Instructions
1. Ensure ClearCase 7.0 is installed
2. Ensure the setgroup-swap executable is owned by root and the setuid bit is set to root.
3. Ensure the setgroup-swap executable is in the path for the shell.
Note: Use the appropriate shell syntax for your environment to set the PATH variable.
4. Set the CLEARCASE_GROUPS variable to define which of the 16 groups you want to use with ClearCase.
Note: Use the appropriate shell syntax for your environment and set the CLEARCASE_GROUPS variable as a colon-separated list.
5. Run the setgroup-swap before the ClearCase command.
Example
% cleartool -ver
ClearCase version 7.0.0 (Fri May 05 12:38:05 EDT 2006)
7.0.0.0-RATL-RCC-IFIX01 (Thu Jun 29 23:33:44 EDT 2006)
@(#) MVFS version 7.0.0.0-IFIX01 (Tue May 16 00:02:04 2006)
cleartool 7.0.0.0 (Fri Apr 21 00:16:51 EDT 2006)
db_server 7.0.0.0 (Fri Apr 21 00:15:07 EDT 2006)
VOB database schema version: 54
% pwd
/opt/rational/clearcase/sun5/etc/utils
% ls -al setgroup-swap
-r-xr-xr-x 1 root other 7676 Dec 2 2005 setgroup-swap
% chmod 4555 setgroup-swap
% ls -al setgroup-swap
-r-sr-xr-x 1 root other 7676 Dec 2 2005 setgroup-swap
% PATH=$PATH:/opt/rational/clearcase/
export PATH
% CLEARCASE_GROUPS="group1:group2:group3:group4:group5:group6:^
group7:group8:group9:group10:group11:group12:group13:^
group14:group15:group16";
export CLEARCASE_GROUPS
% setgroup-swap
usage: ./setgroup-swap
CLEARCASE_GROUPS EV to reorganize groups)
% setgroup-swap cleartool mkview -tag testview -host testhost^
-gpath /net/homes/testuser/testview.vws -hpath^
/net/homes/testuser/testview.vws ^
/net/homes/testuser/testview.vws
About maximum groups on UNIX and Linux for use with ClearCase
The maximum number of groups a user can belong to on UNIX or Linux is 16.
The 16 group limitation is not controlled by ClearCase, rather by the architecture from which the RFC (Request for Comments) for RPC (Remote Procedure Call) Standards Track emanates.
The original RFC for RPC was RFC#1050 published in 1988 which had a limitation of 10 additional GID's:
9.2 UNIX Authentication
The caller of a remote procedure may wish to identify himself as he
is identified on a UNIX(tm) system. The value of the credential's
discriminant of an RPC call message is "AUTH_UNIX". The bytes of the
credential's opaque body encode the following structure:
struct auth_unix {
unsigned int stamp;
string machinename<255>;
unsigned int uid;
unsigned int gid;
unsigned int gids<10>;
};
This was updated and superseded by RFC#1831, published in 1995 which increased the number of additional GID's to 16.
APPENDIX A: SYSTEM AUTHENTICATION
The client may wish to identify itself, for example, as it is
identified on a UNIX(tm) system. The flavor of the client credential
is "AUTH_SYS". The opaque data constituting the credential encodes
the following structure:
struct authsys_parms {
unsigned int stamp;
string machinename<255>;
unsigned int uid;
unsigned int gid;
unsigned int gids<16>;
};
APAR PK10876 has been submitted to address this behavior.
Answer
This defect, APAR PK10876, has been resolved through use of a workaround in ClearCase 7.0.
WORKAROUND:
You will be required to use a wrapper utility to process any ClearCase commands when a user is a member of more than 16 groups.
DOCUMENTATION:
setgroup-swap
Allows users who are a member of more than 16 groups to use ClearCase commands.
Applicability
Product
Command type
ClearCase executable
Platform
UNIX and Linux
Synopsis
Use ClearCase functionality when user membership exceeds 16 groups.
Description
Due to the RPC limitation imposed by UNIX and Linux, users who are members of more than 16 groups cannot properly process RPC calls for ClearCase use. To work around this issue, you can use the setgroup-swap utility (found in the /opt/rational/clearcase/etc/utils directory) to work in conjunction with the CLEARCASE_GROUPS variable to define an ordered list of groups for ClearCase to package and process RPC calls in accordance with RFC#1831 guidelines and restrictions.
Restrictions
Identities
You must have one of the following identities:
* root (UNIX and Linux)
Note: This identity is required to chmod the setgroup-swap utility to apply the setuid permission. After that, no special identities are required.
Options and arguments
By default setgroup-swap does not have any options.
The only arguments that are required is the ClearCase command you wish to run.
Instructions
1. Ensure ClearCase 7.0 is installed
2. Ensure the setgroup-swap executable is owned by root and the setuid bit is set to root.
3. Ensure the setgroup-swap executable is in the path for the shell.
Note: Use the appropriate shell syntax for your environment to set the PATH variable.
4. Set the CLEARCASE_GROUPS variable to define which of the 16 groups you want to use with ClearCase.
Note: Use the appropriate shell syntax for your environment and set the CLEARCASE_GROUPS variable as a colon-separated list.
5. Run the setgroup-swap before the ClearCase command.
Example
% cleartool -ver
ClearCase version 7.0.0 (Fri May 05 12:38:05 EDT 2006)
7.0.0.0-RATL-RCC-IFIX01 (Thu Jun 29 23:33:44 EDT 2006)
@(#) MVFS version 7.0.0.0-IFIX01 (Tue May 16 00:02:04 2006)
cleartool 7.0.0.0 (Fri Apr 21 00:16:51 EDT 2006)
db_server 7.0.0.0 (Fri Apr 21 00:15:07 EDT 2006)
VOB database schema version: 54
% pwd
/opt/rational/clearcase/sun5/etc/utils
% ls -al setgroup-swap
-r-xr-xr-x 1 root other 7676 Dec 2 2005 setgroup-swap
% chmod 4555 setgroup-swap
% ls -al setgroup-swap
-r-sr-xr-x 1 root other 7676 Dec 2 2005 setgroup-swap
% PATH=$PATH:/opt/rational/clearcase/
export PATH
% CLEARCASE_GROUPS="group1:group2:group3:group4:group5:group6:^
group7:group8:group9:group10:group11:group12:group13:^
group14:group15:group16";
export CLEARCASE_GROUPS
% setgroup-swap
usage: ./setgroup-swap
CLEARCASE_GROUPS EV to reorganize groups)
% setgroup-swap cleartool mkview -tag testview -host testhost^
-gpath /net/homes/testuser/testview.vws -hpath^
/net/homes/testuser/testview.vws ^
/net/homes/testuser/testview.vws
Trouble removing view references from a replicated VOB using rmview -uuid -vob command
| |||||
| Cause | |||||
| Review technote 1122515 for more information on the rmview -uuid command and it usage. When a DO is accessed by a view, two references are made in the VOB:
If the view is improperly removed in this situation, the above scenario can occur. The DO-specific reference to the view can be removed with the cleartool rmview -uuid command, but the other general reference cannot (even though the VOB is no longer really holding a reference to that view). Defect RATLC00588487 has been logged against this behavior. | |||||
| Answer | |||||
| This defect has been fixed in the following 2002.05.00 ClearCase patches.
The patch above corrects a defect that could cause config records to be lost in a view. This could also cause internal errors when examining hierarchical config records (diffcr -flat or diffcr -recurse), and could also cause rmview to fail with an internal error when attempting to remove views that had lost config records. |
Checkout (reserved) an element that is already checked out (reserved) in another view
| Problem | ||||||||
| This technote explains how to checkout (reserved) an element that is already checked out (reserved) on the same branch in another IBM® Rational® ClearCase® snapshot or dynamic view. | ||||||||
| | ||||||||
| Cause | ||||||||
| One of two common scenarios is associated with this problem:
| ||||||||
| | ||||||||
| Solution | ||||||||
| There are two solutions to this problem: 1. Uncheckout the element(s)
See technote 1122515 which provides instructions on how to remove all the checkout references from a view using the cleartool rmview -uuid command. 2. Change the checkout status of the elements(s) from reserved to unreserved
Review the ClearCase Command Reference Guide on the topic of unreserve (cleartool man unreserve) for more information. There are two scenarios that use slighltly different methods to achive the same results. These scenarios depend on the availablity of the view and the ability of a user to start and or set into the view itself.
If you can start and set into the view that has the checkouts, but do not want to checkin the data and do not want to lose the changes that were made in that view, you can simply change the reserve status directly in one of two ways:
This example would be an option for a snapshot view that is currently disconnected from the network which has changes that can't be lost. Once the element is changed to an unreserved checkout, another view can then check the element out reserved, make changes, and then check it back in.
Command Line:
|
