Puppet users - Jun 2013 - White Paper: Migrating from Redhat satellite server to Puppet + Foreman

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.

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.

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" <mreams@gmail.com> 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.

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.

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.

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 <skbenja@gmail.com>
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.