Puppet users - Feb 2009 - Puppet Questions

Hi guys,

I''ve got a few questions regarding Puppet. We''re currently
investigating it
for deployment at the ISP where I work.

Here''s some questions that have been raised;

Why the pull architecture?

How can this be achieved using a push, what are the limitations?

What are the implications of using puppet on legacy systems?

How do you generally manage updates?

Is there any web interface in addition to the CLI?

How do you stage the updates (testing)?



Any input is greatly appreciated.

Joel

-- 
$ echo "kpfmAdpoofdufevq/dp/vl" | perl -pe
''s/(.)/chr(ord($1)-1)/ge''

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

I''ll go with a general response, re push vs pull:

Pull is generally preferred in these settings because the server is
not forced to be updated, but requests them. Security is a big reason,
since the client does not have an open port it is less likely to be
attacked. Another reason is consistency, if individual clients are
failing to listen, then different clients will have different settings
(push). If the server fails, all clients remain constant, though
frozen in time.

Push has the limitation that the client has to be receiving, firewalls
in ever network / area / zone to allow traffic in (see security above)
make a push less desirable.

Cheers
chakkerz
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Joel Merrick wrote:
> Hi guys,
> 
> I''ve got a few questions regarding Puppet. We''re
currently investigating
> it for deployment at the ISP where I work.
> 
> Here''s some questions that have been raised;
> 
> Why the pull architecture?
> 
> How can this be achieved using a push, what are the limitations?
I can''t really speak to the original design decisions about push vs
pull, but
you can get roughly the push behavior via "puppetrun".  What happens
is that
you configure the puppet client to listen on a port.  When it receives an 
authenticated puppetrun request on that port, it triggers a run.  The client 
still does a pull from the client, but it gives you the ability to trigger 
runs in a more centralized push like fashion.
> What are the implications of using puppet on legacy systems?
In general, puppet is only as heavy handed as your manifest.  For example, if 
you use puppet to install a particular package, it won''t by default add
or
remove any other packages on the system.  Likewise, if you use the user type 
to set the display name of a user account, it won''t touch the password
value.

Overall, this means that puppet doesn''t make the process of wrangling 
previously ad-hoc managed systems into a fully puppet managed setup any more 
painful than it has to be.  We''re in the process of making that
transition
here, and puppet has allowed us to do things in a very gradual fashion.

> How do you stage the updates (testing)?
Larger sites, or ones with lots of churn, typically put the puppet manifests 
under version control.  They can then have a production branch, development 
branch, etc as needed that applies to the entire host configuration.

In addition, puppet environments let you use a single puppetmaster.  Each 
environment has a totally separate manifest, so you can have conflicting 
versions of classes existing in different environments.  You would have each 
environment fed by a different branch of your manifest.  At that point, you 
can apply existing devel/testing/production type processes to keep things 
under control.

-- 
Frank Sweetser fs at wpi.edu  |  For every problem, there is a solution that
WPI Senior Network Engineer   |  is simple, elegant, and wrong. - HL Mencken
     GPG fingerprint = 6174 1257 129E 0D21 D8D4  E8A3 8E39 29E3 E2E8 8CEC

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