The OpenVMS Frequently Asked Questions (FAQ)
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:
- 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.
- 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:
On Alpha:
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:
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.
- 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
|
- 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
|
- 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.
- 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:
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.
|
