On Wednesday, November 11, 2015 at 11:58:19 AM UTC-6, Arnau wrote:
>
>
> Hi John,
>
> 2015-11-11 15:43 GMT+01:00 jcbollinger <john.bo...@stjude.org
> <javascript:>>:
>
>
> first of all, let me thanks for your answer,
>
> [...]
>
> 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.
>>
>
> Sure, no problem at all. In the orginal question I refered to the module I
> was using (https://forge.puppetlabs.com/thias/nagios/dependencies).
> Let me try to give you all the information:
>
> The relevant part of code :
>
> The nagios class:
>
> "nagios/manifests/client.pp"
> class nagios::client (
> [...tons of parmaeters....]
> $selinux = true
> ) inherits ::nagios::params {
> [...]
>
>
So, importantly, class nagios::client does have a class parameter
$::nagios::client::selinux. Its value defaults to the boolean value true
if it is not otherwise specified.
On the other hand, checking the full source shows that there is no class
parameter $::nagios::client::selinux_enforced.
> my base profile:
>
> class profiles::base {
> contain ntp
> contain resolv
> contain smtp
> contain ssh
> contain common
> contain puppet::agent
> contain repos
> contain nagios::client
>
> [...Order...]
>
> }
>
> My hiera conf:
>
> $ grep selinux hieradb/defaults.yaml
> nagios::client::selinux: 'false'
> nagios::client::selinux_enforced: 'false'
>
>
Because there is no class parameter $::nagios::client::selinux_enforced,
providing data for key "nagios::client::selinux_enforced" probably has no
observable effect on catalog building. It's unlikely to be directly
harmful to provide that data, but doing so could be confusing.
>
> and the error (Parser error- > undefined type) refer to line 160 of
> client.pp:
>
>
> # With selinux, some nrpe plugins require additional rules to work
> if $selinux and $::selinux_enforced {
> selinux::audit2allow { 'nrpe':
> source => "puppet:///modules/${module_name}/messages.nrpe",
> }
> }
>
>
Note that the condition is based on global variable $::selinux_enforced,
which takes its value from a node fact. Setting a value in Hiera for key
"nagios::client::selinux_enforced" has no effect on the value of that
variable. This also explains why disabling selinux on the client alters
Puppet's observed behavior.
> * I don't have the selinux module installed as I don't want to use it. The
> trivial solution would be installing it.
>
I submit that it is a poor choice to install a puppet module but to
intentionally avoid installing all of that module's dependencies. However,
although installing the selinux module ought to resolve the problem
*manifestation*, the real problem is that during kickstart, the master is
not using the correct data for the node. That should be resolved, as it
might cause other, less visible, problems, either now or in the future.
>
>
>> 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?
>>
>
> I've created this tag and only ntp class includes it.
> the ntp class is a in-house developed class that does not include any
> other one : package -> file -> service .
>
>
Ok.
>
>>
>>> 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?
>>
>
> I'll try to add some screenshot (sorry, VMware web client... can't copy
> and paste).
> But it's a parser error in line 160 of client.pp because it does not know
> the type. (Sorry, I should be more precise in this key point)
>
Ok, good enough for me.
>
>
>>
>> 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.
>>
>
> yes, both runs report differnt facts. As you already know, selinux
> changes its value.
> puppet is run in cron mode, so there are no puppet in between.
>
>
>> 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).
>>
>
> No, I'm sure about the env it runs during the installation and after it.
> only my environment has the nagios class and only my uses hiera.
> I should not pasted different commands becasue they are the same. I just
> copied & pasted from another terminal.
>
The fact remains that by far the most plausible explanations for the
observed behavior difference revolve around the variable interpolations on
which your Hiera hierarchy relies. I remain suspicious of the environment
chosen, as you have data only for a non-default environment, and Hiera not
providing any data would certainly produce the effect you observe.
I suggest switching your focus from the client to the master for a bit:
kickstart a node, and look in the master's logs / puppetdb / node fact
cache to see which environment the node was actually assigned to, and what
facts it reported. Running the master with debug logging enabled might
help here. Look for any Hiera data file that might override the value of
the "nagios::client::selinux" key to true. Don't overlook any files named
".yaml" anywhere in the Hiera data tree; if there are any, then by default
they will not be presented in directory listings, but it's conceivable that
Hiera would read and use such files under certain circumstances.
>
>> More generally, it would be helpful both to you and to us if you could
>> narrow down the failure case as much as possible, and present a complete,
>> minimal example with which we could reproduce the problem. There's far too
>> much that we don't know about your manifest set and data; without (much)
>> more, it's difficult for us to offer more than guesswork.
>>
>
> I think I've asked the proper question now.... did I?
>
>
You have not provided all that I asked: a complete, minimal example with
which we could reproduce the problem. Nevertheless, what you did provide
answers several questions, enough so to move forward.
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/8b3e6dc8-e0b0-4b47-b6d5-cbfea270ec8a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
