HP OpenVMS Systems Documentation

Content starts here

The OpenVMS Frequently Asked Questions (FAQ)


Previous Contents Index

4.8 Using w32time or an SNTP as a time provider?

No standards-compliant NTP or SNTP server is reportedly capable of synchronizing with the Microsoft Windows w32time services.

Further, NTP clients are not generally capable of synchronizing with an SNTP server.

Open Source (Free) NTP servers (qv: OpenNTP) are available for Microsoft Windows platforms, and TCP/IP Services and third-party packages all provide NTP servers for OpenVMS, and NTP and SNTP clients can synchronize with these srvers.


Chapter 5
System Management Information

If you are searching for something here, please consider using the text-format FAQ.

5.1 What is an installed image?

The term "install" has two distinct meanings in OpenVMS. The first relates to "installing a product", which is done with either the SYS$UPDATE:VMSINSTAL.COM command procedure or the POLYCENTER Software Installation (PCSI) utility (PRODUCT command). The second meaning relates to the use of the INSTALL utility, which is what concerns us here.

The INSTALL utility is used to identify to OpenVMS a specific copy of an image, either executable or shareable, which is to be given some set of enhanced properties. For example, when you issue the SET PASSWORD command, the image SYS$SYSTEM:SETP0.EXE is run. That image needs to have elevated privileges to perform its function.

The other important attribute is /SHARED. This means that shareable parts of the image (typically read-only code and data) are loaded into memory only once and are shared among all users on a system. Executable images can be installed /SHARED as well as shareable library images. (The term "shareable" has dual meanings here, too. See the OpenVMS Programming Concepts Manual for further details.)

It's important to note that there is no such thing as "installing a shareable image with privileges". The INSTALL utility will let you do it, but the privileges you specify will be ignored. To have a callable routine run with enhanced privileges that are not available to its caller, you must construct your routines as "user-written system services" (UWSS) and install the shareable image with the /PROTECT qualifier. See the OpenVMS Programming Concepts Manual for more information on user-written system services. Note also that in many cases the need to grant privileges to an image can be replaced with the use of the "Protected Subsystems" feature that grants a rights identifier to an image. See the OpenVMS Guide to System Security for information on Protected Subsystems.

5.2 Are there any known viruses for OpenVMS?

Viruses and worms are common on personal computers because the operating systems involved, such as the Microsoft MS-DOS, Windows 95, Windows 98 and Windows ME variants, do not particularly protect the operating system or the file system against hostile action by programs. Microsoft Windows NT, Windows 2000 and Windows XP do implement protections for specific configurations and do implement memory protection models, but many users of these systems choose to operate with full adminstrator access and thus the available protections are entirely defeated and entirely not relevent, and any program that can activate itself or can cause the user to activate the code can subvert the operating system and take over the hardware, at which point the malicious code can do most anything it wishes, including hiding copies of itself in other programs or in the file system, redistributing itself via mail, IM, or network connections, or can be used as a zombie in staging attacks on other systems.

This is less likely with multi-user systems such as OpenVMS, Unix, Linux, MVS and other platforms for various reasons. First, the operating system runs in a privileged mode in memory that is protected against modification by normal user programs. Any program cannot simply take over the hardware as it can on operating systems without security and particularly without memory page protections. Secondly, multi-user systems can be set up so that non-privileged programs cannot modify system programs and files on disk, and this is normal for most installations. Both of these protection schemes mean that traditional viral infections don't work on these OSes. Third, typical applications and configurations tend to prevent the uncontrolled execution of untrusted code as part of received mail messages or web access; one of the central vulnerabilities of the Microsoft Windows platform involves its intentionally easy ability to dynamically (and transparently) activate code and macros that are embedded within mail messages and within data files.

It is possible for OpenVMS and other multi-user systems to become infected by viruses or worms, but to do so, the program containing the virus must be run from a user account that has amplified privileges. So long as the system administrator is careful that only trusted applications are run from such accounts (and this is generally the case) and so long as there are no OpenVMS system security breaches (due to malicious operator activity, OpenVMS errors, or errors within trusted and privileged product packages) there is no of modifications to the operating system or other protected files from the virus or the worm.

The FAQ maintainer is aware of a few (and very old) DECnet worms that have affected OpenVMS systems on DECnet networks ("WANK" was one), but is aware of no OpenVMS viruses that are loose in the field.

To protect against viruses and other attempts at system interference or misuse, please follow the security recommendations in the OpenVMS Guide to System Security. Additionally, you will want to keep your OpenVMS ECOs current and you will want to apply all mandatory ECO kits and any security MUPs for OpenVMS and OpenVMS products, and you will want to keep to OpenVMS releases with Prior Version Support (PVS) or with Current Version Support. (This is obviously a general system maintenance recommendation, in addition to being a good system security recommendation---new security features and capabilities are implemented in more recent OpenVMS releases, for instance. Details on PVS releases are available over in Section 5.10.6.) You may also want to consider optional software products which can monitor your system for intrusion or infection attempts. Computer Associates (CA) offers various products in this area, as to other vendors.

Rocksoft offers the Veracity data integrity tool (for info, send mail to demo@rocksoft.com). MD5 tools are also available.

Tools to scan OpenVMS file systems for Microsoft Windows infections are and have been available, including a commercial package from Sophos , and a port of the open source Clam Antivirus scanner at http://www.clamav.net/ and with an OpenVMS port at http://fafner.dyndns.org/~alexey/clamav.zip .

These scanning tools are particularly useful for systems running Samba or Advanced Server (PATHWORKS), as these servers tend to have a higher population of files intended for Microsoft Windows systems users, and as common virus and worm attacks can find and infect files on the file shares that these products can provide. These infections do not target OpenVMS itself, though the OpenVMS server (and any other platform and any other server capable of storing files for Windows systems) can silently host files containing common Microsoft Windows infections.

5.3 Sources of OpenVMS security information?

Where can I get information on OpenVMS system security?

5.4 How do I mount an ISO-9660 CD on OpenVMS?

ISO-9660 support was added in the following releases:

  • OpenVMS VAX V6.0
  • OpenVMS AXP V1.5

An add-on ISO-9660 kit was also available for OpenVMS VAX V5.5, V5.5-1, V5.5-2, and V5.5-2H4. This requires the installation of the F11CD kit from the InfoServer CD, from the Consolidated Distribution CD under the InfoServer area, or the F11CD ECO kit. (Upgrades to V6 and later are strongly recommended.)

By default, OpenVMS senses the specific type of media. If you are working with dual-format media---media that uses both the ODS-2 and ISO-9660 formats on the same CD-ROM---then MOUNT will first detect and then default to the ODS-2 format. If you wish to override this and explicitly mount the media using ISO-9660, use the command:


$ MOUNT/MEDIA_FORMAT=CDROM  device-name[:] [volume-label]

In most circumstances, you will not need nor will you want to include an explicit /MEDIA_FORMAT specification. For further information, please refer to the OpenVMS MOUNT Utility Manual. Particularly note the information on the MOUNT /MEDIA_FORMAT and /UNDEFINED_FAT qualifiers.

The MOUNT /UNDEFINED_FAT qualifier is of interest because ISO-9660 media can be mastered on a wide variety of operating system platforms, and these platforms do not necessarily support the semantics needed for files containing predefined record formats. The /UNDEFINED_FAT allows you to specify the default attributes for files accessed from volumes using the ISO-9660 format.

An example which works for most CD-ROMs is:


$ MOUNT/MEDIA_FORMAT=CDROM/UNDEFINED_FAT=STREAM:2048 DUA0: FREEWARE

This particular MOUNT command forces access to the CD-ROM media using the ISO-9660 volume structure, and the use of the MOUNT /UNDEFINED_FAT qualifier causes any file whose file attributes are "undefined" to be returned with "stream" attributes with a maximum record length 2048.

On OpenVMS, the ISO-9660 format is (internally) considered to be the ODS-3 file structure, while the High Sierra extensions to the standard are considered to be the ODS-4 file structure. The Rock Ridge extensions are not currently available on OpenVMS.

For details on ODS-1 and ODS-2 file specifications, see Kirby McCoy's VMS File System Internals Manual (published by Digital Press, but potentially out of print), and see:

5.5 How do I extract the contents of a PCSI kit?

A growing number of OpenVMS products are being provided in PCSI (POLYCENTER Software Installation) kits which are installed using the PRODUCT INSTALL command. These are alternatives to or replacement for VMSINSTAL kits which were BACKUP savesets. PCSI kits are not BACKUP savesets and are structured differently from VMSINSTAL kits.

If you want to extract product files from a PCSI kit, create a directory into which the kit should be expanded and use the following command:


$ PRODUCT COPY prodname /SOURCE=[where-the-kit-is] -
    /DEST=[destination-directory] /FORMAT=REFERENCE

A PCSI kit file has a file specification of the following form:


DEC-VAXVMS-FORTRAN-V0603-141-1.PCSI

In this example, "FORTRAN" is the "prodname". PCSI will expand the kit files into the directory you specify and subdirectories beneath such as [SYSEXE], [SYSLIB], etc., reflecting the eventual destination of files found there. Most of the actual product files (images, etc.) will be in the subdirectories. In the top-level directory will be a file with the file type PCSI$DESCRIPTION that specifies where various files should go. For more details, see the POLYCENTER Software Installation Developer's Guide for OpenVMS, which can be found in the OpenVMS documentation on the Consolidated Online Documentation CD-ROM.

5.6 Emergency (Conversational) System Startup?

If you need to perform system management operations on an OpenVMS system and cannot access the system through normal means---the password on the SYSTEM username was forgetten and no other privileged usernames are available, or one or more core system product authorization key (PAK) software licenses are unavailable or expired---then you must perform a conversational (emergency) bootstrap.

Here are the steps:

  1. Halt the system. Exactly how this is done depends on the specific system model: Depending on the model, this can involve pressing the [HALT] button, entering [CTRL/P] on the console, or pressing the [BREAK] key on the console.
  2. At the console prompt, use a console command to boot into the SYSBOOT utility. (SYSBOOT allows conversational changes to system parameters.) (The console syntax for the conversational bootstrap varies by system model and by system architecture---this typically involves specifying a flag with the lowest bit set. See Section 14.3.5 for related details.) For example:
    On VAX, use one of the following three commands depending on the particular model of VAX system involved:


    B/R5:1
    B/1
    @GENBOO
    

    On Alpha:


    b -flags 0,1
    

    If your system has a non-zero system root (such as root SYSE, shown here), you will have to use a console command such as the following:
    On VAX:


    B/E0000001
    B/R5:E0000001
    @<console media procedure name varies widely>
    

    On Alpha:


    b -flags e,1
    

    On the IA-64 architecture systems, you can establish and manage an EFI boot alias for a conversational bootstrap as discussed in Section 14.3.5.1 and in Section 14.3.10, or you can use VMS_LOADER.EFI interactively as shown here. Of the core mechanisms discussed in Section 14.3.5.1, the following uses an EFI Shell command to perform a conversational bootstrap of root SYSE via the partition device fsn:. There are alternative mechanisms available.


    fsn:\efi\vms\vms_loader.efi -flags e,1
    

    If your Alpha system has a hardware password (various systems support a password that prevents unauthorized access to the console), you will need to know theis password and will need to enter it using the LOGIN or similar command at the console. If you get an "Inv Cmd" error trying to perform a conversational bootstrap, and you do not have the hardware console password for the console LOGIN command, you are stuck---you will need to call for hardware service for assistance in resetting the hardware console password. The implementation and the syntax used for the console password mechanism does vary by implementation.
  3. Once at the SYSBOOT prompt, request that OpenVMS read the system startup commands directly from the system console, that the window system (if any) not be started, and that OpenVMS not record these particular parameter changes for subsequent system reboots:


    SET/STARTUP OPA0:
    SET WINDOW_SYSTEM 0
    SET WRITESYSPARAMS 0
    CONTINUE
    
  4. At the $ prompt, the system will now be accepting startup commands directly from the console. Type the following two DCL commands:


    $ SPAWN
    $ @SYS$SYSTEM:STARTUP
    
  5. You should now see the dollar ($) prompt of DCL.
    The result of these two commands will be the normal system startup, but you will be left logged in on the console, running under a fully privileged username. Without the use of the SPAWN command, you would be logged out when the startup completes.
    Perform the task(s) required, such as resetting the password on the SYSTEM username as described in Section 5.6.1 or registering one or more license product authorization keys (PAKs) as described in Section 5.6.2.
  6. Once you log out of this session, the system will complete the startup and can be used normally. You can choose to reboot the system, but that is not necessary.

Some system managers will suggest a method using the UAFALTERNATE system parameter rather than the SET/STARTUP OPA0: command shown. This approach is not always available and is accordingly less commonly recommended, as there can easily be an alternate user authorization database (SYS$SYSTEM:SYSUAFALT.DAT) configured on the system. With a system manager that has configured an alternate SYSUAFALT.DAT file, the UAFALTERNATE method will fail---well, assuming you do not know the password of a privileged username stored within SYSUAFALT.DAT, of course.

The UAFALTERNATE system parameter is used to trigger what is sometimes known as the console backdoor. The OPA0: system console is critical to system operations and system security, and will allow access when the SYSUAF system authorization database is unavailable or corrupted, when core product license PAKs are not registered, expired or disabled (NOLICENSE errors), or in various other cases of system failures. All this is in addition to the role of the console in the display of certain system-critical event messages. Access to the OPA0: console has a security exposure that is equivalent to direct access to the system hardware.

When LOGINOUT detects an error (such as a SYSUAF corruption, by a missing SYSUAF, missing product licenses, or other trigger), it will prevent access to the OpenVMS system from all terminals except the system console. The OPA0: system console will be allowed access, and the resulting process will be fully privileged. Resetting the UAFALTERNATE system parameter---in the absence of an alternate SYSUAF system authorization database---will cause the console backdoor to be opened simply because LOGINOUT cannot locate SYS$SYSTEM:SYSUAFALT.DAT. When the authorization database cannot be located, access will be granted from the console only.

For further information on emergency startup and shutdown, as well as for the official OpenVMS documentation on how to change the SYSTEM password from the console in an emergency, please see the OpenVMS System Manager's Manual in the OpenVMS documentation set.

For information and recommendations on setting up OpenVMS system security, please see the NCSC Class C2 appendix of the Guide to OpenVMS System Security manual, also in the OpenVMS documentation set.

You can also use the conversational bootstrap technique shown earlier (the steps until SET/STARTUP) to alter various system parameters, as well. At the SYSBOOT prompt, you can enter new parameters values:


SHOW MAXPROCESSCNT
SET . 64
CONTINUE

The [.] is a shorthand notation used for the last parameter examined within SYSGEN and SYSBOOT.

5.6.1 I've forgotten the SYSTEM password - what can I do?

If you have forgotten or do not have the password for the SYSTEM username, you must perform the conversational bootstrap as described in Section 5.6, and must enter the following commands once you have reached the dollar ($) prompt:


$ SET DEFAULT SYS$SYSTEM:  ! or wherever your SYSUAF.DAT resides
$ RUN SYS$SYSTEM:AUTHORIZE
MODIFY SYSTEM /PASSWORD=newpassword
EXIT

You have now reset the password on the SYSTEM username.

5.6.2 My product licenses have expired - what can I do?

If you have a system with no licenses for OpenVMS or for OpenVMS users and thus cannot log into the OpenVMS system normally, you should be able to log into the console serial terminal---this is the terminal device known as OPA0:---and perform the commands necessary.

For systems that are not configured with an accessable console serial terminal---as can be the case with how some DECwindows workstations are configured---you must log in over the network or from a local serial connection. If you cannot log in over a network connection (SET HOST, telnet, etc) or from another local serial terminal connection, you will have to halt the system and perform a conversational bootstrap as described in Section 5.6. You must then enter licensing-related commands once the conversational bootstrap has reached the dollar ($) prompt.

Use the following DCL command to invoke a menu that allows you to manage and to register new or replacement license PAKs:


$ @SYS$UPDATE:VMSLICENSE

You have now registered the license PAKs. Direct use of the DCL commands LICENSE and SHOW LICENSE and such is also obviously available.

If you wish to connect a serial console on your DECwindows workstation, please see Section 14.3.3.3, Section 14.3.6, Section 11.10, and Section 14.17.

For information on troubleshooting DECwindows, please see Section 11.5.

5.7 How do I change the node name of an OpenVMS System?

The first step is to get a BACKUP of the system disk before making any changes---use the system disk backup procedures as documented in the OpenVMS System Management Manual, making sure to use the procedures and commands appropriate for the system disk.

Changing the node name involves a number of steps---the node name tends to be imbedded in a number of different data files around the system.

  • Update the SCSNODE in MODPARAMS.DAT, and then run AUTOGEN as far as the SETPARAMS phase. (Do not reboot yet.)
  • Modify the DECnet node name. (NETCONFIG is the DECnet Phase IV tool, and NET$CONFIGURE is the DECnet-Plus tool.)
  • Modify the host node name on the various queues in the queue database. (each queue has a host name, and it defaults to the SCS node name of the queue's host system. See the command INIT/QUEUE/ON=node for information.) Site-specific startup command procedures can explicitly specify the (local or even the current) node on the /ON parameter in an INIT/QUEUE/START/ON= command.
  • Modify the node name saved in any application databases, or any local node-conditional operations present in the site-specific system startup, etc. (SEARCH for the node name, specifying all types of files.)
  • Use the AUTHORIZE utility command RENAME/IDENTIFIER to rename the SYS$NODE_oldnodename rightslist identifier to match the new node name. (Do not change the binary value of this identifier, and do not delete the identifier.)
    If you have erroneously deleted or duplicate the identifier, you can locate existing references to the binary identifier value using the Freeware DFU package, and specifically the commands SEARCH/ACE and /OWNER. You must (re)create the correctly-named identifier using the binary value that is often stored in various Access Control List Entry (ACE) structures and object owner fields associated with files and objects present in the OpenVMS system.
  • Reset any license PAKs that are restricted to the old node name to the new node name.
  • If the node name is part of a disk volume label, see Section 5.13.
  • Reboot the node or---if in a VMScluster---reboot the whole VMScluster. (This tends to catch any errors immediately.)
  • Modify the IP node name. (The TCP/IP Services tool is UCX$CONFIG prior to V5.0, and is TCPIP$CONFIG in V5.0 and later releases.) Note that TCP/IP Services ties the IP host name to the current SCSNODE value within its UCX$CONFIGURATION.DAT or TCPIP$CONFIGURATION.DAT database. Thus if SCSNODE is changed, the IP host name reconfiguration must occur, and the required reconfiguration can occur only after a system reboot. Accordingly, it is best to perform the TCP/IP Services host name reconfiguration step after the reboot.

There are likely a few other areas where the nodename will be stored. Local procedures and data files are one such example, and various sites will have the system name loaded in the operator control panel via the OCP_TEXT console environment variable available at the SRM prompt on some Alpha systems is another.

If the system is configured in a VMScluster and you change either the SCSNODE or the SCSSYSTEMID---but not both values---then you will have to reboot the entire VMScluster. (The VMScluster remembers the mapping between these two values, and will assume that a configuration problem has occured if a mismatched pair appears, and will refuse to let a node with a mismatched pair join the VMScluster.)

To calculate the correct SCSSYSTEMID value, multiply the DECnet Phase IV area number by 1024, and add the DECnet Phase IV node number. For example, the SCSSYSTEMID value for a DECnet node with address 19.22 is 19478. ((19 * 1024) + 22 = 19478)

This may well have missed one or two configuration tools (or more!) that are needed at your site---the node name tends to get stored all over the place, in layered products, and in local software...

Also see Section 15.6.3 and Section 15.6.4.


Previous Next Contents Index