Puppet users - Sep 2013 - Distributing files from varied sources to a common location on the clients

Very new to Puppet.  Tried various ways to do this and I''m not
particularly
happy with any of them.  

Say I have a common scripts file on my clients: /opt/local/scripts.  I want 
to store the master version of these files in a directory tree on my Puppet 
Master.  Something like this under the module''s directory:  

files/optLocalScripts
files/optLocalScripts/CentOS
files/optLocalScripts/Solaris/sparc
files/optLocalScripts/Solaris/x86
files/optLocalScripts/Common

The idea is that we just have to drop the file in the correct directory, 
and it will get copied out the the clients'' /opt/local/scripts
directory.
Scripts or binaries that are only appropriate for Solaris sparc clients get 
put in files/optLocalScripts/Solaris/sparc, etc., etc., and the 
files/optLocalScripts/Common is for scripts that will run on any platform 
and thus should be copied to all the clients.  

So now if I could write a class that would make proper use of this 
organized directory structure on the Master, that''d be great.  I try to
use
the file resource with "recuse => true".  Works great for one of
the above
sources.  If I pass an array of all those source directories to the file 
resource, it only uses the first directory in the array:

   file { ''/opt/local/scripts'':
      ensure => "present",
      #owner  => "root",
      #group  => "root",
      #mode   => 0755,
      recurse => true,
      source  =>
["puppet:///modules/commonScripts/optLocalScripts/Common",
                  
"puppet:///modules/uts_scripts/optLocalScripts/${operatingsystem}",
                  
"puppet:///modules/uts_scripts/optLocalScripts/${operatingsystem}/${hardwareisa}"],
   } 
 
In the above example, only the files in my Common directory get copied to 
the clients.  Another problem with using this approach is that I cannot 
specify owner or group or any other attributes, or all the other unmanaged 
files on the clients in /opt/local/scripts get changed.  I just want to 
mange the files that I have in the directory structure on the master, not 
other files that may exist on the client.  

I can''t have a separate File resource for each of my Source directories
either.  Why not?  Because they would all be named the same: 
''/opt/local/scripts''.
Okay so it seems that I must then list each file that I wish to manage in 
my class, in addition to keeping the copies on the Master updated.  I was 
hoping to only have to do the latter.  Looking for suggestions.
 
(Hope I explained this clearly.)

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

The first question is why can''t you manage everything in
/opt/local/scripts with puppet?

But assuming that you have to do it the way you describe, here is a
terrible solution: manage subdirectories of /opt/local/scripts (e.g.,
/opt/local/scripts/Common, /opt/local/scripts/redhat).  Then you can
have a separate resource for each directory.  Here is where it gets
terrible.  Create an exec resource that symlinks everything in those
subdirectories into /opt/local/scripts (and maybe removes stale
symlinks if you want to get fancy).

I said it was terrible, didn''t I?

Seriously, I think the correct way to do this is to roll packages
(rpm, deb, pkg, etc.) and distribute those with puppet, but that might
be a lot of work in your environment.

- Chad

On Fri, Sep 13, 2013 at 3:35 PM, root <clri.c0t0d0@gmail.com>
wrote:
> Very new to Puppet.  Tried various ways to do this and I''m not
particularly
> happy with any of them.
>
> Say I have a common scripts file on my clients: /opt/local/scripts.  I want
> to store the master version of these files in a directory tree on my Puppet
> Master.  Something like this under the module''s directory:
>
> files/optLocalScripts
> files/optLocalScripts/CentOS
> files/optLocalScripts/Solaris/sparc
> files/optLocalScripts/Solaris/x86
> files/optLocalScripts/Common
>
> The idea is that we just have to drop the file in the correct directory,
and
> it will get copied out the the clients'' /opt/local/scripts
directory.
> Scripts or binaries that are only appropriate for Solaris sparc clients get
> put in files/optLocalScripts/Solaris/sparc, etc., etc., and the
> files/optLocalScripts/Common is for scripts that will run on any platform
> and thus should be copied to all the clients.
>
> So now if I could write a class that would make proper use of this
organized
> directory structure on the Master, that''d be great.  I try to use
the file
> resource with "recuse => true".  Works great for one of the
above sources.
> If I pass an array of all those source directories to the file resource, it
> only uses the first directory in the array:
>
>    file { ''/opt/local/scripts'':
>       ensure => "present",
>       #owner  => "root",
>       #group  => "root",
>       #mode   => 0755,
>       recurse => true,
>       source  =>
["puppet:///modules/commonScripts/optLocalScripts/Common",
>
>
"puppet:///modules/uts_scripts/optLocalScripts/${operatingsystem}",
>
>
"puppet:///modules/uts_scripts/optLocalScripts/${operatingsystem}/${hardwareisa}"],
>    }
>
> In the above example, only the files in my Common directory get copied to
> the clients.  Another problem with using this approach is that I cannot
> specify owner or group or any other attributes, or all the other unmanaged
> files on the clients in /opt/local/scripts get changed.  I just want to
> mange the files that I have in the directory structure on the master, not
> other files that may exist on the client.
>
> I can''t have a separate File resource for each of my Source
directories
> either.  Why not?  Because they would all be named the same:
> ''/opt/local/scripts''.
>
> Okay so it seems that I must then list each file that I wish to manage in
my
> class, in addition to keeping the copies on the Master updated.  I was
> hoping to only have to do the latter.  Looking for suggestions.
>
> (Hope I explained this clearly.)
>
> --
> 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.


-- 
Chad M. Huneycutt

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

I could manage everything in /opt/local/scripts, but then if I wanted to 
choose which files to deploy based on OS or platform, I''d have to list
each
file inside my class.  I thought it would be nice and simple to just have 
people drop a script in the correct sub-folder, and it would get deployed 
to the /opt/local/scripts directory on the appropriate clients.  Now it 
looks like I will be using the sub-folders on the Master to organize my 
various scripts, but I''ll still be listing each one in the class.
>> Create an exec resource that symlinks 
Ah, symlinks — is there are problem they cannot solve?  

Thanks.  


On Friday, September 13, 2013 6:41:07 PM UTC-4, Chad Huneycutt
wrote:
>
> The first question is why can''t you manage everything in 
> /opt/local/scripts with puppet? 
>
> But assuming that you have to do it the way you describe, here is a 
> terrible solution: manage subdirectories of /opt/local/scripts (e.g., 
> /opt/local/scripts/Common, /opt/local/scripts/redhat).  Then you can 
> have a separate resource for each directory.  Here is where it gets 
> terrible.  Create an exec resource that symlinks everything in those 
> subdirectories into /opt/local/scripts (and maybe removes stale 
> symlinks if you want to get fancy). 
>
> I said it was terrible, didn''t I? 
>
> Seriously, I think the correct way to do this is to roll packages 
> (rpm, deb, pkg, etc.) and distribute those with puppet, but that might 
> be a lot of work in your environment. 
>
> - Chad 
>
> On Fri, Sep 13, 2013 at 3:35 PM, root <clri....@gmail.com
<javascript:>>
> wrote: 
> > Very new to Puppet.  Tried various ways to do this and I''m
not
> particularly 
> > happy with any of them. 
> > 
> > Say I have a common scripts file on my clients: /opt/local/scripts.  I
> want 
> > to store the master version of these files in a directory tree on my 
> Puppet 
> > Master.  Something like this under the module''s directory: 
> > 
> > files/optLocalScripts 
> > files/optLocalScripts/CentOS 
> > files/optLocalScripts/Solaris/sparc 
> > files/optLocalScripts/Solaris/x86 
> > files/optLocalScripts/Common 
> > 
> > The idea is that we just have to drop the file in the correct
directory,
> and 
> > it will get copied out the the clients'' /opt/local/scripts
directory.
> > Scripts or binaries that are only appropriate for Solaris sparc
clients
> get 
> > put in files/optLocalScripts/Solaris/sparc, etc., etc., and the 
> > files/optLocalScripts/Common is for scripts that will run on any 
> platform 
> > and thus should be copied to all the clients. 
> > 
> > So now if I could write a class that would make proper use of this 
> organized 
> > directory structure on the Master, that''d be great.  I try to
use the
> file 
> > resource with "recuse => true".  Works great for one of
the above
> sources. 
> > If I pass an array of all those source directories to the file
resource,
> it 
> > only uses the first directory in the array: 
> > 
> >    file { ''/opt/local/scripts'': 
> >       ensure => "present", 
> >       #owner  => "root", 
> >       #group  => "root", 
> >       #mode   => 0755, 
> >       recurse => true, 
> >       source  => 
> ["puppet:///modules/commonScripts/optLocalScripts/Common", 
> > 
> >
"puppet:///modules/uts_scripts/optLocalScripts/${operatingsystem}",
> > 
> > 
>
"puppet:///modules/uts_scripts/optLocalScripts/${operatingsystem}/${hardwareisa}"],
>
> >    } 
> > 
> > In the above example, only the files in my Common directory get copied
> to 
> > the clients.  Another problem with using this approach is that I
cannot
> > specify owner or group or any other attributes, or all the other 
> unmanaged 
> > files on the clients in /opt/local/scripts get changed.  I just want
to
> > mange the files that I have in the directory structure on the master, 
> not 
> > other files that may exist on the client. 
> > 
> > I can''t have a separate File resource for each of my Source
directories
> > either.  Why not?  Because they would all be named the same: 
> > ''/opt/local/scripts''. 
> > 
> > Okay so it seems that I must then list each file that I wish to manage
> in my 
> > class, in addition to keeping the copies on the Master updated.  I was
> > hoping to only have to do the latter.  Looking for suggestions. 
> > 
> > (Hope I explained this clearly.) 
> > 
> > -- 
> > 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...@googlegroups.com <javascript:>. 
> > To post to this group, send email to
puppet...@googlegroups.com<javascript:>.
>
> > Visit this group at http://groups.google.com/group/puppet-users. 
> > For more options, visit https://groups.google.com/groups/opt_out. 
>
>
>
> -- 
> Chad M. Huneycutt 
>
-- 
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.

I could manage everything in /opt/local/scripts, but then if I wanted to 
choose which files to deploy based on OS or platform, I''d have to list
each
file inside my class.  I thought it would be nice and simple to just have 
people drop a script in the correct sub-folder, and it would get deployed 
to the /opt/local/scripts directory on the appropriate clients.  Now it 
looks like I will be using the sub-folders on the Master to organize my 
various scripts, but I''ll still be listing each one in the class.
>> Create an exec resource that symlinks 
Ah, symlinks — is there any problem they cannot solve?  

Thanks.  

On Friday, September 13, 2013 6:41:07 PM UTC-4, Chad Huneycutt
wrote:
>
> The first question is why can''t you manage everything in 
> /opt/local/scripts with puppet? 
>
> But assuming that you have to do it the way you describe, here is a 
> terrible solution: manage subdirectories of /opt/local/scripts (e.g., 
> /opt/local/scripts/Common, /opt/local/scripts/redhat).  Then you can 
> have a separate resource for each directory.  Here is where it gets 
> terrible.  Create an exec resource that symlinks everything in those 
> subdirectories into /opt/local/scripts (and maybe removes stale 
> symlinks if you want to get fancy). 
>
> I said it was terrible, didn''t I? 
>
> Seriously, I think the correct way to do this is to roll packages 
> (rpm, deb, pkg, etc.) and distribute those with puppet, but that might 
> be a lot of work in your environment. 
>
> - Chad 
>
> On Fri, Sep 13, 2013 at 3:35 PM, root <clri....@gmail.com
<javascript:>>
> wrote: 
> > Very new to Puppet.  Tried various ways to do this and I''m
not
> particularly 
> > happy with any of them. 
> > 
> > Say I have a common scripts file on my clients: /opt/local/scripts.  I
> want 
> > to store the master version of these files in a directory tree on my 
> Puppet 
> > Master.  Something like this under the module''s directory: 
> > 
> > files/optLocalScripts 
> > files/optLocalScripts/CentOS 
> > files/optLocalScripts/Solaris/sparc 
> > files/optLocalScripts/Solaris/x86 
> > files/optLocalScripts/Common 
> > 
> > The idea is that we just have to drop the file in the correct
directory,
> and 
> > it will get copied out the the clients'' /opt/local/scripts
directory.
> > Scripts or binaries that are only appropriate for Solaris sparc
clients
> get 
> > put in files/optLocalScripts/Solaris/sparc, etc., etc., and the 
> > files/optLocalScripts/Common is for scripts that will run on any 
> platform 
> > and thus should be copied to all the clients. 
> > 
> > So now if I could write a class that would make proper use of this 
> organized 
> > directory structure on the Master, that''d be great.  I try to
use the
> file 
> > resource with "recuse => true".  Works great for one of
the above
> sources. 
> > If I pass an array of all those source directories to the file
resource,
> it 
> > only uses the first directory in the array: 
> > 
> >    file { ''/opt/local/scripts'': 
> >       ensure => "present", 
> >       #owner  => "root", 
> >       #group  => "root", 
> >       #mode   => 0755, 
> >       recurse => true, 
> >       source  => 
> ["puppet:///modules/commonScripts/optLocalScripts/Common", 
> > 
> >
"puppet:///modules/uts_scripts/optLocalScripts/${operatingsystem}",
> > 
> > 
>
"puppet:///modules/uts_scripts/optLocalScripts/${operatingsystem}/${hardwareisa}"],
>
> >    } 
> > 
> > In the above example, only the files in my Common directory get copied
> to 
> > the clients.  Another problem with using this approach is that I
cannot
> > specify owner or group or any other attributes, or all the other 
> unmanaged 
> > files on the clients in /opt/local/scripts get changed.  I just want
to
> > mange the files that I have in the directory structure on the master, 
> not 
> > other files that may exist on the client. 
> > 
> > I can''t have a separate File resource for each of my Source
directories
> > either.  Why not?  Because they would all be named the same: 
> > ''/opt/local/scripts''. 
> > 
> > Okay so it seems that I must then list each file that I wish to manage
> in my 
> > class, in addition to keeping the copies on the Master updated.  I was
> > hoping to only have to do the latter.  Looking for suggestions. 
> > 
> > (Hope I explained this clearly.) 
> > 
> > -- 
> > 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...@googlegroups.com <javascript:>. 
> > To post to this group, send email to
puppet...@googlegroups.com<javascript:>.
>
> > Visit this group at http://groups.google.com/group/puppet-users. 
> > For more options, visit https://groups.google.com/groups/opt_out. 
>
>
>
> -- 
> Chad M. Huneycutt 
>
-- 
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.