Re: [Puppet Users] Re: My Array and Hash datatype getting treated as simple string.

[Peter Huene]

Hi Arun,

On Feb 8, 2017 7:32 AM, "Arun Kumar"  wrote:

Hi Henrik,

I have a requirement where i need to interpolate facter and an array
element. Facters are interpolated in double quotes and array elements
inside it is getting treated as a one single string. So could you advise on
this?

  $dir=["/share","/share/dir1"]

  mount {  /opt/share1 :
device => "$::fqdn:/$dir[1]",
options => defaults,
fstype => nfs,
ensure => mounted,
}


For accessing an array element, you'll need to use the expression form of
an interpolation:

"...${dir[1]}..."

There is no need to use a dollar sign on the variable inside the brackets
because array accesses are treated specially.


Outcome:

 tail -1 /etc/fstab
client.example.com://share/share/dir1[1]/opt/share1 nfs
defaults0   0


Expected:

 tail -1 /etc/fstab
client.example.com:/share/dir1[1]/opt/share1 nfs defaults
 0   0


Did you mean to have [1] in the expected output here? If so, include it
after the closing brace of the expression above.






On Sunday, 22 January 2017 22:35:51 UTC+5:30, Arun Kumar wrote:
>
> Hi Guys,
>
> I am very new to Puppet and installed 3.8. I tried creating template using
> array type variable but I got output as string.
>
> My sample code as below:
>
> init.pp
> ---
> $servers = ['facter', 'hiera', 'mco', 'puppet', 'puppetserver'],
>
> config.pp
> --
> $servers = "$::apache::servers",
>
> file {"/root/welcome":
> ensure => present,
> content => template('apache/hello.erb'),
>
>
> hello.erb
> --
> <% @servers.each do |val| -%>
> Welcome <%= val %>
> <% end -%>
>
>
> output as :
> ==
>
> cat /root/welcome
> Welcome facterhieramcopuppetpuppetserver
>
> Any help will be appreciated.
>
> Thanks,
> Arun
>
-- 
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/6608f6b1-d791-4b1a-ac87-fa4f19abc6cd%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/CACZQQfOe1TnpfXRhCLEe1a%2BgunwKGRtt4eD384_y3tACJBcBPA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] if else statment is now working in puppet

[Peter Huene]

Hi Mohammed,

On Wed, Nov 9, 2016 at 2:08 PM, mohammed mathin <inshamath...@gmail.com>
wrote:

> Hi,
>
> My questing will be silly but sorry for that
>
> I facing problem on setting up the hostname based manifest
>
> My requirement is if the hostname match statment1 file need to be print.
>
> But in all the nodes statmen1 file is printing not sure where i have done
> mistake. hear the below my manifest file
>
>
> class pkg::statment {
> if ["$hostname" == "172.20.14.173"] {
>

This is incorrect syntax for what you would like to accomplish.

`["$hostname" == "172.20.14.173"]` creates an array containing a single
boolean (true if the strings compare or false if not).

The "if" expression is then given the array as the condition, which is
always "truthy", causing '/tmp/statment1' to always be created.

If you remove the surrounding brackets, the "if" expression will then use
the result of the equality operator as the condition, which is what you
want.

Thus, change `if ["$hostname" == "172.20.14.173"] ...` to `if $hostname ==
"172.20.14.173" ...` (you can probably omit the quotes around $hostname as
I suspect $hostname is already a string).

Cheers,

Peter


> file { '/tmp/statment1' :
> ensure => 'file',
> }
> }
> else {
> file { '/tmp/statment2' :
> ensure => 'file',
> }
>  }
> }
>
>
> --
> 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/7a6a23a8-1ac0-46d7-8b0e-13a04c82aa9f%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/7a6a23a8-1ac0-46d7-8b0e-13a04c82aa9f%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
--
Peter Huene - Senior Software Engineer
peter.hu...@puppet.com | @peterhuene

-- 
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/CACZQQfOc3yH48TRWzuQd5w_RC8kNPdfNXp_491%2B2jnf2G4M6mA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] function not loaded when .pp file runs through command line >> Error: Unknown function:

[Peter Huene]

Hi bodik,

On Tue, Nov 8, 2016 at 2:03 AM, bodik <bo...@cesnet.cz> wrote:

> hello,
>
> I'm getting into troubles while using rake (not important) for --noop
> tests during modules development. Using
>
> puppet apply -e 'include class'
>
> everything works fine, but using .pp file containing exactly the same
>
> puppet apply tests/class.pp
>
> results in "Unknown function:" as shown below, where whole usecase is
> documented.
>
> Acording to strace myfunc.rb is found by lstat and fopen in both cases,
> but in the latter (error one), myfunc.rb is searched also in gems
> directories ...
>
> any advice would be appreciated
>
>
> thanks
> bodik
>
>
> ===
> ===
>
>
>
> root@tester:~/pb1# find .
> ./mod1
> ./mod1/manifests
> ./mod1/manifests/init.pp
> ./mod1/lib
> ./mod1/lib/facter
> ./mod1/lib/facter/myfunc.rb
> ./mod1/tests
> ./mod1/tests/init.pp
> ./run.sh
>
>
>
> root@tester:~/pb1# cat ./mod1/manifests/init.pp
> class mod1::puppet_function_resolution() {
> notice(myfunc(1))
> }
>
>
> root@tester:~/pb1# cat ./mod1/lib/facter/myfunc.rb
>

This is not the correct place for Puppet 3.x custom functions (this
location is for custom facts).

The correct location would be mod1/lib/puppet/parser/functions/myfunc.rb.

This is probably why the compiler can't find it.


> # simple wrapper for custom execs
> require "puppet"
> module Puppet::Parser::Functions
> newfunction(:myfunc, :type => :rvalue) do |args|
> return "returned value"
> end
> end
>
>
>
>
> root@tester:~/pb1# cat ./mod1/tests/init.pp
> include mod1::puppet_function_resolution
>
>
> root@tester:~/pb1# cat ./run.sh
> #!/bin/sh
> set -x
>
> puppet apply --modulepath=/root/pb1 -e 'include
> mod1::puppet_function_resolution' --noop
>
> puppet apply --modulepath=/root/pb1 "mod1/tests/init.pp" --noop
>
>
>
>
> root@tester:~/pb1# sh ./run.sh
>
> + puppet apply --modulepath=/root/pb1 -e include
> mod1::puppet_function_resolution --noop
> Notice: Scope(Class[Mod1::Puppet_function_resolution]): returned value
> Notice: Compiled catalog for tester in environment production in 0.04
> seconds
> Notice: Applied catalog in 0.63 seconds
>
>
> + puppet apply --modulepath=/root/pb1 mod1/tests/init.pp --noop
> Error: Evaluation Error: Unknown function: 'myfunc'. at
> /root/pb1/mod1/manifests/init.pp:2:9 on node tester
>
>
>
>
> root@tester:~/pb1# puppet --version
> 4.5.2
>

Given that you're using Puppet 4.x, I recommend using the Puppet 4.x
function API rather than the 3.x API.

As an example for your custom function, in
mod1/lib/puppet/functions/myfunc.rb you would have:

```
Puppet::Functions.create_function(:'mod1::myfunc') do
  dispatch :myfunc do
param :Integer, :arg
  end

  def myfunc(arg)
 "returning value #{arg}"
  end
end
```

And this would be invoked like `mod1::myfunc(1)`.

Cheers,

Peter


>
> --
> 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/ms
> gid/puppet-users/5821A30B.1040104%40cesnet.cz.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
--
Peter Huene - Senior Software Engineer
peter.hu...@puppet.com | @peterhuene

-- 
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/CACZQQfMU_7RcTf5%3D%2B1H9AZhfOuNPtF6AYYOnM3KqPFw%2BLq5XGg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Problems with new PE 2016.4 install

[Peter Huene]

On Nov 4, 2016 3:04 AM, "Jonathan Gazeley" 
wrote:
>
> Thanks for your response. Output of those commands follows:
>
> [jg4461@puppet4-prod ~]$ facter -p mountpoints
>
/,/dev,/sys/kernel/security,/sys/fs/cgroup/systemd,/sys/fs/pstore,/sys/kernel/config,/sys/fs/selinux,/dev/mqueue,/dev/hugepages,/sys/kernel/debug,/boot
>

This looks like it may be coming from a custom fact that is overriding the
expected built-in.

Could you run 'facter -d -p mountpoints' and see if the output mentions
discovery of a mountpoints.rb or a change in fact value?

Thanks!

> [jg4461@puppet4-prod ~]$ mount
> sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime,seclabel)
> proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
> devtmpfs on /dev type devtmpfs
(rw,nosuid,seclabel,size=3996484k,nr_inodes=999121,mode=755)
> securityfs on /sys/kernel/security type securityfs
(rw,nosuid,nodev,noexec,relatime)
> tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,seclabel)
> devpts on /dev/pts type devpts
(rw,nosuid,noexec,relatime,seclabel,gid=5,mode=620,ptmxmode=000)
> tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755)
> tmpfs on /sys/fs/cgroup type tmpfs
(ro,nosuid,nodev,noexec,seclabel,mode=755)
> cgroup on /sys/fs/cgroup/systemd type cgroup
(rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
> pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
> cgroup on /sys/fs/cgroup/blkio type cgroup
(rw,nosuid,nodev,noexec,relatime,blkio)
> cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup
(rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)
> cgroup on /sys/fs/cgroup/devices type cgroup
(rw,nosuid,nodev,noexec,relatime,devices)
> cgroup on /sys/fs/cgroup/net_cls type cgroup
(rw,nosuid,nodev,noexec,relatime,net_cls)
> cgroup on /sys/fs/cgroup/perf_event type cgroup
(rw,nosuid,nodev,noexec,relatime,perf_event)
> cgroup on /sys/fs/cgroup/freezer type cgroup
(rw,nosuid,nodev,noexec,relatime,freezer)
> cgroup on /sys/fs/cgroup/hugetlb type cgroup
(rw,nosuid,nodev,noexec,relatime,hugetlb)
> cgroup on /sys/fs/cgroup/memory type cgroup
(rw,nosuid,nodev,noexec,relatime,memory)
> cgroup on /sys/fs/cgroup/cpuset type cgroup
(rw,nosuid,nodev,noexec,relatime,cpuset)
> configfs on /sys/kernel/config type configfs (rw,relatime)
> /dev/sda3 on / type ext4 (rw,relatime,seclabel,data=ordered)
> selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)
> systemd-1 on /proc/sys/fs/binfmt_misc type autofs
(rw,relatime,fd=34,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
> mqueue on /dev/mqueue type mqueue (rw,relatime,seclabel)
> hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,seclabel)
> debugfs on /sys/kernel/debug type debugfs (rw,relatime)
> /dev/sda1 on /boot type ext4 (rw,relatime,seclabel,data=ordered)
> tmpfs on /run/user/991 type tmpfs
(rw,nosuid,nodev,relatime,seclabel,size=801120k,mode=700,uid=991,gid=460)
> binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
> tmpfs on /run/user/56933 type tmpfs
(rw,nosuid,nodev,relatime,seclabel,size=801120k,mode=700,uid=56933,gid=464)
>
> [jg4461@puppet4-prod ~]$ puppet apply -e 'notify { "${::mountpoints}": };
notify { "${::mountpoints["/"]}": }'
> Error: Evaluation Error: The value '/' cannot be converted to Numeric. at
line 1:59 on node puppet4-prod.resnet.bris.ac.uk
>
> Thanks,
> Jonathan
>
>
> On 03/11/16 17:26, AJ Johnson wrote:
>>
>> Hi Jonathan -
>>
>> Can you run facter -p (interested in what mountpoints is) and `mount`,
>> and paste the output.
>>
>> Also can you run:
>>
>> puppet apply -e 'notify { "${::mountpoints}": }; notify {
>> "${::mountpoints["/"]}": }'
>>
>>
>> Thanks,
>>
>>
>> -aj
>>
>>
>> On Thursday, November 3, 2016 at 2:52:35 AM UTC-7, Jonathan Gazeley
wrote:
>>
>> Hi folks,
>>
>> I've been running open-source Puppet 3.x for years but this week I'm
>> dabbling with a new installation of PE 2016.4. I installed from the
>> pointy-clicky installer and so far the PE server only has itself in
the
>> inventory, but is failing to do a puppet run. It bails with this
error:
>>
>> Could not retrieve catalog from remote server: Error 500 on SERVER:
>> Server Error: Evaluation Error: Error while evaluating a Resource
>> Statement, Evaluation Error: Error while evaluating a Method call,
>> 'dig'
>> parameter 'data' expects a Collection value, got String at
>>
/opt/puppetlabs/puppet/modules/puppet_enterprise/manifests/master/puppetserver.pp:673:42
>>
>> on node puppet4-prod.resnet.bris.ac.uk
>> 
>>
>>
>> I think that manifest is something that came with PE and not
something
>> I've installed, so I've no idea where to start. Any ideas?
>>
>> Thanks,
>> Jonathan
>>
>> --
>> Jonathan Gazeley
>> Senior Systems Administrator
>> IT Services
>> University of Bristol
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups 

Re: [Puppet Users] Problems with new PE 2016.4 install

[Peter Huene]

On Thu, Nov 3, 2016 at 10:30 AM, Justin Stoller <jus...@puppet.com> wrote:

>
>
> On Thu, Nov 3, 2016 at 2:52 AM, Jonathan Gazeley <
> jonathan.gaze...@bristol.ac.uk> wrote:
>
>> Hi folks,
>>
>> I've been running open-source Puppet 3.x for years but this week I'm
>> dabbling with a new installation of PE 2016.4. I installed from the
>> pointy-clicky installer and so far the PE server only has itself in the
>> inventory, but is failing to do a puppet run. It bails with this error:
>>
>> Could not retrieve catalog from remote server: Error 500 on SERVER:
>> Server Error: Evaluation Error: Error while evaluating a Resource
>> Statement, Evaluation Error: Error while evaluating a Method call, 'dig'
>> parameter 'data' expects a Collection value, got String at
>> /opt/puppetlabs/puppet/modules/puppet_enterprise/manifests/master/puppetserver.pp:673:42
>> on node puppet4-prod.resnet.bris.ac.uk
>>
>> I think that manifest is something that came with PE and not something
>> I've installed, so I've no idea where to start. Any ideas?
>>
>
> Looking at that line in the puppet configuration it seems that we're
> digging into the mountpoints:
>
> $tmp_mount_options = $::mountpoints.dig( '/tmp', 'options' )
>
>
> Dig expects to be called on a collection[1], and reading the error I would
> assume that the fact `mountpoints` is returning a string or that the "/tmp"
> key within the fact is returning a string. Which is not how Facter should
> be behaving[2].
>

Perhaps we're picking up a (deprecated for forever now) `stringify_facts =
true` in Puppet's settings, perhaps from a previous installation?

My guess is that Facter is operating correctly since this fact is tested
against the schema definition to verify it is always a map.


>
> Have you changed anything relating to Facter or its configuration?
>
>
>  - Justin
>
>
> 1. https://docs.puppet.com/puppet/4.8/reference/function.html#dig
> 2. https://docs.puppet.com/facter/latest/core_facts.html#mountpoints
>
>>
>> Thanks,
>> Jonathan
>>
>> --
>> Jonathan Gazeley
>> Senior Systems Administrator
>> IT Services
>> University of Bristol
>>
>> --
>> 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/ms
>> gid/puppet-users/a6b299e2-7ff0-edaa-6f38-4747bb64d758%40bristol.ac.uk.
>> 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/CA%2B%3DBEqU%3D1rQq%2Bws%3DjpybcxJWWfeKsu-WKJXx%2BSpnr_
> ebhuCE2Q%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-users/CA%2B%3DBEqU%3D1rQq%2Bws%3DjpybcxJWWfeKsu-WKJXx%2BSpnr_ebhuCE2Q%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
--
Peter Huene - Senior Software Engineer
peter.hu...@puppet.com | @peterhuene

-- 
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/CACZQQfMDTCxkzq1zGXxO2t%2BOnsJUyRB0X88%2BBWa%2BKZZY_vE3Yw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] comparing facts as integers in puppet server 4.5?

[Peter Huene]

Hi Doug:

On Wed, Aug 10, 2016 at 12:28 PM, dkoleary <dkole...@olearycomputers.com>
wrote:

> Hey
>
> I'm setting up a module to handle our smtp config.
>
> My simple if statement is:
>
>   if ($facts['os']['release']['major'] > 5 ) {
>
>
> results in a bright red error stating:
>
> Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
> Evaluation Error: Error while evaluating a Resource Statement, Evaluation
> Error: Comparison of: String > Integer, is not possible. Caused by '*A
> String is not comparable to a non String'*. at /etc/puppetlabs/code/
> environments/dkoleary/modules/mpismtp/manifests/init.pp:50:40 on node
> nap1d030.multiplan.com
>
> Facts are obviously interpreted as strings.  Several posts referenced that
> puppet will auto-translate strings to integers if appropriate.  So,
> figuring there was something special about the facts hash, I created a
> variable for it:
>

Recent versions of Puppet do not "stringify" facts and Facter 3 outputs
facts of many different types, including numerical.  However, Facter's
schema defines this particular fact as being a string because it cannot
limit any component of a version string to be numerical; for example, a
valid version string could just be a release code name.


>
>   $mpismpt_orm = $facts['os']['release']['major']
>   if ($mpismpt_orm > 5) {
>
> with the same result.  It wasn't until I updated the var declaration as
> "$mpismpt_orm = 0 + $facts['os']['release']['major']" that this works - a
> hint in a post from 2010.  There has to be a better way to have facts be
> interpreted as numbers, doesn't there?
>

The Puppet compiler only automatically coerces strings to numeric types for
arithmetic operations, such as the plus operator, as you've noticed; the
comparison operators do no such coercion.

In Puppet 4.5+, you can use the `new` function (
https://docs.puppet.com/puppet/latest/reference/function.html#new) to
perform type conversions:

if Integer($facts['os']['release']['major']) > 5 {
  # ...
}

This example will explicitly convert the string to an integer using the
"type-conversion-like" syntax for invoking the new function.  It is
semantically equivalent to explicitly invoking the `new` function, like so:

if Integer.new($facts['os']['release']['major']) > 5 {
  # ...
}

On older versions, you can use the conversion technique you've already
discovered or the `scanf` function (
https://docs.puppet.com/puppet/latest/reference/function.html#scanf).

Hope this helps.


>
> It works so, if all else fails, I'm good.  It just seems that something
> should have changed in this regards in the last 7 years.
>
> Thanks for any information.
>
> Doug O'Leary
>
>
>
>
> --
> 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/18556755-8853-4367-8a1e-47d337e66a22%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/18556755-8853-4367-8a1e-47d337e66a22%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
--
Peter Huene - Senior Software Engineer
peter.hu...@puppet.com | @peterhuene
-- 
PuppetConf 2016
<https://www.google.com/url?q=https%3A%2F%2Fpuppet.com%2Fpuppetconf=D=1=AFQjCNFf4WhS0623bLixxPqtXYm9RV8fyg>
, 19 - 21 October , San Diego, California
*Summer Savings - Register by 15 September and save $240
<https://www.google.com/url?q=https%3A%2F%2Fpuppetconf2016.eventbrite.com%2F%3Fdiscount%3DSummerSavings=D=1=AFQjCNGjMlH0LEUoxVdNBzlb4PcuUbs42Q>*

-- 
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/CACZQQfNDuOmpzfZeHZ5SBxcjCvWyO9os-UaERk5jq-%3DUkJNY-A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Error with EPP template from "Learning Puppet 4"

[Peter Huene]

On Thu, May 19, 2016 at 2:52 PM, David Karr <davidmichaelk...@gmail.com>
wrote:

> On Thursday, May 19, 2016 at 2:36:53 PM UTC-7, Peter Huene wrote:
>
>>
>> On Thu, May 19, 2016 at 2:23 PM, David Karr <davidmic...@gmail.com>
>> wrote:
>>
>>> On Thursday, May 19, 2016 at 2:16:17 PM UTC-7, Peter Huene wrote:
>>>>
>>>> Hi David:
>>>>
>>>> On Thu, May 19, 2016 at 1:57 PM, David Karr <davidmic...@gmail.com>
>>>> wrote:
>>>>
>>>>> I'm stepping through "Learning Puppet 4", and I ran into an error
>>>>> following steps in the book, and I want to understand what went wrong
>>>>> before I report it.
>>>>>
>>>>> The section in question is "Using Puppet EPP Templates" in chapter 13.
>>>>>
>>>>> I'll work backwards from the error I'm getting, showing the relevant
>>>>> files afterwards.  Here is what I see when I apply the manifest:
>>>>> [vagrant@client puppet]$ sudo puppet apply --environment test
>>>>> manifests/
>>>>> Warning: Unknown variable: '::puppet::common_loglevel'. at /etc/
>>>>> puppetlabs/code/environments/test/modules/puppet/templates/puppet.conf
>>>>> .epp:3:21
>>>>> Warning: Unknown variable: 'puppet::agent_loglevel'. at /etc/
>>>>> puppetlabs/code/environments/test/modules/puppet/templates/puppet.conf
>>>>> .epp:7:7
>>>>> Warning: Unknown variable: '::puppet::server'. at /etc/puppetlabs/code
>>>>> /environments/test/modules/puppet/templates/puppet.conf.epp:10:18
>>>>> Warning: Unknown variable: 'puppet::apply_loglevel'. at /etc/
>>>>> puppetlabs/code/environments/test/modules/puppet/templates/puppet.conf
>>>>> .epp:14:7
>>>>> Notice: Compiled catalog for client.example.com in environment test in
>>>>> 0.04 seconds
>>>>> Notice: /Stage[main]/Main/File[/etc/puppetlabs/puppet/puppet.conf]/
>>>>> content: content changed '{md5}a72aadac19feefd06f10fb6b8f90c5f4' to
>>>>> '{md5}0f89a3d91b54aec8463b4a250a493f36'
>>>>> Notice: /Stage[main]/Main/File[/etc/puppetlabs/puppet/puppet.conf]/
>>>>> owner: owner changed 'vagrant' to 'root'
>>>>> Notice: /Stage[main]/Main/File[/etc/puppetlabs/puppet/puppet.conf]/
>>>>> group: group changed 'vagrant' to 'wheel'
>>>>> Notice: /Stage[main]/Main/File[/etc/puppetlabs/puppet/puppet.conf]/
>>>>> mode: mode changed '0664' to '0644'
>>>>> Notice: Applied catalog in 0.06 seconds
>>>>> [vagrant@client puppet]$
>>>>>
>>>>>
>>>> Based on the warnings, it looks like the "puppet" class hasn't been
>>>> declared.  Did you `include puppet` somewhere or otherwise classify the
>>>> node to include the "puppet" class?
>>>>
>>>
>>> The only file in the "manifests" directory is "init.pp", which is this:
>>> class puppet(
>>>   # input parameters and default values for the class
>>>   $version = 'latest',
>>>   $status  = 'running',
>>>   $enabled = true,
>>>   $server  = 'puppet.example.com',
>>>   $common_loglevel = 'warning',
>>>   $agent_loglevel  = undef,
>>>   $apply_loglevel  = undef,
>>> ) {
>>>
>>>   # echo the input provided
>>>   notice("Install the $version version of Puppet, ensure it's $status,
>>> and set boot time start $enabled.")
>>>
>>>   # install puppet-agent
>>>   package { 'puppet-agent':
>>> ensure => 'latest',
>>> notify => Service['puppet'],
>>>   }
>>>
>>>   # manage the puppet service
>>>   service { 'puppet':
>>> ensure => 'running',
>>> enable => true,
>>> subscribe => Package['puppet-agent'],
>>>   }
>>> }
>>>
>>> class puppet::agent {
>>> }
>>>
>>> file { '/etc/puppetlabs/puppet/puppet.conf':
>>>   ensure => file,
>>>   owner => 'root',
>>>   group => 'wheel',
>>>   mode  => '0644',
>>> #  source => 'puppet:///modules/puppet/puppet.conf',
>>>   content => epp('puppet/puppet.conf.epp'),
>>> }
>>>
>>>
>> Without including the puppet class, the evaluation of the epp function
>> here will result in thos

Re: [Puppet Users] Error with EPP template from "Learning Puppet 4"

[Peter Huene]

On Thu, May 19, 2016 at 2:23 PM, David Karr <davidmichaelk...@gmail.com>
wrote:

> On Thursday, May 19, 2016 at 2:16:17 PM UTC-7, Peter Huene wrote:
>>
>> Hi David:
>>
>> On Thu, May 19, 2016 at 1:57 PM, David Karr <davidmic...@gmail.com>
>> wrote:
>>
>>> I'm stepping through "Learning Puppet 4", and I ran into an error
>>> following steps in the book, and I want to understand what went wrong
>>> before I report it.
>>>
>>> The section in question is "Using Puppet EPP Templates" in chapter 13.
>>>
>>> I'll work backwards from the error I'm getting, showing the relevant
>>> files afterwards.  Here is what I see when I apply the manifest:
>>> [vagrant@client puppet]$ sudo puppet apply --environment test manifests/
>>> Warning: Unknown variable: '::puppet::common_loglevel'. at /etc/
>>> puppetlabs/code/environments/test/modules/puppet/templates/puppet.conf.
>>> epp:3:21
>>> Warning: Unknown variable: 'puppet::agent_loglevel'. at /etc/puppetlabs/
>>> code/environments/test/modules/puppet/templates/puppet.conf.epp:7:7
>>> Warning: Unknown variable: '::puppet::server'. at /etc/puppetlabs/code/
>>> environments/test/modules/puppet/templates/puppet.conf.epp:10:18
>>> Warning: Unknown variable: 'puppet::apply_loglevel'. at /etc/puppetlabs/
>>> code/environments/test/modules/puppet/templates/puppet.conf.epp:14:7
>>> Notice: Compiled catalog for client.example.com in environment test in
>>> 0.04 seconds
>>> Notice: /Stage[main]/Main/File[/etc/puppetlabs/puppet/puppet.conf]/
>>> content: content changed '{md5}a72aadac19feefd06f10fb6b8f90c5f4' to
>>> '{md5}0f89a3d91b54aec8463b4a250a493f36'
>>> Notice: /Stage[main]/Main/File[/etc/puppetlabs/puppet/puppet.conf]/owner
>>> : owner changed 'vagrant' to 'root'
>>> Notice: /Stage[main]/Main/File[/etc/puppetlabs/puppet/puppet.conf]/group
>>> : group changed 'vagrant' to 'wheel'
>>> Notice: /Stage[main]/Main/File[/etc/puppetlabs/puppet/puppet.conf]/mode:
>>> mode changed '0664' to '0644'
>>> Notice: Applied catalog in 0.06 seconds
>>> [vagrant@client puppet]$
>>>
>>>
>> Based on the warnings, it looks like the "puppet" class hasn't been
>> declared.  Did you `include puppet` somewhere or otherwise classify the
>> node to include the "puppet" class?
>>
>
> The only file in the "manifests" directory is "init.pp", which is this:
> class puppet(
>   # input parameters and default values for the class
>   $version = 'latest',
>   $status  = 'running',
>   $enabled = true,
>   $server  = 'puppet.example.com',
>   $common_loglevel = 'warning',
>   $agent_loglevel  = undef,
>   $apply_loglevel  = undef,
> ) {
>
>   # echo the input provided
>   notice("Install the $version version of Puppet, ensure it's $status,
> and set boot time start $enabled.")
>
>   # install puppet-agent
>   package { 'puppet-agent':
> ensure => 'latest',
> notify => Service['puppet'],
>   }
>
>   # manage the puppet service
>   service { 'puppet':
> ensure => 'running',
> enable => true,
> subscribe => Package['puppet-agent'],
>   }
> }
>
> class puppet::agent {
> }
>
> file { '/etc/puppetlabs/puppet/puppet.conf':
>   ensure => file,
>   owner => 'root',
>   group => 'wheel',
>   mode  => '0644',
> #  source => 'puppet:///modules/puppet/puppet.conf',
>   content => epp('puppet/puppet.conf.epp'),
> }
>
>
Without including the puppet class, the evaluation of the epp function here
will result in those "unknown variable" warnings and they will evaluate to
undef (or cause an error in more recent versions of Puppet with strict
variable checking enabled).


>
>
>>
>>
>>> The template in question, right from the book, is this:
>>>
>>> # Generated by Puppet EPP template processor
>>> [master]
>>> log_level = <%= $::puppet::common_loglevel %>
>>>
>>> # This is used by "puppet agent"
>>> [agent]
>>> <% if $puppet::agent_loglevel != undef { -%>
>>> log_level = <%= $::puppet::agent_loglevel %>
>>> <% } -%>
>>> server = <%= $::puppet::server %>
>>>
>>> # This is used for "puppet apply"
>>> [user]
>>> <% if $puppet::apply_loglevel != undef { -%>
>>> log_level = <%= $::puppet::apply_loglevel %>
>>> <% } 

Re: [Puppet Users] Error with EPP template from "Learning Puppet 4"

[Peter Huene]

Hi David:

On Thu, May 19, 2016 at 1:57 PM, David Karr 
wrote:

> I'm stepping through "Learning Puppet 4", and I ran into an error
> following steps in the book, and I want to understand what went wrong
> before I report it.
>
> The section in question is "Using Puppet EPP Templates" in chapter 13.
>
> I'll work backwards from the error I'm getting, showing the relevant files
> afterwards.  Here is what I see when I apply the manifest:
> [vagrant@client puppet]$ sudo puppet apply --environment test manifests/
> Warning: Unknown variable: '::puppet::common_loglevel'. at /etc/puppetlabs
> /code/environments/test/modules/puppet/templates/puppet.conf.epp:3:21
> Warning: Unknown variable: 'puppet::agent_loglevel'. at /etc/puppetlabs/
> code/environments/test/modules/puppet/templates/puppet.conf.epp:7:7
> Warning: Unknown variable: '::puppet::server'. at /etc/puppetlabs/code/
> environments/test/modules/puppet/templates/puppet.conf.epp:10:18
> Warning: Unknown variable: 'puppet::apply_loglevel'. at /etc/puppetlabs/
> code/environments/test/modules/puppet/templates/puppet.conf.epp:14:7
> Notice: Compiled catalog for client.example.com in environment test in
> 0.04 seconds
> Notice: /Stage[main]/Main/File[/etc/puppetlabs/puppet/puppet.conf]/content
> : content changed '{md5}a72aadac19feefd06f10fb6b8f90c5f4' to
> '{md5}0f89a3d91b54aec8463b4a250a493f36'
> Notice: /Stage[main]/Main/File[/etc/puppetlabs/puppet/puppet.conf]/owner:
> owner changed 'vagrant' to 'root'
> Notice: /Stage[main]/Main/File[/etc/puppetlabs/puppet/puppet.conf]/group:
> group changed 'vagrant' to 'wheel'
> Notice: /Stage[main]/Main/File[/etc/puppetlabs/puppet/puppet.conf]/mode:
> mode changed '0664' to '0644'
> Notice: Applied catalog in 0.06 seconds
> [vagrant@client puppet]$
>
>
Based on the warnings, it looks like the "puppet" class hasn't been
declared.  Did you `include puppet` somewhere or otherwise classify the
node to include the "puppet" class?


> The template in question, right from the book, is this:
>
> # Generated by Puppet EPP template processor
> [master]
> log_level = <%= $::puppet::common_loglevel %>
>
> # This is used by "puppet agent"
> [agent]
> <% if $puppet::agent_loglevel != undef { -%>
> log_level = <%= $::puppet::agent_loglevel %>
> <% } -%>
> server = <%= $::puppet::server %>
>
> # This is used for "puppet apply"
> [user]
> <% if $puppet::apply_loglevel != undef { -%>
> log_level = <%= $::puppet::apply_loglevel %>
> <% } -%>
>
>
> Likely the most important piece to see now is the part of the "init.pp"
> manifest that declares the parameters being referenced here:
>
> class puppet(
>   $version = 'latest',
>   $status  = 'running',
>   $enabled = true,
>
>
>
> *$server  = 'puppet.example.com ',  
> $common_loglevel = 'warning',  $agent_loglevel  = undef,  $apply_loglevel  = 
> undef,*
> ) {
>
>
> I imagine the syntax of the variable references in the EPP file have to be
> slightly different, but I have no idea what it should be.
>

The EPP is fine; the code inside an EPP <% %> is expected to be valid
Puppet code.


>
> I also find it curious that the error messages print the name of the
> variable differently for different messages, sometimes prefixed with "::"
> and sometimes not.  Any background that would explain that?
>

When a variable name has a leading "::" it forces a lookup in the
top-scope.  An example where it would be needed is when you have a
top-scoped variable and a local variable of the same name; a leading "::"
would ensure that the top-scope variable is used and not the local variable.

For what it's worth, here's what a warning from a prototype Puppet compiler
I'm working on looks like when evaluating your example (hopefully it's a
bit more clear):

Warning: :3:21: could not look up variable $::puppet::common_loglevel
because class 'puppet' has not been declared.
  log_level = <%= $::puppet::common_loglevel %>
  ^~
 ...

Note: the filename is "" because I stuck your EPP source in an
"inline_epp" call rather than a file.


> --
> 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/01a83a7f-c3f2-4ca6-83d9-df09bec41527%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 

Re: [Puppet Users] facter 3 and at_exit

[Peter Huene]

Hi Clay,

On Fri, Apr 1, 2016 at 1:57 PM, Clay Caviness  wrote:

> I've come across an issue with facter 3, when using at_exit. Basically,
> any at_exit blocks that refer to anything not in the top-level namespace
> (pardon my terminology) trigger an 'uninitialized constant' NameError. I
> think this is a namespace issue of some sort, but it's beyond my ken.
>
> To recreate:
> Create uninitialized.rb:
> require 'facter'
> at_exit { Facter.warn('Facter.warn at exit') }
> at_exit { puts 'puts at exit' }
> Facter.add('uninitialized_constant') do
>   setcode do
> 'foo'
>   end
> end
>
> Run facter:
> facter -p uninitialized_constant facterversion
> facterversion => 3.1.4
> uninitialized_constant => foo
> puts at exit
> /private/var/puppet/lib/facter/unint.rb:3:in `block in ':
> uninitialized constant Facter (NameError)
>
> Note that the 'puts' at_exit works, but not the one using Facter.warn.
>

This is caused by how custom facts are resolved in Facter 3: namely that
custom facts are resolved all at once and no further calls from Ruby into
Facter's native implementation are expected when all resolutions have
completed.  The Facter module removes itself from the Ruby runtime after
all resolutions complete, but before the Ruby runtime is shutdown (when
at_exit callbacks would occur).  This is why your at_exit callbacks can't
find the Facter module; it's no longer there at that point.

Looking things over, I believe it doesn't need to be implemented this way.
The Facter module could outlive the Ruby runtime, allowing at_exit
callbacks to still make use of Facter.  This would require that the native
implementation not attempt to clean up explicit GC registrations made from
the module, which should be entirely unnecessary anyway since the Ruby
runtime has (in theory at least) destroyed the GC heap when the Ruby
runtime is shutdown.

I haven't seen at_exit used in a custom fact before, so I'm interested in
your use case.  Given that I consider this behavior to be an implementation
bug in Facter, would you mind opening a JIRA ticket at
https://tickets.puppetlabs.com (project should be "FACT" for Facter) and
detailing the use case?

Thanks!


>
> This works fine in facter 2:
> $ sudo facter -p uninitialized_constant facterversion
> facterversion => 2.4.4
> uninitialized_constant => foo
> puts at exit
> Facter.warn at exit
>
> I've put all this up at
> https://gist.github.com/ccaviness/12b1db78c42283f4193a1709dd03a8ac
>
> --
> 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/CANU2HrfPkoYcZcEWUioiTbyeN-60KfceZx3d1UX5XzdL3atSqg%40mail.gmail.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/CACZQQfNc01%2ByZBEOeDHTdbES5qVv8uiqQmnpB9sqSbRhE7zTRA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] facter value - not returning expected result

[Peter Huene]

Hi Mike,

On Thu, Mar 24, 2016 at 3:58 PM, Mike Reed <mjohn.r...@gmail.com> wrote:

> Hey Peter,
>
> I've done some additional reading and I believe I understand what's
> happening now.
>
> Thank you very much for the information and help.
>

Glad you got things working; let me know if there are any other questions
that come up.


>
> Cheers,
>
> Mike
>
>
> On Thursday, March 24, 2016 at 2:25:38 PM UTC-7, Mike Reed wrote:
>>
>> Hey Peter,
>>
>> Thank you for the reply and the information.
>>
>> In terms of the piped greps, the second  string is actually our
>> internal domain name (which I removed and replaced with ) for
>> security sake.
>>
>> I'm a little confused by code above as I'm still not getting what I would
>> expect from your code above.  I think part of my confusion is how the
>> recommended code gives me a true/false value.  I've changed the fact to now
>> look like this:
>>
>> require 'facter'
>>
>> Facter.add(:pbis_joined) do
>>   setcode do
>>   !Facter::Util::Resolution.exec(%q{/opt/pbis/bin/domainjoin-cli
>> query | grep -i 'domain' | grep -i ''}).nil? && $?.success?
>>   end
>> end
>>
>> The issue I'm seeing is that on a machine that is added to the domain, I
>> would expect the /opt/pbis...command to return true (as evidenced by the
>> exit status of zero on the command line).  However, upon running this new
>> fact, I get a value of: pbis_joined => false; even though I know the
>> machine is on the domain and running the command manually does give me an
>> exit status of '0' on this particular machine.
>>
>> I tried this new fact on another machine that I know is not joined to the
>> domain and I do get a 'false' on that box.
>>
>> If the problem is that #exec returns nil or a string; and being that I'm
>> looking to evaluate against an integer, could I not just do something like
>> 'domain_return.to_i' in the original code?
>>
>
I wasn't very clear on what #exec returns: the string it returns is the
stdout output of the executed process as a string; thus it would not
contain a representation of the exit code as you've already surmised.

Unfortunately, right now Ruby's built-in `$?` global variable is the only
way of getting at the exit code from the executed process with the way the
Facter execution API is currently defined.


>
>> I wanted to thank you again for your help.  It is very much appreciated.
>>
>> Cheers,
>>
>> Mike
>>
>>
>>
>> On Thursday, March 24, 2016 at 1:06:48 PM UTC-7, Peter Huene wrote:
>>>
>>> Hi Mike,
>>>
>>> On Thu, Mar 24, 2016 at 12:30 PM, Mike Reed <mjohn...@gmail.com> wrote:
>>>
>>>> Hey Peter,
>>>>
>>>> Thank you for the reply.
>>>>
>>>> If I run the command on a machine that I know is 'joined' to the domain
>>>> and run 'echo $?' immediately after, I get a return of '0'.
>>>>
>>>
>>> If you're going solely off of grep's exit status, try this:
>>>
>>> ```
>>> Facter.add(:pbis_joined) do
>>>   setcode do
>>>   !Facter::Util::Resolution.exec(%q{/opt/pbis/bin/domainjoin-cli
>>> query | grep -i 'domain' | grep -i ''}).nil? && $?.success?
>>>   end
>>> end
>>> ```
>>>
>>> Breaking that down:
>>>
>>> ```
>>> !Facter::Util::Resolution.exec(%q{/opt/pbis/bin/domainjoin-cli query |
>>> grep -i 'domain' | grep -i ''}).nil?
>>> ```
>>>
>>> This runs the command and ensures #exec doesn't return nil (which will
>>> happen if it failed to execute the command, e.g. command not found).
>>>
>>> ```
>>> $?.success?
>>> ```
>>>
>>> This ensures the executed process exited with a zero exit code (i.e. $?
>>> in a shell == 0).
>>>
>>> On an aside: do you need the piped greps?  Seems like the latter grep
>>> would be all that's needed assuming you're looking for just "",
>>> unless you intended this to be either "domain" or "", which won't
>>> work as currently constructed.
>>>
>>>
>>>>
>>>> Thank you again,
>>>>
>>>> Mike
>>>>
>>>> On Thursday, March 24, 2016 at 12:13:53 PM UTC-7, Peter Huene wrote:
>>>>>
>>>>> Hi Mike,
>>>>>
>>>>> On Thu, Mar 24, 2016 at 11:59 AM, Mike Reed <mjohn...@gmail.com>
>>>>> wrote

Re: [Puppet Users] facter value - not returning expected result

[Peter Huene]

Hi Mike,

On Thu, Mar 24, 2016 at 12:30 PM, Mike Reed <mjohn.r...@gmail.com> wrote:

> Hey Peter,
>
> Thank you for the reply.
>
> If I run the command on a machine that I know is 'joined' to the domain
> and run 'echo $?' immediately after, I get a return of '0'.
>

If you're going solely off of grep's exit status, try this:

```
Facter.add(:pbis_joined) do
  setcode do
  !Facter::Util::Resolution.exec(%q{/opt/pbis/bin/domainjoin-cli query
| grep -i 'domain' | grep -i ''}).nil? && $?.success?
  end
end
```

Breaking that down:

```
!Facter::Util::Resolution.exec(%q{/opt/pbis/bin/domainjoin-cli query | grep
-i 'domain' | grep -i ''}).nil?
```

This runs the command and ensures #exec doesn't return nil (which will
happen if it failed to execute the command, e.g. command not found).

```
$?.success?
```

This ensures the executed process exited with a zero exit code (i.e. $? in
a shell == 0).

On an aside: do you need the piped greps?  Seems like the latter grep would
be all that's needed assuming you're looking for just "", unless
you intended this to be either "domain" or "", which won't work as
currently constructed.


>
> Thank you again,
>
> Mike
>
> On Thursday, March 24, 2016 at 12:13:53 PM UTC-7, Peter Huene wrote:
>>
>> Hi Mike,
>>
>> On Thu, Mar 24, 2016 at 11:59 AM, Mike Reed <mjohn...@gmail.com> wrote:
>>
>>> Hey all,
>>>
>>> I'm a little stumped on why this fact is returning the incorrect value
>>> and I was hoping somebody would have some advice on this one.
>>>
>>> The fact is very basic and looks like this:
>>>
>>> # custom fact for detecting if machine is joined to the domain
>>> require 'facter'
>>>
>>> Facter.add(:pbis_joined) do
>>>   setcode do
>>>   domain_check = %q{/opt/pbis/bin/domainjoin-cli query | grep -i
>>> 'domain' | grep -i ''}
>>> domain_return = Facter::Util::Resolution.exec(domain_check)
>>> if domain_return == 0
>>>
>>
>> Facter::Util::Resolution.exec returns the command's output as a string or
>> nil if the command failed.  Thus, I would expect this conditional
>> (`domain_return == 0`) to never evaluate to true because a string or a nil
>> can never equal 0.
>>
>> What does the command output if you run it manually when you expect the
>> `pbis_joined` facter to be true?
>>
>>
>>>   pbis_joined = true
>>> else
>>>   pbis_joined = false
>>> end
>>>   end
>>> end
>>>
>>
>> Also, the `pbis_joined` local variable serves no purpose here, as it is
>> the return value from the block that sets the fact's value.
>>
>>
>>>
>>> Regardless of whether the domain_check command is a success on the
>>> client, I always get a value of 'true' from the fact.  In fact, if I
>>> completely remove the /opt/pbis folder from the machine and run the fact
>>> again, I still get a value of 'true'.  Additionally, If I manually run the
>>> domain_check command on a machine that I know is not joined to the domain,
>>> I will still get a value of 'true' from the fact.
>>>
>>> I've also tried both single '=' and double '==' for the 'if
>>> domain_return' piece of the fact and neither seem to give me what I want.
>>> I then thought that the domain_check object may not be considered an
>>> integer when comparing against the '0' so I added 'domain_return.to_i' and
>>> still got the same result.
>>>
>>> The code within the manifest that looks to this fact looks like this:
>>> if ($::pbis_joined == true) {etc,etc,etc}
>>>
>>> I do have stringify_facts set to 'false' within puppet.conf on both the
>>> client and the master.
>>>
>>> Puppet version 3.6.2/Hiera version: 1.3.4
>>>
>>> Does anybody have any suggestions they can give me as to why I'm not
>>> getting the correct return value?
>>>
>>> As always, thanks to everybody for their help and support.
>>>
>>> Cheers,
>>>
>>> Mike
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> 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...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/puppet-users/a1f8ece8-627b-478d-a108-97c91d76d654%40

Re: [Puppet Users] facter value - not returning expected result

[Peter Huene]

Hi Mike,

On Thu, Mar 24, 2016 at 11:59 AM, Mike Reed  wrote:

> Hey all,
>
> I'm a little stumped on why this fact is returning the incorrect value and
> I was hoping somebody would have some advice on this one.
>
> The fact is very basic and looks like this:
>
> # custom fact for detecting if machine is joined to the domain
> require 'facter'
>
> Facter.add(:pbis_joined) do
>   setcode do
>   domain_check = %q{/opt/pbis/bin/domainjoin-cli query | grep -i
> 'domain' | grep -i ''}
> domain_return = Facter::Util::Resolution.exec(domain_check)
> if domain_return == 0
>

Facter::Util::Resolution.exec returns the command's output as a string or
nil if the command failed.  Thus, I would expect this conditional
(`domain_return == 0`) to never evaluate to true because a string or a nil
can never equal 0.

What does the command output if you run it manually when you expect the
`pbis_joined` facter to be true?


>   pbis_joined = true
> else
>   pbis_joined = false
> end
>   end
> end
>

Also, the `pbis_joined` local variable serves no purpose here, as it is the
return value from the block that sets the fact's value.


>
> Regardless of whether the domain_check command is a success on the client,
> I always get a value of 'true' from the fact.  In fact, if I completely
> remove the /opt/pbis folder from the machine and run the fact again, I
> still get a value of 'true'.  Additionally, If I manually run the
> domain_check command on a machine that I know is not joined to the domain,
> I will still get a value of 'true' from the fact.
>
> I've also tried both single '=' and double '==' for the 'if domain_return'
> piece of the fact and neither seem to give me what I want.  I then thought
> that the domain_check object may not be considered an integer when
> comparing against the '0' so I added 'domain_return.to_i' and still got the
> same result.
>
> The code within the manifest that looks to this fact looks like this:  if
> ($::pbis_joined == true) {etc,etc,etc}
>
> I do have stringify_facts set to 'false' within puppet.conf on both the
> client and the master.
>
> Puppet version 3.6.2/Hiera version: 1.3.4
>
> Does anybody have any suggestions they can give me as to why I'm not
> getting the correct return value?
>
> As always, thanks to everybody for their help and support.
>
> Cheers,
>
> Mike
>
>
>
>
>
>
> --
> 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/a1f8ece8-627b-478d-a108-97c91d76d654%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/CACZQQfP%3D7kHSwGRtM2_vfpe77%2B%3Dk%3Dg3YPeqQDraxbfBEz%2BvSQQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: manipulating new facts

[Peter Huene]

On Tue, Jan 26, 2016 at 6:16 AM, jcbollinger 
wrote:

>
>
> On Monday, January 25, 2016 at 5:48:18 PM UTC-6, Diego Roccia wrote:
>>
>> Hi
>>
>> I'm migrating my puppet configuration from 3.6 to v4.2, but I'm having
>> some problem with ip type facts. For example, I have this line :
>>
>> priority  => inline_template('<%= 256 -
>> ipaddress.split(".")[3].to_i %>')
>>
>> on puppet 3.6 and it works, putting there the last octet of my ip
>> address. on puppet 4.2 I get:
>>
>> ==> node-1: Error: Evaluation Error: Error while evaluating a Function
>> Call, Failed to parse inline template: undefined local variable or method
>> `ipaddress' for # at
>> /tmp/vagrant-puppet/environments/test/manifests/default.pp:25:16 on node
>> node-1.station
>>
>> I think it depends on the new facts being no longer strings.
>>
>
>
> It is apparently true that in Facter 3, $ipaddress is of type 'ip' rather
> than of type string, but "undefined" is very different from "incorrect
> type".
>

The `ipaddress` fact should still be a string.  I think the confusion lies
in the schema calling it an "ip", which is really just a regular expression
that confines the string to a particular format, e.g. an IPv4 address).  If
you observe the `ipaddress` fact to be any other type please let us know,
as that would be a serious regression.


>
>
>
>> in facts this works:
>>
>> file { "/var/lib/zookeeper/myid":
>> ensure =>
>> present,
>>
>> content => "${ipaddress}"
>> }
>>
>> my file contains the whole ip address, but with this:
>>
>> file { "/var/lib/zookeeper/myid":
>> ensure =>
>> present,
>>
>> content => "${ipaddress.split('.')[3]}"
>> }
>>
>>
> the file is empty
>>
>
>
> As far as I am aware, that last form shouldn't work at all.  Unlike Ruby
> values, Puppet values do not have methods, unless you count array and hash
> indexing.  You cannot split a string like that (even if $ipaddress were a
> string).
>

Puppet 4 supports two different function call expressions: `foo(bar)` and
`bar.foo()`, where the latter form is called the "method call" expression.
As John said, Puppet doesn't have "methods" in the Ruby sense, only free
functions, so calls with the "method call" form are simply translated into
calling a free function with the same name (e.g. `foo`), passing the target
operand (e.g. `bar`) as the first argument to the function.  I hope that
makes sense.

>
>
>
>> any idea?
>>
>>
> In Puppet 3.6 you could access Puppet variables, including facts, via
> their bare names, but that form was deprecated well before the end of the
> 3.x series.  In ERB templates you should instead use the form @variable
> to access in-scope variables; this works in 3.x, too.  You can also use
> the scope object to access variables, including (counter-intuitively)
> those that are not in scope inside the template.  More details are
> available in the templating docs
> 
> .
>
> I'm not actually sure where to find any documentation on the type 'ip'
> that legacy fact $ipaddress now has, but you could try indexing into it
> as if it were an array of integers:
>
> priority => inline_template('<%= 256 - @ipaddress.[3] %>')
>
> Failing that, the value's stringification seems to be the same as the old
> string value, so you could very likely do this:
>
> priority => inline_template('<%= 256 - @ipaddress.to_s.split(".")[3].to_i
> %>')
>
>
> 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/6def4fc8-f97f-4de4-85e5-31afd2de5e2a%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/CACZQQfMcPEXBSvSp%2B7OGhncoEuVzV7qE6X8x92peXWR8hQ%2Bn1g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Data Type: Hashes

[Peter Huene]

Hi Matthew,

On Tue, Nov 24, 2015 at 4:35 PM, Matthew Ceroni 
wrote:

> I am having an issue accessing elements of a hash.
>
> First, it is defined in hiera as such:
>
> lb::rules:
>   VCC: rule1
>   GR: rule2
>
> I retrieve the value using
>
> $lb_rules = hiera('lb::rules')
>
> Then I simply try to print out one of the values
> ex:
>
>  notify { "$lb_rules[VCC]": }
>

VCC (without quotes) is a type name in the Puppet Language because it
starts with a capitalized letter.

Try using single quotes around VCC, like so:

```
notify { "$lb_rules['VCC']": }
```


>
> But get
>
> Error 400 on SERVER: Evaluation Error: Missing title. The title expression
> resulted in undef at
> /etc/puppet/environments/sandbox/manifests/site.pp:14:11
>
> If I don't specify a key and instead do
>
> notify { "$lb_rules": }
>
> I get
>
> Error 400 on SERVER: Evaluation Error: Illegal title type at index 0.
> Expected String, got Hash[String, String]
>
> Confirming that lb_rules is a hash.
>
>
>
>
> --
> 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/CA%2BNsY5jkQAEyamw7yauG2FWA6ktqeWGOVRZBCKaS_pW%2BYqS0OQ%40mail.gmail.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/CACZQQfMUPbmXm_DSzQgu%3DXBrrvkAVMcNtcHnpq-SOp7VaKsW%2Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Migrating to future parser (on 3.8) in preparation for upgrade to 4.0

[Peter Huene]

Hi Matthew:

On Tue, Nov 24, 2015 at 12:02 PM, Matthew Ceroni 
wrote:

> Working on migrating my manifests to work with Puppet 4.0. Currently on
> 3.8 and have started to experiment with the future parser (probably not so
> much future anymore).
>
> I am stuck on an error that is being reported.
>
> Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
> Evaluation Error: Error while evaluating a Function Call, ensure parameter
> must be specified at
> /etc/puppet/environments/sandbox/modules/sudo/manifests/init.pp:51:2 on
> node op1227
>
> The code is a simple check and fail if not met
>
> if ! ($ensure in [ 'present', 'absent' ]) {
> fail("sudo 'ensure' parameter must be set to either 'absent' or
> 'present'")
> }
>
>
Fail is expected to fail the parse, but I'd expect the given error message
to match up with what was returned by the server.

What's the value of $ensure at evaluation time?  Perhaps changing the error
message to something like "'$ensure' is not a valid value for parameter
\$ensure: expected either 'absent' or 'present'" so it's easily displayed
in the error might help debug this.


> It isn't liking something about the function call fail.
>
> Any help would be appreciated.
>
> 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-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/CA%2BNsY5iN4%3DjYvXnppOdnw_KLNZZtunauoF8kodryXLwYcohEhA%40mail.gmail.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/CACZQQfPAKWAyffwxkPFW9nY-Rz0Z2TFa11BfUbsA9CH%3DYBR_RA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet/Facter custom fact on windows misbahaving

[Peter Huene]

On Wed, Nov 18, 2015 at 1:54 AM, Fredrik Nilsson 
wrote:

> Hi folks,
>
> So I have an interesting behaviour of a custom fact I'm trying to deploy
> to our windows boxes using Puppet. I'm not certain wether this is a bug or
> if I'm doing the fact all wrong. I've been going over the fact it self a
> few times to make certain that it works as intended, and it seemingly do,
> so there must be something else going on. What I want to accomplish is to
> check which version of IIS is installed on the boxes that have that feature
> installed, the way I found to do that is to read the registry value found
> under the property "VersionString" under
> "HKLM:\SOFTWARE\Microsoft\InetStp". This fact will serve to purposes check
> wether IIS feature is installed and which version that is, of course one
> could settle just for checking if the feature is installed, but me myself
> never remember what version of IIS came with what version of Windows...
>
> So this is my fact written in Ruby:
>
>  Facter.add(:iis_version) do
>   confine :kernel => :windows
>   setcode do
>  version = nil
>  require 'win32/registry'
>  begin
>  Win32::Registry::HKEY_LOCAL_MACHINE.open('SOFTWARE\Microsoft\InetStp') do
> |reg|
>  version = reg['VersionString']
>   version = version[8,3]
>  end
> rescue Win32::Registry::Error
> end
> version
> end
> end
>
>
> I've made some runs just using Ruby with a script from line 4-13 and then
> I wrapped it up in a facter wrapping and have "beta tested" it on some
> boxes manually putting the fact in this path:
> C:\ProgramData\PuppetLabs\puppet\var\lib\facter, everything working just
> great. If there is an IIS installation it returns the value of the registry
> property, and if that property is absent nothing is returned.
>
> Then Puppet comes in to play, in my module I put my script in the path
> /lib/facter allong with my other customfacts (all the other are wrapped
> Powershell scripts), I run it through code review and such, Jenkins thinks
> everything is play ball. But then the fishy part comes in to play, as I
> said, obviously I've done a few itterations of the script to get it
> right and as I've come to understand the custom facts part in different
> modules, the /lib/facter path, could have problem with compartmentalization
> in our Puppet version (3.8.4). BTW our Windows boxes also on client version
> 3.8.4. Any way what happens is that on each puppet run the custom fact
> file, iis_version.rb, gets replaced two times, always with the same to
> hashes from {md5}11c0899297882d8c4b1e6005688a339a' to
> '{md5}8b99d355199c9628c459c6d7dc62e4ee' and then the step after back again
> :-S. When I check the content of the file I get this:
>
> # iis_version.rb
> Facter.add("iis_version") do
>  confine :kernel => :windows
>   setcode do
> begin
>   psexec = if File.exists?(
> "#{ENV['SYSTEMROOT']}\\sysnative\\WindowsPowershell\\v1.0\\powershell.exe"
> )
>
> "#{ENV['SYSTEMROOT']}\\sysnative\\WindowsPowershell\\v1.0\\powershell.exe"
>elsif File.exists?(
> "#{ENV['SYSTEMROOT']}\\system32\\WindowsPowershell\\v1.0\\powershell.exe")
>
> "#{ENV['SYSTEMROOT']}\\system32\\WindowsPowershell\\v1.0\\powershell.exe"
>else
> 'powershell.exe'
>end
>   iis_ver = %x{#{psexec} -ExecutionPolicy ByPass -Command
> "(Get-ItemProperty HKLM:\\SOFTWARE\\Microsoft\\InetStp\\ -Name
> VersionString).VersionString.SubString(8,3)"}
> rescue
>   iis_ver = ""
> end
> iis_ver
>   end
> end
>
> SAY WHAT? It is a not entirely satisfying "translation" of my Ruby
> script into a wrapped Powershell script, it misses out on some key parts
> from my point of view. This have happened all the time since the first
> itteration of my script, which I think never have been a wrapped script, it
> have always been all Ruby, don't quite recall though.
>

It looks like another module has a custom fact with the same file name.
Unfortunately Puppet agent's pluginsync doesn't properly handle modules
with identical file names very well.

Does renaming your fact file to something unique work?  If so, that would
indicate the issue is a conflict with another module's file and the other
module is unfortunately overwriting your fact when the custom facts are
synced to the agent.


>
> I have no clue where this is comming from.  I think my Ruby script is just
> fine, it's my first one so it might look ugly to a Ruby jedi. But neither
> me (a Windows admin) or the puppet master (a Linux guy) can figure this one
> out. Anyone have a clue, seen the same behaviour, have any pointers?
>
> --
> 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
> 

Re: [Puppet Users] Re: strange line wrapping behavior

[Peter Huene]

On Wed, Nov 18, 2015 at 8:42 AM,  wrote:

>
> Have you tried omitting the '\'?  As far as I know, Puppet has no
>> requirement that array literals be expressed all on one line, and newlines
>> are permitted as part of the optional whitespace between elements.
>>
> It will work without the "\". I was just wondering why because I haven't
> found anything in the official documentation and on several web places for
> some reason the "\" solution was propagated.
>

It works because Puppet ignores whitespace between tokens entirely.  That
said you can't insert whitespace in the middle of a token and there's no
way to "continue" the token into the next line (i.e. a line continuation
marker).

For example, this is legal:

```
notice(
   hello::world
)
```

But this is not:

```
notice(
hello::
world
)
```

That is because the line break is in the middle of the name token, making
it malformed.

Note that string literal tokens may span multiple lines, but the whitespace
is made part of the string:

```
notice('
 hello
 world
')
```

i.e. this will print the line breaks as they are part of the string.

Hope that helps.


> --
> 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/1491dc4d-91c2-414e-8db8-6f90c3189921%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/CACZQQfMRm8MyMxJdEeKH7b-eejorZ07jtMwE0wk4GRphA0yeew%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Structured custom fact behavior

[Peter Huene]

Hi Guto,
On Nov 17, 2015 6:19 PM, "Guto Carvalho"  wrote:
>
> Hi guys,
>
> I'm playing around with custom facts, I'm trying to create a simple
custom (structured) fact.
>
> [root@centos7 ~]# puppet --version
> 4.2.1
>
> [root@centos7 ~]# facter --version
> 3.0.2 (commit 5dc120fa9db4c19150466b1bbd1d0cf42c87c6bd)
>
> Here is my code
>
> https://gist.github.com/gutocarvalho/d60987f4cee423d017c4
>
> The fact is almost working
>
> root@centos7 ~]# facter -p postgresql
> {
>   installed => true,
>   version => "9.2.13"
> }
>
> When I try to print the fact value using notify it works fine
>
> notify { "PostgreSQL version is ${::postgresql['version']}":
>
> info: Applying configuration version '1447812110'
> Notice: PostgreSQL version is 9.2.13
> Notice: /Stage[main]/Main/Node[centos7.puppet]/Notify[PostgreSQL version
is 9.2.13]/message: defined 'message' as 'PostgreSQL version is 9.2.13'
>
> But, when I try to call postgresql.installed or postgresql.version facter
doesn't show any result.

This was a bug in facter that was recently fixed. The bug was that facts
from ruby (i.e. custom facts) were not able to be traversed by facter's
command line query.  I'm on a mobile device at the moment, so I'll
follow-up with a link to a ticket when I can.

>
> [root@centos7 ~]# facter -p postgresql.installed
>
> [root@centos7 ~]# facter -p postgresql.version
>
> What could possibly cause this?
>
> --
> 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/be550b4e-e7b7-4e36-89d4-2e37445b910f%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/CACZQQfOg5szLMngRFwWswgKasEyzEWnx5u-xbP3nDqQrksapbA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Structured custom fact behavior

[Peter Huene]

On Tue, Nov 17, 2015 at 6:24 PM, Peter Huene <peter.hu...@puppetlabs.com>
wrote:

> Hi Guto,
> On Nov 17, 2015 6:19 PM, "Guto Carvalho" <gutocarva...@gmail.com> wrote:
> >
> > Hi guys,
> >
> > I'm playing around with custom facts, I'm trying to create a simple
> custom (structured) fact.
> >
> > [root@centos7 ~]# puppet --version
> > 4.2.1
> >
> > [root@centos7 ~]# facter --version
> > 3.0.2 (commit 5dc120fa9db4c19150466b1bbd1d0cf42c87c6bd)
> >
> > Here is my code
> >
> > https://gist.github.com/gutocarvalho/d60987f4cee423d017c4
> >
> > The fact is almost working
> >
> > root@centos7 ~]# facter -p postgresql
> > {
> >   installed => true,
> >   version => "9.2.13"
> > }
> >
> > When I try to print the fact value using notify it works fine
> >
> > notify { "PostgreSQL version is ${::postgresql['version']}":
> >
> > info: Applying configuration version '1447812110'
> > Notice: PostgreSQL version is 9.2.13
> > Notice: /Stage[main]/Main/Node[centos7.puppet]/Notify[PostgreSQL version
> is 9.2.13]/message: defined 'message' as 'PostgreSQL version is 9.2.13'
> >
> > But, when I try to call postgresql.installed or postgresql.version
> facter doesn't show any result.
>
> This was a bug in facter that was recently fixed. The bug was that facts
> from ruby (i.e. custom facts) were not able to be traversed by facter's
> command line query.  I'm on a mobile device at the moment, so I'll
> follow-up with a link to a ticket when I can.
>

FYI, this was FACT-1254: https://tickets.puppetlabs.com/browse/FACT-1254

It was fixed in Facter 3.1.2.


> >
> > [root@centos7 ~]# facter -p postgresql.installed
> >
> > [root@centos7 ~]# facter -p postgresql.version
> >
> > What could possibly cause this?
> >
> > --
> > 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/be550b4e-e7b7-4e36-89d4-2e37445b910f%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/CACZQQfOfS4Pc4FN7vDQ8bwidBqFZCucUBkFPpqK%2BnT41NAWrSg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] External facts and the Vagrant Puppet Provider

[Peter Huene]

Hi Fraser,

On Fri, Nov 13, 2015 at 10:00 AM, Fraser Goffin  wrote:

> Puppet: 4.2.1
> Facter: 3.0.2
> OS: Windows
>
> I have a module with a facts.d folder containing a simple yaml file and a
> powershell script :-
>
> sonatype_nexus
> - puppet
> - modules
> - sonatype_nexus
> - facts.d
>  facts.yaml
>  alpha.ps1
>
>
> facts.yaml :-
>
>baz: baz
>
> alpha.ps1 :-
>
> Write-Host "alpha=alpha"
>

> ... and just for the purpose of illustration, the puppet class just tries
> to emit the two facts :-
>
>   notice($::baz)
>   notice($::alpha)
>
> When I run this on my laptop using a simple 'puppet apply' all is well :-
>
> Notice: Scope(Class[Sonatype_nexus]): CLASS: sonatype_nexus
> Notice: Scope(Class[Sonatype_nexus]):
> Notice: Scope(Class[Sonatype_nexus::Windows::Install]): baz
> Notice: Scope(Class[Sonatype_nexus::Windows::Install]): alpha
> Notice: Compiled catalog for lt032064.avivagroup.com in environment
> production in 1.78 seconds
> Notice: Applied catalog in 3.03 seconds
>
> Furthermore, If I switch debug on I can see facter resolving those very
> facts too :-
>
> Debug: Facter: searching
> "E:/Data\git\sonatype_nexus\puppet\modules\sonatype_nexus\facts.d" for
> external facts.
> Debug: Facter: checking execution on
> E:/Data\git\sonatype_nexus\puppet\modules\sonatype_nexus\facts.d\alpha.ps1
> Debug: Facter: resolving facts from powershell script
> "E:/Data\git\sonatype_nexus\puppet\modules\sonatype_nexus\facts.d\alpha.ps1".
> Debug: Facter: executing command:
> C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe -NoProfile
> -NonInteractive -NoLogo -ExecutionPolicy Bypass -File
> E:/Data\git\sonatype_nexus\puppet\modules\sonatype_nexus\facts.d\alpha.ps1
> Debug: Facter: alpha=alpha
> Debug: Facter: fact "alpha" has resolved to "alpha".
> Debug: Facter: process exited with exit code 0.
> Debug: Facter: completed resolving facts from powershell script
> "E:/Data\git\sonatype_nexus\puppet\modules\sonatype_nexus\facts.d\alpha.ps1".
> Debug: Facter: resolving facts from YAML file
> "E:/Data\git\sonatype_nexus\puppet\modules\sonatype_nexus\facts.d\facts.yaml".
> Debug: Facter: fact "baz" has resolved to "baz".
> Debug: Facter: completed resolving facts from YAML file
> "E:/Data\git\sonatype_nexus\puppet\modules\sonatype_nexus\facts.d\facts.yaml".
> ...
>
> However, when I run the same code on Vagrant using the Puppet provisioner,
> I get a very different result :-
>
> *Warning: Facter: skipping external facts for
> "C:/tmp/vagrant-puppet/modules-d002123d6028e7e12b22cf92698d76f5/sonatype_nexus/facts.d":
> The request is not supported*
>

This failure (ERROR_NOT_SUPPORTED) is coming from Facter before the
Powershell script is being executed.  There is code to canonicalize the
directory's path (because relative paths are supported) and the failure is
coming the library Facter uses to do that canonicalization.

Do you know if
'C:/tmp/vagrant-puppet/modules-d002123d6028e7e12b22cf92698d76f5/sonatype_nexus/facts.d'
is a NTFS reparse point by chance?  Those aren't always supported well in
third party libraries.

Regardless of the issue in the underlying library Facter uses, Facter
should probably debug/warn that the directory could not be canonicalized
(or skip canonicalization if the path is already absolute) and try to
search for files in it anyway, rather than "skipping" the directory
entirely.

If possible, could you create a ticket at https://tickets.puppetlabs.com
describing the issue and provide all the great information you've included
in this post and we'll try to get this fixed in Facter.

Thanks!


>
> and neither of the facts are available to the class.
>
> Debug output, doesn't really provide mush more than that :-
>
> ...
> Debug: Runtime environment: puppet_version=4.2.1, ruby_version=2.1.6,
> run_mode=user, default_encoding=CP850
> Debug: Evicting cache entry for environment 'production'
> Debug: Caching environment 'production' (ttl = 0 sec)
> Debug: Evicting cache entry for environment 'production'
> Debug: Caching environment 'production' (ttl = 0 sec)
> Debug: Loading external facts from
> C:/tmp/vagrant-puppet/modules-d002123d6028e7e12b22cf92698d76f5/sonatype_nexus/facts.d
> Debug: Loading external facts from
> C:/ProgramData/PuppetLabs/puppet/cache/facts.d
> Info: Loading facts
> Debug: Loading facts from
> C:/tmp/vagrant-puppet/modules-d002123d6028e7e12b22cf92698d76f5/chocolatey/lib/facter/chocolateyversion.rb
> Debug: Loading facts from
> C:/tmp/vagrant-puppet/modules-d002123d6028e7e12b22cf92698d76f5/chocolatey/lib/facter/choco_install_path.rb
> Info: Loading facts
> Debug: Loading facts from
> C:/tmp/vagrant-puppet/modules-d002123d6028e7e12b22cf92698d76f5/stdlib/lib/facter/facter_dot_d.rb
> Debug: Loading facts from
> C:/tmp/vagrant-puppet/modules-d002123d6028e7e12b22cf92698d76f5/stdlib/lib/facter/pe_version.rb
> Debug: Loading facts from
> 

Re: [Puppet Users] What is the preferred method for getting back a single custom fact now that facter -p is deprecated?

[Peter Huene]

Hi Trevor,

On Fri, Oct 23, 2015 at 2:46 PM, Trevor Vaughan 
wrote:

> While I'm a master of parsing clumped JSON by eye, not everyone might be...
>

TL;DR: you may continue to use the `--puppet` option in Facter 3.0.2+.

We reversed course on removing the `--puppet` option from Facter in 3.0.2
as there was no suitable replacement in place ("puppet facts" just doesn't
cut it).  While it's still considered to be "deprecated" in the sense that
we don't like having a "reverse" dependency on Puppet from Facter, I don't
think we have plans to implement a replacement any time soon.

If you have a single location where your custom facts are stored, you may
also pass the "--custom-dir" option to Facter to let it search the given
directory for custom facts; it's an easy alternative if you're just hacking
a custom fact together without a Puppet module in place.


>
> Thanks,
>
> Trevor
>
> --
> Trevor Vaughan
> Vice President, Onyx Point, Inc
> (410) 541-6699
>
> -- This account not approved for unencrypted proprietary information --
>
> --
> 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/CANs%2BFoVkcY6h9uJYAmACogR0EAggNbfhnPGYQf4yoMJcpH6ebA%40mail.gmail.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/CACZQQfN2gfVw8ihdM-Acc-bnto4YHf6Pe_1gxFo_FQP-oxKFdg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Confine a custom fact by file existence

[Peter Huene]

Hi Thomas,

On Thu, Oct 22, 2015 at 1:00 AM, Thomas Müller 
wrote:

> Hi
>
> I know it's possible to confine a fact by other facts like "confine
> :operatingsystem => :Fedora".
>
> But i have a fact which requires a binary from a rpm package which is only
> installed by puppet. For the first puppet run tries to execute the not-yet
> installed binary and fails.
>
> is it possible to use something like this to confine based on existing
> files?
>

It is possible, as the `confine` method also takes a block:

```
Facter.add(:foo) do
  confine do
File.exist? '/path/to/binary'
  end

  setcode do
'bar'
  end
end
```


>
> confine File.exists?(/path/to/binary)
>
>
> Or what is the best practice for such facts which rely on things installed
> by puppet manifests?
>
> - Thomas
>
> --
> 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/3cc22965-5c92-49da-a370-36589d6c0dc9%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/CACZQQfMAx7XKQQik8qwKGGV51AKodb%3DJ%3DjKY7cvbM6nw6es%2BZg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet method to subtract two arrays?

[Peter Huene]

Hi Sean,

On Thu, Sep 17, 2015 at 12:01 PM, Sean <smalde...@gmail.com> wrote:

> Hello,
>
> I have been working on trying to drive an include statement with an array
> parameter.
>
> The idea looks like so (in pseudo code) :
>
>
> class foo( $whitelist = $::foo::params::whitelist, $blacklist = [],) {
>
>   $include_list = inline_template( "<% @whitelist - @blacklist %>" )
>   validate_array($include_list)
>   include $include_list
>
> }
>
> I picked up that inline template from a message in the group dating back
> to 2011.
>

The template is missing a '=' character to write the result, like so:

<%= @whitelist - @blacklist %>

However, this will return a string-ified version of the array and is not
what you want as include will treat it as a single class name.

In the current version of the Puppet language, two arrays can simply be
subtracted from one another:

$whitelist = [foo, bar, baz]
$blacklist = [bar]
include $whitelist - $blacklist

This would include "foo" and "baz", but not "bar".


> Basically, class foo has a ton of subclasses who's names populate the
> default value for $whitelist.  Normally all these get applied, but I need
> to allow for deviations for specific cases, thus the blacklist.
>
> The issue seems to be that no matter what I put in whitelist or blacklist,
> include_list is always empty.  What am I missing?  I have also tried
> writing a Custom Function to do the same as the inline template but the
> result was not anymore successful, though the debugging was more difficult.
>
> Thanks for your thoughts on this!
>
> --
> 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/6ac9c22b-f5fc-409b-a75e-7d286862220b%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/6ac9c22b-f5fc-409b-a75e-7d286862220b%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
--
Peter Huene
Software Engineer, Puppet Labs
Puppet Open Source Team
---

*PuppetConf 2015 <http://2015.puppetconf.com/> ** is right around the
corner! Join us October 5-9 in Portland, OR. *
*Register now <https://puppetconf2015.eventbrite.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/CACZQQfPx4Xo46M1dKYJ7XdMwGCCE95%3DPXdJMi6X7LznDB5QuQw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] How can I send parameters to a required class?

[Peter Huene]

On Wed, Aug 26, 2015 at 11:50 PM, Francis Chan poi...@gmail.com wrote:

 I'm using the something like this since I want all of class bar to be
 applied before any class foo:

 # init.pp for module bar
 class bar( $var = hello )
 {
 }


 # something.pp in module foo
 class foo::something {
 require bar
 }


Instead of using the `require` function, try using the resource-like
declaration syntax:

class { bar:
  var = world,
  before = Class[foo::something]
}

This has the same effect as the require function (i.e. making
Class[foo::something] dependent upon Class[bar]), but it passes world as
the value for $var.

Is it possible to change bar::var using when foo uses the require
 statement?  Is there another way that will keep the same dependency but
 allow me to pass in parameters to the required class?

 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-users+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/puppet-users/23998ab8-35c4-4bc8-987a-41bc791ade00%40googlegroups.com
 https://groups.google.com/d/msgid/puppet-users/23998ab8-35c4-4bc8-987a-41bc791ade00%40googlegroups.com?utm_medium=emailutm_source=footer
 .
 For more options, visit https://groups.google.com/d/optout.




-- 
--
Peter Huene
Software Engineer, Puppet Labs
Puppet Open Source Team
---

PuppetConf 2015 is coming to Portland, Oregon! Join us October 5-9!

-- 
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/CACZQQfN_asdjO%3DCphoR%3DN2owuXkJ0gJSq%2BUTgccu05ygNmJf_g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] 2015.2 strange message

[Peter Huene]

Hi Vince,

On Thu, Aug 13, 2015 at 10:21 AM, Vince Skahan vinceska...@gmail.com
wrote:

 Spun up a 2015.2 system and every time an agent runs we see Error:
 Facter: error while resolving custom facts in
 /opt/puppetlabs/puppet/cache/lib/facter/portage.rb: cannot load such file
 -- facter/util/resolution.   Any ideas ?

 I saw one bug report at
 https://github.com/gentoo/puppet-portage/issues/136 saying facter needed
 to be updated and this was allegedly done in 2015.2, but perhaps not (???)


This was fixed in the puppet-portage module itself, so updating the module
to a fixed version or porting the fix to the fact file (simply delete the
require 'facter/util/resolution' line) should solve the problem with Facter
3.  This particular fix is also backwards compatible with 2.x, as 2.x also
required this file before resolving any custom facts.

If memory serves, I searched through the Forge for references in custom
facts depending on the Facter 2.x implementation's file structure and found
only this one.  Therefore I didn't end up adding the workaround to Facter
itself to support requiring parts of 2.x Facter beyond simply `require
'facter'` (which itself is also unnecessary, but was more frequently
done).  We could revisit fixing this in Facter itself (basically
manipulating the load path to fake the load of 'facter/util/resolution') if
it proves to be a more widespread problem affecting other modules.



 Vagrant box I'm testing on is centos-6.7 fully patched up.

 --
 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/e23e8c46-3b97-4a7e-bb88-ccba4abc06a4%40googlegroups.com
 https://groups.google.com/d/msgid/puppet-users/e23e8c46-3b97-4a7e-bb88-ccba4abc06a4%40googlegroups.com?utm_medium=emailutm_source=footer
 .
 For more options, visit https://groups.google.com/d/optout.




-- 
--
Peter Huene
Software Engineer, Puppet Labs
Puppet Open Source Team
---

PuppetConf 2015 is coming to Portland, Oregon! Join us October 5-9!

-- 
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/CACZQQfO%2B0tnOaFxR6W5L%3DZVaSeF2OdjutH%2B9w%3DPUi4xeJDjcDA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] PE 2015.2 puppet master cannot load custom facts

[Peter Huene]

On Wed, Aug 5, 2015 at 3:11 PM, Maneesh M P endej...@gmail.com wrote:

 I am facing issues with path of customs facts and with forge modules  in
 the latest PE 2015.2 version of puppet.

 Custom facts are located at :  /var/opt/lib/pe-puppet/lib/facter/
 Common forge modules are located at :
 /etc/puppetlabs/puppet/modules/production/modules

 But I keep getting below errors while executing the puppet agent on puppet
 master.

 Error: Facter: error while resolving custom facts in
 /var/opt/lib/pe-puppet/lib/facter/nodejs_stable_version.rb: Version is not
 a class


Could you pastebin the contents of this custom fact so I can take a look?
Also, try running the agent with `-d --trace --test` and see if Facter
outputs anything useful related to the error.


 Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
 Invalid parameter: 'sources' on Class[R10k] at
 /etc/puppetlabs/puppet/environments/integration/modules/master/manifests/setup.pp:15
 on node master.abc.com


 Snippet of my puppet.conf

 [main]
 certname = master.abc.com
 vardir = /var/opt/lib/pe-puppet
 logdir = /var/log/pe-puppet
 rundir = /var/run/pe-puppet
 basemodulepath =
 /opt/puppetlabs/puppet/modules:/etc/puppetlabs/puppet/modules/production/modules
 environmentpath = /etc/puppetlabs/puppet/environments

 .

 Any help will be appreciated.

 Thanks,
 En

 --
 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/1dd3ec7b-a7ac-4c8b-83f2-51e8cf8a2db2%40googlegroups.com
 https://groups.google.com/d/msgid/puppet-users/1dd3ec7b-a7ac-4c8b-83f2-51e8cf8a2db2%40googlegroups.com?utm_medium=emailutm_source=footer
 .
 For more options, visit https://groups.google.com/d/optout.




-- 
--
Peter Huene
Software Engineer, Puppet Labs
Puppet Open Source Team
---

PuppetConf 2015 is coming to Portland, Oregon! Join us October 5-9!

-- 
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/CACZQQfNttnCuJYDLJjfHezFYyboCXPU3u9Wvi8YakXfMPoZw%2Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Puppet server failing on invalid UTF-8 facts

[Peter Huene]

On Wed, Jul 22, 2015 at 3:01 AM, Federico Agnelli fagne...@gmail.com
wrote:

 Hi Peter,

 attached you can find the output of dmidecode and another file with the
 output of the cat command.


It looks like, for whatever reason, those values were set by the
manufacturer to 0xFF 0xFF 0xFF ...

dmidecode outputs a series of dots to represent these invalid characters.
I've opened https://tickets.puppetlabs.com/browse/FACT-1140 to track this
issue so that Facter fixes it in a similar way.

I should have a fix into the stable branch soon, but unfortunately it won't
make it into the about-to-be-released Facter 3.0.2.

Thanks!



 Thanks,
 Federico


 Il giorno lunedì 20 luglio 2015 22:24:18 UTC+2, Peter Huene ha scritto:


 On Monday, July 20, 2015 at 1:23:20 PM UTC-7, Peter Huene wrote:

 On Monday, July 20, 2015 at 1:16:07 PM UTC-7, Federico Agnelli wrote:

 Hi Giorgio,

 I have the same problem with a puppet client on Intel NUC5i5RYH.
 All other clients (on different hardware) with the same puppet version
 work fine.

 My puppet version for both agent and server is 4.2.0. Version 4.1.0 was
 ok.


 It looks like Facter is expecting the contents of those files to be
 UTF-8, which may not be the correct thing to do.  Could you install/run the
 dmiencode utility and paste the output?  Also, cat the same files Giorgio
 did and attach as a file (the characters are coming through as invalid
 characters in Google Groups).  Thanks!


 Correction: the utility is *dmidecode*.





 Did you find a fix?

 Thanks,
 Federico

  --
 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/164d75be-37df-47aa-a341-a093cda95cdb%40googlegroups.com
 https://groups.google.com/d/msgid/puppet-users/164d75be-37df-47aa-a341-a093cda95cdb%40googlegroups.com?utm_medium=emailutm_source=footer
 .

 For more options, visit https://groups.google.com/d/optout.




-- 
*Join us at **PuppetConf 2015, October 5-9 in Portland, OR - *www.
http://www.google.com/url?q=http%3A%2F%2Fwww.sa=Dsntz=1usg=AFQjCNEnS7itqgvQV3E4Se1fu4Um_UapSw
2015.puppetconf.com
http://www.google.com/url?q=http%3A%2F%2F2015.puppetconf.comsa=Dsntz=1usg=AFQjCNE1uQL4Sh23Vr-XkPLa4xfNcoXSog

*Register early to save 40%!*

-- 
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/CACZQQfM9X-iWwZHSDb9g1vWqs5%3DZf%3Dm5jqtigHQj5qe3B_mY1Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] puppet facts and mcollective are incompatible

[Peter Huene]

On Tue, Jul 21, 2015 at 1:27 AM, Fabrice Bacchella 
fabrice.bacche...@orange.fr wrote:



 
  For this (and a few other reasons), the breaking change of removing the
 -p switch in Facter 3.0.0 is being reverted in 3.0.2, which will be
 released very soon.
 

 When do you expect it to be released ?


Within a few days, hopefully.



 I've found many bugs with facter 3 (and I've been using it only for a few
 days), where can I found the list of closed bugs for this release ?


Here's a list of what's been addressed in 3.0.2:
https://tickets.puppetlabs.com/issues/?jql=project%20%3D%20FACT%20AND%20fixVersion%20%3D%20%22FACT%203.0.2%22

There have been a number of regression fixes including fixes to command
execution, inclusion of the -p option, porting the xendomains fact, OS fact
fixes, and the fqdn fact reporting incorrectly on some systems.

If there's an issue you're running into that you don't see being addressed
in this release, please file a ticket describing your problem and let me
know the ticket number and I'll see what I can do to address the problem.
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-users+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/puppet-users/57D60F90-53A6-403A-922B-39A07A58AE12%40orange.fr
 .
 For more options, visit https://groups.google.com/d/optout.




-- 
*Join us at **PuppetConf 2015, October 5-9 in Portland, OR - *www.
http://www.google.com/url?q=http%3A%2F%2Fwww.sa=Dsntz=1usg=AFQjCNEnS7itqgvQV3E4Se1fu4Um_UapSw
2015.puppetconf.com
http://www.google.com/url?q=http%3A%2F%2F2015.puppetconf.comsa=Dsntz=1usg=AFQjCNE1uQL4Sh23Vr-XkPLa4xfNcoXSog

*Register early to save 40%!*

-- 
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/CACZQQfPnhnFU2jZBDe_NY2JyFauCi6JtqmGxdzYBYGBsiLeQNw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] facter 3 and linux disagree about interfaces

[Peter Huene]

On Tue, Jul 21, 2015 at 9:50 AM, Fabrice Bacchella 
fabrice.bacche...@orange.fr wrote:

 On a linux, if I enumerate interfaces using standards tools I get :
 ~# ip link list
 1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
 2: eth0: BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP mtu 1500 qdisc mq master
 bond0 state UP qlen 1000
 link/ether 00:1c:c4:74:83:80 brd ff:ff:ff:ff:ff:ff
 3: eth1: BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP mtu 1500 qdisc mq master
 bond0 state UP qlen 1000
 link/ether 00:1c:c4:74:83:80 brd ff:ff:ff:ff:ff:ff
 4: bond0: BROADCAST,MULTICAST,MASTER,UP,LOWER_UP mtu 1500 qdisc noqueue
 state UP
 link/ether 00:1c:c4:74:83:80 brd ff:ff:ff:ff:ff:ff


 ~# cat /proc/net/dev
 Inter-|   Receive|
 Transmit
  face |bytespackets errs drop fifo frame compressed multicast|bytes
 packets errs drop fifo colls carrier compressed
 lo: 3406986600 26540155000 0  0 0
 3406986600 26540155000 0   0  0
   eth0: 40938625356 197161174000 0  0   1254629
 626979237863 480085481000 0   0  0
   eth1: 72695854413 260987060600 6  0   1254612
 69902498 507216135000 0   0  0
  bond0: 113634479769 458148234600 6  0   2509241
 1326004215641 987301616000 0   0  0

 I don't use ifconfig any more, it's deprecated since ages.

 But with facter I got one more :
 ~# /opt/puppetlabs/bin/facter interfaces
 bond0,bond0:1,eth0,eth1,lo

 Because bond0 has two interfaces :
 ~# ip addr list bond0
 4: bond0: BROADCAST,MULTICAST,MASTER,UP,LOWER_UP mtu 1500 qdisc noqueue
 state UP
 link/ether 00:1c:c4:74:83:80 brd ff:ff:ff:ff:ff:ff
 inet xxx/20 brd  scope global bond0
 inet xxx/20 brd xxx scope global secondary bond0:1

 In full structured view I get
 networking = {
   
   interfaces = {
 bond0 = {
 },
 bond0:1 = {
 },
   },
 }

 I would expect something like:
 networking = {
   
   interfaces = {
 bond0 = {
   [ ip = ]
   [ ip = ]
 },
   },
 }


 Is that a bug or a feature ?

 My view it's bug, because when I ask for interfaces, I mean interfaces,
 not interfaces and friends. But it might be different on other OS.


I agree that Facter could do a better job merging the secondary interface
into the primary one here.  It shares the networking fact code with a few
other platforms (mainly OSX and the BSDs) and it currently doesn't do any
specific logic for Linux to merge bonded interfaces together.

We could potentially address this in a backwards-compatible way by adding a
secondary  field to a interface entry that is an array of the remaining
secondary addresses.  Thus, the bond0:1 interface would be effectively
moved to networking.interfaces.bond0.secondary.0.  Would that make sense
to do?


 In full struc

 --
 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/C5E27602-09BE-42A1-8040-C7B764116A06%40orange.fr
 https://groups.google.com/d/msgid/puppet-users/C5E27602-09BE-42A1-8040-C7B764116A06%40orange.fr?utm_medium=emailutm_source=footer
 .
 For more options, visit https://groups.google.com/d/optout.




-- 
*Join us at **PuppetConf 2015, October 5-9 in Portland, OR - *www.
http://www.google.com/url?q=http%3A%2F%2Fwww.sa=Dsntz=1usg=AFQjCNEnS7itqgvQV3E4Se1fu4Um_UapSw
2015.puppetconf.com
http://www.google.com/url?q=http%3A%2F%2F2015.puppetconf.comsa=Dsntz=1usg=AFQjCNE1uQL4Sh23Vr-XkPLa4xfNcoXSog

*Register early to save 40%!*

-- 
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/CACZQQfMt%3D12KyoCo0iHKPZEHc3eZePCahxUNaUvmKAE20YKo6g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] facter 3 and linux disagree about interfaces

[Peter Huene]

On Tue, Jul 21, 2015 at 11:47 AM, Fabrice Bacchella 
fabrice.bacche...@orange.fr wrote:


  Le 21 juil. 2015 à 20:33, Peter Huene peter.hu...@puppetlabs.com a
 écrit :

 
  Thus there would be no eth0:1 in the interfaces list; it would just
 show up as the first element in the secondary array.  e.g. eth0:1 becomes
 eth0.secondary.0, eth0:2 becomes eth0.secondary.1, etc.
 
  Thoughts on this approach? It would better model the output of command
 line tools that don't distinguish interfaces between iface and iface:x.
 
  Alternatively, we could keep eth0:1 in the list and have a reference to
 the primary interface like you suggested.  I'm open to either approach.

 I prefer to have no eth0:1 in the interfaces too, but it can break
 comptability with legacy code. I'm currently switching to facter 3, so
 that's not a problem for me, other might disagree.


Facter 2.x parsed the output of ifconfig, which I suspect did not list
secondary interfaces in the output or, worse, Facter parsed the output such
that the addresses of an interface were actually overridden by subsequent
lines of output (historically, there were a few bugs around that).

Facter 3.x uses the getifaddrs function to enumerate the interfaces
directly from the kernel, so it isn't susceptible to that particular
problem, although as you've discovered it returns unique interfaces for
what should be logically considered secondary.

If you have access to Facter 2.x on this same system, I'd be curious to see
if it would output the secondary interface / address information.  If not,
I think we could consider Facter's 3.x behavior to be a bug and fix it by
moving the secondary interfaces to where they belong.



 --
 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/6F5D8E9E-DC38-402B-B254-85949A7DDC81%40orange.fr
 .
 For more options, visit https://groups.google.com/d/optout.




-- 
*Join us at **PuppetConf 2015, October 5-9 in Portland, OR - *www.
http://www.google.com/url?q=http%3A%2F%2Fwww.sa=Dsntz=1usg=AFQjCNEnS7itqgvQV3E4Se1fu4Um_UapSw
2015.puppetconf.com
http://www.google.com/url?q=http%3A%2F%2F2015.puppetconf.comsa=Dsntz=1usg=AFQjCNE1uQL4Sh23Vr-XkPLa4xfNcoXSog

*Register early to save 40%!*

-- 
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/CACZQQfNRAEZVMavOdiiFecj%2BiCgWhbJbCGUEkFbOCzHMP3_Nyw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] facter 3 and linux disagree about interfaces

[Peter Huene]

On Tue, Jul 21, 2015 at 11:06 AM, Fabrice Bacchella 
fabrice.bacche...@orange.fr wrote:

 I agree that Facter could do a better job merging the secondary
 interface into the primary one here.  It shares the networking fact code
 with a few other platforms (mainly OSX and the BSDs) and it currently
 doesn't do any specific logic for Linux to merge bonded interfaces together.


 I don't thinks that specific to bonded interfaces, a plain eth0 would work
 the same way.

 We could potentially address this in a backwards-compatible way by adding
 a secondary  field to a interface entry that is an array of the remaining
 secondary addresses.  Thus, the bond0:1 interface would be effectively
 moved to networking.interfaces.bond0.secondary.0.  Would that make sense
 to do?



 That's sound good. And perhaps add a primary: ...  to secondaries too.

 So the structured fact will look like :
 networking = {
   
   interfaces = {
 eth0 = {
 secondaries =  [ eth0:1 ]
 },
 eth0:1 = {
 primary = eth0
 },
   },
 }

 So it would be easy to filter interfaces in template or other places


I was thinking more along the lines of:

networking = {
  ...
  interfaces = {
eth0 = {
  ip = xyz.xyz.xyz.xyz,
  ...
  secondary = [
{
  ip = abc.abc.abc.abc,
  ...
},
...
  ]
}
...
  }
  ...
}

Thus there would be no eth0:1 in the interfaces list; it would just show
up as the first element in the secondary array.  e.g. eth0:1 becomes
eth0.secondary.0, eth0:2 becomes eth0.secondary.1, etc.

Thoughts on this approach? It would better model the output of command line
tools that don't distinguish interfaces between iface and iface:x.

Alternatively, we could keep eth0:1 in the list and have a reference to the
primary interface like you suggested.  I'm open to either approach.




  --
 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/DE6C8BA7-3685-42A0-BFAA-E4E82E35B557%40orange.fr
 https://groups.google.com/d/msgid/puppet-users/DE6C8BA7-3685-42A0-BFAA-E4E82E35B557%40orange.fr?utm_medium=emailutm_source=footer
 .

 For more options, visit https://groups.google.com/d/optout.




-- 
*Join us at **PuppetConf 2015, October 5-9 in Portland, OR - *www.
http://www.google.com/url?q=http%3A%2F%2Fwww.sa=Dsntz=1usg=AFQjCNEnS7itqgvQV3E4Se1fu4Um_UapSw
2015.puppetconf.com
http://www.google.com/url?q=http%3A%2F%2F2015.puppetconf.comsa=Dsntz=1usg=AFQjCNE1uQL4Sh23Vr-XkPLa4xfNcoXSog

*Register early to save 40%!*

-- 
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/CACZQQfNoQjPaFpCYbmd2hq0Ah69tCmwEhgF8AXLwbZP4k0YywA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] facter 3 and linux disagree about interfaces

[Peter Huene]

On Tue, Jul 21, 2015 at 12:26 PM, Fabrice Bacchella 
fabrice.bacche...@orange.fr wrote:



 If you have access to Facter 2.x on this same system, I'd be curious to
 see if it would output the secondary interface / address information.  If
 not, I think we could consider Facter's 3.x behavior to be a bug and fix it
 by moving the secondary interfaces to where they belong.


 On facter2, I get the secondary interface (on another server):
 ~# ip addr list
 link/ether XXX brd ff:ff:ff:ff:ff:ff
 inet  brd XXX scope global bond0
valid_lft forever preferred_lft forever
 inet XXX brd XXX scope global secondary bond0:git
valid_lft forever preferred_lft forever

 ~# facter interfaces
 bond0,bond0_git,eth0,eth1,lo


Shucks, I was hoping Facter 2.x wasn't reporting the secondary interface so
we could fix it such that it doesn't appear in the interfaces list and
maintain backwards compatibility.  It sounds like we may have to take your
earlier suggestion of tying secondary and primary interfaces together via
additional attributes.


 ~# facter -v
 2.4.4

  --
 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/A4D6EAFC-A729-419C-815A-AAC16C7056A0%40orange.fr
 https://groups.google.com/d/msgid/puppet-users/A4D6EAFC-A729-419C-815A-AAC16C7056A0%40orange.fr?utm_medium=emailutm_source=footer
 .

 For more options, visit https://groups.google.com/d/optout.




-- 
*Join us at **PuppetConf 2015, October 5-9 in Portland, OR - *www.
http://www.google.com/url?q=http%3A%2F%2Fwww.sa=Dsntz=1usg=AFQjCNEnS7itqgvQV3E4Se1fu4Um_UapSw
2015.puppetconf.com
http://www.google.com/url?q=http%3A%2F%2F2015.puppetconf.comsa=Dsntz=1usg=AFQjCNE1uQL4Sh23Vr-XkPLa4xfNcoXSog

*Register early to save 40%!*

-- 
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/CACZQQfOioU%3DXeWKct-41Hbdgnvys1hqMLXTQdJNJV2AiPfcR5Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: puppet facts and mcollective are incompatible

[Peter Huene]

On Monday, July 20, 2015 at 2:12:45 PM UTC-7, Fabrice Bacchella wrote:

 I used to fill mcollective yaml facts with a simple facter -p  foo.yaml. 

 But with facter 3, -p is gone, one should use 'puppet facts --render-as 
 yaml' instead. 


For this (and a few other reasons), the breaking change of removing the -p 
switch in Facter 3.0.0 is being reverted in 3.0.2, which will be released 
very soon.

Unfortunately I don't know of a good workaround that is possible with the 
puppet facts command given your intended usage.
 


 So far so good, but mcollective can't use this command output : 
 yaml_facts.rb:31:in `rescue in block in load_facts_from_source' Failed to 
 load yaml facts from /var/cache/mcollective/facts.yaml: TypeError: no 
 implicit conversion of Puppet::Node::Facts into Hash 

 Indeed, the output is: 
 --- !ruby/object:Puppet::Node::Facts 
 name: FQDN 
 values: 
 ... 
 fact values 
 ... 

 How can I filter the output and get only the values ? 



-- 
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/935fa546-6e1c-41bd-8c6f-5c5788267ae7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Puppet server failing on invalid UTF-8 facts

[Peter Huene]

On Monday, July 20, 2015 at 1:23:20 PM UTC-7, Peter Huene wrote:

 On Monday, July 20, 2015 at 1:16:07 PM UTC-7, Federico Agnelli wrote:

 Hi Giorgio,

 I have the same problem with a puppet client on Intel NUC5i5RYH.
 All other clients (on different hardware) with the same puppet version 
 work fine.

 My puppet version for both agent and server is 4.2.0. Version 4.1.0 was 
 ok.


 It looks like Facter is expecting the contents of those files to be UTF-8, 
 which may not be the correct thing to do.  Could you install/run the 
 dmiencode utility and paste the output?  Also, cat the same files Giorgio 
 did and attach as a file (the characters are coming through as invalid 
 characters in Google Groups).  Thanks!


Correction: the utility is *dmidecode*.
 

  


 Did you find a fix?

 Thanks,
 Federico



-- 
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/613ff7b5-1978-4851-9b7b-a2ed90a63b45%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Puppet server failing on invalid UTF-8 facts

[Peter Huene]

On Monday, July 20, 2015 at 1:16:07 PM UTC-7, Federico Agnelli wrote:

 Hi Giorgio,

 I have the same problem with a puppet client on Intel NUC5i5RYH.
 All other clients (on different hardware) with the same puppet version 
 work fine.

 My puppet version for both agent and server is 4.2.0. Version 4.1.0 was ok.


It looks like Facter is expecting the contents of those files to be UTF-8, 
which may not be the correct thing to do.  Could you install/run the 
dmiencode utility and paste the output?  Also, cat the same files Giorgio 
did and attach as a file (the characters are coming through as invalid 
characters in Google Groups).  Thanks!
 


 Did you find a fix?

 Thanks,
 Federico


-- 
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/a604ce95-3b59-45c1-9b39-de7d7f16ef73%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Dictating class evaluation order

[Peter Huene]

On Sun, Jul 19, 2015 at 7:07 AM, Andrew Langhorn 
andrew.langh...@digital.cabinet-office.gov.uk wrote:

 Hi Felix,

 Thanks for the reply.

 Yep - that snippet is representative. I've copied the full thing for you
 below. Granted, it needs some tidying up, but I think it should just work
 as it stands:

 class app::reservations {

 include tomcat


 Exec {
   path = /usr/bin:/usr/sbin:/bin:/sbin:/usr/local/bin:/usr/local/sbin,
 }


 tomcat::instance { 'reservations':
   ensure= present,
   http_port = 8080,
   require   = Class['tomcat'],
 }


 file { '/srv/tomcat/reservations/webapps/reservations.war':
   ensure = present,
   source = 'puppet:///modules/app/reservations.war',
   owner  = 'tomcat',
   group  = 'adm',
   mode   = '0755',
   notify = Exec['restart-reservations-tomcat'],
   }


 exec { 'restart-reservations-tomcat':
   command = '/etc/init.d/tomcat-reservations restart',
 }


 }


 Under normal circumstances, I agree that explicitly including the Tomcat
 class up above the instantiation of the tomcat::instance class should work
 fine. I don't know why it's not working quite as expected. Here's the
 output from Puppet with the --debug flag:

 == app: Debug: importing
 '/opt/puppet/modules/app/manifests/reservations.pp' in environment
 development
 == app: Debug: Automatically imported app:reservations from
 app/reservations in to development
 == app: Debug: importing '/opt/puppet/modules/app/manifests/tomcat.pp' in
 environment development


It looks like the loader found app/manifests/tomcat.pp instead of
tomcat/manifests/init.pp.  Perhaps qualify the include as `include
::tomcat`?  Not sure if that would work with Puppet 3.6 though.


 == app: Debug: Automatically imported app::tomcat from app/tomcat into
 development

== app: Debug: importing
 '/opt/puppet/vendor/modules/tomcat/manifests/instance.pp' in environment
 development
 == app: Debug: Automatically imported tomcat::instance from
 tomcat/instance into development
 == app: Warning: Scope(Tomcat::Instance[reservations]): Could not look up
 qualified variable 'tomcat::instance_basedir'; class tomcat has not been
 evaluated
 == app: Warning: Scope(Tomcat::Instance[reservations]): Could not look up
 qualified variable 'tomcat::version'; class tomcat has not been evaluated

 Values for both tomcat::version and tomcat::instance_basedir are retrieved
 from a case statement which, ultimately, resides at
 https://github.com/camptocamp/puppet-tomcat/blob/master/manifests/params.pp,
 which either works out a value or just passes in a value, respectively.

 So, it looks like the Tomcat module is - at least partially - being
 imported.

 I'm a bit stumped now!

 Andrew

 On Sunday, 19 July 2015 01:06:26 UTC+1, Felix.Frank wrote:

  On 07/19/2015 01:19 AM, Andrew Langhorn wrote:

  class apps::reservations {


include tomcat


tomcat::instance { ‘reservations’:

ensure = present,

   http_port = 8080,

}


   }


  However, when I run Puppet against a Vagrant VM, it tells me that the
 tomcat class hasn’t been evaluated, so it can’t use tomcat::instance
 (because of underlying failures when using the Tomcat module):


   == app: Warning: Scope(Tomcat::Instance[reservations]): Could not
 look up qualified variable 'tomcat::instance_basedir'; class tomcat has not
 been evaluated


 Hmm, if the resource declaration is lexically preceded by an 'include
 tomcat' then this should not happen.

 In this case, the order in your manifest is really important. Is your
 snippet truly representative of your actual code?

 Regards,
 Felix

  --
 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/2d506a73-c86a-4ddd-bfd4-09579565bd04%40googlegroups.com
 https://groups.google.com/d/msgid/puppet-users/2d506a73-c86a-4ddd-bfd4-09579565bd04%40googlegroups.com?utm_medium=emailutm_source=footer
 .

 For more options, visit https://groups.google.com/d/optout.




-- 
*Join us at **PuppetConf 2015, October 5-9 in Portland, OR - *www.
http://www.google.com/url?q=http%3A%2F%2Fwww.sa=Dsntz=1usg=AFQjCNEnS7itqgvQV3E4Se1fu4Um_UapSw
2015.puppetconf.com
http://www.google.com/url?q=http%3A%2F%2F2015.puppetconf.comsa=Dsntz=1usg=AFQjCNE1uQL4Sh23Vr-XkPLa4xfNcoXSog

*Register early to save 40%!*

-- 
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/CACZQQfO4BWWK3_aZ2xBWSRaKGnGp00uaA66DVFxkL-7jdOadbA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Centos 7 facter 2 issue

[Peter Huene]

On Wed, Jul 15, 2015 at 4:51 PM, Phil Manuel flar...@gmail.com wrote:

 Hi,

 If I do a clean install of CentOS 7 with facter and puppet, my puppet
 fails with

 puppet agent -t
 Info: Retrieving pluginfacts
 Info: Retrieving plugin
 Error: Could not retrieve local facts: undefined method `hostname' for
 Facter:Module
 Error: Failed to apply catalog: Could not retrieve local facts: undefined
 method `hostname' for Facter:Module


It sounds like you're using a module with a custom fact that, on CentOS 7
at least, uses a syntax that was removed in Facter 2.x and later.

Facter 2.x (and Facter 3.x) do not support querying facts via the method
syntax on the Facter module itself.

e.g. `Facter.hostname` is not supported in 2.x+; instead, use
`Facter.value(:hostname)`.

Specify `--trace` to puppet and see if you can determine the offending
module in the trace back.



 rpm -qa puppet
 puppet-3.8.1-1.el7.noarch
 rpm -qa facter
 facter-2.4.4-1.el7.x86_64

 If i run facter hostname it works fine.  If I run puppet facts find
 hostname
 Error: Could not call 'find' on 'facts': undefined method `hostname' for
 Facter:Module
 Error: Could not call 'find' on 'facts': undefined method `hostname' for
 Facter:Module
 Error: Try 'puppet help facts find' for usage


 If I downgrade facter to 1.7.x then it works fine.


 If I  perform the same process on Fedora 22 which has

 rpm -qa facter
 facter-2.4.1-1.fc22.x86_64
 rpm -qa puppet
 puppet-4.1.0-1.fc22.noarch


 It works fine.

 Has anyone got any suggestions ?

 Thanks

 Phil.

 --
 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/86d2bf02-7152-4a9a-bd25-9645fbaab7d2%40googlegroups.com
 https://groups.google.com/d/msgid/puppet-users/86d2bf02-7152-4a9a-bd25-9645fbaab7d2%40googlegroups.com?utm_medium=emailutm_source=footer
 .
 For more options, visit https://groups.google.com/d/optout.




-- 
*Join us at **PuppetConf 2015, October 5-9 in Portland, OR - *www.
http://www.google.com/url?q=http%3A%2F%2Fwww.sa=Dsntz=1usg=AFQjCNEnS7itqgvQV3E4Se1fu4Um_UapSw
2015.puppetconf.com
http://www.google.com/url?q=http%3A%2F%2F2015.puppetconf.comsa=Dsntz=1usg=AFQjCNE1uQL4Sh23Vr-XkPLa4xfNcoXSog

*Register early to save 40%!*

-- 
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/CACZQQfPUKM8gFS%2B_ikBwSy6ccWhNMz9jSh%2BM_a5-G7GWiOkx6g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet 4.2. and latest Puppet Agent 1.2.1-x64 on Windows 2008 r2 keeps crashing with error 400: Invalid byte sequence in UTF-8

[Peter Huene]

On Wed, Jul 15, 2015 at 9:08 AM, Peter Huene peter.hu...@puppetlabs.com
wrote:

 On Wed, Jul 15, 2015 at 9:04 AM, Josh Cooper j...@puppetlabs.com wrote:



 On Tue, Jul 14, 2015 at 2:13 PM, mst3k gro...@gt-it.de wrote:

 Hi,

 thx for the answer - and sorry for the weird postings. I may need to
 create a google-account after all to submit decent requests.. But I got the
 logs:

 puppet.log - http://pastebin.com/aA6dqK24
 facter.log - http://pastebin.com/f3i8Q6Y9


 I believe the timezone fact is giving us trouble:

   timezone = Mitteleurop‰ische Sommerzeit

 There have been various tickets filed[1], and I thought it had finally
 been resolved, but perhaps not or this is a regression in native facter?


 This appears to be a regression in Facter 3.0.1.  I've opened a ticket to
 track this: https://tickets.puppetlabs.com/browse/FACT-1126


Closing the loop.  We've fixed this for Facter 3.0.2 and the fix will be in
the next release of Puppet agent.  Thanks very much for reporting this
issue to us.







 I hope that helps.

 Thank you for your time!


 Am 14.07.2015 um 17:52 schrieb Rob Reynolds r...@puppetlabs.com:

  Would you mind including some logs from the agent as well?
 
  I'm looking for
  * facter --trace --debug facter.log 21
  * puppet agent --test --debug --verbose --trace puppet.log 21
 
  Thanks!
 
 
 
  On Mon, Jul 13, 2015 at 10:12 AM, mst3k gro...@gt-it.de wrote:
  Hi,
 
  I’m trying to set up a new heterogeneous environment with a Puppet
 4.2. server running on a 14.04.2 Ubuntu LTS and some *nix and windows
 clients. Without any changes to the server (except enabling autosigning for
 my domain and setting the alt_dns_names for the master) I’m trying to
 connect from another Ubuntu and a Windows 2008 r2 client, but where the
 ubuntu client will connect without a problem, windows keeps getting an
 Error:
 
  Error 400 on Server: Invalid byte sequence in UTF-8
 
  I searched the web for a hint and saw, that in an earlier version this
 could be fixed with a locale-setting in the file „config.ru“, which I
 don’t seem to have on a 4.2. installation.
  I also tried to set the apache charset to utf-8 with the
 charset-config file with no success.
 
  Can anybody point me to the right direction?
 
  Thank you in advance.
 
  The error-log on the server:
 
  2015-07-13 09:48:00,273 INFO  [puppet-server] Puppet Caching node for
 mynode.mydomain
  2015-07-13 09:48:00,736 ERROR [puppet-server] Puppet invalid byte
 sequence in UTF-8
  org/jruby/RubyString.java:6202:in `count'
 
 /opt/puppetlabs/server/apps/puppetserver/puppet-server-release.jar!/META-INF/jruby.home/lib/ruby/shared/psych/visitors/yaml_tree.rb:248:in
 `binary?'
 
 /opt/puppetlabs/server/apps/puppetserver/puppet-server-release.jar!/META-INF/jruby.home/lib/ruby/shared/psych/visitors/yaml_tree.rb:262:in
 `visit_String'
 
 /opt/puppetlabs/server/apps/puppetserver/puppet-server-release.jar!/META-INF/jruby.home/lib/ruby/shared/psych/visitors/yaml_tree.rb:128:in
 `accept'
 
 /opt/puppetlabs/server/apps/puppetserver/puppet-server-release.jar!/META-INF/jruby.home/lib/ruby/shared/psych/visitors/yaml_tree.rb:324:in
 `visit_Hash'
  org/jruby/RubyHash.java:1341:in `each'
 
 /opt/puppetlabs/server/apps/puppetserver/puppet-server-release.jar!/META-INF/jruby.home/lib/ruby/shared/psych/visitors/yaml_tree.rb:322:in
 `visit_Hash'
 
 /opt/puppetlabs/server/apps/puppetserver/puppet-server-release.jar!/META-INF/jruby.home/lib/ruby/shared/psych/visitors/yaml_tree.rb:128:in
 `accept'
 
 /opt/puppetlabs/server/apps/puppetserver/puppet-server-release.jar!/META-INF/jruby.home/lib/ruby/shared/psych/visitors/yaml_tree.rb:467:in
 `emit_coder'
  org/jruby/RubyHash.java:1341:in `each'
 
 /opt/puppetlabs/server/apps/puppetserver/puppet-server-release.jar!/META-INF/jruby.home/lib/ruby/shared/psych/visitors/yaml_tree.rb:465:in
 `emit_coder'
 
 /opt/puppetlabs/server/apps/puppetserver/puppet-server-release.jar!/META-INF/jruby.home/lib/ruby/shared/psych/visitors/yaml_tree.rb:450:in
 `dump_coder'
 
 /opt/puppetlabs/server/apps/puppetserver/puppet-server-release.jar!/META-INF/jruby.home/lib/ruby/shared/psych/visitors/yaml_tree.rb:126:in
 `accept'
 
 /opt/puppetlabs/server/apps/puppetserver/puppet-server-release.jar!/META-INF/jruby.home/lib/ruby/shared/psych/visitors/yaml_tree.rb:92:in
 `push'
 
 /opt/puppetlabs/server/apps/puppetserver/puppet-server-release.jar!/META-INF/jruby.home/lib/ruby/shared/psych.rb:244:in
 `dump'
  /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/yaml.rb:21:in
 `dump'
  /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util.rb:380:in
 `replace_file'
  /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/yaml.rb:20:in
 `dump'
 
 /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/indirector/yaml.rb:30:in
 `save'
 
 /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/indirector/indirection.rb:276:in
 `save'
  /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/node/facts.rb:21:in
 `save'
 
 /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet

Re: [Puppet Users] Puppet 4.2. and latest Puppet Agent 1.2.1-x64 on Windows 2008 r2 keeps crashing with error 400: Invalid byte sequence in UTF-8

[Peter Huene]

On Wed, Jul 15, 2015 at 9:04 AM, Josh Cooper j...@puppetlabs.com wrote:



 On Tue, Jul 14, 2015 at 2:13 PM, mst3k gro...@gt-it.de wrote:

 Hi,

 thx for the answer - and sorry for the weird postings. I may need to
 create a google-account after all to submit decent requests.. But I got the
 logs:

 puppet.log - http://pastebin.com/aA6dqK24
 facter.log - http://pastebin.com/f3i8Q6Y9


 I believe the timezone fact is giving us trouble:

   timezone = Mitteleurop‰ische Sommerzeit

 There have been various tickets filed[1], and I thought it had finally
 been resolved, but perhaps not or this is a regression in native facter?


This appears to be a regression in Facter 3.0.1.  I've opened a ticket to
track this: https://tickets.puppetlabs.com/browse/FACT-1126





 I hope that helps.

 Thank you for your time!


 Am 14.07.2015 um 17:52 schrieb Rob Reynolds r...@puppetlabs.com:

  Would you mind including some logs from the agent as well?
 
  I'm looking for
  * facter --trace --debug facter.log 21
  * puppet agent --test --debug --verbose --trace puppet.log 21
 
  Thanks!
 
 
 
  On Mon, Jul 13, 2015 at 10:12 AM, mst3k gro...@gt-it.de wrote:
  Hi,
 
  I’m trying to set up a new heterogeneous environment with a Puppet 4.2.
 server running on a 14.04.2 Ubuntu LTS and some *nix and windows clients.
 Without any changes to the server (except enabling autosigning for my
 domain and setting the alt_dns_names for the master) I’m trying to connect
 from another Ubuntu and a Windows 2008 r2 client, but where the ubuntu
 client will connect without a problem, windows keeps getting an Error:
 
  Error 400 on Server: Invalid byte sequence in UTF-8
 
  I searched the web for a hint and saw, that in an earlier version this
 could be fixed with a locale-setting in the file „config.ru“, which I
 don’t seem to have on a 4.2. installation.
  I also tried to set the apache charset to utf-8 with the charset-config
 file with no success.
 
  Can anybody point me to the right direction?
 
  Thank you in advance.
 
  The error-log on the server:
 
  2015-07-13 09:48:00,273 INFO  [puppet-server] Puppet Caching node for
 mynode.mydomain
  2015-07-13 09:48:00,736 ERROR [puppet-server] Puppet invalid byte
 sequence in UTF-8
  org/jruby/RubyString.java:6202:in `count'
 
 /opt/puppetlabs/server/apps/puppetserver/puppet-server-release.jar!/META-INF/jruby.home/lib/ruby/shared/psych/visitors/yaml_tree.rb:248:in
 `binary?'
 
 /opt/puppetlabs/server/apps/puppetserver/puppet-server-release.jar!/META-INF/jruby.home/lib/ruby/shared/psych/visitors/yaml_tree.rb:262:in
 `visit_String'
 
 /opt/puppetlabs/server/apps/puppetserver/puppet-server-release.jar!/META-INF/jruby.home/lib/ruby/shared/psych/visitors/yaml_tree.rb:128:in
 `accept'
 
 /opt/puppetlabs/server/apps/puppetserver/puppet-server-release.jar!/META-INF/jruby.home/lib/ruby/shared/psych/visitors/yaml_tree.rb:324:in
 `visit_Hash'
  org/jruby/RubyHash.java:1341:in `each'
 
 /opt/puppetlabs/server/apps/puppetserver/puppet-server-release.jar!/META-INF/jruby.home/lib/ruby/shared/psych/visitors/yaml_tree.rb:322:in
 `visit_Hash'
 
 /opt/puppetlabs/server/apps/puppetserver/puppet-server-release.jar!/META-INF/jruby.home/lib/ruby/shared/psych/visitors/yaml_tree.rb:128:in
 `accept'
 
 /opt/puppetlabs/server/apps/puppetserver/puppet-server-release.jar!/META-INF/jruby.home/lib/ruby/shared/psych/visitors/yaml_tree.rb:467:in
 `emit_coder'
  org/jruby/RubyHash.java:1341:in `each'
 
 /opt/puppetlabs/server/apps/puppetserver/puppet-server-release.jar!/META-INF/jruby.home/lib/ruby/shared/psych/visitors/yaml_tree.rb:465:in
 `emit_coder'
 
 /opt/puppetlabs/server/apps/puppetserver/puppet-server-release.jar!/META-INF/jruby.home/lib/ruby/shared/psych/visitors/yaml_tree.rb:450:in
 `dump_coder'
 
 /opt/puppetlabs/server/apps/puppetserver/puppet-server-release.jar!/META-INF/jruby.home/lib/ruby/shared/psych/visitors/yaml_tree.rb:126:in
 `accept'
 
 /opt/puppetlabs/server/apps/puppetserver/puppet-server-release.jar!/META-INF/jruby.home/lib/ruby/shared/psych/visitors/yaml_tree.rb:92:in
 `push'
 
 /opt/puppetlabs/server/apps/puppetserver/puppet-server-release.jar!/META-INF/jruby.home/lib/ruby/shared/psych.rb:244:in
 `dump'
  /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/yaml.rb:21:in
 `dump'
  /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util.rb:380:in
 `replace_file'
  /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/yaml.rb:20:in
 `dump'
 
 /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/indirector/yaml.rb:30:in
 `save'
 
 /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/indirector/indirection.rb:276:in
 `save'
  /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/node/facts.rb:21:in
 `save'
 
 /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/indirector/catalog/compiler.rb:39:in
 `extract_facts_from_request'
 
 /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/profiler/around_profiler.rb:58:in
 `profile'
 
 /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/profiler.rb:51:in
 

Re: [Puppet Users] Facter 3.0 breaks custom facts and dropped a needed core fact

[Peter Huene]

Hi Ken!

On Thu, Jun 25, 2015 at 11:53 AM, Ken Bowley kbow...@gmail.com wrote:

 While testing puppet 4 to see if it was ready for production (still not),
 I now get to deal with the new Facter 3.0.

 Hopefully ruby based facter won't be totally abandoned, since the C++
 based version is going to be an annoyance on non-PL supported systems.

 The first thing I noticed is that a couple of our custom facts no longer
 work because they used facter utils (Facter::Util::IP,
 Facter::Util::Resolution).


Could you elaborate on what you need from Facter::Util::IP and
Facter::Util::Resolution? We did implement Facter::Util::Resolution::exec
and Facter::Util::Resolution::which (despite both being marked deprecated
in 2.x) as they were commonly used.  While we tried to maximize the support
for any method marked @api public, we obviously can't expose everything
that existed in Facter 2.x via C++.  Facter 3 doesn't use the Ruby API
internally at all; it only exists to support custom facts, so types like
Facter::Util::IP didn't make much sense to me reimplement in C++ at the
time.  It sounds like my understanding of that was wrong, though, so let's
see what we can do to enable your custom facts.



 Upon finally looking at the release info, I see that xendomains was not
 ported into Facter 3.0, and this fact is used all the time in our
 environment!  I will most likely end out reinventing the deprecated wheel
 of xendomains, but this just adds to the frustration that is the Puppet 4
 CF.


The xendomains fact will be reimplemented in a Facter 3 release.  It looks
like we have an existing ticket (FACT-867) for this that flew under the
radar because it was not associated with the 3.0.0 release.  I'll update
the ticket so that we properly track this.

  --
 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/ad894c61-9d36-428e-a26a-7afb6ec065fe%40googlegroups.com
 https://groups.google.com/d/msgid/puppet-users/ad894c61-9d36-428e-a26a-7afb6ec065fe%40googlegroups.com?utm_medium=emailutm_source=footer
 .
 For more options, visit https://groups.google.com/d/optout.




-- 
*Join us at **PuppetConf 2015, October 5-9 in Portland, OR - *www.
http://www.google.com/url?q=http%3A%2F%2Fwww.sa=Dsntz=1usg=AFQjCNEnS7itqgvQV3E4Se1fu4Um_UapSw
2015.puppetconf.com
http://www.google.com/url?q=http%3A%2F%2F2015.puppetconf.comsa=Dsntz=1usg=AFQjCNE1uQL4Sh23Vr-XkPLa4xfNcoXSog

*Register early to save 40%!*

-- 
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/CACZQQfOzZT5gDEXp5a9imDGa8i-mQSu50r8EoKBLvHK1wTGMbw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] passing custom fact into a variable

[Peter Huene]

Hi Toky,

On Fri, Jun 19, 2015 at 12:16 PM, Toky toky.c...@gmail.com wrote:

 I have a custom fact (creationkey) which gives me the AWS Creation key
 name (this is also a local linux user account). I'm trying to use that fact
 with the rvm module.

 https://forge.puppetlabs.com/maestrodev/rvm/readme

 rvm::system_user { bturner: ; jdoe: ; jsmith: ; }

 I've tried the following:
 rvm::system_user { ::creationkey: ; }

 rvm::system_user { ::$creationkey: ; }

 rvm::system_user { ::${creationkey}: ; }


I think you're looking for $::creationkey, e.g. rvm::system_user {
$::creationkey: }


 They all give this error:
 Error: Could not create user $creationkey: Execution of '/usr/sbin/useradd
 -M $creationkey' returned 3: useradd: invalid user name '$creationkey'

 I tried:

 $user = ::creationkey

 rvm::system_user { $user: ; }

 But that is not working either.

 PS the creationkey fact does work as expected on the instances, its just
 using it to populate the variable what is failing.

 Cheers,

 --
 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/b21e2e16-c077-4c87-897c-3d550e9fcf85%40googlegroups.com
 https://groups.google.com/d/msgid/puppet-users/b21e2e16-c077-4c87-897c-3d550e9fcf85%40googlegroups.com?utm_medium=emailutm_source=footer
 .
 For more options, visit https://groups.google.com/d/optout.




-- 
*Join us at **PuppetConf 2015, October 5-9 in Portland, OR - *www.
http://www.google.com/url?q=http%3A%2F%2Fwww.sa=Dsntz=1usg=AFQjCNEnS7itqgvQV3E4Se1fu4Um_UapSw
2015.puppetconf.com
http://www.google.com/url?q=http%3A%2F%2F2015.puppetconf.comsa=Dsntz=1usg=AFQjCNE1uQL4Sh23Vr-XkPLa4xfNcoXSog

*Register early to save 40%!*

-- 
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/CACZQQfMBdN1oOBwxxYPp4_jTgWmgxpvYLRdzjhUdUQcFovL21Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] custom fact in custom facts resolves to nil

[Peter Huene]

Hi Andreas,

On Tue, May 26, 2015 at 11:16 PM, ashee...@gmail.com wrote:

 Hi,

 is it possible to use custom facts inside other custom facts?

 With facter -p the custom fact is listed ( e.g.):

 ...
 userblweb = 1000

 With irb:

 irb(main):001:0 require 'facter'
 = true
 irb(main):002:0 a = Facter.value(:userblweb)
 = nil

 Any idea?


When using the Facter API, Facter needs to be told where the custom facts
are stored:

irb Facter.search 'path_to_custom_facts'

Note: despite being a verb, the 'search' method only adds the given path to
the list of search paths.

The same thing happens during Puppet's settings initialization that is
invoked when you pass the '-p' option to Facter (as Thomas mentioned, this
is deprecated).

Likewise, the path can be specified to Facter by using the FACTERLIB
environment variable set to a list of paths to search for custom facts.

Facter 3 will be adding a '--custom-dir' command line option that is
another way of specifying where custom facts are stored.

I hope this helps.


-- 
*Join us at **PuppetConf 2015, October 5-9 in Portland, OR - *www.
http://www.google.com/url?q=http%3A%2F%2Fwww.sa=Dsntz=1usg=AFQjCNEnS7itqgvQV3E4Se1fu4Um_UapSw
2015.puppetconf.com
http://www.google.com/url?q=http%3A%2F%2F2015.puppetconf.comsa=Dsntz=1usg=AFQjCNE1uQL4Sh23Vr-XkPLa4xfNcoXSog

*Register early to save 40%!*

-- 
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/CACZQQfOMw7igPKm_ZWKcFWzrv6%3DGguWJbs%2B2aAeaaJdX2QQxMw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Announce: Facter 2.4.1 available

[Peter Huene]

Facter 2.4.1 is a bug fix release in the Facter 2 series.

Included in this release are fixes for the following bugs:

   - The ec2_metadata fact was not filtering out sensitive IAM security
   credentials.
   - The virtual fact's detection of KVM hypervisors when running as
   non-root on Linux was misreporting as physical.

To download Facter, follow the instructions here:
http://docs.puppetlabs.com/guides/install_puppet/pre_install.html


Release notes are available here: http://docs.puppetlabs.
com/facter/latest/release_notes.html


To see a complete list of issues fixed in this release:
*https://tickets.puppetlabs.com/issues/?filter=13550
https://tickets.puppetlabs.com/issues/?filter=13550 *

We're tracking bugs people find in this release with the Affected Version
field set to 2.4.1:
*https://tickets.puppetlabs.com/issues/?filter=13551
https://tickets.puppetlabs.com/issues/?filter=13551 *

-- 
*Join us at **PuppetConf 2015, October 5-9 in Portland, OR - *www.
http://www.google.com/url?q=http%3A%2F%2Fwww.sa=Dsntz=1usg=AFQjCNEnS7itqgvQV3E4Se1fu4Um_UapSw
2015.puppetconf.com
http://www.google.com/url?q=http%3A%2F%2F2015.puppetconf.comsa=Dsntz=1usg=AFQjCNE1uQL4Sh23Vr-XkPLa4xfNcoXSog

*Register early to save 40%!*

-- 
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/CACZQQfNY12-grOGtQjzEZGzhbAch7WAd5o85XLeHOmowO4QodA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Announce: Native Facter (cfacter) 0.3.0 is available!

[Peter Huene]

Native Facter (cfacter) 0.3.0 is a features-and-fixes release in the Native
Facter pre-1.0 series.

Included in this release is support for building Native Facter on Windows
and Solaris.  The EC2 and GCE facts were also implemented in this release.

Notable updates:

   - Windows is now a supported platform:
   - Please see https://github.com/puppetlabs/cfacter/blob/master/WINDOWS.md
   for build instructions.
  - Solaris is now a supported platform:
   - Please see https://github.com/puppetlabs/cfacter-build
   for build instructions.
   - Added a Fedora 20 package.
   - Implemented overriding facts from FACTER_* environment variables.
   - Added a new networking structured fact to organize networking data.
   - Implemented the EC2 and GCE facts.
   - Various bug fixes including a fix for a hang when exec'ing a shell
   script missing a hashbang and supporting custom facts on platforms with
   libraries in a lib64 directory.

Packages for the following platforms have been distributed on the Puppet
Labs Package Repositories:

   - Debian/Ubuntu: Lucid, Precise, Squeeze, Trusty, and Wheezy.
   - RHEL 5, 6, and 7.
   - Fedora 20

Please see
https://docs.puppetlabs.com/guides/puppetlabs_package_repositories.html
 for information about installing from the package repositories.

-- 
*Join us at **PuppetConf 2015, October 5-9 in Portland, OR - *www.
http://www.google.com/url?q=http%3A%2F%2Fwww.sa=Dsntz=1usg=AFQjCNEnS7itqgvQV3E4Se1fu4Um_UapSw
2015.puppetconf.com
http://www.google.com/url?q=http%3A%2F%2F2015.puppetconf.comsa=Dsntz=1usg=AFQjCNE1uQL4Sh23Vr-XkPLa4xfNcoXSog

*Register early to save 40%!*

-- 
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/CACZQQfObGc%2BOXKe5rz7RjTLEAACsK2bAK13mofF7rrhuYZ7Z5A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.