Chapter 24. SLP Services in the Network

Contents

24.1. Installation
24.2. Activating SLP
24.3. SLP Front-Ends in openSUSE
24.4. Installation over SLP
24.5. Providing Services via SLP
24.6. For More Information

The service location protocol (SLP) was developed to simplify the configuration of networked clients within a local network. To configure a network client, including all required services, the administrator traditionally needs detailed knowledge of the servers available in the network. SLP makes the availability of selected services known to all clients in the local network. Applications that support SLP can use the information distributed and be configured automatically.

openSUSE® supports installation using installation sources provided with SLP and contains many system services with integrated support for SLP. YaST and Konqueror both have appropriate front-ends for SLP. You can use SLP to provide networked clients with central functions, such as an installation server, file server, or print server on your system.

[Important]SLP Support in openSUSE

Services that offer SLP support include cupsd, rsyncd, ypserv, openldap2, ksysguardd, saned, kdm, vnc, login, smpppd, rpasswd , postfix, and sshd (via fish).

24.1. Installation

All packages necessary to use SLP services are installed by default. However, if you want to provide services via SLP, check that the openslp-server package is installed. For SLP daemon server configuration install the yast2-slp-server package.

24.2. Activating SLP

slpd must run on your system to offer services with SLP. If the machine should only operate as client, and does not offer services, it is not necessary to run slpd. Like most system services in openSUSE, the slpd daemon is controlled by means of a separate init script. After the installation, the daemon is inactive by default. To activate it temporarily, run rcslpd start as root or rcslpd stop to stop it. Perform a restart or status check with restart or status. If slpd should be always active after booting, enable slpd in YaST System+System Services (Runlevel) or run the insserv slpd command as root.

24.3. SLP Front-Ends in openSUSE

To find services provided via SLP in your network, use an SLP front-end such as slptool (openslp package) or YaST:

slptool

slptool is a command line program that can be used to announce SLP inquiries in the network or announce proprietary services. slptool --help lists all available options and functions. For example, to find all time servers that announce themselves in the current network, run the command:

slptool findsrvs service:ntp
YaST

YaST also provides an SLP browser. However, this browser is not available from the YaST Control Center. To start it, run yast2 slp as root user. Click on a Service Type on the lefthand side to get more information about a service.

24.4. Installation over SLP

If you have an installation server with openSUSE installation media within your network, this can be registered and offered with SLP. For details, see Section 2.2, “Setting Up the Server Holding the Installation Sources”. If SLP installation is selected, linuxrc starts an SLP inquiry after the system has booted from the selected boot medium and displays the sources found.

24.5. Providing Services via SLP

Many applications in openSUSE have integrated SLP support through the use of the libslp library. If a service has not been compiled with SLP support, use one of the following methods to make it available via SLP:

Static Registration with /etc/slp.reg.d

Create a separate registration file for each new service. This is an example for registering a scanner service:

## Register a saned service on this system
## en means english language
## 65535 disables the timeout, so the service registration does
## not need refreshes
service:scanner.sane://$HOSTNAME:6566,en,65535
watch-port-tcp=6566
description=SANE scanner daemon

The most important line in this file is the service URL, which begins with service:. This contains the service type (scanner.sane) and the address under which the service is available on the server. $HOSTNAME is automatically replaced with the full hostname. The name of the TCP port on which the relevant service can be found follows, separated by a colon. Then enter the language in which the service should appear and the duration of registration in seconds. These should be separated from the service URL by commas. Set the value for the duration of registration between 0 and 65535. 0 prevents registration. 65535 removes all restrictions.

The registration file also contains the two variables watch-port-tcp and description. watch-port-tcp links the SLP service announcement to whether the relevant service is active by having slpd check the status of the service. The second variable contains a more precise description of the service that is displayed in suitable browsers.

Static Registration with /etc/slp.reg

The only difference between this method and the procedure with /etc/slp.reg.d is that all services are grouped within a central file.

Dynamic Registration with slptool

If a service needs to be registered dynamically without the need of configuration files, use the slptool command line utility. The same utility can also be used to deregister an existing service offering without restarting slpd.

24.6. For More Information

RFC 2608, 2609, 2610

RFC 2608 generally deals with the definition of SLP. RFC 2609 deals with the syntax of the service URLs used in greater detail and RFC 2610 deals with DHCP via SLP.

http://www.openslp.org

The home page of the OpenSLP project.

/usr/share/doc/packages/openslp

This directory contains the documentation for SLP coming with the openslp-server package, including a README.SuSE containing the openSUSE details, the RFCs, and two introductory HTML documents. Programmers who want to use the SLP functions find more information in the Programmers Guide that is included in the openslp-devel package.