![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
First, you must follow the steps described in the previous sections to create the top-level default directory and to add the account. Then you can associate the account with a particular terminal or port using the following format:
ALF ADD device user [/TERMINAL] [/PORT] [/PROXY] [/LOG]
where:
| device | is the terminal or port name that you want to assign to a user name. Note that device must be a terminal name if you do not specify qualifiers on the command line. |
| user | is the account user name that you want to assign to a particular terminal or port. |
| /TERMINAL | causes SYSMAN to treat device as a terminal name. This is the default behavior. |
| /PORT | causes SYSMAN to treat device as a port name. If the port name contains a special character such as a slash ( / ) or if it contains lowercase letters that you want to preserve, you must enclose the port name within quotation marks. Be aware that anything within quotation marks is written literally to the ALF database file. For example, if the actual port name contains uppercase letters as well as special characters, be sure to specify uppercase letters within the quotation marks. Otherwise, a mismatch will occur between the actual port name and what is specified in the SYSALF.DAT file. |
| /PROXY | causes SYSMAN to check that device is in the NODE::USERNAME format, which can be up to 63 characters in length. |
| /LOG | causes SYSMAN to display a message that the device and user have been added to the ALF database. |
To protect automatic login accounts, set the AUTOLOGIN flag in the account's UAF record. This flag makes the account available only by autologin, batch, and network proxy.
Examples
The following example shows how to invoke SYSMAN and assign terminal TTA0 to the INVENTORY25 account:
$ RUN SYS$SYSTEM:SYSMAN SYSMAN> ALF ADD TTA0 INVENTORY25
When you create ALF records for proxy accounts, the device parameter can be as long as 63 characters. For example:
SYSMAN> ALF ADD VMS:.ZKO.VMSORG.SYSMAN.CLIENT1::SYSTEM FOOBAR
In this command, VMS:.ZKO.VMSORG.SYSMAN.CLIENT1::SYSTEM is the value of the device parameter.
For more information about autologin accounts and the SYSMAN ALF commands, see the OpenVMS System Management Utilities Reference Manual and the OpenVMS Guide to System Security.
This section describes how to set up a project account that uses access control lists (ACLs) to control access to files shared by members of a project group. See the OpenVMS Guide to System Security for complete details on setting up accounts with ACLs.
How to Perform This Task
You must first add an identifier to the rights database for the project account. Use the AUTHORIZE command ADD/IDENTIFIER to add identifiers to the rights database and then associate users as holders of existing ACL identifiers with the AUTHORIZE command GRANT/IDENTIFIER. All users who hold the project's identifier can use the disk space of the project account.
You can set up the project account so that disk space is charged to the project, rather than to individual users, by assigning the resource attribute to the project identifier.
Example
The following example summarizes the steps for setting up a project account:
$ RUN SYS$SYSTEM:AUTHORIZE
UAF> ADD/IDENTIFIER KITE_FLYING/ATTRIBUTES=RESOURCE
{message}
UAF> GRANT/IDENTIFIER KITE_FLYING GEORGE/ATTRIBUTES=RESOURCE
{message}
UAF> GRANT/IDENTIFIER KITE_FLYING LINDORF/ATTRIBUTES=RESOURCE
{message}
UAF> EXIT
$ RUN SYS$SYSTEM:SYSMAN SYSMAN> DISKQUOTA ADD KITE_FLYING/PERMQUOTA=2000/OVERDRAFT=200 SYSMAN> EXIT
$ CREATE/DIRECTORY [KITE_FLYING]/OWNER=[KITE_FLYING]
$ SET SECURITY [000000]KITE_FLYING.DIR;1 - _$ /ACL=((DEFAULT_PROTECTION,S:RWED,O:RWED,G,W) - _$ (IDENTIFIER=KITE_FLYING, ACCESS=READ+WRITE+EXECUTE), - _$ (IDENTIFIER=KITE_FLYING,OPTIONS=DEFAULT,ACCESS=READ+WRITE+EXECUTE))
Access must be granted through ACL entries, because the owner identifier of the directory and the files (KITE_FLYING) does not match the UIC of any of the project members; thus, only world access is available through the UIC-based protection mask. The first ACE of the specified ACL gives all project members read, write, and execute access to the directory; the second ACE gives them read, write, and execute access for all files created in the directory.
Note that project members are not allowed to delete (or control) files created by others. However, the members each have complete access to files that they have created in the directory, because the file system supplies an additional default ACL entry that grants to the creator control access plus the access specified in the OWNER field of the UIC-based protection mask. This ACE appears only when the owner of the created file does not match the UIC of the creator.
Thus, when LINDORF creates the file [KITE_FLYING]THURSDAY.TXT, the file receives the following access control list by default:
(IDENTIFIER=LINDORF,OPTIONS=NOPROPAGATE, ACCESS=READ+WRITE+EXECUTE+CONTROL) (IDENTIFIER=KITE_FLYING,ACCESS=READ+WRITE+EXECUTE)
You can use the Creator ACE command in the ACL editor to add an extra ACE to the ACL for a file created within the directory to which you assign the Creator ACE. The Creator ACE applies only when the following conditions exist:
See the OpenVMS System Management Utilities Reference Manual and the OpenVMS Guide to System Security for more information about the Creator ACE.
A network proxy account allows users on a remote node in a network to access data by way of a local account on your system. Proxy accounts are useful when you want to grant one or more users on a remote node access to specific files, but you do not want to give them a private account on your system. Very often, system managers set up proxy accounts as restricted. You establish and control proxy accounts with the Authorize utility (AUTHORIZE).
With proxy accounts, you can authorize one or more users on a remote node to enter DCL commands that access data from a particular account on your system. Proxy accounts allow remote users to access specific local data (for example, type and print files) without having to log in to your system or use an access control string. Remote users assume the same file access rights as the local account and also receive the default privileges of the local account. The following sections explain the procedures for setting up proxy accounts.
To properly maintain proxy database consistency across all members of a mixed-version OpenVMS Cluster system, you must perform all proxy modifications from either of the following:
This restriction ensures that the NET$PROXY.DAT database is updated with correct proxy information.
For more information about proxy accounts, see the OpenVMS Guide to System Security.
A proxy account permits an authorized user from a remote node to log in to a local node, as if the user owned an account on the local node. Proxy accounts are created and maintained using the Authorize utility (AUTHORIZE). See the OpenVMS System Management Utilities Reference Manual for more information about the Authorize utility.
On OpenVMS systems, the following information is stored in two proxy authorization files, NETPROXY.DAT and NET$PROXY.DAT:
Note
Deleting either NETPROXY.DAT or NET$PROXY.DAT will result in incorrect functioning of proxy access on systems running DECnet for OpenVMS Phase IV. Also, many applications such as ALL-IN-1 rely on NETPROXY.DAT.
The SYSUAF.DAT file, on your local system, must associate proxy accounts with user accounts. You will probably want to create a "standard access" account in the UAF for proxy accounts. For example, you could create an account named REMOTE_MKT with limited privileges, which allows access to certain data files on your local system.
Suppose you have a group of users on your local system who prepare marketing reports and who rely on input from users on other systems. You would assign the REMOTE_MKT account in SYSUAF.DAT the same group number and default privileges you assign to the local marketing group. In this way, the remote contributors could access any data files that are "owned" by users in your marketing group and that are not protected from group access.
How to Perform This Task
Use the AUTHORIZE command CREATE/PROXY to create and initialize network proxy authorization files:
UAF> CREATE/PROXY
Create a proxy account by adding entries to the network proxy authorization file; these entries equate one or more users on a remote node to users on your home node.
How to Perform This Task
The command syntax for adding a proxy account is as follows:
ADD/PROXY node::remote-user local-user/DEFAULT [,...]
You can allow remote users access to up to 16 total local accounts: 1 default proxy account and 15 alternate proxy accounts. Use the /DEFAULT qualifier to specify the default proxy account.
Examples
UAF> ADD/PROXY HAL::WALTER REMOTE_MKT/DEFAULT,PROXY2,PROXY3
Caution
Because the remote user receives the same privileges as the local user, do not set up proxy accounts associated with local accounts that have special privilege. Granting remote users such access powers poses a threat to the security of your system.
UAF> ADD/PROXY RSTS32::[360,54] GENERIC/DEFAULT
UAF> ADD/PROXY HAL::* */DEFAULTThis command authorizes any user on the remote node HAL to access any account with the same user name on your system.
UAF> ADD/PROXY HAL::BARBARA */DEFAULT
UAF> ADD/PROXY RUBY::DELAPORT DELAPORT/DEFAULT,SYSTEM %UAF-I-NAFADDMSG, proxy from OMNI:.US.RUBY::DELAPORT to DELAPORT added %UAF-I-NAFADDMSG, proxy from OMNI:.US.RUBY::DELAPORT to SYSTEM added
To remove proxy accounts, use the AUTHORIZE command REMOVE/PROXY; for example:
UAF> REMOVE/PROXY RUBY::DELAPORT SYSTEM
This command removes proxy access from RUBY::DELAPORT to the local SYSTEM account.
To display proxy accounts, use the AUTHORIZE command SHOW/PROXY. This command displays only the first 255 characters of the node name, although the command can handle a maximum of 1024 characters.
The following examples assume that proxy access from RUBY::DELAPORT to the local account DELAPORT has been added to the network proxy authorization file as the default. (The second example shows the DECnet-Plus equivalent of RUBY::DELAPORT.)
Examples
UAF> SHOW/PROXY *::*
RUBY::DELAPORT
DELAPORT (D)
UAF> SHOW/PROXY *::*
OMNI:.US.RUBY::DELAPORT
DELAPORT (D)
UAF> SHOW/PROXY/OLD *::*
Whenever a proxy login request occurs, the system verifies that proxy access on the participating nodes is enabled. (By default, both incoming and outgoing proxy access is enabled for each node.)
On systems running DECnet for OpenVMS, you can change proxy access or disable it totally by using the Network Control Program (NCP). The DECnet for OpenVMS Networking Manual describes how to use NCP to control proxy access.
On systems running DECnet-Plus software, you can change proxy access by using the Network Control Language utility (NCL). The DECnet-Plus Network Control Language Reference manual describes how to use NCL.
When managing user accounts, you might have to manage a user's mail account. For example, you may want to perform the following tasks:
The following sections explain how to perform all of these tasks.
All users can modify and display information about their own records using various SET and SHOW commands available within Mail. These commands access SYS$SYSTEM:VMSMAIL_PROFILE.DATA, which is a single-key indexed sequential file containing information for each user.
With SYSPRV, you can modify the records of other users. Table 6-7 lists the fields in the user profile record and the MAIL command you can use to modify those fields.
| Field | Command |
|---|---|
| Username | -------- |
| Forwarding address | SET FORWARD |
| Personal name | SET PERSONAL_NAME |
| Editor name | SET EDITOR |
| Copy SEND/REPLY flags | SET COPY_SELF |
| Autopurge flag | SET AUTO_PURGE |
| Mail file subdirectory name | SET MAIL_DIRECTORY |
| New mail count | READ/NEW |
| Default queue | SET QUEUE |
| Default form | SET FORM |
| Carbon copy enabled | SET CC_PROMPT |
You can arrange mail forwarding for users without accounts on the system by using the command SET FORWARD/USER=user.
Typically, once you have deleted a user's record in the UAF, you will also want to remove that user's information from the user profile database. You can remove a record from the user profile database with the REMOVE command.
Certain flags set in a user's UAF record can affect the user's Mail environment. You can set the appropriate flags in a user account by specifying the following flags with the /FLAGS qualifiers using AUTHORIZE:
| Flag | Meaning |
|---|---|
| [NO]DISNEWMAIL | Enables or disables the display of the new mail count when the user logs in to the system. |
| [NO]DISMAIL | Allows or restricts the receipt of new mail. |
This section contains detailed descriptions of the resource control attributes you can assign to a user process when creating a record in the UAF.
VAX and Alpha systems allocate and deallocate memory for processes in units called pages. A page on a VAX system is 512 bytes. On Alpha systems, the page size will be one of four values: 8KB (8192 bytes), 16KB, 32KB, or 64KB. A particular Alpha system will implement only one of the four page sizes and the initial set of machines use an 8KB page.
In most cases, Alpha systems present to users, and accept from users, units of memory in a 512-byte quantity called a pagelet. Thus, one pagelet is the same size as one VAX page. Also, on an Alpha 8KB computer, 16 pagelets equal 1 Alpha page. The following conversion table shows the relationship between pages, pagelets, and bytes:
One Alpha pagelet = one VAX page = 512 bytes One Alpha page = 16 Alpha pagelets = 16 VAX pages = 8192 bytes
Authorize utility commands, parameters, and default values are identical. However, the default values for process quotas related to memory use might be inappropriate for some Alpha system users.
See A Comparison of System Management on OpenVMS AXP and OpenVMS VAX for more information about Alpha system management. (This manual has been archived but is available in PostScript and DECW$BOOK (Bookreader) formats on the OpenVMS Documentation CD-ROM. A printed book can be ordered through DECdirect (800-354-4825).)
Each system user is limited in the consumption of such resources as system memory, volatile (pagefile) disk space, number of processes, and I/O requests. You set limits when you create an account for the user with the Authorize utility.
Limits control the way in which a process shares its allotment of a resource with the subprocesses it creates. In addition to restricting the number of processes that a single user or account has at any given time, the system uses four types of limits for sharing resources. Table 6-1 describes these limits.
When you create an account, you assign values to the limits shown in Table 6-8. These limits are described in the following sections. Usually, you simply assign the default values for these limits. However, see the OpenVMS Performance Management for a discussion of how to evaluate and adjust the limits in the context of performance optimization strategies.
Table 6-8 summarizes each of these limits, the value supplied in the UAF record for the SYSTEM and DEFAULT accounts, and the type of limit.
| Limit | VAX SYSTEM Value | VAX DEFAULT Value | Alpha SYSTEM Value | Alpha DEFAULT Value | Type¹ | Description |
|---|---|---|---|---|---|---|
| ASTlm | 50 | 0 | 250 | 250 | N | AST queue limit |
| BIOlm | 40 | 40 | 150 | 150 | N | Buffered I/O count limit |
| Bytlm | 32768 | 32768 | 64000 | 64000 | P | Buffered I/O byte count limit |
| CPU | 0 | 0 | 0 | 0 | D | CPU time limit (0 = no limit) |
| DIOlm | 40 | 40 | 150 | 150 | N | Direct I/O count limit |
| Enqlm | 300 | 200 | 2000 | 2000 | P | Enqueue quota |
| Fillm | 300 | 300 | 100 | 100 | P | Open file limit |
| JTquota | 4096 | 4096 | 4096 | 4096 | P | Initial byte quota for jobwide logical name table |
| Maxacctjobs | 0 | 0 | 0 | 0 | S | Maximum active processes for a single account (0 = no limit) |
| Maxdetach | 0 | 0 | 0 | 0 | S | Maximum detached processes for a single user name (0 = no limit) |
| Maxjobs | 0 | 0 | 0 | 0 | S | Maximum active processes for a single user name (0 = no limit) |
| Pgflquo | 20480 pages | 32768 pages | 50000 pagelets | 50000 pagelets | P | Page file limit |
| Prclm | 10 | 2 | 10 | 8 | P | Subprocess creation limit |
| TQElm | 30 | 40 | 20 | 10 | P | Timer queue entry limit |
| WSdef² | 256 pages | 256 pages | 2000 pagelets | 2000 pagelets | N | Default working set size |
| WSextent² | 40960 pages | 1024 pages | 16384 pagelets | 16384 pagelets | N | Working set extent |
| WSquo² | 512 pages | 512 pages | 4000 pagelets | 4000 pagelets | N | Working set quota |
Table 6-9 shows the names and descriptions of the SYSTEM and DEFAULT accounts whose values are listed in Table 6-8. The /EXPIRATION qualifier is also described in Table 6-9.
System managers are often responsible for setting up and managing peripheral devices such as terminals and printers. This chapter describes these tasks. For information on managing storage media such as disks and tapes, see Chapter 8.
Information Provided in This Chapter
6017P017.HTM OSSG Documentation 22-NOV-1996 14:21:40.98
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.