- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: User(s) transfer from 7.2 to 8.3
Operating System - OpenVMS
1755392
Members
2661
Online
108832
Solutions
Forums
Categories
Company
Local Language
юдл
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
юдл
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Go to solution
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-14-2011 08:37 AM
тАО03-14-2011 08:37 AM
Re: User(s) transfer from 7.2 to 8.3
Are you moving the users to new tin?
If so, I wouldn't ship anything but provide new.
Use it as an opportunity to rationalise and strip out all the crud that will have gathered on the system over the years.
Use new physical device names, logical names, usernames (possibly a new VMS username standard), etc..
Craig
If so, I wouldn't ship anything but provide new.
Use it as an opportunity to rationalise and strip out all the crud that will have gathered on the system over the years.
Use new physical device names, logical names, usernames (possibly a new VMS username standard), etc..
Craig
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-14-2011 11:25 AM
тАО03-14-2011 11:25 AM
Re: User(s) transfer from 7.2 to 8.3
Given that there's no f$getuai DCL lexical function, here's the GETUAI tool, a tool that extracts the specified UAF record contents into DCL symbols, and which could be the basis for a locally-written migration procedure:
http://labs.hoffmanlabs.com/node/1205
if you'd prefer to get out of the business of adding and maintaining this stuff and allow folks to enroll themselves and allows them to reset their own passwords, here's the NEWUSER tool:
http://labs.hoffmanlabs.com/node/1260
If you do decide to port over the contents of the core authorization files in bulk, do expect to have to resolve the inevitable UIC and binary identifier values collisions; these tend to collide. (This wouldn't be my preferred approach, but I've used it.)
Here are the list of files that are shared, and that can have either host or usernames or UICs or identities embedded:
http://labs.hoffmanlabs.com/node/169
That's likely a few more files than you will have to deal with here, but it's a start, and it describes the files that are shared in a cluster.
As for cleaning off stale identifiers in file ACLs and such, here's an ACL_SCRUB tool:
http://labs.hoffmanlabs.com/node/426
Here's a general write-up on creating OpenVMS users:
http://labs.hoffmanlabs.com/node/856
And as Craig A comments, I'd start over again and haul over as little as possible, if that's at all feasible. VMS systems tend to build up huge accretions over the years, odd defaults and settings, weird logical names and all that dreck makes the management more complex, and can lead to higher direct and indirect support costs. (You can end up paying for the support for products and licenses that you aren't using anymore, for instance.)
http://labs.hoffmanlabs.com/node/1205
if you'd prefer to get out of the business of adding and maintaining this stuff and allow folks to enroll themselves and allows them to reset their own passwords, here's the NEWUSER tool:
http://labs.hoffmanlabs.com/node/1260
If you do decide to port over the contents of the core authorization files in bulk, do expect to have to resolve the inevitable UIC and binary identifier values collisions; these tend to collide. (This wouldn't be my preferred approach, but I've used it.)
Here are the list of files that are shared, and that can have either host or usernames or UICs or identities embedded:
http://labs.hoffmanlabs.com/node/169
That's likely a few more files than you will have to deal with here, but it's a start, and it describes the files that are shared in a cluster.
As for cleaning off stale identifiers in file ACLs and such, here's an ACL_SCRUB tool:
http://labs.hoffmanlabs.com/node/426
Here's a general write-up on creating OpenVMS users:
http://labs.hoffmanlabs.com/node/856
And as Craig A comments, I'd start over again and haul over as little as possible, if that's at all feasible. VMS systems tend to build up huge accretions over the years, odd defaults and settings, weird logical names and all that dreck makes the management more complex, and can lead to higher direct and indirect support costs. (You can end up paying for the support for products and licenses that you aren't using anymore, for instance.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-23-2011 09:02 PM
тАО03-23-2011 09:02 PM
Re: User(s) transfer from 7.2 to 8.3
Hi Niall,
I've also had to deal with the problem of moving a batch of users from one system to another. Copying SYSUAF and RIGHTSLIST is one method but I prefer to merge the old and new instead.
First you need to confirm that the users to be moved don't have UICs which conflict with any existing users on the destination server. (In your case it sounds like you're building a new server so this shouldn't be a problem.)
Secondly you need to get a list of all the Rights Identifiers on the existing system using
$ MCR AUTHORIZE LIST/ID/FULL *
which will create RIGHTSLIST.LIS. Armed with this information, create the Identifiers on the new system. It's best if you can preserve the identifier values otherwise you risk breaking any ACLs which might be present in your filesystem.
Then to move the users I use EDIT/TPU to edit the SYSUAF.DAT file from the old system, removing the users which aren't going to be moved, then saving the file to (say) USERS.TXT. I copy USERS.TXT to the new system then merge it into the UAF there using
$ CONVERT/MERGE USERS.TXT SYS$SYSTEM:SYSUAF.DAT
The next step is to create rights identifiers for all the moved users. The ADD/IDENT/USER= command within AUTHORIZE is the easiest way, in my experience.
Once the user Rights Identifiers are created you need to grant any other Identifiers to each user. Use the RIGHTSLIST.LIS file to guide you. (If you're good at TPU it's not hard to turn this into a list of GRANT/IDENT commands.)
Other steps might include moving the users' directories using BACKUP (unless the disks are being moved from the old machine to the new) and possibly changing the users' default device and directory in SYSUAF.
Regards,
Jeremy Begg
I've also had to deal with the problem of moving a batch of users from one system to another. Copying SYSUAF and RIGHTSLIST is one method but I prefer to merge the old and new instead.
First you need to confirm that the users to be moved don't have UICs which conflict with any existing users on the destination server. (In your case it sounds like you're building a new server so this shouldn't be a problem.)
Secondly you need to get a list of all the Rights Identifiers on the existing system using
$ MCR AUTHORIZE LIST/ID/FULL *
which will create RIGHTSLIST.LIS. Armed with this information, create the Identifiers on the new system. It's best if you can preserve the identifier values otherwise you risk breaking any ACLs which might be present in your filesystem.
Then to move the users I use EDIT/TPU to edit the SYSUAF.DAT file from the old system, removing the users which aren't going to be moved, then saving the file to (say) USERS.TXT. I copy USERS.TXT to the new system then merge it into the UAF there using
$ CONVERT/MERGE USERS.TXT SYS$SYSTEM:SYSUAF.DAT
The next step is to create rights identifiers for all the moved users. The ADD/IDENT/USER= command within AUTHORIZE is the easiest way, in my experience.
Once the user Rights Identifiers are created you need to grant any other Identifiers to each user. Use the RIGHTSLIST.LIS file to guide you. (If you're good at TPU it's not hard to turn this into a list of GRANT/IDENT commands.)
Other steps might include moving the users' directories using BACKUP (unless the disks are being moved from the old machine to the new) and possibly changing the users' default device and directory in SYSUAF.
Regards,
Jeremy Begg
- « Previous
-
- 1
- 2
- Next »
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP