I do not understand, why you had to use yast2 wagon to go to oes24.1 . For me that was a standard service pack installation, which runs in the standard yast2 online-update without major issues.

if I am sure that I have a "clean" OES installation I use zypper up for installion of 24.1 (mean patching system)

If I am not sure what I have in my hands I create a supportconfig and then read it to know what to expect. I clean up any errors beforehand. I then use the wagon because it gives me some important information, e.g. is the system registered correctly, do I have a defective patch source, a defective rpm database and other things. Above all the wagon executes all pre installation scripts e.g. for lum including eDir update and then writes a configure=yes into the cfg files.

My approach has to do with the fact that I often have to look after very critical systems, some of which have nss volumes with over 100 GB of data. or more den 25 Server in a Tree. The responsibility is great and therefore defensive and first an inspection. Anyone who says you can revert VMware or other snapshots doesn't know what they are doing to the eDirectory and the leading backup system

you can ask  customers of me about yast2 online-update. I actually had system downtime from OES 23.4 which have been patched to OES 24.1. These were systems with incomplete repos or when downloading the patches there was an https 28 (timeout), not authorized (403) or other funny things regarding the NCC update.

Maybe one more thing:

When upgrading via NCC, it does not matter whether zypper patch or zypper up is executed. The complete OT repo is used and the data is loaded from the NCC repo. The situation is different when using SMT or SUSEManager

NCC Patch Source zypper lr

# zypper ls
# | Alias         | Name          | Enabled | GPG Check | Refresh | Type
--+---------------+---------------+---------+-----------+---------+-----
1 | nu_novell_com | nu_novell_com | Yes     | ----      | Yes     | ris

George

Georg H. Weber said:

if I am sure that I have a "clean" OES installation I use zypper up for installion of 24.1 (mean patching system)

If you must install update(patch) using zypper, alway use zypper patch command.

Georg H. Weber said:

I then use the wagon because it gives me some important information

Correct. If you go zypper way, then we recommend running /opt/novell/oes-install/util/oes_upgrade_check.pl script to check the configuration of all deployed services​ before upgrade.

The note /opt/novell/oes-install/util/oes_upgrade_check.pl is important, the note is top! There are often signs of problems here.

Before I patch a system, I go through a list that has served me well for many years. No matter if I use zypper patch, yast online or whatever. I read through a support config, there is always something there. If the master is leased, I carry out a master change beforehand. The tree CA is backed up in any case and many small steps more. The upgrade check is also part of this. Furthermore, an ndstrace with various commands to see whether the NDS is OK, ndcheck or ndsrepair. A backup of the NDS is also part of it and I already have 2023 ahead of me can easily check the function of the certificates for different servers with the certutils, which I usually do with openssl. in many cases, an ldapsearch also helps to see whether configurations are correct or how an installation was carried out in the first place. As an example I will take the eDir integrated DNS / DHCP, oes_proxy_use, casa or lum config

Another thing is that I have developed scripts that perform analyses for me. So I have a script which uses nmap to check whether 389, 636, 524 or other important ports are "up" for the OES system and communication between all servers is possible. How often have I seen with WAN links that ports are blocked or not all servers can see each other?


Many thanks for the valuable tips

Thanks for the feedback! 

Georg H. Weber said:

1. ) cat /etc/OES-brand delivers OES version 23.4  that is confusing

Agreed. This needs tidying up (coming in a future update).

Georg H. Weber said:

2) the documentation is still for 23.4

Good catch! This is now resolved. Please retry. 

Georg H. Weber said:

3.) in the SLD there is a file OES24.1.tar.xz which only contains rpm of version 24.1, where is the ISO?

Only Q4 releases come with ISO. The 24.1 update is available over the channel for 23.4 servers. The tar file contains RPMs included with the update only for your reference.

Georg H. Weber said:

4) as before, the iManager plugins are reinstalled, this really takes time

  UMC(+IC) is due to replace iManager.   

Georg H. Weber said:

5) With two new installations the zypper upgrade / yast2 wagon did not work.

We have not observed the need for channel reregistration. Is this happening on every upgrade from OES 23.4 to 24.1? On a side note, refrain from doing zypper up instead use the documented zypper patch command.

Georg H. Weber said:

The small fixes e.g. that the install scripts forget to enter the port for the UMC and the postgres in the firewall config

I believe the ports are updated in the firewall - will check and fix in next update this, if not. 

I'll provide my experience for far with OES 24.1.

I just upgraded two OES 2023 servers.  I used the OES 23.4 ISO/offline method.  

Both servers were registered and full patched before booting with the ISO.

On both servers, registration failed at the "Configure Now" screen (I didn't take a screen shot at the time, but it was something about registration code missing, but they were both previously registered).

After the first reboot I got the error about the missing workflow, which I have gotten on every single OES 2018.3 or 2023 server I've ever upgraded.

I also got an error about unable to access repositories after the workflow error, but I hit continue/retry and everything seemed to proceed as expected.

One server had iManager, this time I timed the how long the plugin installation took, it was 25 minutes.  This is ridiculous.

After that was done, I had to re-register the servers using suse_register with --restore-repos option.

I then was able to use zypper to do the updates to get the servers to 24.1.

-------------------------------

Some other comments, I've upgraded at least a dozen servers from either 2018.3 or 2023 directly to 23.4 and/or 24.1 using the offline/ISO method.  I've never once had the registration work during the install, not one time (some of these sites had local SMT some didn't).  Every single server I have ever upgraded I've had to re-register after the upgrade and patch myself.

Every single server I've ever upgraded got the "Workflow" error during the upgrade.

Every single server with iManager I've upgraded takes an incredible amount of time during the plugin installation.

I find the new versioning confusing, as has been mentioned above.  Is it 2023? it is 23? is it 24?  What is it really? All the repos still say 23.4.  I figure this is an artifact of having to "shoehorn" these products into OpenText's corporate versioning standard.

I did just upgrade two 23.4 servers to 24.1 using zypper from an SMT server, and that seemed to work just fine.

Matt

Hello Matt,

in the field for customers I have noticed that the query of the URL for the repos that are located at OT are often rejected with an Http 28, http 403 or 404. The Zypper log then also gives corresponding information with a brocken pipe. However, this is not a fundamental problem. The solution is to re-register the system in question in the NCC using any method.

The repos are still 23.4, which is correct, see also /etc/novell-release

cat /etc/OES-brand still brings OES 23.4 although the patch was run after 24.1, this is cosmetic according to OT. Correct is here
cat novell-release
Open Enterprise Server 24.1 (x86_64)
VERSION = 2023.1
PATCHLEVEL = 1
DISPLAY_RELEASE = 24.1

With the SMT I can say the following from field experience: Before upgrade / migrations I usually run a smt-ncc-sync and a smt-mirror first in clean mode and then in debug mode to see possible first errors with the mirror, then finally the sync. Maybe I am a bit overcautious, but if you are a Tekki in environments that have an OES server in the tree and a TB NSS. The largest I once had in my fingers were nss volumes totaling more than one PB. That warms up your fingers and your head .-)

What I would also like to add is to run commercial certificates for the tree CA and the services. The oes cert tools will help to make things easier. Furthermore, it should be considered from which IPs admin tools for the OES systems may be accessed at all. It is also important to me that the IC console and UMC are introduced to customers. The new version of the IC for OES 24.1 is available in the SLD for LINUX; WIN

George

Every server I've upgraded was registered and full patched before attempting an upgrade, whether locally to an SMT or to the NCC.  It hasn't made any difference in my experience so far.

Same with SMT, fully sync'd and mirrored.  At one customer I did extensive testing in their lab with an SMT and spent a lot of time trying to figure out these issues but I finally gave up and just did what I had to in order to get the servers upgraded.

Requiring commercial certs for the tree CA and services is ridiculous.  It shouldn't be a problem to use internally minted certificates.  It's very common for large enterprises to use an internal PKI infrastructure.  I actually haven't had any issues here that I'm aware of quite honestly.

Identity Console is a horrible piece of software with an incredible amount of bugs (I primarily work with the NetIQ IAM products so I'm quite familiar with Identity Console unfortunately). If you are an IAM customer, you really cannot get rid of iManager yet.

I haven't installed UMC yet, I do need to do that.  I wish it didn't require a database.  Requiring a DB for an administration tool also doesn't seem to make sense.

I will admit I am upgrading some pretty old boxes, so I know there is most likely some baggage there.  It's just that the process is overall kind of a sloppy mess to me.  It all can be made to work (every server I've done is working just fine), but the attention to detail is lacking (really an OT wide problem).

Matt

Just thought I would chime in with my experience so far.  I have five OES 2018 SP3 servers that I am upgrading.  Three are done now and installs completed without any problems.  I used the boot from iso method.  I did make sure they were fully patched and I entered the network config (they want to default to DHCP and ignore previous settings).  I also entered the reg code during registration.  The fourth server I will migrate instead of upgrading because it has some disk limitations and will be easier to handle this way.  That will just leave me one more to complete the set.

Just for the sake of it: I've done several dozen OES2018 SP3 to 23.4/24.1 upgrades, and have seen basically everything, *except* registration errors. Neither via ncc, not smt. Not a single one. The fact that you see those on every server makes me think there must be something the servers you look after have in common that causes this.

Wholeheartedly agreee on the databse for UMC thing. We all *really* need to stop making things like this so overcomplex. We're already well beyond the point to be able to mange the software mosters we create. Reliability and manageability constantly decline with alarminng rate.
Note: this isn't limited to "our" products at all. It's a general industry "standard". It seems, the only way we can think forward is to keep adding (code).