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] On Mon, Aug 15, 2016 at 4:19 PM, Dan Mahoney <[email protected]> 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/CAC76iT-MRDzRfqwhBeJGhYBweEj2YPjB8TQP1s2VSUp59LoHWg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
