Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

RIGHTSLIST merging - what am I doing wrong???

 
SOLVED
Go to solution
Steve Reece_3
Trusted Contributor

RIGHTSLIST merging - what am I doing wrong???

This should be dead easy, but I've spent a lot of time on it already and I'm getting to the end of my patience!

Two systems, A and B.
I want to merge identifiers from system B into system A's rightslist:

$ CONVERT/MERGE RIGHTSLISTB.DAT RIGHTSLISTA.DAT

This gives informationals of 102 duplicate keys encountered, as:

%CONVERT-I-DUP, duplicate key encountered

Howver, it seems I'm getting inconsistent results with identifiers in RIGHTSLISTA.DAT getting overwritten on some occasions whilst on others I end up with two identifiers with the same text translation. :o(

ANALYZE/RMS on the files uncovers no errors.

Following the script in the back of the OpenVMS Cluster Systems manual resulted in even more corruption of the identifiers with some losing their names completely although the identifiers themselves remained on the system!

Any ideas what I'm doing wrong (other than starting this in the first place...)
10 REPLIES 10
P Muralidhar Kini
Honored Contributor

Re: RIGHTSLIST merging - what am I doing wrong???

Hi Steve,

>> Following the script in the back of the OpenVMS Cluster Systems manual
>> resulted in even more corruption ...
Are you are mentioning about the procedure mentioned here -
http://h71000.www7.hp.com/doc/731final/4477/4477pro_023.html#build_uaf_upgrade

Discussion on a similar requirement -
http://forums11.itrc.hp.com/service/forums/questionanswer.do?admit=109447626+1276795503159+28353475&threadId=980127

Hope this helps.

Regards,
Murali
Let There Be Rock - AC/DC
Steve Reece_3
Trusted Contributor

Re: RIGHTSLIST merging - what am I doing wrong???

Hiya,

yep, it was that process that I was using and that was no help either. I got multiple records with the same identifier value, and identifier names from the master file got overwritten by identifier names from the other file too.

>> Following the script in the back of the OpenVMS Cluster Systems manual
>> resulted in even more corruption ...
Are you are mentioning about the procedure mentioned here -
http://h71000.www7.hp.com/doc/731final/4477/4477pro_023.html#build_uaf_upgrade
Jan van den Ende
Honored Contributor
Solution

Re: RIGHTSLIST merging - what am I doing wrong???

Steve,

what you are "doing wrong" is way back in history: you(r predecessors) have used the default RIGHTSLIST behavior on different systems.
I here will assume that you do not have usernames with colliding [grp,mem] combo's - that would probably have led to a differently formulated question.

By default, a new identifier simply gets assigned the next available HEX number.

In all probability, on different systems the same name gets allocated a different numewric value, and/or different names get assigned colliding values.

IF you want to merge two or more RIGHTSLISTs, then FIRST you will have to decide which one will be leading (usually based on which dataset will be kept), and all conflicts need to be resolved beforehand (yes, simple lousy work).
Any clashes can be changed by
$ MC AUTHORIZE MODIFY indentname /VALUE:INT=%X

Remeber: any dataset coming from the system whose identifier was changed also needs to be inspected for ACLs using that ident, because they are stored numerically.

IMHO it was a VERY BAD design decision to simply have identifier values be generated that way.

For more than two decades I 've had a procedure that generates unique identifier values from alphanumeric names, under the condition that the first 4 chars of that name are unique. (Actually, name SETs, with at most 16 (0 - %xE) modifiers, eg PROD as resource ident, PROD_MGR for application manager, PROD_RO for Read_Only access, etc)

Maybe this IS a time to start implementing something like that?

For now, regrettably it will just be a lot of work.
My sympathy.

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
P Muralidhar Kini
Honored Contributor

Re: RIGHTSLIST merging - what am I doing wrong???

Hi Steve,

One more thread with a similar discussion -
http://forums11.itrc.hp.com/service/forums/questionanswer.do?admit=109447626+1276945918873+28353475&threadId=213453
Here merging both the SYSUAF.DAT and RIGHTSLIST.DAT are discussed.
There is sequence of steps using "SORT/NODUP..." which is claimed to be
working. You can try that out too.

Hope this helps you out. Good luck.

Regards,
Murali
Let There Be Rock - AC/DC
Jan van den Ende
Honored Contributor

Re: RIGHTSLIST merging - what am I doing wrong???

Oops,

glith in previous answer:

>>>
$ MC AUTHORIZE MODIFY indentname /VALUE:INT=%X
<<<
should be

$ MC AUTHORIZE MODIFY /IDENTIFIER indentname /VALUE:INT=%X

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
Hoff
Honored Contributor

Re: RIGHTSLIST merging - what am I doing wrong???

Robert Gezelter
Honored Contributor

Re: RIGHTSLIST merging - what am I doing wrong???

Steve,

I have done this quite a few times during cluster and system merges. As has been noted, the values RIGHTSLIST entries must be normalized PRIOR to trying to merge the files.

In addition to what has already been said, I will add that File Ownership needs to be checked also on ALL volumes.

In short:

- Identify all collisions (Same name-Different value; Different Name-Same Value)
- Prepare list of collisions, scan all volumes for affected files and ACLsf; correct values to desired values
- Resolve so both types of collisions no longer exist

Needless to say, good backups are an excellent idea. There is substantial potential to make a mistake.

- Bob Gezelter, http://www.rlgsc.com
Jon Pinkley
Honored Contributor

Re: RIGHTSLIST merging - what am I doing wrong???

Steve,

You've had a cap for a while but I don't remember giving you congrats. Was there ever a topic for your promotion?

Now, on to your problem:

Duplicates are not the problem, the problem is if the (Text ID,binary value,attribute) tuples don't match. In other words, if you have a common username that has a different UIC on one system than the other, or an Identifier has a different value on one system then the other, and to a lesser extent, if there is an identifier that has a different set of attributes. (resource, subsystem, etc.)

Examples:

JONES [123,456] | JONES [321,654] ! same name with two different UIC values

BLACK [123,123] | SMITH [123,123] ! two different names with same UIC value

DFU_ALLPRIV %X80010009 | DFU_ALLPRIV %X80010003 ! Same general identifier, two different values

As Jan has said, cleaning up is busy work.

Here is what I do:

$ mcr authorize list /id /br * ! do this on both systems

Then copy the two rightslist.lis files to a common location, and use differences to find the "problem duplicates"

To make it easier to detect duplicate binary values (UIC, or %X values) sort each rightslist.lis by the UIC portion.

$ sort rightslist.lis; rightslist.val; /key=(pos:36,siz:15)

$ difference/par/match=1 rightslist.lis

$ difference/par/match=1 rightslist.val

This will find the problems, i.e. all tuples that don't match in name, value or attributes.

Everything that shows up here has to be checked. If something shows up on one side only, then it may be able to be merged, but you need to verify that the name or UIC isn't in the other list. In other words, in the example from the top, JONES would show up as it is above in the RIGHTSLIST.LIS diffs, but as two different lines in the RIGHTSLIST.VAL, and the UIC [123,123] would should up on two widely separated lines in the RIGHTSLIST.LIS diffs, but on the same line in the RIGHTSLIST.VAL diffs.

When you find a problem, then you need to find the files that are affected, if any are. For the case of DFU_ALLPRIV, it is just an identifier that the DFU programs looks up to see if the process running DFU holds the identifier, so in general, there won't be files with the DFU_ALLPRIV identifier as owner or in an ACL. However, many identifiers may either be the owners of files, or may be in ACLs on the files (or even in ACLs on other objects, like queues or logical name tables). To find the affected files, DFU is a good tool.

$ def/job dfu$nosmg 1
$ dfu search /own=jones /sort ! for every disk... just busy work, you may want to do this in a batch job
$ dfu search /ace=jones /sort

You need to do that on both systems (as this may help you decide which identifiers to change and which to leave)

To fix the files will require more work, and the identifiers in the ACLs are the hardest to deal with. I am not aware of a utility to change the ACLs to modify the value in an identifier. You could probably write one using David Jones' program to cleanup pathworks identifiers as a starting point.

See David's post dated Jun 1, 2009 14:12:41 GMT in the thread titled "A tool to delete all Pathworks ACEs ?"

http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1344050

You will also need to change the ownership of the files (set security will work, but will modify the modification date, using backup will allow copying the files and changing the ownership without changing the modification date).

After you have both systems using the same values for the same users/identifiers, then you can merge the files.

Good luck,

Jon
it depends
Ian Miller.
Honored Contributor

Re: RIGHTSLIST merging - what am I doing wrong???

Personally I convert/merge SYSUAF but not RIGHTSLIST.
Extract identifiers from RIGHTSLIST B and prune then add to RIGHTSLIST A using commands in AUTHORIZE. Then delete and reapply ACLs
Most of that can be automated.
____________________
Purely Personal Opinion
Steve Reece_3
Trusted Contributor

Re: RIGHTSLIST merging - what am I doing wrong???

Thanks Jon - I don't think there was a topic for my cap, but it's only a small cap so no problem. I normally ask the questions on here rather than answering them!!

Thanks to Jon and Ian for the answers. Thankfully, the rightslist isn't all that complex as there are few identifiers granted and few differences to the two sets of UICs - mainly around the TCPIP service UICs and the SYS$NODE_xxxxxx identifiers (one of the rightslists comes from a cluster.)

Thanks again.