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.
With legacy service advertising, you can enable the SLP UAs to find devices and services such as the following on your networks. You can find 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.
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.
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.
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.
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.
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 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:
net.slp.serializedRegURL=file:/etc/inet/slp.reg |
Save your changes and close the file.
Restart slpd to activate your changes.
# svcadm enable network/slp |
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) (3) service:lpr://bizserver/mainspool,en,65535 (4) scope=eng,corp (5) make-model=Laserwriter II (6) location-description=B16-2345 (7) color-supported=monochromatic (8) fonts-supported=Courier,Times,Helvetica 9 10 (9) (10) #Advertise FTP server (11) (12) ftp://archive/usr/src/public,en,65535,src-server (13) content=Source code for projects (14) |
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.
Generally, modifying the source code to add SLP is preferable to writing a SLP-enabled service that uses the SLP API to advertise on behalf of other services. Modifying the source code is also preferable to using proxy registration. When you modify the source code, you can add service-specific features and closely track service availability. If the source code is unavailable, writing an SLP-enabled helper service that advertises on behalf of other services is preferable to using proxy registration. Ideally, this helper service is integrated into the service start/stop procedure that is used to control activation and deactivation. Proxy advertising is generally the third choice, when no source code is available and writing a standalone SA is impractical.
Proxy advertisements are maintained only if slpd is running to read the proxy registration file. No direct connection exists between the proxy advertisement and the service. If an advertisement times out or slpd is halted, the proxy advertisement is no longer available.
If the service is shut down, slpd must be stopped. The serialized registration file is edited to comment out or remove the proxy advertisement, and slpd is restarted. You must follow the same procedure when the service is restarted or reinstalled. The lack of connection between the proxy advertisement and the service is a major disadvantage of proxy advertisements.