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
- Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
- Stop slpd and all SLP activity on the host.
# svcadm disable network/slp
- 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:
- Save your changes and close the file.
- Restart slpd to activate your changes.
# svcadm enable network/slp
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.
(5) make-model=Laserwriter II
(8) fonts-supported=Courier,Times,Helvetica 9 10
(10) #Advertise FTP server
(13) content=Source code for projects
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 10-1 SLP Proxy Registration File 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.
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.
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.
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.