Find the answer to your Linux question:
Results 1 to 5 of 5
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1

    Is Redhat Satellite server rollback useless?


    First time apologies if this is not the right forum.
    Having purchased Redhat Satellite server and used it successfully (mainly) for patching our non prod estate - we hit an issue with one server - and attempted rollback. This had been tested on several VMs - but not on a physical blade.
    It failed on the physical blade as "Satellite server rollback does not support rollback to snapshots including non Redhat rpms"....accoding to Redhat.
    Redhats subsequent advice was they basically advised we should remove all the non redhat rpms before taking a snapshot. As there are circa 50 non redhat rpms - some of them for Veritas vxvm filesystems...this is a non starter.
    Has anyone else else hit this problem and overcome it?

  2. #2
    Penguin of trust elija's Avatar
    Join Date
    Jul 2004
    Either at home or at work or down the pub
    No, but I do sympathise with your Red Hat support experience. We had to use it for what turned out to be a relatively simple thing and they were so bad that we stopped paying and switched to CentOS instead. I wish you luck.
    Should you be sitting wondering,
    Which Batman is the best,
    There's only one true answer my friend,
    It's Adam Bloody West!

    The Fifth Continent

  3. #3
    Dont blame you - we used Centos directory server - but everything else is Redhat proprietary.
    Not looking promising for a response this one....oh well...thats life

  4. $spacer_open
  5. #4
    Trusted Penguin Irithori's Avatar
    Join Date
    May 2009
    Fwiw, we used spacewalk, which is the non-supported version of satellite.
    Also spacewalk is only for centos.

    Imho the restriction "redhat rpms only" for rollbacks kind of makes sense:
    Redhat needs control over the rpm quality and the deployment.
    This control is a requirement for commercial support.

    For example: I could easily write a spec file with extensive %pre or %post scripts.
    These scripts can modify a system on package install/deinstall time, but these changes are not neccessarily reflected in the rpm filelist.
    Hence: If one would install and then rollback (deinstall) such a package, then there might be leftovers: Rollback failed.

    Another example: One could -with enough violence- download and install alien rpms.
    So, if one getīs "UncleJoesSuperAppForSuse8.0" and force installs it on a redhat enterprise 6.2, then bad things will happen: Inconsistent filelists int the rpmdb, broken dependencies, etc.
    Hence: Rollback would also fail.

    We have chosen another path:
    In Spacewalk (and most probably also satellite), you can define which server is subscribed to which channel.

    So we do have channels for the latest and greatest.
    This is, what dev and qa machines get.

    Once our self-written apps (which are also rpm-ed) have been tested,
    the software stack + our apps becomes the new "approved" channel.
    RC and production machines are subscribed to the approved channel.

    Which helps preventing rollbacks, but unfortunately they are still not impossible.
    We addressed that by utilizing puppet.

    All our machines are 100% puppet controlled, which includes packages.
    A package in puppet can have one of multiple states: absent, installed, latest or specific version.
    So in case of rollback, we set the specific version of our app to the previous approved one: --> voila, rollback

    Note: Due to a known bug in yum, downgrades with complex dependencies will fail.
    But relatively simple: A needs B work.
    Last edited by Irithori; 03-18-2012 at 07:01 PM.
    You must always face the curtain with a bow.

  6. #5
    Thanks - appreciate the feedback

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts