Re: [Puppet Users] Recent 5.5.x point releases are throwing some warnings for me

2019-06-17 Thread lhu
Thanks Ben.

Would you know why this wouldn't work? I have the module manifest folder 
under adhoc/pakg/dan/manifest/

#puppet parser validate init.pp

Warning: Unacceptable location. The name 'adhoc::pkg::dan::init' is 
unacceptable in file 
'/opt/puppetlabs/puppet/modules/adhoc/pkg/dan/manifests/init.pp' (file: 
/opt/puppetlabs/puppet/modules/adhoc/pkg/dan/manifests/init.pp, line: 1, 
column: 1)


So I assumed with the init.pp file this would work? 
class adhoc::pkg::dan {


}

I also tried just using the module name prior to the manifest folder but 
that didn't work as well. 


On Friday, June 14, 2019 at 6:34:34 PM UTC-4, Ben Ford wrote:
>
> Yes. A class without a namespace must be named the same as the module 
> containing it, *and be in the init.pp file*.
>
> In other words, your /opt/puppetlabs/puppet/modules/adhoc/manifests/
> *adhoc*.pp file should be /opt/puppetlabs/puppet/modules/adhoc/manifests/
> *init*.pp.
>
> See https://puppet.com/docs/puppet/latest/modules_fundamentals.html for 
> more information.
>
> On Fri, Jun 14, 2019 at 1:06 PM lhu > wrote:
>
>> Hi John,
>>
>> Would you have any idea why this would fail 
>> file
>> #puppet parser validate adhoc.pp
>> Warning: Unacceptable location. The name 'adhoc' is unacceptable in file 
>> '/opt/puppetlabs/puppet/modules/adhoc/manifests/adhoc.pp' (file: 
>> /opt/puppetlabs/puppet/modules/adhoc/manifests/adhoc.pp, line: 1, column: 1)
>>
>> adhoc.pp file:
>>
>> class adhoc {
>>
>>
>> }
>>
>> I put the file under
>> /opt/puppetlabs/puppet/modules/adhoc/manifests
>> this is running puppet 5.5 on a new install
>>
>> Thanks,
>> Leo
>>
>> On Wednesday, August 29, 2018 at 9:58:32 AM UTC-4, Henrik Lindberg wrote:
>>>
>>> On 2018-08-29 15:11, jcbollinger wrote: 
>>> > 
>>> > 
>>> > On Tuesday, August 28, 2018 at 12:13:15 PM UTC-5, kris.b...@puppet.com 
>>> > wrote: 
>>> > 
>>> > 
>>> > Hi Jon, 
>>> > 
>>> > As you have read, this is part of our work implementing errors to 
>>> > enforce the standards set down in PUP-1434.  In particular, your 
>>> > example '$module_path/seed/manifests/init.pp' looks like it is in 
>>> > the init file of module 'seed'.  Assuming that is what you meant, 
>>> > anything starting with 'seed' would be OK in that file, e.g. 
>>> 'seed', 
>>> > 'seed::remote_file', 'seed::foo::remote_file' would all work.  
>>> Note 
>>> > that as part of point 4. of PUP-1434 (now being implemented in the 
>>> > work of PUP-9020), you will also not be allowed to put things like 
>>> > resources in the top level, but instead should include your 
>>> > resources in a class, define, function, or type declaration. 
>>> > 
>>> > 
>>> > As a matter of style, the usual recommendation is that furthermore, 
>>> > every class and defined type definition be located in its own file 
>>> > , 
>>> > named as predicted from its fully-qualified name.  Of course, this is 
>>> > coupled with assigning an appropriate fully-qualified name.  It is 
>>> > important to understand that class and type names in Puppet are 
>>> > independent of the pathnames of the files in which the class and type 
>>> > definitions appear.  The importance of the pathnames is limited to 
>>> > enabling Puppet to /find/ type and class definitions at runtime. 
>>> > 
>>> > 
>>>
>>> Not quite - what is now starting to be enforced is that definitions 
>>> must be made in a file that is on an accepted path for that definition. 
>>>
>>> Best, 
>>> - henrik 
>>>
>>> > 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...@googlegroups.com 
>>> > . 
>>> > To view this discussion on the web visit 
>>> > 
>>> https://groups.google.com/d/msgid/puppet-users/916271cc-6a49-4374-afe2-d6fe0dff297d%40googlegroups.com
>>>  
>>> > <
>>> https://groups.google.com/d/msgid/puppet-users/916271cc-6a49-4374-afe2-d6fe0dff297d%40googlegroups.com?utm_medium=email_source=footer>.
>>>  
>>>
>>> > For more options, visit https://groups.google.com/d/optout. 
>>>
>>>
>>> -- 
>>>
>>> Visit my Blog "Puppet on the Edge" 
>>> http://puppet-on-the-edge.blogspot.se/ 
>>>
>>> -- 
>> 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...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/puppet-users/dc9b55e8-f5c3-4622-a223-0d5df43e36db%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this 

[Puppet Users] Puppet agent not loading facts when run on puppetserver

2019-06-17 Thread Eirik Øverby
Hi,

We just started our trials with puppet6 (upgrading from puppet5) on FreeBSD, 
and while we think we have a pretty good grip on most things that we need to 
do, there is one mind-bending problem we're having: When running the Puppet 
Agent on the Puppetserver instance itself, it never prints "Loading facts.." 
and then errors out complaining about unassigned variables (like 
$operatingsystemrelease, for instance).

Running 'puppet facts' only gives this:

# puppet facts
{
  "name": "puppet.pmn.nyc.modirum.com",
  "values": {
"trusted": {
  "domain": "pmn.nyc.modirum.com",
  "certname": "puppet.pmn.nyc.modirum.com",
  "hostname": "puppet",
  "extensions": {
  },
  "authenticated": "remote"
}
  },
  "timestamp": "2019-06-17T10:02:03.156284600+00:00"
}

On any other node, we get the usual huge amount of data. Interestingly, running 
'facter -p' also gives the expected result.

Running 'puppet facts --debug' shows indications that it is attempting to laod 
facts (see snippets below), but they aren't printed at the end. Facts caching 
is not the issue (there is no facter config on the puppetserver node, so no 
caching is taking place).

The configuration is exactly the same we've used for puppet5, where the agent 
runs happily on the puppetserver. It has simply been a matter of pkg delete 
puppet* puppetdb* / pkg install puppet6 puppetserver6 puppetdb6 
puppetdb-terminus6.

I have a vage recollection of having seen this problem before, but it's many 
years ago and I have an even more vague recollection (as in none at all) of 
what was done to fix it. It's probably unrelated anyway.

/Eirik

# puppet facts --debug 2>&1 | less -R

Debug: Facter: fact "networking" has resolved to {
  domain => "pmn.nyc.modirum.com",
  fqdn => "puppet.pmn.nyc.modirum.com",
  hostname => "puppet",
  interfaces => {
em0 => {
  bindings => [
{
...

and on to...

Debug: Facter: executing command: /bin/freebsd-version
Debug: Facter: 11.2-RELEASE-p9
Debug: Facter: process exited with status code 0.
Debug: Facter: fact "osfamily" has resolved to "FreeBSD".
Debug: Facter: fact "operatingsystemmajrelease" has resolved to "11".
Debug: Facter: fact "operatingsystemrelease" has resolved to "11.2-RELEASE-p9".
Debug: Facter: fact "hardwaremodel" has resolved to "amd64".
Debug: Facter: fact "architecture" has resolved to "amd64".
Debug: Facter: fact "operatingsystem" has resolved to "FreeBSD".
Debug: Facter: fact "os" has resolved to {
  architecture => "amd64",
  family => "FreeBSD",
  hardware => "amd64",
  name => "FreeBSD",
  release => {
full => "11.2-RELEASE-p9",
major => "11",
minor => "2-RELEASE-p9"
  }
}.

-- 
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/1143BED7-65E0-4280-AE35-85261481BA7B%40anduin.net.
For more options, visit https://groups.google.com/d/optout.