Gathering OES23.4 In-Place Upgrade issues (and their solutions)

Hi. I wanted to start a thread with all real-life Inplace Upgrade Issues long with their (if known) possible solutions. Also, I want to generally discuss the upgrade process, and if there isn't a lot of potential for improvement, cause in my mind, there are dozens unnecessary and dangerous steps the Upgrade process does for no reason.

So let's start:

1. Check /etc/sysconfig/novell/edir_oes2018_sp3, if it contains 'SERVICE_CONFIGURED="yes"'. If it says "no", the upgrade to oes2018sp3 hasn't finished properly. Most likely, the "yast channel-upgrade-oes" didn't happen or ran into an error that wasn't fixed, and now haunts you. Your server most likely is working fine anyways, but your ugrade will fail miserably. (*)

Solution: Edit the file to read 'SERVICE_CONFIGURED="yes"' *before* attemting the upgrade. If you don't do this, the upgrade process will attempt to add your server to the eDir Tree instead of upgrading it.
(IMNSHO this is a massive bug. Relying on some freely editable, notoriously unreliable config file that has no meaning whatsoever to the operation of the server, to determine if a server is active part of an eDir tree or no is insane. Why not just ask eDir instead?)
Also, when this happens, verify the other OES2018SP3 files in /etc/sysconfig/novell, as most likely some others are wrong.

2. The Upgrade *will* activate the Firewall in all cases, which will block most non-standard traffic. Solution: Obviously to disable the firewall after the upgrade again, or configure it for your needs. I personally consider Server Side Firewalls a completely broken idea.

3. The upgrade will alter your Timesync config massively. If you have multiple time servers configured now, it will only take over the first one, plus, it will add a public SUSE NTP pool to your setup without asking. On top (and this is nasty), it will stop your server from answering to NTP traffic, as the /etc/chrony.conf it creates does not contain an "allow=" line. Many installs do rely on OES Servers as their Time Sources, and they will no longer work after the upgrade.

Solution: Edit /etc/chrony.conf (or use yast) and add back all your servers. Also, remove /etc/chrony.d/pool.conf (that is the public suse server pool you may not want).

4. Less important, but may hit you anyways, especially when you run Groupwise: The Upgrade will reenable postfix when it was disabled before. Solution: Disable postfix again, if e.g your GWIA will no longer listen on port 25, and you need it to listen on more than one IP.

More to come. Feel free to add to the discussion what you have found.


 



Parents
  • 0

    mrosen, you forget many other troubles, i will say this was "a big catastrophe", this is a no-go!

    other troubles:

    dns/dhcp-Server

    http-Server

    NFS

    Graphical interfaces not working

    And one month after the released version, not all problems are resolved!

    Why is it not possible to create by installation a error-log-file with all installation troubles, so that it is possible to send this file to OT for analyzing!

    We had productive machines and will not end as bad system integrator, we must have more trust in OT and performant and quickly support.

    Where is the next buyer of the Novell/MF-Products?

    Sorry, i am a long customer, but never seen this in near 40 years!

Reply
  • 0

    mrosen, you forget many other troubles, i will say this was "a big catastrophe", this is a no-go!

    other troubles:

    dns/dhcp-Server

    http-Server

    NFS

    Graphical interfaces not working

    And one month after the released version, not all problems are resolved!

    Why is it not possible to create by installation a error-log-file with all installation troubles, so that it is possible to send this file to OT for analyzing!

    We had productive machines and will not end as bad system integrator, we must have more trust in OT and performant and quickly support.

    Where is the next buyer of the Novell/MF-Products?

    Sorry, i am a long customer, but never seen this in near 40 years!

Children
  • 0   in reply to 

    FWIW, I didn't have any problems with DNS/DHCP, and virtually all servers I upgraded run those.

    *BUT*: And that is part of the discussion: In an upgrade from OES2018SP3 to OES20234, IMHO it is *completely* unnecessary to touch DNS, DHCP, LUM, LDAP and a few other configurations. And *of course* everything you touch although you don't have to, has the potential to break. Especially, if you, as the OES Upgrade has done forever, do *NOT* take the configuration of the existing services *from* the service itself, but instead pull it from some absolutely meaningless fil in /etc/sysconfig/novell, which may, or may not match the true config.

    While we're at it: It is also absolutely unnecessary too, to "upgrade" the eDir schema or the NMAS methods on *every* server. This needs to be done exactly once per tree. That's another potentially dangerous step.

    Oh, and I forgot. Using LDAPS for most of the configs without reason, and without at the same time verifying *BEFORE* anything happens with the server that this is working flawlessly, is another of those sillinesses. NCP exists and is 100% reliable. LDAPS (especially the "S" part of it, is a major nightmare ever since OES exists, and is simply not even remotely reliable enough.

  • 0 in reply to 

    I agree it is very frustrating, almost like MF get a single basic server upgrade to work and sign off the QA testing.

    On the servers I've upgraded, the only issue I've had is the GUI console is FUBAR'd on one server. I just see a little sad face and a message saying something has gone wrong, and to contact a Sysadm! :-D Why on that one and not the others who knows? Would be nice to get a fix at some point as _very_ infrequently I need to do something in the Console - but it's always when something else has gone pop and I can't ssh in remotely.

    M