HP Technology Forum 2006

Advanced OpenVMS System Management Techniques, Tools, and Tricks DJE Systems - http://www.djesys.com/ David J. Dachtera - [email protected]

GET CONNECTED People. Training. Technology.

© 2006 DJE Systems, All rights reserved The information contained herein is subject to change without notice

1

This presentation is intended to be displayed or printed in the “Notes View” so it reads like a text book. If you are viewing this as a “Slide View” .PDF (Adobe Acrobat file), download the .PPT (PowerPoint presentation) from: http://www.djesys.com/vms/support/1065.ppt

When published with the Symposium Session notes, this presentation might be converted to .PDF in the slide view only. Go to the URL shown to get the final PowerPoint presentation, then view it the way that works best for you.

2

Agenda Logical names Logical name tables Logical name table search order Modifying the search order

Logical name types Single Translation Search list “Rooted” (Concealed) logical names

Lexical Function Caveat F$TRNLNM() differs from F$LOGICAL()

Since much of the way the VMS environment works is driven by the use of logical names, we’ll spend a good bit of time talking about them. Questions “in real time” are encouraged during this discussion, and we can always refer back to it as we proceed into those areas where logical names are used. This will provide an opportunity for reinforcement through practical examples. We’ll also discuss a few “gotcha”’s regarding DCL lexical functions as they relate to OpenVMS and system management.

3

Agenda Logical names, cont’d Cluster-wide logical names Caveats

SYS$COMMON Notes Caveats (VMS$COMMON)

Site-Specific Paths Organizing local system management code

In the newer versions of OpenVMS, Cluster-wide logical name tables were introduced. While these did not introduce any new complexity, working with them is not as straight-forward as it might appear at first glance. We’ll take a look at some practical examples of why the VMS$COMMON directory is rarely - if ever - used in the many logical names that the familiar OpenVMS environment depends on.

4

Agenda Network Topics TCP/IP TCP/IP Services (fka UCX) Multinet TCPware CMU/IP (VAX only)

DECnet Access control FAL logging

TCP/IP Services (fka UCX) Access control

Continuing our discussion of the essential elements of the system and system management, we’ll take a look at a brief overview of OpenVMS and networking. We’ll look at the various TCP/IP stacks available for OpenVMS: three commercial products for VAX and Alpha and a freeware piece for OpenVMS VAX only. We’ll look at DECnet as well, and take a look at Access Control and logging as well as some undocumented logical names can that be used to modify the behavior of FAL logging.

5

Agenda Network Topics, cont’d LAT MOP Remote Access Remote procedures Types Security concerns

Network Alerts OPCOM alerts for DECnet network access OPCOM alerts for FTP network access

Relevant to the discussion of networking is network access to OpenVMS. We’ll look at some of the types and methods of remote access offered by the TCP/IP stacks, discuss some of he security concerns surrounding them. Then, we’ll look at ways to to provide expanded logging for DECnet access and access via FTP.

6

Agenda System Startup STARTUP phases STARTUP parameters Site-Specific startups Logging SYSTARTUP_VMS.COM Node-specific startups Saving a crash dump at start-up time DEFINE-ing Group Logicals Soft-coding # of logins allowed at startup

SYSMAN and STARTUP Conversational Boot, Minimal Startup

Having reviewed some of the essential elements of OpenVMS Systems and system management, we’ll start to look a bit deeper into the process of starting the OpenVMS operating environment. We’ll look at how the OpenVMS-supplied procedures work so we can understand how to function within that framework. We’ll examine the various phases of the STARTUP procedure and the parameters it uses and observes. In our discussion of site-specific startups, we’ll look at some tips and tricks for retaining a log of the site-specific startup, suggest some ways to manage startups specific to a single node or group of nodes in a cluster, we’ll look at how to save crash dump information at system startup time and we’ll at a method of soft-coding the number of logins allowed at system startup time. In recent versions of VMS, the SYSMAN utility has acquired an interface to the OpenVMS-supplied system startup procedure which allows for some customization. We’ll look into that in some detail, as well.

7

Agenda System Shutdown SHUTDOWN parameters SHUTDOWN$xxxx logical names AUTOGEN Shutdowns AGEN$SHUTDOWN_TIME logical name

Cluster Shutdown REMOVE_NODE, CLUSTER_SHUTDOWN

Being able to startup the system is only half of the story. So, we’ll look into the system shutdown procedures as well. We’ll look at the various parameters and options of the OpenVMSsupplied SHUTDOWN procedure, and some logical names that can be used to provide default values to certain SHUTDOWN parameters, including one that is used specifically by the AUTOGEN procedure. OpenVMS clusters introduce some additional shutdown-time considerations. So, we’ll look into those as well. The SYSMAN utility provides some functionality for system and cluster shutdown. We’ll look at that as well.

8

Agenda AUTOGEN MODPARAMS.DAT Reports and outputs

Useful Tips and Tricks An UPTIME command Enhanced HELP/PAGE Show logins (limit, current) A “more” command for VMS VMS disk “partitions” – Logical Disks

The system STARTUP procedure harks back to the early days of VMS, a venerable and trusted facility. As such, it contains some artifacts of its heritage that are worthy of attention. We’ll take a look at those, since they could lead to some confusion if used as a current-version example of how to program DCL procedures. AUTOGEN is a useful tool for helping to keep OpenVMS systems in tune and performing well. We’ll look at using AUTOGEN, setting values for system parameters in he MODPARAMS.DAT file, and we’ll look at the reports and outputs of AUTOGEN and how to use them.

9

Agenda OpenVMS Security Essentials UICs and File/Directory Protection Access Control Lists (ACLs) Access Control Entries (ACEs) Rights Identifiers and ACEs Propagating ACEs and Default Protections

Closing Comments, Q & A Sources of Freeware for VMS Disclaimer

Finally, if time permits, we’ll take a look at the essentials of OpenVMS System security and the various elements that make it work. Additionally, we’ll look at third-party software and freeware that can be used to help secure your systems and access to them. We’ll conclude with lists of sources for free- and open-source software for OpenVMS where one might find useful extensions for secure access to OpenVMS systems, as well as utilities and other helpful items.

10

Session 1065

OpenVMS Logical Names

11

Logical Names

A form of symbol with limited or system-wide scope. $ show logical sys$sysroot "SYS$SYSROOT" = "DJAS01$DKA300:[SYS0.]" (LNM$SYSTEM_TABLE) = "SYS$COMMON:" 1 "SYS$COMMON" = "DJAS01$DKA300:[SYS0.SYSCOMMON.]" (LNM$SYSTEM_TABLE)

A feature that is more or less unique to OpenVMS is the concept of logical names. Similar features may be present in some mainframe operating systems, also. Simply stated, logical names provide a way to represent a device name, a device name and a path name or even a device name and part of a path name in a simple way so that software, files, etc. can be easily used on and moved from one system to another, to pass data to programs and procedures or just for convenience.

12

Logical Name Tables LNM$SYSTEM_DIRECTORY LNM$JOB_xxxxxxxx LNM$GROUP_xxxxxx LNM$SYSTEM_TABLE DECW$LOGICAL_NAMES

LNM$PROCESS_DIRECTORY

Logical names are organized in logical name tables. Logical name tables exist in hierarchies, with logical name table directories at the highest or “root” levels. As supplied, VMS has two primary logical name table hierarchies. Most logical name tables are found under the LNM$SYSTEM_DIRECTORY, as shown in he example in the slide. The LNM$PROCESS_DIRECTORY is private to each process on the system and cannot be viewed from another process except by accessing data structures via routines which require privilege. This affords a degree of security for sensitive information since it cannot be easily viewed by other users.

13

Logical Name Tables Search Order: $ sh log/tab=* lnm$file_dev "LNM$FILE_DEV" = "LNM$PROCESS" (LNM$SYSTEM_DIRECTORY) = "LNM$JOB" = "LNM$GROUP" = "LNM$SYSTEM" = "DECW$LOGICAL_NAMES"

VMS provides that logical name tables can be searched by providing a search list which is itself a logical name. The LNM$FILE_DEV logical name indicates which logical names should be searched when the SHOW LOGICAL command is issued without the /TABLE qualifier or when a file is being opened or sought.

14

Logical Name Tables Modifying the search order: $ DEFINE/TABLE=LNM$PROCESS_DIRECTORY LNM$FILE_DEV LNM$PROCESS,LNM_PRIVATE,LNM$GROUP,LNM$SYSTEM,DECW$LOGICAL_NAMES •

Defines a new search list in supervisor mode. − Some software will only use “trusted” logical names in certain directories or those DEFINEd in an “inner’ (more privileged) mode.

It is possible to modify the search order specified in the LNM$FILE_DEV logical name. This can be done for individual processes, for entire UIC groups (requires GRPNAM privilege) or across the entire system (may require SYSPRV, SYSNAM and CMEXEC privilege). Note, however, that some software will only use logical names that appear in certain logical name table directories or logical name tables or are DEFINEd in a privileged access mode. It is assumed that privileged programs and procedures are “trusted”, and thus that logical names they may establish are similarly trust worthy.

15

Logical Names Single translation $ DEFINE lnm value

Search List $ DEFINE lnm value,value[,…]

Concealed Logical Names $ DEFINE lnm value/TRANS=CONCEAL

Rooted Logical Names $ DEFINE lnm ddcu:[dir.]/TRANS=CONCEAL

Here we see examples of the various forms of logical names. Single translation logical names have only one equivalence string. Search lists can have multiple equivalence strings. Concealed logical names are used in cases where it is desired that nonprivileged programs and procedures should not display the equivalence string associated with concealed logical names. Rooted logical names are used in a manner very similar to device names. The “top level” directory in a path indicated by a rooted logical is referred to as “[000000]”, just as is the Master File Directory (MFD) of a disk volume. The actual device name and root path are not displayed by nonprivileged programs and procedures. Some folks refer to rooted logicals as “pseudo disks” for that reason. See also discussion of Logical Disks later on in this presentation.

16

Logical Names Creating $ DEFINE lnm value $ ASSIGN value lnm

Deleting $ DEASSIGN lnm

There are two DCL commands for creating logical names. The DEFINE command has the logical name as its first parameter and the equivalence string(s) as the second parameter. The ASSIGN command reverses the order of the parameters: the equivalence string(s) as the first parameter, and the logical name as the second parameter. There is one DCL command for deleting logical names. The DEASSIGN command is used to delete logical names.

17

Logical Names Access Modes User DEFINE/USER SupervisorDEFINE (/SUPER is default) Executive DEFINE/EXECUTIVE, requires CMEXEC privilege. Kernel Can only be created by using the $CRELNM system service, requires CMKRNL privilege. Executive and Kernel mode logical names are “trusted” since privilege is required to create them.

Logical names are DEFINEd is one of four “access modes”. More privileged access modes are sometimes referred to as “inner” modes. User mode logical names are the lowest and least privileged level. User mode logical names are deleted when an image (a program) is run down (exits). Supervisor mode is the default access mode for both DEFINE and ASSIGN. Supervisor mode is also a low privilege level; however, supervisor mode logical names persist and are not deleted when an image (a program) is run down (exits). Executive mode is similar to Supervisor mode, but requires CMEXEC privilege. Kernel mode is the most privileged access mode. Kernel mode logical names can only be established by invoking the $CRELNM system service which is only accessible within a program. There is no /KERNEL qualifier for either the DEFINE or ASSIGN commands.

18

Logical Names Single Translation $ DEFINE lnm value

Examples: "LNM$PROCESS" = "LNM$PROCESS_TABLE" (LNM$PROCESS_DIRECTORY) "LNM$JOB" = "LNM$JOB_80D27B00" (LNM$PROCESS_DIRECTORY) "LNM$GROUP" = "LNM$GROUP_000030" (LNM$PROCESS_DIRECTORY) "LNM$SYSTEM" = "LNM$SYSTEM_TABLE" (LNM$SYSTEM_DIRECTORY) “SYS$LOGIN" = "DKA0:[DDACHTERA]" (LNM$JOB_80D27B00)

Here we see a few examples of common single-translation logical names that may be encountered on a running OpenVMS system.

19

Logical Names Search Lists $ DEFINE lnm value,value[,…] Examples: $ sh log sys$sysroot "SYS$SYSROOT" = "DJAS01$DKA300:[SYS0.]" (LNM$SYSTEM_TABLE) = "SYS$COMMON:" 1 "SYS$COMMON" = "DJAS01$DKA300:[SYS0.SYSCOMMON.]" (LNM$SYSTEM_TABLE) $ sh log user_exe ! Presenter’s environment, not provided by VMS. "USER_EXE" = "USER_IMG:" (LNM$JOB_80D27B00) = "USER_COM:" = "SYS$SPECIFIC:[SYSEXE]" = "SYS$COMMON:[SYSEXE]" 1 "USER_IMG" = "USER_ROOT:[EXE.ALPHA]" (LNM$JOB_80D27B00) 1 "USER_COM" = "USER_ROOT:[EXE]" (LNM$JOB_80D27B00)

Here we see some examples of logical names which are set up as search lists. Under the translation of SYS$SYSROOT, we also see the translation of one of its elements: SYS$COMMON. SYS$COMMON is a rooted logical as is the first translation of SYS$SYSROOT. The second example, USER_EXE is a search list that is set up in the environment of a specific user’s process. Under USER_EXE we see the translations of two of its elements, USER_IMG and USER_COM.

20

Logical Names Concealed Logical Names $ DEFINE lnm value/TRANS=CONCEAL

Example: $ sh log sys$sysdevice "SYS$SYSDEVICE" = "DJAS01$DKA300:" (LNM$SYSTEM_TABLE) $ sh log sys$sysdevice/full "SYS$SYSDEVICE" [exec] = "DJAS01$DKA300:" [concealed,terminal] (LNM$SYSTEM_TABLE)

Here we see an example of a commonly encountered system-wide logical name. SYS$SYSDEVICE is a concealed logical name created in executive mode. SYS$SYSDEVICE also has the “Terminal” attribute which means that after translating SYS$SYSDEVICE no further translation be attempted beyond the equivalence string of SYS$SYSDEVICE (in this example, “DJAS01$DKA300:”).

21

Logical Names “Rooted” Logical Names $ DEFINE lnm ddcu:[dir.]/TRANS=CONCEAL

Examples: $ show logical sys$specific,sys$common,user_root "SYS$SPECIFIC" = "DJAS01$DKA300:[SYS0.]" (LNM$SYSTEM_TABLE) "SYS$COMMON" = "DJAS01$DKA300:[SYS0.SYSCOMMON.]" (LNM$SYSTEM_TABLE) "USER_ROOT" = "DKA0:[DDACHTERA.]" (LNM$JOB_80D27B00)

Here we see two examples of commonly encountered rooted logical names. The equivalence string of SYS$SPECIFIC includes the physical name of the system disk device and the node’s boot root (“[SYS0.]”). The equivalence string of SYS$COMMON includes the physical name of the system disk device, the node’s boot root (“[SYS0.”) and the rootspecific alias for the VMS$COMMON directory (“SYSCOMMON]”).

22

Logical Names Using rooted logical names Examples: $ show logical sys$sysroot,user_root,user_com,user_img "SYS$SYSROOT" = "DJAS01$DKA300:[SYS0.]" (LNM$SYSTEM_TABLE) = "SYS$COMMON:" 1 "SYS$COMMON" = "DJAS01$DKA300:[SYS0.SYSCOMMON.]" (LNM$SYSTEM_TABLE) "USER_ROOT" = "DKA0:[DDACHTERA.]" (LNM$JOB_80D27B00) "USER_COM" = "USER_ROOT:[EXE]" (LNM$JOB_80D27B00) "USER_IMG" = "USER_ROOT:[EXE.ALPHA]" (LNM$JOB_80D27B00)

Here we see examples of system and user level uses of rooted logical names. SYS$SYROOT we saw in an earlier slide. USER_ROOT we’ve seen before, also. Here we see how it is DEFINEd. The USER_COM and USER_IMG logical names both use the rooted logical name USER_ROOT.

23

Logical Names & Lexicals Beware: F$LOGICAL() (deprecated) differs from F$TRNLNM(). F$LOGICAL() uses hard-coded search list internally: Process, Job, Group, System. F$TRNLNM() uses LNM$FILE_DEV

Something to watch out for here: Some of the older DCL procedures supplied with the system by OpenVMS use the F$LOGICAL() lexical function. F$LOGICAL() has been deprecated (made obsolete) and is no longer documented. However, OpenVMS always attempts to maintain compatibility across versions as much as possible. So, while F$LOGICAL() is no longer documented, it remains present in the system. Any new procedures that are developed should use the newer, documented F$TRNLNM() lexical function.

24

Cluster-Wide Logical Names •

New in V7.2.

•

Defined in table LNM$SYSCLUSTER

•

LNM$SYSTEM is now a search list:

$ show log/tab=* lnm$system "LNM$SYSTEM" = "LNM$SYSTEM_TABLE" (LNM$SYSTEM_DIRECTORY) = "LNM$SYSCLUSTER" 1 "LNM$SYSCLUSTER" = "LNM$SYSCLUSTER_TABLE" (LNM$SYSTEM_DIRECTORY)

A new feature in OpenVMS V7.2 is the concept of cluster-wide logical names. These are logical names that once DEFINEd on a node of the cluster are propagated to the LNM$SYSCLUSTER_TABLE of all of the nodes participating in the cluster. To facilitate this without “breaking” any existing code, the LNM$SYSTEM logical name was made a search list pointing first to the local systemwide logical name table (LNM$SYSTEM_TABLE) and then to the clusterwide logical name table. Note that LNM$SYSCLUSTER is a logical name pointing to the table of cluster-wide logical names.

25

Cluster-Wide Logical Names Caveat (pre-V8.2): • •

There is no /CLUSTER qualifier for DEFINE, ASSIGN or DEASSIGN. Use /TABLE=LNM$SYSCLUSTER

Note, however, that there is no additional qualifier provided for the DEFINE, ASSIGN and DEASSIGN commands. To create, maintain or delete cluster-wide logical names, specify /TABLE=LNM$SYSCLUSTER in the command.

26

Cluster-Wide Logical Names Caveat (all versions): •

The LNM$SYSCLUSTER table is synchronized across cluster nodes by a process which may or may not have been started by the time the LNM$SYSCLUSTER table is needed. − See the notes in SYLOGICALS.COM

The LNM$SYSCLUSTER table depends on inter-node communication for synchronization. The process which manages this synchronization may or may not be started and functioning when you need to use the LNM$SYSCLUSTER table in your system startup procedures. See the notes in SYS$SYARTUP:SYLOGICALS.TEMPLATE for how to determine whether the needed synchronization has completed before attempting to use the LNM$SYSCLUSTER table at system startup time.

27

Logical Names Notes: VMS$COMMON usually not found in system logical names. It IS possible to have a system with a missing or corrupted VMS$COMMON. OpenVMS upgrades will fail. Difficult to recover. Running in this condition is not supported.

Note that the VMS$COMMON directory does not appear in the systemwide logical names setup and used by OpenVMS. In fact it is possible to have a missing or corrupted VMS$COMMON directory. The author of this presentation observed it in a running nonclustered system. While the system will boot and run, OpenVMS upgrades will fail. This situation is difficult to recover. Your best bet is to build a new system disk and copy over the system-specific files as needed. This is a tedious and time-consuming task, but it can be used as a last resort if ANALYZE/DISK/NOREPAIR doesn’t turn up the missing directory as a lost file. Running a system in this condition is probably not supported by OpenVMS Support.

28

Logical Names Leave OpenVMS-provided logical names alone. ReDEFINE-ing things like SYS$SYSROOT can jeopardize support position or system certification (Healthcare, etc.) If any of these are reDEFINEd, do it at the /PROCESS level, not system-wide. Make sure to leave the system account “pristine”.

In the abstract for this seminar, mention was made of adding a translation to the SYS$SYSROOT search list. This is not a good idea, and the author of this presentation does not advocate making any changes to logical names provided by OpenVMS. It could cause problems with OpenVMS support if a question comes up involving any such logical names or any software that uses them. Also, from the perspective of the healthcare world, this would constitute a significant change to the operating environment and could raise questions regarding the environment’s continued certification. If reDEFINE-ing any of theses logical names could be helpful, be sure to only do this at the /PROCESS level, not system-wide. Make sure to keep the system account’s user environment as “pristine” as possible so as not to raise any questions of supportability or certified environment specifications.

29

Logical Names Leave OpenVMS-provided logical names alone. Probably okay to do this in a privileged account other than SYSTEM. If these are needed at SYSTARTUP_VMS time, invoke a proc. to do the DEFINEs, invoke the proc.’s that need the local logical names, then clean up using DEASSIGN/PROCESS.

Using DEFINE (/PROCESS is the default) in your own privileged account to provide process-private logicals with the same name as those at the system level would probably not raise any questions or problems. However, should any support issues arise, you will likely be asked to try to do without the private logical names by OpenVMS support. You could use your private logical names at system startup time by first invoking a procedure to create the process-private logical names, perform whatever procedures require those logical names, then clean them up using DEASSIGN (/PROCESS is the default). OpenVMS provides certain logical names for its own use. It is best, in the author’s opinion, to operate within that framework and not try to “bend the rules”. Such actions invariably come back to haunt you.

30

Logical Names It is possible to organize your site-specific procedures and keep them separated from the OpenVMS files without reDEFINE-ing any logical names provided by OpenVMS.

It is possible to organize your site-specific system management and/or operational procedures and still keep them separated from those files supplied by/with OpenVMS, without reDEFINE-ing any logical names that OpenVMS provides. Keeping your your site-specific system management and/or operational procedures organized separately from the OpenVMS files is a very good idea. This virtually guarantees that they will not be disturbed during a system upgrade.

31

Logical Names OpenVMS Logical Names: Usually contain a “$” (dollar sign).

User (Site-Specific) Logical Names Avoid “$” – use underscore: SYS_MANAGER SYS_BACKUP SYS_OPERATOR SYS_HELP SYS_ROOT

In logical names, symbol names, file names, etc., use of the dollar sign (“$”) is reserved to OpenVMS. User supplied names should use only underscores as “punctutaion”. Shown are some examples of user-supplied logical names that might prove useful. For example: SYS_MANAGER SYS_BACKUP SYS_OPERATOR SYS_HELP

Management procedures, software startups, etc. Backup procedures and files they use Menus, VMSmail, etc. Site-specific help libraries, documentation…

Any of these logical names can be made search lists, and probably should. For example, SYS_MANAGER could point first to the directory where the local site-specific files reside, then to SYS$MANAGER. Likewise, SYS_HELP could point first to the local site-specific help, then to SYS$HELP.

32

Logical Names $ sho log sys_* (LNM$PROCESS_TABLE) (LNM$JOB_80D128C0) (LNM$GROUP_000030) (LNM$SYSTEM_TABLE) "SYS_BACKUP" = "SYS_ROOT:[BACKUP]" "SYS_HELP" = “SYS_ROOT:[SYSHLP]" "SYS_MANAGER" = "SYS_ROOT:[SYSMGR]" "SYS_OPERATOR" = "SYS_ROOT:[OPERATOR]” “SYS_ROOT“ = “SYS$SYSDEVICE:[XYZCORP.]” = ”SYS$SYSROOT:”

As mentioned in the previous slide, any of these example site-specific logical names can be made search lists. In the example, SYS_MANAGER points first to the directory where the local site-specific files reside, then to SYS$MANAGER. Likewise, SYS_HELP points first to the local site-specific help, then to SYS$HELP. In these cases, the local files will be found first, if their names duplicate the name of a file found in the system directories. When the system is searching for a file, as when you invoke or edit a procedure, the system files will be found if no site-specific file matches the requested file specification. Notice that SHOW LOGICAL allows the use of wildcards. Since any logical name table can have a lot of entries, this makes things a bit easier to find.

33

Logical Names Site-specific logical names for system management can be organized in their own logical name tables. User Logical name table can be added to LNM$FILE_DEV, but don’t do that system-wide – DEFINE things /PROCESS. See the earlier example of how to modify the LNM$FILE_DEV search list for a process. /PROCESS is the default for DEFINE and ASSIGN if not specified.

While SHOW LOGICAL does support the use of wildcarded logical names as we saw in the previous slide, you may still want to isolate sitespecific logical names for system management in their own logical name table. One reason to do this might be that you can then set the protection and/or ACL of the site-specific logical name table to deny access to unprivileged users. This helps keep your environment secure. In those privileged accounts that need access to these logical names, you can reDEFINE the LNM$FILE_DEV search list as mentioned in an earlier slide. Again, as recommended in an earlier slide, do this at the process level, or no higher than the group level if all of your privileged users have he same group number in their UIC, and that group includes only privileged users doing system management.

34

Logical Names None of us is immortal. Remember to document your customizations THOROUGHLY! If you get hit by a bus today, will someone else be able to come in and understand what you’ve done?

Whatever system management scheme you come up with, consider the plight of someone who may come after you. If you “inherited” an operating environment from a previous SysAdmin, remember how you felt when you had to figure out what had been done in the past. Remember that none of us will be around forever, either biologically or professionally. Not only are we mortal, but in these layoff-crazy days, any of us can be turned out into the job market at the whim of management on zero notice. Remember to document your system management procedures thoroughly. This may even be required by the local IS Auditors. When you are away on holiday, out sick or otherwise not around, someone else should be able to pick your notes and figure it out without having to spend a lot of time exploring the system.

35

Session 1065

OpenVMS Networking

36

Networking Network stacks for OpenVMS: •

TCP/IP

•

DECnet − Phase IV − Phase V (DECnet/OSI)

Utilities: • LANCP (works without DECnet) •

SET HOST/MOP (Phase V - NET$CCR)

Let’s switch gears here and start to look at networking on OpenVMS. Originally, OpenVMS (it was called VAX/VMS at the time) provided only DECnet, LAT and MOP. As the need to support TCP/IP evolved, Digital provided the “Ultrix Connection” software we now know as “UCX” and which has come to be known as TCP/IP Services for OpenVMS. By that time, DECnet had evolved into its fourth major phase which is why we call it DECnet Phase-IV. About the same time as Digital was developing its early TCP/IP offerings, it was also developing a new version of DECnet called DECnet/OSI for “Open Systems Interconnect”, also known as DECnet Phase-V, now known as DECnet-Plus. DECnet-Plus was built around the OSI “seven layer model” and did not include specifications for support of the proprietary LAT and MOP protocols, nor did it provide extensive low-level (Layer 1) support. So LANCP was developed to fill the MOP and low-level support niche.

37

Networking - TCP/IP TCP/IP Services for OpenVMS Formerly known as UCX (Ultrix Connection) Developed, sold and supported by HP, shared code base with Tru64 TCP/IP Management interface somewhat weak. Some features (like adding secondary name server and setting up NTP) require editing config. files manually. Access to non-volatile Database is inconsistent: sometimes SET CONFIG, sometimes SET/PERMANENT.

TCP/IP Services for OpenVMS is the new official name for the software that had come to be known as “UCX”. TCP/IP Services was renamed and redeveloped so as to share a common code base with the TCP/IP stack for Tru64. While TCP/IP Services is developed and supported by the same company produces OpenVMS, it does have some weaknesses. TCP/IP Services’ management interface is somewhat inconsistent when it comes to setting characteristics in the “permanent database”. Sometimes the command form uses SET CONFIG (as contrasted with just SET that effects only the “volatile” database) and sometimes the command form requires a /PERMANENT qualifier to indicate that something is being set in the non-volatile database. Also, adding a secondary name server requires manually editing the configuration files, since the management interface does not provide for this.

38

Networking - TCP/IP TCP/IP Services for OpenVMS V5.4 “High Performance Kernel” was optional – optimized for SMP. V5.5 uses this exclusively.

TCP/IP Services for OpenVMS V5.4 introduced the “performance” kernel – a set of images optimized for system with high CPU counts (optimized for SMP). These were optional and were made available through a TIMA kit. V5.5 offers only the SMP optimized kernel images.

39

Networking TCP/IP TCPware Native to and developed on OpenVMS (originally on VAX/VMS, ported to Alpha). Developed, sold and supported by Process Software, Inc. Proprietary Management Interface, now similar to Multinet in some ways. Slightly more functionality than (UCX), performs better than Multinet and UCX).

The TCPware product from Process Software was developed natively to VAX/VMS and then ported to Alpha. The TCPware management interface is proprietary and unlike DECnet. Since Process Software now also owns the Multinet product, TCPware’s management interface is becoming more like that of Multinet. TCPware provides some functionality that is not found in TCP/IP services. However, discussion of the differences is outside the scope of this presentation.

40

Networking - TCP/IP Multinet Developed from BSD V4.3 code by TGV, Inc. on VAX/VMS, ported to Alpha. Now developed, sold and supported by Process Software, Inc. Proprietary Management Interface. Functionality similar to TCPware.

The Multinet TCP/IP product is descended from 4.3BSD code and was developed by a company called TGV on VAX/VMS. It was later ported to Alpha. TGV sold Multinet to Cisco Systems, and Cisco sold it to Process Software. Multinet’s management interface is proprietary, but consistent. In general, most functionality of the software is available through the management interface without manually editing configuration files. In general, Multinet enjoys feature parity with TCPware since the two products are now owned and developed by the same company. Multinet performance is somewhat better than that of UCX. However, since TCPware is native to OpenVMS its performance is somewhat better than that of Multinet or UCX.

41

Networking - TCP/IP Multinet Performance is less than TCPware. Uses Direct I/O – generates a lot of Interrupts. By contrast, current UCX uses Buffered I/O. Sites with high transaction volumes may need to consider this.

Multinet performance is somewhat better than that of UCX in many respects. However, since TCPware is native to OpenVMS its performance is somewhat better than that of Multinet or UCX. Sites with high transaction volumes should carefully analyze their processing loads. Multinet uses Direct I/O which generates a great deal of interrupts. This may pose a challenge in high-volume environments if not managed carefully. UCX uses Buffered I/O which does not generate hardware interrupts. It may perform better in some environments. The SMP-optimized kernel images help reduce MP-Synch loading, also. The two together may yield significant benefits at the expense of functionality and manageability.

42

Networking - TCP/IP CMU/IP Freeware, a bit old. Originally developed by TEK, released to Carnegie Mellon Univ. C.S. department - became freeware. VAX only - no known Alpha port. TCP/IP-V4 only.

CMU/IP is a freeware TCP/IP stack for OpenVMS-VAX. It has never been ported to Alpha. CMU/IP is a bit old and does not provide much beyond the basic TCP/IP “end node” functionality. Also, it is TCP/IP V4 only. As of the date this presentation was prepared, CMU/IP was available on the web at ftp://ftp.csus.edu/pub/cmuip. There may be other sources. Search the Google archives of the comp.os.vms newsgroup for CMUIP, CMU-IP or CMU/IP for more information.

43

Networking - DECnet Developed by Digital for PDP-11, migrated to VAX, ported to Alpha and I64. Phase-IV is in use widely. Phase V used where it is needed. Also known as DECnet-Plus or DECnet/OSI.

DECnet is the original network stack available for OpenVMS. It’s roots go back to the days of the PDP/11 operating systems. DECnet Phase-IV is still widely used, even though it has gone into mature product support. DECnet-IV is very reliable and simple to manage. Just set it and forget it, for the most part. DECnet-V, known as DECnet-OSI and DECnet-Plus is used where the functionality it provides is needed. In general though, TCP/IP co-existence has been mandated due to the need to consolidate onto a single network infrastructure and support system.

44

Networking - DECnet DECnet Phase IV Very SysAdmin friendly, but takes some getting used to. “Set it and forget it” - easily configured, does not issue a lot of OPCOM messages unless there is trouble on the line(s). Specification was published, still publicly available on the web. Google is your friend.

DECnet phase-IV has a fairly simple and straight-forward management interface. The Network Control Program (NCP) uses SET commands to modify the volatile database (in-memory database or the running software) and DEFINE commands to modify the permanent database (on-disk information used when the software is started). Generally, DECnet-IV does not require a lot of daily attention. Line and circuit counters can be zeroed daily if needed to track network issues, but the software will run quite happily for extended periods without doing so. DECnet-IV is very conservative about issuing OPCOM messages, generally only on line and circuit transitions, adjacency transitions and other noteworthy events. The DECnet-IV specification was available from the old Digital web site until recently. The open source community used it to develop a freeware DECnet stack for Linux and *BSD. It no longer appears at the old URL.

45

Networking - DECnet DECnet Phase IV Permanent database DEFINE commands in NCP

Volatile database SET commands in NCP

DECnet-IV’s management interface is simple and consistent. Information pertaining to the executor (the “DECnet kernel”), network nodes, line, circuits and DECnet objects is stored on disk and managed using DEFINE and PURGE commands. The permanent data used when starting up the DECnet software. The running DECnet software, or the “volatile” database is modified using SET and CLEAR commands. Generally, anything that can be DEFINEd can also be SET. Even the on-line HELP for NCP reflects this.

46

Networking - DECnet DECnet Phase IV Provides MOP Remote Console CONNECT command in NCP

Provides MOP downline load, upline dump LOAD and TRIGGER commands in NCP

Provides for remote management of other nodes. SET EXECUTOR NODE command in NCP, requires privilege and remote password.

In DECnet-IV, you can connect to the remote console of devices supporting MOP Remote Console using the CONNECT command in NCP. DECnet-IV also provides support for MOP downline load requests and upline dump requests from terminal servers, remote VMS satellite nodes, etc. Nodes supporting it can be TRiGGERed to request an downline load. There is also a LOAD command available for those remote nodes that support it. DECnet-IV even provides for remote management of other DECnet executors, within certain limits. The SET EXECUTOR NODE command can be used to tell NCP that subsequent commands issued at he command line should be sent to a remote node for execution. This allows some management of remote DECnet nodes that support this function.

47

Networking - DECnet DECnet Phase V (DECnet-Plus) More complicated to manage - management paradigm follows the OSI seven-layer model. Circuits are built from the bottom up, following the OSI seven-layer model. Management is performed using NCL (Network Control Language). Non-volatile database is .NCL files - no “permanent” database.

DECnet-V, also known as DECnet-Plus and DECnet-OSI takes a more “from the ground up” approach to network management. It follows the paradigm of the OSI seven-layer model for building the network by configuring the software one layer at a time. The DECnet-V management interface is the Network Control Language (NCL) program. Unlike DECnet-V, NCL has no “permanent database” - everything is done in memory. DECnet-V’s “permanent database” consists of the NCL files that are used at DECnet-V startup time to configure and start the software. Unlike DECnet-IV, DECnet-V is designed to handle a much broader spectrum of objects. Hence, the NCL on-line HELP can be a bit confusing and cryptic to those accustomed to NCP.

48

Networking - DECnet DECnet Phase V (DECnet-Plus) OPCOM messages are more plentiful and more verbose than Phase IV. Allows for diagnosis of trouble in each layer. Provides some features not available in Phase IV. Complete specification is not published.

DECnet-V issues a lot more OPCOM messages than DECnet-IV. Almost all network events trigger an OPCOM message from starting the software to configuring the software to normal network events like bursts of collisions, and so on. Because DECnet-V is designed around the seven layer model, the messages issued can be used to diagnose trouble down to a specific layer. So troubleshooting efforts can be more targetted. There are some features and functionality in DECnet-V that are not available in DECnet-IV. Most notably, DECnet-V is better suited to DECnet -over-TCP/IP. The complete Decnet-V specification has never been published, to the knowledge of the author of this presentation.

49

Networking - DECnet Access Control − Set up proxy records in SYS$SYSTEM:NET$PROXY.DAT using the AUTHORIZE program. − Enable proxy access in NCP (Phase-IV): incoming, outgoing. • Incoming proxy access, if disabled, defaults to the access control info of the target object instead of the source node/user.

DECnet Access Control focuses mostly on network proxies and object security. Decnet proxy records are maintained using the OpenVMS AUTHORIZE program. Remote access by proxy is configured in the NCP program for DECnetIV. If incoming proxy access is disabled, inbound access is instead controlled by the access control information of the target object.

50

Networking - DECnet Access Control − Create the proxy database if it doesn’t already exist. Use AUTHORIZE, CREATE/PROXY − Set up proxy records in Authorize. − Enable proxy access in NCL (Phase-V): See the SET SESSION CONTROL statements.

In DECnet-V, as in DECnet-IV, you must first create the proxy database if it doesn’t already exist. This is done with the AUTORIZE program using the CREATE/PROXY command. Then use AUTHORIZE to populate the proxy database Incoming and outgoing proxy access is controlled using SET SESSION CONTROL statements in NCL. See the DECnet-V Advanced Configuration documentation for information concerning your specific needs. DECnet-V configuration is outside the scope of this presentation.

51

Networking - DECnet FAL Logging •

Two Logical Names: − FAL$LOG − FAL$OUTPUT

FAL is the DECnet File Access Listener object. It gets started whenever a remote DECnet node (or the local node) requests network access to a file for any reason. There are two undocumented logical names that can be used to expand the logging information that comes out of the FAL process (FAL$LOG) and to record that information someplace other than the default file destination (FAL$OUTPUT).

52

Networking - DECnet FAL Logging •

FAL$LOG In SYLOGIN or the DECnet object file: $ DEFINE FAL$LOG “1/disable=8” This is an unsupported feature “1”: file name and file type access information “disable=8” disables “Poor Man’s Routing”: $ dir node1::node2::node3::

The FAL logical name FAL$LOG should be setup in the SYS$SYLOGIN procedure or in the DECnet object file, SYS$SYSTEM:FAL.COM The value shown for this logical name has two functional parts. The digit before the slash tells FAL what level of information logging to use. The string after the slash tells FAL to disable “poor man’s routing”, where a request is routed through multiple systems to achieve the same end as having routing nodes where node exist (hence the name, since DECnetIV licenses greater than end-node are tarditionally more expensive than end-node licenses).

53

Networking - DECnet FAL Logging •

FAL$LOG, cont’d Produces copious output - use with discretion.

•

FAL$OUTPUT Can be used to specify the name of the log file to create in place of SYS$OUTPUT $ DEFINE FAL$OUTPUT FAL.LOG

Depending upon the level of logging requested, FAL$LOG can produce copious amounts of output and should be used with discretion to avoid filling up a disk over weekend. The other undocumented FAL logical name is FAL$OUTPUT. This one can be used to specify that the output of FAL should go someplace other than to the SYS$OUTPUT stream. Here again, DEFINE this logical name in SYS$SYLOGIN or in the object file for FAL. Note that the FAL object is typically just the FAL.EXE image. To utilize these logical names without putting them in SYS$SYLOGIN, you can make a FAL.COM procedure in the SYS$SYSTEM path to define the logical names and then invoke FAL. Another approach might be to put these logical names into the login script of one or more accounts used for remote FAL access where you want extended logging information for whatever reason.

54

Networking - UCX Access Control •

Trusted Relationships − Enable “R” services between nodes without having passwords traverse the network as clear text. − Should be used between nodes on inside networks only (inside the firewall), and then very judiciously.

Trusted relationships between nodes can be used to enable “R” (Remote) services like RSHELL, REXEC, RCP, etc. without the need to have passwords appear in programs or scripts, or traverse the network in clear text. This should, of course, only be used on systems which are “behind” the firewall and not exposed directly to the internet or the “DMZ”.

55

Networking - UCX Access Control •

Trusted Relationships No .RHOSTS or HOSTS.EQUIV files. Use the ADD PROXY command in TCPIP$UCP. Not well documented: To make new proxies take effect, issue this command to TCPIP$UCP: $ TCPIP TCPIP> SET TCP/SIGNAL

When setting up trusted relationships between OpenVMS nodes running UCX (a.k.a. “TCP/IP Services”), use the ADD PROXY command in TCPIP$UCP. UCX has no equivalent to either the .rhosts file or hosts.equiv file found on some UN*X platforms. See the on-line HELP for how to use the ADD PROXY command. To activate recently entered proxies or deactivate recently deleted proxies without rebooting and without bouncing UCX, use the SET TCP/SIGNAL command in TCPIP$UCP, as shown. This command does not appear to be documented. The information was obtained from UCX Support after a call was opened inquiring as to why entered proxies did not take effect.

56

Networking - LAT LAT - Local Area Transport •

Robust, Efficient − Can package data for multiple sessions at the same MAC address into common packets.

•

Not routable − No routable info in the network layer

•

DEC-proprietary (licensed) − Specification published under license

LAT was commonly used for terminal server access prior to the rise of TCP/IP and TELNET. LAT is a very efficient and robust protocol. Data for multiple sessions at a specific MAC address can be packed into a single packet to reduce network overhead and make better use of the packet size. LAT is not routable, however, as the packets contain no useful information that would make routing useful or efficient. LAT is a DEC-proprietary protocol. The specification is available only under license. The Open Source community has made efforts to reverseengineer it.

57

Networking - LAT LAT Control Program (LATCP) •

Management interface for LAT

•

Controls services broadcast by an OpenVMS node Used to create, manage and delete LTA devices on OpenVMS nodes.

•

The program for managing LAT on OpenVMS is called LATCP. It is used for setting up and controlling services broadcast by the node, as well to setup and configure LTA devices which are used for “reverse-LAT” outbound connections to remote services or ports on servers for printers, modems, terminals, etc.

58

Networking MOP Maintenance Operation Protocol •

Not routable − No routable info in the network layer

•

DEC-proprietary (licensed) − Specification published under license

• •

Remote Console facility Downline load, upline dump.

A service originally provide by the DECnet-IV executor and managed using NCP is MOP, the Maintenance Operation Protocol. Like LAT, MOP cannot be routed. Like LAT, MOP is DEC-proprietary and the specification is subject to license. MOP provides for remote console capabilities, but also provides that remote systems can receive their operating software from as a downline load from a load host, or dump their memory up to an upline dump host.

59

Networking MOP Maintenance Operation Protocol •

User interfaces - Remote Console: − NCP (DECnet Phase IV) CONNECT NODE CONNECT VIA circuit_id PHYS ADDR mac_addr

− LANCP CONNECT NODE name/DEVICE=enet_dev:

− SET HOST/MOP (DECnet Phase V) SET HOST/MOP node_name SET HOST/MOP/ADDR=mac_addr/CIRC=xxxx

MOP now has three user interface programs at the DCL level: In DECnet-IV, the NCP program still provides for remote console using the CONNECT NODE and CONNECT VIA commands. Even when DECnet is not installed, the LANCP and LANACP programs are available. DECnet-V provides for downline loading and upline dumping just like DECnet-IV. However, remote console is provided by an extension to the SET HOST command by way of an additional qualifier, /MOP. SET HOST/MOP can use a known remote node name if the node is set up in DECnet-V or it supports connecting using the MAC (/PHYSICAL) address over a specified DECnet-V circuit.

60

Networking MOP Maintenance Operation Protocol •

User interfaces - Downline Load, Upline dump: − NCP (DECnet Phase IV) DEFINE/SET NODE name – ADDRESS xx.xxxxHARDWARE ADDRESS xx-xx-xx-xx-xx-xx – SERVICE CIRCUIT xxx-n – LOAD FILE filespec – SECONDARY LOADER filespec – DUMP FILE filespec

In DECnet-IV, downline load and upline dump are configured using the DEFINE or SET NODE command. As shown in the slide, the system needs to know the device’s physical or MAC address, the circuit over which service will be provided, and the file(s) that should be sent if the device does not request a specific file. Note also that for devices requesting a specific load file, any potential load host which has the requested software and has service enabled can service the load request. MOP does not provide for loading from only a specific host.

61

Networking MOP Maintenance Operation Protocol •

User interfaces - Downline Load: − LANCP DEFINE NODE name /ADDRESS=xx-xx-xx-xx-xx-xx/FILE=filespec • Mostly for use in booting LAVc nodes • LANCP does not provide for upline dump

LANCP also provides for downline loading. This is mostly intended for Local Area VMS cluster (LAVc) nodes. The LANCP terminology is DLL (Down Line Load). Upline dump is not provided. Note that unlike the DECnet-IV executor, the LANACP will only answer load requests for nodes that are in the node database. By contrast, the DECnet-IV executor will answer any load request if the requested load file is available. LANCP is documented in the System Management Utilities A-L manual.

62

Networking - Remote Access Types of remote Access: •

DECnet − SET HOST (CTERM) − Remote File Access (FAL) − NML (NCP SET EXECUTOR NODE)

•

LAT − Connect (from terminal server or PC w/LAT) − SET HOST/LAT

There are many ways to access the system remotely. Outside of dial-up access to a physical terminal port on the machine itself, DECnet provides for remote terminal access via the CTERM protocol (SET HOST, no qualifiers) and provides for remote access to files via the File Access Listener (FAL). In NCP, you can access the DECnet-IV executor on another node using the SET EXECUTOR NODE command. The portion of DECnet used is called the Network Management Layer (NML). LAT provides for remote connections from terminal servers, PCs that have an LAT stack and other nodes running LAT. From an OpenVMS system, you can connect to other systems and nodes that support LAT using the SET HOST/LAT command. (Note that unlike SET HOST 0, you cannot SET HOST/LAT to the local node.)

63

Networking - Remote Access Types of remote Access, cont’d: •

TCP/IP: − TELNET − Rshell / Rexec − Rlogin − RCP − SSH, SFTP, etc.

The Various TCP/IP stacks also provide for some common modes of remote access, including Telnet, Remote Shell (RSHELL), Remote Login (RLOGIN) and in the case of some of the newer versions of he TCP/IP stacks for OpenVMS, Secure Shell, Secure FTP (SFTP) and Secure Socket Layer are provided for along with Kerberos. See the documentation or the vendor for your TCP/IP stack to see what is currently available as this tends to change frequently as products develop and evolve.

64

Networking - Remote Proc.’s Types of Remote Procedures: •

DECnet − DECnet objects − SUBMIT/REMOTE, PRINT/REMOTE

•

TCP/IP − RPC (Remote Procedure Call) − Secure Socket Layer (SSL)

For remote procedure executon, DECnet provides objects that are remotely accessible. The most notorious of these is the TASK object, which is generally considered best left disabled unless absolutely necessary. It represents an opportunity for some serious security risks. Disabling the default DECNET account goes along way toward securing a DECnet system. Also on DECnet systems, the SUBMIT/REMOTE and PRINT/REMOTE command provided for some remote access as well. These are very restricted in their functionality in order to preserve security as much as possible. TCP/IP provides for Remote Procedure Call (RPC) and Secure Socket Layer connections for various purposes. Refer to the documentation for or the vendor of your TCP/IP stack(s) to determine the current states of support and availability. Such information is beyond the scope of this presentation.

65

Networking - Remote Proc.’s Security Concerns •

DECnet objects like TASK

•

Unsecured accounts by any access method. (This is not a security presentation.)

Again, the DECnet TASK object is best left out or disabled for security reasons. If needed, care should be taken to keep your system as secure as possible. Regardless of how the system is accessed, unsecured accounts (no password, weak passwords) represent a significant risk. Good system management must include vigilance in this area. In-depth security discussion is beyond the scope of this presentation, although elements of OpenVMS security will be examined near the end of this presentation.

66

Network Alerts OPCOM Alerts for network access •

SET AUDIT/ENABLE=CONNECTION − DECnet (Phase IV) − $IPC − SYSMAN

•

SET AUDIT/ENABLE=LOGIN= − ALL, BATCH, DETACHED, DIALUP, LOCAL, NETWORK, REMOTE, SUBPROCESS

Simple things that can help alert the OpenVMS System Manager to security issues include enabling Security Audits of incoming connections via Telnet, CTERM, DECnet, etc. In addition to login failures (LOGFAIL), successful logins can likewise be audited to help ensure that everyone’s tracks can be followed, so to speak. Here again, care must be taken to not audit too much so that disk space and processing resources are not overly dedicated to security issues, unless that is the purpose of the system.

67

Network Alerts Additional OPCOM Alerts for FTP •

Add commands to the DCL proc. associated with the FTP service. − Example: MULTINET:FTP_SERVER.COM

• •

Can be as general or specific needed. See the documentation and example code for your TCP/IP stack.

Additional OPCOM alerts can be set up for FTP using the service procedures supplied with TCP/IP stack or by building your own “wrapper” around the vendor’s scripts. These can be as general or as specific as deemed necessary and/or appropriate for each situation. The best source of information is the vendor of your TCP/IP stack or FTP server software.

68

Session 1065

System Startup Procedure

69

System Startup Default /STARTUP procedure: •

SYS$SYSTEM:STARTUP.COM

•

Set using SYSBOOT, SYSGEN or SYSMAN.

Here we begin our discussion of the system startup procedures. The procedure run as the STARTUP process on OpenVMS is the procedure associated with the /STARTUP qualifier in SYSGEN, SYSMAN or SYSBOOT. For example, the command in SYSGEN or SYSBOOT would look like this: SET/STARTUP filespec In SYSMAN, the command is preceded by the PARAMETERS keyword: SYSMAN> PARA SET/STARTUP filespec

70

System Startup STARTUP Phases: •

In SYS$STARTUP:VMS$VMS.DAT − RMS Indexed file − Changes to this area of the startup are *NOT* supported by HP.

The OpenVMS startup procedure, SYS$SYSTEM:STARTUP.COM runs in phases. These phases are setup in the VMS$VMS.DAT file. This is an ordinary RMS indexed file. Do NOT change this file as such changes may jeopardize your support agreements.

71

System Startup STARTUP Phases: $ TY SYS$STARTUP:VMS$VMS.DAT BASEENVIRON DVMS$BASEENVIRON-050_VMS.COM E*BASEENVIRON DVMS$BASEENVIRON-050_SMISERVER.COM E*BASEENVIRON DVMS$BASEENVIRON-050_LIB.COM E*BASEENVIRON DDECDTM$STARTUP.COM E*BASEENVIRON DLICENSE_CHECK.EXE E*CONFIG

DVMS$CONFIG-050_VMS.COM

E*CONFIG

DVMS$CONFIG-050_ERRFMT.COM

E*CONFIG

DVMS$CONFIG-050_CACHE_SERVER.COM

E*CONFIG

DVMS$CONFIG-050_CSP.COM

E*CONFIG

DVMS$CONFIG-050_OPCOM.COM

E*CONFIG

DVMS$CONFIG-050_AUDIT_SERVER.COM

E*CONFIG

DVMS$CONFIG-050_JOBCTL.COM

E*CONFIG

DVMS$CONFIG-050_LMF.COM

E*CONFIG

DVMS$CONFIG-050_SHADOW_SERVER.COM

E*CONFIG

DVMS$CONFIG-050_SECURITY_SERVER.COM

E*DEVICES

DVMS$DEVICE_STARTUP.COM

E*INITIAL

DVMS$INITIAL-050_VMS.COM

E*INITIAL

DVMS$INITIAL-050_LIB.COM

E*INITIAL

CVMS$INITIAL-050_CONFIGURE.COM

E*LPBEGIN

DVMS$LPBEGIN-050_STARTUP.COM

E*PRECONFIG

DIPC$STARTUP.COM

E*PRECONFIG

DVMS$SPIRALOG_STARTUP.COM

E*

Here’s a look at the contents of VMS$VMS.DAT. You can see which procedures are executed and in what sequence - the file is read sequentially.

72

System Startup Phases, Files INITIAL DEVICES SYCONFIG SYLOGICALS SYPAGSWPFILES

PRECONFIG CONFIG SYSECURITY

BASEENVIRON LPBEGIN SYSTARTUP_VMS

LPMAIN LPBETA END

Here’s a little more “plain English” presentation of how the startup procedure progresses. The file names are indented from the phase names in an effort to clarify the sequence of events.

73

System Startup Phases, Files INITIAL DEVICES SYCONFIG SYLOGICALS SYPAGSWPFILES

These files are always executed, even during a “MIN”-imum boot.

PRECONFIG CONFIG SYSECURITY

BASEENVIRON LPBEGIN SYSTARTUP_VMS

LPMAIN LPBETA END

Note that even during a minimum boot, some procedures are always a part of the startup sequence. It is best not to MOUNT disks in these procedures unless it will always be okay to do so, even in a minimal startup.

74

System Startup Site-Specific STARTUPs: •

In SYS$MANAGER path

•

SYSTARTUP_VMS.COM in V6 and later

•

SYSTARTUP_V5.COM in V5.x SYSTARTUP.COM in V4 and earlier.

•

The site-specific startup procedure is executed during the LPBEGIN phase of STARTUP. For OpenVMS V6 and later, the site-specific system startup procedure is SYS$MANAGER:SYSTARUP_VMS.COM. For OpenVMS V5.5-2 and or VAX/VMS v5.x, the site-specific system startup procedure is SYS$MANAGER:SYSTARTUP_V5.COM. For VAX/VMS V4 and earlier, site-specific system startup procedure is SYS$MANAGER:SYSTARTUP.COM. Some folks simply use “@SYS$MANAGER:SYSTARTUP” in their SYSTARTUP_VMS or SYSTARTUP_V5 procedure if the system has been upgraded or migrated from earlier versions and/or architectures.

75

System Startup STARTUP Parameters: •

STARTUP_P1 − blank - Normal System Startup − “MIN” - Minimal Startup • No SYSTARTUP_VMS but • Most of the other SY*.COM proc.’s will still be run.

The STARTUP procedure accepts a couple of parameters. These are derived from the values of the system parameters STARTUP_P1 through STARTUP_P8. Currently, only P1 and P2 are used. The other are reserved to OpenVMS engineering. For a normal system startup, STARTUP_P1 is empty or blank. For mininum startup, set STARTUP_P1 to “MIN”. Other values are available, but reserved to OpenVMS enginerring for updates and such.

76

System Startup STARTUP Parameters: •

STARTUP_P2 − blank - Normal System Startup − “1”, “YES” or “TRUE” - Verify on

•

STARTUP_P3 thru _P8 − Reserved for future use

STARTUP_P2 is used to control DCL command verification during the startup process. If STARTUP_P2 is empty or blank, verify is “off” or “false”. If STARTUP_P2 is “1” or “TRUE”, verify is “on”. STARTUP_P3 through STARTUP_P8 are reserved to OpenVMS engineering for future use.

77

System Startup SYSTARTUP_VMS : •

Author prefers to keep procedure modular for easier maintenance, invoke modules from SYSTARTUP_VMS: $ SET NOON . . .

$ @MOUNT_DISKS $ @DEFINE_GROUP_LOGICALS

The author of this presentation prefers to keep redundant, “cut-andpaste” code down to a bare minimum, and so advocates keeping the system startup procedures modular. This has multiple advantages. Individual startup procedures can be run manually at anytime without having to run the entire site-specific startup procedure. Maintenance of individual procedures is eased by having less code to wade through. Changes typically need to be done in only one place rather than many. Startups that differ between nodes can be separated by exploiting the SYS$SYSROOT search list. Node-specific procedures can be placed in node-specific roots while cluster common procedures can be placed in the cluster common path. This allows for non-redundant code for common events as well as node specific additions and exclusions.

78

System Startup SYSTARTUP_VMS : •

Author prefers to keep procedure modular for easier maintenance, invoke node-specific proc.’s from SYSTARTUP_VMS: $ FSP = F$SEARCH( “SYS$MANAGER:SYSTARTUP.COM” ) $ IF FSP .NES. “” THEN @&FSP

− Avoids redundant, cut-and-paste code.

This slide illustrates a way to see if a particular startup element exists before attempting to invoke it. This reduces the number of diagnostics issued during the site-specific startup procedure and helps facilitate reduction of redundant, cut-and-paste code.

79

System Startup SYSTARTUP_VMS : •

Logging SYSTARTUP_VMS: $ SET NOON $ DEFINE SYS$OUTPUT SYS$MANAGER:SYSTARTUP_VMS.LOG . . . $ DEASSIGN SYS$OUTPUT

This slide illustrates a trick for providing a log of events occurring during the site-specific startup procedure. Near the top of the procedure, insert a DEFINE SYS$OUTPUT command. DCL will recognize this and direct subsequent output to the file. A SET NOON helps insure that the procedure will run to completion in spite of errors that may occur during it, and enables the procedure to detect the success or failure of each element. Near the bottom of the procedure, insert a DEASSIGN SYS$OUTPUT command. DCL will detect this and close the file. SYS$OUTPUT data will again show up on OPA0:.

80

System Startup SYSTARTUP_VMS : •

Logging SYSTARTUP_VMS: Caveat: May not work with some application startups Example: MiSys (Sunquest) FlexiLAB » (MUMPS application, runs in InterSystems’s Cache’ RDB environment) » Expects a response to a prompt, chokes on the log file as SYS$OUTPUT.

System Startup logging by redirecting SYS$OUTPUT may not work as expected with some application startups. For example: MiSys’s FlexiLAB is MUMPS application and also runs under InterSystem’s newest version of that environment known as Cache’. At startup time, the application startup expects a response to prompt asking if a full startup should be done. The default answer is “N” or “no”. As a result, when the SYS$OUTPUT stream is directed away from the console terminal, the prompt errors out and the application does not start up. A work-around for this has not yet been found.

81

System Startup Saving/reporting a crash dump at System Startup time: $ ANALYZE/CRASH_DUMP SYS$SYSTEM:SYSDUMP.DMP COPY ddcu::SAVEDUMP.DMP

! copy to wherever is convenient.

SET OUTPUT SYS$MANAGER:SYSDUMP.LIS ! Set this as you like READ/EXEC ! READ SYS$SYSTEM:SYSDEF

! For VAX

READ SYS$LOADABLE_IMAGES:SYSDEF

! For Alpha

SHOW CRASH SHOW STACK /ALL SHOW SUMMARY SHOW PROCESS /PCB /PHD /REGISTERS SHOW SYMBOL /ALL EXIT

This slide illustrates a method for performing preliminary crash dump analysis at startup time. If the dump file contains a valid dump, the remaining commands will execute; if not, the remaining commands will be ignored.

82

System Startup Saving/reporting a crash dump at System Startup time: COPY in SDA only copies the portion of the dump file that was actually written during the last dump. The result is usually much smaller than the actual dump file, unless the dump file is too small. $ ANALYZE/CRASH_DUMP SYS$SYSTEM:SYSDUMP.DMP COPY ddcu::SAVEDUMP.DMP SET OUTPUT SYS$MANAGER:SYSDUMP.LIS READ/EXEC ! READ SYS$SYSTEM:SYSDEF READ SYS$LOADABLE_IMAGES:SYSDEF ! For Alpha SHOW CRASH SHOW STACK /ALL SHOW SUMMARY SHOW PROCESS /PCB /PHD /REGISTERS SHOW SYMBOL /ALL EXIT

! copy to wherever is convenient. ! Set this as you like ! For VAX

The COPY command in SDA copies only that portion of the dump file that was actually written during the most recent dump. Thus, the COPY destination can be significantly smaller than the dump file itself and can more easily be FTPed to VMS Support for analysis.

83

System Startup DEFINE-ing Group Logicals at Startup: − SET up a DCL procedure to DEFINE (or assign) the needed logicals using /GROUP and whatever access mode is appropriate. − Invoke that procedure as a detached process at system startup time.

It is frequently necessary to define some group-level logical names at system startup time. Trouble is, until a user in that group logs into the system, the group logical name table doesn’t yet exist. This slide describes one approach to this. You can set up the groupspecific logical name definitions in a separate file and then run that procedure as a detached process under that UIC at system startup time. When the process exists, the group logical name table and its contents will remain.

84

System Startup DEFINE-ing Group Logicals at Startup: Example: $ RUN SYS$SYSTEM:LOGINOUT.EXE/UIC=[300,1]/INPUT=GROUP_300_LOGICALS.COM/OUTPUT=GROUP_300_LOGICALS.LOG

The UIC specified does not need to exist in the UAF.

Here’s an example of the technique. In this case, the group 300 specific logical name definitions are contained in a DCL procedure called GROUP_300__LOGICALS.COM. That procedure is run in a detached process under a group 300 UIC. Note that the UIC specified need not actually exist in the UAF. Any UIC in the target group will do. Remember also that the group and member number elements of the UIC are always octal numbers.

85

System Startup DEFINE-ing Group Logicals at Startup: Alternate Example: $ RUN SYS$SYSTEM:LOGINOUT.EXE/UIC=[300,1]/INPUT=NLA0:/OUTPUT=NLA0:

− The UIC specified does not need to exist in the UAF. − The example creates the LNM$GROUP_000300 table. − Logical names can then be created in that table by any suitably privileged process.

Here’s a variation on that technique. In this case, the process is run with the null device as both the input and output. The net effect of running the process is to create the desired logical name table. Once created, the logical name table can be populated by any suitably privileged process or procedure.

86

System Startup Setting logins at Startup: •

Global DCL symbol (STARTUP process) is set up during SYS$STARTUP:VMS$BASEENVIRON050_VMS.COM: $startup$interactive_logins == 64

A problem that has dogged VMS System Managers since the dawn of VMS is to have the required number of interactive logins set at system startup time. Currently, a global DCL symbol (global to the STARTUP process) is set up during SYS$STARTUP:VMS$BASEENVIRON-050_VMS.COM: $startup$interactive_logins == 64. It is assigned an arbitrary value of 64, which happens to also be the default value for the IJOBLIM system parameter. IJOBLIM limits the number of interactive logins available at any given time.

87

System Startup Setting logins at Startup, cont’d: •

Global DCL symbol (STARTUP process) is used in SYS$STARTUP:VMS$LPBEGIN050_STARTUP.COM: $set logins/interactive='startup$interactive_logins

This global DCL symbol is used in the procedure SYS$STARTUP:VMS$LPBEGIN-050_STARTUP.COM which is run AFTER the site-specific startup procedure, SYSTARTUP_VMS. So, the number of interactive logins to be allowed upon completion of the system startup sequence can be manipulated by assigning the desired value to startup$interactive_logins. However, this has the drawback that unless a way is found to soft code this value, the the site-specific startup procedure may need to be edited in order to change it.

88

System Startup Setting logins at Startup, cont’d: •

Change the value of startup$interactive_logins during SYSTARTUP_VMS:

$ startup$interactive_logins == F$GETSYI( “IJOBLIM” )

Illustrated here is a method of allowing the number of interactive logins permitted after startup to be soft coded. The value of IJOBLIM read in when the system parameters get loaded does not change until SET LOGINS/INTERACTIVE=value occurs very late in the startup sequence. So, the system parameters file can be used as a source of the desired value for interactive logins allowed upon completion of the startup.

89

System Startup Setting logins at Startup, cont’d: $ startup$interactive_logins == F$GETSYI( “IJOBLIM” ) Notes: • Set the desired value for IJOBLIM in MODPARAMS and run AUTOGEN, or change the CURRENT value using SYSMAN or SYSGEN. Change takes effect on next boot.

Set the desired or required value into the IJOBLIM parameter in MODPARAMS.DAT as well as in the current system parameters (or edit MODPARAMS.DAT, then run AUTOGEN through at least the SETPARAMS phase). Insert the code shown into the site-specific startup procedure, very late in the procedure - near the end to help ensure it doesn’t get changed by anything else. Upon your next startup, you will have the desired number of logins set automatically and you can change it at anytime without having to edit the site-specific startup procedure.

90

System Startup Setting logins at Startup, cont’d: $ startup$interactive_logins == F$GETSYI( “IJOBLIM” ) Notes, cont’d: • IJOBLIM is a dynamic parameter. The SET LOGINS/INTERACTIVE command displays or varies its value. See the HELP.

Remember that IJOBLIM is a dynamic parameter. It is this parameter that gets modified by the SET LOGINS/INTERACTIVE=value command. The command with no value or without the /INTERACTIVE qualifier displays the current number of logins and the number allowed.

91

System Startup Setting logins at Startup, cont’d: SET LOGINS/INTERACTIVE caveat: •

•

Largely undocumented, little known fact: until this command is issued for the first time after a reboot, the job controller will not create interactive processes. If used in SYSTARTUP_VMS, it may enable logins before the system is ready for users to log in.

Here’s an important caveat regarding SET LOGINS/INTERACTIVE: It is largely unknown and undocumented that the system job controller will not create interactive process when OpenVMS is first booted until this command is issued with a value. Once that happens, logins become possible, even if the value specified is zero. Remember that suitably privileged users can still login, even when logins are disabled by setting them to zero. If the site-specific startup procedure, or a procedure that it invokes executes a SET LOGINS/INTERACTIVE=x command, this may result in logins being enabled before the system is ready to have users log in. Application errors and loss or corruption of data may be possible under such circumstances. TCP/IP Caveat: Note that UCX and TCPware use the job controller to create interactive processes as a result of a TELNET connect. Multinet, however, uses its own MULTINET_SERVER process to do this. MULTINET_SERVER does not observe this protocol, and so will produce interactive logins even before they have been enabled by SET LOGINS/INTERACTIVE=n.

92

System Startup Setting logins at Startup, cont’d: SET LOGINS/INTERACTIVE caveat: •

DO NOT USE THIS COMMAND IN SYSTARTUP_VMS!!!

•

…or any proc. that it invokes!!! Use the global DCL symbol instead (STARTUP$INTERACTIVE_LOGINS).

•

For the reason outlined in the notes on the previous slide, the author of this presentation recommends that this command NEVER be used in the site-specific startup procedure or any that it invokes. Use the global DCL symbol instead.

93

System Startup - VMS Files •

Must never be changed unless software documentation or VMS support instructs you to do so.

•

May be replaced when VMS or layered products are upgraded. May use deprecated lexical functions (like F$LOGICAL()), or may contain misspelled function names (like F$GETSYS(), DCL sees only F$GETS).

•

Some other important notes about the system startup, files: Never muck about with the DCL procedures and data files in the SYS$STARTUP directories SYS$SYSROOT:[SYS$STARTUP] and SYS$COMMON:[SYS$STARTUP]. They may quite likely be replaced on the next OpenVMS or layered product upgrade or patch kit install. Also, be careful about emulating anything you find in any of the startup procedures provided with OpenVMS. They may use deprecated lexical functions like F$LOGICAL() or may contain misspelled lexical function names like F$GETSYS (should be F$GETSYI). DCL only looks at the first four characters of the a command or function name, so these do not cause problems now, but may result in errors later if DCL is ever revamped in a major way.

94

System Startup - VMS Files •

Site-specific startups are usually found in the SYS$MANAGER path.

System startup files that are unique to a system or a cluster are usually found in the SYS$MANAGER path. The translation of the logical name SYS$MANAGER is SYS$SYSROOT:[SYSMGR]. Since SYS$SYSROOT is a search list, care should be taken when setting SYS$MANAGER as your default. If you are editing files, the revised versions of those files will be written back to their original location. If found in SYS$SPECIFIC:[SYSMGR], that’s where the new version will be written. If found in SYS$COMMON:[SYSMGR], that’s where the new version will be written. If you create a new file, and your default is set to SYS$MANAGER, the new file will be created in the directory indicated by the first element of SYS$MANAGER, namely the node-specific path. Note that the translation of SYS$SPECIFIC is the same as the first translation of the SYS$SYSROOT search list.

95

Session 1065

SYSMAN and STARTUP

96

SYSMAN & STARTUP SYSMAN can be used to modify the “user” portion of the startup database. − Two database files used by SYSMAN: STARTUP$STARTUP_VMS Used for the VMS startup DO NOT MODIFY !!! STARTUP$STARTUP_LAYERED When you add an item using SYSMAN it goes here.

The SYSMAN utility includes options to add items to the startup sequence by entering records in the startup databse. SYSMAN will modify the STARTUP$STARTUP_VMS file in the startup database. However, this file should only be modified by OpenVMS support or engineering, or by software or patch kits developed by them. The OpenVMS system manager must never modify STARTUP$STARTUP_VMS unless intsructed to do so by OpenVMS support. The STARTUP$STARTUP_LAYERED file in the startup database is the correct place to make site-specific modifications to the startup database.

97

SYSMAN & STARTUP SYSMAN can be used to modify the “user” portion of the startup database. − Not as flexible the traditional method using SYSTARTUP_VMS. − Not as widely used. Incoming SysAdmins may be unware of previous modifications to the startup database using SYSMAN. − Allows for specifying that some startup procedures run in BATCH, in-line (DIRECT) or in sub-processes (SPAWN).

While SYSMAN does provide this ability, there are some caveats and notes: This method of entering site-specific startups into the startup sequence is not as flexible as doing so from the site specific startup procedure. Making startups conditional upon the success or failure of previous startups becomes more cumbersome as does inserting startups that are local to a node rather than common to the cluster. This method of modifying the startup sequence is not as widely used or as widely known. Those who come after you may have difficulty understanding or supporting modifications to the startup database made using SYSMAN. The good news, however, is that SYSMAN provides for specifying that procedures added this way should run detached, in batch, in a subprocess or in-line (DIRECT).

98

SYSMAN & STARTUP − Allows for entering startup items that run after SYSTARTUP_VMS. • SYSTARTUP_VMS is invoked during the LPBEGIN phase. • Valid phases for SYSMAN STARTUP entries are LPBEGIN, LPMAIN, LPBETA and END. • Premature logins are possible if SYSTARTUP_VMS enables logins before startups in later phases (LPMAIN, LPBETA or END) have run.

SYSMAN allows for entering items into the startup sequence that run after SYSTARTUP_VMS. So, these notes should be borne in mind when planning and implementing startup modifications through SYSMAN: SYSTARTUP_VMS is invoked during the LPBEGIN phase. This phase is not executed in a minimal startup. Neither are any of the other “LP” (Layered Product) phases. Valid phases for startup sequence modifications entered using SYSMAN are LPBEGIN, LPMAIN, LPBETA and END, in order of execution. When adding a startup that occurs after SYSTARTUP_VMS is completed be aware that SYSTARTUP_VMS, or a procedure that it invokes may have enabled logins and users may already be accessing the system, before the startup sequence is complete.

99

Session 1065

Conversational Boot, Minimum Startup

100

Conversational Boot HP Integrity Servers – EFI Shell Shell> set vms_flags “x,1” or Shell> fs0:\efi\vms\vms_loader.efi –fl x,1 Using a shell alias: Shell> alias b “fs0:\efi\vms\vms_loader.efi” Shell> b –fl x,1

Conversational boot is invoke by setting bit 0 of Register 5 before loading the bootstraps. On HP integrity servers, this is done by setting the EFI environment variable “vms_flags” to an appropriate value in the familiar format, “root_number,flag_value”. On Alphas and VAX 7000s, this is done using the “-fl[ags] x,1” qualifier, were “x” is the node’s system root (0-FF).

101

Conversational Boot Most Current Alphas, most “old” Alphas (including Multia), VAX 7000: >>> boot –fl x,1

VAX 6000 >>> BOOT boot_profile/R5=1 >>> BOOT boot_profile/R5=x0000001

Older small VAXes >>> B/R5:1 or B/R5:x0000001

VAX 8000’s See the manual

Conversational boot is invoke by setting bit 0 of Register 5 before loading the bootstraps. On VAX 6000s, add the /R5:value qualifier to the boot command after the name of the boot profile, or just after the BOOT command if using the default boot profile. VAX 6000s can only boot from roots 0 thru F. Most older small VAXes (VAX 4000, MicroVAX, etc.) have console variables for the boot device and the default boot flags. Just add the appropriate variant of /R5:value. For VAX 8000, 9000 and 10000, see the console documentation on how to do this.

102

Minimum Boot >>> b –fl 10,1 SYSBOOT> SET STARTUP_P1 “MIN” SYSBOOT> CONTINUE Use SET WRITESYSPARAMS 0 before CONTINUE for a one-time minimum boot.

Setting bit zero in Register 5 before loading the bootstraps causes SYSBOOT to pause and prompt for input at the console. Hence, the name: “Conversational boot”. At the SYSBOOT prompt, you can modify system parameters, then continue the boot up sequence. For a minimum boot, SET the STARTUP_P1 parameter to “MIN”. If the minimum boot is a one-time event, you can the SET the WRITESYSPARAMS parameter to zero(0) to prevent the system from saving the system parameters at boot time. The default value for this parameter is one(1), write the system parameters at boot time, meaning any changes you make in SYSBOOT will be saved in the current parameter set. To continue the boot up sequence, tell SYSBOOT to CONTINUE.

103

Session 1065

System Shutdown Procedure

104

System Shutdown $ @SYS$SYSTEM:SHUTDOWN − Prompts interactively for parameters − Parameters can also be specified on the command line that invokes the procedure. • See the SHUTDOWN and REBOOT symbols in SYS$MANAGER:LOGIN.TEMPLATE

Let’s look now at the process of shutting down OpenVMS. The provided DCL procedure is found as SYS$SYSTEM:SHUTDOWN.COM. It should actually be found in the cluster common path. This is provided by/with OpenVMS, and so should not be modified except as instructed by OpenVMS support (which should never happen). SHUTDOWN prompts interactively for the shutdown parameters if none are specified on the command line used to invoke SHUTDOWN. Parameters to SHUTDOWN can also be specified on the command line used to invoke SHUTDOWN. Two examples are found in the SYS$MANAGER:LOGIN.TEMPLATE script template. Look for SHUTDOWN and REBOOT in that file. If you use these “foreign commands”, bear in mind that as supplied, they do NOT execute the site-specific shutdown procedure.

105

System Shutdown SYS$SYSTEM:SHUTDOWN.COM Parameters: P1 = Minutes to final shutdown P2 = Reason for Shutdown P3 = Spin down disk volumes? (Y/N) P4 = Invoke SYSHUTDWN.COM? (Y/N) P5 = When will system be rebooted? P6 = Should auto. reboot be performed? (Y/N) P7 = Options (SAVE_FEEDBACK, etc.) • P5 and P6 are reverse order to the prompts.

To modify the SHUTDOWN or REBOOT symbols, refer to the information in the slide regarding the parameters that SHUTDOWN accepts from the command line. Notice that P5, when the system will be rebooted and P6, should an automatic reboot be performed are in reverse order to the order of the prompts issued by SHUTDOWN.

106

Site-Specific Shutdown Proc. SYSHUTDWN.COM Found in the SYS$MANAGER path.

Just as there is a site-specific startup procedure, there is also a sitespecific shutdown procedure. SYS$MANAGER:SYSHUTDWN.COM is run as part of the SHUTDOWN sequence if this option is selected in SHUTDOWN. Use SYSHUTDWN to stop applications, databases, daemons, etc. that may be holding files open. This provides that such software can be shutdown gracefully instead of letting SHUTDOWN STOP them abruptly later on in the SHUTDOWN sequence. Like SYSTARTUP_VMS, the author recommends keeping SYSHUTDWN modular so that individual shutdowns can be invoked at will for testing, problem solving, etc.

107

System Shutdown SYS$SYSTEM:SHUTDOWN.COM Logical Names SHUTDOWN$MINIMUM_MINUTES Default value for minutes to final shutdown.

AGEN$SHUTDOWN_TIME Used by AUTOGEN as minutes to final SHUTDOWN or REBOOT.

SHUTDOWN$INFORM_NODES Cluster nodes to receive REPLY messages from SHUTDOWN

SHUTDOWN$VERIFY Allows SET VERIFY to be in effect during SHUTDOWN

In the “minutes until shutdown” prompt, a default value of zero is given. This can be over-ridden with the SHUTDOWN$MINIMUM_MINUTES logical name. Also, if P1 to SHUTDOWN is specified as “MINIMUM”, the value of this logical name is used as the time until final shutdown, or zero if the logical is not DEFINEd. The AUTOGEN procedure has its own logical name for the “minutes until final shutdown” value that will be provided to SHUTDOWN by AUTOGEN. The AGEN$SHUTDOWN_MINUTES logical name can be used to provide a value for this; otherwise, AUTOGEN uses either SHUTDOWN$MINIMUM_MINUTES or a default of zero(0).

108

Shutdown Options REBOOT_CHECK SAVE_FEEDBACK DISABLE_AUTOSTART POWER_OFF

The SHUTDOWN procedure allows for some shutdown options. The options listed here are common to both clusters and non-clustered systems. These options are specified as a comma-separated list either interactively or as P7 on the command line used to invoke SHUTDOWN. The option names can be abbreviated. The author of this presentation recommends using the option name up to the first underscore as a minimum abbreviation. In the next slides, we’ll look at these options one by one.

109

Shutdown Options REBOOT_CHECK •

Performs a basic check for the existence of files needed to reboot the system.

•

Not comprehensive - cannot detect a damaged boot block, corrupted bootstrap image, etc.

The reboot check option performs some very basic checks for the existence of some key files. Some examples include the APB or VMB bootstraps, SYSBOOT and others. Note, however, that this check is not comprehensive. It does not attempt to detect corrupted or unreadable files, for instance, nor does it check the integrity of the boot block. It can catch certain situations that would prevent a successful reboot; the author has found this useful. The errors were fixed and a successful shutdown and reboot was done.

110

Shutdown Options SAVE_FEEDBACK •

Saves some vital statistics about the system that can be used by AUTOGEN after the system comes back up.

•

Same as the SAVPARAMS phase of AUTOGEN.

The SAVE_FEEDBACK option does the same thing as the SAVPARAMS phase of AUTOGEN. It allows that feedback information can be saved at shutdown time allowing for AUTOGEN to be run using the saved feedback at some later time.

111

Shutdown Options DISABLE_AUTOSTART •

Use this if needed to prevent AUTOSTART queues on this node from failing over to this node from another node.

DISABLE_AUTOSTART stops autostart queues on the node, and prevents any queues from failing over to the node from another node in the cluster.

112

Shutdown Options POWER_OFF •

If the system console supports it, request that the machine power itself down once VMS has been SHUTDOWN.

Some of the newer Alpha console subsystems allow for the hardware system to be powered down under software control. The POWER_OFF shutdown option was added to support this feature. The POWER_OFF option is new as of OpenVMS V7.

113

Shutdown Options - Clusters •

REMOVE_NODE for all but the last node. − Node exits the cluster gracefully.

•

CLUSTER_SHUTDOWN for the last cluster node to be shutdown. − If used on all nodes, each node waits for other nodes to reach the point of exiting the cluster, then proceeds to shutdown (“dissolves” the cluster).

These two options are only displayed on a node which is a member of a cluster. Specify REMOVE_NODE to have a node exit the cluster gracefully. The surviving nodes will recalculate quorum and then continue running after the resulting cluster state transition, if the total of votes remaining is greater than or equal to quorum. When shutting down the last surviving node of a cluster, or to shutdown all nodes of a cluster at the same time, specify the CLUSTER_SHUTDOWN option. If you use this to shutdown all the nodes of a cluster at the same time, each node will wait for the others to reach a common point in the shutdown, then they will all shutdown together gracefully dissolving the cluster.

114

Every Shutdown •

Author recommends you always specify option REBOOT_CHECK for all nodes.

•

Has been helpful in preventing some nasty surprises.

A reminder that the REBOOT_CHECK option can be very helpful in preventing problems, especially when a cluster or a system has run for many months without being shutdown. While not 100% comprehensive, it can detect some kinds of situations that may evolve in a long-uptime system or cluster, such as key files getting deleted. The Author of this presentation recommends always using the REBOOT_CHECK option of SHUTDOWN based on personal experience.

115

Session 1065

AUTOGEN

116

AUTOGEN SYS$UPDATE:AUTOGEN.COM • •

DCL procedure supplied by OpenVMS as an aid in tuning the OpenVMS system. Not a replacement for diligent system management.

This presentation has mentioned the AUTOGEN procedure, so let’s take a look at it in a bit of detail. AUTOGEN is a DCL procedure supplied by/with OpenVMS as an aid to tuning the system and maintaining modifications to the system parameters. While AUTOGEN can point up some problems with proposed changes to the system parameters, and can suggest other changes that may be useful to maintain or improve performance, it is not a substitute for diligent system management. You must still monitor your system’s performance and tune the system to maintain expected levels of performance or service.

117

AUTOGEN •

Applies changes to the default system parameters as specified in the file SYS$SYSTEM:MODPARAMS.DAT

•

Is invoked during installs and upgrades, sometimes more than once.

•

Can be used to help size the swap and page files.

AUTOGEN applies changes to the system parameters as specified in the SYS$SYSTEM:MODPARAMS.DAT file. The OpenVMS system manager maintains MODPARAMS based on the need of the site, system or cluster. AUTOGEN is invoked during OpenVMS installation and upgrades, sometimes more than once. AUTOGEN calculates changes to the system parameters based on entries in MODPARAMS, but can also suggest changes to the system swap, page and dumpfiles based on the physical configuration and on observed utilization of the system (feedback).

118

AUTOGEN - MODPARAMS SYS$SYSTEM:MODPARAMS.DAT •

This is where changes to the default values are made so they persist from one AUTOGEN to the next.

•

Entries look like this: parameter_name = needed_value MIN_parameter_name = needed_value MAX_parameter_name = needed_value ADD_ parameter_name = needed_value

MODPARAMS is the supported method for setting modifications to the values of the system parameters. Values specified in MODPARAMS are applied to the DEFAULT system parameters. So, changes are not cumulative. Also, any changes made outside of MODPARAMS will be wiped out by AUTOGEN. AUTOGEN accepts your specified modifications and also calculates changes to related parameters where appropriate. There are four type of entries that can be made in MODPARAMS to specify changes to the default values of the system parameters: hardcoded values, minimum values, maximum values and additional values.

119

AUTOGEN - MODPARAMS parameter_name = needed_value •

Provides a hard-coded value for the parameter. SCSNODE = “ALPHAONE” GBLPAGES = 121589

•

AUTOGEN calculations do not over-ride hardcoded values.

Hard-coded values are appropriate for some system parameters such as the SCSNODE name, the SCSSYSTEMID, quorum disk name and others. In some cases, other parameters can be hard-coded, also. Generally, it’s best to specify minimum values for many system parameters and let AUTOGEN use higher values if it calculates that higher values would be helpful. In any case, the values that AUTOGEN calculates for system parameters do not over-ride hard-coded value specified in MODPARAMS.

120

AUTOGEN - MODPARAMS MIN_parameter_name = minimum_value •

Provides a minimum value for the parameter. MIN_GBLPAGES = 121589

•

AUTOGEN may calculate and use a higher value, but will always use the MIN_ if it calculates a lower value.

Sometimes, it is appropriate to specify a minimum value for some parameters and let AUTOGEN use higher values for them, if AUTOGEN determines that higher values would be helpful for performance reasons or other reasons. In these cases, use a MIN_ value in MODPARAMS. AUTOGEN will reflect that the values of such parameters are not allowed to be lower than the value specified for them in MODPARAMS.

121

AUTOGEN - MODPARAMS MAX_parameter_name = maximum_value •

Provides a maximum value for the parameter. MAX_GBLPAGES = 12158900

•

AUTOGEN may calculate and use a lower value, but will always use the MAX_ if it calculates a higher value.

Some times, it is appropriate to specify a maximum value for some parameters and let AUTOGEN use a lower value if it calculates that a lower value is appropriate. In these cases, use a MAX_ value in MODPARAMS. AUTOGEN will reflect that the values of such parameters are not allowed to exceed the value specified for them in MODPARAMS.

122

AUTOGEN - MODPARAMS ADD_parameter_name = addtl_value •

Provides an addition to the default value for the parameter. ADD_GBLPAGES = 81920

•

AUTOGEN can use feedback to calculate a new value, then adds the specified value to the calculated value.

In other cases, it may only be necessary to specify that AUTOGEN should add a certain value to the calculated value of some parameters, but otherwise allow AUTOGEN calculations to prevail. In these cases, AUTOGEN will perform all of its usual calculations, then add the specified value to the calculated value of such parameters. For parameters not calculated by AUTOGEN, the value specified is added to the default to arrive at the new value.

123

AUTOGEN - Phases SAVPARAMS GETDATA GENPARAMS TESTFILES GENFILES SETPARAMS SHUTDOWN REBOOT

- Collects Feedback - Collects all other data - Generates new parameters - Calculates new sys file sizes - Generates new system files - Creates new boot param.’s - Shutdown the system - Reboot the system

HELP

- Displays AUTOGEN info

AUTOGEN runs in phases that perform specific sub-tasks of the overall AUTOGEN task. The AUTOGEN phases are listed above. In the following slides, we’ll discuss these phases in some detail.

124

AUTOGEN - Phases SAVPARAMS

Saves dynamic feedback from the running system. Same as SAVE_FEEBACK option of SHUTDOWN.

The SAVPARAMS phase extracts the feedback information from the running system. If the system uptime is less than twenty-four(24) hours, AUTOGEN may complain about this. Feedback includes some dynamic data from the running system that can be used in later calculations to determine optimal values for certain performance related system parameters. SAVPARAMS does the same thing as the SAVE_FEEBACK option of SHUTDOWN.

125

AUTOGEN - Phases GETDATA

Collects all data to be used in AUTOGEN calculations. Includes existing feedback data if it is not over 30 days old. Includes MODPARAMS info.

During the GETDATA phase, AUTOGEN collects all of the information needed to perform its calculations. This includes validating the feedback information, unless NOFEEDBACK is specified or the feedback information is older than 30 days.

126

AUTOGEN - Phases GENPARAMS Performs calculations and generates the new system parameters (but does not yet set them into the “Current” parameters). Creates the new list of installed images based on the state of the currently running system.

During the GENPARAMS phase, AUTOGEN performs its calculations and writes a list of changes that will be applied to the default system parameters. This can be found in the SYS$SYSTEM path in the SETPARAMS.DAT file. AUTOGEN also creates a new list of images to be installed at systemstartup time during the GENPARAMS phase.

127

AUTOGEN - Phases TESTFILES Calculates new page and swap file sizes, but does not apply any changes.

During the TESTFILES phase, AUTOGEN performs its calculations for changes it will suggest to the sizes of the swap, page and dump files. Only the calculations are performed – no changes are actually applied in the TESTFILES phase.

128

AUTOGEN - Phases GENFILES Generates new swap and page files based on AUTOGEN calculations. Use entries in MODPARAMS to override: DUMPFILE=0 SWAPFILE=0 PAGEFILE=0

During the GENFILES phase, AUTOGEN will apply the changes it calculates for the swap, page and dump files. This can be over-ridden in MODPARAMS by supplying entries for the swap, page and dumpfiles with zero(0) values. These keywords can also be used to specify hard-coded values for the sizes of these files. The hard-coded values will over-ride AUTOGEN’s calculations.

129

AUTOGEN - Phases SETPARAMS Creates the new boot-time (“current”) parameters. Changes take effect on the next boot.

During the SETPARAMS phase, the calculated changes to the default system parameters are applied and saved as the current parameters to be loaded next time the system boots. The ACTIVE parameter set is not changed.

130

AUTOGEN - Phases SHUTDOWN Shutdown the system and leave it ready for a manual boot or other console-level operations. Caveat: Does *NOT* invoke SYSHUTDWN!

The SHUTDOWN phase allows AUTOGEN to shut the system down to await a manual reboot, for performing operations at the console, for power-down allowing hardware maintenance, etc. A caveat about SHUTDOWN is that the site-specific shutdown procedure, SYSHUTDWN is not executed during the SHUTDOWN phase of AUTOGEN. The SHUTDOWN and REBOOT phases of AUTOGEN invoke SYS$SYSTEM:SHUTDOWN.COM.

131

AUTOGEN - Phases REBOOT Reboot the system using the newly generated parameters and/or system files. Caveat: Does *NOT* invoke SYSHUTDWN!

The REBOOT phase allows AUTOGEN to shut the system down and specify that automatic reboot should be performed. This is what typically happens at the end of an OpenVMS upgrade or install. A caveat about REBOOT is that the site-specific shutdown procedure, SYSHUTDWN is not executed during the REBOOT or SHUTDOWN phase of AUTOGEN. The SHUTDOWN and REBOOT phases of AUTOGEN invoke SYS$SYSTEM:SHUTDOWN.COM.

132

AUTOGEN - Phases HELP Display HELP information for how to use AUTOGEN. Useful to output this to a file: $ @SYS$UPDATE:AUTOGEN/OUTPUT=AGEN_HELP.LIS HELP

There is no DCL HELP topic for AUTOGEN. However, there is a HELP option for AUTOGEN which outputs some useful information on how to use AUTOGEN. It is useful to output this information to a file for future reference. Simply specify /OUTPUT=filespec after “@SYS$UPDATE:AUTOGEN” and specify HELP as the first parameter.

133

AUTOGEN - Phases Typical uses: See if current MODPARAMS settings are suitable: $ @SYS$UPDATE:AUTOGEN SAVPARAMS TESTFILES Generate new system parameters for next boot: $ @SYS$UPDATE:AUTOGEN SAVPARAMS SETPARAMS AUTOGEN using previously saved feedback: $ @SYS$UPDATE:AUTOGEN GENPARAMS SETPARAMS

Here are some typical examples of how to use AUTOGEN. The first example shows how to use AUTOGEN to test the suitability of your proposed parameter changes. No actual changes will be made to the current parameter set; however, a new list of installed images is generated and will be used on the next boot. The second example shows how to use AUTOGEN to generate a new current parameter set for use on the next boot. The running system is not effected. The third example show how to use AUTOGEN using feedback saved earlier, either by the SAVE_FEEDBACK option of SHUTDOWN or by running AUTOGEN with SAVPARAMS as both the starting and ending phase.

134

AUTOGEN - Phases Typical uses: AUTOGEN ignoring feedback: $ @SYS$UPDATE:AUTOGEN _$ GENPARAMS SETPARAMS NOFEEDBACK AUTOGEN using previously saved feedback, if it is valid: $ @SYS$UPDATE:AUTOGEN _$ GENPARAMS SETPARAMS CHECK_FEEDBACK

Two more examples of using AUTOGEN: The first example here shows how to use AUTOGEN when the system has not been up long enough to have any valid feedback. AUTOGEN is run from the GENPARAMS phase through the SETPARAMS phase and is told to use no feedback. The system can then be shutdown or rebooted at a later time. The second example here shows how to use AUTOGEN when you’re not certain of the validity of the feedback information. If the feedback information is older than 30 days, AUTOGEN will not use it but will still continue through the specified end phase. If P3 is not specified at all, AUTOGEN will check the validity of the feedback and if it is suspect (too old), AUTOGEN will adjust the ending phase to TESTFILES and allow the system manager to take appropriate action.

135

AUTOGEN - Report SYS$SYSTEM:AGEN$PARAMS.REPORT • Generated on each run of AUTOGEN during the GENPARAMS phase. • Indicates any MODPARAMS errors detected by AUTOGEN. • Indicates the results of AUTOGEN calculations and resulting changes to system parameters.

In peforming its calculations, AUTOGEN produces a report regarding changes it makes to the default parameters to generate the new current parameter set. The AGEN$PARAMS.REPORT is generated in the SYS$SYSTEM path on every run of AUTOGEN which includes the GENPARAMS phase. Any errors or inconsistencies detected in MODPARAMS will be reported in AGEN$PARAMS.REPORT.

136

AUTOGEN - Logging AUTOGEN issues useful information on SYS$OUTPUT, also. Some SysAdmins find this useful: $ @SYS$UPDATE:AUTOGEN/OUT=AGEN.LOG start_phase end_phase

AUTOGEN also produces some useful messages on its SYS$OUTPUT stream. A useful technique is to specify a log file as /OUTPUT when invoking AUTOGEN, as shown in the slide.

137

Session 1065

Useful Tips and Tricks

During our discussion of the system startup sequence, we looked at some tips for logging the site-specific startup procedure, saving a crash dump and doing a preliminary analysis, creating group-level logical names and soft-coding the initial number of logins set during system startup. During our discussion of logical names, we looked at ways to modify the logical name table search list for processes and groups of users and ways to combine the OpenVMS-supplied logical names with our own to help keep our system management and operational procedures separate from the ones supplied by/with OpenVMS. Here we’ll look at a couple more tricks that may be useful.

138

Useful Tips and Tricks An “uptime” command: $ SHOW SYSTEM/NOPROCESS $ UPT*TIME :== SHOW SYSTEM/NOPROCESS Works in V6.2 and later.

A HELP enhancement, ala “man | less”: $ HELP/PAGE=SAVE=64 $ MAN :== HELP/PAGE=SAVE=64

Before we begin talking about system management tools, here are a couple of useful tips and tricks that can be helpful in the course of everyday operations. This slide presents a way to establish an “uptime” command like UN*X has. SHOW SYSTEM/NOPROCESS shows only the banner line with no process detail. /NOPROCESS is new for SHOW SYSTEM since V6.2. Also shown is a way to make HELP behave like the “man” command on some flavors of UN*X which pipe the output through “less” or “more”. HELP/PAGE=SAVE provides that you can scroll back through a long HELP text without needing to be using a terminal program on a PC or laptop. Using /PAGE=SAVE=64 provides a very good sized scroll-back buffer (circa. 64 screens worth of text).

139

Useful Tips and Tricks A simple command to show usage: $ SHL :== PIPE SHOW USERS/FULL | (READ SYS$PIPE P9 ; WRITE SYS$OUTPUT P9 ; READ SYS$PIPE P9 ; WRITE SYS$OUTPUT P9 ; SET LOGINS)

This slide presents a way to establish a simple command to show how many unique user names are logged in and how many processes those users represent. The current interactive logion statistics are displayed as well. Because this uses the PIPE command, it only works on V7.x and later of OpenVMS. Here is an example of the output from this command: $ shl OpenVMS User Processes at 30-SEP-2002 11:33:56.56 Total number of users = 7, number of processes = 86 %SET-I-INTSET, login interactive limit = 350, current interactive value = 82

140

Useful Tips and Tricks A simple command to show usage: $ SHL OpenVMS User Processes at 13-JUL-2006 20:22:50.09 Total number of users = 1, number of processes = 3 %SET-I-INTSET, login interactive limit = 64, current interactive value = 1

This slide presents a way to establish a simple command to show how many unique user names are logged in and how many processes those users represent. The current interactive logion statistics are displayed as well. Because this uses the PIPE command, it only works on V7.x and later of OpenVMS. Here is an example of the output from this command: $ shl OpenVMS User Processes at 30-SEP-2002 11:33:56.56 Total number of users = 7, number of processes = 86 %SET-I-INTSET, login interactive limit = 350, current interactive value = 82

141

Useful Tips and Tricks A MORE command: $ ipt := sys$input $ if f$trnlnm( "sys$pipe" ) .nes. "" then $ ipt := sys$pipe $ if p1 .eqs. "" then p1 = ipt $ if f$type( more_pages ) .eqs. "" then $ more_pages = 64 $ type/page=save='more_pages' &p1 $ exit

This slide presents a way to establish a “more” command using TYPE/PAGE=SAVE in a PIPE-line. Note that the SYS$PIPE logical name exists only in the second or later segment of a PIPE-line. This can be used detect whether the procedure is being used as the target for PIPEd output and the input source for TYPE can be selected accordingly. The MORE_PAGES symbol can be defined in the user’s LGICMD, if desired. In the slide, the code shown assumes a value of 64 for this symbol if it is not present in the process’s environment.

142

Useful Tips and Tricks VMS Disk “Partitions” – Logical Disks » Actual devices which use a container file or a specified range of blocks on a disk to provide logical disk devices. » Need to install the LD V8 or later kit » See HELP LD after installing. » Available for V7.3-2 and later (Alpha and I64 only).

The LD – Logical Disk – software has been around as freeware from Digital for many years. It provides the ability to use container files and now ranges of disk blocks to provide logical disk devices that behave more or less identically to a physical disk device. The software is present but not supported or installed beginning with V7.3-2. To achieve the full functionality, obtain the newer PCSI kit for LD V8 from the OpenVMS freeware CD site. HELP is provided for the LD command once the kit is installed. Beginning with OpenVMS V8.2, LD becomes a supported part of the operating system environment.

143

Useful Tips and Tricks VMS Disk “Partitions” – Logical Disks Can be useful with disk storage arrays which are not easily reconfigured. For example: EMC Symmetrix, DMX, etc.

Example (Small Alpha with direct-attached RZ29B, 4.3GB SCSI disk): $ ld connect dka100:/lbn=(start=0,count=3145728) lda1/allo=1 $ ld connect dka100:/lbn=(start=3145728,count=3145728) lda3 $ ld connect dka200:/lbn=(start=0,count=3145728) lda2 $ ld connect dka200:/lbn=(start=3145728,count=3145728) lda4 $ moun/noassi/syst dsa1/shad=($1$lda1,$1$lda2) shadow1 shadow1 $ moun/noassi/syst dsa2/shad=($1$lda3,$1$lda4) shadow2 shadow2

The LD – Logical Disk – software can be useful in environments where very large but not easily reconfigured storage arrays are in use. In such cases, large devices up to OpenVMS’s current limitations can be provided to the console and the operating system, and then “carved up” using LD into smaller disk units. In this scenario, care must be taken so that when used in a production environment the I/O queue of the underlying physical disk unit is not being overtaxed resulting in I/O contention. Provide a good number of large units so the I/O load can be spread out over the physical devices provided by the array. Take plentiful performance measurements in your development / test environment. This may not be suitable for performance-critical environments. Field experience with this is limited or non-existent. Use this with care.

144

Session 1065

OpenVMS Security Elements

145

OpenVMS Security Elements An OpenVMS system is only as secure as the SysAdmin makes it. Understanding and using the elements of OpenVMS Security is the best way to help ensure the security and integrity of an OpenVMS system.

System Security is an important job of the OpenVMS SysAdmin. The system will only be as secure as the SysAdmin makes it. An understanding of OpenVMS Security Elements will help the SysAdmin be effective at keeping the system secure. Effectively understanding and using the elements of OpenVMS Security is the best way to help ensure the security of an OpenVMS system and the security and integrity of the data it contains and processes. This part of the presentation will look briefly at some of the key elements of OpenVMS security. An in-depth security presentation may be available as a technical breakout session in the symposium, or it may be presented as full-day seminar at a future symposium.

146

OpenVMS Security Elements Points to remember: TELNET and FTP sessions are not encrypted, passwords are sent as clear text. Use Secure Shell and Secure FTP for best security. LAT and DECnet are not encrypted, passwords are sent as clear text.

Many forms of network access result in passwords being sent as clear text. Among them are TELNET and FTP, to name only two. For the best security, use Secure Shell and Secure FTP to help keep password secure. LAT and CTERM (DECnet SET HOST) do not provide for encryption. User names and passwords are sent as clear text.

147

OpenVMS Security Elements User Identification Codes [group,user] Similar to UN*X UIDs, except digits are always octal. Users belong to only one UIC group. Use Rights Identifiers to grant additional access.

The first key element of OpenVMS security is the User Identification Code or UIC. The protection masks assigned to object such as files, devices, in-memory objects, etc. are all driven by the UIC. Numeric UICs have only digits in the group and user (member) fields. Where UIC identifiers exist, UICs are sometimes displayed as Alphanumeric expressions such as [SYSTEM,SYSADMIN]. UICs are similar, but not identical, to UN*X UIDs. Users belong to only one UIC group. If additional associations are required, rights identifiers can be created and GRANTed to users as needed.

148

OpenVMS Security Elements Protection Masks Based on the UIC. Four classes of permission: System Owner Group World UN*X only has Owner, Group, World

UIC-based protection masks provide four classes of permission or access: System Owner Group World System class users have a UIC group less than or equal to the value of the system parameter MAXSYSGROUP. The Owner class includes any user who has the UIC found in the owner field of an object descriptor. The Group class includes those users whose UIC group number matches that of the owner. The World class includes all users who do not match the other criteria. UN*X has only the Owner, Group and World fields - the “root” (super) user (almost) always has full access to everything.

149

OpenVMS Security Elements Levels of Permission in each class: Files Read - Open read only Write - Open write only Execute - Run (if it’s a program/proc.) Delete - Delete the file (Requires write access to parent directory.)

For each class of user, there are four levels of permission. For files: Read access grants permission to open the file read-only. Write access grants permission to open the file write-only. Execute access grants permission to run a program (activate an image) or execute a DCL procedure. Delete access grants permission to delete a file (requires Write access to the file’s parent directory). Note that for OpenVMS-I64, executable images need both Read and Execute access (RE).

150

OpenVMS Security Elements Levels of Permission in each class: Directories Read - List files Write - Create/delete files Execute - Traverse the directory (Look up files) Delete - Delete the directory (Requires Write access to parent).

For each class of user, there are four levels of permission. For Directories: Read access grants permission to list the contents of the directory. Write Access grants permission to create or delete files in the directory. Execute access grants permission to look up files in the directory. Delete access grants permission to delete the directory (requires Write access to the parent directory).

151

OpenVMS Security Elements Levels of Permission in each class: Devices READ WRITE LOGICAL I/O PHYSICAL I/O

For each class of user, there are four levels of permission. For devices: Read access grants permission to open a device read-only. No other permission is granted. For devices, Write access grants permission to open a device write-only. No other permission is granted. For devices, Logical I/O access grants permission to perform Logical I/O to a device. No other permission is granted. For devices, Physical I/O access grants permission to perform Physical I/O to a device. No other permission is granted.

152

OpenVMS Security Elements Levels of Permission in each class: Queues READ - Display queue, jobs MODIFY - Modify queue, jobs SUBMIT - SUBMIT/PRINT jobs DELETE - Delete jobs or the queue

For each class of user, there are four levels of permission. For Queues: Read access grants permission to display characteristics of the queue or a jobs in the queue. Modify access grants permission to modify characteristics of the queue or a jobs in the queue. Submit access grants permission to submit jobs to the queue (SUBMIT or PRINT). Delete access grants permission to delete jobs in the queue or the queue itself.

153

OpenVMS Security Elements Access Control Lists Specify access control beyond the UIC based protections. Consist of access control entries.

Access Control Lists (ACLs) are used to specify access permissions beyond what the UIC based protect mask allows for. ACLs consist of Access Control Entries (ACEs). The OpenVMS Guide To System Security describes access control in detail. The documentation is available on-line at this URL: http://www.hp.com/go/openvms/doc

154

OpenVMS Security Elements Access Control Entries Associate access control with UICs or Rights Identifiers Levels of access: READ WRITE

DELETE CONTROL

EXECUTE Object owner always has CONTROL

Access Control Entries (ACEs) associate access permissions with UICs or Rights Identifiers ACEs can specify levels of access permission or permission to modify the object’s security profile (Control access). The owner of an object always has Control access.

155

OpenVMS Security Elements Rights Identifiers Created using AUTHORIZE. Can be associated with a resource (disk files - to control disk quotas). GRANTed to or REVOKEd from users using AUTHORIZE. Can be dynamic – non-privileged users can acquire and release using SET RIGHTS_LIST in DCL.

Rights Identifiers for use in setting up Access Control Entries (ACEs) are created and managed using the AUTHORIZE utility. Identifiers can be simple identifiers or they can be associated with common resources, such as to cause disk usage for a file to be charged against a specific UIC’s disk quota. There are other types of identifiers also, such as those associated with protected subsystems and those associated with UICs. Identifiers can be GRANTed to users or REVOKEd from users by using AUTHORIZE program. Note that identifiers can be dynamic - non-privileged users can acquire and release them using the SET RIGHTS_LIST command in DCL.

156

OpenVMS Security Elements Propagating ACEs, Default Protections Set an ACE on a directory with the DEFAULT attribute. Default Protection ACE is set on a directory. Will be applied to new files, or use SET SECURITY/DEFAULT to propagate to existing files.

Access Control Entries (ACEs) and default protection masks can be propagated onto existing files in a directory tree. On the root directory of a tree: Set an ACE with the DEFAULT attribute. Set a Default Protection ACE. These will be applied to new file created in the root directory. To propagate these ACEs onto all the files in the tree, use the SET SECURITY/DEFAULT command with a wildcarded path. Example: $ SET SECURITY/DEFAULT ddcu:[root_level_directory…]*.*;*

157

OpenVMS Security Elements Set ACEs in the proper sequence First matching ACE determines access. Enter ACEs from least restrictive to most restrictive. EDIT/ACL can be helpful. ACL takes priority over UIC based protection mask.

The key to successful use of ACLs is to set ACEs in the proper sequence. When the system is determining access permission, only the first matching ACE is used. ACEs should be entered into the ACL starting with the least restrictive to the most restrictive. The ACL Editor (EDIT/ACL) can be helpful for objects that have large ACLs. Note that the ACL takes priority over the UIC-based protection mask. If the UIC-based protection grants access but the ACL doesn’t, access to the object will be denied.

158

Session 1065

Closing Comments, Q&A

159

Freeware Sources − The OpenVMS Freeware CDs are online at the OpenVMS website. − The DFWCUG DECUS CD-ROM Archive: ftp://ftp.montagar.com/decus/

Here is a brief list of some sites where OpenVMS freeware (or links to it) can be found. The contents of the OpenVMS Freeware CDs V4 and V5 can be found on line at the OpenVMS website. The Dallas / Fort Worth LUG maintains an extensive archive of free software and DECUS CDs. Note that the ftp://ftp.montagar.com/ URLs were tested successfully with an older Netscape (V4.77). The site was also accessed successfully using the Multinet FTP client on OpenVMS. Attempts to access the site using Internet Explorer V6 on Windows were less than successful.

160

Freeware Sources − OpenVMS FAQ http://www.hp.com/go/openvms/faq − DJE Systems OpenVMS Freeware archive: http://www.djesys.com/freeware/vms/

Links to other freeware sites can be found in the OpenVMS Frequently Asked Questions (FAQ) which can be found at the URL shown. DJE Systems also has some selected items available for download. Not all of them are listed on our freeware page; however, they can be downloaded by going to the URL shown above. Look for the following files associated with this session at the URL shown above: Session_1065.ppt

This PowerPoint Presentation

This session is based on a pre-symposium seminar given at HP/ETS2002 in St. Louis, Missouri (USA). The presentation and associated freeware are available at the DJE Systems VMS Freeware archive: 4038_freeware.zip

Additional DCL tools from DJE Systems

seminar_1024_2002.zip

Arthur Cochrane’s original files and PowerPoint slides

This presentation can be found on-line shortly after the symposium at this URL: http://www.djesys.com/vms/support/

161

Session 1065 Thanks for coming! Disclaimer: All information is correct to the best of the author’s knowledge. Please fill out the evaluation forms, if available.

162