Environment
OpenSLP
SUSE LINUX Enterprise Server 9
SUSE LINUX Enterprise Server 10
eDir 8.7.3 and eDir 8.7.3.3
eDir 8.8.x
Novell Open Enterprise Server 2 (OES 2) Linux Support Pack 3
SUSE LINUX Enterprise Server 9
SUSE LINUX Enterprise Server 10
eDir 8.7.3 and eDir 8.7.3.3
eDir 8.8.x
Novell Open Enterprise Server 2 (OES 2) Linux Support Pack 3
Situation
eDir not registering with OpenSLP
Cannot browse for the tree or server
Can login via IP address without problems
eDir taking an hour to register its NDAP and Bindery services
OpenSLP comes up with no services initially
OpenSLP does not keep a back up of services
OpenSLP does not sync information with other DA's
Cannot browse for the tree or server
Can login via IP address without problems
eDir taking an hour to register its NDAP and Bindery services
OpenSLP comes up with no services initially
OpenSLP does not keep a back up of services
OpenSLP does not sync information with other DA's
Resolution
eDir Not registering with
OpenSLP
eDir 8.7.3.4 and 8.7.3.5 do register with OpenSLP so updating older eDir versions that are not registering their services with OpenSLP to either of these versions of eDir or later versions could be considered a solution.
eDir 8.7.3.4 and 8.7.3.5 do register with OpenSLP so updating older eDir versions that are not registering their services with OpenSLP to either of these versions of eDir or later versions could be considered a solution.
eDir 8.8.X will also register its Bindery and NDAP services
with OpenSLP however, it chooses to do so every hour. This
can be seen by looking at iMonitor > Agent Activity >
Background Processes Schedule. The RNRadvertise process is
the eDir process that registers Bindery and NDAP. There will
be a time listed to the right in the Scheduled column that will
tell you when it will register these services again.
You can change the reregistration timer in eDir for the NDAP and BINDERY services on eDir 8.8.5 with the following commands.
OpenSLP's DA is a cache-only DA
OpenSLP stores service registrations in cache.
When the SLP daemon is first loaded it has an empty cache. In other words there are no dynamic services registered yet.
OpenSLP must wait for registrations from external service providers (servers/applications) to be sent in order for those services to be added to the cache.
NOTE: OpenSLP can work around either of the eDir issues (not registering, or taking an hour to do so) by manually registering these services at start up. This is not the recommended solution as the service exists in the SLP cache regardless of whether or not eDir or the server hosting the services is actually available. (See the Additional Information section for more details)
OES2 SP3 - New additions to SLP
net.slp.isDABackup = true
Which enables the DA to backup service registrations to the /etc/slp.reg.d/slpd/DABackup file.
What this means is that services will be backed up to a file on the DA's file system so that when the cache-only OpenSLP DA starts up it can read this backup file and immediately populate its cache with services that were previously registered and backed up by this DA.
That means no waiting for services to register on the applications registration interval after an SLP restart.
net.slp.DABackupInterval = 900
This is a 32 bit integer giving the number of seconds between DABackup file updates.
The default is 15 minutes (900 seconds).
This setting is ignored if net.slp.isDA = false.
net.slp.DABackupLocalReg = true
This setting tells the DA to include its own local service registrations in the backup file.
The default is false because at start up the DA will notify the local applications/service providers that it is now a DA and those local applications / service providers should register quite quickly.
net.slp.DASyncReg = true
This setting enables slpd to sync service registrations between its configured DA's on startup. (See net.slp.DAAddresses which contains a list of IP addresses or resolvable names of DA's)
The default is false.
As stated this option will allow for services to be synchronized at start up between the configured DA's. After that it is the responsibility of the application to register and re-register with the SA to maintain it's service registrations with any and all configured DA's.
You can change the reregistration timer in eDir for the NDAP and BINDERY services on eDir 8.8.5 with the following commands.
1. ndsconfig get | grep -i n4u.nds.advertise-life-time
Note: ndsconfig get will give you
the nds configuration parameters. (Adding the grep -i
n4u.nds.advertise-life-time displays for you (case insensitive)
just the matches for the parameter you listed.)
The parameter you are looking for is
n4u.nds.advertise-life-time which by default is set to 3600 seconds
( 1 hour ) and has a settable range of 1 - 65535 seconds. If
clustered see TID# 7007479 before setting this value below
1800.
2. ndsconfig set
Note: This will allow you to set an nds parameter.
Example to change the advertise life time for SLP to 10 minutes you would do the following
ndsconfig set n4u.nds.advertise-life-time=600
Note: You can verify that eDir is using this new setting by going into iMonitor > Agent Activity> Background Process Schedule. On this screen the RNRAdvertise item will show you a "Waiting" status and the amount of Hours:Minutes:seconds until the next advertisement of the eDir service types, Bindery and NDAP.OpenSLP's DA is a cache-only DA
OpenSLP stores service registrations in cache.
When the SLP daemon is first loaded it has an empty cache. In other words there are no dynamic services registered yet.
OpenSLP must wait for registrations from external service providers (servers/applications) to be sent in order for those services to be added to the cache.
NOTE: OpenSLP can work around either of the eDir issues (not registering, or taking an hour to do so) by manually registering these services at start up. This is not the recommended solution as the service exists in the SLP cache regardless of whether or not eDir or the server hosting the services is actually available. (See the Additional Information section for more details)
OES2 SP3 - New additions to SLP
net.slp.isDABackup = true
Which enables the DA to backup service registrations to the /etc/slp.reg.d/slpd/DABackup file.
What this means is that services will be backed up to a file on the DA's file system so that when the cache-only OpenSLP DA starts up it can read this backup file and immediately populate its cache with services that were previously registered and backed up by this DA.
That means no waiting for services to register on the applications registration interval after an SLP restart.
net.slp.DABackupInterval = 900
This is a 32 bit integer giving the number of seconds between DABackup file updates.
The default is 15 minutes (900 seconds).
This setting is ignored if net.slp.isDA = false.
net.slp.DABackupLocalReg = true
This setting tells the DA to include its own local service registrations in the backup file.
The default is false because at start up the DA will notify the local applications/service providers that it is now a DA and those local applications / service providers should register quite quickly.
net.slp.DASyncReg = true
This setting enables slpd to sync service registrations between its configured DA's on startup. (See net.slp.DAAddresses which contains a list of IP addresses or resolvable names of DA's)
The default is false.
As stated this option will allow for services to be synchronized at start up between the configured DA's. After that it is the responsibility of the application to register and re-register with the SA to maintain it's service registrations with any and all configured DA's.
Additional Information
Manual Registration:
While it is possible to manually register services with SLP, that manual registration defeats the dynamic nature of SLP. Manual registrations will always be available whether or not the service is in fact available. If a URL for a service is given out by the DA to a UA when the service is really not available, it will cause the UA to try to contact the unavailable service and delays will be the result. Therefore it is not recommended to Manually register services in SLP or to add resource records for the tree or partition in DNS.
To manually register a bindery.novell and ndap.novell service in SLP the slp.reg file has to be modified with the following information.
service:bindery.novell:///servername,en,65535,bindery.novell
scopes=scopename
svcname-ws=servername
svcaddr-ws=2-1-6-0a0a0a0a020c0000000000000000,2-2-17-0a0a0a0a020c0000000000000000
NOTE - the 0a0a0a0a is the hex value for the servers IP address. Carriage returns are important.
service:ndap.novell:///partitionname,en,65535,ndap.novell
scopes=scopename
svcname-ws=partitionname
svcaddr-ws=2-1-6-0a0a0a0a020c0000000000000000,2-2-17-0a0a0a0a020c0000000000000000
NOTE- with an ndap.novell service it is possible to have multiple server addresses in the attribute svcaddr-ws. Separated with a comma and begin with 2-1-6 for the TCP address and 2-2-17 for the UDP address.
The 65535 portion of the service registration tells the DA that the service lifetime is permanent or never dies.
SLP needs to be restarted to have it read the slp.reg file and register the service. (example: rcslpd restart)
Formerly known as TID# 10096235
TID# 7007479 talks about the fact that clustered Bindery and NDAP services re-register by default every 60 minutes (3600 seconds) and have a minimum setting of 30 minutes (1800 seconds). Therefore, setting the "ndsconfig set n4u.nds.advertise-life-time=" to a value of less than 1800 seconds as discussed above can cause these clustered services to appear and disappear. Please see TID#7007479 for a more detailed explanation.
Defect #613670 tells how to see the service registrations from an NCP perspective. It says to run "ncpcon log ncpserv.log everything". You can look in the log for DircacheMaintenanceEvent or RefreshSLPAdvertisement or AdvertiseVirtualServer. Here is an example of what each would look like:
[D 2014-01-16 15:35:23] DircacheMaintenanceEvent:(2) GetParam returns ndserr = 1 slpLifetime = 300
[D 2014-01-16 15:35:23] RefreshSLPAdvertisement: server: PROVO-CLUSTER-SHARE-SERVER
[D 2014-01-16 15:35:23] AdvertiseVirtualServer: AdvertiseThruSLP start=1 name=PROVO-CLUSTER-SHARE-SERVER ipaddr=151.155.133.205 retry=0
Looking at the service registrations from an NDS perspective can be done by using ndstrace and using the TIME, TAGS, and SADV flags. The output would look something like this:
1276598592 SADV: [2010/08/11 15:34:34.6] Start advertising Bindery (edirdt-50)
via SLP succeeded.
1276598592 SADV: [2010/08/11 15:34:34.6] Start advertising NDAP (.LUM-PS.) via
SLP succeeded.
1278703936 SADV: [2010/08/11 15:35:34.2] Start advertising LDAP
(164.99.88.106:389.) via SLP succeeded.
1278703936 SADV: [2010/08/11 15:35:34.2] Start advertising Bindery (edirdt-50)
via SLP succeeded.
1278703936 SADV: [2010/08/11 15:35:34.2] Start advertising NDAP (.LUM-PS.) via
SLP succeeded.
While it is possible to manually register services with SLP, that manual registration defeats the dynamic nature of SLP. Manual registrations will always be available whether or not the service is in fact available. If a URL for a service is given out by the DA to a UA when the service is really not available, it will cause the UA to try to contact the unavailable service and delays will be the result. Therefore it is not recommended to Manually register services in SLP or to add resource records for the tree or partition in DNS.
To manually register a bindery.novell and ndap.novell service in SLP the slp.reg file has to be modified with the following information.
service:bindery.novell:///servername,en,65535,bindery.novell
scopes=scopename
svcname-ws=servername
svcaddr-ws=2-1-6-0a0a0a0a020c0000000000000000,2-2-17-0a0a0a0a020c0000000000000000
NOTE - the 0a0a0a0a is the hex value for the servers IP address. Carriage returns are important.
service:ndap.novell:///partitionname,en,65535,ndap.novell
scopes=scopename
svcname-ws=partitionname
svcaddr-ws=2-1-6-0a0a0a0a020c0000000000000000,2-2-17-0a0a0a0a020c0000000000000000
NOTE- with an ndap.novell service it is possible to have multiple server addresses in the attribute svcaddr-ws. Separated with a comma and begin with 2-1-6 for the TCP address and 2-2-17 for the UDP address.
The 65535 portion of the service registration tells the DA that the service lifetime is permanent or never dies.
SLP needs to be restarted to have it read the slp.reg file and register the service. (example: rcslpd restart)
Formerly known as TID# 10096235
TID# 7007479 talks about the fact that clustered Bindery and NDAP services re-register by default every 60 minutes (3600 seconds) and have a minimum setting of 30 minutes (1800 seconds). Therefore, setting the "ndsconfig set n4u.nds.advertise-life-time=" to a value of less than 1800 seconds as discussed above can cause these clustered services to appear and disappear. Please see TID#7007479 for a more detailed explanation.
Defect #613670 tells how to see the service registrations from an NCP perspective. It says to run "ncpcon log ncpserv.log everything". You can look in the log for DircacheMaintenanceEvent or RefreshSLPAdvertisement or AdvertiseVirtualServer. Here is an example of what each would look like:
[D 2014-01-16 15:35:23] DircacheMaintenanceEvent:(2) GetParam returns ndserr = 1 slpLifetime = 300
[D 2014-01-16 15:35:23] RefreshSLPAdvertisement: server: PROVO-CLUSTER-SHARE-SERVER
[D 2014-01-16 15:35:23] AdvertiseVirtualServer: AdvertiseThruSLP start=1 name=PROVO-CLUSTER-SHARE-SERVER ipaddr=151.155.133.205 retry=0
Looking at the service registrations from an NDS perspective can be done by using ndstrace and using the TIME, TAGS, and SADV flags. The output would look something like this:
1276598592 SADV: [2010/08/11 15:34:34.6] Start advertising Bindery (edirdt-50)
via SLP succeeded.
1276598592 SADV: [2010/08/11 15:34:34.6] Start advertising NDAP (.LUM-PS.) via
SLP succeeded.
1278703936 SADV: [2010/08/11 15:35:34.2] Start advertising LDAP
(164.99.88.106:389.) via SLP succeeded.
1278703936 SADV: [2010/08/11 15:35:34.2] Start advertising Bindery (edirdt-50)
via SLP succeeded.
1278703936 SADV: [2010/08/11 15:35:34.2] Start advertising NDAP (.LUM-PS.) via
SLP succeeded.