I received one request from one of our client regarding "group permission change for listed folders" from “abc” vob as they are not able to change permission due to mastership issue for those folders (Because, mastership lies at our end).
I got request to change the group permissions for our vob's 10 directories. So that they can access and do some analysis through some tools.
But as per our admins, VOB group permissions remains to one group only and they cannot change it.
But our Client is keep on pinging me. As per my R&D, I found "protectvob" command. Does the below command works?
cleartool protectvob –add_group "groupname" /path_of_the_vob/abc_vob/directory1
Please could you check and send me the steps to change group permission for only 10 directories of abc vob?
protectvob will allow you to add secondary groups to the Vob.
But it won't change the protection on any element within that Vob.
See the examples of cleartool protectvob man page.
To change a group on a collection of files, you can use cleartool protect (once you have added that group to the secondary groups of your vob, so protectvob is still needed):
cleartool find . -nrec -exec "cleartool protect -chgrp \"My Group\" \"%CLEARCASE_PN%\""
(adapt the cleartool find to list only what you need)
Related
I am trying to perform a build of some software that exists on an air gapped network. And I having issues with clearcase, denying me access to files that I need to perform the build.
When I check the protection settings for the VOB on the clearcase server I get:
Pool "sdft" appears to be protected correctly
Pool "ddft" appears to be protected correctly
Pool "cdft" appears to be protected correctly
looking at that same vob from the windows side I see:
Pool "sdft" needs to be protected correctly
Pool "ddft" needs to be protected correctly
Pool "cdft" needs to be protected correctly
Before seeing this issue there was a problem with VOB caused because active directory had been modified so I recently changed the ownership of all of the files in the VOB to me. and according to a sidwalk/looking at the files from the linux side. It looks like I have the correct permisions set."
What can I do to fix this issue?
EDIT learned old information was relevant:
This was not included because I didn't think this was related.
Before trying to get things working on this system, there had been a software update which had broken the active directory configuration. Which was fixed and gave me access again to ClearCase and the ClearCase Server
This is somewhat stream-of-consciousness and being edited on mobile, so bear with me.
Without knowing WHY you are "denied access" resolution attempts may make thing worse.
Those outputs are from protectvob, and would have to be taken with a grain of salt when run from windows if the VOB is in Unix.
The describe of the VOB is the first step. Look for "nobody" in the user and groups. These are groups that are not mapping. Then describe the file you are trying to access. Does its group map? Are you a member of the group? An element group that doesn't map between windows and UNIX will block cleartext construction.
Are you the only person with access issues?
When did they start?
Does Creds ({cc install}\etc\utils\creds) show you in that group?
If this is happening in dynamic views, and everything else looks right, how are you logging into Windows? If you're using biometric, smartcard, or Windows Hello authentication, the clearcase primary group and/or clearcase groups environment variables will only partially "take" until you invoke the nplogon.exe utility in \windows\syswow64. The above login mechanisms bypass this, and you can have mismatches between what creds sees and what the MVFS sees.
I feel bad, that due to some missing information on my part.
The missing information
This network uses active directory to keep the users synchronized between devices... But a software update broke it. So we had to create a new configuration. This ended up creating a 2nd identically named group to the group that owned the clearcase VOBs. Looking at the files on the ClearCase server side, protectvob saw that the username was what it was supposed to be, the group name was what it was supposed to be, no problem! It didn't realize that clear_case_group(gid=1) is not clear_case_group(gid=2).
The windows side however had no idea who clear_case_group(gid=1) is and so realized that there was a problem.
My attempts to us fix_prot to fix that access errors failed, because fix_prot was applying the gid from clear_case_group(gid=1) to the files and not the second, newer group.
How i found out that this was the actual problem
id questor soon after looking at a sidwalk dump and noticed thatclear_case_group had a different GID for questor then inside of the dump file.
getent group clear_case_group, questor was not a part of the group... But
getent group <gid=2> -> clear_case_group that questor was a part of...
getent group <gid=1> -> clear_case_group that questor was not a part of.
There are 2 clear_case_groups on the ClearCase server for some reason (terrible practice, I know).
The Fix:
vob_sidwalk used to replace clear_case_group(gid=1) with clear_case_group(gid=2), or fix_protect using GID instead of group_name...
Lessons learned
Group names do not have to be unique on Linux. Linux allows for duplicate group names with different GIDs. This is my first (and hopefully only) time encountering identically named groups. SO before making a claim that the user/groups are correct.... Look at the GIDs which are unique not the names.
Check the primary group of the VOB: cleartool describe -long vob:<vob-tag>
Your ACL should at least reflect that group.
See "About ClearCase permissions on Windows"
Security descriptors contain information about ownership of objects: who owns the object, who can access the object, and the types of access allowed for the object.
A discretionary access control list (DACL) is a component of a security descriptor which is viewable and modifiable by users with read access to the object.
Note that the terms DACL and access control list (ACL) are used interchangeably.
VOB and view storage directories (ending with .vbs and .vws) use identity.sd and groups.sd files that describe ownership, regardless of the file system on which they reside.
The contents of these files can be viewed using the lsacl -f command.
That last command is detailed in "Fixing protection problems"
If the filegroups.sd exists in the storage directory root stg-pname, run this command:
ccase-home-dir\etc\utils\lsacl –f stg-pname\groups.sd
Example:
===== stg-pname\groups.sd (Owner)
Owner: NT_WEST\bob (User) (non-defaulted) (Primary group)
Group: NT_WEST\usersnt (Group) (non-defaulted)
ACL (revision 2):
0: allowed
SID: NT_WEST\user (Group) (Supplementary group)
rights (00000000)
1: allowed
SID: NT_WEST\tester (Group) (Supplementary group)
rights (00000000)
===== stg-pname\groups.sd (Owner)
Owner: NT_WEST\bob (User) (non-defaulted) (Primary group)
Group: NT_WEST\usersnt (Group) (non-defaulted)
ACL (revision 2):
Empty ACL: all access denied (No supplementary group)
Remove the supplementary group list. Run the following command:
ccase-home-dir\etc\utils\fix_prot –r –root –chown owner –chgrp group stg-pname
If you are fixing view storage, you are finished.
If you are fixing VOB storage, log on as the VOB owner and continue.
If the VOB has a supplementary group list, run this command:
cleartool protectvob –add_group group-name[, ...] vob-stg-pname
Remove the cleartext containers. Run the following command:
scrubber –e –k cltxt vob-stg-pname
This step must precede Step 7 because checkvob cannot fix cleartext containers.
Fix the storage pools protections. Run the following command:
cleartool checkvob –force –fix –protections –pool vob-stg-pname
I have Rational ClearCase v7.1.2.13
I need to delete certain checkouts from a view as these check-outs are reserved and the user has gone for a vacation.
Please help me.
The easiest to do is to "unregister" the user's checkouts:
cleartool descr -l vob:\myVob
# get the uuid of the user's view from the description of the vob
cleartool mount \myVob
cd m:\mynewView\myVob
cleartool rmview -force -uuid old_view_uuid
That will not modify anything in the user's views: the files are still being modified, but they won't be considered as checked out.
Instead, they will be "hijacked" (identified in snapshot view) or "eclipsed" (dynamic view).
The other option (put a reserved checkout as unreserved) is rarely possible, as it require access to the view as well as elevated privileges.
I am receiving the below error when I am trying to edit the value of Proj_Mgr in UCM.
Please advise
no permission to perform operation "Make attribute" UCM
You must see an error like:
No permission to perform Make Attribute.
Must be one of: member of object group, object owner, VOB owner, member of admin group
So check your CLEARCASE_PRIMARY_GROUP environment variable, and compare it to the groups of the vob, or the associated pvob (in UCM).
You can see those by describing the vob:
cleartool descr -l vob:\myVob
As a possible cause, check out the IBM technote
"Problems that occur if the ClearCase Administrator group owns the VOB or VOB objects":
When a VOB or objects contained within a VOB (elements and metadata) are owned by the ClearCase Administrators group, this will most certainly result in permissions errors whenever an operation is performed against that object by a non-Admin user.
Since the administrators group by default has access to all ClearCase objects, it is not necessary to explicitly add that group and should be avoided.
You can see a concrete scenario where that error pops up in:
"Error setting the recommended baselines for this stream" (for a Stream though. In your case, you shouldn't have to reprotect the Vob, but rather make sure you have the right identity/group).
I used this command to solve this issue (a protection issue as described above):
ct protect -chgrp ccuser project
My friend who recently left our organisation also left his ClearCase view undeleted.
Now we wanted to delete it.
I was trying to delete but it did not allow. It said:
Unable to remove "\\hostname\viewsharefolder\Viewname.vws"
Operation not permitted
Can administrator only delete his views?
If I deleted the (.vws) folder associated with view, for ex: "Components_int.vws", will it be enough?
Yes you can (for any view, snapshot or dynamic, UCM or base ClearCase).
You also can remove it without ever accessing it. (So removing the view storage isn't enough, or even necessary)
If you still have access to the view storage:
cleartool rmview theViewToRemove
If there is any access/right issue when trying to remove said view:
cleartool lsview -l theViewToRemove # get its uuid
cleartool rmtag -view theViewToRemove
cleartool unregister -view -uuid uuid_of_viewToRemove
That second solution is very handy in that you don't need access to the view storage.
You simply remove reference to that view in the central registry of ClearCase (specifically the view_object and view_tag files of your ClearCase registry server)
Tamir Gefen mentions in the comment the IBM script rmview.pl, which is also mention in the SO question "Delete ClearCase Views Script".
A simpler script is in my answer of that same question: "muke_view.pl"
Can the project manager force cancellation of checkouts of files/directories made in any view/stream/project? How?
A ClearCase administrator can force all files of a given view to be considered as "not checked out" (which is the equivalent of canceling their checkout status), with cleartool rmview:
cleartool rmview -force -uuid (uuid_of_the_view) -vob \aVob
You can get the uuid by grepping the user in the output of:
cleartool descr -l vob:\aVob
See technote "Removing checked-out references of a view from a VOB".
It will work for any view (snapshot or dynamic views, base ClearCase or UCM views)
I would recommend limiting that command to a specific vob.
Anyway, that doesn't concern the Project manager unless he/she is also a ClearCase administrator (ie, he/she is in the same group than the ClearCase administrators group on Windows, or if he/she is root on Unix)
Regarding a cleartool unco (which you can attempt on a dynamic view only), keep in mind if will only work for:
Version creator
Element owner
VOB owner
root (UNIX and Linux)
Member of the ClearCase administrators group (ClearCase on Windows)
Local administrator of the ClearCase LT server host (ClearCase LT on Windows)
So, unless your project manager has created the Vob in which those checked out files are managed, he/she won't be able to undo checkout them.
As commented below, all checkout files of the associated vob \avob are no longer considered checked out (their status is reset, not their modified content, which is untouched).
In order to restore those checked out files, a user can:
for a snapshot view, list hijacked files (as in this technote)
for a dynamic view list eclipsed files (see technote on eclipsed files)
Each filename found can be piped to a clearcase checkout command.
So restoring the checked out files is fairly easy for a given view and vob.
You can't if it was checked out in a snapshot view. You may be able to if it was checked out in a dynamic view. You can use Find Checkouts to find checked out files and attempt to undo the checkouts from there.
Ideally, if it is a view that is accessible by someone with higher privilege, e.g. Clearcase administrator who possesses the VOB owner account, it is best to ask him to perform the checkin (if you are sure the file can be checked in) or a saving of the checkedout file followed by a "cleartool unco".
If it is not the case, the command
cleartool rmview -force -uuid (uuid_of_the_view) -vob <vob-tag-where-checkout-is>
should do the trick as mentionned previously by VonC.
However, be aware that this command cancel ALL the checkout in .
So if you have say :
\avob\file1.c
\avob\file2.c
Say both files are checkedout by the same view of the same user and you want to uncheckout only file1.c. The "cleartool rmview" command described above cancels ALL the checkout in the VOB. So file2.c will also be uncheckedout.
The good news is that the checkedout version will not be lost as they will stay locally in the absent user's view. He will be able to access them once he is back.
There is still another strategy how to handle other persons checkouts as an administrator. Gain access to the users snapshot view. If the computer is reachable, mount the snapshot location and use it as yours. In this case you may even checkin these checkouts as you see the changed files. Is the computer is unreachable, you can construct a new view.dat with the view UUID and populate your view with a cleartool update command for the critial files and directories. Changes in directory versions you will see and be able to checkin, file element changes are not reachable, so you have always to unco file versions.