The OpenSLP services on OES 2 are compatible with NetWare SLP services.
This section discusses the following topics:
The Service Location Protocol (SLP) was developed so that clients and other software modules can dynamically discover and use services on the network without knowing the IP address or the hostname of the server offering the service.
NetWare: Although many other applications and server types rely on SLP for service discovery, NetWare services are actually integrated with eDirectory, and if eDirectory is configured correctly, the services work without SLP. However, SLP is automatically provided on NetWare for other services that might be installed.
OES 2: On the other hand, for OES 2 services to work, the server must either:
Have an eDirectory replica installed.
This is not automatic after the third server installed in a tree, nor is having more than three to five replicas on servers in the tree recommended.
Have eDirectory registered with the OpenSLP service running on the server.
This requires SLP configuration either during the OES 2 installation or manually.
Three software “agents” provide the infrastructure for service discovery:
Service Agents (SAs): Are a required component of any SLP infrastructure. They act on behalf of a network service that is running on a server by advertising that the service is available.
User Agents (UAs): Are also required. They act on behalf of clients or other software modules that need network services by searching for the needed services.
Directory Agents (DAs): Are technically optional, but they are used in most SLP infrastructures. They collect service information from Service Agents so that User Agents can more easily locate the services. DAs are like a phone book directory listing of services on the network.
DAs are not needed when all of the SAs and UAs are on the same subnet. This is because the UAs and SAs can find each other within the subnet using multicast packets, provided that there are no firewalls that are set to block multicast traffic.
Novell recommends against routing multicast packets across subnet boundaries, and most network configurations conform with that recommendation. Therefore, when SAs and UAs are on different subnets, they need an alternative to multicasting for advertizing and locating services on the other subnets.
Network administrators use DAs to solve this problem by setting up organzational or geographical DAs and then configuring the SAs and UAs within the organization or georgraphical area to use them. Many administrators further subdivide the DA workload by defining multiple SLP scopes based on different kinds of network services, and then configuring the SAs and UAs to communicate with the DAs servicing the scope that pertains to them.
When you configure eDirectory during an OES server installation, you have the option of specifying one or more SLP DAs for the server to communicate with. Each time eDirectory starts and every hour thereafter, the server’s SA will send a unicast packet to the server’s assigned DAs, advertising that its eDirectory services are available.
IMPORTANT: Prior to eDirectory 8.8.2, the eDirectory SA advertised service availability every 10 minutes by default. Starting with eDirectory 8.8.2, the refresh interval changed to one hour. This has caused some confusion for network administrators who couldn’t figure out why it took so long for eDirectory to register as a service
For information on how to set the refresh interval to a smaller value, see TID 7001449 in the Novell Support Knowledgebase.
As you can imagine, a Directory agent in a large organization can accumulate many service listings after it has been running for a while. Unfortunately, because DAs are inherently cache-only repositories, if they go down for some reason, when they come back up their list of services is initially blank.
Novell SLP solved this problem on NetWare 5.x and later through eDirectory Modified Event notifications. These notifications keep all of the NetWare DA's that are servicing the same scope in sync with each other. After going down and coming back up, a NetWare DA can quickly recover its directory listings.
OpenSLP DA's, on the other hand, have historically been completely independent from each other. Because they are not eDirectory-aware, they have had no means of recovering the directory listings they had prior to going down.
This has now changed in OES 2 SP3.
OpenSLP DAs can now
Retrieve and/or push service information to and/or from other DAs. For more information, see Synchronizing Data Between OpenSLP DAs and/or Novell SLP DAs.
Back up their service registrations so that when the DA service is started up it can read the backup file and pre-populate its cache. For more information, see Backing Up Registrations and Managing Persistence.
These changes provide, in effect, the same type of DA to DA communication for OES that has traditionally been available only on NetWare.
Table 13-4 SLP Solutions
|
Platform |
NetWare |
OES 2 |
|---|---|---|
|
SLP Solution |
Novell SLP |
OpenSLP |
|
About the Solution |
The Novell version of SLP adapted portions of the SLP standard to provide a more robust service advertising environment. Novell SLP remains the default discovery mechanism for NetWare 6.5 SP8 servers. However, all NetWare service components that engage in discovery, including Novell Client software, can use alternative mechanisms such as DNS, eDirectory, or local host configuration files. |
OpenSLP is an implementation of various IETF specifications, including RFC 2614 (SLP version 2.0). It is the default SLP service installed on SLES 10. In OES 2, OpenSLP is available for those applications that require it. The default discovery mechanism is actually DNS, but SLP must be present for any applications that require it, especially in those cases where the OES 2 server is the fourth or later server added to a tree and doesn’t have an eDirectory replica automatically installed. |
|
Differences |
Novell SLP directory agents (DAs) store service registrations for their SLP scope in eDirectory. As a new service registration is stored in eDirectory, other DAs assigned to the same scope are notified so that they can refresh their caches with the latest service information. Also, when a Novell SLP DA starts up, it immediately populates its cache with the latest service information stored in eDirectory. NOTE:Novell SLP DAs do not directly share information with each other as many administrators have assumed. But they do maintain well synchronized caches through eDirectory as described above. |
OpenSLP directory agents (DAs) are able to share service registrations as described in Synchronizing Data Between OpenSLP DAs and/or Novell SLP DAs. OpenSLP is also capable of ensuring data persistence when DAs go down, as explained in Backing Up Registrations and Managing Persistence. |
|
Compatibility |
Novell SLP user agents (UAs) or service agents (SAs) can access both Novell SLP DAs and OpenSLP DAs. |
OpenSLP-based user agents or service agents can access both Novell SLP DAs and OpenSLP DAs. |
|
Documentation |
|
|
SLP services are always installed as part of both NetWare and SLES 10 SP4 (the underlying OES 2 SP3 platform). On NetWare the Novell SLP service is configured to automatically work with eDirectory and other services. On OES 2, the OpenSLP service must be manually configured to work with eDirectory and other services.
You must set up OpenSLP on your OES 2x server if both of the following apply:
You plan to install more than three servers into a new tree or a new eDirectory partition being created on an OES 2 server.
You either don’t have an existing Novell SLP service, or you don’t want to continue using Novell SLP.
IMPORTANT:If you need to set up OpenSLP for the reasons above, it is most convenient if you do it before you install the fourth server in your tree or partition. That way you can point to the SLP service during the installation. Setting up SLP services on every OES 2 server is recommended.
If you need OpenSLP and you don’t already have an OpenSLP Directory Agent (DA) set up on your network, for simplicity’s sake we recommend that you set up the first OES 2 server in your tree as an OpenSLP DA. Although SLP services can be managed without having a Directory Agent, that approach is far less robust, requires multicasting, and involves disabling the firewall.
After creating the DA, you can then configure all subsequently installed servers to either point to that DA or to other DAs you create later.
On the OES 2 server that will become the DA, open the /etc/slp.conf file in a text editor.
In slp.conf, remove the semicolon [;]) from the beginning of the following line:
;net.slp.isDA = true
so that it reads
net.slp.isDA = true
Find the following line:
;net.slp.useScopes = myScope1, myScope2, myScope3
IMPORTANT:The example in the configuration file is misleading because the spaces after each comma are not ignored as one might expect them to be.
Therefore, the scope names created or configured by the statement after the first comma actually have leading spaces in them. For example, the first scope name is myScope1
but the scope names that follow it all have leading spaces, myScope2
, myScope3
and so on. This is a problem, especially if one of the later names becomes the first name in a subsequent SLP configuration and the leading space is ignored.
If you use the scopes given in the example, remove the spaces between the entries.
Modify the line by removing the semicolon and typing the name of the scope you want this DA to use to provide service information on the network. For example, you might change the line as follows:
net.slp.useScopes = Directory
IMPORTANT:Although SLP provides a default scope if no scope is specified, it is always good practice to define one or more scopes by configuring the net.slp.useScopes parameter in slp.conf.
Scopes group and organize the services on your network into logical categories. For example, the services that the Accounting group needs might be grouped into an Accounting scope.
More information about scope planning is available in Configuring OpenSLP for eDirectory
in the Novell eDirectory 8.8 SP7 Administration Guide and on the OpenSLP Web site.
When no scope is specified, all services are registered in a scope named Default.
Configure the firewall on the DA server to allow SLP daemon traffic:
In the YaST Control Center, click > .
In the left navigation frame, click .
Click the drop-down list and select .
Click > .
Click .
At the command prompt, enter the following command to restart the SLP daemon:
rcslpd restart
(Conditional) If you are doing this after installing OES 2 and eDirectory, you must also restart eDirectory by entering the following command:
rcndsd restart
Continue with the following sections that apply to your situation:
This is accomplished through setting the following parameters in the slp.conf file:
If the net.slp.dasyncreg parameter value is set to true, then synchronization is achieved by the DA pushing or pulling SLP registrations from the DAs listed for the slp.DAaddresses parameter, as follows:
When the DA starts up, it pulls the registration information from all of the server DAs listed in the the slp.DAaddresses parameter, including any Novell SLP DAs listed.
When the DA receives a service registration, it forwards the information to the OpenSLP DAs that are listed.
IMPORTANT:Service registrations cannot be pushed to Novell SLP DA's.
This is accomplished through setting the following parameters in the slp.conf file:
net.slp.isDABackup = true/false
net.slp.DABackupInterval = time_in_seconds
If the net.slp.isDABackup parameter is set to true, service registrations are backed up in the /etc/slp.reg.d/slpd/DABackup file at the interval specified for the net.slp.DABackupInterval parameter. By default, the interval parameter value is 900 secs.
If you created the OpenSLP DA on an OES 2 server installed in your tree, then SLP is properly configured on that server and these instructions do not apply to it.
For all other OES 2 servers installed in your eDirectory tree, you should complete one of the following procedures as it applies to your situation:
As you install OES 2 by using the instructions in the Novell eDirectory Services
section of the OES 2 SP3: Installation Guide, do the following:
When you reach the eDirectory Configuration - NTP and SLP
section of the installation, select .
The first option, , causes problems with eDirectory and other services if this is the fourth or later server installed in the tree. The second option, , requires that you disable the firewall on the server. Disabling the firewall is always discouraged.
In the field, specify the scope you defined in Step 4. You can also list additional scopes, separated by commas (no spaces).
For example, you might type Directory in the field if that is the scope name you assigned to the DA you created.
In the field, type the IP address of the DA server you defined in Setting Up an OpenSLP DA Server. You can also list additional DA addresses, separated by commas.
Return to the Novell Modular Authentication Services
instructions in the OES 2 SP3: Installation Guide.
Whether you configure DA access before installing OES 2 on a SLES 10 server or after a simultaneous install of SLES 10 and OES 2, the manual DA configuration process is the same.
Open /etc/slp.conf in a text editor.
Find the following line:
;net.slp.useScopes = myScope1, myScope2, myScope3
IMPORTANT:The example in the configuration file is misleading because the spaces after each comma are not ignored as one might expect them to be.
Therefore, the scope names created or configured by the statement after the first comma actually have leading spaces in them. For example, the first scope name is myScope1
but the scope names that follow it all have leading spaces, myScope2
, myScope3
and so on. This is a problem, especially if one of the later names becomes the first name in a subsequent SLP configuration and the leading space is ignored.
If you use the scopes given in the example for some reason, remove the spaces between the entries.
Modify the line by removing the semicolon and typing the name or names of the scopes you want this server to have access to. Be sure to include the scope you defined in Step 4.
For example, you might change the line as follows:
net.slp.useScopes = Directory
Find the following line:
;net.slp.DAAddresses = myDa1,myDa2,myDa3
Modify the line by removing the semicolon and typing the actual IP address of the OpenSLP DA you defined in Setting Up an OpenSLP DA Server.
net.slp.DAAddresses = IP_Address
Save the file and close it.
At the Linux command prompt, enter the following to restart the SLP daemon and reset its configuration:
rcslpd restart
IMPORTANT:NetWare uses Novell SLP by default and will configure a server for that service if possible.
Complete one of the following as it applies to your situation:
In the dialog box where you set up IP addresses for network boards, click .
Click the tab.
Specify the IP address of the OES 2 DA servers—up to three.
Type the list of scopes covered by the configured DAs that you want the NetWare server to have access to.
IMPORTANT:We recommend you do not configure the server to use multicast because that necessitates disabling firewalls, which is never recommended.
Click OK.
Using a text editor, edit the SYS:ETC/slp.cfg file on the NetWare server and add the following line for each DA server you want the NetWare server to have access to:
where IP_AddressX is the IP address of an OES 2 DA server.
Save the file and close it.
At the NetWare console prompt, specify the scopes you want the NetWare server to have access to, write the SLP cache to the registry, and restart the SLP service:
Verify that SLP is functioning correctly by entering the following command:
display slp services
If you have a NetWare tree, you automatically have Novell SLP on your network and you can continue to use it as the SLP service during the upgrade to OES 2 until you are ready to switch to OpenSLP.
This section discusses the following:
When you install NetWare, if you don’t specify an alternate SLP configuration, the server is automatically configured to use Novell SLP in a way that is sufficient for most networks. Information about Novell SLP and customization instructions is available in Configuring OpenSLP for eDirectory
in the Novell eDirectory 8.8 SP7 Administration Guide.
For each of the OES 2 servers installed in your eDirectory tree, you should complete one of the following procedures as it applies to your situation:
As you install OES 2, in the Novell eDirectory Services
section of the OES 2 SP3: Installation Guide, do the following:
When you reach the SLP section of the installation, select .
The first option, , causes problems with eDirectory and other services if this is the fourth or later server installed in the tree. The second option, , requires that you disable the firewall on the server. Disabling the firewall is always discouraged.
In the field, specify one or more appropriate scopes that are defined on your network.
If you aren’t sure about the exact scope names, you can view the SLP configuration of a NetWare server on the same network segment. Log into Novell Remote Manager on the server and click > .
You can list multiple scopes, separated by commas (no spaces).
For example, you might type Directory in the field.
In the field, type the IP address of an appropriate DA server.
You can use Novell Remote Manager on a NetWare server if you aren’t sure which address to use.
You can also list additional DA addresses, separated by commas.
Return to the Novell eDirectory Services
instructions in the OES 2 SP3: Installation Guide.
Whether you configure DA access before installing OES 2 on a SLES 10 server or after a simultaneous install of SLES 10 and OES 2, the manual DA configuration process is the same.
Open /etc/slp.conf in a text editor.
Find the following line:
;net.slp.useScopes = myScope1, myScope2, myScope3
IMPORTANT:The example in the configuration file is misleading because the spaces after each comma are not ignored as one might expect them to be.
Therefore, the scope names created or configured by the statement after the first comma actually have leading spaces in them. For example, the first scope name is myScope1
but the scope names that follow it all have leading spaces, myScope2
, myScope3
and so on. This is a problem, especially if one of the later names becomes the first name in a subsequent SLP configuration and the leading space is ignored.
If you use the scope names given in the example, remove the spaces between the entries.
Modify the line by removing the semicolon and typing the name or names of the scopes you want this server to have access to.
If you aren’t sure about the exact scope names, you can view the SLP configuration of a NetWare server on the same network segment. Log into Novell Remote Manager on the server and click > .
You can list multiple scopes, separated by commas (no spaces).
For example, you might change the line as follows:
net.slp.useScopes = Directory
Find the following line:
;net.slp.DAAddresses = myDa1,myDa2,myDa3
Modify the line by removing the semicolon and typing the actual IP address of the Novell SLP DA (using Novell Remote Manager if necessary).
net.slp.DAAddresses = IP_Address
Save the file and close it.
At a terminal prompt, enter the following to restart the SLP daemon and reset its configuration:
rcslpd restart
Enter the following commands to verify that the DA and scopes you configured are recognized.
slptool findsrvs service:
The DA server should be listed.
slptool findscopes
The scopes should be listed.
If you did this after installing OES 2, enter the following to verify that the tree is found:
slptool findsrvs service:ndap.novell
There are several ways to check the status of Novell SLP services.
If you know the IP addresses of the DAs, check the SYS:\etc\slp.cfg file on non-DA servers to see if the DA IP addresses are listed.
If you know the scope names, check for the proper scope name configuration by using the SET SLP SCOPE LIST command.
Use the DISPLAY SLP SERVICES command to list all of the services that are registered in all of the scopes that the server is configured to use.
Use iManager to open the scope container object to see all of the registered services.
If you are registering different services in different scopes, look in the SYS:\etc\slp.cfg file for REGISTER TYPE lines.
At the DOS prompt on a Windows workstation with Client32 installed, use the SLPINFO /ALL command.