Hi John, 2015-11-11 15:43 GMT+01:00 jcbollinger <john.bollin...@stjude.org>:
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 { [...] 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' 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", } } * I don't have the selinux module installed as I don't want to use it. The trivial solution would be installing it. > 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 . > >> 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) > > 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. [... at this point I join your answer from the other e-mail....] Change ::selinux to false (append selinux=0 in the kernel line) and > everything works as expected. > > > still (very) confused.... > It is plausible that disabling selinux on the machine would result in > selinux-related classes declaring no resources, or otherwise behaving > differently then when selinux is enabled. That would be a function of the > classes involved, but the enablement status would be visible to them via a > node fact. I'm inclined to think that the behavior change you describe > arises from such a provision, but I cannot be sure without reviewing the > classes involved. > yes, it's plausible, but looking into nagios code again, it refers to : if $selinux and $::selinux_enforced { ::selinux_eforced = true because selinux is enabled during installation. but I though that $selinux value inside nagios::client class _should_ come from hiera as it's nagios::client::hiera. this is my mistake, am I wrong? and after the reboot puppet runs because all selinux variables (facts) equal to false as selinux has been disabled after reboot. I'm not setting the variable properly in hiera. > 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? Again, thanks to all of you for your answers, Best, Arnau -- 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/CAM69jx_3SV0vwPaRJ63WM%3DHDBa0mFPY%2B3VxCDWrkKrTa8S%3D0hQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
