I used rcleartool with no problem until yesterday.
In today, "write" commands fail with permission error. I do not change any configuration. I don't know whether CM server changed or not.
some examples when I encounter problem
cmd> rcleartool mkelem -nc {file path}
(some output)
ClearCase CM Server: Error: Can't create object with group (XXXX\Domain Users)
that is not in the VOB's group list.
at com.ibm.rational.stp.cs.internal.util.StpExceptionImpl.realException(StpExceptionImpl.java:493)
at com.ibm.rational.stp.cs.internal.util.StpExceptionImpl.<init>(StpExceptionImpl.java:572)
at com.ibm.rational.stp.cs.internal.util.StpExceptionImpl.cloneFor(StpExceptionImpl.java:956)
at com.ibm.rational.stp.cs.internal.util.StpExceptionImpl.cloneFor(StpExceptionImpl.java:980)
at com.ibm.rational.stp.client.internal.cc.WebViewBulkOpBase$ReadPropsIterWrapper.checkForBulkOpFailure(WebViewBulkOpBase.java:119)
at com.ibm.rational.stp.client.internal.cc.WebViewBulkOpBase$ReadPropsIterWrapper.next(WebViewBulkOpBase.java:81)
at com.ibm.rational.stp.client.internal.cc.WebViewBulkOpBase$ReadPropsIterWrapper.next(WebViewBulkOpBase.java:52)
at com.ibm.rational.stp.client.internal.cc.CcFileImpl.doCcVersionControl(CcFileImpl.java:280)
at com.ibm.rational.stp.client.internal.cc.CcFileImpl.doVersionControl(CcFileImpl.java:269)
at com.ibm.rational.ccrc.cli.command.MkElemCommand.execute(Unknown Source)
at com.ibm.rational.ccrc.cli.command.Command.run(Unknown Source)
at com.ibm.rational.ccrc.cli.command.ClearWan.main(Unknown Source)
(command)
cmd> rcleartool rmelem -f {file path}
(some output)
Request failed in method CcRpc::destroy with status 1001
(file=\nucor\server\stp\ccrpc\ccrpc.cxx, line=1751)'
CRVAP0239E: CRVSV0078E RPC:
CRVSV0841E 'CRVSV0613E Destroy failed: ''error detected by
ClearCase subsystemClearCase CM Server:
Error: No permission to perform operation "remove element".
ClearCase CM Server: Error: Must be one of: element owner, VOB owner, member of ClearCase group
This is usually:
because the current DOS session for this rcleartool command doesn't have the right CLEARCASE_PRIMARY_GROUP fixed anymore
or because of some permission issue on the parent directory where this add to source control (mkelem) takes place.
I would seriously check the first possibility, as it fits the Primary Group requirements for element creation and is found in other cleartool commands like multitool.
Note about mkelem:
The mkelem command has different Primary Group requirements on Windows and UNIX/Linux.
UNIX/Linux:
In order to create an element in a VOB, your Primary Group must match a group in the VOB's group list.
WINDOWS:
As long as you "are a member of" a group in the VOB's group list and the parent directory where the element will be created is owned by the group to which you are a member, you will be able to create elements in the VOB.
If, however, you are a member of more than one of the VOB's groups, the CLEARCASE_PRIMARY_GROUP will need to be set to one of these.
See technote 1135509 for more information about the CLEARCASE_PRIMARY_GROUP variable.
user972301 refers in the comments to "Primary Group requirements for element creation"
I get the same error with cleartool but under Linux when I try to do an mkelem in a snapshot view of a child development stream whose parent is located on a different PVOB than what I usually work wit
One needs to change his local machine's group ownership to match the PVOB's
Related
How to know which user has write access to Clearcase database? It mainly means authorization to perform check-in but not only, for example modify a Clearcase value of a defined attribute...
How to have a list of all the user identifiers who modify something in a given VOB? In any of the VOBs?
Does exist specific roles and profile in Clearcase? Or just the Unix root?
For information:
- ClearCase 8.0.1.4 (AIX 1 7)
- BASE CLEARCASE only is used, not UCM.
Start with "VOB and view access control"; the main access criteria is user and groups:
A user's name and group memberships are the principal credentials evaluated by Rational® ClearCase® when access is requested.
So any user which is has, as a primary group (first group when typing id -a) the same group as the one of a Vob can access that Vob. See for example "ClearCase won't allow Check-In" (note: the view itself must be correctly protected as well)
On AIX, you can use lsuser to list users of a given group.
See more with "Access control for elements".
But since ClearCase 9, you also have ACL authorization:
You can use ACLs to protect the VOB object, policies, rolemaps, and elements (other object types, such as branch types and label types, must be secured by the protection mechanisms of the operating system
You can setup policies (see cleartool lspolicy), and rolemaps
You use a rolemap to specify the principals that take on roles listed in a policy, and to apply the access controls to one or more VOB objects.
The intention is that you can define a small number of policies that determine ‘how' you apply permissions to objects. You then define a number of rolemaps for each policy describing ‘who' takes on the roles in the policy.
By listing rolemaps (cleartool lsrolemap), you can back a list of groups, from which you can deduce the list of users:
Role:Reader --> Group:DOMAIN/developers
Role:Manager --> Group:DOMAIN/mgrs
Role:Developer --> User:DOMAIN/danny
Role:Integrator --> Group:DOMAIN/integs
Role:Developer --> Group:DOMAIN/devs
Role:Administrator --> User:DOMAIN/vobadmin
I have a very basic question in clearcase.
does every version of an file have same OID? As far as I know each version is an object and each object will have a different OID.
I even checked with cleartool dump and each version has different OID.
More precisely, as explained in "How to find oid and uuid of an element in IBM Rational ClearCase"
Every single object in a ClearCase VOB is referenced by its oid ("object ID").
The oid is unique inside the VOB.
This does not apply only to file, but to all objects in the VOB.
Element
Version
Metadata
ClearCase uses the oid internally. The oid is invisible for common user's operation. However, in some error messages, you see a reference to an oid.
To find the oid from an object, you use :
cleartool dump <object>
To find the object from an oid, you use :
cleartool dump oid:<object>
For theses commands to work, you need to be in a view and in the corresponding VOB. This is necessary in order to generate the path/file name.
<object> can be anything defined as an object for ClearCase. Like for instance:
element <file>##
version <file> or <file>##\main\......
type lbtype:<name>
VOB or replica object vob:<vobtag>
You can also run "cleartool describe -long oid:<oid>" on the oid while set in a view to the root of the VOB to which the element resides, and the output will return an element name.
See "Identifying elements by the source container path"
This should in theory be quite simple, i.e. merge the changes from a specific UCM activity from one stream to another.
I had thought that I might just be able to use the Deliver command in the GUI and then select just the required activity to deliver, but it seems that the target stream is set to not allow deliveries from other streams.
From searching the documentation it seems that I might instead be able to do this via the command line using the findmerge tool, but it's not at all clear from the rather sparse documentation how you do this. It seems like it might be a two stage process, i.e. first generate a "changeset", then merge that changeset ? Also I'd like to do the merge manually for each affected file, so I would need the graphical merge tool to be invoked if possible.
If someone can give me an example findmerge + whatever command line for merging an activity that would be a great start. Also any other suggestions for how to merge an activity would be welcome.
First, deliver in UCM are (usually) made to deliver all activities.
You can try to deliver only a subset, but you quickly comes to gripe with "timeline", which are linked artificially all the activities together, forcing you at the next deliver to deliver them (all).
findmerge tool, but it's not at all clear from the rather sparse documentation how you do this. It seems like it might be a two stage process, i.e. first generate a "changeset" then merge that changeset ?
cleartool findmerge activity: is the non-UCM way to merge all versions referenced by an activity from a stream (a branch actually here) to another branch.
ct findmerge activity:A1#\pvob activity:A3#\pvob -fcsets -c "report for delivery" -merge -gmerge
See "ClearCase : Making new baseline with old baseline activities" for more on timeline (activity dependencies) and findmerge.
This is documented in the technote swg21267316:
WORKAROUND:
From the target view:
Set to an activity (setact) or create a new activity (mkact). This activity is just like the Integration activity normally used/created during a deliver. It allows you to:
check the files in after the merge.
Run a findmerge using the following format:
cleartool findmerge activity-selector ... -fcsets [-gmerge | -merge]
Merge files as needed
Checkin files that were merged
Example:
M:\int\cvob1>cleartool findmerge activity:A#\pvob -fcsets -gmerge
Needs Merge "M:\int\cvob1\old folder\new name" [to \main\int\7 from \main\int\de
v\2 base \main\int\dev\1]
Checkout comments for this and any additional elements:
deliver dependencies work around
.
Checked out "M:\int\cvob1\old folder\new name" from version "\main\int\7".
Attached activities:
activity:int-merge#\pvob "int-merge"
We use ClearCase UCM which has multiple Vobs (10).
How to find the activities for past one week?
Or list activities between two date ranges?
It is a bit trickey, because all cleartool lsactivity commands are limited to one pvob ("project vob" or "special vob with UCM metadata in it"):
cleartool lsact -invob \my\pvob -stream ...
And an activity can be reused (meaning an old activity can have in its changeset very recent versions)
If you have two baselines, you can easily diff them (by activity): See ..diffbl**.
ct diffbl -act baseline:bas1#\myPVob baseline:bas2#\myPVob
(that is necessary for one component within one Vob though)
But if not, you need to list all activities and their changeset, to see which one contains version produced in the relevant date range.
We are using a ClearCase UCM plugin which called "Compare BL", made by "Go Midjets". It answers your needs.
Here a useful snippet for Linux tcsh.
For each activity you get you may want to list its changed set.
You can use
cleartool lsact -s and cleartool lsact -fmt "%[versions]p" <act_Name>
as shown here:
http://www.snip2code.com/Snippet/961/list-files-changed-in-clearcase-ucm-stre?fromPage=1
I have a problem with manager attribute in Sun Directory Server.
I set this attribute for a user in the directory, e.g. cn=testmanager,dc=test,dc=com and when I change manager's dn this change is not propagated in manager attributes.
For example:
I have two users:
dn: cn=testmanager,dc=test,dc=com
and
dn: cn=testperson,dc=test,com
manager: cn=testmanager,dc=test,dc=com
Then I modify manager's dn to:
dn: cn=testmanagerchange,dc=test,dc=com
But manager attribute in cn=testperson,dc=test,com doesn't change is still equal to cn=testmanager,dc=test,dc=com. In Active Directory it works fine.
Exact definition of attribute:
Name: manager
OID: 0.9.2342.19200300.100.1.10
Aliases: -
Origin: RFC 1274
Description: Standard LDAP attribute type
Syntax: 1.3.6.1.4.1.1466.115.121.1.12 (DN)
Multivalued: Yes
This may not directly help, but it may depend on how Sun Directory Server handles DN syntax attributes. I can speak with experience for eDirectory, where DN syntax attributes do what you want automagically.
I.e. You can rename, move, or delete an object, and all DN syntax references to it will automatically update themselves. (Actually for renames and moves they do not actually update, rather when they convert the internal database ID value for the object to display the pretty human readable name, it always shows the current value. Clean up after deletes are handled differently).
The question becomes, how does Sun Directory Server handle these cases.
Though it is interesting that manager can be multivalued. That would suck, having several managers!
I found the answer.
In Sun Directory Server you have to set the list of attributes that should keep reference integrity. Some attributes are set by default, however you have to manually add manager attribute.
This is an article that explains this issue: http://docs.sun.com/app/docs/doc/820-2763/fsush?a=view.
Thanks for your help.