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+unsubscr...@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.
