Chapter 4 - VINES Base Services
Banyan provides a diverse set of VINES applications that run on servers and workstations. These programs operate together to provide an ordered procedure to accomplish user or manager tasks in a multivendor business computing environment.
VINES applications let multiple independent workstation users share critical system resources, such as printers, disk storage, and communications facilities. Users accomplish tasks on the network in much the same way as business users interact within their own organization or department.
Banyan provides an integrated VINES applications development environment. The VINES Applications Toolkit includes tools that let a developer create both services and clients to run in the VINES environment and interact with VINES services.
VINES Client/Service Computing
VINES networks are based on communication between clients and network services. In a VINES network, users who log in to the network can access services provided anywhere on that network.
VINES services include:
Base services, such as the StreetTalk global naming service and the VINES Security Service, are part of the software required to run VINES. This chapter describes the various types of base services provided by Banyan. Optional services, such as Intelligent Messaging and any VINES compatible service you might build, extend network capabilities. VINES optional services are described in Chapter 5.
Services communicate with one other and with VINES software on workstations. For example, the StreetTalk service identifies every element in the network by a unique name and provides this information to other services. The Server Service is a supervisory process that manages all the services on a server. Figure 4-1 illustrates the relationship between system and workstation software.
Each VINES service consists of the following software components:
|
|
Application clients generate requests for services or data. Generally clients are executable programs that run on DOS, OS/2, Windows, or Macintosh workstations. VINES provides a communication environment for these clients. |
|
|
Application services are UNIX processes that make services and data available, and respond to requests from application clients. Services can also functions as clients. |
Figure 4-2 illustrates how information passes back and forth between clients and services in the following order:
1. Information collected and interpreted by the client software is passed back to the application on the server in a data packet. The packet contains both data entered by the user and information specific to the service being used.
2. The server-based application interprets and manages the information in the packet.
3. The server sends the packet back to the client.
4. The client re-interprets the information and presents it to the user.
Macintosh Client/Server Interaction
Macintosh clients and servers use an intermediary service called the AppleTalk Agent (ATA) to let Macintosh clients communicate with VINES services that use the VINES IP protocol. The ATA transfers service socket requests from Macintosh clients to VINES services. Because ATA handles requests asynchronously, it can handle multiple Macintosh sessions simultaneously. This service also lets Macintosh workstations access the VINES Applications Toolkit.
The ATA uses the AppleTalk Session Protocol (ASP) to communicate with Macintosh workstations. ASP controls the client transfer of data to servers. ATA registers with both StreetTalk (ATA@server-name@Servers) and the AppleTalk NBP (as VinesSocketeer:<server>@<zone>). ATA then waits for a Macintosh client to initiate an ASP session.
Example ATA Process Flow
An application on your Macintosh desktop resides on a VINES server and uses VINES IP. When you start a session with the application, the following events occur:
1. When you open the application, client software on the Macintosh uses ASP to issue a request to open a communications socket.
2. ASP sends an open socket request to the ATA service.
3. ATA calls VnsOpenSocket.
4. ATA receives a response to VnsOpenSocket.
5. ATA transfers the response back to ASP.
6. ASP sends the response back to the client on the Macintosh.
Figure 4-3 illustrates this process.
Every VINES server-based application is managed by a supervisory process, called the Server Service. This utility service runs under UNIX and manages all of the services on a given server. The Server Service's user interface is a workstation client that lets a network administrator perform the following functions:
|
|
Add and delete services and other network resources. |
|
|
Assign or move server resources. |
|
|
Start and stop services. |
|
|
View service status. |
|
|
Control the level of information logged by the service. |
|
|
Generate service activity reports. |
This type of central management of services is possible because all VINES services, like users, have unique StreetTalk names.
You control the base functions of some services with service-specific VINES management routines. These routines configure a service by setting parameters in the service or client process to meet your needs. The parameters control the physical resources that the service uses, determine which users can access the service, and so on. VINES terminal emulation, file, and print services are services that use this feature.
You develop VINES services and clients using commands or functions that operate at specific levels of interprocess communication. For example, you can create an application using functions at one of the following development environments:
VINES sockets (using VINES and other supported non-VINES protocols) Transport Layer Interface (TLI) Remote Procedures (RPC)
VINES services and other applications use both the service/client and socket/connection models for interprocess communication, depending on the task at hand. For example, routines that change the configuration of a VINES service use service/client RPCs, but file transfers during terminal emulation use virtual connections.
See documentation for the VINES Applications Toolkit for more information on developing and integrating third-party services into VINES networks.
The sections that follow present information about each VINES base service. Each description includes the information described in Table 4-1.
Description VINES Backup and Recovery Service provides UNIX file-level backup and restoration for user data areas on the server.
Client Support This service is accessible only from the server console.
Features Server operators can select:
Automatic scheduled backup Automatic incremental backup Single-service backup for selected service types
Operators can restore:
The entire system Individual services of selected types Individual files and directories within file services
Backup/restore also supports relocation of StreetTalk data for groups and services.
Note: The Backup and Recovery Service is for the data areas of all services integrated with VINES. This does not include the UNIX executables of these services.
Views Network administrators access the Backup/Restore utility from the server console's Operator Menu.
APIs Integrating third-party applications as VINES services automatically integrates the application's data space into the Backup/Restore procedures on a VINES server. Administrators can selectively back up third-party applications at any time, or as part of scheduled backups. To provide this feature, application programmers must structure service data areas to conform to standard VINES directory structures.
See the Banyan Server Operations Guide.
Description VINES file services support the sharing of files by users on supported workstation types, while letting users maintain the familiarity of their native file system. File services provide transparent extensions to a workstation's file environment.
Client Support DOS, OS/2, Windows, and Macintosh workstations.
The ENS for UNIX product line supports the sharing of files between VINES users (on DOS, Windows, and OS/2 workstations) and UNIX users using the UNIX Connectivity File Service (UCFS). See the ENS for UNIX Administrator's Guide for more information on UCFS.
Features VINES 5.x file services are managed by the VINES File System (VFS). VFS supports:
32-bit i-nodes Macintosh file sharing OS/2 Extended Attributes
VFS maintains the components of a file service and all associated information, including:
Names of directories and files Directory and file attributes and access rights lists Date and time file services were created, last accessed, and last modified
Software resident in DOS, Windows, and OS/2 workstations redirect file service calls to the appropriate local or server-based storage. The standard SMB protocol communicates between redirector software and the file service.
Server disk storage is organized into file services with private or shared directory structures controlled by access rights lists (ARLs). Administrators add and name file services using specific server disks as needed. You can install and run a maximum of 15 file services per server.
Macintosh workstations use standard AppleShare client software for file sharing. VFS maintains the resource forks for Macintosh files stored in VINES file services.
File Views DOS, OS/2 FAT, and Macintosh file systems constitute different views. A view is the perspective from which access rights, attributes, and names of directories and files are displayed, edited, and saved. For example, on a DOS workstation you can edit and save access rights from the Macintosh view in the VINES SETARL program. The Macintosh Get Privileges or Sharing commands displays the same access rights on the Macintosh workstation.
Names VFS creates and maintains names for each component of a file service. VFS names are based on the naming rules of the file system in which the component is created and the file system in which the component is shared. VFS uses the following guidelines:
If the component is created at a Macintosh, VFS follows AppleShare naming rules. To generate names in the other spaces, VFS follows XOPEN rules. If the component is created from any other file system, VFS follows XOPEN naming rules established by Microsoft Corporation to coordinate DOS FAT and OS/2 High Performance File System (HPFS) names.
Security To integrate different file systems, VFS preserves native access rights and attributes, and presents both the native file system view and a composite VINES view. VFS lets you choose the view you use to set access rights and attributes, and see how settings in one view affect settings in another view.
In case of conflict, VFS enforces the most secure settings.
The Macintosh file system has its own native access rights commands for AppleShare file sharing:
Get Privileges (System 6.x) Sharing (System 7.x)
Macintosh lets you assign attributes to files (for example, the Locked attribute) and create a special case for a folder, known as a drop box.
The DOS and OS/2 FAT file system has file attributes but lacks an access rights list (ARL). VFS provides a VINES Access Rights List (ARL) for DOS, OS/2, and Macintosh. The VINES SETARL command lets you manage these ARLs. In addition, you can set access rights for both directories and files.
A VINES ARL contains a set of mandatory entries, called the Primary List. The Primary List consists of:
Owner, the name of the person who created the file service Group, including everyone in the Owner's StreetTalk group World, by default defined as *@*@*
Every directory and file in a VINES file service has a VINES ARL with at least an Owner, a Group, and World. While these mandatory entries support Macintosh, they also ensure that VINES adheres to the POSIX specification.
A VINES ARL also contains a set of five optional entries, called the Extended List. This list has a maximum rights mask, called Maximum Rights, which is a set of access rights that overrides any settings for individual entries in the Extended List. If you upgrade from a VINES 4.x release, your original VINES ARLs are in the Extended List.
Synchronization Synchronization ensures that file system components receive maximum protection and that modes, locking attributes, and renaming affect components consistently. VFS supports the following synchronization guidelines:
Access rights are based on the file system view from which the rights were last saved. DOS and Macintosh open or sharing modes. DOS and Macintosh byte-range locking. VFS treats the files as locked for all views. DOS and Macintosh file attributes. OS/2 extended attributes are supported through the use of the VINES VCOPY command. File and directory name changes.
Processes A unique UNIX process exists for each file service. These file services communicate with VFS in the server. Under DOS, client programs manage file access and let users set workstation drives to VINES file services. On the workstation, native operating system requests to the file service are intercepted and redirected to the file service.
A single UNIX process for AFP exists in each server to provide access to all file services by Macintosh clients.
Figure 4-4 shows the interaction between these processes.
Hardware The administrator must allocate sufficient disk space on the server to store files. File service size increases dynamically as users create more files to fill available disk space. Currently there are no disk limiting capabilities.
Currently, file services do not span multiple disks. If services support the hardware capabilities of presenting multiple disks as one logical disk, a file service may span multiple physical disks that appear to UNIX as one logical disk.
Views Administrators control access to file services and directories by specifying:
User names Lists Patterns paired with a level of access
Administrators can set up default mappings in the VINES user profile to associate workstation drive letters with file services, both for groups and for individual users.
Workstation drive designators, such as F:, are associated with file services by the administrator or by the user if the administrator allows it. The association between a file service and a workstation drive designator is called a drive setting. VINES file services appear to be fixed disks under the native operating system with identical directory structures and commands. All user capabilities are subject to administrator-controlled access rights.
Macintosh users access file services by selecting the name of the file service in the Macintosh Chooser menu instead of selecting a drive designator. File services are mounted on the user's desktop and adhere to standard Macintosh conventions.
APIs Files are accessible to applications through standard DOS calls, subject to the drive settings and access rights of the user running the application. The native VINES development environment includes a file service known as the bridge file service, that provides access to the development area from both UNIX and DOS environments. Developers can provide a bridge file service to their customers if needed.
On the VINES server, files in file services are accessible through standard UNIX system calls. On native VINES servers, the Banyan File Service (BFS) and VFS APIs interact with services on the same server. On Open VINES servers these APIs interact with any BFS service in the network.
See Managing VINES Services and the VINES Service Developer's Guide.
Description VINES Netbios Emulation Service is a full-featured IBM-compatible Netbios (Network Basic Input/Output System) service. The service is fully compatible with the IBM PC LAN Program. The service lets applications that require Netbios function on a VINES network.
Client Support DOS, OS/2, and Windows workstations.
Features The Netbios naming domain is extended to any user who chooses a particular service and is not limited to any LAN segment or type of LAN. The VINES network can include one or more naming domains.
Processes A Netbios service runs on the server. The service provides:
Name management within its domain of associated users Name lookup to establish sessions between workstations Datagram service for broadcasts and workstation-to-workstation sessions Name lookup to bind workstation-to-workstation sessions and maintain a record of all local workstation name tables within its domain
The client application resides on the workstation and interacts with the service. The client controls the local name table and configures the number of Netbios sessions and outstanding commands allowed at the workstation.
Views Standard management clients on the workstation let administrators add, delete, start, and stop services by name. Administrators can set up parameters such as machine name, number of sessions, and number of outstanding commands in the user profile, while associating a service with a group or with individual users. All users sharing a Netbios application must use the same service to ensure proper coordination.
The resident client must be loaded from DOS or by the network software configuration of the local workstation. The client must be paired with a specific service through the user profile or the DOS command line.
APIs On the workstation side, access to Netbios functions uses standard DOS calls, including interrupt 2A (software) and interrupt 5C (hardware). The client's emulation software lets the developer code or port a Netbios service and client so that they can run under DOS in the VINES environment.
Description VINES print services support access to printers attached to servers, workstations, or an AppleTalk node on a network for PAP-compatible PostScript printers.
Client Support DOS, OS/2, Windows, and Macintosh workstations.
Features The VINES redirector, which resides in DOS, OS/2, and Windows workstations, redirects print calls from a workstation port (LPT1, LPT2, LPT3) to the appropriate local or network printers. Each print service supports:
Access control Forms control Spooling control Settings that pair one or more printer identifiers (LPTn and PRN) with the service
Macintosh workstations use Macintosh software and the PAP protocol to redirect a print requests to the VINES print service.
Administrators add and name print services and assign queues to specific server disks as needed. Each server can support up to 20 concurrently running print services.
User output, called print jobs, is spooled to a server-resident print queue that can be managed by both users and administrators. From the print queue the job is sent to a serial or parallel printer or to another destination.
Destinations From the print queue jobs may be sent to any of the following destinations:
Printers attached to parallel or serial ports on a VINES server PAP-compatible printers connected to a VINES server by a LocalTalk® board or to a VINES network by a transition bridge Printers attached to the parallel or serial ports of a workstation running the VINES PCPRINT program Other print services
Print Queues A print service stores print jobs in a queue until they can be sent to a printer. The queue can receive jobs from more than one print service and a print service can send jobs to more than one queue. Print queues let you perform the following tasks:
Stop a queue without stopping the print service. Set the maximum number of jobs. Set the maximum size of print jobs. Redirect print jobs in one queue to other queues on the network.
Processes Two UNIX processes exist on the server to manage all the print services and print queues on that server. On DOS and OS/2 workstations and on the server console, client programs support service management and user settings that pair DOS printer ports and VINES print services.
Hardware Administrators must allocate sufficient disk space on the server to store jobs in the print queue. Administrators must also install a parallel or serial printer and cable or a LAN attachment on an appropriate workstation or server port.
Views Using a print service management client, administrators control access to printers by specifying StreetTalk names, lists or patterns. Administrators can control printer configuration, including set-up strings, and manage print queues.
Print services use specific ports on servers or DOS workstations. Administrators can set up default mappings in the user profile to associate the workstation printer ports (LPTn or PRN) with print services for groups or for single users.
Network printers appear to be DOS printers. Workstation printer ports (such as LPT1) are associated with print queues (services) by the administrator or by the user if the administrator allows it.
All user capabilities are subject to the access rights of the print service they use. Based on the workstation port associated with a service, users can:
Control job form type Manage their own print jobs Set the delay before job spooling
APIs Network printers are accessible to applications through standard DOS calls, subject to the settings and access rights of the logged-in user who runs the application. The VINES Programmer's Interface (DOS) includes calls to determine the active printer port at a workstation and to programmatically spool a job to the associated VINES print service. On the UNIX side, a special VINES system call lets processes spool jobs to network printers.
See Managing VINES Services, Planning a Banyan Network, VINES Print Service Programming Interface, and VINES Programmer's Interface (DOS).
Description The Remote Program Load (RPL) option lets you connect diskless workstations to a VINES network.
Client Support DOS version 3.0 or greater and Windows version 3.0 or greater.
Features Diskless workstations have neither fixed nor floppy disk drives. These workstations improve network security because users cannot add software to the network or copy software from it. However, the absence of a fixed or floppy drive means that these workstations must get their network software from the network.
The VINES workstation directory, which usually resides on the local A or C drive of the workstation, is stored instead on a server. The VINES RPL service is responsible for downloading a boot image to each diskless workstation.
You install an IBM RPL module in each diskless workstation. The module broadcasts a boot request over the network and the VINES RPL service responds by downloading a boot image.
The following restrictions apply to the RPL service:
The RPL service can only be configured from a DOS workstation. Only one RPL service can run on a server at a given time. The boot image is a maximum of 360 KB for VINES, DOS, and any device drivers. This may limit the number of device drivers that can be configured in CONFIG.SYS. Servers running RPL service for diskless PCs require large communications buffers.
Processes The RPL option supports the IBM Remote Program Load protocol on VINES servers and diskless workstations connected to Ethernet or Token-Ring networks. The protocol lets VINES servers download DOS and VINES client software to diskless workstations so that they can log in to a VINES network. Diskless workstations can then function as full VINES clients.
The VINES RPL option is implemented as a VINES service. Only one RPL service can run on a server. In addition to the RPL service, you also need a file service.
Broadcasting Boot Requests When a diskless workstation is turned on or reset, it looks for a diskette drive or fixed disk. When one is not found, the workstation hands off control to the RPL module on its Token-Ring or Ethernet LAN card. The module broadcasts an RPL boot request over the network at the data-link level.
A workstation with an Ethernet card broadcasts a boot request over the local LAN and over any remote LANs connected by a bridge or a repeater.
A workstation on a Token-Ring LAN operates differently. Its first three boot requests are confined to the local ring. If a server on the local ring does not respond to any of these requests, the workstation issues an all-ring broadcast to find an RPL service. If the remote server is accessible over a local Token-Ring bridge, all subsequent requests travel to both the local and remote rings.
Server Response to Boot Requests Drivers on VINES servers that run the RPL service were modified to respond to RPL broadcasts. When an RPL service receives a boot request, it downloads boot files to the workstation if the service is configured with a:
Workstation's unique adapter address Default workstation address
If the service is configured with a default address and an exceptions list that includes the requesting workstation, it will not respond.
When more than one eligible server responds to the workstation request, the workstation selects a server and begins exchanging frames with it.
Downloading Image Files When the workstation selects a server, the server creates an image to be sent to the workstation. The image is a file that contains the DOS and VINES software needed to boot the workstation. The server either creates a unique image for each workstation or retrieves one already created. More than one workstation can request and receive the same image.
The server uses the RPL protocol to send the image to the workstation. The image boots the workstation and creates a RAM disk, a simulated drive A, in the workstation's memory.
The server downloads the image in this manner:
1. The RAM disk is temporarily mapped to the workstation's drive A.
2. The workstation automatically does a second "soft" reboot to load DOS and VINES files from its RAM disk.
3. As the workstation boots DOS and VINES, the RPL service maps the workstation's drive A to a file service that the administrator configured for the RPL service.
4. The workstation obtains a copy of the LOGIN command from the file service and executes it so that the user can log in.
5. The server temporarily writes the image file to its own fixed disk.
6. After a set interval, if no additional boot request is received, the server deletes the image that it created for the workstation.
Restricting Boots On Token-Ring and Ethernet LANs, you can prevent a remote server from booting a workstation by:
Configuring RPL services on the local and remote LANs to boot only workstations connected to their respective LANs. Adding the addresses of the workstations on the local LAN to the exceptions list of the remote service if the remote service is configured with a default address. An exceptions list contains the addresses of workstations that do not receive a DOS image from this service. Turning off the bridge if all local and remote RPL services were configured to broadcast images to any requesting workstations.
If all servers are configured to boot all workstations, installing the RPL service on at least one server on each LAN reduces the possibility that a remote server will be used to boot a workstation on a local LAN.
Hardware The RPL service supports the following hardware for DOS-based workstations:
IBM PS/2 model 55LS family of diskless workstations IBM 4/16 ISA-based Token-Ring card IBM 4/16 MCA-based Token-Ring card IBM MCA-based Ethernet card
A diskless workstation must have a minimum of 640 KB of memory to run the VINES RPL software. Additional memory may be required to run other applications such as Microsoft Windows.
The workstation LAN card must have an RPL module installed on its Ethernet or Token-Ring card. These modules are available from IBM.
Views Administrators perform the following tasks:
1. Run MSERVICE to create a file service on the server that will boot the diskless workstations.
2. Create a DOS boot diskette that contains the COMMAND.COM file and the two DOS system files.
3. Run MSERVICE to create and start the RPL service.
4. After the service is started, use the RPL configuration menus to configure each workstation for VINES. You can configure groups of workstations that share the same boot device or configure individual workstations that have their own unique boot device.
5. After you can log in to VINES from a diskless workstation, perform the following tasks:
a. Run the IBM Reference Diskette manually from the logged-in diskless workstation.
b. Manually copy any required device drivers, such as HIMEM.SYS, to the file service that serves as drive A.
c. Add the drivers to the workstation's CONFIG.SYS file.
A subset of DOS and VINES commands are available to users prior to logging in to VINES. After logging in, a user has full access to all files in all the directories on the boot device.
APIs None.
Description The Semaphore Service supports multi-user applications that define semaphore interfaces, usually only found in applications written under versions of PC- or MS-DOS® prior to 3.10. The VINES semaphore functions are compatible with many Novell® and 3Com semaphore calls.
Client Support DOS workstations.
Features Semaphore services provide a control mechanism for file sharing under earlier versions of DOS, as required by specific applications.
Processes Semaphore services run on the VINES server. On the workstation, a resident client provides a semaphore interface to executing applications.
Views Administrators can set up the type of compatibility (Novell or 3Com) and associate a service with a group or with individual users through the user profile. Users sharing an application should use the same service to ensure proper coordination.
The resident client software must be loaded from DOS or by the network software configuration of the local workstation (using the VINES PCCONFIG program). The client type must match the compatibility type specified through the user profile or the DOS command line. Thereafter, applications that use semaphores execute as they would in the environment of compatibility.
APIs The VINES Programmer's Interface (DOS) includes a list of supported functions in the DOS environment.
See Managing VINES Services and VINES Programmer's Interface (DOS).
Description The VINES Server Service manages both Banyan and non-Banyan services, and includes a synchronized network-wide time and date service.
Client Support None.
Features The Server Service performs the following functions:
Provides orderly shutdown of the server in the case of a power failure Automatically restarts services that terminate abnormally Initializes the service environment Handles starting, stopping, creating, and deleting services under administrator control Initializes scheduled events such as backups or temporary links Coordinates worldwide network time among servers Initializes workstations with the network time and date at login
The Server Service allows for remote management of services from any workstation on the network using the Server Service clients: OPERATE, and MSERVICE.
Processes After the service is installed, the VINES utilities, MSERVICE and OPERATE requests that Server Service create, start, configure, and stop the service.
Table 4-2 describes the actions you take to load, run, and maintain a service. Except for the first and last items in the table, all of the actions are controlled by the VINES Server Service.
The VINES Server Service uses four files to store information about VINES and third-party services:
pgms3.db (for Banyan-provided services) and pgms.db (for third-party services) identify the types of third-party services that can exist on the server. No matter how many services of this type exist or are added to a server, exactly one entry should be in this file. Add entries by hand or by using a script. You must add a service to StreetTalk and start it before it can be used.
The type entry includes a string identifier, the name of the service's home directory, and other pertinent data. The file is read by the Server Service each time the server initializes (whenever all services were shut down and are restarting).svc3.db (for Banyan-provided services) and svc.db (for third-party services) is a database of services registered with the VINES Server Service. In these files one entry appears for each third-party service on this server. Read this file to obtain the password assigned to each instance of your service. Describe your services type in pgms.db and add your service to StreetTalk to include your service in this file. Caution: Do not edit the svc3.db file. It is created and maintained by the Server Service.
Server Service works with MSERVICE and OPERATE as follows:
1. A user selects the service's StreetTalk name in MSERVICE or OPERATE.
2. Server Service checks svc.db or svc3.db file for the specified StreetTalk name and extracts the service type.
3. Server Service checks pgms.db or pgms3.bd to find the home directory for the service by matching the service type from the svc.db with the types in pgms.db.
4. Server Service executes one of the following files, depending on the action selected in MSERVICE or OPERATE:
- Create
- Startup
- Destroy
The file selected by Server Service executes to complete the action requested by the user. See the VINES Service Developer's Guide for more information on service control scripts.
APIs All VINES applications that run under UNIX on the server register with the Server Service. This is done automatically by including the SvcCalls.mm header in the NetRPC specification file of third-party services. Once registered, services are notified about important events such as configuration changes or imminent server shutdown. Administrators access registered services through standard VINES service management routines.
See VINES Service Developer's Guide.
Description StreetTalk is the VINES distributed naming service from Banyan that maintains the names and attributes of all network resources. Naming is global across the internetwork and is independent of network topology. StreetTalk lets other network services, such as the VINES Security Service, enforce user access control.
Client Support DOS, OS/2, Windows, and Macintosh workstations.
Features All objects in the network are identified by a 3-part name, using this format:
item@group@organization
An item is the first part of a StreetTalk name. Items include users, services, and lists. Each item has a unique name and belongs to a group. Items are maintained in Latin-1 format.
A group is the second part of a StreetTalk name. Groups logically associate items that have something in common, such as the users in a department, and control how naming information is distributed on the network. Each group logically belongs to an organization. Groups are maintained in ASCII-7 format.
An organization is the third part of a StreetTalk name. Organizations are logical identifiers that associate groups. Organizations are maintained in ASCII-7 format.
Groups and Servers StreetTalk item names are associated with specific groups. Administrators add a StreetTalk group to a specific server. Each server maintains the following information about StreetTalk groups:
Group-level information includes the names of all groups on the network and whether a particular group is maintained on this server. For each group not maintained on this server, there is a record of the server responsible for that group and the internet address of that server. Item-level information details attributes and other characteristics of every user and resource in each group maintained on this server.
Each server shares group-level information with its neighbors. This group level information is added to each servers' StreetTalk database. As each neighbor passes its database on, the location of every group in the network eventually becomes known to all StreetTalk servers.
Servers share only group-level information, not item-level information, in the exchange. Thus, as illustrated in Figure 4-5, StreetTalk information is fully distributed and VINES does not have to rely on a centralized naming server.
In StreetTalk, all names are global to the entire network and cannot be duplicated. When one server is down, only the resources in the groups it maintains are affected.
Each StreetTalk Service can locate other StreetTalk services using the NetRPC search message as follows:
1. Every StreetTalk Service attaches to the well-known local communications port, 0x000f.
2. The service broadcasts the search message using the IPCPORT address.
3. Each StreetTalk entity shares the names of the groups that it maintains by broadcasting this information at regular intervals or when one of the following events occurs:
- A group name is created within the service database.
- A group name is deleted from the service database.
- A new server node enters the network.
- The entity receives information from a previously unknown StreetTalk entity.
If a StreetTalk Service fails to receive information concerning a particular group for more than 96 hours, the service assumes that the group no longer exists on the network and deletes all group information.
When a StreetTalk Service receives a request from a client, the service determines whether the group specified in the request is maintained in its own database or in the database of another StreetTalk Service. In the latter case, the service that initially received the request routes it to the appropriate service for processing. A StreetTalk Service uses RPC runtimes to communicate with clients and other StreetTalk services. The client and service must agree on various parameters, such as the byte size of a StreetTalk name and categories of objects in the StreetTalk database.
Unique Groups All servers must be given a unique name when added to the network and are referenced through the group server-name@Servers. The system creates the organization Servers. The group server-name is automatically created when an administrator installs and names the server. Administrators explicitly create other groups and add them to specific servers on the network.
Within each group, the system creates a reserved StreetTalk name, AdminList@Group@Organization. This name specifies users who are administrators, or managers, of both the group and the objects it contains. Members of that list can modify it as desired. A corresponding AdminList in each server-name@Servers group describes administrators of that server.
Access Rights System managers or administrators can grant access rights to users, groups, or organizations to manage the use of shared system resources. To do so, administrators set up access rights lists (ARLs) for all or part of a system resource, such as a file service or a connection to a host computer.
Item Information For each item, StreetTalk maintains the following information:
The item's class:
- User
- Nickname
- Service
- List
- GroupThe category of the item within its class. For example, the service class has categories such as file service, print service, and so on. Associated records that contain information about the item. These records are numbered from 0 to 999. Attributes that contain information about the item. An item may have 264 attributes.
Associated Records Prior to VINES 5.5, associated records were the primary means by which information could be associated with StreetTalk items.
Note: Associated records are being replaced by attributes. Banyan will continue to support associated records as a subset of attributes for a limited period of time.
Associated records are a series of 1024-byte fields numbered from 1 through 999. While useful for the storage of basic information, associated records do not support the use of data types, are not associated with specific vendors, and the content of each record depends upon the operating system of the clients involved.
Attributes Attributes are user-defined data associated with StreetTalk names. Attributes can be shared and referenced easily in a consistent fashion. You can configure STDA services to collect and index attribute information making searches on any attribute possible.
You can associate attributes with each type of StreetTalk object: users, groups, lists, services, and nicknames. Attributes are entirely user defined. You might specify attributes that associate user's StreetTalk names with their phone numbers, job descriptions, or office locations. You could define attributes for services that represent their location, configuration parameters, and administrators.
An attribute is identified by a two number pair in the following format:
<Vendor_Number:Attribute_Number>
The vendor number represents an individual vendor or enterprise. By assigning unique vendor numbers, each vendor can reference its own set of attributes. Vendor numbers are numbered from 0 through 2 32- 1. The attribute number represents an individual attribute within a vendor number range. Individual attributes are numbered from 0 through 2 32- 1.
Attributes have the following advantages over associated records:
Each object may have 2 64 attributes. Attribute value length is limited only by the size of the storage media. Each set of 2 32 attributes can be associated with a specific vendor or site. The view of attributes remains constant, regardless from which environment they are viewed. For instance, no special translation is required on the developer's part for DOS and Macintosh to view the attributes.
VINES clients can access attributes using any of the following programs:
MAVD creates or modifies an Attribute View Definition (AVD) file to define language and site-specific attribute labels. MATTR creates, replaces, examines, and deletes attributes in StreetTalk. XSTD looks up attributes and performs attribute-based searches in STDA. In VINES 5.5, this is the same interface as F2 in the Intelligent Messaging client interface.
Refer to Managing Users and StreetTalk for more information on these commands.
AVD You define the attributes and labels using the VINES Attribute View Definition (AVD) system. AVD provides the link between your attributes and VINES system software. The AVD system has two components:
A set of tools that you use to define the attributes and labels specific to your environment A set of APIs that software developers use to discover the local attribute definitions and to present them in a consistent manner using the application's user interface
Attribute Labels Although each attribute can represent any kind of information, an individual <v:a> identifier does not have a label that is easy to remember. Banyan provides a default AVD file, called vines.avd, that defines attribute labels commonly used in the VINES environment.
Figure 4-6 shows a portion of a decompiled AVD file where three of the <vendor:attribute> identifiers are assigned labels.
Attribute Collections A collection is a group of attributes that share some common characteristic. For example, the collection label Phone Numbers may contain the attributes for a FAX number, home number, and office number. Each collection consists of a label, filter references, and one or more attribute definitions.
In Figure 4-7, the collection "Group Information" holds pertinent data about StreetTalk group class objects for access by users and administrators.
Filters You control which types of attributes are matched with which kinds of objects by associating collections of attributes with filters. The filter references indicate to VINES clients and attribute management programs that the collection contains <vendor:attribute> pairs and labels for the class of STDA or StreetTalk object being viewed.
In Figure 4-7, the filter reference "StreetTalk Group" indicates that the collection appears when a user or administrator operates on a "Group" class object.
Processes The ST@server-name@Servers service on each server maintains the StreetTalk database. Clients on each workstation provide interfaces for the administrator and user.
Views The administrator adds, displays, manages, or deletes network objects by name, using management client routines that run on the workstation. The administrator can also create associations between objects, usually users and services.
When adding a group to the network, the administrator chooses a server to manage all items in the group. Other servers in the network automatically refer all requests for items in that group to that server, which maintains detailed information. The administrator restricts access to items by using names, lists, or patterns to describe the appropriate users.
Adding an organization is implicit when you add a new group in a new organization. Likewise when you delete the last group in an organization, the organization is deleted.
The end user's access to StreetTalk can be tailored by the administrator. Generally, users view the names of other users and services through a workstation directory client. Users can select all types of services by name, subject to administrator-controlled access rights.
APIs Tools that interface with StreetTalk include C library calls under UNIX and C library and assembler calls under DOS. All third-party services must be named within a group and organization, and associated with a specific service category in coordination with Banyan.
See For more information on implementing and managing StreetTalk see Managing Users and StreetTalk. For more information on using StreetTalk APIs, see the VINES StreetTalk and STDA Programming Interface.
StreetTalk Directory Assistance (STDA)
Description StreetTalk Directory Assistance (STDA) lets users and administrators quickly and easily look up the names of users, lists, print services, file services, and other services located on their VINES network. The STDA database contains StreetTalk names and descriptions as well as non-StreetTalk names that you can add.
STDA lets users search for item names:
Alphanumerically By the group to which the user, list, or service belongs By attributes you configure in StreetTalk
STDA is fully integrated with the Banyan Intelligent Messaging option, so users can look up the name of a recipient or list of recipients and incorporate the names in a mail message. The SETPRINT program has an STDA interface that lets users look up the names of network print services.
Client Support DOS, OS/2, and Windows workstations. Macintosh workstations can search STDA for StreetTalk names using the Macintosh Mail option. See Chapter 5 for more Macintosh workstation information.
Features Every STDA database has two components. One component collects information from other services and the second component arranges information in the first database for display to users. Information in the database is organized into classes.
STDA Classes StreetTalk uses a three-part name to identify all objects in a network (item@group@organization). Items identify names or services. For each item, StreetTalk maintains, along with other information, the item's class.
STDA uses StreetTalk classes so that the names of users, lists, and services can be efficiently displayed on an STDA screen for a user, or excluded from an STDA service's database. Table 4-3 lists the STDA classes and their definitions.
STDA lets you sort each class by as many strings as you can create from a 31-character StreetTalk item name, or according to other attributes that you configured for the StreetTalk objects in each class.
Example STDA Sorting
If an item name consists of three separate strings, such as Diane Lucie Baillargeon, STDA sorts on any of them, depending on how you configured the service. The default sorting algorithm for users is to sort on the first letter of the last name, then the first letter of the first name, then the first letter of the second name, and so on.
STDA Services There are two types of STDA services: STDA master services and STDA satellite services. These services maintain and distribute the STDA database across the network. A VINES network can have multiple master and satellite services.
Figure 4-8 shows how master STDA services collect information from StreetTalk services and the order, from the top, in which master and satellites can download. Downloading is the process of a satellite retrieving data from a master or satellite service. A server from whose STDA database names are retrieved is called a download server.
STDA master services collect user names, list names, service names, and nicknames in the network from StreetTalk services, and place them into their databases. Master services can collect data from an unlimited number of StreetTalk services.
When an STDA master service is first created and started, it collects the StreetTalk names from designated servers on the network. If a server becomes accessible across a transient link, a master service can collect information from that server, too. Using inclusions and exclusions, you can create server lists that include or exclude servers with StreetTalk services from which you want to collect information.
A master service builds its initial database with the names found in the StreetTalk service databases it is instructed to poll. A satellite collects data from a master service. In Figure 4-8, the satellite services pull data from the master or from other satellite services. You configure the service that retrieves (pulls) the information, not the service that maintains the database that is downloaded.
A satellite service can request data from multiple master and satellite services. By doing so, a satellite service may contain all the names on the network.
Any names that you add to a satellite service (for example, non-StreetTalk names) download to other satellite services. These names will never be in the database of a master service because master services do not retrieve names from satellite services. However, you can add non-StreetTalk names to a master service.
Rebuilding the Database After the initial database is built, every VINES network event, such as a new server coming on line, causes a master service to collect newly available StreetTalk information. The master service incorporates the changes into its database, according to a schedule configured from within the MSERVICE program. This process is known as a scheduled rebuild. When a satellite service rebuilds its database, it requests that another service download its database. It incorporates the new names from the download server into its database.
You can use the MSERVICE program to rebuild the master or a satellite service at any time. This is called an unscheduled rebuild.
Customizing the Database You can use the inclusion, exclusion, and exception parameters to customize the database of a master or satellite service.
Exclusions prevent StreetTalk names from being included in the database of a master service. For example, it is recommended that you restrict user access to AdminLists, sample profiles, and private lists.
Exceptions fine-tune exclusions so that they work on all but a few StreetTalk names in the STDA database. For example, you exclude all AdminLists from the database except those identified as exceptions. Names that qualify as exceptions remain in the database when it is downloaded to satellite services.
Inclusions add non-StreetTalk names, such as those from mail gateways, to the STDA database. Only inclusions added since the last rebuild download to satellite services from a download server. All STDA services can accept, distribute, and display inclusions. Satellite services can filter the inclusion information they collect.
A service's configuration parameters apply to its own database and to the databases of those services that it downloads. If a service does not use a particular parameter, a satellite that it downloads is not affected by it. The configuration parameters of satellite services do not affect the STDA master services.
Views STDA lets users type in a string of characters that can be searched for and located in its database. STDA automatically scrolls through the list of names as users type in the characters, to quickly locate the exact name. After a name is found, it is copied to the entry field in which the users was working when STDA was entered. For example, if mail users compose a message, they can run STDA from within mail, select a name, and put that name in the To: field of the mail message.
The STDIRECT command loads the terminate-and-stay-resident (TSR) program STDIRECT.EXE into a workstation's memory. STDIRECT lets users press a defined hotkey to access the STDA database from anywhere within the VINES environment. For example, you can run STDA from within MSERVICE, which lets you locate the name of an item that you want to manage.
The XSTD command activates the STDA program and attaches to a local STDA service. You can view attribute information associated with StreetTalk objects or search for objects based on their attribute values. When XSTD displays names in the STDA database, they can only be viewed. They cannot be inserted into a command line.
APIs The VINES Applications Toolkit provides a full set of APIs for interfacing to STDA. See the VINES StreetTalk and STDA Programming Interface for more information.
See Managing Users and StreetTalk, Planning a Banyan Network, and VINES StreetTalk and STDA Programming Interface.
VINES Network Management and System Management (VNSM)
Description The VINES Network Management and System Management (VNSM) option is a collection of services that let the network manager monitor and diagnose a network of VINES servers.
Client Support VNSM is installed on the server but can be run from any server console or DOS, Windows, or OS/2 workstation on the network.
Features VNSM provides statistics and configuration information on:
Individual servers Services and protocol families that run on VINES servers LANs WAN data links Network topologies
Currently VNSM cannot be accessed on a Macintosh workstation except through the use of corresponding SNMP service software and Macintosh-based SNMP client software.
Table 4-4 shows the types of network and server information VNSM collects and displays.
Processes VNSM includes a service that runs on the server and a client that runs on both the server and the network workstations. The client can view statistics about any server on the network that has this software installed and running.
VNSM monitors and collects data from a number of different management and tracking services that run on the server, including the following:
Alert Management Service (AMS) Network and System Management Service (SNM) Network Management Service (NMS)
Views VNSM statistics provide valuable data that is interpreted in the context of site-specific conditions and experience. The network manager can then use the data to take corrective actions. These include:
Relocating services Redistributing the disk load on a server Adding hardware Reconfiguring server resources such as communications buffers
All VNSM information is updated in real time, so the network manager observes changes in the network based on user actions. Detailed statistics on hardware interfaces take specific media into account and can help identify or eliminate network hardware as a source of problems.
APIs The VINES Network and Systems Management (VNSM) Programming Interface lets you write a program that monitors the network. This program runs on DOS, OS/2, or Windows workstations, or under UNIX on a VINES server. Using the VNSM functions, you can write a program that performs the following tasks:
Submits requests for descriptive information and detailed statistics to network management services on VINES servers in the network Submits requests for notification of alerts to the Alert Management Service (AMS)
See Monitoring and Optimizing Servers and VINES Network and Systems Management Programming Interface.
Description VINES Security Service enforces network security and authenticates all requests to access, add, or modify information.
Client Support DOS, OS/2, Windows, and Macintosh workstations.
Features Both users and services log in to VINES through a VINES Security Service whenever they enter the network. Users log in through a VINES command at the workstation or server console. Services log in programmatically.
When a user attempts to log in to the network, the Security Service verifies that the StreetTalk name and password are accurate and that the user can log in without violating security. To do so, the service examines the user profile and any security information associated with the user or the user's StreetTalk group. For example, an administrator may specify that a user be restricted to logging in only at certain times or at certain locations on the network.
The Security Service also enforces security after a successful user login. For example, the Security Service interacts with StreetTalk to determine whether a user is allowed to edit his or her own user profile or to access a given file service.
Issuing a Nonce If security conditions let the user log in, the Security Service issues a special object called a nonce. The nonce consists of:
A server serial number A time and date stamp A unique number generated by the Security Service Related information about the login event
The nonce uniquely identifies the current session between VINES and the user, and provides a record of when that user logs in and out the network.
The nonce is bound to the StreetTalk name of the user. The Security Service then uses the nonce to authenticate the user's identity whenever that person attempts to interact with other network objects such as VINES services. The Security Service authenticates all requests made by client programs, whether supplied by Banyan or a third-party developer, that run on the user's workstation.
Security for Services Each VINES service programmatically logs in with the Security Service, which verifies the service's name and password. If StreetTalk and the Server Service validate the name and password, the service receives a nonce and can begin interacting with objects on the network.
As with an individual user, the nonce issued to a service is bound to its StreetTalk name. The Security Service provides both security and authentication for services, using the same pattern applied to users. For example, the Security Service authenticates service requests to interact with StreetTalk or to modify a StreetTalk associated record.
Internet Security The Security Service features server operation routines that provide security and authentication for server-to-server internetwork communication. When remote servers connect to one another, the Security Service enforces passwords at both ends and an administrator-controlled level of information exchange. Within this scheme, servers can exchange all information, no information, or mail messages only. The Security Service also authenticates all requests for information from remote sites through the nonce mechanism, and enforces security for user dial-in to the network from a workstation.
Processes There is one VS@server-name@Servers service on each server. The service provides authentication and security features for all items in all groups maintained on that server.
Views The administrator sets up network security with the workstation user management and server operation client programs. All security features are based on StreetTalk names. Security for users can be provided by:
VINES defaults Group settings Individual user settings
Administrators generate and view reports on user and service activity as monitored by the Security Service.
APIs All third-party services must register with the Security Service. C libraries for both UNIX and DOS let third-party applications authenticate user and service requests.
