Serious issues upgrading to OES2018 around Common Proxy



Micro Focus seriously needs to look at the upgrade scripts in inplace OES2018SP1 updates. I'm currently busy doing lots of OES2015SP1 to OES2018SP1 updates, and the *vast* majoriy fails in oe way or the other, but every single time the core failure reason are the various service proxies, aka most of the time the common proxy, coupled with the lack of error handling in these scripts.

What I'm seeing:

1. DNS and DHCP if installed are disabled after the update. Trying to enable or manuall start them fails because they can't login to eDirectory to access their information.
Remedy: Often it is enough to run the " (which has it's own set of issues I posted about here: /collaboration/oes/f/oes_discussions/190966/move_to_common_proxy-sh-bug).
However, sometimes that doesn't fix it, in that case the common proxy repair script found here: /collaboration/oes/w/oes_tips/21913/common-proxy-repair-script-for-oes2018-oes2015-and-oes11
often helps. The issue seems to be that the common proxy password gets lost in the process somehow. When you manually attempt to reconfigure DNS or DHCP via Yast, you'll find that the Common Proxy password is empty and you can't proceed without it.

2. The upgrade hanging at "Saving Novell Cifs Services Configuration" forever. It will never recover from here. In the background, you can see Cifs trying to start over and over once per minute, but never susscesful. This must somehow be related to ncs, as in Y2log the last activity shown was:

[Ruby] modules/NovellUtils.rb:2145 Moving novell-ncs service to common proxy

The only way (I have found) out of here is to forcefull kill all y2start threads, and then manually fix the common proxy (again). Here only the common proxy repair script as per above helps.

Needless to say that all services were working flawlessly before the upgrade, and the common proxy was set for all of them (e.g, running the "" script before the update stated that nothing needs to be done".

  • Those are the common problems. Others include sorting out which IP numbers to use when there is more than one available, and of course Common Proxy problems. A list of these, with my experiences, have been communicated to the OES team earlier this summer, and they are said to be working on them.

    A consequence of our failed attempts can be an accumulation of eDirectory Dead Obits (talking between servers in case of the ID Transfer method) which may not be removable. One of my machines has over 1000 such entries. Thus I have asked that the eDir team look into a way of providing a cleanup tool or technique which we can use in the field, and not encounter a paywall.

    I agree completely that the apparatus used in migration/upgrade to OES2018 needs a thorough review and cleanup. One of the steps which I suggested is apply many internal (team member) eyes to review the detailed code and plans of attack, and I have urged management to allocate resources for that self boot-strap improvment to occur.