topic Re: user database in Operating System - OpenVMS

user database

umesh_singapore — Mon, 05 May 2008 05:18:13 GMT

Can we copy user database ( SYSUAF.DAT, RIGHTSLIST.DAT,NET$PROXY.DAT ) files from OVMS 7.3-2 to v8.3 system,

If yes ? then only these DAT files enough to move database or else .

Re: user database

Heinz W Genhart — Mon, 05 May 2008 05:27:49 GMT

Hi Umesh_Singapore

First of all welcome to the ITRC OpenVMS Forum

Yes, you can copy those files. I would recommend to copy also NETPROXY.DAT (old Format Proxy Database). If You copy SYSUAF.DAT, RIGHTSLIST.DAT, NET$PROXY.DAT and NETPROXY.DAT you have moved the user Database.

Regards

Geni

Re: user database

Jan van den Ende — Mon, 05 May 2008 06:32:48 GMT

umesh_singapore,

Welcome from me too!

In addition to what Geni wrote, if you are using TCPIP, then also copy TCPIP$PROCY.DAT

Success.

Proost.

Have one on me.

jpe

Re: user database

Wim Van den Wyngaert — Mon, 05 May 2008 06:33:17 GMT

But don't forget to boost the quotas.
http://forums12.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1209972706099+28353475&threadId=1168142

Wim

Re: user database

Jan van den Ende — Mon, 05 May 2008 06:34:06 GMT

Oops.

TCPIP$PROCY.DAT should have been TCPIP$PROXY.DAT

Proost.

Have one on me.

jpe

Re: user database

Robert Gezelter — Mon, 05 May 2008 08:57:35 GMT

umesh_singapore,

You can move your users by copying the SYSUAF, RIGHTSLIST, and various proxy files, as has been mentioned by other posters.

There are two cautionary notes:

- (as has been mentioned) check whether the quotas need to be increased, and either change them in the authorization files or increase the system-wide minimums

- please ensure that the various UICs created for layered products are the same in the 8.3 system and the 7.3-2 system that the files are being copied from.

Subject to those two cautions, this is an operation that I have done many times.

- Bob Gezelter, http://www.rlgsc.com

Re: user database

Hoff — Mon, 05 May 2008 12:39:58 GMT

With specific investigation of your old and your new configuration, and with some likely changes needed, yes, you can do this.

Why do I mention the need for work? There are binary values that can be or are written all over the disks, files, queues, devices, etc., that originate in these files, so you can end up having unintended access blocks, unexpected permits, and unexpected ownership.

If you're just looking to move users over (merge), I'd tend to move over the specific attributes over (username, salt, hashed password, directory, etc) with a duplicate check. (A MERGE/STABLE/NODUPL command can potentially be used here.)

But you need to be aware of the binary values of the identifiers (resource, subsystem, UIC, etc), and where these are used on your old and your new environment.

You'll need to weed out the usual collisions, as the old and newly-minted environments tend not to have the same UIC values for the common server accounts, for instance. Which means you need to pick one of the two UIC values (the one from the new environment tends to be the best choice here) and use that one. TCP/IP Services and DECnet, for instance, can have server accounts, as can many layered products.

It's not quite as transparent or as simple as it should be, if you're looking to deal with all of the pieces related to security.

Here's some related reading material:

http://64.223.189.234/node/169

Re: user database

Hein van den Heuvel — Mon, 05 May 2008 14:33:07 GMT

Just some additional hints...

Typically those files are in use on a system, so a simple COPY command might not do.

You could use BACKUP/IGNORE=INTERLOCK, but runa minor risk of picking up a bad file.

The best way to copy those actively used indexed files is :
$CONVERT/SHARE x.dat x.copy

You MAY want to convert to a sequential file:
$CONVERT/SHARE/FDL=NL: x.dat x.seq

And on the receiving side, instead of replacing the target file you can ADD the missing records, leaving the 'system' records and original file in place:
$CONVERT/STAT/MERGE/SHARE/EXCEP=x.dups x.seq x.dat

- That MERGE is optional... a new file is preferred.

- That input does not have to be sequential, it can be indexed.

- Many more postings exist on this topic in the official doc as well as ITRC and c.o.v and Hoff's site. Google is your friend.

Hein.

Re: user database

John Gillings — Mon, 05 May 2008 21:45:20 GMT

There are many other files to consider! just a few extras which might be relevant:

VMSMAIL_PROFILE.DATA
VMS$PASSWORD_HISTORY.DATA
VMS$PASSWORD_DICTIONARY.DATA
SYSALF.DAT
VMS$OBJECTS.DAT

See SYLOGICALS.TEMPLATE and cross reference with the cluster manuals.

This is an area where OpenVMS really is very ugly and clumsy. It's very difficult to work out exactly what files you need to define your environment. I really wish OpenVMS engineering would get its act together and give us decent tools for managing system data bases (creation, maintenance, backup, restore, move, transfer to another system etc...). It's especially important for multi system disk clusters.

Re: user database

Neelmani Pandey — Wed, 14 May 2008 12:20:04 GMT

Hi Umesh ,

First of all message me your no on my email,

Neel this side i think u might hav got me.

Waise sab chalegi u can copy.

He he ..