21.6. SLP Services in the Network

The service location protocol (SLP) was developed with the aim of simplifying 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 is used to make the availability of a certain service known to all clients in the local network. Applications that support SLP can use the information distributed and be configured automatically.

[Important]SLP Support in SUSE LINUX Enterprise Server

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

21.6.1. SLP Support in SUSE LINUX

SUSE LINUX supports installation using installation sources provided via 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 installation server, YOU server, file server, or print server on your SUSE LINUX Enterprise Server.

21.6.1.1. Installation via SLP

If you offer an installation server with SUSE LINUX installation media within your network, this can be registered with SLP. For details, see Section 4.1. “Setting up a Central Installation Server”. 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.

21.6.1.2. Registering Your Own Services

Many applications under SUSE LINUX already 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 with SLP:

Static Registration via /etc/slp.reg.d

Create a separate registration file for each new service. The following is an example of a file 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 host name. 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-tcp-port and description. The former links the SLP service announcement to whether the relevant service is active because slpd checks the status of the service. The second variable contains a more precise description of the service that is displayed in suitable browsers.

[Tip]YaST and SLP

Some services brokered by YaST, such as an installation server or YOU server, perform this registration for you automatically when you activate SLP in the module dialogs. YaST then creates registration files for these services.

Static Registration with /etc/slp.reg

The only difference from the procedure described above is the grouping of all services within a central file.

Dynamic Registration with slptool

If a service should be registered for SLP from proprietary scripts, use the slptool command line front-end.

21.6.1.3. SLP Front-Ends in SUSE LINUX

SUSE LINUX contains several front-ends that enable SLP information to be checked and used by means of a network:

slptool

slptool is a simple command line program that can be used to announce SLP inquiries in the network or to announce proprietary services. slptool --help lists all available options and functions. slptool can also be called from scripts that process SLP information.

YaST SLP Browser

YaST contains a separate SLP browser that lists all services in the local network announced via SLP in a tree diagram under Network Services+SLP browser

Konqueror

When used as a network browser, Konqueror can display all SLP services available in the local network at slp:/. Click the icons in the main window to obtain more detailed information about the relevant service.

If you use Konqueror with service:/, click the relevant icon once in the browser window to set up a connection with the selected service.

21.6.1.4. Activating SLP

[Tip]Activating slpd

slpd must run on your system if you want to offer services. It is not necessary to start this daemon simply to make service inquiries.

Like most system services under SUSE LINUX, the slpd daemon is controlled by means of a separate init script. The daemon is inactive by default. To activate it for the duration of a session, run rcslpd start as root to start it and rcslpd stop to stop it. Perform a restart or status check with restart or status. If slpd should be active by default, run the insserv slpd command once as root. This automatically includes slpd in the set of services to start when a system boots.

21.6.2. For More information

The following sources are available for further information about SLP:

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.com

The home page of the OpenSLP project.

file:/usr/share/doc/packages/openslp/*

This directory contains all available documentation on SLP, including a README.SuSE containing the SUSE LINUX details, the RFCs mentioned above, and two introductory HTML documents. Programmers who want to use the SLP functions should install the openslp-devel package to consult its supplied Programmers Guide.