On Tuesday, November 10, 2015 at 7:19:49 AM UTC-6, Arnau wrote: > ** Hiera works and returns the expected values:* > > # hiera -c /etc/puppet/hiera.yaml -d classes environment=basic_conf > clientcert=XX > DEBUG: Tue Nov 10 14:14:39 +0100 2015: Hiera YAML backend starting > DEBUG: Tue Nov 10 14:14:39 +0100 2015: Looking up classes in YAML backend > DEBUG: Tue Nov 10 14:14:39 +0100 2015: Looking for data source > basic_conf/hieradb/global > DEBUG: Tue Nov 10 14:14:39 +0100 2015: Looking for data source > basic_conf/hieradb/cert/XX > DEBUG: Tue Nov 10 14:14:39 +0100 2015: Looking for data source > basic_conf/hieradb/env/basic_conf > DEBUG: Tue Nov 10 14:14:39 +0100 2015: Cannot find datafile > /var/lib/puppet-deploy/.../basic_conf.yaml, skipping > DEBUG: Tue Nov 10 14:14:39 +0100 2015: Looking for data source > basic_conf/hieradb/defaults > DEBUG: Tue Nov 10 14:14:39 +0100 2015: Found classes in > basic_conf/hieradb/defaults["profiles::cb::base"] > > # hiera -c /etc/puppet/hiera.yaml -d nagios::client::selinux > environment=basic_cb_conf clientcert=inhas01883.eu.boehringer.com > > [...] > > false > > > My kickstart posinstall section runs puppet like: > > puppet agent --test --tags=kickstart::bootstrap --report --pluginsync > --no-noop > > > *I expect puppet to run, not include selinux and ONLY configure ntp* > >
You haven't given us enough information to judge whether that's a reasonable expectation. First off, you talk about how you are using Hiera to set *variables* of class ::nagios::client, but that can be true only inasmuch as class *parameters* are a special kind of variable, and only if the particular variables you are trying to set are indeed class parameters. Is that the case? My apologies if I sound pedantic, but it is essential that we share a common understanding of the situation. Secondly, all classes declared directly or indirectly by those tagged kickstart::bootstrap will also bear that tag, and if you have a class by that name or any with kickstart::bootstrap:: as a name prefix then those will bear that tag, too. Are you certain there are no such classes that could explain the observed behavior? > But it gives me an error (failed catalog) because *selinux::audit2allow *is > an invlaid resource type. (which means that the nagios variables are not > picked up from hiera (false) so selinux is included) > > Well, maybe it does. The actual error message emitted by the catalog builder might be helpful in tying the error to a specific line in a specific manifest. Without such a clue, it is conceivable that the unwanted declaration is not the one you're looking at. It is a catalog *build* failure you're talking about, right? Not a catalog *application* failure? > If I reboot the node, and run the same exact puppet agent line, then puppet > runs (no selinux complain) and only NTP class is configured: > > # /usr/bin/puppet agent --test --environment=basic_cb_conf > --tags=kickstart::bootstrap > Info: Retrieving pluginfacts > Info: Retrieving plugin > Info: Loading facts > Info: Caching catalog for XXX > Info: Applying configuration version '....' > Notice: /Stage[main]/Ntp/File[/etc/ntp.conf]/content: > --- /etc/ntp.conf 2015-11-10 12:23:14.946909373 +0000 > +++ /tmp/puppet-file20151110-5619-gw8wio-0 2015-11-10 12:24:05.208909327 > +0000 > @@ -1,54 +1,10 @@ > -# For more information about this file, see the man pages > -# ntp.conf(5), ntp_acc(5), ntp_auth(5), ntp_clock(5), ntp_misc(5), > ntp_mon(5).[...] > > the expected behaivour. > > So, what are (or could be) the differences between puppet runs inside the > kickstart postinstall process and puppet runs outside it? > Why is hiera ignored? > > I think it's safe to say that Hiera is not ignored; the unexpected behavior surely arises for a different reason. As to differences, the local machine's state is likely different after the initial reboot than it was in kickstart. This is especially likely if your kickstart configures the agent to run automatically as a daemon, for in that case a catalog run will have been launched as soon as the machine restarted, so that by the time you manually perform your run, Puppet will have already applied the node's full configuration. Even if no other Puppet run happens between the two you are comparing, the agent might well report different fact values in the two cases, and there could be other differences related to when the agent run occurs relative to other actions that take place during kickstart. Also, as others have observed already, your two Puppet commands are *not* the same. Specifying an environment in one case and not doing so in the other is a big distinction if your master is configured to accept the agent's assertion of its environment, and especially when your Hiera hierarchy is environment-specific, as yours is. If neither agent nor ENC explicitly specifies an environment, then the agent is assigned to environment "production". If that's what is being used during kickstart then the master will get different data for the node in the two cases (given the Hiera configuration you provided in another post). 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/93fa0326-8fca-42ad-b3bc-e0ac9bb328cb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
