Chapter 19Incorporating Legacy Services
Legacy services are network services that predate the development
and implementation of SLP. Solaris services such as the line printer daemon
(lpsched), the NFS file service, and
NIS/NIS+ name service, for example, do not contain internal SAs for SLP. This
chapter describes when and how to advertise legacy services.
When to Advertise Legacy Services
With legacy service advertising,
you can enable the SLP UAs to find devices and services such as the following
on your network:
Hardware devices and software services that do that do not
contain SLP SAs. When applications with SLP UAs need to find printers or databases
that do not contain SLP SAs, for example, legacy advertising might be required.
Advertising Legacy Services
You use any of the following methods to advertise
legacy services.
Modify the service to incorporate an SLP SA.
Write a small program that advertises on behalf of a service
that is not SLP enabled.
Use
proxy advertising to have slpd advertise the service.
Modifying the Service
If the source code for the software server is available, you can incorporate
a SLP SA. The C and Java APIs for SLP are relatively straightforward to use.
See the man pages for information on the C API and documentation on the Java
API. If the service is a hardware device, the manufacturer might have an updated
PROM that incorporates SLP. Contact the device manufacturer for more information.
Advertising a Service That Is Not SLP Enabled
If the source code
or an updated PROM that contains SLP is not available, you can write a small
application that uses the SLP client library to advertise the service. This
application could function as a small daemon that you start or stop from the
same shell script you use to start and stop the service.
SLP Proxy Registration
Solaris slpd supports legacy service advertising
with a proxy registration file. The proxy registration file is a list of service
advertisements in a portable format.
How to Enable SLP Proxy Registration
Create a proxy registration file on the host file system or in any network
directory that is accessible by HTTP.
Determine if a service type template exists for the service. The template is a description of the service URL and attributes of a
service type. A template is used to define the components of an advertisement
for a particular service type:
If a service type template exists, use the template to construct
the proxy registration. See RFC 2609 for more information on service-type
templates.
If a service type template is not available for the service,
select a collection of attributes that precisely describe the service. Use
a naming authority other than the default for the advertisement. The default
naming authority is allowed only for service types that have been standardized.
See RFC 2609 for more information on naming authorities.
For example, suppose a company that is called BizApp
has a local database that is used to track software defects. To advertise
the database, the company might use a URL with the service type service:bugdb.bizapp. The naming authority would then be bizapp.
Follow the next steps to configure the net.slp.serializedRegURL property in the /etc/inet/slp.conf file with
the location of the registration file that was created in the previous steps.
Become superuser.
Stop slpd and all SLP activity on the host.
Back up the default /etc/inet/slp.conf file before
you change the configuration settings.
Specify the location of the proxy registration file in the net.slp.serializedRegURL property of the /etc/inet/slp.conf file. net.slp.net.slp.serializedRegURL=proxy registration file URL
|
For example, if the serialized registration file is /net/inet/slp.reg, you configure the property as shown in the following: net.slp.serializedRegURL=file:/etc/inet/slp.reg |
Save your changes and close the file.
Restart slpd to activate your changes.
Using SLP Proxy Registration to Advertise
A service advertisement
consists of lines that identify the service URL, an optional scope, and a
series of attribute definitions. The SLP daemon reads, registers, and maintains
proxy advertisements exactly as an SA client would. The following is an example
of an advertisement from a proxy registration file.
In the example, a legacy printer that supports LPR protocol and an FTP
server are advertised. Line numbers have been added for description purposes
and are not part of the file.
1#Advertise legacy printer.
2
3service:lpr://bizserver/mainspool,en,65535
4scope=eng,corp
5make-model=Laserwriter II
6location-description=B16-2345
7color-supported=monochromatic
8fonts-supported=Courier,Times,Helvetica 9 10
9
10#Advertise FTP server
11
12ftp://archive/usr/src/public,en,65535,src-server
13content=Source code for projects
14
|
Note - The proxy registration file supports the same convention for escaping
non-ASCII characters as the configuration file does. For more information
about the format of the proxy registration file, see RFC 2614.
Table 19-1 SLP Proxy Registration File Description
Line Numbers | Description |
1 and 10 | Comment lines begin with a cross-hatch symbol (#) and do not affect the file's
operation. All characters through the end of a comment line are ignored. |
2, 9, and 14 | Blank lines that
delimit the advertisements. |
3, 12 | Service URLs that each
have three required fields and one optional field that are separated by commas: Generic or service: URL advertised. See
RFC 2609 for the specification of how to form a service: URL.
Language of the advertisement. In the previous example, the
field is designated English, en. Language is an RFC 1766
language tag.
Lifetime of the registration, measured in seconds. The lifetime
is restricted to an unsigned 16 bit-integer. If the lifetime is less than
the maximum, 65535, slpd times out the advertisement. If
the lifetime is 65535, slpd refreshes the advertisement
periodically, and the lifetime is considered permanent, until slpd exits.
(Optional) Service type field - If used, this field
defines the service type. If the service URL is defined, you can change the
service type under which the URL is advertised. In the previous example of
a proxy registration file, line 12 contains a generic FTP URL. The optional
type field causes the URL to be advertised under the service type name src-server. The service prefix is not added
by default to the type name.
|
4 | Scope designation. Optional line consists of the token scope, followed by an equal sign and a comma-separated list of scope
names. Scope names are defined by the net.slp.useScopes configuration property. Only
scopes that are configured for the host should be included in the list. When
a scope line is not added, the registration is made in all scopes with which slpd is configured. The scope line must appear immediately after
the URL line. Otherwise, scope names are recognized as attributes. |
5-8 | Attribute definitions. After the optional scope line, the bulk
of the service advertisement contains attribute/value list pair lines. Each
pair consists of the attribute tag, followed by an equal sign, and an attribute
value or a comma-separated list of values. In the previous example of a proxy
registration file, line 8 illustrates an attribute list with multiple values.
All other lists have single values. The format for the attribute names and
values is the same as on-the-wire SLP messages. |
|