Puppet users - Dec 2009 - Managing the same file from multiple modules/classes/manifests

Hey everyone,

I accidentally sent an earlier (unfinished) version of this message to
the list, but hopefully it was moderated out. In any case, I''m
wondering about the best way to manage the contents of a single file
from multiple modules or maninfests/classes within the same module.
Specifically, I''m trying to manage the entries in /etc/pam.d/system-
auth-ac (we''re running RedHat).

Currently we have a module called ''unix-srr'' that implements
the DISA
unix security guidelines. One of the classes within this module (unix-
srr::pam) implements security settings that are involved with the
system-auth-ac file (password requirements, password history, su
usage). All the unix-srr::pam class does is define a file type that
updates/ensures the local file matches the version in the unix-srr/
files/etc/pam.d/ module directory on the puppetmaster.

Given the above scenario, what would be the best way to add the
ability to configure kerberos based authentication? This will also
require edits to the system-auth-ac file. I would like to put this
into a separate module/class since not all sites will need/require
kerberos authentication. As I see it there are two options:

1. Another class that re-implements the file based approach where the
source system-auth-ac file already includes the unix-srr changes.

2. Another class that implements an Augeas based solution.

I think that we can all agree that Option 1 is a kludge since any
changes to the unix-srr version of the system-auth-ac file will also
have to be made to the kerberos-auth version; otherwise we''d have one
overwriting the other in an infinite loop. Option 2 is viable, but I
am annoyed by the amount of time that is required for changes via
Augeas since by default Augeas parses all files under /etc/. I have
tried setting the ''root'' option of the augeas type to
''/etc/pam.d/''
but this does not work as expected (I also tried this with augtool via
the AUGEAS_ROOT environment variable and it failed as well, so this is
an issue with Augeas and not puppet).

So, does anyone have a suggestion for how to deal with this? I''m
pretty new to puppet so it may well be possible that the layout
described above is fundamentally flawed.

Thanks in advance,

-Dave

--

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.

David Pheasant wrote:
> Hey everyone,
>
> I accidentally sent an earlier (unfinished) version of this message to
> the list, but hopefully it was moderated out. In any case, I''m
> wondering about the best way to manage the contents of a single file
> from multiple modules or maninfests/classes within the same module.
> Specifically, I''m trying to manage the entries in
/etc/pam.d/system-
> auth-ac (we''re running RedHat).
>
> Currently we have a module called ''unix-srr'' that
implements the DISA
> unix security guidelines. One of the classes within this module (unix-
> srr::pam) implements security settings that are involved with the
> system-auth-ac file (password requirements, password history, su
> usage). All the unix-srr::pam class does is define a file type that
> updates/ensures the local file matches the version in the unix-srr/
> files/etc/pam.d/ module directory on the puppetmaster.
>
> Given the above scenario, what would be the best way to add the
> ability to configure kerberos based authentication? This will also
> require edits to the system-auth-ac file. I would like to put this
> into a separate module/class since not all sites will need/require
> kerberos authentication. As I see it there are two options:
>
> 1. Another class that re-implements the file based approach where the
> source system-auth-ac file already includes the unix-srr changes.
>   
The thread 
http://groups.google.com/group/puppet-users/browse_thread/thread/3f6c8cfb36adf6f6
has some ideeas about how to do this.

> 2. Another class that implements an Augeas based solution.
>
> I think that we can all agree that Option 1 is a kludge since any
> changes to the unix-srr version of the system-auth-ac file will also
> have to be made to the kerberos-auth version; otherwise we''d have
one
> overwriting the other in an infinite loop. Option 2 is viable, but I
> am annoyed by the amount of time that is required for changes via
> Augeas since by default Augeas parses all files under /etc/. I have
> tried setting the ''root'' option of the augeas type to
''/etc/pam.d/''
> but this does not work as expected (I also tried this with augtool via
> the AUGEAS_ROOT environment variable and it failed as well, so this is
> an issue with Augeas and not puppet).
>   
Are you sure it''s augeas''s fault? But if you say that augtool
behaves
the same you''re probably right. I haven''t noticed this issue
on my
system... Maybe old version of augeas/puppet?
Maybe it''s because you wrote the message fast but shouldn''t
the root be
/files/etc/pam.d ?

Hope I helped in any way :">
Silviu
> So, does anyone have a suggestion for how to deal with this? I''m
> pretty new to puppet so it may well be possible that the layout
> described above is fundamentally flawed.
>
> Thanks in advance,
>
> -Dave
>
> --
>
> 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.
>
>
>   
--

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.

Silviu,

Thanks for your reply. I''ll take a look at the link you provided.

In regards to Augeas, I had tried every combination i could think of
to get the ''root'' option to work as I expected. For the sake
of sanity
(my own and the list''s) here are a few quick command line tests run on
my test machine...


[root@localhost manifests]# date && augtool -- ls /files && date
Fri Dec 18 09:14:32 EST 2009
boot/ = (none)
etc/ = (none)
Fri Dec 18 09:14:35 EST 2009
[root@localhost manifests]# date && augtool -r /etc/ -- ls /files
&&
date
Fri Dec 18 09:14:58 EST 2009
Fri Dec 18 09:14:59 EST 2009
[root@localhost manifests]# date && augtool -r /etc/pam.d -- ls /files
&& date
Fri Dec 18 09:15:07 EST 2009
Fri Dec 18 09:15:07 EST 2009

-Dave

--

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.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David,

I would place each relevant part into its own file and build the
resulting file at the end of the manifest collection.

This is an example of doing this:
http://reductivelabs.com/trac/puppet/wiki/Recipes/BuildingMultipartFiles

I seem to remember something more elegant out there but I can''t seem to
find it right now.

I was hoping to create a custom type for this type of activity at some
point that would build everything server side but haven''t had the time.

You can also use your PAM class to allow other classes to call out
specific functionality such as unix-srr::pam::kerberos, where the called
item is a specific define.

Lastly, you can allow the setting of specific variables influence what
you include in your PAM settings, but this is a bit error prone in
execution from my experience.

Trevor

On 12/17/2009 08:21 PM, David Pheasant wrote:
> Hey everyone,
> 
> I accidentally sent an earlier (unfinished) version of this message to
> the list, but hopefully it was moderated out. In any case, I''m
> wondering about the best way to manage the contents of a single file
> from multiple modules or maninfests/classes within the same module.
> Specifically, I''m trying to manage the entries in
/etc/pam.d/system-
> auth-ac (we''re running RedHat).
> 
> Currently we have a module called ''unix-srr'' that
implements the DISA
> unix security guidelines. One of the classes within this module (unix-
> srr::pam) implements security settings that are involved with the
> system-auth-ac file (password requirements, password history, su
> usage). All the unix-srr::pam class does is define a file type that
> updates/ensures the local file matches the version in the unix-srr/
> files/etc/pam.d/ module directory on the puppetmaster.
> 
> Given the above scenario, what would be the best way to add the
> ability to configure kerberos based authentication? This will also
> require edits to the system-auth-ac file. I would like to put this
> into a separate module/class since not all sites will need/require
> kerberos authentication. As I see it there are two options:
> 
> 1. Another class that re-implements the file based approach where the
> source system-auth-ac file already includes the unix-srr changes.
> 
> 2. Another class that implements an Augeas based solution.
> 
> I think that we can all agree that Option 1 is a kludge since any
> changes to the unix-srr version of the system-auth-ac file will also
> have to be made to the kerberos-auth version; otherwise we''d have
one
> overwriting the other in an infinite loop. Option 2 is viable, but I
> am annoyed by the amount of time that is required for changes via
> Augeas since by default Augeas parses all files under /etc/. I have
> tried setting the ''root'' option of the augeas type to
''/etc/pam.d/''
> but this does not work as expected (I also tried this with augtool via
> the AUGEAS_ROOT environment variable and it failed as well, so this is
> an issue with Augeas and not puppet).
> 
> So, does anyone have a suggestion for how to deal with this? I''m
> pretty new to puppet so it may well be possible that the layout
> described above is fundamentally flawed.
> 
> Thanks in advance,
> 
> -Dave
> 
> --
> 
> 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.
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAksutUsACgkQyjMdFR1108BnhgCfePQnlpTIPFq++xz/k2Kfp0Dw
VfMAnjIOYnBa1NBst/SXsmYHytbbpLT7
=ZT3+
-----END PGP SIGNATURE-----

--

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.

You wouldn''t by any chance be able to share those DISA SRR manifests to
others would you?    I''ve got to do the same thing here at work and it
could
be a good starting point.



On Thu, Dec 17, 2009 at 8:21 PM, David Pheasant <dpheasant@gmail.com>
wrote:
> Hey everyone,
>
> I accidentally sent an earlier (unfinished) version of this message to
> the list, but hopefully it was moderated out. In any case, I''m
> wondering about the best way to manage the contents of a single file
> from multiple modules or maninfests/classes within the same module.
> Specifically, I''m trying to manage the entries in
/etc/pam.d/system-
> auth-ac (we''re running RedHat).
>
> Currently we have a module called ''unix-srr'' that
implements the DISA
> unix security guidelines. One of the classes within this module (unix-
> srr::pam) implements security settings that are involved with the
> system-auth-ac file (password requirements, password history, su
> usage). All the unix-srr::pam class does is define a file type that
> updates/ensures the local file matches the version in the unix-srr/
> files/etc/pam.d/ module directory on the puppetmaster.
>
> Given the above scenario, what would be the best way to add the
> ability to configure kerberos based authentication? This will also
> require edits to the system-auth-ac file. I would like to put this
> into a separate module/class since not all sites will need/require
> kerberos authentication. As I see it there are two options:
>
> 1. Another class that re-implements the file based approach where the
> source system-auth-ac file already includes the unix-srr changes.
>
> 2. Another class that implements an Augeas based solution.
>
> I think that we can all agree that Option 1 is a kludge since any
> changes to the unix-srr version of the system-auth-ac file will also
> have to be made to the kerberos-auth version; otherwise we''d have
one
> overwriting the other in an infinite loop. Option 2 is viable, but I
> am annoyed by the amount of time that is required for changes via
> Augeas since by default Augeas parses all files under /etc/. I have
> tried setting the ''root'' option of the augeas type to
''/etc/pam.d/''
> but this does not work as expected (I also tried this with augtool via
> the AUGEAS_ROOT environment variable and it failed as well, so this is
> an issue with Augeas and not puppet).
>
> So, does anyone have a suggestion for how to deal with this? I''m
> pretty new to puppet so it may well be possible that the layout
> described above is fundamentally flawed.
>
> Thanks in advance,
>
> -Dave
>
> --
>
> 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.