| Previous | Contents |
A recurring request from CMS users is for better configuration management support. This chapter attempts to answer these requests by explaining the general philosophy of CMS in regards to configuration management. It also illustrates ways to fulfill various configuration management requirements not directly supported by CMS.
Specifically, this chapter describes the following:
This description of a Software Configuration Management (SCM) system is based on the Level 2 SCM process area described in the Software Engineering Institute's (SEI) Capability Maturity Model (CMM). See the The Capability Maturity Model: Guidelines for Improving the Software Process (Carnegie Mellon University / Software Engineering Institute (1995) ) .
The following list of requirements is based on the key SCM activities described in the CMM:
While this list is not exhaustive, it does provide a basis for
evaluating an SCM tool, or in this case, CMS.
5.2 The Goals of CMS
CMS was not designed to meet the requirements as an SCM system but to be part of such a system. CMS is a code management tool providing an efficient and reliable system for storing files and tracking all changes to those files. To this end, the main goal of CMS is to ensure the integrity of the files within a library. It is this library which forms the base of CMS.
Most of the interaction with the library (from the command-line, DECwindows, or the CMS Client interface) is performed using public callable routines. The routines may be used to write your own interface to a CMS library. This interface could hide CMS from the users and implement all the checking and reporting requirements you have. Section 5.4 briefly describes, and provides an example of using, the callable routines.
Many of the requirements identified for SCM are directly supported by CMS:
Although CMS directly meets most of the version control and reliability requirements of an SCM system, additional effort is required in the areas of SCM reporting, change requests, and problem report tracking.
CMS meets most of the version control and reliability requirements but
requires help with change control and reporting.
5.3 Common CMS Commands for Configuration Management
5.3.1 Generate a CMS History File (SHOW HISTORY)
A record is generated in a library's history file whenever a CMS command alters the state of the library or is entered with a remark.
The SHOW HISTORY command allows you to review the history file and display a chronological list of the transactions performed on a library. It allows you to select the transactions that are displayed through different parameters and qualifiers on the command. For example, you can display information on a particular transaction (such as REPLACE) on transactions occurring within specified dates, on a particular object (element, class or group), or on any combination of the following:
SHOW HISTORY [object-expression]
/BEFORE=date-time and /SINCE=date-time
/TRANSACTIONS=(keyword,...)
Displays all transaction records generated by a specific command.
You can specify the following keywords with this qualifier:
ACCEPT FETCH REMOVE ALL INSERT REPLACE
CANCEL MARK RESERVE COPY MODIFY REVIEW
CREATE REJECT SET DELETE REMARK UNRESERVE
VERIFY
/USER=username
Displays all history records generated by a specific user.
|
In addition to the SHOW HISTORY command, CMS provides the DIFFERENCES
and ANNOTATE commands which generate information about changes made to
individual elements. ANNOTATE documents the development of an element
by creating a line-by-line file listing the changes made in each
specified element generation. DIFFERENCES compares files, element
generations, or a file and an element generation.
5.3.3 Track File Development (CREATE or MODIFY ELEMENT/REVIEW)
Development status may be maintained and monitored in CMS if schemes are devised to do so. For example, elements may be placed into release or testing classes when ready. As long as these schemes are followed, showing the contents of these classes will reveal the current status of the elements. Changes to elements or classes may also be tracked through the review attribute or notification access control entries (see Section 5.6).
Using the CREATE or MODIFY ELEMENT /REVIEW qualifier, you can specify that newly-created generations of elements are marked for review by placing them on a review pending list. If an attempt is made to reserve or fetch a generation under review, CMS displays a message and prompts for confirmation to continue:
CMS> RESERVE test-element "remark" Generation 1 of element TEST-ELEMENT has a review pending Proceed? [Y/N] (N): |
These messages are issued for all attempts to access the generation until the review status is resolved. Table 5-1 provides a summary of the review commands, which are available from the command-line, DECwindows interface, and callable routines:
| Command | Action |
|---|---|
| ACCEPT GENERATION | Changes the review status of each specified element generation from "pending" to "accepted" and removes it from the review pending list. |
| CANCEL REVIEW | Changes the review status of each specified element generation from "pending" to "none" and removes it from the review pending list. |
| MARK GENERATION | Marks each specified element generation for review and adds it to the review pending list. |
| REJECT GENERATION | Changes the review status of each specified element generation from "pending" to "rejected" and removes it from the review pending list. |
| REVIEW GENERATION | Associates a review comment with one or more specified element generations. |
| SHOW REVIEWS_PENDING | Displays a list of element generations that currently have review pending status. |
If a review is accepted or canceled, CMS halts the review-related messages and confirmation on subsequent reservation attempts. If the review is rejected, CMS issues a message that the generation was reviewed and rejected. However, the generation is still accessible so that the problems within it may be corrected:
CMS> FETCH test-element "remark" Generation 1 of element TEST-ELEMENT has been rejected %CMS-S-FETCHED, generation 1 of element TEST-ELEMENT fetched |
A generation that currently has a review pending or that was previously rejected is automatically marked for review, regardless of the setting of the element's review attribute. |
CMS provides a complete set of routines that may be used to access and interact with CMS libraries from user-written programs. The callable routines are the "kernel" which presents a uniform interface to the CMS-supplied front ends, the CMS Client, and any user-written front ends:
Figure 5-1 shows the relationship between the callable routines, the other components of CMS, and a CMS library.
Figure 5-1 CMS Callable Routines Interfaces
+-------------------+
| CMS Client |
+---------^---------+
|
+---------V---------+
| CMS Client Server <----+
+-------------------+ |
|
| +-------------------+
+-------------------+ +----> | +-------------------+
| CMS command-line <---------> | | |
+-------------------+ | | | |
| Callable Routines <-----> CMS LIBRARY |
| | | |
+-------------------+ | | | |
| CMS DECwindows <---------> | +-------------------+
+-------------------+ +----> |
| +-------------------+
|
+-------------------+ |
| User Program <----+
+-------------------+
|
The callable routines are described in DIGITAL Code Management System Callable Routines Reference Manual. The routines can be called from the majority of the languages supported on OpenVMS, and the documentation reflects this by having examples in different languages. In general, there is an entry point into CMS for each DCL-level command, for example:
The routine CMS$CMS allows calling programs to pass a complete CLI command-line to CMS.
Appendix A contains several programs which demonstrate how the CMS callable routines can be used.
The product release notes should also be consulted for descriptions of features added after the documentation was printed and for information about known restrictions and software or documentation errors. |
A CMS library is composed of a single directory, known as the CMS library directory, and the files and subdirectories contained in it. To prevent the corruption or loss of data, it is strongly recommended that only CMS be used to access a CMS library and the files in the library.
This section describes different methods that can be used to control
access to a CMS library and its contents.
5.5.1 CMS Library Access Control Mechanisms
Access to a CMS library can be controlled by using one or more of the following methods:
The OpenVMS file system provides the lowest level of access control to a CMS library. A user can not perform CMS operations which require access to files which is not permitted by the file system. This also means that any user who has sufficient access to modify a CMS library (for example, to create or to reserve and replace elements) may also modify the library files without using CMS.
OpenVMS provides the following mechanisms to control file access:
An OpenVMS user may possess one or more privileges that override file
protection settings: BYPASS, READALL, SYSPRV, or GRPPRV. For example, a
user with BYPASS privilege has full access to any file on the system
regardless of the file protection. A user with READALL privilege can
read all files; all other file access rights are determined by the
normal file access controls. For more information on OpenVMS privileges
and how they affect file access rights, see Chapter 4 of the
OpenVMS Guide to System Security.
5.5.1.2 CMS ACLs
CMS ACLs provide a mechanism to implement more flexible control of individual CMS commands, CMS library objects (elements, groups, and classes), and objects lists. CMS ACLs refine access granted by OpenVMS file access control mechanisms; they do not override file access restrictions imposed by the OpenVMS file system.
In the absence of CMS ACLs, CMS permits all users full access to the library, subject to the file system access controls. If any CMS ACLs are present for a command or object, all access to that command or object is denied unless an access control entry (ACE) specifically granting access is present. This is an important point to remember, as it is easy to inadvertently create conditions where all users are prevented from operating on an object or class of objects.
For example, consider the following situation:
CMS> SET ACL/OBJECT_TYPE=COMMAND CREATE_ELEMENT - _CMS> /ACL=(IDENTIFIER=USER1, ACCESS=EXECUTE+CONTROL) CMS> SET ACL/OBJECT_TYPE=LIBRARY ELEMENT_LIST - _CMS> /ACL=(IDENTIFIER=USER2, ACCESS=CREATE) |
The first CMS command gives USER1 access to execute the CREATE ELEMENT command; all other users are implicitly restricted from using this command because there are no ACEs granting any other user EXECUTE permission. Similarly, the second CMS command gives only USER2 access to add element to the library element list.
Creating an element in a CMS library requires access to both the CREATE ELEMENT command and the library element list. In this library there is no user with access to both the command and the element list; therefore, no one will be able to create elements in the library.
CMS ACLs are only checked for operations performed by CMS and the CMS callable routines; they have no effect on OpenVMS utilities or user programs which access the library files by any other means.
Users with BYPASS privilege are granted full access to all CMS commands and objects.
A detailed description of CMS ACLs can be found in Section 7.2 of the
Guide to DIGITAL Code Management System for OpenVMS Systems.
5.5.1.3 Protected Subsystems
Protected subsystems provide a mechanism by which the OpenVMS file system restricts access to certain files to predefined application programs. They allow a CMS library to be configured so that it can only be accessed by CMS (or a suitably privileged user).
In a protected subsystem, file access is denied to all users; the only access allowed is via a special subsystem identifier. Rather than being granted to users, the subsystem identifier is assigned to executable images. Only the images which have the subsystem identifier assigned are able to access the controlled files.
Protected subsystems are available in the Compaq OpenVMS Operating System, Versions 6.2 and later.
For more information on protected subsystems, see:
The use of access control lists (ACLs) provide a great deal of flexibility in configuring the security profile of a CMS library; however, that flexibility comes at some cost. Large access control lists can be expensive in terms of disk storage space and execution speed.
Each access control entry (ACE) occupies disk space in the file header for OpenVMS ACLs and in the CMS library control files for CMS ACLs. When large ACLs are applied to many objects, the cummulative storage requirements for the ACLs can be significant.
Each time an object with an ACL is referenced, each ACE in the list must be compared to the identifiers held by the user until either a match is found or all of the ACEs in the list have been checked. This can be a very time consuming process when the access control lists are very long and/or the checks are performed frequently.
It many cases it may be possible to improve the performance of CMS library access by considering the following guidelines:
If your security requirements require large OpenVMS ACLs consider using
a Protected Subsystem, where the user access ACLs are applied to the
CMS executable images rather than to each file in the CMS library. The
overhead for the ACL check is once per image activation rather than
once per file access. To minimize the overhead, multiple CMS commands
should be issued from within CMS rather than on separate DCL command
lines.
5.5.2 Access Control Lists (ACLs)
An ACL defines the access rights to an object based on the user's identity (UIC) or the rights identifiers granted to the user's process. The access identifiers can be explicitly granted to the user in the system RIGHTSLIST database, be assigned by OpenVMS based on a process characteristic (e.g., "Interactive", "Local", "Dialup"), or can be assigned to a gatekeeper application for a protected subsystem. In the last case, the user process inherits the rights granted to the application only while the application is executing.
An ACL consist of a list of one or more ACEs. There are several types of ACEs; we will be discussing one of those, the Identifier ACE.
An Identifier ACE consist of three main components:
An access control list may have multiple ACEs. If this is the case, the user's access rights are determined by evaluating each Identifier ACE in order until one is found which matches an identifier held by the user. Once a match is found, the access rights specified in that ACE determine the user's access to that object; no further ACEs will be examined. For this reason the ordering of ACEs in an ACL is very important.
In general, ACEs should be specified in the following order:
More information on ACE ordering can be found in Section 4.4.6 of the OpenVMS Guide to System Security. The same principles apply to the ordering of ACEs in CMS.
The default behavior of both the OpenVMS SET ACL command and the CMS SET ACL command is to add an ACE to the beginning of an existing access control list. If this is not the desired behavior, the position of the ACE can be specified using the /AFTER qualifier for OpenVMS and CMS or the /BEFORE qualifier for OpenVMS only.
Adding an OpenVMS ACL to existing files within a CMS library will update the file headers. This causes CMS to generate "File not closed by CMS" error messages. Once the ACLs have been added, run VERIFY/REPAIR on the library to eliminate the "not closed by CMS" messages on the files. |
This section shows how to setup a CMS library for a project where
different classes of users have different access privileges to a
library and its contents. A combination of OpenVMS ACLs and CMS ACLs
are used to control access.
5.5.3.1 Access Policy
For this project there are four classes of users with regard to CMS library access:
The users in each class are identified by means of OpenVMS rights identifiers. The following rights identifiers are used in this example:
The following commands can be used to create these rights identifiers and assign them to users:
$ SET DEFAULT SYS$SYSTEM $ RUN AUTHORIZE UAF> ADD/IDENTIFIER PROJ_LIBRARIAN UAF> ADD/IDENTIFIER PROJ_DEVELOPER UAF> ADD/IDENTIFIER PROJ_USER UAF> GRANT/IDENTIFIER PROJ_LIBRARIAN librarian UAF> GRANT/IDENTIFIER PROJ_DEVELOPER devo1 UAF> GRANT/IDENTIFIER PROJ_DEVELOPER devo2 UAF> GRANT/IDENTIFIER PROJ_USER user1 UAF> EXIT |
| Previous | Next | Contents |