/usr/share/doc/openslp-doc/html/UsersGuide/SlpReg.html is in openslp-doc 1.2.1-10+deb8u1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 | <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="GENERATOR" content="Mozilla/4.72C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.2.14 i686) [Netscape]">
<title>OpenSLP - Static Registration File</title>
</head>
<body text="#000000" bgcolor="#FFFFFF" link="#0000EE" vlink="#551A8B" alink="#FF0000">
<h2>
The Static Registration File</h2>
<hr WIDTH="100%">
<p>Often it will be very useful for OpenSLP users to be able to statically
register legacy services (applications that were not compiled to use the
SLP library). To accommodate this need <a href="../../rfc/rfc2614.txt">RFC
2614</a> specifies a syntax for a registration file that is read by the
OpenSLP daemon (slpd). All of the registrations from the registration
file are maintained by slpd and will remain registered as long as slpd
is alive. The default location for the registration can be changed
from <tt>/etc/slp.reg
</tt>to another location using the <a href="CommandLine.html">-r
command line option</a><tt>. slpd reads the slp.reg </tt>file on
startup and re-reads it when ever the SIGHUP signal is received.
<h3>
<tt>Syntax</tt></h3>
The registration file format is pretty easy to understand. It can
get complicated so if you have any questions after reading this please
consult <a href="../../rfc/rfc2614.txt">RFC 2614.</a>
Each registration consists of several lines with the following format:
<br>
<blockquote><b><tt>#comment</tt></b>
<br><b><tt>;comment</tt></b>
<br><b><tt>service-url,language-tag,lifetime,[service-type]<newline></tt></b>
<br><b><tt>"scopes="[scope-list]<newline></tt></b>
<br><b><tt>[attrid]"="val1<newline></tt></b>
<br><b><tt>[attrid]"="val1,val2,val3<newline></tt></b>
<br><b><tt><newline></tt></b></blockquote>
<p><br><b><tt>service-url</tt></b>
<blockquote>(Required) The service-url which must follow the Service URL
syntax explained <a href="#Service URL Syntax">below</a>.</blockquote>
<b><tt>language-tag</tt></b>
<blockquote>(Required) The language-tag uses the (two character) language
tags as specified by <a href="../../rfc/rfc1766.txt">RFC
1766</a> ("en" "fr", "de", etc...)</blockquote>
<b><tt>lifetime</tt></b>
<blockquote>(Required) The lifetime of the registration in seconds.
Value must be between 0 and 65535. Use 65535 if you want the registration
to be maintained for the life of slpd.</blockquote>
<b><tt>service-type</tt></b>
<blockquote>(Optional) The type of service being registered. Ignored
by OpenSLP because service-url must conform to the SLP Service URL format.</blockquote>
<b><tt>scope-list</tt></b>
<blockquote>(Optional) List of comma delimited scopes to register the service
in. If omitted then service is registered in all scopes specified
by the <tt><a href="SlpConf.html">slp.conf</a></tt>
file.</blockquote>
<b><tt>attrs</tt></b>
<blockquote>(Optional) The attributes to register along with the service.
Any string but "scopes" or "SCOPES" can be used as an attrid. Note
that the '"' character has no real significance. Strings should not be
quoted!</blockquote>
<h3>
Examples</h3>
Several examples of registration entries are provided below:
<br>
<blockquote><tt>#Register a OpenSLP testing service</tt>
<br><tt>service:test.openslp://192.168.100.1,en,65535</tt>
<br><tt>scopes=test1,test2</tt>
<br><tt>description=OpenSLP Testing Service</tt>
<br><tt>authors=mpeterson,jcarey</tt>
<p><tt>#Register ssh service</tt>
<br><tt>service:ssh.openslp://192.168.100.1,en,65535</tt>
<br><tt>#use default scopes</tt>
<br><tt>description=Secure Shell</tt>
<p><tt>#Register telnet service with no attributes</tt>
<br><tt>service:telnet.myorg://192.168.100.1,en,65535</tt>
<br><tt>#use default scopes</tt></blockquote>
<h3>
<a NAME="Service URL Syntax"></a>Service URL Syntax</h3>
If you decide to use Service URLs extensively, you should probably
read <a href="../../rfc/rfc2609.txt">RFC 2609</a>,
but if you just want to know what they look like, the following explanation
should be good enough:
<blockquote><tt>service-url = "service:"<service-type>"://"<addrspec></tt></blockquote>
The service-type is a service type as explained <a href="#SLP Service Type Syntax">below</a>.
addrspec can be just about anything you want that fits URL syntax (see
<a href="../../rfc/rfc2396.txt">RFC 2396</a>) and can be translated as a network location. The "<tt>service:</tt>"
and "<tt>://</tt>" strings are required.
<p><b>Service URL Examples</b>
<p><tt>service:weather.nasa:wtp://weather.nasa.com:12000</tt>
<br><tt>service:weather.nasa:swtp://weather.nasa.com:12001</tt>
<br><tt>service:chat.superchat://chat.superchat.com;auth=ldap</tt>
<br>
<h3>
<a NAME="SLP Service Type Syntax"></a>SLP Service Type Syntax</h3>
The official definition of Service Type strings can be found in
<a href="../../rfc/rfc2609.txt">RFC 2609</a>,
"Service Templates and Service Schemes". If you will be
working with "well known" (IANA) service types, you should read it.
If you are developing applications for "proprietary" services then you
will probably be satisfied with the following explanation:
<p> <tt>service-type = <abstract-type.naming-authority>":"<concrete-type></tt>
<p>The abstract-type is simple (hopefully short) descriptive string that
describes the type of service. The naming-authority is the name (hopefully
unique) name of the organization that named the service. The naming-authority
is optional, but if it is omitted then IANA is assumed to be the naming
authority and IANA requires service-types to be registered
(see <a href="../../rfc/rfc2609.txt">RFC 2609</a>). The
concrete-type is also optional. Think of a concrete-type
as a kind of sub-type of the abstract-type. For example, "printer"
is an abstract type (owned by IANA) and "printer:lpr" is a concrete type
(owned by IANA).
<p><b>Service Type Examples</b>
<p><tt>weather.nasa:wtp</tt> - A (fictitious) weather service type
owned by NASA that uses Weather Transfer protocol
<br>weather.nasa:swtp - A (fictitious) weather service type owned by NASA
that uses Simple Weather Transfer protocol.
<br><tt>chat.superchat</tt> - A chat service type owned by SuperChat
<br><tt>printer.samba</tt> - A samba printer service type
<br><tt>ftp</tt> - An IANA ftp service type
<br><tt>telnet</tt> - An IANA telnet service type
<br>
</body>
</html>
|