Chapter 12 OpenSLP Administration
Internet Express provides the OpenSLP server and Application Program Interfaces based on the SLP Version 2 standard protocol. The Service Location Protocol (SLP) provides client/server applications with the means to discover and select system services on the network. This chapter provides the following information: Internet Express kit provides the OpenSLP server and Application Programming Interfaces (APIs) based on the SLP Version 2 standard protocol (RFC 2608). Using OpenSLP, connection to services is based on a request for a type of service (for example, printing) and a set of service provider attributes (for example, printer configuration). Under the SLP framework, software agents process protocol messages that define service discovery and service connection operations. A User Agent issues a service request on behalf of an application. A call is multicast to Service Agents, one or more of which advertise the requested service and return a URL indicating location of a service provider. Services can include printers, Web servers, file systems, databases, fax machines, and so on. OpenSLP provides an alternative to the static configuration of network services and allows users and applications to dynamically query services available on the network and to select the appropriate service without having to know the network host name. When you install the IAESLP subset, the following files and examples are installed on the operating system.
This section provides information for configuring OpenSLP: Using the OpenSLP Configuration and Registration Files |  |
Internet Express provides default configuration and registration files. The configuration file is /etc/slp.conf and the registration file is /etc/slp.reg. Each file describes its own contents. To change the operation of OpenSLP, you must change the entries in the configuration file. To register services at the startup of the slpd daemon, you must add entries to the registration file. See RFC 2614, an API for Service Location, for a description of the configuration and registration files: Configuring Optional Security |  |
OpenSLP offers an optional SLP Version 2 security feature that you can enable on your Tru64 UNIX system. By default, OpenSLP runs on Tru64 UNIX without security enabled. SLP Version 2 security is implemented differently on Tru64 UNIX than on standard OpenSLP: The Tru64 UNIX implementation uses CDSA for security libraries. Tru64 UNIX generates public and private key pairs using the keytool utility. Tru64 UNIX uses the Security Parameter Index file, /etc/slp.spi.
Follow these steps to enable security on your Tru64 UNIX system: Install the CDSA security subset on your system. See the following Web site for information on downloading the CDSA security subset: Enable security in OpenSLP by placing the following entry in the /etc/slp.conf configuration file: net.slp.securityEnabled = true |
In the root account, run the keytool utility to generate pairs of public and private keys. To do this, you must have an account on the system for user daemon. The keytool utility places one file for the private key and a corresponding file for the public key in the current working directory. You can move the files to any appropriate location on the system. The names of the files take the form priv_<unique_number> and pub_<unique_number>. Corresponding pairs of private and public files have the same unique number. The private key file will ultimately be owned by daemon with read-only-by-owner privileges. The public key file will be owned by root and will be readable by owner, group, and other users. Configure a Security Parameter Index file, /etc/slp.spi, that will associate each key pair with an SLP Security Parameter Index (SPI). Use the following format: <private | public> SPI_string path_of_file_generated_by_keytool |
For example, the contents of the /etc/slp.spi file could look as follows: private spi1 secure_directory/priv_1234567890
public spi1 any_directory/pub_1234567890
public spi2 any_directory/pub_2234567890
public spi3 any_directory/pub_3234567890
|
Running the Services |  |
To select and run services on the network, you must first run the OpenSLP daemon (slpd), which enables binding to the SLP port. From the Internet Express Administration utility, you can start, stop, and restart the OpenSLP: From the Manage Components menu, choose Manage OpenSLP for Tru64 UNIX. The OpenSLP Administration menu is displayed. From the OpenSLP Administration menu, choose Start/Stop the OpenSLP daemon. The Start/Stop the OpenSLP Daemon form is displayed, indicating whether the OpenSLP daemon is running or is stopped. When the daemon is stopped, Start and Cancel buttons appear on the form. When the daemon is running, Stop, Restart, and Cancel buttons appear. To start the OpenSLP daemon, click the Start button. This action starts the OpenSLP daemon (slpd with certain default options: -c /etc/slp.config when no security is enabled, and -s /etc/slp.spi when security is enabled. To stop a running OpenSLP daemon, click the Stop button. This action terminates the OpenSLP daemon (slpd). Click the Restart button to stop the OpenSLP daemon and then start it again. The Cancel option leaves the OpenSLP daemon in its current state and displays a message that daemon will not be changed.
The following information describes how to control the OpenSLP daemon from the command line: To select and run services on the network, you must first run the SLP daemon (slpd) as root, which enables binding to the SLP port. The SLP daemon relinquishes root privilege and sets the user ID (suid) to the daemon user. If you attempt to run slpd from a nonroot account, a fatal error will occur (that is, slpd must be started by root). Use the following command to run the SLP daemon: # slpd -c configuration-file -r registration-file -s spi-file |
Each parameter is optional. The /etc/slp.conf configuration file, /etc/slp.reg registration file, and /etc/slp.spi index file will be used if you do not specify another file location. For information on other potential error messages, see Section 4.1.2 of RFC 2614, An API for Service Location, at the following URL: Internet Express provides an example configuration that you can build and run. Each example is fully documented in the example.c source file that tests specific SLP APIs. See the example.c file for detailed descriptions of the various function calls. The registration file for the example, example.reg, contains information on service registration. The example configuration file, example.conf, lists the scopes that are used. (Scopes are the set of SLP services that compose a logical administrative group.) Follow these steps to run the example configuration: As root, use the following command to run the SLP daemon (slpd) for the example configuration: # slpd -c example.conf -r example.reg |
With the SLP daemon successfully running, log in as any user and enter the following commands to build and run the SLP example, located in the /usr/internet/openslp/examples directory: # cc example.c -o example -lslp
# example
|
Review the expected output for the example program can be found in the example.output file .
For further information, see RFC 2614 (http://www.ietf.org/rfc/rfc2614.txt) for a description of the configuration and registration files for an API for Service Location. This section provides considerations to better understand how SLP APIs are applied. For additional information on SLP APIs, refer to Section 4 (C Language Binding) of RFC 2614, An API for Service Location , at the following URL: Consider the following notes when you review the SLP APIs used in the examples (Section : Running the Example Configuration) provided with the OpenSLP component: A service registration with no scope specified is a member of the default scope. Service registrations containing a scope must have DEFAULT listed to be a member of the default scope. A service registration with no naming authority specified is a member of the default naming authority (IANA, represented by the empty string). The SLPOpen API, used in all examples, returns an SLP handle for a particular language locale. The default language is English (represented by en). The isAsync parameter must be SLP_FALSE. The SLPClose API, also used in all examples, closes an open SLP handle and frees all resources associated with the handle. Callback functions will no longer be called. The SLPFindSrvTypes API, used in Example 1, locates service types (i.e., service:scheme). The query can be limited by a scope list and a naming authority. Results are returned in the callback function specified. Queries are independent of the language locale; service types for all language locales will be returned regardless of the language locale specified in the SLPOpen call and represented by the SLPHandle parameter to this function. The SLPSrvTypeCallback API, used in Example 1, is a function type that returns service types from the SLPFindSrvTypes query. The name of the function is user defined and is a parameter to the SLPFindSrvTypes function. Data can be passed between the client who makes the SLPFindSrvTypes call and the callback function via the pvCookie parameter. The SLPFindSrvs API, used in Examples 2, 4, and 5, locates the services. The query can be limited by a service type, scope list, or attribute search filter. Results are returned in the callback function specified. Queries are limited to the language locale specified in the SLPOpen call and represented by the SLPHandle parameter to this function. The SLPSrvURLCallback API, used in Examples 2, 4, and 5, is a function type that returns services from the SLPFindSrvs query. The name of the function is user defined and is a parameter to the SLPFindSrvs function. Data can be passed between the client who makes the SLPFindSrvs call and the callback function via the pvCookie parameter. This function serves as an iterator to return multiple values. This function must return SLP_TRUE to continue to return data. When the value of the errCode parameter is SLP_LAST_CALL, there will be no additional data to retrieve. The SLPFindAttrs API, used in Examples 3, 6, and 7, locates service attributes. The query can be limited by a scope list, attribute IDs, and either a service type or a service URL. Results are returned in the callback function specified. Queries are limited to the language locale specified in the SLPOpen call and represented by the SLPHandle parameter to this function. The SLPFindAttrCallback API, used in Examples 3, 6, and 7, is a function type that returns services from the SLPFinAttrs query. The name of the function is user defined and is a parameter to the SLPFindAttrs function. Data can be passed between the client who makes the SLPFindAttrs call and the callback function via the pvCookie parameter. This function serves as an iterator to return multiple values. This function must return SLP_TRUE to continue to return data. When the value of the errCode parameter is SLP_LAST_CALL, there will be no additional data to retrieve. Example 8 uses SLPFindSrvTypes, SLPFindSrvs, SLPSrvTypeCallback, and SLPSrvURLCallback. The example demonstrates a complicated query using multiple SLP APIs.
Documentation for OpenSLP can be accessed online from the Caldera Systems, Inc. Web site and from other SLP sites on the Web. Example and configuration files (Section : Configuration Files and Examples) included in the OpenSLP subset also include documentation that describes operation of the software. The following list describes the SLP documentation available on line: Introduction to SLP – Provides an overview of the Service Location Protocol and a general description of the agents, messages, and APIs. Service Location Protocol Version 2 – Information about the standard protocol for SLP. Service Location Application Programming Interface (API) – Information about the standardized APIs for SLP in C and Java. Programmer's Guide – Information describing the SLP APIs and the OpenSLP implementation from Caldera Systems. This guide is helpful for developers using the Tru64 UNIX OpenSLP implementation provided with Internet Express that is based on the Caldera Systems OpenSLP.
|