Oracle Linux, virtualization , Enterprise and Cloud Management Cloud technology musings

  • December 22, 2014

New features in ksplice uptrack-upgrade tools for Oracle Linux

We have many, many happy Oracle Linux customers that use and rely on the Oracle Ksplice service to keep their kernels up to date with all the critical CVEs/bugfixes that we release as zero downtime patches.

There are 2 ways to use the Ksplice service :

  • Online edition/client

  • The uptrack tools (the Ksplice utilities you install on an Oracle Linux server to start applying ksplice updates) connect directly with the Oracle server to download updates. This model gives the most flexibility in terms of providing information of patches and detail of what is installed because we have a website on which you can find your servers and detailed patch status.

  • Offline edition/client

  • Many companies cannot or do not register all servers remotely with our system so they can rely on the offline client to apply updates. In this mode, the ksplice patches are packaged in RPMs for convenience. For each kernel that is shipped by Oracle for Oracle Linux, we provide a corresponding uptrack-update RPM for that specific kernel version. This RPM contains all the updates that have been released since that version was released.

    The RPM is updated whenever a new ksplice patch becomes available. So you always have 1 RPM installed for a given kernel, and this RPM gets updated. This was standard yum / rpm commands can be used to update your server(s) with ksplice patches as well and everything is nicely integrated.

    The standard model is that an uptrack-upgrade command will apply all updates to current/latest on your server. This is of course the preferred way of applying security fixes on your running system, it's best to be on the latest version. However, in some cases, customers want more fine-grained control than latest.

    We just did an update of the ksplice offline tools to add support for updating to a specific "kernel version". This way, if you are on kernel version x, you would like to go to kernel version y (effective patches/security fixes) but latest is kernel version z, you can tell uptrack-upgrade to go to kernel version y. Let me give a quick and simple example below. I hope this is a useful addition to the tools.

    happy holidays and happy ksplicing!

    To install the tools, make sure that your server(s) has access to the ol6_x86_64_ksplice channel (if it's OL6) :

    $ yum install uptrack-offline

    Now, in my example, I have Oracle Linux 6 installed with the following version of UEK3 :

    $ uname -r

    Let's check if updates are available :

    $ yum search uptrack-updates-3.8.13-44.1.1
    Loaded plugins: rhnplugin, security
    This system is receiving updates from ULN.
    =========== N/S Matched: uptrack-updates-3.8.13-44.1.1.el6uek.x86_64 ===========
    uptrack-updates-3.8.13-44.1.1.el6uek.x86_64.noarch : Rebootless updates for the
    ...: Ksplice Uptrack rebootless kernel update service

    As I mentioned earlier, for each kernel there's a corresponding ksplice update RPM. Just install that. In this case, I run 3.8.13-44.1.1.

    $ yum install uptrack-updates-3.8.13-44.1.1.el6uek.x86_64.noarch
    Loaded plugins: rhnplugin, security
    This system is receiving updates from ULN.
    Setting up Install Process
    Resolving Dependencies
    --> Running transaction check
    ---> Package uptrack-updates-3.8.13-44.1.1.el6uek.x86_64.noarch 0:20141216-0 will be installed
    --> Finished Dependency Resolution
    Dependencies Resolved
    Package Arch Version Repository Size
    noarch 20141216-0 ol6_x86_64_ksplice 39 M
    Transaction Summary
    Install 1 Package(s)
    Total download size: 39 M
    Installed size: 40 M
    Is this ok [y/N]: y
    Downloading Packages:
    uptrack-updates-3.8.13-44.1.1.el6uek.x86_64-20141216-0.n | 39 MB 00:29
    Running rpm_check_debug
    Running Transaction Test
    Transaction Test Succeeded
    Running Transaction
    Installing : uptrack-updates-3.8.13-44.1.1.el6uek.x86_64-20141216-0.noa 1/1
    The following steps will be taken:
    Install [b9hqohyk] CVE-2014-5077: Remote denial-of-service in SCTP on simultaneous connections.
    Installing [vtujkei9] CVE-2014-6410: Denial of service in UDF filesystem parsing.
    Your kernel is fully up to date.
    Effective kernel version is 3.8.13-55.1.1.el6uek
    Verifying : uptrack-updates-3.8.13-44.1.1.el6uek.x86_64-20141216-0.noa 1/1
    uptrack-updates-3.8.13-44.1.1.el6uek.x86_64.noarch 0:20141216-0

    There have been a ton of updates released since 44.1.1, and the above update gets me to effectively running 3.8.13-55.1.1. Of course, without a reboot.

    $ uptrack-uname -r

    Now we get to the new feature. There's a new option in uptrack-upgrade that lists all effective kernel versions from the installed kernel to the latest based on the ksplice rpm installed.

    $ uptrack-upgrade --list-effective
    Available effective kernel versions:
    3.8.13-44.1.1.el6uek.x86_64/#2 SMP Wed Sep 10 06:10:25 PDT 2014
    3.8.13-44.1.3.el6uek.x86_64/#2 SMP Wed Oct 15 19:53:10 PDT 2014
    3.8.13-44.1.4.el6uek.x86_64/#2 SMP Wed Oct 29 23:58:06 PDT 2014
    3.8.13-44.1.5.el6uek.x86_64/#2 SMP Wed Nov 12 14:23:31 PST 2014
    3.8.13-55.el6uek.x86_64/#2 SMP Mon Dec 1 11:32:40 PST 2014
    3.8.13-55.1.1.el6uek.x86_64/#2 SMP Thu Dec 11 00:20:49 PST 2014

    So as an example, let's say I want to update from 44.1.1 to 44.1.5 instead of to 55.1.1 (for whatever reason I might have). All I have to do, is run uptrack-upgrade to go to that effective kernel version.

    Let's start with removing the installed updates and go back from 55.1.1 to 44.1.1 and then upgrade again to 44.1.5 :

    $ uptrack-remove --all
    $ uptrack-upgrade --effective="3.8.13-44.1.5.el6uek.x86_64/#2 SMP Wed Nov 12 14:23:31
    PST 2014"

    Effective kernel version is 3.8.13-44.1.5.el6uek

    And that's it.

    Be the first to comment

    Comments ( 0 )
    Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.