eDirectory 9.2.8 SLES 12 sp5 to SLES 15 sp6 in-place upgrade

Does anyone have experience with an in-place upgrade eDirectory from SLES12 SP5 to SLES15 SP6?

We have VM servers, 3 in each of 4 trees, in production and also in the test environment.

We are using eDirectory 9.2.8 as LDAP server and IDM 4.8.7.

One eDirectory server is running on SLES15 SP6 with a fresh install. It works perfectly.

I want to avoid installing new VMs, it would be about 20 servers.

I have not found any references to recommendations and no-goes. Every information is helpful

Thank you very much,
Ute E.

  • 0  

    Question: do you not have a actual OES-Server that hold the master eDir? and better two oes-server for a replica!

    OES 24.3 is the actual version based on sles15sp4, oes24.4 is coming the next quartal

    not all services / programs are validated for sles15sp6 and sles12sp5 is for me obsolete, but used as os for many ot-applications as zcm, zsd, filr, aa, etc...

    this may be a wonder to had all on one os-version by ot, may be a dream from me!

  • 0 in reply to   

    No we don't use OES, just SLES

  • 0   in reply to 

    Why? What is the reason? i come from novell netware in 1985, had migrate to oes11 near 2010 and had migrated to all version, now on 24.3. It is very stable and any "more features" that sles not had.

    Now i am retired and i continue to follow the development and participate on many beta products, i will not missed all this possiblities over a only sles-server!

    It is not a critic, i ask for understanding other minds and experience!

    great regards

  • 0   in reply to   

    Hello Claude,

    there are cases where a pure eDir is required in the IAM/IDM area. A core OS without the OES baggage makes sense here. In the field, I have some pure SLES systems with eDir that are even masters because I can do things with them where OES Core is in the background. A SLES is set up very quickly with Ranger or similar from a script as a minimal OS and setting up eDir is a case of less than 5 minutes if you know what you are doing.
    Geroge

    “You can't teach a person anything, you can only help them to discover it within themselves.” Galileo Galilei

  • 0  

    Hi, a2828au

    It is possible to run more than one eDir instance on a SLES system. If I run into such a situation in the field, I move the DIB with everything that goes with it to a system on which an eDir is already running. Of course there is more to do than just moving the DIB from a to b. Secondary IP, additional names to the corresponding IP etc. I think anyone who runs eDir on SLES knows what is meant here.

    After the eDir has been moved, I stop the corresponding services and prevent the services from starting after a restart. Because the NDS of the system in question is running on another server, the NDS is OK. Now either in-place upgrade or another method can be selected. The way backwards of the DIB is basically a disaster recovery process from a system that had a crashed NDS. The procedure even works for master and for BaumCA carriers. There are many other ways that are elegant, here is a first approach for further procedures,
    George

    “You can't teach a person anything, you can only help them to discover it within themselves.” Galileo Galilei

  • 0   in reply to   

    may be, Georg!

    OES-Installation take not longer time as SLES-Installation and the configuration of supplement oes services is very easy.

    But i want to anderstand the motivation of a2822au! Each customer has his own regards of a stable system!

  • 0   in reply to   

    Claude, in customer installations in which Proxmox, KVM or OpenStack is running, I can pull up a ready-made SLES with all the necessary patches from an image within 3-4 minutes using Scipt - all the parameters that a system must have are correct. Network, name, firewall, driver, time source and more. Even with the help of an install server it is possible to have a SLES faster than an OES.

    George

    “You can't teach a person anything, you can only help them to discover it within themselves.” Galileo Galilei

  • 0   in reply to   

    I can think of a couple of reasons

    - licenses

    - security in depth: fewer services on a machine means smaller attack surface

    - skills: you'd need someone who knows OES in addition to standard Linux knowledge 

  • 0   in reply to   

    In many customer installations, there are SLES systems on which an eDir has been set up for precisely the reasons listed here. Outside I have large GroupWise installations running and in these systems I specifically go to a SLES/eDir for LDAP because very excessive LDAP requests can be handled better. Of course, this also applies to the other OT products that use LDAP. Other reasons are less workload, better security because there are fewer services and, above all, disaster recovery is much easier than with an OES system. Thanks for the valuable reminder of the reasons in the post

    “You can't teach a person anything, you can only help them to discover it within themselves.” Galileo Galilei

  • 0  

    Hi a2822au,

    We usually do migrations because that is what most of our customers (or their infrastructure providers) prefer. Especially on Linux, it is not a big deal if you have a good plan and understanding of the components involved.

    But at least as far as the SLES documentation goes, it should be possible to do an in-place upgrade:

    documentation.suse.com/.../cha-upgrade-paths.html

    Since you are working with VMs, you should be able to simply back up one of the boxes in the test stage an give it a try.

    Best regards,
    Philipp