FAQ
Hi Everyone,
I've written a paper that captures the approach that we took when moving
from Redhat Satellite for configuration and software management to Puppet
and Foreman (alongside some other assorted technologies).

The paper contains a number of lessons learnt in the Ruby, Puppet, Foreman
and Software deployment spaces that are likely to be useful for other
administrators looking to move from Satellite or similar technologies.

It is important to note that whilst this approach to migrating from
Satellite server was ideal for this particular business and environment, it
is not suitable for everyone. It is also worth mentioning that a number of
the Puppet techniques used in this document may no longer be considered
best practice as the product evolves rapidly and features that are now
available such as hiera did not exist at the time the environment was being
designed and deployed.

The document can be found here:
- De-Orbiting Satellite (PDF) - http://goo.gl/0CAcy


I hope some of you find this of some use and if you have any questions,
feedback, etc feel free to drop me a line.

Cheers,

K

Keiran (at) gmail.com || @keiran_s

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Matthew Reams at Jun 11, 2013 at 2:37 pm
    Hi.

    I really appreciate this knowledge sharing. I currently use Spacewalk
    instead of Red Hat Satellite for patch management of my RHEL hosts, but I'm
    not happy with it for configuration management and working towards
    implementing Puppet. How do you audit and report your current package
    levels on your servers now that you've moved to this new solution?

    Thanks!
    On Monday, June 10, 2013 9:04:17 AM UTC-4, Keiran Sweet wrote:

    Hi Everyone,
    I've written a paper that captures the approach that we took when moving
    from Redhat Satellite for configuration and software management to Puppet
    and Foreman (alongside some other assorted technologies).

    The paper contains a number of lessons learnt in the Ruby, Puppet, Foreman
    and Software deployment spaces that are likely to be useful for other
    administrators looking to move from Satellite or similar technologies.

    It is important to note that whilst this approach to migrating from
    Satellite server was ideal for this particular business and environment, it
    is not suitable for everyone. It is also worth mentioning that a number of
    the Puppet techniques used in this document may no longer be considered
    best practice as the product evolves rapidly and features that are now
    available such as hiera did not exist at the time the environment was being
    designed and deployed.

    The document can be found here:
    - De-Orbiting Satellite (PDF) - http://goo.gl/0CAcy


    I hope some of you find this of some use and if you have any questions,
    feedback, etc feel free to drop me a line.

    Cheers,

    K

    Keiran (at) gmail.com || @keiran_s
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Keiran Sweet at Jun 13, 2013 at 10:46 am
    Hi There,
    At the moment we don't, but it is something we need to look at.

    Part of the challenge with this particular environment was that every
    system was literally different in configuration and installed package
    versions. What I opted to do was pick a modern baseline OS to bring the
    whole fleet up to (at the time RHEL 4.9, 5.8 and 6.3), address the
    configuration issues with puppet then revisit the issue.

    Long term, I think I would look to use mcollective to write/implement a set
    of tools that allowed real time reporting of various OS patch levels across
    the fleet, and possibly move from the Apache + yum platform that works very
    well as a stop gap to pulp for a more streamlined workflow , however it is
    still something I need to research further, and patch and package
    management currently isn't the lowest hanging fruit in this particular
    environment.

    One thing Foreman does offer out of the box is some levels of reporting on
    fact data, so you can get an idea of fleet composition based on OS release
    and sub versions, which is of some use, and better than flying blind as we
    were before..

    Hope this helps, and if you have ideas or suggestions I'd be keen to hear
    them too.

    Cheers,

    K
    On 11 Jun 2013 15:38, "Matthew Reams" wrote:

    Hi.

    I really appreciate this knowledge sharing. I currently use Spacewalk
    instead of Red Hat Satellite for patch management of my RHEL hosts, but I'm
    not happy with it for configuration management and working towards
    implementing Puppet. How do you audit and report your current package
    levels on your servers now that you've moved to this new solution?

    Thanks!
    On Monday, June 10, 2013 9:04:17 AM UTC-4, Keiran Sweet wrote:

    Hi Everyone,
    I've written a paper that captures the approach that we took when moving
    from Redhat Satellite for configuration and software management to Puppet
    and Foreman (alongside some other assorted technologies).

    The paper contains a number of lessons learnt in the Ruby, Puppet,
    Foreman and Software deployment spaces that are likely to be useful for
    other administrators looking to move from Satellite or similar technologies.

    It is important to note that whilst this approach to migrating from
    Satellite server was ideal for this particular business and environment, it
    is not suitable for everyone. It is also worth mentioning that a number of
    the Puppet techniques used in this document may no longer be considered
    best practice as the product evolves rapidly and features that are now
    available such as hiera did not exist at the time the environment was being
    designed and deployed.

    The document can be found here:
    - De-Orbiting Satellite (PDF) - http://goo.gl/0CAcy


    I hope some of you find this of some use and if you have any questions,
    feedback, etc feel free to drop me a line.

    Cheers,

    K

    Keiran (at) gmail.com || @keiran_s
    --
    You received this message because you are subscribed to a topic in the
    Google Groups "Puppet Users" group.
    To unsubscribe from this topic, visit
    https://groups.google.com/d/topic/puppet-users/-74LLSshgpY/unsubscribe?hl=en
    .
    To unsubscribe from this group and all its topics, send an email to
    puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Stephen Benjamin at Jun 13, 2013 at 1:19 pm
    Hi,

    Interesting paper. For full disclosure, I do work for Red Hat, so you
    know, I could be biased :)

    I agree about Puppet being miles ahead for configuration. For customers
    who can, I think they should rely on Puppet instead of Satellite for
    configuration, unless they have simple needs.

    But I prefer Satellite's software management.

    There's no reason you can't use Satellite alongside the Foreman or with
    plain Puppet. I have many customers who do, and I do on my own home
    network. The hybrid approach works well. You can, of course, leave
    Satellite to setup your own roll your own yum repos with mrepo/grindr, or
    using Pulp. IMHO, I think you spend a lot of effort for a solution that's
    not as good.

    Cloned channels, for the moment, is really the best way to lock multiple
    systems to the same versions. A roll-your-own with yum repos makes that
    difficult -- you're left with having multiple copies of everything on the
    filesystem. For Pulp, you need at least 2 copies of all the software (the
    mrepo/grindr dump, and the internal pulp copy). Pulp does has similar
    features like cloned channels but last time I looked it wasn't as mature as
    Satellite's. I also remember having quite a bit of difficulty getting
    install trees to import correctly into Pulp.

    Satellite also gives you a really nice view into the latest errata,
    including security updates, and the ability to compare systems and look at
    their package profiles in detail.

    Overall, I think patch management plan needs a closer look in your solution.

    As far as the list of complaints about Satellite, I disagree with most.
      There's two pages of complaing about Satellite when admittedly, you're
    running this on a pretty old version of Satellite. Most of your complaints
    could be addressed by just upgrading or understanding the product better.

    Just a few notes about your complaints:

    * Reporting for software related information is good - you can see the full
    package set on systems, and do a "diff" of two systems.

    * You can see what systems are not checking in quite easily...

    * Duplicate node finder was available starting with 5.3 (5.4?) although I
    don't think it's perfect. You're better of making sure you're using
    reactivation keys, which I think are now included in the latest RHN
    registration snippet.

    * Inventory? Satellite has *a lot* of information about a system. For
    custom data you can use key/value pairs. For example, I have a script that
    syncs Facter info to Satellite: https://github.com/stbenjam/spacewalk-facter

    * Speed complaints - TBH, this sounds like there was some underlying
    problems with your Satellite server. I'd have opened a ticket with Red Hat
    to have them look at it in detail. Building a new server total time takes
    under 5 minutes for me, including registration to Satellite.

    * Kickstart - host renaming from localhost is easily fixed by writing a
    better kickstart, e.g. using
    https://github.com/stbenjam/junk-drawer/blob/master/kickstart/pre_parse_kernel_cmdline.txt
    and
    https://github.com/stbenjam/junk-drawer/blob/master/kickstart/cmdline_network



    - Stephen

    On Monday, June 10, 2013 3:04:17 PM UTC+2, Keiran Sweet wrote:

    Hi Everyone,
    I've written a paper that captures the approach that we took when moving
    from Redhat Satellite for configuration and software management to Puppet
    and Foreman (alongside some other assorted technologies).

    The paper contains a number of lessons learnt in the Ruby, Puppet, Foreman
    and Software deployment spaces that are likely to be useful for other
    administrators looking to move from Satellite or similar technologies.

    It is important to note that whilst this approach to migrating from
    Satellite server was ideal for this particular business and environment, it
    is not suitable for everyone. It is also worth mentioning that a number of
    the Puppet techniques used in this document may no longer be considered
    best practice as the product evolves rapidly and features that are now
    available such as hiera did not exist at the time the environment was being
    designed and deployed.

    The document can be found here:
    - De-Orbiting Satellite (PDF) - http://goo.gl/0CAcy


    I hope some of you find this of some use and if you have any questions,
    feedback, etc feel free to drop me a line.

    Cheers,

    K

    Keiran (at) gmail.com || @keiran_s
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Keiran Sweet at Jun 26, 2013 at 2:10 pm
    Hey There,
    Sorry for the late reply on this, been a bit manic this end and am just
    catching up.

    To be honest, I don't disagree with you really on most of your points. In
    regards to the paper, this was that worked for this environment and there
    were some other factors behind the scenes (financial, political and
    technical) that drove the approach as well, however things like patch and
    release management is something that needs to be looked at going forward.

    One thing I opted out of talking about in the paper was that we had to deal
    with a just as problematic Spacewalk install, other software repos served
    random infrastructure hosts and a mess of other kickstart setups for both
    RHEL and CentOS glued together with a web of cobbler, because of this I
    opted to centralise all the packages from these locations on a simple
    Apache based YUM platform, then revisit it when when I got the chance.

    I did have Puppet + Satellite running for a while as well, and it did
    function as I expected, although it was pretty slow, but as you mention, it
    could have been the age and configuration of the platform as well.

    I do appreciate you taking the time to provide feedback, my goal really was
    to get information out there about what to expect if/when you migrate,
    without the admin having to rediscover every step along the way, and your
    comments do provide the other side of the coin.

    Cheers,

    K





    On Thu, Jun 13, 2013 at 2:17 PM, Stephen Benjamin wrote:

    Hi,

    Interesting paper. For full disclosure, I do work for Red Hat, so you
    know, I could be biased :)

    I agree about Puppet being miles ahead for configuration. For customers
    who can, I think they should rely on Puppet instead of Satellite for
    configuration, unless they have simple needs.

    But I prefer Satellite's software management.

    There's no reason you can't use Satellite alongside the Foreman or with
    plain Puppet. I have many customers who do, and I do on my own home
    network. The hybrid approach works well. You can, of course, leave
    Satellite to setup your own roll your own yum repos with mrepo/grindr, or
    using Pulp. IMHO, I think you spend a lot of effort for a solution that's
    not as good.

    Cloned channels, for the moment, is really the best way to lock multiple
    systems to the same versions. A roll-your-own with yum repos makes that
    difficult -- you're left with having multiple copies of everything on the
    filesystem. For Pulp, you need at least 2 copies of all the software (the
    mrepo/grindr dump, and the internal pulp copy). Pulp does has similar
    features like cloned channels but last time I looked it wasn't as mature as
    Satellite's. I also remember having quite a bit of difficulty getting
    install trees to import correctly into Pulp.

    Satellite also gives you a really nice view into the latest errata,
    including security updates, and the ability to compare systems and look at
    their package profiles in detail.

    Overall, I think patch management plan needs a closer look in your
    solution.

    As far as the list of complaints about Satellite, I disagree with most.
    There's two pages of complaing about Satellite when admittedly, you're
    running this on a pretty old version of Satellite. Most of your complaints
    could be addressed by just upgrading or understanding the product better.

    Just a few notes about your complaints:

    * Reporting for software related information is good - you can see the
    full package set on systems, and do a "diff" of two systems.

    * You can see what systems are not checking in quite easily...

    * Duplicate node finder was available starting with 5.3 (5.4?) although I
    don't think it's perfect. You're better of making sure you're using
    reactivation keys, which I think are now included in the latest RHN
    registration snippet.

    * Inventory? Satellite has *a lot* of information about a system. For
    custom data you can use key/value pairs. For example, I have a script that
    syncs Facter info to Satellite:
    https://github.com/stbenjam/spacewalk-facter

    * Speed complaints - TBH, this sounds like there was some underlying
    problems with your Satellite server. I'd have opened a ticket with Red Hat
    to have them look at it in detail. Building a new server total time takes
    under 5 minutes for me, including registration to Satellite.

    * Kickstart - host renaming from localhost is easily fixed by writing a
    better kickstart, e.g. using
    https://github.com/stbenjam/junk-drawer/blob/master/kickstart/pre_parse_kernel_cmdline.txtand
    https://github.com/stbenjam/junk-drawer/blob/master/kickstart/cmdline_network



    - Stephen

    On Monday, June 10, 2013 3:04:17 PM UTC+2, Keiran Sweet wrote:

    Hi Everyone,
    I've written a paper that captures the approach that we took when moving
    from Redhat Satellite for configuration and software management to Puppet
    and Foreman (alongside some other assorted technologies).

    The paper contains a number of lessons learnt in the Ruby, Puppet,
    Foreman and Software deployment spaces that are likely to be useful for
    other administrators looking to move from Satellite or similar technologies.

    It is important to note that whilst this approach to migrating from
    Satellite server was ideal for this particular business and environment, it
    is not suitable for everyone. It is also worth mentioning that a number of
    the Puppet techniques used in this document may no longer be considered
    best practice as the product evolves rapidly and features that are now
    available such as hiera did not exist at the time the environment was being
    designed and deployed.

    The document can be found here:
    - De-Orbiting Satellite (PDF) - http://goo.gl/0CAcy


    I hope some of you find this of some use and if you have any questions,
    feedback, etc feel free to drop me a line.

    Cheers,

    K

    Keiran (at) gmail.com || @keiran_s
    --
    You received this message because you are subscribed to a topic in the
    Google Groups "Puppet Users" group.
    To unsubscribe from this topic, visit
    https://groups.google.com/d/topic/puppet-users/-74LLSshgpY/unsubscribe?hl=en
    .
    To unsubscribe from this group and all its topics, send an email to
    puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Chuck at Jun 13, 2013 at 2:41 pm
    You could also look at the Satellite 6 upsteam project Katello.

    http://www.katello.org/

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedJun 10, '13 at 1:04p
activeJun 26, '13 at 2:10p
posts6
users4
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase