Puppet users - Nov 2008 - Getting started on puppet transition

Hello Puppet List,

I was hoping to get some help starting looking at moving my current
kickstart baseline to using puppet. I have been reading up on puppet
and really think it would be a great.

I am looking to start by making the right classes in puppet to manage
the configuration details in the %post section of this ks.

There are some CM items that look fairly strait forward to implement (
chmods, killing services, users etc.), however some things like pam.d
management, login management, sshd banner/noroot login, nosuid in
fstab mounts, auditd configuration management, etc. I could use a
little discussion on where to use modules, templates, recipes.

I have attached a ks file with a good portion of what type of CM items
I need to work with so folks can get an idea of what I am trying to
sort out.

Also, I would like to also like to ''tag'' my CM items with
specific
codes to match them with tracking numbers used in other systems. So,
"ITEM001 -> Boot loader with use a password" etc. I am hoping that
puppet can handle this and if necessary remap the ''tags'' if I
go from
Coding X to Coding Y.

Any thoughts, suggestions etc. would be appreciated.

Yours,

Aaron

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

it seems quite simple to translate your kickstart.

First start grouping all of your file permissions and content to logical
units (e.g. audit, ssh, etc )
than for each section, try to implement the file security, and than just see
if your configuration files are dynamic, or they could always be fixed for
the same host type/ os version etc.

if they are dynamic, try to think about templates and facts, if not, just
keep one copy of the file per os/host type whatever and let puppet copy it
for you.

Just give it a try.... :)

Ohad

On Tue, Nov 11, 2008 at 1:33 PM, Aaron Lippold <lippold@gmail.com> wrote:
> Hello Puppet List,
>
> I was hoping to get some help starting looking at moving my current
> kickstart baseline to using puppet. I have been reading up on puppet
> and really think it would be a great.
>
> I am looking to start by making the right classes in puppet to manage
> the configuration details in the %post section of this ks.
>
> There are some CM items that look fairly strait forward to implement (
> chmods, killing services, users etc.), however some things like pam.d
> management, login management, sshd banner/noroot login, nosuid in
> fstab mounts, auditd configuration management, etc. I could use a
> little discussion on where to use modules, templates, recipes.
>
> I have attached a ks file with a good portion of what type of CM items
> I need to work with so folks can get an idea of what I am trying to
> sort out.
>
> Also, I would like to also like to ''tag'' my CM items with
specific
> codes to match them with tracking numbers used in other systems. So,
> "ITEM001 -> Boot loader with use a password" etc. I am hoping
that
> puppet can handle this and if necessary remap the ''tags''
if I go from
> Coding X to Coding Y.
>
> Any thoughts, suggestions etc. would be appreciated.
>
> Yours,
>
> Aaron
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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,

Being a recent convert and having recently gone through the kickstart
process I may be able to offer a couple of pointers while it''s fresh in
my
mind. The postinstall can just be used to pull in the puppet packages and
start script leaving puppet to do the rest. Most of the work in my case
seemed to get done as modules as these required pulling in associated files
and seemed large enough pieces to justify package style treatment

My layout was like this:-

/etc/puppet/templates        #holds .erb files
/etc/puppet/manifests        #holds nodes.pp site.pp
/etc/puppet/manifests/classes    #holds smaller  .pp files that do not
justify full module treatment e.g. motd change
/etc/puppet/manifests/os   # holds os specific classes .eg satellite
registration
/etc/puppet/modules     # holds all the slightly bigger pieces that tend to
pull in other files
/etc/puppet/modules/automount
/etc/puppet/modules/automount/files   # contains auto_master etc
/etc/puppet/modules/automount/manifests   # contains site.pp with the
automount class containing file and service resources
/etc/puppet/modules/sshkeys
/etc/puppet/modules/sshkeys/files
/etc/puppet/modules/sshkeys/manifests
/etc/puppet/modules/ldap
/etc/puppet/modules/ldap/files
/etc/puppet/modules/ldap/manifests
/etc/puppet/modules/apache
/etc/puppet/modules/apache/files
/etc/puppet/modules/apache/templates
/etc/puppet/modules/apache/manifests
/etc/puppet/modules/postfix
/etc/puppet/modules/postfix/files
/etc/puppet/modules/postfix/manifests
/etc/puppet/modules/mysql
/etc/puppet/modules/mysql/files
/etc/puppet/modules/mysql/manifests

To build up the kickstart I would focus on peforming the initial
post-install on your kickstart client. Then, on the puppet server complete a
module and test back on the client (without kickstarting) by running puppetd
in tag mode pointing to the newly configured module:-
puppetd --server <server_name> --test --tags automount

Doing it this way may save lots of repeated kickstarts. Otherwise you will
waste 30mins each time waiting for the os to be rebuild

Having briefly looked at your kickstart file which seems largely about file
tweaks to comply with your security guidelines I guess a lot of it could go
in the classes directory with names such as GEN006520.pp    which could
contain a file resource to do the chmods.
Unfortunately, in-situ file editing does not seem to be one of puppet''s
strong  points at the moment so you may find yourself copying in lots of
files or using workarounds involving exec. Following that same naming scheme
you could create modules in the same way eg /etc/puppet/modules/GEN006255
which would contain subdirs files/ manifests/ templates. The possible
advantage of using that is that your tags would refllect the compliance
points. The downside is that you''ll probably need a look up sheet to
remind
yourself what each bit is doing

I would strongly advise btw, reading the Understanding Puppet book and all
the references in the right hand bar of the wiki  (e.g resources ref, types
ref, style guides etc) but it sounds like in such a security conscious
environment as yours puppet definitely fits the bill as once your systems
are built to that spec puppet will keep them that way

Good luck
Paul

2008/11/11 Aaron Lippold <lippold@gmail.com>
> Hello Puppet List,
>
> I was hoping to get some help starting looking at moving my current
> kickstart baseline to using puppet. I have been reading up on puppet
> and really think it would be a great.
>
> I am looking to start by making the right classes in puppet to manage
> the configuration details in the %post section of this ks.
>
> There are some CM items that look fairly strait forward to implement (
> chmods, killing services, users etc.), however some things like pam.d
> management, login management, sshd banner/noroot login, nosuid in
> fstab mounts, auditd configuration management, etc. I could use a
> little discussion on where to use modules, templates, recipes.
>
> I have attached a ks file with a good portion of what type of CM items
> I need to work with so folks can get an idea of what I am trying to
> sort out.
>
> Also, I would like to also like to ''tag'' my CM items with
specific
> codes to match them with tracking numbers used in other systems. So,
> "ITEM001 -> Boot loader with use a password" etc. I am hoping
that
> puppet can handle this and if necessary remap the ''tags''
if I go from
> Coding X to Coding Y.
>
> Any thoughts, suggestions etc. would be appreciated.
>
> Yours,
>
> Aaron
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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 Wed, Nov 12, 2008 at 8:58 AM, paul matthews
<paulsmatthews@googlemail.com> wrote:
> Hi,
>
> Being a recent convert and having recently gone through the kickstart
> process I may be able to offer a couple of pointers while it''s
fresh in my
> mind. The postinstall can just be used to pull in the puppet packages and
> start script leaving puppet to do the rest. Most of the work in my case
> seemed to get done as modules as these required pulling in associated files
> and seemed large enough pieces to justify package style treatment
>
> My layout was like this:-
>
> /etc/puppet/templates        #holds .erb files
> /etc/puppet/manifests        #holds nodes.pp site.pp
> /etc/puppet/manifests/classes    #holds smaller  .pp files that do not
> justify full module treatment e.g. motd change
> /etc/puppet/manifests/os   # holds os specific classes .eg satellite
> registration
> /etc/puppet/modules     # holds all the slightly bigger pieces that tend to
> pull in other files
> /etc/puppet/modules/automount
> /etc/puppet/modules/automount/files   # contains auto_master etc
> /etc/puppet/modules/automount/manifests   # contains site.pp with the
> automount class containing file and service resources
> /etc/puppet/modules/sshkeys
> /etc/puppet/modules/sshkeys/files
> /etc/puppet/modules/sshkeys/manifests
> /etc/puppet/modules/ldap
> /etc/puppet/modules/ldap/files
> /etc/puppet/modules/ldap/manifests
> /etc/puppet/modules/apache
> /etc/puppet/modules/apache/files
> /etc/puppet/modules/apache/templates
> /etc/puppet/modules/apache/manifests
> /etc/puppet/modules/postfix
> /etc/puppet/modules/postfix/files
> /etc/puppet/modules/postfix/manifests
> /etc/puppet/modules/mysql
> /etc/puppet/modules/mysql/files
> /etc/puppet/modules/mysql/manifests
>
> To build up the kickstart I would focus on peforming the initial
> post-install on your kickstart client. Then, on the puppet server complete
a
> module and test back on the client (without kickstarting) by running
puppetd
> in tag mode pointing to the newly configured module:-
> puppetd --server <server_name> --test --tags automount
I used this type of workflow with I did similar work with the Solaris
SST for our org. Thanks for the tip.
>
> Doing it this way may save lots of repeated kickstarts. Otherwise you will
> waste 30mins each time waiting for the os to be rebuild
>
> Having briefly looked at your kickstart file which seems largely about file
> tweaks to comply with your security guidelines I guess a lot of it could go
> in the classes directory with names such as GEN006520.pp    which could
> contain a file resource to do the chmods.
I was hoping to organize the workload into logical units of
management, such as compliant SSHd setup, banner managment, user / pam
requirements, man page requirments, etc. Then I was hoping that I
could create a map saying "Class X covers GEN1, Gen2, ..., GenN" So
that if the mapping changes or someone wants to use my classes,
modules etc but uses a different coding system to track compliance
then it could be just a matter of remapping.

Compliance to "GENX" is almost more a reporting than it is real CM
since CM is a collection of best practices in my mind.
> Unfortunately, in-situ file editing does not seem to be one of
puppet''s
> strong  points at the moment so you may find yourself copying in lots of
> files or using workarounds involving exec.
I think I only do that a few times but was hoping there were some easy
ways to manage:

* User Setting Requirements
  - MAX, MIN days etc.
  - Password Complexity
  - etc. etc.
* PAM Settings
* AUDITD
  - setting etc.

I guess each of these could use the file copy/module method but that
is just a step above cat > EOF which hopefully we can all get away
from at some point :). It adds an upkeep layer that I was hoping
puppet would allow me to avoid.

Following that same naming scheme
> you could create modules in the same way eg /etc/puppet/modules/GEN006255
> which would contain subdirs files/ manifests/ templates. The possible
> advantage of using that is that your tags would reflect the compliance
> points. The downside is that you''ll probably need a look up sheet
to remind
> yourself what each bit is doing
Agreed. But again, I want to try to keep the coding a level above,
like separating implementation from interface as it were. I want to
try and make my classes, templates and facts reuseable to other users
if I can.

One goal here would be the ability to create an appliance ( apache,
mysql, postgresql, postfix, etc. ) That can easily grab all my orgs
requirements and push them to the OS layer, App layer etc. Only
pulling the pieces of interest to the installed baseline.

Another goal is to remove the hard tie to organization specific
mappings and help generalize to the best practice. At least that is my
goal :).
>
> I would strongly advise btw, reading the Understanding Puppet book and all
> the references in the right hand bar of the wiki  (e.g resources ref, types
> ref, style guides etc) but it sounds like in such a security conscious
> environment as yours puppet definitely fits the bill as once your systems
> are built to that spec puppet will keep them that way
Totally agree. I have read the Pulling Strings book. Is there another
book. Google doesn''t seem to think so. I want to make this CM and IA
stuff easy :) because I am a good lazy SA :).
>
> Good luck
> Paul
>
> 2008/11/11 Aaron Lippold <lippold@gmail.com>
>>
>> Hello Puppet List,
>>
>> I was hoping to get some help starting looking at moving my current
>> kickstart baseline to using puppet. I have been reading up on puppet
>> and really think it would be a great.
>>
>> I am looking to start by making the right classes in puppet to manage
>> the configuration details in the %post section of this ks.
>>
>> There are some CM items that look fairly strait forward to implement (
>> chmods, killing services, users etc.), however some things like pam.d
>> management, login management, sshd banner/noroot login, nosuid in
>> fstab mounts, auditd configuration management, etc. I could use a
>> little discussion on where to use modules, templates, recipes.
>>
>> I have attached a ks file with a good portion of what type of CM items
>> I need to work with so folks can get an idea of what I am trying to
>> sort out.
>>
>> Also, I would like to also like to ''tag'' my CM items
with specific
>> codes to match them with tracking numbers used in other systems. So,
>> "ITEM001 -> Boot loader with use a password" etc. I am
hoping that
>> puppet can handle this and if necessary remap the
''tags'' if I go from
>> Coding X to Coding Y.
>>
>> Any thoughts, suggestions etc. would be appreciated.
>>
>> Yours,
>>
>> Aaron
>>
>>
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Just adding an interested person to the discussion :)

A

On Wed, Nov 12, 2008 at 2:15 PM, Aaron Lippold <lippold@gmail.com>
wrote:
> On Wed, Nov 12, 2008 at 8:58 AM, paul matthews
> <paulsmatthews@googlemail.com> wrote:
>> Hi,
>>
>> Being a recent convert and having recently gone through the kickstart
>> process I may be able to offer a couple of pointers while it''s
fresh in my
>> mind. The postinstall can just be used to pull in the puppet packages
and
>> start script leaving puppet to do the rest. Most of the work in my case
>> seemed to get done as modules as these required pulling in associated
files
>> and seemed large enough pieces to justify package style treatment
>>
>> My layout was like this:-
>>
>> /etc/puppet/templates        #holds .erb files
>> /etc/puppet/manifests        #holds nodes.pp site.pp
>> /etc/puppet/manifests/classes    #holds smaller  .pp files that do not
>> justify full module treatment e.g. motd change
>> /etc/puppet/manifests/os   # holds os specific classes .eg satellite
>> registration
>> /etc/puppet/modules     # holds all the slightly bigger pieces that
tend to
>> pull in other files
>> /etc/puppet/modules/automount
>> /etc/puppet/modules/automount/files   # contains auto_master etc
>> /etc/puppet/modules/automount/manifests   # contains site.pp with the
>> automount class containing file and service resources
>> /etc/puppet/modules/sshkeys
>> /etc/puppet/modules/sshkeys/files
>> /etc/puppet/modules/sshkeys/manifests
>> /etc/puppet/modules/ldap
>> /etc/puppet/modules/ldap/files
>> /etc/puppet/modules/ldap/manifests
>> /etc/puppet/modules/apache
>> /etc/puppet/modules/apache/files
>> /etc/puppet/modules/apache/templates
>> /etc/puppet/modules/apache/manifests
>> /etc/puppet/modules/postfix
>> /etc/puppet/modules/postfix/files
>> /etc/puppet/modules/postfix/manifests
>> /etc/puppet/modules/mysql
>> /etc/puppet/modules/mysql/files
>> /etc/puppet/modules/mysql/manifests
>>
>> To build up the kickstart I would focus on peforming the initial
>> post-install on your kickstart client. Then, on the puppet server
complete a
>> module and test back on the client (without kickstarting) by running
puppetd
>> in tag mode pointing to the newly configured module:-
>> puppetd --server <server_name> --test --tags automount
>
> I used this type of workflow with I did similar work with the Solaris
> SST for our org. Thanks for the tip.
>
>>
>> Doing it this way may save lots of repeated kickstarts. Otherwise you
will
>> waste 30mins each time waiting for the os to be rebuild
>>
>> Having briefly looked at your kickstart file which seems largely about
file
>> tweaks to comply with your security guidelines I guess a lot of it
could go
>> in the classes directory with names such as GEN006520.pp    which could
>> contain a file resource to do the chmods.
>
> I was hoping to organize the workload into logical units of
> management, such as compliant SSHd setup, banner managment, user / pam
> requirements, man page requirments, etc. Then I was hoping that I
> could create a map saying "Class X covers GEN1, Gen2, ..., GenN"
So
> that if the mapping changes or someone wants to use my classes,
> modules etc but uses a different coding system to track compliance
> then it could be just a matter of remapping.
>
> Compliance to "GENX" is almost more a reporting than it is real
CM
> since CM is a collection of best practices in my mind.
>
>> Unfortunately, in-situ file editing does not seem to be one of
puppet''s
>> strong  points at the moment so you may find yourself copying in lots
of
>> files or using workarounds involving exec.
>
> I think I only do that a few times but was hoping there were some easy
> ways to manage:
>
> * User Setting Requirements
>  - MAX, MIN days etc.
>  - Password Complexity
>  - etc. etc.
> * PAM Settings
> * AUDITD
>  - setting etc.
>
> I guess each of these could use the file copy/module method but that
> is just a step above cat > EOF which hopefully we can all get away
> from at some point :). It adds an upkeep layer that I was hoping
> puppet would allow me to avoid.
>
> Following that same naming scheme
>> you could create modules in the same way eg
/etc/puppet/modules/GEN006255
>> which would contain subdirs files/ manifests/ templates. The possible
>> advantage of using that is that your tags would reflect the compliance
>> points. The downside is that you''ll probably need a look up
sheet to remind
>> yourself what each bit is doing
>
> Agreed. But again, I want to try to keep the coding a level above,
> like separating implementation from interface as it were. I want to
> try and make my classes, templates and facts reuseable to other users
> if I can.
>
> One goal here would be the ability to create an appliance ( apache,
> mysql, postgresql, postfix, etc. ) That can easily grab all my orgs
> requirements and push them to the OS layer, App layer etc. Only
> pulling the pieces of interest to the installed baseline.
>
> Another goal is to remove the hard tie to organization specific
> mappings and help generalize to the best practice. At least that is my
> goal :).
>
>>
>> I would strongly advise btw, reading the Understanding Puppet book and
all
>> the references in the right hand bar of the wiki  (e.g resources ref,
types
>> ref, style guides etc) but it sounds like in such a security conscious
>> environment as yours puppet definitely fits the bill as once your
systems
>> are built to that spec puppet will keep them that way
>
> Totally agree. I have read the Pulling Strings book. Is there another
> book. Google doesn''t seem to think so. I want to make this CM and
IA
> stuff easy :) because I am a good lazy SA :).
>
>>
>> Good luck
>> Paul
>>
>> 2008/11/11 Aaron Lippold <lippold@gmail.com>
>>>
>>> Hello Puppet List,
>>>
>>> I was hoping to get some help starting looking at moving my current
>>> kickstart baseline to using puppet. I have been reading up on
puppet
>>> and really think it would be a great.
>>>
>>> I am looking to start by making the right classes in puppet to
manage
>>> the configuration details in the %post section of this ks.
>>>
>>> There are some CM items that look fairly strait forward to
implement (
>>> chmods, killing services, users etc.), however some things like
pam.d
>>> management, login management, sshd banner/noroot login, nosuid in
>>> fstab mounts, auditd configuration management, etc. I could use a
>>> little discussion on where to use modules, templates, recipes.
>>>
>>> I have attached a ks file with a good portion of what type of CM
items
>>> I need to work with so folks can get an idea of what I am trying to
>>> sort out.
>>>
>>> Also, I would like to also like to ''tag'' my CM
items with specific
>>> codes to match them with tracking numbers used in other systems.
So,
>>> "ITEM001 -> Boot loader with use a password" etc. I am
hoping that
>>> puppet can handle this and if necessary remap the
''tags'' if I go from
>>> Coding X to Coding Y.
>>>
>>> Any thoughts, suggestions etc. would be appreciated.
>>>
>>> Yours,
>>>
>>> Aaron
>>>
>>>
>>
>>
>> >>
>>
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

And another ...

Thanks, I am done now :)

A

On Wed, Nov 12, 2008 at 2:15 PM, Aaron Lippold <lippold@gmail.com>
wrote:
> On Wed, Nov 12, 2008 at 8:58 AM, paul matthews
> <paulsmatthews@googlemail.com> wrote:
>> Hi,
>>
>> Being a recent convert and having recently gone through the kickstart
>> process I may be able to offer a couple of pointers while it''s
fresh in my
>> mind. The postinstall can just be used to pull in the puppet packages
and
>> start script leaving puppet to do the rest. Most of the work in my case
>> seemed to get done as modules as these required pulling in associated
files
>> and seemed large enough pieces to justify package style treatment
>>
>> My layout was like this:-
>>
>> /etc/puppet/templates        #holds .erb files
>> /etc/puppet/manifests        #holds nodes.pp site.pp
>> /etc/puppet/manifests/classes    #holds smaller  .pp files that do not
>> justify full module treatment e.g. motd change
>> /etc/puppet/manifests/os   # holds os specific classes .eg satellite
>> registration
>> /etc/puppet/modules     # holds all the slightly bigger pieces that
tend to
>> pull in other files
>> /etc/puppet/modules/automount
>> /etc/puppet/modules/automount/files   # contains auto_master etc
>> /etc/puppet/modules/automount/manifests   # contains site.pp with the
>> automount class containing file and service resources
>> /etc/puppet/modules/sshkeys
>> /etc/puppet/modules/sshkeys/files
>> /etc/puppet/modules/sshkeys/manifests
>> /etc/puppet/modules/ldap
>> /etc/puppet/modules/ldap/files
>> /etc/puppet/modules/ldap/manifests
>> /etc/puppet/modules/apache
>> /etc/puppet/modules/apache/files
>> /etc/puppet/modules/apache/templates
>> /etc/puppet/modules/apache/manifests
>> /etc/puppet/modules/postfix
>> /etc/puppet/modules/postfix/files
>> /etc/puppet/modules/postfix/manifests
>> /etc/puppet/modules/mysql
>> /etc/puppet/modules/mysql/files
>> /etc/puppet/modules/mysql/manifests
>>
>> To build up the kickstart I would focus on peforming the initial
>> post-install on your kickstart client. Then, on the puppet server
complete a
>> module and test back on the client (without kickstarting) by running
puppetd
>> in tag mode pointing to the newly configured module:-
>> puppetd --server <server_name> --test --tags automount
>
> I used this type of workflow with I did similar work with the Solaris
> SST for our org. Thanks for the tip.
>
>>
>> Doing it this way may save lots of repeated kickstarts. Otherwise you
will
>> waste 30mins each time waiting for the os to be rebuild
>>
>> Having briefly looked at your kickstart file which seems largely about
file
>> tweaks to comply with your security guidelines I guess a lot of it
could go
>> in the classes directory with names such as GEN006520.pp    which could
>> contain a file resource to do the chmods.
>
> I was hoping to organize the workload into logical units of
> management, such as compliant SSHd setup, banner managment, user / pam
> requirements, man page requirments, etc. Then I was hoping that I
> could create a map saying "Class X covers GEN1, Gen2, ..., GenN"
So
> that if the mapping changes or someone wants to use my classes,
> modules etc but uses a different coding system to track compliance
> then it could be just a matter of remapping.
>
> Compliance to "GENX" is almost more a reporting than it is real
CM
> since CM is a collection of best practices in my mind.
>
>> Unfortunately, in-situ file editing does not seem to be one of
puppet''s
>> strong  points at the moment so you may find yourself copying in lots
of
>> files or using workarounds involving exec.
>
> I think I only do that a few times but was hoping there were some easy
> ways to manage:
>
> * User Setting Requirements
>  - MAX, MIN days etc.
>  - Password Complexity
>  - etc. etc.
> * PAM Settings
> * AUDITD
>  - setting etc.
>
> I guess each of these could use the file copy/module method but that
> is just a step above cat > EOF which hopefully we can all get away
> from at some point :). It adds an upkeep layer that I was hoping
> puppet would allow me to avoid.
>
> Following that same naming scheme
>> you could create modules in the same way eg
/etc/puppet/modules/GEN006255
>> which would contain subdirs files/ manifests/ templates. The possible
>> advantage of using that is that your tags would reflect the compliance
>> points. The downside is that you''ll probably need a look up
sheet to remind
>> yourself what each bit is doing
>
> Agreed. But again, I want to try to keep the coding a level above,
> like separating implementation from interface as it were. I want to
> try and make my classes, templates and facts reuseable to other users
> if I can.
>
> One goal here would be the ability to create an appliance ( apache,
> mysql, postgresql, postfix, etc. ) That can easily grab all my orgs
> requirements and push them to the OS layer, App layer etc. Only
> pulling the pieces of interest to the installed baseline.
>
> Another goal is to remove the hard tie to organization specific
> mappings and help generalize to the best practice. At least that is my
> goal :).
>
>>
>> I would strongly advise btw, reading the Understanding Puppet book and
all
>> the references in the right hand bar of the wiki  (e.g resources ref,
types
>> ref, style guides etc) but it sounds like in such a security conscious
>> environment as yours puppet definitely fits the bill as once your
systems
>> are built to that spec puppet will keep them that way
>
> Totally agree. I have read the Pulling Strings book. Is there another
> book. Google doesn''t seem to think so. I want to make this CM and
IA
> stuff easy :) because I am a good lazy SA :).
>
>>
>> Good luck
>> Paul
>>
>> 2008/11/11 Aaron Lippold <lippold@gmail.com>
>>>
>>> Hello Puppet List,
>>>
>>> I was hoping to get some help starting looking at moving my current
>>> kickstart baseline to using puppet. I have been reading up on
puppet
>>> and really think it would be a great.
>>>
>>> I am looking to start by making the right classes in puppet to
manage
>>> the configuration details in the %post section of this ks.
>>>
>>> There are some CM items that look fairly strait forward to
implement (
>>> chmods, killing services, users etc.), however some things like
pam.d
>>> management, login management, sshd banner/noroot login, nosuid in
>>> fstab mounts, auditd configuration management, etc. I could use a
>>> little discussion on where to use modules, templates, recipes.
>>>
>>> I have attached a ks file with a good portion of what type of CM
items
>>> I need to work with so folks can get an idea of what I am trying to
>>> sort out.
>>>
>>> Also, I would like to also like to ''tag'' my CM
items with specific
>>> codes to match them with tracking numbers used in other systems.
So,
>>> "ITEM001 -> Boot loader with use a password" etc. I am
hoping that
>>> puppet can handle this and if necessary remap the
''tags'' if I go from
>>> Coding X to Coding Y.
>>>
>>> Any thoughts, suggestions etc. would be appreciated.
>>>
>>> Yours,
>>>
>>> Aaron
>>>
>>>
>>
>>
>> >>
>>
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

>>> Unfortunately, in-situ file editing does not seem to be one of
puppet''s
>>> strong  points at the moment so you may find yourself copying in
lots of
>>> files or using workarounds involving exec.
>>
>> I think I only do that a few times but was hoping there were some easy
>> ways to manage:
>>
>> * User Setting Requirements
>>  - MAX, MIN days etc.
>>  - Password Complexity
>>  - etc. etc.
>> * PAM Settings
>> * AUDITD
>>  - setting etc.
>>
>> I guess each of these could use the file copy/module method but that
>> is just a step above cat > EOF which hopefully we can all get away
>> from at some point :). It adds an upkeep layer that I was hoping
>> puppet would allow me to avoid.
You will be amazed at what templating can do for you here. The
generate function and content attribute has alot of interesting
possibilities to help with this. Assuming you have more or less
standard setting but need to do small tweaks, you use generate
function to call a server side script to create the file data on the
fly from facts and policy scripts. also I see no one has pointed that
if you have a large number of nodes you will probably want to use and
LDAP tree for your node declarations. It is a bit more versatile than
in manifest node definitions and is easier to parse for security audit
tools.

>> Following that same naming scheme
>>> you could create modules in the same way eg
/etc/puppet/modules/GEN006255
>>> which would contain subdirs files/ manifests/ templates. The
possible
>>> advantage of using that is that your tags would reflect the
compliance
>>> points. The downside is that you''ll probably need a look
up sheet to remind
>>> yourself what each bit is doing
>>
>> Agreed. But again, I want to try to keep the coding a level above,
>> like separating implementation from interface as it were. I want to
>> try and make my classes, templates and facts reuseable to other users
>> if I can.
The key here is learning to think like puppet. That is the absolute
hardest part of the equation. Only suggestion I have to help here is
to go back through the examples in Pulling Strings and understand who
the approach there differs from the procedural or "SSH" approach.
>> One goal here would be the ability to create an appliance ( apache,
>> mysql, postgresql, postfix, etc. ) That can easily grab all my orgs
>> requirements and push them to the OS layer, App layer etc. Only
>> pulling the pieces of interest to the installed baseline.
>>
>> Another goal is to remove the hard tie to organization specific
>> mappings and help generalize to the best practice. At least that is my
>> goal :).
>>
>> Totally agree. I have read the Pulling Strings book. Is there another
>> book. Google doesn''t seem to think so. I want to make this CM
and IA
>> stuff easy :) because I am a good lazy SA :).
>>
Not sure about any other books, but James is on the list and really
good at tossing those useful tidbits of knowledge in an understandable
way.

I don''t have near the setup some of the guys on here do, but I can say
that puppet paired with version control for the manifests has really
helped here by forcing a minimum level of documentation to all system
changes and configurations.

Evan

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

Since you mention Kickstart you might have a look at cobbler:
https://fedorahosted.org/cobbler/
coupled with puppet we have a fairly efficient build/install process.
That said, cobbler just builds the initial server spec and installs
puppet.
Puppet then takes over and finishes loading all the configs.

On Nov 12, 1:50 pm, "Evan Hisey" <ehi...@gmail.com>
wrote:
> >>> Unfortunately, in-situ file editing does not seem to be one of
puppet''s
> >>> strong  points at the moment so you may find yourself copying
in lots of
> >>> files or using workarounds involving exec.
>
> >> I think I only do that a few times but was hoping there were some
easy
> >> ways to manage:
>
> >> * User Setting Requirements
> >>  - MAX, MIN days etc.
> >>  - Password Complexity
> >>  - etc. etc.
> >> * PAM Settings
> >> * AUDITD
> >>  - setting etc.
>
> >> I guess each of these could use the file copy/module method but
that
> >> is just a step above cat > EOF which hopefully we can all get
away
> >> from at some point :). It adds an upkeep layer that I was hoping
> >> puppet would allow me to avoid.
>
> You will be amazed at what templating can do for you here. The
> generate function and content attribute has alot of interesting
> possibilities to help with this. Assuming you have more or less
> standard setting but need to do small tweaks, you use generate
> function to call a server side script to create the file data on the
> fly from facts and policy scripts. also I see no one has pointed that
> if you have a large number of nodes you will probably want to use and
> LDAP tree for your node declarations. It is a bit more versatile than
> in manifest node definitions and is easier to parse for security audit
> tools.
>
> >> Following that same naming scheme
> >>> you could create modules in the same way eg
/etc/puppet/modules/GEN006255
> >>> which would contain subdirs files/ manifests/ templates. The
possible
> >>> advantage of using that is that your tags would reflect the
compliance
> >>> points. The downside is that you''ll probably need a
look up sheet to remind
> >>> yourself what each bit is doing
>
> >> Agreed. But again, I want to try to keep the coding a level above,
> >> like separating implementation from interface as it were. I want
to
> >> try and make my classes, templates and facts reuseable to other
users
> >> if I can.
>
> The key here is learning to think like puppet. That is the absolute
> hardest part of the equation. Only suggestion I have to help here is
> to go back through the examples in Pulling Strings and understand who
> the approach there differs from the procedural or "SSH" approach.
>
> >> One goal here would be the ability to create an appliance (
apache,
> >> mysql, postgresql, postfix, etc. ) That can easily grab all my
orgs
> >> requirements and push them to the OS layer, App layer etc. Only
> >> pulling the pieces of interest to the installed baseline.
>
> >> Another goal is to remove the hard tie to organization specific
> >> mappings and help generalize to the best practice. At least that
is my
> >> goal :).
>
> >> Totally agree. I have read the Pulling Strings book. Is there
another
> >> book. Google doesn''t seem to think so. I want to make
this CM and IA
> >> stuff easy :) because I am a good lazy SA :).
>
> Not sure about any other books, but James is on the list and really
> good at tossing those useful tidbits of knowledge in an understandable
> way.
>
> I don''t have near the setup some of the guys on here do, but I can
say
> that puppet paired with version control for the manifests has really
> helped here by forcing a minimum level of documentation to all system
> changes and configurations.
>
> Evan
--~--~---------~--~----~------------~-------~--~----~
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 would strongly advise btw, reading the Understanding Puppet book and
> all
> > the references in the right hand bar of the wiki  (e.g resources ref,
> types
> > ref, style guides etc) but it sounds like in such a security conscious
> > environment as yours puppet definitely fits the bill as once your
systems
> > are built to that spec puppet will keep them that way
>
> Totally agree. I have read the Pulling Strings book. Is there another
> book. Google doesn''t seem to think so. I want to make this CM and
IA
> stuff easy :) because I am a good lazy SA :).

Hi yes, did I say "Understanding Puppet" ? I meant Pulling Strings.
Sorry if
you (or anyone else) spent time looking for the mythical made up one.
>
>
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---