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 <[email protected]> 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 [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
