Puppet users - Jun 2010 - Automated installation of Puppetmaster and Dashboard

Hi.


We''re going to set up Puppetmaster and Dashboard, and would like to
automate the installation process. Have anyone made scripts or puppet
manifests for installing these and would like to share?


- kenneho

-- 
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.

> We''re going to set up Puppetmaster and Dashboard, and would like
to
> automate the installation process. Have anyone made scripts or puppet
> manifests for installing these and would like to share?
I''m not aware of any specific examples, but do a search at
http://github.com/ if you haven''t already done so.  There''s a
few
folks (inc me) who have shared manifests to install/control puppet.
At very least, could maybe get you started on your own efforts.

I''ve reecntly been working on a puppet module to automate the
installation/configuration of a puppetmaster using passenger.  I''m
quite new to puppet, so my manifests might not be a great example of
best practice, but feel free to take a look...
http://github.com/liquidstate/puppet-puppet/

As an aside, I''d welcome critique of my manifests in the style of Wil
Shipley''s "pimp my code"!

Cheers,
Bryan

-- 
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.

Hi Bryan,

I was just looking over your puppet-puppet recipe and I was curious on
how you are managing your different target environments.  I see that
you have defined different trees for each environment:
[development]
    manifest = /etc/puppet/environments/development/site.pp
    modulepath = /etc/puppet/environments/development/modules

# Define testing environment
[testing]
    manifest = /etc/puppet/environments/testing/site.pp
    modulepath = /etc/puppet/environments/testing/modules

# Define production environment
[production]
    manifest = /etc/puppet/environments/production/site.pp
    modulepath = /etc/puppet/environments/production/modules

So I am assuming that you must need to maintain 3 different trees of
code for all of your classes?  What I am trying to do is avoid that
but am concerned about edits of classes, etc that can trickle out to
production before they have been properly QA''d.  I haven''t
read much
on how best to do this and have been working on a completely different
approach.  I would be interested in how you are handling that.

Thanks,

John

On Jun 17, 11:23 am, Bryan Ross <br...@liquidstate.net>
wrote:
> > We''re going to set up Puppetmaster and Dashboard, and would
like to
> > automate the installation process. Have anyone made scripts or puppet
> > manifests for installing these and would like to share?
>
> I''m not aware of any specific examples, but do a search
athttp://github.com/if you haven''t already done so.  There''s a
few
> folks (inc me) who have shared manifests to install/control puppet.
> At very least, could maybe get you started on your own efforts.
>
> I''ve reecntly been working on a puppet module to automate the
> installation/configuration of a puppetmaster using passenger.  I''m
> quite new to puppet, so my manifests might not be a great example of
> best practice, but feel free to take a
look...http://github.com/liquidstate/puppet-puppet/
>
> As an aside, I''d welcome critique of my manifests in the style of
Wil
> Shipley''s "pimp my code"!
>
> Cheers,
> Bryan
-- 
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.

On Thu, Jun 17, 2010 at 4:23 PM, PBWebGuy <pbwebguy@gmail.com>
wrote:
> Hi Bryan,
>
> I was just looking over your puppet-puppet recipe and I was curious on
> how you are managing your different target environments.  I see that
> you have defined different trees for each environment:
> [development]
>    manifest = /etc/puppet/environments/development/site.pp
>    modulepath = /etc/puppet/environments/development/modules
>
> # Define testing environment
> [testing]
>    manifest = /etc/puppet/environments/testing/site.pp
>    modulepath = /etc/puppet/environments/testing/modules
>
> # Define production environment
> [production]
>    manifest = /etc/puppet/environments/production/site.pp
>    modulepath = /etc/puppet/environments/production/modules
>
> So I am assuming that you must need to maintain 3 different trees of
> code for all of your classes?  What I am trying to do is avoid that
> but am concerned about edits of classes, etc that can trickle out to
> production before they have been properly QA''d.  I
haven''t read much
> on how best to do this and have been working on a completely different
> approach.  I would be interested in how you are handling that.
The normal process is to never commit directly to testing or
production, but to only ever integrate from:

development -> testing -> production.

You''re not really maintaining different trees, you''re serving
different revisions of the same data. Always commit to development
only.


>
> Thanks,
>
> John
>
> On Jun 17, 11:23 am, Bryan Ross <br...@liquidstate.net> wrote:
>> > We''re going to set up Puppetmaster and Dashboard, and
would like to
>> > automate the installation process. Have anyone made scripts or
puppet
>> > manifests for installing these and would like to share?
>>
>> I''m not aware of any specific examples, but do a search
athttp://github.com/if you haven''t already done so.  There''s a
few
>> folks (inc me) who have shared manifests to install/control puppet.
>> At very least, could maybe get you started on your own efforts.
>>
>> I''ve reecntly been working on a puppet module to automate the
>> installation/configuration of a puppetmaster using passenger.
 I''m
>> quite new to puppet, so my manifests might not be a great example of
>> best practice, but feel free to take a
look...http://github.com/liquidstate/puppet-puppet/
>>
>> As an aside, I''d welcome critique of my manifests in the style
of Wil
>> Shipley''s "pimp my code"!
>>
>> Cheers,
>> Bryan
>
> --
> 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.
>
>


-- 
nigel

-- 
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.

Hello

Is there any way to have a user with two different passwords.

I have a user that is present in our prod and non prod environments. 
However the password for non-prod is different than prod.  Anyway I can 
arrange that in puppet? 

-- 
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.

Hi,

IMHO the best way will be to develop a small fact that indicates whether
it''s a prod or non-prod environment and use it in the ressource to
select
the right password :

user {"my-user":
  ensure => present,
  password => $yourfact ? {
    ''prod'' => ''production-password'',
    ''non-prod'' =>
''non-production-password'',
  },
  ...
}

Note that the fact used for the selection could be also the hostname of the
server or anything other that can determine if it''s a prod or non-prod
environment.

Cheers,
Mathieu

On Fri, Jun 18, 2010 at 5:50 AM, Marek Dohojda <chrobry@gmail.com> wrote:
> Hello
>
> Is there any way to have a user with two different passwords.
>
> I have a user that is present in our prod and non prod environments.
> However the password for non-prod is different than prod.  Anyway I can
> arrange that in puppet?
> --
> 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<puppet-users%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>
-- 
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.

> On Thu, Jun 17, 2010 at 4:23 PM, PBWebGuy <pbwebguy@gmail.com> wrote:
>> I was just looking over your puppet-puppet recipe and I was curious on
>> how you are managing your different target environments.  I see that
>> you have defined different trees for each environment:
>> ...
>> So I am assuming that you must need to maintain 3 different trees of
>> code for all of your classes?  What I am trying to do is avoid that
>> but am concerned about edits of classes, etc that can trickle out to
>> production before they have been properly QA''d.  I
haven''t read much
>> on how best to do this and have been working on a completely different
>> approach.  I would be interested in how you are handling that.
My actual usage gets a bit more complicated, but as Nigel suggested, I
generally have a single repository of code and each environment
represents a different point in time "snapshot" of that codebase.  All
my changes are checked in to ''development''.  When I''m
happy that the
dev codebase is fairly stable, I''ll then copy/tag that codebase, which
can be checked out to the ''testing'' environment.  If that
codebase
performs as expected, then it gets checked out to production.  Im
currently using SVN, so this fairly trivial to do - just create a
''cheap copy'' of the current repo and tag it with an
appropriate name
(based on release version / date for me)

Hope that helps,

Cheers,
Bryan

-- 
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.