copying data with rights and protection intact accross remote nodes?

[Clayton_12]

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

[Uwe Zessin]

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]

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.

[Arch_Muthiah]

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

[Arch_Muthiah]

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

[Jan van den Ende]

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

[Arch_Muthiah]

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

[Bart Zorn_1]

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]

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]

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


Thx
Clayton

[Uwe Zessin]

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]

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

Thx
Clayton

[Uwe Zessin]

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.]

" 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.

[Clayton_12]

Thx for responses.

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

[Uwe Zessin]

Use /BY_OWNER=ORIGINAL as an output qualifier.

[Clayton_12]

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 · Accepted solution]

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]

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]

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

[Clayton_12]

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]

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

[Clayton_12]

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