Cool Solutions

OPEN CALL: How to Fluently Migrate SLP Services from NetWare to OES2?



September 22, 2009 11:32 am






When OES2 was released, NTS told us that it might be better to keep the SLP DAs on NetWare – which we did, but now we finally need to move those.

As I have understood there is still no Novell SLP on OES2, “only” Open SLP?

How do we make fault tolerant, as we cannot have such single point of failure?

Currently we have 2 SLP DA and namedscope.

30 servers and 3000 workstations are using it, with static scope and static DA settings.

Any experiences on this?


Sami Kapanen

If you have any experiences to share on this topic, post your comments below.

0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this post.

Categories: Uncategorized


Disclaimer: This content is not supported by Micro Focus. 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 it thoroughly before using it in a production environment.


  1. By:davidkrotil

    this is last thing I miss, when I migrate my customers to OES2 Linux. I have posted my request on please do it too. Why ? Now you can´t make SLP service fault tolerant and quick as you could on NetWare. There isn´t possibility to cluster OpenSLP, while it response only on first bound network interface. Second bad thing is there isn´t any cache of discovered services, when you reload your OpenSLP daemon, it is blind. All services are kept in memory, you can wait many seconds to minutes or make manual registration of services, how handy.

  2. By:khurni

    Currently there’s no real way to do this. I mean, you can have two OpenSLP DA running. The problem is that whenever the server restarts, it clears out its memory cache, so that when it comes back up the cache is empty and it has to rebuild it. It can take upwards of 3 hours to rebuild this list. In the meantime, your pc’s (if they are coded to use THAT particular SLP DA) will get “no” results and fail to resolve.

    IF you are lucky enough to give out the IP of your DA via DHCP you could change all your DHCP servers to then give out the IP of the DA that hasn’t been rebooted.

    Supposedly though, Novell is investigating a workaround. I would submit an SR, as well as an enhancement request so that you can be notified if something comes out. Hopefully soon!

  3. By:jbeeson

    So from what I’ve read moving to OpenSLP on thr Linux platorm looks like a bit of a backwards step as I found it very complete with is Netware version. You have to re-boot a server to refresh SLP data as restart SLP daemon will not do that. Joys of open source?

  4. By:jlodom

    My understanding is that OpenSLP is more compliant to the SLP spec than the Netware version. I can attest to this, given some problems which MacOS 9.x used to have with the Netware DA (and Apple invented SLP, eventually abandoning it for Bonjour / ZeroConf). This is perhaps why Novell is not porting the Netware code.

    Given that, I could really use an eDirectory-integrated OpenSLP variant a la the freeRadius and Kerberos support that is already in the tree. Your point about clustering is also well-taken.

    OpenSLP might be more stable, however, given that services on Linux rarely take down the entire server when they explode, and can be restarted without a reboot. So, on a Linux server you may never have to stop the OpenSLP process even if other services are having issues.

    It sounds like in the short-term you’re going to want to create a virtual Netware cluster (maybe using XEN?) for the first DA for fault-tolerance, and then perhaps make your second DA a Linux box with OpenSLP.

    Sorry I’m not being more directly helpful, but these are the factors that I’m considering in my own migration.

  5. By:skapanen

    Thanks for the comments,
    this seems to be (still) a common issue for people moving from NW to OES2, so it isn’t just me who has issues with this..

    If you have good experiences about migrating SLP services to OES2, let us know.

    If you feel that the OpenSLP that is offered with OES2 is not a good replacement for NW SLP, let us and Novell know it too! (reply here and make enhancement request.)


  6. By:ashmoore

    The reason you don’t hear about good experiences about moving from NW-SLP to OpenSLP is that there are none, its all about what you lose.
    People are hanging on to Netware SLP because the OpenSLP solution doesn’t work and is abandonware.
    Wake up and listen to your customers Novell.

    • By:jlodom

      Currently the client pieces of OpenSLP ship in a number of Linux distros and, perhaps more interestingly, every copy of Mac OS X. It is in heavy use, and the client end works well (much better than Apple’s own implementation), so perhaps some of its stagnation is due to the fact that the client piece seems largely complete and “just works.”

      I notice that the listed maintainer of OpenSLP is a Novell employee. That seems to indicate that Novell will be able to do what needs to be done with it. I do think it needs an eDirectory-integrated data store, but I’d hardly describe it as “Abandonware.” Most likely improvements to it will come in the next couple of OES releases — perhaps OES 3?

      • By:kjhurni

        The main issue (and the original title of this Open Call) is regarding migrating SLP/DA from NetWare to OES2.

        The main issue is with the OpenSLP DA lack of features compared to NetWare SLPDA.

        You are correct that a Novell employee is listed as the owner, but I believe if you search the support forums you’ll find some interesting information regarding that as well (ie, lack of resources, etc.). Hence the term “abandonware”.

        At the main heart of the issue is that if ndsd is ever restarted on an OpenSLP DA, the list of services is only stored in memory, and thus, will be lost.

        So when the OpenSLP DA (technically ndsd/eDirectory) is restarted, the memory cache is cleared, and you end up with a DA that has nothing in its services list.

        This does affect clients because when a client PC goes to request a service from that DA, it stands a good chance of not finding the service.

        To further add insult to injury, with eDir 8.8.x, the services (bindery.novell) only register every hour (by default). This means your OpenSLP DA can be “empty” or not fully populated for up to an hour.

        In reality, I’ve seen or network take 3.5 hours for the bindery.novell list to fully populate on the DA. This wreaks havoc on the client pc’s, as well as our Citrix servers with the Novell Client on them (sorry you cannot login or access your work right now, you have to wait several hours).

        That is hardly a smooth transition from NetWare to OES2 in the case of SLPDA -> OpenSLP DA.

        That being said, I believe Novell is working on some short-term workaround to alleviate the problem, but I do not know what the ETA is yet. I would urge everyone with this issue to open an SR AND submit an enhancement request:

  7. By:ashmoore

    You miss the point though. You are taking OpenSLP in isolation – not compared to Netware SLP.
    I am fully aware that OpenSLP works, indeed “just works” is a good way of putting it.
    It “only just” works, meaning it has minimal functionality.
    It is well documented how much is missing in OpenSLP compared to the feature set of SLP in Netware.
    Most of us here are fed up of waiting just in case Novell might actually fix it in OES3 – it was supposed to be fixed by OES2.

    As for it being abandonware….
    The newest item in the tracker is from 2004.
    The last closed bug is from 2005.
    OpenSLP V2 has not made it past beta since April 2008 and the last stable release was in 2005.
    Sure looks like abandonware from here

  8. By:stideswe


    I wrote a Cool Solution article about it ….

    This works extremely well (i.e. it has never gone wrong). It is mostly automated and contains very simple components that are easy to troubleshoot and maintain. It’s all command-line too which makes it doubly nice.

    We have used this since early 2007 and it works very well indeed. It is as applicable to OES1 as it is to OES2.


  9. By:Sgermanides

    I checked with the project manager, and it looks like what we have in the works is a “cool tool” or “technology preview” to improve your experience with OpenSLP. That is slated for the Sp2 timeframe, with better support in Ponderosa.

    And thanks to Simon Flood who’s shared his best practice with the thread. I love reading the threads to see the variety of experiences.


  10. By:ashmoore

    I give up,
    Yes Simon, only you are missing something that everyone else here can see, how much more detail do you want, just read this thread and the comments on your cool solution.
    Frankly, calling a customer with a problem a “knocker” is a telling view of why you see the cool solution as a “fix”.
    I’m glad it works for you, but the rest of us don’t want to have to stick all of that cool solution spit, string and duct tape to replace something that used to be click and go – and should still be.

    If it is such a great solution why is it not in the product already and why are Novell advising customers to keep Netware SLP?

    • By:stideswe

      I read back through all the posts again and it seems that the main issue people have with OpenSLP is the absence of a persistent cache and the absence of any replication of service information. That’s what my Cool Solutions article addresses and now I have the best of both worlds. And we don’t have any more NetWare servers – praise be!!!

      It would be good if Novell did an eDirectory integrated SLPDA but I believe they have far more pressing matters to attend to that their developers should be focusing on.

      I don’t regard my solution as “spit, string and duct tape”: it has been rock solid and worked brilliantly for 2-3 years now without a single problem. By comparison much of the product that we have deployed and which was written by Novell developers has been flakey and unreliable and and absolute nightmare to look after.

      You say you want something to be “click and go” but this is running on Linux now and that attitude is missing the point. Linux/Open Source offers so much more in the way of possibilities but sometimes it requires a bit more of the administrator in terms of intellectual input. I don’t see that as a bad thing – it keeps the job from being very dull. If you want “click and go” why don’t you migrate to Microsoft and you can click away to your heart’s content – but don’t be too surprised if you find it terribly boring!!!


      • By:nlandas

        When Novell acquired SuSe it acquired the Linux disease with it. The pervasive attitude that a good solution has to be complex to configure in order to be flexible. The attitude that anyone who doesn’t have the time to waste in manually setting up and configuring systems in poorly documented text files, is a noob and should just go RTFM.

        Now with all due respect, I know you have been nice enough to create a Cool Solution to work around some of the limitation of the default implementation of OpenSLP. So it seems like it’s not the full normal Linux treatment because you have at least documented a work around to the base implementation.

        Service Location is at the core of what a network does. This shouldn’t be some afterthought Open Source solution that “just works” as long you spend a lot of time tweaking it, with a work around. This should have a persistent cache that is stored in eDirectory (a self replicating, partitionable database) and straight forward management tools. The Linux camp at Novell seems to be doing everything it can to ignore eDirectory and promote the traditional, stick it in a text file mentality.

        “I don’t see that as a bad thing – it keeps the job from being very dull. If you want “click and go” why don’t you migrate to Microsoft and you can click away to your heart’s content – but don’t be too surprised if you find it terribly boring!!!”

        From being dull, you have got to be kidding? Nothing is more dull than frogging around with text files and cron jobs to make something work that should work out of the box with little setup. Something that should have some form of simple management tool whether it’s GUI or not. Something that should be set up out of the box without too much effort. Like Novell SLP, which Novell owns the code for.

        To say that someone who wants OpenSLP to have the same feature set as Novell SLP should just go and use Microsoft is ignorant. This attitude is why Open Source isn’t adopted to the desktop and Enterprise more readily. Where is the advantage to a flexible solution if managing takes significantly more effort?

        “sometimes it requires a bit more of the administrator in terms of intellectual input.”

        Ooops maybe I was wrong Simon, this sounds just like many other arrogant Linux users, if you don’t want to take the time to learn the minutia of a configuration for every network service you run you lack intellectual input. This is exactly what I’m talking about. Tthe Linux community should drop the, well it works, who cares if it’s hard to manage and start including easy management in the development process. If a network service is well implemented and stable, there should be no need for even a genius level NetAdmin to known the minutia of how it can be configured, unless he is troubleshooting an extraordinary issue. Novell SLP has been very easy to configure and troubleshoot. In other words, it’s easy to manage and stable.

        One of the things that drew me to SuSe was YaST and the ease of configuring basic services that typically required manually editing of text files. There is no need for that and it doesn’t make you stupid if you use YaSt to do basic configuration/maintenance tasks. Its like saying, why use a wheelbarrow to move those rocks when you can move them one by one and really experience each rock in detail. Knowing the rocks in details isn’t germane to the task of getting the rocks from point A to point B. Just as knowing the details of a configuration file does little to increase your knowledge of what a service provides or the process by which it provides it.

        I’m more than willing to move to OpenSLP, I’ve been readily migrating my other services to Novell OES2 on Suse but things I want in OpenSLP are –
        A persistent cache stored in eDirectory without the need for separate replication process.
        Allow for a single scope to be serviced by multiple DAs.
        Allow for management via a simple interface in say, oh I don’t know, YaST.

        Things others might want –
        Let the client query a secondary DA should the first not know about the service. (I believe this was a problem with OpenSLP and the Novell Client. The last I checked.)

        These hardly seem like major requests in a Service Location system. I for one sincerely hope that Novell’s excellent tradition of offering robust secure network systems, that are easy to properly manage, can win out over this elitist Linux attitude of power/flexibility must equal management complexity.

  11. By:stideswe

    I can see a lot of knockers out there complaining (and, believe me, Novell and complaining and me are very common themes in my daily life). But I cannot understand what it is that people are complaining about here?

    What, in detail, are the problems you experience with OpenSLP? To me it just seems to work. And let’s face it, SLP is important to get right to avoid really bad stuff from occurring but once the basics are set up it doesn’t really make a lot of difference to end-users’ productivity.

    Am I missing something? NetWare SLP was convenient and so on but things like ActiveSync, the GroupWise client, Outlook connector are far more painful issues to deal with than SLP surely?


  12. By:davidkrotil

    Simon, it´s nice workaround, but SLP from its nature is dynamic, you degrade it to some static “it´s working in my environment” service. I think there isn´t technical problem, but some political. Some people in Novell think, that current functionality of OpenSLP on OES2 is OK and some people not. When we make pressure and if Novell is customer need oriented company, than they will change this and make this work as in NetWare environment.

    Just my 5 cents.

  13. By:ashmoore

    Sorry Simon, you totally miss the point.
    We are running businesses here, not having religious debates about open and closed source.
    My decisions are based on business needs – not my need to feel good about a technical solution. I have enough of those to sort out with deliberately adding more, I don’t need to make Linux more difficult to use just to make my life interesting.

    Linux is now in the real world of big businesses and needs to grow up and play with the big boys or get back into the closet. Most modern Linux developers and admins already recognize that. The ones that do not will get left behind or marginalized.

    I am sure Novell would love your thought that customers who want an easy to use system should migrate to Microsoft – that is a great business case for them, to cease to exist.

    I am now going to get back to bugging Novell to make OES the best it can be and compete in the real world because I want Novell to succeed.

    Thank you Sophia for the news that this is being addressed and not ignored, many of us are no doubt looking forward to trying it out.

    • By:stideswe

      Hello, we clearly see things from different perspectives.

      “This is not religion” – no it’s much more serious than that!!!!

      My point about Microsoft being click and go was more intended to highlight that whilst it is easy it is also hugely inflexible, crude and limiting.

      I am not running a business like you, I am purely working in a technical capacity. The system is there for my own amusement and the end-users are just an irritating nuisance – the system would be so much better if those idiots were not using it!!!!

      I guess we’ll just have to agree to disagree.


  14. By:kjhurni

    Simon did refer to a nice article he took the time to write for a potential workaround.

    I personally prefer Simon’s approach vs. the Novell TID “official” approach (essentially both are doing the same thing, but Simon has a nicer way of automating the input of the file, whereas Novell’s TID has you do this manually–which is very time consuming).

    I would still urge everyone who wants this to change to continue to open an SR (if they have maintenance) and to submit an enhancement request.

  15. By:davidkrotil

    Sophia has revealed something which is true, Novell is listening and see that current situation is not good. I got this weekend “official” information, that something is prepared for OES2 SP2 and full port of NetWare SLP functionality is planed for OES3. I hope, that I don´t revealed something, what I shouldn´t, but SP2 for OES2 is relative near, than I think is good to now, that OpenSLP ISN´T abadonware and we will get some real proof of that in 2 – 3 months.

  16. By:skapanen

    I browsed through the SP2 beta docs and didn’t see anything mentioned about SLP changes?

    • By:dkrotil

      nothing changed in OES2 SP2. Next releases are OES2 SP3 and OES3 ( ? ). maybe there will be this problem solved. I´m now battling with OpenSLP on OES2 clusters and don´t understand, why someone can think, that OpenSLP is working replacement for NetWare SLP.

      • By:kjhurni

        You are correct. The upcoming fix was not in SP2, and I’ve not heard or been able to get anyone at Novell to respond to me either, so that doesn’t bode well.

        There IS a bug with OpenSLP DA and I don’t know if the patch is in the channel yet. We received an FTF patch from Novell in order to get NetWare SLP DA to coexist with OpenSLP DA, contrary to the NTS person who wrote that ‘Myths” TID about OpenSLP.

  17. By:ashmoore

    There is a Brainshare session dedicated to SLP, so I have added it as one of my high priority sessions.
    Obviously Novell are listening – I am hopeful that it is something other than another workaround. But dedicating Brainshare resources is a valuable resource to add.

    • By:skapanen

      Hopefully this session will give some ideas how to solve the issue of OES2 SLP migrations.. keep us posted!
      We have project starting to retire Netware clusters, and that would retire the SLP DA’s too.

  18. By:jbeeson

    Well I could not justify the cost of Brainshare this year. Do let us know what you find out in the session and perhaps bend someones ear about it as well.

    Just as well we keep on Netware server running SLP that does work properly.

  19. By:leraly

    Latest OpenHorizons Magazine has an article of Jason Taylor about the OES roadmap.

    In the part where he speaks about OES2 SP3 he says the following:

    Finally, Novell will be adding an SLP Directory Agent update for OES2 SP3.
    This update will allow the Open SLP Directory Agent to store service information within eDirectory. This provides the same level of capability that has been available for Netware 6.5 for some time.

    Looks promising. Reading this made my day I hope It can also make your day 😉

  20. By:leraly

    @thsundel: That specific version of the magazine will be distributed during Brainshare (Maybe it will be online afterwards)

    @ecyoung: IIRC SLES11 will be the base of OES3 (which is due for 2011)
    In the same release (OES2) they will never do such a big upgrade (e.g SLES11 no longer has evms which is critical to NSS,…)

    • By:nlandas

      @thsundel – Wow, I didn’t catch the SLES 11 didn’t support evms. I can’t be without NSS support – I for one want to stay with Novell File Access Rights over the simplistic Linux file rights. I also want them tied directly to eDirectory for easy assignment. I wonder what Novell is planning now.

      @Everyone else –
      I have submitted a Feature Request for OpenSLP to support eDirectory. This is holding up our migration off of Netware which includes an extremely large geographic area of NYS and multiple school districts. We can’t move to OpenSLP as implemented it isn’t reliable enough for a large dynamic environment. The data should have at least been automatically cached into a file instead of only memory. Of course once you have a distributed X500 database, why would you store any global server information anywhere else? DHCP, DNS, SLP, etc. data should all be stored in eDirectory for easy replication to handle failures.

      Anyone know when OES3 is due out? I’m hoping it will be in there. My Netware is running on older hardware that I’d like to eliminate.

  21. By:skapanen

    ofcoz NSS is staying!
    It is just the EVMS part that is going away – and that’s just good. Luckily we have been able to avoid evms, always used separate logical disk for NSS with OES2 installations.

    OES2 SP3 brings new functionality for SLP, look at the BrainShare slides..

  22. By:leraly

    OES will continue to have NSS so no need to be afraid. Novell will just replace the evms part inside NSS with something else. 2 Years ago I discussed this with one of the product managers during Brainshare and they were already thinking about it back then.

  23. By:nlandas

    That’s a relief – So that’s probably why the delay on OES for SLES 11. They are working on not only testing and certifying all of OES but creating a new NSS implementation.

    Anyone have any links to details on the new SLP setup in OES2 SP3?

  24. By:nlandas

    OpenSLP is not an option and we are stuck with Netware running on older server hardware until Novell addresses the issue.

    I hope they either extend OpenSLP to support eDirectory or just port Novell SLP which has been stable and robust for us for years.

    I’ve submitted multiple feature requests on this. The first was
    Integreate OpenSLP into eDirectory 16 May 2009 Open Enterprise Server

    The response was – Duplicate (So I wonder how long this Enhancement request has been in from someone else.)

  25. By:kjhurni

    At Brainshare I was told that in OES2 SP3 (still based on SLES 10 kernel vs. SLES 11) will have an eDirectory enabled OpenSLP.

  26. By:ashmoore

    For NSS on OES3 – SLES11 drops evms and only uses lvm, so they have to migrate to that. They have so much invested in NSS that it will not likely be going away.
    They were also talking about future NSS improvements like breaking the 2Tb partition or the 8Tb pool barriers and other limitations which sounds rather encouraging.

    I attended the four hour OpenSLP session, it was interesting that the angle being taken was that Netware was none standard SLP, whereas OpenSLP was standards based – and that being standards based was more important than functionality.
    However OES2-SP3 is supposed to have some form of edirectory enablement, but no implementation detail where forthcoming, so it was difficult to form an opinion on it.

    It was very encouraging that Novell seems to have turned the corner after going totally open source focused to the apparent exclusion of their own technologies (like edir).
    I am glad to see that start to change and see Novell products that leverage their own tech.

  27. By:nlandas

    Please don’t take this the wrong way because those posting here have gone out of their way to be helpful but I’m really stuck on my migration and it’s getting frustrating. I am past the point where I’d like to retire the old Netware server that was acting as my SLPDA and migrate to using SLP my new SLES OES2 server. I can’t do this until SLP on SLES OES2 supports some form of eDirectory integration.

    I hear above that OES2-SP3 might have this. Can someone from Novell confirm this for certain and let us know roughly when a stable SP3 might be expected?

    As I said, I’d hate to have to migrate SLP to my last remaining Netware server only to then have to remigrate it to SLES OES2 when its SLP supports eDirectory. As an end user, I could care less that Novell SLP isn’t “standards” based, it works and it uses eDir as a repository for services. I am not alone in wanting an eDirectory enabled SLP implementation.

    This is the LAST service keeping us on Netware and it’s making me rely on servers that are having hardware issues that I really need to retire. I would think Novell would want us to be able to use SLES OES2 fully without the need for Netware?

    Please Novell, can you confirm the game plan here?

  28. By:jbeeson

    This was first raised in September last year and from what I remember no one from Novell has confirmed or denied anything on SLP and Linux. There was talk of something at Brainshare but no one has shared anything.

    I do read that the latest beta of OES SP3 will haved some sort of EDir integration or retension as they call it.

    Is it just a taboo subject or can no one comment on it?

    • By:stideswe

      This is a little off topic but …

      With the Novell Client for Windows 7 we have found that, apparently, there is no “IP Costing” feature in the Novell Client (as there was in Windows XP). As a result, if the clients are not configured with a preferred server (as well as tree and context) then you will end up logging in against the first replica listed in the replica ring (as served up by SLP). So if you roll out Windows 7 you may end up with your clients all trying to log in against replicas over WAN links. My company (in Australia) has 2-4Mbps WAN links and so that behaviour would cause some significant impact. I know it’s a little off topic but it is something to watch out for!


  29. By:kjhurni

    There was a presentation at Brainshare (CL115) and the slides can be obtained from the Brainshare Amsterdam site. Anyway, the slides, according to Novell, says that an eDir SLP version will be in OES2 SP3.

    SP3 was (maybe still is) accepting AUTHORIZED beta participants. Legally anyone in the beta program cannot comment on what it may contain.

    I spoke to someone at Brainshare as well and they confirmed what the CL115 slide shows that there will be an “edir” enabled SLPDA for OES2 in SP3.

    • By:jbeeson

      Well that’s fine and some of us didn’t go to Brainshare.

      As I said before why can’t anyone from Novell make an official comment about it. We get more information from the GroupWise group on forthcoming features and they do a good job on promoting that. So why can’t someone from the OES2 team be more forthcoming. We don’t have to time to go a beta program at the moment.

    • By:nlandas

      Thanks kjhurni – It’s good to hear others with some confirmation that something should be in OES2 SP3.

      I do find it very disturbing that Novell has been so silent on SLP. It’s not like Service Location is critical to a network or anything. OpenSLP won’t work for us, I can’t have services be unavailable when I need to restart SLP for some reason.

      I for one would have thought that SLP would have been the first “service” to receive Novell’s attention and integration with eDirectory. Considering the age of Netware 6.5 and it’s end up official support in 2012 – Self support in 2015, I’d hope that Novell would leave customers a few years to migrate to SLES OES2. I suspect that some may have decided to not even start until SLP was eDir enabled.

  30. By:skapanen

    I have seen some SP3 slides too, but I understood that it would save SLP info to a local file, instead of eDir?
    anyway, it should be better than the current..

  31. By:davidkrotil

    Current version of OpenSLP saves SLP info to a local file , SP3 should eDir enabled.

    • By:nlandas

      Thanks davidkrotil. That is a huge step in the right direction. At least if registrations are cached to disk then when you have to reload the DA it will know about existing ones quickly. Not as robust as storing them in the replicated X500 directory but makes me more comfortable moving from Netware SLP.

      I’ll be doing some thinking today.

      I really appreciate that link, I hadn’t seen it.

    • By:jbeeson

      That’s great news.

      Is there any links an documentation for the options for OpenSLP as there is not alot mentioned in the uppdate?

  32. By:davidkrotil

    Make diff /etc/slp.conf /etc/slp.conf.rpmsave and you will get, beside your changes against defaults, two sections, which are new. There is info, what both new switches do.

    • By:gmarsh

      Just wish to comment that, in order to change the advertising interval, you can do so on eDir 8.8.5 with the command:

      ndsconfig set n4u.nds.advertise-life-time=540

      The above example sets it to 9 minutes just like it was in eDir 8.7.3

      Search the KB for the above parameter, also search for RNRAdvertise and you will find more information. It seems that the default value is still one hour, but at least it can be configured since 8.8.5; it was not configurable prior to 8.8.5.

  33. By:mbeauchamp

    Found this article that might be of interest to many of you.


    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.

    There is a presentation on this link check it out.

  34. By:nlandas

    Since the last post on this is from 2010, I am thinking that the persistent cache to file and the ability for DAs to sync services with each other has made most admins happy. We are looking at pulling the trigger in a couple months and retiring one of our Netware SLPDAs, which will put us pretty much fully on OES2 on our main campus.

    Does anyone have any gotchas I should be on the lookout for. My OpenSLP DA seems to be caching to a file successfully. All of our remaining WinXP clients are running 4.91sp5. Anything else that others have seen that I could make changes to prevent from occurring?


    • By:kjhurni

      We ran into a bug maybe 4 months ago where the OpenSLP DA would either de-register services or not register them at all, thus causing all sorts of problems.

      There’s a patch (since released in the patch channel) to address this, but has to be applied to all your OES servers.

      We worked around it by re-configuring the Novell Client to use DNS as well for name resolution (essentially bypassing the SLP queries) as it was easier and less intrusive than putting an FTF (at the time) on all our servers.