SUSE Conversations


SLP updates for Open Enterprise Server 2 / SLES10



By: gldavis

July 23, 2010 2:39 am

Reads:241

Comments:8

Rating:0

Many customers have been asking for SLP services to be more persistent on the Linux platform. This feature has now shipped in a SLES10SP3 patch, and the new functionality will be fully supported with OES2SP3 slated to ship before year end.

In NetWare the SLP agent on the server would look in eDirectory for SLP entries, thus the services were always available even if the SLP service had to be restarted or the server rebooted.

With openSLP on linux the services were stored in memory, and thus had to be “rediscovered” when the SLP service was shutdown for any reason. In large environments with hundreds or thousands of SLP entries, it could take quite some time for these services to be rediscovered.

With a new patch available in SLES10SP3, the services can now cached locally on the server in a file (through new entries added to the slp.conf file), and the services can be synchronized between SLP Directory Agents.

With OES2SP3 (currently in private beta), the caching feature will be turned on by default as part of the install as well as the code will have gone through full integration testing with the OES platform.

For more information on what is coming see the attached slide deck.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Tags:
Categories: Open Enterprise Server on SLES, SUSE Linux Enterprise Server, Technical Solutions

Disclaimer: As with everything else at SUSE Conversations, this content is definitely not supported by SUSE (so don't even think of calling Support if you try something and it blows up).  It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.

8 Comments

  1. By:kjhurni

    For posting this (there was another thread going about resolving some of the issues).

  2. By:gmarsh

    1. The SLP documentation in SLES10, eDir88, and OES2 is still woefully inadequate and needs to be updated to make it easier to configure and to understand the dependencies between the various parameters in the .conf file, and also to describe the DA backup and sync options which are new. Also need to consider SLP design real-world scenarios and incorporate them into the documentation, not just TIDs or user-contributed coolsolutions.

    2. I assume that DASyncReg and DABackup are only useful if isDA=true, correct?

    3. If DASyncReg=true then what do we put in the DAAddresses. Do we put only the “remote” DA’s or do we also put the “local” DA as well as the “remote” DA’s. What is the behaviour of YaST if DASyncReg is checked – will it allow me to add addresses in the greyed-out box “Configured SLP DA’s”? And presumably those addresses are simply added to the DAAddresses in the config file? This is not shown in the presentation file.

    4. Thanks for implementing this feature. After all this time, it seems that OpenSLP is starting to catch up with NWSLP in terms of features and functionality.

  3. By:sveld

    2) correct

    3) DAAddresses -only- contains remote DA’s. The slp.isDA=true takes care of the local DA.

    # /etc/slp.conf DA1 xx.xx.xx.xx
    net.slp.DAAddresses = yy.yy.yy.yy
    net.slp.useScopes = myscope
    net.slp.isDA = true
    net.isBroadcastOnly = false
    net.slp.isDABackup = true
    net.slp.DABackupInterval = 900
    net.slp.DASyncReg = true

    # /etc/slp.conf DA2 yy.yy.yy.yy
    net.slp.DAAddresses = xx.xx.xx.xx
    net.slp.useScopes = myscope
    net.slp.isDA = true
    net.isBroadcastOnly = false
    net.slp.isDABackup = true
    net.slp.DABackupInterval = 900
    net.slp.DASyncReg = true

    4) Works great for me so far.

  4. By:rogerithomas1

    Does this mean that OES 2 SP3 will only be using this local machine file rather than the NW solution of a fully distributed backend based on eDir.

    I also second the comments on providing more detail docs on SLP configuration.

    Thanks

    Roger

  5. By:sveld

    SLES10 SP3 SLP updates will have full backup functionality and distribution to other DA’s. like you have on NetWare, but it’s -not- integrated in eDirectory anymore. This means that the new SLP functions on SLES can still be used even if one does not have eDirectory at all.

    eDirectory integration for SLP on NetWare had it’s downsides as well; dependency on eDirectory is one, but more important is you needed to replicate the SLP partition to all DA’s which has impact on your eDir design which can be challenging in larger environments, then there’s the sync overhead in eDir/clashes when SA’s register on multiple DA’s – in the end it worked but it’s not perfect by all means or better then the solution now developed for SLES. I think the update for SLES as there now is just mean and lean and does the job we want it to do.

  6. By:gmarsh

    I haven’t tested yet, but this patch is in the channel:

    Description

    The openslp daemon could run into an endless loop when receiving specially crafted packets (CVE-2010-3609). This has been fixed.

    Additionally the following non-security bugs were fixed:

    * This openSLP update extends the net.slp.isDABackup mechanism introduced with the previous update by a new configuration option “DABackupLocalReg”.
    * This option tells the openslp server to also backup local registrations (bnc#597215).
    * In addition, standard compliance was fixed by stripping leading and trailing white spaces when doing string comparisons of scopes.

    Security Issue reference:

    * CVE-2010-3609

  7. By:gmarsh

    I should add the following clarifications:

    1. The new parameter for local DA registration persistence is:
    ; net.slp.DABackupLocalReg = true
    However, it defaults to false. You need to uncomment the line to enable it.

    2. The new parameters relating to persistence will not be added to your existing slp.conf if you have modified it, which will usually be the case. The new parameters will exist in slp.conf.rpmnew after applying the updated slp package.

    3. My normal practice is to manually edit the slp.conf file rather than use the Yast configuration module owing to issues with the latter such as, but not limited to: (a) the new persistence parameters are not listed in Expert mode; (b) if one species “Becomes a DA server”, one cannot also specify the remote DA Addresses in order to have the local server register its services with other DA servers; (c) Yast lower-cases all the parameters. Although slp is supposed to be case-insensitive, the parameters in the config file follow a mixed-case convention. Why mess it up in Yast? The Yast module should (i) respect the case of the original parameters and (ii) allow for all the settings in Expert mode and (iii) allow a server to be both a DA and for entries to be added to DAAddresses.

  8. By:ChrisRandles

    Just an FYI. The updates to SLP were added to the OES2 SP2 channel as well.

Comment

RSS