Re: [Puppet Users] Facter 4.0.27 is now available

[Eirik Øverby]

Hi,

I've trying since the initial Facter 4 release to find information on how I can 
use it - with Puppet, specifically. Is that documented anywhere? It would also 
be useful to know what "the big deal" with Facter 4 is. This is also something 
that was referenced in previous announcements here but I have not been able to 
find anything substantial on that. Am I blind? :)

/Eirik

On 6/25/20 9:28 AM, Florin Dragos wrote:
> Hello,
> 
> The Facter team is happy to announce the release of *Facter 4.0.27 
> .*
> *
> *
> Here is what changed:
> 
> 
>   New features
> 
>   * Networking facts for OSX #1929 
> 
>   * FreeBSD disks and partitions facts #553 
> 
>   * Use puppet AIO VERSION file to specify AIO version #549 
> 
>   * EC2 facts for Windows #546 
> 
>   * EC2 facts for Linux #544 
> 
>   * External facts cache #541 
> 
>   * Support for processors facts on *BSD #489 
> 
> 
> 
>   Bug 
> fixes
> 
>   * Networking fact on linux should have logic for selecting IPs #1928 
> 
>   * Facter sometimes pollutes the calling processes environment (race 
> condition) #1932 
> 
> 
> Feel free to reach out onslack 
> or open a ticket 
> onhttps://tickets.puppetlabs.com/projects/FACTwith facter-nglabel. Or, 
> evenbetter, open a PR on the facter  
> repository, targeting the 4.x branch.
> 
> Best regards,
> Florin Dragos
> 
> -- 
> 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/CAAkyxch%3Dd%3DyTTKFKDAsckoLAY%2B73sb6QSWZx8fMUfXEsSE88eA%40mail.gmail.com
>  
> .

-- 
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/c7c97880-c09a-881a-9da6-28c4a7309beb%40anduin.net.

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

[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.

Re: [Puppet Users] How to start puppet master for v6.0.0 or late

[Eirik Øverby]

Ok I have _no_ idea how that happened. Sorry about the noise, folks!
/Eirik

> On 22 May 2019, at 16:05, Eirik Øverby  wrote:
> 
> Hei,
> 
> jeg driver og roter i jailet nå - gi meg noen minutter!
> Er du på noen fornuftig IM-kanal som jeg kan bruke fra laptoppen min?
> 
> /Eirik
> 
>> On 22 May 2019, at 15:52, samding dd  wrote:
>> 
>> Thank you for you reply.
>> 
>> But how to get/build puppetserver on other platform than x86_64?
>> The document of v6.4 says  to get puppetserver by first adding a repository 
>> and then install it as a normal  package. 
>> But I cannot get it for s390x in the same way, probably the repository does 
>> not support it.
>> Is there any way to build to build puppetserver from the Github directly?
>> 
>> Thanks,
>> 
>> 
>> On Wednesday, 22 May 2019 03:25:32 UTC-4, Bart-Jan Vrielink wrote:
>> Hello,
>> 
>> Puppet master has been deprecated for a while and is removed from Puppet 6. 
>> Instead of a puppet master, you should switch to using a puppetserver 
>> instead.
>> See https://puppet.com/docs/puppet/6.0/release_notes_puppet.html#webrick
>> 
>> -Original message-
>> From: samding dd 
>> Sent: Tuesday 21st May 2019 22:10
>> To: Puppet Users 
>> Subject: [Puppet Users] How to start puppet master for v6.0.0 or late
>> 
>> Hi there,
>> 
>> I am new to puppet. 
>> I want to know how to start puppet master for v6.0.0 or late versions. 
>> For version below v6.0.0, I can install puppet by:
>> 
>> 
>>   gem install puppet -v 5.5.14
>> 
>> Then start by :
>> 
>>   puppet master --verbose --no-daemonizepuppet
>> 
>> However, after v6.0.0, there is no subcommand "master" option.
>> 
>> If installing v6.4.2, the "puppet help" shows below:
>> 
>> "puppet]# puppet help
>> 
>> Usage: puppet  [options]  [options]
>> 
>> Available subcommands:
>> 
>>  Common:
>>agent The puppet agent daemon
>>apply Apply Puppet manifests locally
>>configInteract with Puppet's settings.
>>help  Display Puppet help.
>>lookupInteractive Hiera lookup
>>moduleCreates, installs and searches for modules on the 
>> Puppet Forge.
>>resource  The resource abstraction layer shell
>> 
>> 
>>  Specialized:
>>catalog   Compile, save, view, and convert catalogs.
>>describe  Display help about resource types
>>deviceManage remote network devices
>>doc   Generate Puppet references
>>epp   Interact directly with the EPP template parser/renderer.
>>facts Retrieve and store facts.
>>filebucketStore and retrieve files in a filebucket
>>generate  Generates Puppet code from Ruby definitions.
>>node  View and manage node definitions.
>>parserInteract directly with the parser.
>>scriptRun a puppet manifests as a script without compiling a 
>> catalog
>>ssl   Manage SSL keys and certificates for puppet SSL clients 
>> 
>> Thanks,
>> 
>> 
>> 
>> -- 
>> 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/0d3ae17b-e47e-4c79-a631-88c2dc163311%40googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>> 
>> -- 
>> 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/78d5e284-7147-42c6-a9a8-e249d8e6bceb%40googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> 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/ECBBF59E-D7AF-461A-B47E-FEA88C6F3361%40anduin.net.
> For more options, visit https://groups.google.com/d/optout.
> 

-- 
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/5EC2FD36-281B-4D24-A564-D7F6514BCEB1%40anduin.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] How to start puppet master for v6.0.0 or late

[Eirik Øverby]

Hei,

jeg driver og roter i jailet nå - gi meg noen minutter!
Er du på noen fornuftig IM-kanal som jeg kan bruke fra laptoppen min?

/Eirik

> On 22 May 2019, at 15:52, samding dd  wrote:
> 
> Thank you for you reply.
> 
> But how to get/build puppetserver on other platform than x86_64?
> The document of v6.4 says  to get puppetserver by first adding a repository 
> and then install it as a normal  package. 
> But I cannot get it for s390x in the same way, probably the repository does 
> not support it.
> Is there any way to build to build puppetserver from the Github directly?
> 
> Thanks,
> 
> 
> On Wednesday, 22 May 2019 03:25:32 UTC-4, Bart-Jan Vrielink wrote:
> Hello,
> 
> Puppet master has been deprecated for a while and is removed from Puppet 6. 
> Instead of a puppet master, you should switch to using a puppetserver instead.
> See https://puppet.com/docs/puppet/6.0/release_notes_puppet.html#webrick
> 
> -Original message-
> From: samding dd 
> Sent: Tuesday 21st May 2019 22:10
> To: Puppet Users 
> Subject: [Puppet Users] How to start puppet master for v6.0.0 or late
> 
> Hi there,
> 
> I am new to puppet. 
> I want to know how to start puppet master for v6.0.0 or late versions. 
> For version below v6.0.0, I can install puppet by:
> 
>
>gem install puppet -v 5.5.14
> 
> Then start by :
>   
>puppet master --verbose --no-daemonizepuppet
> 
> However, after v6.0.0, there is no subcommand "master" option.
> 
> If installing v6.4.2, the "puppet help" shows below:
> 
> "puppet]# puppet help
> 
> Usage: puppet  [options]  [options]
> 
> Available subcommands:
> 
>   Common:
> agent The puppet agent daemon
> apply Apply Puppet manifests locally
> configInteract with Puppet's settings.
> help  Display Puppet help.
> lookupInteractive Hiera lookup
> moduleCreates, installs and searches for modules on the 
> Puppet Forge.
> resource  The resource abstraction layer shell
> 
> 
>   Specialized:
> catalog   Compile, save, view, and convert catalogs.
> describe  Display help about resource types
> deviceManage remote network devices
> doc   Generate Puppet references
> epp   Interact directly with the EPP template parser/renderer.
> facts Retrieve and store facts.
> filebucketStore and retrieve files in a filebucket
> generate  Generates Puppet code from Ruby definitions.
> node  View and manage node definitions.
> parserInteract directly with the parser.
> scriptRun a puppet manifests as a script without compiling a 
> catalog
> ssl   Manage SSL keys and certificates for puppet SSL clients 
> 
> Thanks,
> 
> 
> 
> -- 
> 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/0d3ae17b-e47e-4c79-a631-88c2dc163311%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> 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/78d5e284-7147-42c6-a9a8-e249d8e6bceb%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/ECBBF59E-D7AF-461A-B47E-FEA88C6F3361%40anduin.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Pass parameters to the 'postgresql' module when instantiated as a dependency of the 'puppetdb' module

[Eirik Øverby]

> class foo:bar(
> $param1, # This enables you to provide 'param1' when instantiating 
> the class,
>  # and it enables auto-parameter-lookup for foo::bar::param1 
> in Hiera.
>  # if no value is given or found in Hiera, the value of 
> $param1 will be undef.
> 
> $param2='test'   # This enables you to provide 'param2' when instantiating 
> the class,
>  # and it enables auto-parameter-lookup for foo::bar::param2 
> in Hiera.
>  # if no value is given or found in Hiera, the value of 
> $param2 will be 'test'.
> ) { ... }
> 
> In other words, specifying = after a parameter in the class 
> parameter definition, will enable you to provide a default value that is used 
> as a last resort.

Really? We just had to modify about 20 classes in our end because the hiera 
values were *not* used when defaults were specified in the class definitions.. 
Is there some obscure option/setting we've inherited from puppet2/3 that we're 
being bitten by?

And to Chadwick - sorry for the apparently bad advice :-)

/Eirik

-- 
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/35F60FFD-9962-4AA6-9685-6ABBB41F4E55%40anduin.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Pass parameters to the 'postgresql' module when instantiated as a dependency of the 'puppetdb' module

[Eirik Øverby]

Hi,

> I don't fully understand Part 2: "2. You need any applicable resource-like 
> declaration of class postgresql::server in the manifest set to not itself 
> bind a value to the config_hash parameter."

You are probably declaring your class/resource setting default values for 
parameters directly in the .pp file. This will override whatever you're 
defining in Hiera. Just leave the declaration like

class foo:bar ( $param1, $param2='test' ) { ... }

In this way $param1 is considered mandatory, and if it's defined in hiera all 
is good (the hiera value will be used). Rparam2 is optional, and will be 
assigned the value 'test' no matter what hiera says - unless you instantiate 
the class with that parameter explicitly set.

/Eirik

-- 
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/B1A88929-5741-4EE6-9F35-FBD54B0F44D3%40anduin.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Set default param value based on another param

[Eirik Øverby]

On 8 Oct 2018, at 17:05, Henrik Lindberg  wrote:
> 
> On 2018-10-08 08:44, Eirik Øverby wrote:
>> Hi,
>> Sorry for hijacking this thread, but it caught my interest.
>> My scenario is that I'd like to re-use the title of an nginx server instance 
>> in, say, the log file for that server instance. However, since I don't want 
>> to touch the nginx module itself, it seems I have to wrap its server class 
>> in one of my own to allow setting this kind of defaults - but I have found 
>> no way to use $title in this way.
>> The best would be if I could do something like this - assuming nginx::server 
>> is a module class already defined:
>> nginx::server {
>>   default:
>> $access_log => "${nginx::logdir}/${mytitle}.log",
>> ...,
>>   ;
>>   'my-fine-443-server':
>> listen_port => 443,
>>   ;
>> }
>> Here it would also be helpful if I could somehow re-use the default values 
>> in the individual instances too - I might not know what the default values 
>> are, but I would know what to do with them (append '.log' for instance, or 
>> set listen_port to the same value as ssl_port or vice versa).
>> Even being able to do the following would be better than what we're 
>> currently doing, which is repeating the fully-typed access log line (and all 
>> the other similar entries) for every instance:
>> nginx::server { 'my-fine-443-server':
>> $access_log => "${nginx::logdir}/${mytitle}.log",
>> listen_port => 443,
>> }
>> Not sure how I could use functions here either, as I want this to happen at 
>> instantiation time, not in the module itself.
>> Am I hoping for too much? Missed something?
> 
> I have a bit of a hard time following this. You say assuming "nginx::server" 
> is a class, but then it looks like it is a resource since it is instantiated 
> with a title. Also don't understand what $mytitle is - is that supposed to be 
> $title ?

Clearly I got up too early this morning. Of course nginx::server is a resource, 
and I want to instantiate a whole bunch of them. And what I mean with $mytitle 
is exactly that - the $title of the instantiated resource. So in this case I 
would like to say that the log file name is a product of the instantiated 
resource's title, which means I can create a lot of them following 
"my-fine-443-server", and they'd all have log file names based on the resource 
title. In this case, my-fine-443-server would have (in our world) 
/var/log/nginx/my-fine-443-server.access.log. A "my-less-fine-8443-server" 
instance would then get /var/log/nginx/my-less-fine-8443-server.access.log, and 
so on and so forth.

Taking this example a bit further (correcting for some syntax errors in my 
original sample above):

nginx::server {
  default:
access_log => "${nginx::logdir}/${title}.log",
ssl_port => $listen_port,
...,
  ;
  'my-fine-443-server':
listen_port => 443,
  ;
}

$title would normally refer to the class in which I create these resources, so 
that variable is useless. Similarly, the $listen_port in the default: section 
is not yet specified - but I'd prefer not to have to type it for each instance 
since it's just the nginx module that for some reason requires me to specify 
both - but they'll always be the same value.

We use hiera for a lot of our defaults, but these are context-specific defaults 
that cannot be set in hiera - and strictly I mostly want them for style and 
reduced duplication of code (with associated risks of mistakes when creating 
dozens of server or location resources).

.

> Best advice; be explicit about defaults, and get them via hiera and use APL.

We're using hiera a *lot*. I guess part of the problem is that our 
environment(s) isn't (aren't) as homogenous as we would like (to think they 
are)..

Thanks for your attempts to understand me :)

/Eirik

-- 
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/481CEBF4-F8B5-41E5-ACAF-BB45C7DCAD06%40anduin.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Set default param value based on another param

[Eirik Øverby]

Hi,

Sorry for hijacking this thread, but it caught my interest. 

My scenario is that I'd like to re-use the title of an nginx server instance 
in, say, the log file for that server instance. However, since I don't want to 
touch the nginx module itself, it seems I have to wrap its server class in one 
of my own to allow setting this kind of defaults - but I have found no way to 
use $title in this way.

The best would be if I could do something like this - assuming nginx::server is 
a module class already defined:
nginx::server {
  default:
$access_log => "${nginx::logdir}/${mytitle}.log",
...,
  ;
  'my-fine-443-server':
listen_port => 443,
  ;
}

Here it would also be helpful if I could somehow re-use the default values in 
the individual instances too - I might not know what the default values are, 
but I would know what to do with them (append '.log' for instance, or set 
listen_port to the same value as ssl_port or vice versa).

Even being able to do the following would be better than what we're currently 
doing, which is repeating the fully-typed access log line (and all the other 
similar entries) for every instance:
nginx::server { 'my-fine-443-server':
$access_log => "${nginx::logdir}/${mytitle}.log",
listen_port => 443,
}

Not sure how I could use functions here either, as I want this to happen at 
instantiation time, not in the module itself.

Am I hoping for too much? Missed something?

/Eirik

> On 7 Oct 2018, at 11:35, Henrik Lindberg  wrote:
> 
> If you are on a reasonably modern Puppet version you should do it like this:
> 
> class myclass(
>  String $base_dir,
>  Optional[String] $conf_dir = "${base_dir}/conf"
> ) {
> }
> 
> I tested it as well:
> 
>  class myclass(
>String $base_dir,
>Optional[String] $conf_dir = "${base_dir}/conf"
>  ) {
>notice "base_dir = ${base_dir}, conf_dir = ${conf_dir}"
>  }
>  class { myclass: base_dir => 'yay' }
> 
> With the result:
> 
>  Notice: Scope(Class[Myclass]): base_dir = yay, conf_dir = yay/conf
> 
> And when executed like this:
> 
>  class myclass(
>String $base_dir,
>Optional[String] $conf_dir = "${base_dir}/conf"
>  ) {
>notice "base_dir = ${base_dir}, conf_dir = ${conf_dir}"
>  }
>  class { myclass: base_dir => 'yay', conf_dir => 'not yay' }
> 
> The result is:
> 
>  Notice: Scope(Class[Myclass]): base_dir = yay, conf_dir = not_yay
> 
> Which I think is what you wanted.
> 
> If the logic you need for coming up with a default value is complex, it can 
> be written as a function to which you present the input as arguments. The 
> above could have been written:
> 
> function mymodule::conf_default(String $base) { "${base}/conf" }
> class myclass(
>  String $base_dir,
>  Optional[String] $conf_dir = mymodule::conf_default($base_dir)
> ) {
> }
> 
> Which for the case you showed is total overkill, but good to know if
> you need something more complex in another place in your code.
> 
> Hope this helps.
> Best,
> - henrik
> 
> 
> 
>> On 2018-10-06 18:15, 'Dan White' via Puppet Users wrote: > You need to do 
>> like this:
>> class myClass (
>> String $base_dir,
>> Optional[String] $conf_dir,
>> ) {
>> if $myClass::conf_dir == undef {
>>   $myClass::actual_conf_dir = "$myClass::base_dir/conf”
>> } else {
>> $myClass::actual_conf_dir = $myClass::conf_dir
>> }
>> … and then use $myClass::actual_conf_dir in the template
>> }
>>> On Oct 3, 2018, at 12:41 PM, Jody Des Roches  wrote:
>>> 
>>> I'd like to set default values for parameters that will be passed to epp 
>>> templates.  However, the default value is based on another parameter.  I 
>>> understand that variables are immutable but this is a parameter that 
>>> shouldn't be touched unless it wasn't set.
>>> 
>>> Here is an example construct with a few of my syntax attempts.
>>> 
>>> class myClass (
>>> String $base_dir,
>>> Optional[String] $conf_dir,
>>> ) {
>>> #Attempt 1: Failed
>>> if $myClass::conf_dir == undef { $myClass::conf_dir = 
>>> "$myClass::base_dir/conf" }
>>> 
>>> #Attempt 2: Failed
>>> if !$myClass::conf_dir { $myClass::conf_dir = "$myClass::base_dir/conf" }
>>> 
>>> #Attempt 3: Failed
>>> unless $myClass::conf_dir { $myClass::conf_dir = "$myClass::base_dir/conf" }
>>> }
>>> 
>>> -- 
>>> 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/8e2db8c1-7353-4360-adc5-00713e1c0214%40googlegroups.com.
>>> 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 

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

[Eirik Øverby]

> I would expect this to get into 5.5.7 but can't promise yet.

Brilliant - as long as it's not me being crazy. Thanks again.

/Eirik

-- 
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/F1172FD8-CDC6-4E21-A4A1-B7BD2EA2DDBC%40anduin.net.
For more options, visit https://groups.google.com/d/optout.

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

[Eirik Øverby]

> Hi X,
> 
> Nick Lewis helped me reproduce this issue with the extra module path, I have 
> filed https://tickets.puppetlabs.com/browse/PUP-9211 for the issue.
> 
> Thanks!

Thanks a *lot*!
I've resuscitated my JIRA account, so if you wish to attach me to the ticket in 
some way, my username is 'ltning'.

I presume 5.5.7 should have this one fixed then? :)

/Eirik

-- 
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/660D6F34-A653-462E-B0EA-645CCA3228DB%40anduin.net.
For more options, visit https://groups.google.com/d/optout.

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

[Eirik Øverby]

> Hi Eirik,
> 
> I was unable to reproduce your issue in Puppet 5.5.6 (aka SHA 60de165 from 
> https://github.com/puppetlabs/puppet/releases):
> 
> kris.bosland@kris:puppet % git checkout 60de165   
>   
>±[5.5.6^0]
> HEAD is now at 60de165b86... Merge pull request #7007 from 
> justinstoller/maint-pin-rake-more
> kris.bosland@kris:puppet % cat ../tmp/test/bash/manifests/init.pp 
>   
>±[5.5.6^0]
> class bash {
> package { "shells/bash":
> ensure => installed,
> }
> }
> 
> class smash {
> package { "shells/bash":
> ensure => installed,
> }
> }
> kris.bosland@kris:puppet % bx puppet apply --modulepath ../tmp/test -e 'class 
> test { include bash }; include test'  
>±[5.5.6^0]
> Warning: Unacceptable location. The name 'smash' is unacceptable in file 
> '/Users/kris.bosland/work/tmp/test/bash/manifests/init.pp' (file: 
> /Users/kris.bosland/work/tmp/test/bash/manifests/init.pp, line: 7, column: 1)
> Notice: Compiled catalog for kris.bosland-c02kf9eafft1 in environment 
> production in 0.56 seconds
> Error: Mac OS X PKG DMGs must specify a package source.
> Error: /Stage[main]/Bash/Package[shells/bash]/ensure: change from 'absent' to 
> 'present' failed: Mac OS X PKG DMGs must specify a package source.
> Notice: Applied catalog in 0.02 seconds
> kris.bosland@kris:puppet %
> 
> Note that Puppet complains about the class 'smash' in the 'bash' module, but 
> not the class 'bash'.

I would expect that too - not that I like it (it will still require a load of 
work to clean up our puppetserver.log), but in our end it complains even about 
'bash'..


> Can you provide a more detailed example that fails for you?

I'm not sure how much more detail I can give? Most of our in-house modules are 
relatively simple, much like my original example. It complains about - it 
seems, but I haven't counted - every module we have written.

One possible issue might be that we have several module directories - all 
listed in basemodulepath:
/usr/local/etc/puppet/modules - anything installed using 'puppet module...'
/usr/local/etc/puppet/modules.common - all in-house modules that apply to all 
our environments
 - This is where the bash module (and git, sudo, nano, vim, etcall 
suffering from the same) lives
/usr/local/etc/puppet/nodes.common - all node classes and definitions that are 
the same across all our environments

We're on FreeBSD and running unmodified puppetserver from the ports tree. 
Puppet server is v5.3.5

Does this help? Any information I can collect that would shed light on this?


Thanks,
/Eirik

-- 
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/3A1D3608-9A23-44FE-A2B5-A3351266BFD2%40anduin.net.
For more options, visit https://groups.google.com/d/optout.

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

[Eirik Øverby]

On Tuesday, August 28, 2018 at 6:50:48 PM UTC+3, Branan Purvine-Riley wrote:

> Hi Jon,
>
> In Puppet 6 we're going to start requiring that the names of 
> classes/defines match the name that's implied by their file path[1]. We 
> added that deprecation warning in 5.5.6[2] as part of a push to get 
> upcoming Puppet 6 changes printing warnings whenever possible.
>
> [1] https://tickets.puppetlabs.com/browse/PUP-1434 and 
> https://tickets.puppetlabs.com/browse/PUP-4242
> [2] https://tickets.puppetlabs.com/browse/PUP-8894
>

Since 5.5.6 our puppetserver has been issuing warnings of this kind:
Puppet Unacceptable location. The name 'bash' is unacceptable in file 
'/usr/local/etc/puppet/modules.common/bash/manifests/init.pp'

The init.pp file contains only this:
class bash {
package { "shells/bash":
ensure => installed,
}
}

I am at a loss as to how I'm supposed to refactor this to make the warning 
go away. We do need an init.pp, and I know that for style points we should 
split this into a base class and a ::install class, but I refuse to believe 
that this is *required* for something as simple as the above. I am also not 
finding the documentation particularly helpful in this simple use-case. It 
does look like it's complaining about absolutely every class we have 
defined, no matter if we use only init.pp or properly-defined 
directory/file hierarchy and -naming for the classes, defines, etc.

Can someone help me nudge my neurons in a way that I understand what is 
expected of me?

/Eirik 

-- 
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/1a76f507-f1a6-4115-be51-1c504fd84ed4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.