On Monday, February 22, 2016 at 5:12:24 PM UTC-6, Scott Walker wrote: > > I'm slowly getting up to speed on puppet (coming over from chef but > honestly haven't used either in probably 3 years so I'm relearning the > learning curve.). > > We are using puppet 3.7.1 on our hosts, what I am trying to do is this. > > I have a file /etc/install-class which when we kickstart a machine > depending on what you choose will result in this file having CLASS="some > string" > > I am trying to find the "proper" way to create a cron job based on this > file. > > IE: if /etc/install-class == CLASS=render then create a cron job otherwise > do nothing. > > I know I can hackily get around this with doing it in bash and a onlyif > exec statement. But running a shell, then running grep, is expensive > timewise (yes yes, only a few ms but when trying to get machines built ASAP > ms add up). > > I've done a lot of digging today but I can't seem to figure out an elegant > way to make this work without involving a few modules written by people > (I'm not adverse to using modules but I don't like using a module to do > something rather simple.. or at least what I consider something simple). > > Some thoughts? And thanks in advance for the help. >
Facts are Puppet's mechanism for communicating details of nodes' state to the catalog compiler. There are several ways to plug custom facts <https://docs.puppetlabs.com/facter/2.3/custom_facts.html>. into the system, and having done so, you can use them in your manifests to influence what goes into nodes' catalogs. The traditional way to implement custom facts involves writing a small chunk of Ruby code, but more recently there is a provision for "external facts <https://docs.puppetlabs.com/facter/2.3/custom_facts.html#external-facts>", and it sounds like that flavor of custom fact, would fit especially well with what you already do. Supposing that you are not open to moving or changing the form of the /etc/install-class files (because you must already use them as they are for some other purpose), you would write a separate script that reads that file and emits the fact name and value, in the form Facter interprets. Two things, though: 1. Fact names should be all lower-case 2. Because "class" is a keyword in Puppet DSL, you should not use it as a fact name. The script you want might be as simple as: #!/bin/bash # An executable external fact script for the 'install_class' fact sed -n -e '/^\s*CLASS/ s/\s*\w\w*\s*=\s*\(.*\)/install_class=\1/p' < /etc/ install-class Indeed, it might be even simpler than that if you're willing to make more assumptions about the form of the contents of the install-class file. The custom fact documentation describes briefly how you can make Puppet distribute this fact to your clients itself (i.e. via pluginsync), which it will do early enough for the fact to be available on the same Puppet run in which its script is installed. This is the preferred way to install such facts. Having the fact value in hand, you can use it in your manifests to influence which resources are declared for the node, and what their properties are. At the simplest, you might do something like if $::install_class == 'render' { cron { 'render_cron': command => '/usr/bin/some-command arg1 arg2', user => 'root', hour => 1, minute => 15, ensure => 'present' } } in one of the classes applied to your nodes. That will manage the specified cron job for nodes having value 'render' for the fact 'install_class'. If there is reason to anticipate that machines' classes may change without a full re-provisioning, then you might prefer this alternative: cron { 'render_cron': command => '/usr/bin/some-command arg1 arg2', user => 'root', hour => 1, minute => 15, ensure => $::install_class ? { 'render' => 'present', default => 'absent' } } That manages the same cron job as before, but for all nodes. It manages it to be present for those whose install_class fact has the value 'render', and to be absent for all other nodes. Do note, by the way, that it is a bit questionable to rely on nodes to tell the master what configuration they should have. Puppet does support it, and in more explicit ways than I have described, too, but such mechanisms can provide a mechanism for a compromised machine to be used to extract information from Puppet that that machine was not intended to have. There are other considerations, too. Nevertheless, such risks may not concern you for this particular environment. If you want to take this approach then Puppet can support you in that. 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/180aa131-b411-435c-b756-f263daef57b1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
