Hey; Thanks for the responses. I hadn't thought of packages. I will start exploring that option
Thanks again. Doug O'Leary On Monday, August 15, 2016 at 3:42:20 PM UTC-5, Rob Nelson wrote: > > Doubt, > > I agree with Dan, packaging is the answer. And before you say it - yes, > packaging sounds scary at first, but it doesn't have to be. Check out FPM - > https://github.com/jordansissel/fpm/wiki - to generate a package in the > correct format. You can very easily package static files that way, and use > file resources with `source => template(...)` for any dynamic files > required. > > Hosting the files is pretty easy if you're using yum, as yumrepos are > built in. You can host them on a node with profile::yumrepo ( > https://github.com/puppetinabox/controlrepo/blob/production/dist/profile/manifests/yumrepo.pp > > and > https://github.com/puppetinabox/controlrepo/blob/production/hiera/puppet_role/yumrepo.yaml), > > throw the rpms in /var/www/html/puppetrepo/el7, and then ensure your base > profile distributes that repo ( > https://github.com/puppetinabox/controlrepo/blob/production/dist/profile/manifests/base.pp#L29-L38). > > That code is dated and needs a little improvement (stop using > `create_resources()`!) but should get you started quickly. I'm sure there's > an equivalent for Apt. > > > Rob Nelson > [email protected] <javascript:> > > On Mon, Aug 15, 2016 at 4:19 PM, Dan Mahoney <[email protected] > <javascript:>> wrote: > >> On Mon, 15 Aug 2016, dkoleary wrote: >> >> Hey; >>> I suspected this was going to be a problem and, sure enough, it is. >>> >>> Here's the scenario: puppet server 4.5: I have ~ 1200 hosts on which I >>> want specific files in /root/bin on all hosts. A reasonably large >>> subset of >>> those should have additional files in /root/bin as part of an home-grown >>> application management process. To be clear, none of the files from the >>> 'all-host' group overlap with any of the files from the 'some-hosts' >>> group. >>> >>> The all-host group is easy enough:: >>> >>> file { '/root/bin': >>> ensure => 'directory', >>> owner => 'root', >>> group => 'root', >>> mode => '0700', >>> recurse => true, >>> source => 'puppet:///modules/myroot/rootbin', >>> require => File['/root'], >>> } >>> >>> So, that's worked for weeks now. In my company's slow migration to >>> puppet >>> management, I'm finally to the point of adding some custom application >>> related files to /root/bin. On the surface, the some-hosts group is >>> pretty >>> easy too:: >>> >>> file { 'webconfbin': >>> ensure => 'directory', >>> path => '/root/bin', >>> owner => 'root', >>> group => 'root', >>> mode => '0700', >>> recurse => true, >>> source => 'puppet:///modules/myroot/webconf', >>> } >>> >>> As I suspected, that resulted in the bright red error message about >>> 'resource /root/bin already declared'. The two options that I can think >>> of >>> aren't particularly appetizing: >>> >>> 1. Add the files from some-hosts to all-hosts resulting in the app >>> management files being everywhere. These files, themselves, don't >>> represent >>> a security issue, but it's not a very clean approach. >>> >>> 2. Use individual file resources. I could get away with that approach >>> on >>> this one; but, when I run into a similar issue with dozens or 100s of >>> files, >>> I'd hate to be specifying all those file resources. >>> >>> Realizing I probably took a wrong turn in my initial design and figuring >>> someone else has to have had run into this problem before, I'm asking the >>> experts. What's the right way to have a set of files on all hosts and a >>> different set of files on a subset of all hosts in the same directory? >>> >> >> I don't often comment on the puppet stuff, but yours made me need to >> chime in and say this: >> >> Recurse is an ugly, awful, terrible hack and should be deprecated. >> >> I don't say that with any knowledge of the way it evolved or what its >> future support status is, but if you look at it -- it's effectively an >> expansion macro that turns into dozens or hundreds of File[] resources (and >> interally -- can and MUST grow your manifest internally in-memory to that >> size). >> >> Judging by the fact that you're using a /bin directory to distribute >> things, which I assume are binaries, or scripts, the thing that makes sense >> here (especially with 1200 hosts) is to look in to using your OS's package >> manager to accomplish this task -- where you could, possibly, break out the >> installables by host-class. (i.e. the files in yoursite-db.rpm would >> require the files in yoursite-common.rpm) >> >> You could, then, use puppet to manage a local installable of that >> distributable, with a notify action that ran the installer -- or you could >> use the builtin package resource type with a local repo, and use require => >> latest to upgrade that, if you have a high change delta. >> >> (Where I say RPM, subsitute OS package manager of choice, obviously). >> >> Yes, this steps outside of puppet, but on its face, puppet is *config* >> management, and what you seem to be trying to do, is not. >> >> -- > > > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/9b736b27-6c5b-42f3-b265-da7250a682f4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
