Internet Express Version 6.7 for Tru64 UNIX: Internet Express for Tru64 UNIX Administration Guide
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.
|