HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Hours:
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

copying data with rights and protection intact accross remote nodes?

 
SOLVED
Go to solution
Clayton_12
Frequent Advisor

copying data with rights and protection intact accross remote nodes?

I have a 6.2 system and a 8.2 sytem, separtate nodes non clustered.

IS it possible to copy files and structure from DIsk on 6.2 system with all protections and rightlist information intact onto the 8.2 system?

Is it possible to use BACKUP to backup disk from the 6.2 host into save-sets on the 8.2 host disks?

Thx
CLayton
22 REPLIES
Uwe Zessin
Honored Contributor

Re: copying data with rights and protection intact accross remote nodes?

Yes, BACKUP is the right way. It will even retain the creation and revision dates on plain files. For directores, I use a hack of two command procedures and the good old FILE utility.
.
David Jones_21
Trusted Contributor

Re: copying data with rights and protection intact accross remote nodes?

Note that the rights identifiers in the ACLS will have the binary values, not the names so you have to manually reconcile the rightslist.dat files on the 2 systems.
I'm looking for marbles all day long.
Arch_Muthiah
Honored Contributor

Re: copying data with rights and protection intact accross remote nodes?

Clyton,

you can try some related info here under the subtitle of
B.1 Building a Common SYSUAF.DAT File
B.2 Merging RIGHTSLIST.DAT Files

http://h71000.www7.hp.com/doc/731FINAL/4477/4477pro_023.html#build_uaf_upgrade


Archunan
Regards
Archie
Arch_Muthiah
Honored Contributor

Re: copying data with rights and protection intact accross remote nodes?

Clayton,

"VMS guide to system security" says that BACKUP of RIGHTSLIST.database will not be correct even if we use /IGNORE=INTERLOCK qualifier in the backup command as RIGHTSLIST database is one of the VMS CORE files which should be open always.

And the manual says RIGHTSLIST database cannot be recovered from a BACKUP copy.

So better
1. CREATE RIGHTSLIST database
2. ADD/IDENTIFIER to generate UIC for each user in SYSUAF.database.
3, Redefine the holders of the identifiers with GRANT/IDENTIFIER commands.

I saw your couple posting on this same topic earlier, I guess this is best way as per the the manual.

Archunan
Regards
Archie
Jan van den Ende
Honored Contributor

Re: copying data with rights and protection intact accross remote nodes?

Re: archuan:

A consistent copy of active SYSUAF.DAT and RIGHTSLIST.DAT (and other permanently opened files) can be made by
$ CONVERT/SHARE ,
and then copying temp-file.
(see the MANY postings on this and related subjects by Mr. RMS himself, Hein van den Heuvel)

Proost.

Have one on me.

Jpe
Don't rust yours pelled jacker to fine doll missed aches.
Arch_Muthiah
Honored Contributor

Re: copying data with rights and protection intact accross remote nodes?

Clayton,

Yes, Jan. Clayton can use CONVERT/SHARE to a copy of rightslist file, and he already mentioned in his previous posting that he used COPY command and it worked for him.

I never tried BACKUP?, our docs also says backup/restore can't be the best way.

Archunan

Regards
Archie
Bart Zorn_1
Trusted Contributor

Re: copying data with rights and protection intact accross remote nodes?

How unreliable is a BACKUP/IGNORE=INTERLOCK of RIGHTSLIST.DAT really?

IMHO there is very little write/update activity on RIGHTSLIST on a normal system. So when you take this backup on a system which is not doing anything else, the chance that you wind up with an unusable RIGHTSLIST file is very slim.

OK, the documentation is correct. There is a chance that something goes wrong. In practice, if you know what you are doing, just do it!

Regards,

Bart Zorn
Petr Spisek
Regular Advisor

Re: copying data with rights and protection intact accross remote nodes?

CLayton,
yes, BACKUP can save original owner-UIC of file (Did you mean this as "righlist information"?). The best solution is to use the same user with the same UIC on both systems for owner of the saved file. If user of orig. UIC doesn't exist, you'll see only UIC-num as owner of file. You can use parameter /BY_OWNER=ORIGINAL into your BACKUP comands for backup and restor (or /BY_OWNER=['actual_uic'] for restore command).
Petr
Clayton_12
Frequent Advisor

Re: copying data with rights and protection intact accross remote nodes?

I was looking to perserve both Owner information, protection information, and identifier (Rightlist??/) permisions on files and directories?


Thx
Clayton
Uwe Zessin
Honored Contributor

Re: copying data with rights and protection intact accross remote nodes?

Most of what BACKUP does (ownership, protection, ACL), but the ACL (Access Control List), which is part of the file header, stores the binary information of an identifier while RIGHTSLIST.DAT stores the name-to-value mapping.
.
Clayton_12
Frequent Advisor

Re: copying data with rights and protection intact accross remote nodes?

IS the qualifier /by_owner the one that captures and restores the file and directory protection, owner, and ACL information?

Thx
Clayton

Uwe Zessin
Honored Contributor

Re: copying data with rights and protection intact accross remote nodes?

Ownership and protection are always saved. /BY_OWNER can be used as an input qualifier to select a sub-set of files to be saved.

/BY_OWNER as an output qualifier is a silly name (IMO), because it changes the ownership of all files created.

I say silly, because, prior to VAX/VMS V5.0 we had the /OWNER qualifier with the same functionality.
.
Ian Miller.
Honored Contributor

Re: copying data with rights and protection intact accross remote nodes?

" IS the qualifier /by_owner the one that captures and restores the file and directory protection, owner, and ACL information? "

No /BY_OWNER is a file selection qualifier.

Backup always preserves the security info in the backup saveset.
____________________
Purely Personal Opinion
Clayton_12
Frequent Advisor

Re: copying data with rights and protection intact accross remote nodes?

Thx for responses.

Does the security permissions automatically restore or is there a switch or qualifier that will do it?
Uwe Zessin
Honored Contributor

Re: copying data with rights and protection intact accross remote nodes?

Use /BY_OWNER=ORIGINAL as an output qualifier.
.
Clayton_12
Frequent Advisor

Re: copying data with rights and protection intact accross remote nodes?

everthing is looking good except there is
One little quirk!

I backup from the 6.2 system:

backup /verify /record /ignore=(interlock) device:[*...] userdata:[username]file.bck /saveset

I copy the file to the 8.2 system then restore the data:

device:[backups]file.bck.bck/saveset device:[newdir...] /by_owner=original

All the files and and directories retain there ownership and the ACLS
EXCEPT!
All the directories at the root of newdir.
All device:[newdir.*] retain ownership but not the ACLS. All device[newdir.*.*] do have ACLs retained, all files have ACLs retained?


ANy ideas?


Uwe Zessin
Honored Contributor
Solution

Re: copying data with rights and protection intact accross remote nodes?

Right, that's a problem with BACKUP - use:

$ backup disk:[000000]dir1.DIR;1,[dir1...]*.*;* -
saveset.bck/SAVE_SET

or something like this.
.
Clayton_12
Frequent Advisor

Re: copying data with rights and protection intact accross remote nodes?

The way I see it now , the best solution is to first backup the root directory into one saveset , restore without [...] output specification

And then restore data saveset with the [...]
output specification:



backup /verify /record /ignore=(interlock) device:[000000]*.dir userdata:[username]rootdirfile.bck /saveset
backup /verify /record /ignore=(interlock) device:[*...] userdata:[username]file.bck /saveset

I copy the file to the 8.2 system then restore the data:


then first restore the root tree structure:
device:[backups]rootdirfile.bck.bck/saveset device:[newdir] /by_owner=original

This gives the root directories with ACLS

then restore all files by command:
device:[backups]file.bck.bck/saveset device:[newdir...] /by_owner=original

IS the the best solution?

Thx
Clayton

Jan van den Ende
Honored Contributor

Re: copying data with rights and protection intact accross remote nodes?

Clayton,



IS the the best solution?


I don't know if it is THE best solution, but it sure is a GOOD solution, and it is straightforward.

Success!

Proost.

Have one on me.

jpe

Don't rust yours pelled jacker to fine doll missed aches.
Clayton_12
Frequent Advisor

Re: copying data with rights and protection intact accross remote nodes?

AS per my last reply first create root directory with back saveset , then restore all files and subdirectories from another saveset into this strucutre.


Thx for all feedback, as always every contribution was very helpful in learning about the topic at hand and OPENVMS as well.

CLayton
Jan van den Ende
Honored Contributor

Re: copying data with rights and protection intact accross remote nodes?

Oh, on second thought,


backup /verify /record /ignore=(interlock) device:[000000]*.dir userdata:[username]


perhaps it is better to /EXCLUDE 000000.DIR here.
All kinds of strange effects can occur if you create a 000000.DIR in your MFD.
The one you (and a BACKUP command!) normally see there is in fact a self-reference, but upon restore sometimes (and I still have not found out exactly WHEN and WHEN NOT) a real one gets created. Better safe than sorry!

As an aside: what goal is served here by /RECORD?

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
Clayton_12
Frequent Advisor

Re: copying data with rights and protection intact accross remote nodes?

Record is just a throw back from the existing system backup command files that I didn't take out.

I had the 000000 problem when I restored the *.dir saveset with [newdir...] output qualifier but not with the [newdir] qualifier. I shall use the /exclude qualifier.

Thanks Again
Clayton