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 <[email protected] <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 [email protected] <javascript:>. > > To post to this group, send email to > > [email protected]<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 [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.
