Novell Open Enterprise Server 11 - Updated Installation and Patching information

The latest Novell Open Enterprise Server 11 (OES 11)  Linux release is built on the most advanced Linux: SUSE Linux Enterprise 11.

Novell Open Enterprise Server 11 is fully certified and supported to run on SUSE Linux Enterprise 11.

Novell Open Enterprise Server 11 has been released to the General public on December 13th, 2011. A number of recent updates to the core SLE 11 environment, have introduced few side-effects to the installation procedure since February 2012. These issues could not be anticipated for our during internal testing and QA cycles for the Novell Open Enterprise Server 11 product, prior to release in December 2011.

These issues are described here (as issues 2 & 3), and make the customer experience slightly differ than what is described in our official collateral on the Novell Documentation site that refers to the OES11 Installation Guide.

Problem 1 :
In Section 3.5 Specifying the Add-On Product installation information of the OES11 Installation Guide.
Adding the OES11 media will ask the administrator to import an Untrusted GnuPG key.



Problem 2 :
In section 4.2 Adding/Configuring OES Services on an Existing Server of the OES11 Installation Guide.
Post February 2012, OES11 installations (where SLES11 SP1 is first installed and fully patched, and OES11 has been installed as Add-on product later), selecting any OES pattern for installation, will present a warning that the installation requires ruby-1.8.7.p357-0.7.1 to be downgraded to ruby-1.8.7.p72-5.30.5.



Problem 3 :
Depending on how one installs OES11, whilst applying patches to the server the results is a warning in resolving package dependencies.
The problems resolving packages dependencies is not about a version downgrade however, but refers to a 'Vendor change' notification

In the log this will show as this:
and further in the process we will see the following :
or from the GUI

Solution 1 :
There is no current workaround to this issue possible, other than manually importing the GnuPG key, and to manually add this into the existing keyring of trusted public keys.

Please verify the GnuPG key to import matches the following :


Solution 2:
Since February 2012, OES11 installations (where SLES11 SP1 is first installed and fully patched, and OES11 will been installed as Add-on product later), please accept the proposed version downgrade for ruby-1.8.7.p357-0.7.1 to ruby-1.8.7.p72-5.30.5 in order to proceed with the installation.

After SLES11 SP1 installation, the ruby version shows as

After OES11 installation, and accepting to downgrade the module, the ruby version shows as :

Once the installation of OES11 (with the ruby module downgrade mentioned here above) has completed, ruby can than safely be upgraded to a later versions when required.
Additional note: When installing both SLES11 SP1 and OES11 at the same time (integrated installation), the installation procedure does not ask for the ruby version downgrade.

Cause 1 :
Traditionally, the SUSE keyring contained public keys for the various geographical locations where Novell software was built. One of this locations was Provo. The public GnuPG keys from the Provo build system has since been removed from the SUSE keyring.

Novell is working in pursuing a proper solution for future releases.

Cause 2 :
In order to not enforce customers with certain pre-installation requirements, for OES11 services that require ruby, it has been decided to use the ruby package that comes with the SLES11 SDK, and package the same with the OES11 product as a convenience copy for our customers.

The advantage for this was that this method prevented customers from having to switch media, and/or having a requirement to have an active subscription to the SLE11 SDK catalog.

Cause 3 :
For OES11, the tomcat6 packages listed were build from source by Novell, instead of packaging the binaries built by SUSE. As such, the vendor change is expected because the vendor info for both the SLE and OES packages are different.

As the SUSE team has released tomcat with L3 support in February 2012, this is a one time conflict on any new installations/upgrades post February 2012.

Additional information :
We could argue such messages were never observed on OES 2, however Vendor change issues have previously existed on OES2 as well.
The reason this was never observed by OES2 customers was because SLE10 used ZMD, and ZMD has never cared about vendor changes. ZMD just had a hard-coded set of vendor fields and if the vendor info of a particular was different from that list, it would still go ahead, and install it (without informing the administrator performing the update), and then would tell YaST to "lock" the package from future updates.