I am trying to make one folder in our VOB where it is readable by everyone, but only one group can write to it. This is what I have done, but I am starting to think that I missed something...
I had a new windows group created and added the specific users to it.
I added this group to the vob group list. (Does it have to be added to the PVOB as well?)
I changed "group" owner on the folder to this group.
I added this group to my CLEARCASE_GROUPS environment variable (and restarted.)
I am still getting "permission denied" when I update, and I am not able to add any files under the folder. Did I in fact miss a step?
You also need to:
add this group to your CLEARCASE_PRIMARY_GROUP
then create a dynamic view (it will be protected with this group)
then mount this vob
and try to create a folder in it.
See also "How to restrict VOB read access in ClearCase (Windows Server)?" for a concrete example.
I mention a dynamic view because it will be easier/faster to test the Vob access and folder creation with it. Once it is working, create a snapshot view in the same conditions and it should also work.
Note: if this Vob is an UCM component Vob, I would recommend adding that group at least to the secondary groups of its associated pvob.
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
In my project I got to create users who are allowed to read only access to VOB. To accomplish this as per study and my understandings I have created different groups and directory wise I have changed root group to respective group.
Example : Under VOB I have three directories dA, dB and dC I created 3 groups gA, gB and gC.
Even after gving protecting directories by chmod 770 so that other groups could not do Checkin/Checkout -
1. Other groups users still could access directories.
2. And other groups are still able to do Checkin/Checkout.
Please do suggest on how I can restrict VOB components(directory basis) from checking ou/in by specified user in clearcase.
ClearCase 7.x:
chmod on the vob storage itself isn't enough to prevent checkout/checkins modification operations: you need to consider the CLEARCASE_PRIMARY_GROUP environment variable used by each user.
If that group is not part of the primary group or secondary groups declared in the vob, they wouldn't be able to checkout/checkin.
See also "About ClearCase permissions on Windows".
As mentioned in this thread:
Unless user is a member of the element's group, he or she would not be able to make any changes (checkouts/check-ins).
It can be used to grant read-only access to a VOB, when elements "world" rights are not revoked.
BTW, even when required group membership is not granted, it would not prevent user from creating metadata, such as branch or label types. Triggers would be required to restrict these operations.
This thread confirms:
you are stuck with a pre-op trigger on checkout.
Add the "read-only" users to the group and only allow users in a list (either in the trigger itself or as an attribute on the VOB) to perform checkouts.
ClearCase 8.x
CC8 introduces the notion of access control lists (ACLs), which simplify the security of your versioned object bases (VOBs).
See more with "Ensure effective administration and security in Rational ClearCase 8.0.1"
We have a current set up of VOB such that source code and documents reside in the same VOB.
To reduce the VOB download time we now want to move the documents to a new VOB, so that only the code part remain in the old VOB.
Since there are lot of folders and files, its not possible to manually relocate each file/folder.
To do this, we need to write a script which will detect file types by their extension and move file types such as .doc,.pdf, .txt to the new VOB.
VOB server is Windows Windows 2008 R2 Enterprise edition.
I'm a novice!
Can someone help me out with the script?
Thanks
Nush
The process would involve cleartool relocate: see "Relocating elements to another VOB".
The best practice is to:
group all the right elements you want to relocate in one folder (cleartool move)
remocate that folder
It is best if what you want to split is cleanly group is one folder structure.
Note that relocate wouldn't work if you are using ClearCase UCM though.
See this article:
The reason for this restriction is immutable baselines: if an element has ever been in a baseline, it can never be moved to another place; the baseline needs to know where to look for it. So a UCM element really can't be relocated.
We selected vob names aligned with our project name ( do not confuse project name with UCM project name) so that we can easily distinguish.
But recently our project name has been changed as we merge 2 products into one.
Some people suggested to rename the vob to indicate the project name.
We tried to analyze the impacts from development and build & release perspective.
There were very little changes, here and there we had to change the path variable to indicate the latest vob name.
So we agree for renaming the vob name.
Then as Clearcase admin i had to do impact analysis.
When i asked advice from senior Clearcase admin. They listed possible impacts such as below.
symlinks across vob will be broken so they may need to repair.
It is better to clear all check out items before changing the vob name
vob will be locked to prevent users from using the old vob name while name change.
Vobs has to be unmounted and remounted
Snapshot and CCRC views may be affected , so it has to be resynchronized.
and etc.
Has any one tried vob rename in your project? Can you share the practical impacts which you have faced which will be helpful for us?
If you already tried and decided not to do it again by any means , can you advice why it is not practically advisable to do so?
Thanks in advance.
Most importantly, your UCM components won't work anymore: you cannot change their root directory (ie path within the vob, or vob itself), even though you can change their name (their "title").
And that is independent from UCM project name (the UCM project don't care about UCM rename, only the UCM Streams do)
Frankly, when face with this kind of refactoring, I:
keep everything in place, but locked and in read-only
start fresh with a new component/vob, importing the latest baseline.
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.