DIGITAL TCP/IP Services for OpenVMS
Concepts and Planning

The OpenVMS system also allows you to perform a similar function with the SET FILE/ENTER and SET FILE/REMOVE commands. The OpenVMS operating system does not maintain a count of links to a file. As a result, you can delete a file, and not delete its links.

Note

The UNIX operating system cannot distinguish the order in which links are created. Therefore, all links to a file are of equal value.

Symbolic Links

A symbolic link is a type of file that contains the name of the file to which it is connected. Symbolic links provide a path to the original file.

A UNIX symbolic link can span file systems. Unlike the hard link, the symbolic link does not maintain a link count. Symbolic links can exist after the file has been deleted. However, an error is returned if the symbolic link file is accessed after the file it names is deleted.

Note

OpenVMS files do not support symbolic links.

The OpenVMS file system supports three file organizations: indexed, relative, and sequential. OpenVMS also supports the following record formats and record attributes:

• Fixed length
• Variable length
• Variable with fixed-length control (VFC)
• Stream (including STREAM_LF and STREAM_CR)
• Undefined
• Carriage return carriage control
• Fortran carriage control
• VFC carriage control

The UNIX file system supports only byte streams. The records in UNIX text files have the same format as the OpenVMS Record Management Services STREAM_LF record format.

A UCX NFS server dynamically converts sequential files that are not streams (STREAM_LF or STREAM_CR) when read by NFS clients.

Note

NFS clients have read-only access to non-stream files.

File Size Discrepancies

Data conversion to STREAM_LF format may change the size of a file because of differences in the record formatting overhead. Therefore, the UCX NFS server does not know the correct size of a non-stream file until it has dynamically converted the file at least once.

For NFS client requests that require the file size to be returned, but do not require reading the file (for example, ls -l), the UCX NFS server returns an estimate of the size based on the unconverted size. The first time the server needs to read the file, it computes the correct converted file size and caches the information for future use.

4.6.5 File Ownership

The OpenVMS and UNIX operating systems use different mechanisms for file ownership.

OpenVMS File Ownership

The OpenVMS operating system controls file ownership and protection through a user identification code (UIC).

A UIC is a 32-bit value that consists of a 14-bit group number, a 16-bit member number, and 2 reserved bits. Each user of the system has a UIC defined in the SYSUAF file. Access to objects depends on the relationship between the UIC of the accessing process and the UIC of the object (the file or directory).

OpenVMS controls file access through an access control list (ACL). You can deny or grant read, write, execute, delete, and control access to a user or group of users who have the identifier specified by the ACL. For additional ACL information, refer to the OpenVMS documentation set.

Because the NFS protocol does not provide ACL support, the NFS client is not aware of an ACL applied to the file by the NFS server. Therefore, the NFS client cannot use an ACL to control file access. Only the NFS server can use an ACL when accessing files. Other access control is determined through standard file protections. Attempts to implement access control through NFS software cause ambiguity. Therefore, an ACL is only used to deny access to OpenVMS files.

UNIX File Ownership

The UNIX operating system controls access to files with user identification (UID) and group identification (GID). Some versions of UNIX use a 16-bit UID and GID; others may use different values. For example, DIGITAL UNIX and NFS use 32-bit UIDs and GIDs.

4.6.6 File Protections

The OpenVMS and UNIX operating systems use similar file protection schemes as shown in Table 4-4.

Table 4-4 File Protection Comparison

Mechanism	OpenVMS File System	UNIX File System
User classifications	SYSTEM (S) OWNER (O) GROUP (G) WORLD (W) Classification depends on the relationship between the UID of the accessing process and the object.	user (u) --- The user has a matching UID group (g) --- The group has a matching GID other (o) --- Any other user System category is not used; system administrators always have access to UNIX files.
Protection levels	READ (R) WRITE (W) EXECUTE (E) (controls file execution and directory search access) DELETE (D)	read (r) write (w) --- controls delete access; if a file has write protection enabled, you can delete it execute (x) --- controls file execution and directory search access
Syntax	s:rwed,o:rwed,g:rwed,w:rwed	rwxrwxrwx The protection levels are divided into groups of three characters, using the following format: First three characters: protection levels for the owner Second three characters: protection levels for the group Last three characters: protection levels for all other users

4.6.7 UNIX-Style File System on UCX Hosts

The DIGITAL TCP/IP Services for OpenVMS software allows you to create a logical UNIX-style file system on an OpenVMS host. Remote UNIX hosts that have NFS software can then access this file system. When a remote UNIX system accesses files, these files conform to the UNIX file system rules, not OpenVMS rules. This ensures that existing UNIX applications will work without change. For information about creating a UNIX file system on an OpenVMS host, refer to the DIGITAL TCP/IP Services for OpenVMS Management guide.

An NFS server on a UCX host can support multiple logical UNIX-style file systems. A logical UNIX-style file system is organized as a tree with a single root node, non-leaf nodes being directory files, and leaf nodes being either directory or regular data files. The logical UNIX-style file system resides on a Files-11 formatted disk and is represented as a set of Files-11 files called a container file system (CFS).

The UNIX-style file names and attributes are catalogued in the container file, one of the files in the CFS. The container file also has a representation of the UNIX-style directory hierarchy and a pointer to the data file for each file name. In addition to its UNIX-style name, each file in the CFS has a valid Files-11 file name assigned by the system.

An OpenVMS directory exists for each UNIX directory stored in the container file. All files cataloged in a UNIX directory are also cataloged in the corresponding OpenVMS directory. However, the UNIX directory hierarchy is not duplicated in the OpenVMS directory hierarchy.

Each UNIX-style file is represented as an OpenVMS data file. Therefore, OpenVMS utilities, such as BACKUP, can use standard methods to access these files.

This chapter outlines the following issues to consider when planning your DIGITAL TCP/IP Services for OpenVMS (UCX) network:

• Local user issues (Section 5.1)
• Remote user issues (Section 5.2)
• BOOTP configuration issues (Section 5.3)

See Chapter 6 for details about planning your BIND service implementation. Refer to the DIGITAL TCP/IP Services for OpenVMS Management guide for details about managing the other UCX services.

5.1 Considering Local User Issues

To enable UCX users access to remote TCP/IP services such as NFS and remote commands, consider the following when creating user accounts on appropriate remote nodes:

• The type of accounts you want to create for local users on the remote hosts. Users on local UCX hosts need accounts on the remote hosts that they access. Consult with the system managers of the remote hosts to determine how best to accomplish this.
• The required account privileges. Set the account privileges and access control lists to ensure that each user (or group of users) can access the remote host.
• The required account quotas. Set account quotas large enough to allow users to access remote services.
• The UID/GID for the outgoing process. Ensure that the proxy database has a valid UID/GID for each user and group of users.

To allow remote users access to UCX services, consider the type of entries you want to create for remote users accessing UCX hosts. Remote users need an entry in the proxy database (UCX$PROXY) on the local host to access such remote services as RSH, RLOGIN, and LPD.

Note

LPD requires only the remote host and user name if you enable proxy checking for that service.

For access to NFS file systems on the UCX host, grant a local OpenVMS identity (UID/GID) to remote users. You can create a single identity for all remote users, an identity for groups of users, or separate identities for each user. Choose the strategy that best suits your organization.

5.3 Determining BOOTP Configuration Issues

The BOOTP and TFTP applications allow you to download files to diskless or other remote systems. The server uses BOOTP to communicate this information to the client. The client uses TFTP to transfer the information.

When you configure BOOTP, the configuration procedure creates the BOOTP database. This database contains entries for each client that requests service from the BOOTP server. If you plan to run the BOOTP server, the following worksheet may help you organize the necessary information:

BOOTP Clients That Will Access the BOOTP Server
Client Name	System Image	System Image Location	Hardware Address	IP Address	Additional Information
Hosts That Will Access the BOOTP Server
Host Name	System Image	System Image Location	Hardware Address	IP Address	Additional Information
Gateways to be Used for Downloading
Name	Address

This chapter describes the following planning steps for implementing a BIND server on a DIGITAL TCP/IP Services for OpenVMS (UCX) host:

• Planning a Domain Hierarchy Strategy (Section 6.1)
• Developing Domain Naming Conventions (Section 6.2)
• Defining Zone Contents and Administration (Section 6.3)
• Selecting Servers (Section 6.4)
• Planning Domain Registration (Section 6.5)

Consider configuring your network to use the BIND service if you have:

• A small configuration with incoming connections from the Internet.
• A large configuration connected to the Internet.
• Any configuration that requires frequent and highly reliable access to remote hosts.

If you have a small local network that requires infrequent access to remote hosts or is not connected to the Internet, consider using a local hosts database instead of a BIND server.

6.1 Planning a Domain Hierarchy Strategy

The effectiveness of your BIND service depends on careful planning of your domain hierarchy. As you plan the domain hierarchy, you need to do the following:

1. Understand the existing domain hierarchy in your organization or company. Contact your system administrator to find the person responsible for the existing domains. If you want your domain on the public network, you need to get the correct domain registration from the InterNIC Registration Services (see Appendix A).
2. If you plan to join an existing zone, negotiate with the administrator of the upper-level domain to ensure that you create an acceptable hierarchy.
3. If you plan to administer zones for your hosts and servers, identify the owners of the parent zone to which you will be a subzone.

When designing your domain hierarchy, select the scheme that suits the needs and preferences of your organization. A common design strategy is to base the domain hierarchy on functional areas of an organization or on geographic areas of a network. For example, you could divide your domain hierarchy into geographic zones used mainly by a group of users concentrated in geographic areas. Similarly, you could create a functional zone with names used mainly by people in a particular branch of an organization.

Table 6-1 describes some of the benefits of using each hierarchy scheme.

Table 6-1 Functional and Geographic Hierarchies

Consider This Hierarchy:	If You Have:	To Implement:
Functional	An organization consisting of: A well-established and stable functional structure. Several independently functioning units with their own resources.	Use your company's organizational chart as a template for designing this hierarchy.
Geographic	Hosts that are: Organized and managed by site or geographic area. Grouped in a specific geographic area together with other hosts that usually communicate with each other.	Use a map as an aid in naming servers. Place secondary servers in the same geographic location.

6.1.1 Finding Existing BIND Service Information

When planning your domain hierarchy, it may be useful to look at information for existing domains and name servers. The UCX product supports the nslookup utility, which allows you to retrieve the following information:

• Host names and addresses on the local domain
• Host names and addresses on remote domains
• Host names that have the mail exchanger (MX records)
• Name servers for a specific zone

You can also define a command and issue requests from the DCL prompt. The UCX nslookup utility recognizes only lowercase commands. UCX interprets uppercase commands as a request to look for a host name. To specify a different name server other than the default, specify the name server when you invoke the nslookup utility.

Note

Without specific instructions to do otherwise, nslookup and the UCX SHOW HOST command use the same name server.

Consider the following domain hierarchy guidelines:

• Limit creation of domains to three or four levels.
  In very large networks, people at individual sites create and own lower-level domains used mainly by a specific group of local users. In such cases, users create as many levels of domains as they deem necessary and convenient to manage.
• You can divide your domain hierarchy into several zones. DIGITAL recommends that you divide your domain hierarchy into multiple zones if your network is large and growing. Multiple zones offer the following management advantages over a single zone structure:
  • Creates a greater opportunity to distribute information in the network, decreasing the processing load on any one system.
  • Decreases the probability of duplicate names (for example,
    aero.sales.dec.com and aero.dev.dec.com are unique).
  • Eases the delegation of administrative responsibility for domains, subdomains, and zones.
  
  Zones require additional network resources to administer. Also, long domain names are difficult to remember.
• Limit domains and zones to a manageable size.
  Domains and zones have a practical size limit based on manageability. Factors to consider include the following:
  • Identify how widely zone information must be copied.
    A zone containing many domain names may need several secondary servers in different places to locate the names close to users. Propagating updates to secondary servers adds overhead, especially across WAN links. For example, if you have three sites and 100,000 domain names, and all of the sites need those domain names, keep them in one zone. Conversely, if specific domain names are only used at one site, save overhead by locating those domain names in a zone for that site.
  • Anticipate growth.
    Design a domain that allows horizontal expansion (more subdomains directly under the upper-level domain) and avoids vertical expansion (more levels of subdomains). This design helps limit the number of subdomain levels and makes the domain easier to manage, even as it grows.

Table 6-2 lists some criteria to use when deciding if you want to create new zones.

Table 6-2 Joining or Creating a Zone

Consider:	If:
Joining an existing zone	A suitable zone already exists in the domain space.
	You plan to manage a small number of hosts.
	You expect little change or growth in your domain space.
	You expect a low demand for host and address lookups.
	The current domain administrator is willing to accept the extra work.
Creating new zones	You are creating the initial domain hierarchy in your organization.
	You want control over your domain space.
	You plan to manage a large number of hosts that use the BIND name service.
	You expect a lot of change or growth in your domain space.
	You expect a high demand for host and address lookups.

Whether you decide to join an existing zone or create a new one, identify the proper parent zone and get the owner's agreement to your approach.

If you decide to create zones, you need to:

• Decide which hosts you want in a particular zone.
• Select the servers for the zone.

After you decide how to structure your domain hierarchy, establish domain naming conventions. Table 6-3 lists domain naming conventions and their supporting reasons.

Table 6-3 Domain Naming Conventions

Convention:	Supporting Reasons:	Example:
Use domain names that match the BIND hierarchy.	Your naming policy and the BIND hierarchy are likely to evolve at the same time.	If you have existing host names (such as: host1, warrick, and marcom), you may want to give them geographic domain names (such as: albany, warrick, hartford) or functional department names (such as: eng, prodmgt, marcom).
Choose domain names that are not likely to change.	Creates a more stable naming hierarchy because it is difficult to change existing labels, especially at higher domain levels. Also, a change in a domain name affects all applications that use them and users who memorized the name of a resource or created an abbreviation.	If you use a functional model, derive domain names from business functions, not current titles. For example, consider using sales.abc.com, admin.abc.com, and eng.abc.com to store names used by the sales, administrative, and engineering branches of the ABC organization.
Use a multi-level domain naming strategy to manage large domains.	Creates a complex, but more manageable domain than a large, single-level domain.	If you have a large domain, you could name upper-level domains after cities such as, nyc.abc.com, paris.abc.com, and geneva.abc.com, and lower-level domains based on site codes or some other more specific geographic name.
Select domain names that are short and describe the resource represented.	These names are easier to remember.	For example, you could use ftp.aero.dev.abc.com as the domain name of the FTP access point used by the ABC's aerospace development division.

6.2.1 Case Sensitivity

The BIND service preserves the case of names as they are entered. Lookups, however, are case insensitive, so it is not possible to create two names that differ only in their case. For example, requests to look up mynode.lkg.dec.com, MYNODE, and MyNode would all produce the same result. If someone attempted to create entries in the zone database files for all three domain names, you would have multiple records for the same names.

6.2.2 Planning Domain Names for Reverse Lookups

The IN-ADDR.ARPA domain names include up to four domain labels in addition to the IN-ADDR.ARPA suffix. Each label represents one octet of an Internet address, in reverse order. For example, if your host has Internet address 37.20.16.08, its domain name for reverse translation would be: 08.16.20.37.IN-ADDR.ARPA.

Use the following guidelines:

• Make sure that each address has a record in the zone file that provides the canonical name of the host (this is the PTR record). Some applications do not function properly unless they can find a host name.
• When you receive a block of addresses to use, ask the organization that supplied them to you about any required actions you need to take regarding reverse translation domain servers.
• If you use a small number of addresses and part of a set of addresses that are owned by a service provider, the service provider typically ensures that reverse translations will be handled properly.
• If you receive a block of addresses from the InterNIC, you are responsible for ensuring reverse translations servers exist.

Deciding which domain names and hosts belong in a zone is a simple task if you planned your domain hierarchy carefully. Your zone will contain domain names, hosts, and servers. The master zone file, maintained on primary servers, contains all the information for the zone.

If you decide to create zones, consider an overall administration scheme. Your plan for who will use and manage names can have a strong influence on zone structure. For example, the upper-level domains should be stable, widely known, and limited in content. Only a few trusted people should be able to create or modify their contents.

Typically, an individual acts as the technical and zone contact for zones. This person is concerned with the technical aspects of maintaining the BIND server and resolver software and the data files. The technical and zone contact keeps the BIND server running and interacts with technical people in other domains and zones to solve problems affecting the local domain.

6.4 Selecting Servers

Your main goals in choosing hosts for servers should be to achieve availability of data, reliability, and optimum performance. If you create your own zones, you must configure at least one primary and one secondary server for each zone.