On Sunday, March 5, 2017 at 6:56:11 PM UTC-6, John Gelnaw wrote:
> I created a second "mount point" in puppet via fileserver.conf, pointing > to a location outside the puppet git tree, so I could use > "puppet:///downloads/<directory>" as a source, synchronized that directory > to a local directory on the workstation using "ensure => directory", > "recurse => true", and "purge => true", then had that resource notify an > exec of "yum install -y *rpm"-- because yum will automatically handle > dependencies, sequence, and upgrades. > > Then any time you drop a new rpm into the directory on the puppet server, > the client automatically downloads and installs and/or upgrades the > packages. > > Not the "Right Way", no, but it does work, and takes less work to add new > packages (my way, drop new RPM in location accessible only by puppet-- > yum/package way, add package to http:// accessible repo, update repo > metadata, and (if needed) add package to node catalog if it's a new package > vs. an upgraded existing package). > That's a viable option. I'd say that its main advantage is avoiding any need to update your manifest set or Hiera data when you want to add a new package to the group. Even that isn't a big win, however: in my environment, it's a one-liner to add a package to my big list of local packages to manage. Nevertheless, it is one fewer piece to get aligned in the right direction, and there is some value in that. All the costs of such an approach should be taken into account, however. One of the more obvious ones is that the full set of RPMs will be maintained locally on each client machine. This could be mitigated by putting the packages on a network drive, so as to avoid any downloading at all, but that does come with its own trade offs. Another cost is somewhat increased security exposure. If someone can obtain sufficient privilege to put their own RPM into the directory containing the local RPM copies, then Puppet will install it along with all the others. That constitutes a privilege escalation attack if it takes more privilege to install packages than it does to drop files in the target directory. Additionally, this approach does not afford an easy way to *remove* packages, though it may be that package removal is rarely needed. John -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/d3e818d4-4b03-4d22-a68e-040b5a886ee8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
