topic Re: I modified the SYSUAF.DAT ,can not log in in Operating System - OpenVMS

I modified the SYSUAF.DAT ,can not log in

likuair_1 — Thu, 20 Mar 2008 03:32:54 GMT

I modified sysuaf.dat,and all the user name can not be used ,how can i log into the system?using DVD or other way?

Re: I modified the SYSUAF.DAT ,can not log in

Phil.Howell — Thu, 20 Mar 2008 04:58:20 GMT

boot from installation cd
restore sysuaf and rightslist from backup.
if you used a text editor on sysuaf.dat you may find that version ;-1 still exists, then you can just rename the spurious one
Phil

Re: I modified the SYSUAF.DAT ,can not log in

Karl Rohwedder — Thu, 20 Mar 2008 05:12:37 GMT

How did you modify SYSUAF.DAT? Using the AUTHORIZE utility or just a text-editor?

regards Kalle

Re: I modified the SYSUAF.DAT ,can not log in

Robert Gezelter — Thu, 20 Mar 2008 05:51:39 GMT

likuair,

The system authorization file can generally only be modified using the AUTHORIZE utility.

If the file was modified using a conventional text editor, then it was likely damaged. In most cases, the editor saved the file as a new version. This can be confirmed by doing a DIRECTORY SYSUAF.DAT;* command. If this was done, there should be two versions of the SYSUAF.DAT file. If so, the newest version (the version with the larger number) can be deleted.

A note of caution that probably does not apply in this specific situation. It is possible that the SYSUAF has been redirected using a logical name. This would change the above advice somewhat.

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

Re: I modified the SYSUAF.DAT ,can not log in

Volker Halle — Thu, 20 Mar 2008 09:48:13 GMT

There are also the Emergency Booting sequences described in the OpenVMS Upgrade and Installation Guide:

http://docs.hp.com/en/BA322-90077/index.html

Volker.

Re: I modified the SYSUAF.DAT ,can not log in

Hoff — Thu, 20 Mar 2008 13:18:23 GMT

Your reference to DVD implies this is OpenVMS I64 V8.2 system, or a later release of OpenVMS I64.

It appears that SYSUAF wasn't so much as modified here, but that it was (somehow) corrupted. The details on how the corruption arose are critical to how to resolve this; on what steps led up to the corruption.

I'd probably first take a complete disk BACKUP /IMAGE, using the bootable DVD environment. This to save off a copy, should the recovery efforts not proceed as planned. The copy allows resetting the system back to its corrupted state, and another attempt at resolving the error.

If the SYSUAF file was edited directly and PURGE was invoked, you'll likely need to restore it from your most recent BACKUP. But if the file was directly edited and the editing session then exited and there was no PURGE, a lower version of SYSUAF is likely still valid, and can be used.

You can potentially RENAME the top version(s) out of the way, and bring the valid SYSUAF back to the top of the version stack. If there were several edits of SYSUAF, there will be several versions.

If AUTHORIZE was used and not direct access into SYSUAF, then something that was changed has locked out the accounts. Recovery here involves reversing whatever happened, using AUTHORIZE. Or a restoration from BACKUP, if that fails.

To get to where you can enter commands to resolve the immediate access problem, you can follow the steps below:

http://64.223.189.234/node/204
http://64.223.189.234/node/280

And when you get to the $ prompt here, you'll be able to enter SET NOON and then some DCL commands. The commands depend on what you did to corrupt the file.

If you edited and exited SYSUAF, the command could move (RENAME) the higher version(s) of SYSUAF out of the way.

If the corruption involved use of AUTHORIZE, you could invoke AUTHORIZE and re-enable SYSTEM or other username.

This is a very limited environment, so various mechanisms will not work as you might expect.

Restoring a BACKUP (of some or all of your system disk) is among the last and least desirable approaches to use here, as you can need to restore other files tied to SYSUAF if your BACKUP is sufficiently old and you're making a file-based recovery attempt, and password changes and such made between the BACKUP and the corruption will be lost. The safest approach is a whole-disk recovery, at least in terms of consistency. It may come to this, but you want to avoid it.

Do also review your BACKUP cycle, and do consider the installation and configuration of a testing system or a bootstrap into a testing environment. Making changes in a production environment is not without its hazards. Even the most experienced of OpenVMS system managers can occasionally botch a critical command or a critical operation.

Stephen Hoffman
HoffmanLabs LLC