SUSE Blog

SUSE Linux Enterprise Server 11 SP4 has Landed in the Public Cloud

rjschwei

By: rjschwei

July 16, 2015 8:45 am

Reads:6,637

Comments:0

Score:5

Print/PDF

As SUSE Linux Enterprise Server 11 SP4 rolled out the door and into the Public Cloud this marks our first service pack transitions since the formalization of the deprecation policy. With FCS (First Customer Ship) on July 14th and the Marketing announcement on July 16th we’ve hit the spot pretty well having all SLES 11 SP4 images live in AWS EC2, Google Compute Engine, HP Helion Public Cloud, and Microsoft Azure by mid day of July 15th. The RightScale Multi Cloud Image definitions that connect the RightScale infrastructure to the SUSE Linux Enterprise Server images in AWS EC2 have also been updated to move to the SLES 11 SP4 RightScale images that include the RighLink 6.3.3 agent.

With the release of the SP4 images the clock on the SLES 11 SP3 images is now ticking. For running SLES 11 SP3 instances updates will continue to be available for the next 6 months. We recommend that you update the instances in place to SLES 11 SP4 at your earliest convenience. Depending on the last time you updated your instances you might get a new kernel, thus plan this update process when it is a convenient time to reboot the instance that is being upgraded.

The procedure below, taken from the earlier blog, will move you forward, run as root:

1.) zypper up
2.) cd /etc/zypp/repos.d
3.) for i in *SP3*; do newname=${i/SP3/SP4}; cp $i $newname; done
4.) sed -i s/SP3/SP4/ *SP4*.repo
5.) sed -i s/enabled=0/enabled=1/ *SP4*.repo
6.) zypper refresh
7.) zypper in zypper

The final step,

8.) zypper dup

should only be executed after you read the rest of this post or you are upgrading an instance in HP Helion Public Cloud.

Before you run ‘zypper dup’ I’d like to point out some special circumstances that apply. We have introduced a Public Cloud Module for SLES 11 SP3 & SP4 and instances launched since July 14th (depending on the time of day) will already have this module registered. Check with:

ls /etc/zypp/repos.d/*SLE11-Pub*

If the repository does not exist you want to create it as follows (as root):

1.) cd /etc/zypp/repos.d
2.) cp *SLES11-SP4-Pool.repo SLE11-Public-Cloud-Module.repo
3.) sed -i s/SLES11-SP4-Pool/SLE11-Public-Cloud-Module/ SLE11-Public-Cloud-Module.repo
4.) zypper refresh

The Public Cloud Module for SLES 11 SP3 & SP4 is not as comprehensive as the Public Cloud Module for SUSE Linux Enterprise Server 12. For example the command line utilities are not included in the SLE11-Public-Cloud-Module. However, we do include the command line utilities in the cloud images and thus zypper would like to remove them during distribution upgrade with ‘zypper dup’.

In AWS instances the information provided by zypper upon running ‘zypper dup’ contains:

The following packages are going to be REMOVED:
  aws-cli crash-sial python-botocore

Running SP3 instances in GCE that are being upgraded will contain the following:

The following packages are going to be REMOVED:
  crash-sial glib2-branding-upstream google-cloud-sdk python-docker-py

Microsoft Azure instances fall into a bit of a different category and are covered in more detail later.

There is nothing to worry about for “crash-sial” and “glib2-branding-upstream”. If you do not need the cloud command line tools in your running instances you can just run ‘zypper dup’ and let the upgrade process do its magic, and you are done.

If you do care about the command line tools in your instance you want to tell zypper not to remove those tools. This works by locking the appropriate packages.

For AWS EC2 instances do the following:

1.) zypper addlock aws-cli python-botocore cloud-regionsrv-client python-ec2metadata python-boto python-requests regionServiceClientConfigEC2
2.) zypper dup
3.) enter “2”, to select “Solution 2: keep obsolete python-dateutil-2.1-41.15.x86_64”
4.) enter “y” to let ‘zypper dup’ upgrade your instance
5.) zypper removelock aws-cli python-botocore cloud-regionsrv-client python-ec2metadata python-boto python-requests regionServiceClientConfigEC2

For running instances in GCE the process looks very similar but we need to lock different packages.

1.) zypper addlock google-cloud-sdk python-docker-py python-httplib2
2.) zypper dup
3.) enter “2”, to select “Solution 2: keep obsolete python-requests-2.6.0-54.5.x86_64”
4.) enter “y” to let ‘zypper dup’ upgrade your instance
5.) zypper removelock google-cloud-sdk python-docker-py python-httplib2

The package lock is removed to allow you to update the packages at a later point if needed. During regular updates of the distribution using ‘zypper patch’ or ‘zypper up’ zypper will not make any attempts to remove or downgrade the packages we locked during this process.

For Microsoft Azure instances we do not need to protect any packages from being removed. But we do need to protect some packages from being downgraded. While the procedures for AWS EC2 instances and GCE instances outlined above was optional depending on your need for the command line tools in the instances the following procedure must be used for Microsoft Azure instances or you might have trouble when the instance needs to be rebooted.

1.) zypper addlock WALinuxAgent python-requests
2.) zypper dup
3.) enter “y” to let ‘zypper dup’ upgrade your instance
4.) zypper removelock WALinuxAgent python-requests

The WALinuxAgent package takes care of instance initialization and the maintenance stream has not yet caught up to the latest state of the code, which is currently being used in the images. We prevent the package from being downgraded and thus maintain the latest feature set of the agent in the image.

SUSE Linux Enterprise Server 11 SP4 is expected to be the final service pack release for SUSE Linux Enterprise Server 11 and thus until it is time to upgrade your running instances to SUSE Linux Enterprise Server 12 you can simply maintain the instances with ‘zypper up’ or ‘zypper patch’ to your liking until SP4 reaches the end of the support cycle.

3 votes, average: 5.00 out of 53 votes, average: 5.00 out of 53 votes, average: 5.00 out of 53 votes, average: 5.00 out of 53 votes, average: 5.00 out of 5 (3 votes, average: 5.00 out of 5)
You need to be a registered member to rate this post.
Loading...

Tags:
Categories: Expert Views, SUSE in the Cloud, SUSE Linux Enterprise Server, Technical Solutions

Disclaimer: As with everything else in the SUSE Blog, this content is definitely not supported by SUSE (so don't even think of calling Support if you try something and it blows up).  It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.

Comment

RSS