[Puppet Users] Puppet Agent 3.7 Install Issues

[Ghh]

Hi All,

I have installed  the master on CentOS 6.5 and while installing Agent , 
that which the node is not connected  to the internet 

Per Documentation, I downloaded the Puppet Agent Tar file  and copied to 
the master server in /opt/staging/pe_repo


Now when I run curl -k 
https://mypuppet.mydomain.com:8140/packages/current/install.bash| sudo bash

The script gets executed , and it tried to fetch the mirror sites from the 
Net and eventually fails.

What is that I am missing to get this work

Thx
G

-- 
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/4718c33d-0f9c-4983-860b-b66bfecf406a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Cant remove depreciated warning message

[Johan De Wit]

You could start checking your manifest dir for your environment :

puppet master --configprint manifest

mine says :

/data/puppet/environments/production/manifests

There you should have your site.pp for that environment.

hth

Johan

On 09/02/15 05:56, David LeVene wrote:

Hey All,

I've started to upgrade a few puppet clients to the latest version and 
have hit the issue which everyone had a while ago around this error


"Warning: The package type's allow_virtual parameter will be changing 
its default value from false to true in a future release. If you do 
not want to allow virtual packages, please explicitly set 
allow_virtual to false.
   (at /usr/lib/ruby/site_ruby/1.8/puppet/type/package.rb:430:in 
`default')"


I've implemented the fix in manfests/sites.pp in my test environment 
but the error message isn't going away!


Puppet masters are 3.7.4, but are setup under RVM so i can run > ruby 
1.8.7 due to an ordering issue.


Why is puppet not picking up the config is it a bug or am I missing 
something obvious?


The below is what i'm using in my site.pp and yes, i do see the notify 
message.


if versioncmp($::puppetversion,'3.6.1') >= 0 {
  notify {'I Am here':}


  $allow_virtual_packages = hiera('allow_virtual_packages',false)


  Package {
allow_virtual => $allow_virtual_packages,
  }
}


# puppet agent -t --environment=dlscratch --server=int-puppet-dev
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Warning: The package type's allow_virtual parameter will be changing 
its default value from false to true in a future release. If you do 
not want to allow virtual packages, please explicitly set 
allow_virtual to false.
   (at /usr/lib/ruby/site_ruby/1.8/puppet/type/package.rb:430:in 
`default')

Info: Caching catalog for xxx
Info: Applying configuration version '1423457136'
Notice: I Am here
Notice: /Stage[main]/Base/Notify[I Am here]/message: defined 'message' 
as 'I Am here'

Notice: Finished catalog run in 6.62 seconds

Any suggestions as to where to look next?

I am aware that I can add this into the puppet.conf to disable all 
warnings, but i'd prefer to keep the config inside the manifests and 
only disable this one warning.


Cheers
David

--
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/a5380933-a138-4f76-9f23-8b16df92f117%40googlegroups.com 
.

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



--
Johan De Wit

Open Source Consultant

Red Hat Certified Engineer  (805008667232363)
Puppet Certified Professional 2013/2014 (PCP006)
blog : http://johan.koewacht.net/
_
 
Open-Future Phone +32 (0)2/255 70 70

Zavelstraat 72  Fax   +32 (0)2/255 70 71
3071 KORTENBERG Mobile+32 (0)474/42 40 73
BELGIUM http://www.open-future.be
_
 



Next Events:
Bacula Administrator 1 | 
http://www.open-future.be/bacula-administrator-i-training-13th-till-15th-january
Puppet Fundamentals | 
http://www.open-future.be/puppet-fundamentals-training-26th-till-28th-january
Puppet Architect | 
http://www.open-future.be/puppet-architect-training-29th-till-30th-january
Linux Training | http://www.open-future.be/linux-training-9th-till-13th-february
Puppet Practitioner | 
http://www.open-future.be/puppet-practitioner-training-17th-till-19th-february
Bacula Administrator 1 | 
http://www.open-future.be/bacula-administrator-i-training-24th-till-26th-february
Subscribe to our newsletter | http://eepurl.com/BUG8H

--
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/54D88453.6080306%40open-future.be.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Requiring a subclass?

[Thomas Müller]

Am Freitag, 6. Februar 2015 22:45:30 UTC+1 schrieb guymatz:
>
> Hello!  Is there a way to set the dependency for a resource that is a 
> subclass?  I have an accounts module, and "within" that is 
> accounts::account which contains declarations to create user, group, etc. . 
> . .  I would like to do something like:
>
> file {'sdfdsf':
>  contents => 'sdkfjdsf',
>  owner=> 'username',
>  *requires Accounts::account['username'] * 
> }
>

to depend on a class: 
require => Class['Accounts::Account'],

(and require without s)

to depend on a specific resource in a class is always depending on the 
resource:
require => User['xyz'],

or group:
require => Group['xyz']

- Thomas

https://docs.puppetlabs.com/puppet/latest/reference/lang_relationships.html

-- 
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/11c008d6-ed95-4808-8936-3d4af6749ba5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Any pointers to RHEL7 CIS hardening usig puppet

[Ash26]

arildjensen-cis seems not to have worked for RHEL7

-- 
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/3e1d942c-74e1-44f0-9a6a-f4cbfd3eb2ba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Requiring a subclass?

[jcbollinger]

On Friday, February 6, 2015 at 3:45:30 PM UTC-6, guymatz wrote:
>
> Hello!  Is there a way to set the dependency for a resource that is a 
> subclass?  I have an accounts module, and "within" that is 
> accounts::account which contains declarations to create user, group, etc. . 
> . .  I would like to do something like:
>
> file {'sdfdsf':
>  contents => 'sdkfjdsf',
>  owner=> 'username',
>  *requires Accounts::account['username'] * 
> }
>
> But that doesn't work.  (Error 400 on SERVER: Syntax error at '::account'; 
> expected ']')
>


It doesn't make sense.

   1. If accounts::account is a (sub)*class* then its name is 
   "accounts::account", and no 'username' has anything to do with it.  In that 
   case, a reference to it would be spelled Class['accounts::account'], as 
   Thomas said.
   2. Whether it is a subclass (of another class) or not has nothing to do 
   with it, but anyway, nothing in what you presented is related to whether or 
   not it actually is a subclass.
   3. Except, if the 'username' part is in fact relevant in any way, it can 
   only be because accounts::account is a defined type, not a class at all 
   (sub- or otherwise).  If it is a defined type, then a reference to an 
   instance of it would be spelled "Accounts::Account['username']" (every 
   name segment capitalized).
   
 

>
> I also thought I should be able to say:
>
> file {'sdfdsf':
>  contents => 'sdkfjdsf',
>  owner=> 'username',
>  *requires User['username'] *
> }
>
> since it's really the user resource that's at the heart of the matter, but 
> that didn't work either!  Puppet still complains that it "Could not find 
> dependency User[username]"
>


If Puppet even gets to the point of determining whether it can find the 
dependency, then what you in fact tried was different from what you wrote 
above, as the declaration above misspells the 'require' metaparameter and 
omits the association arrow (=>) between that parameter name and its 
value.  We can help you better when you post the code that you are actually 
using, so cut&paste is your friend.

Anyway, if you use a syntactically correct variation on the above, and 
Puppet complains that it could not find the dependency, then the problem is 
that you did not declare the dependency.  The 'require' metaparameter does 
not (indeed cannot) do that for you.  Puppet doesn't need to have *already* 
processed the declaration of User['username'] (or 
Account::Accounts['username']) when it processes the File declaration, but 
it needs to see such a declaration somewhere among the resources declared 
for the target node before it finishes building the catalog.


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/73a1d4ec-6ad0-481a-b6ab-2381c3308a18%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Accessing Specific Chunk of Aggregate Fact

[jcbollinger]

On Friday, February 6, 2015 at 2:13:21 PM UTC-6, Steve Harp wrote:
>
> Hi Guys,
>
> I have a json configuration file on each Puppet Agent that I need to parse 
> and return the values as custom facts.  Each json file will contain an 
> array of from 0 to n elements each of which will have needed configuration 
> settings.  I think what I need to write is an aggregate fact where the 
> specific elements in the array will be represented as chunks.
>


The Puppet term for what you appear to want is a "structured fact".  The 
Facter documentation contains a section on writing structured facts 

.

 

> I don't think writing the fact would be too difficult
>


Probably not, supposing you have a JSON parser in your local Ruby lib.  
Such a parser probably produces an appropriate fact value in about one line.

 

> but I don't know how to reference the facts from within a manifest on the 
> Puppet Master.  I would like to be able to access these settings using a 
> custom fact from within a manifest.  Something like:
>
> value=Sites[2]["LIVE_DIR"] 
>
> and have the variable, value, set to '/srv/www/test-.net'.
>
> If you have an aggregate fact, how to you use it in a manifest?
>


Referencing facts is no different from referencing any other Puppet 
variable.  If the name of the fact were "sites" (should be lowercase) and 
its value were structured as an array of hashes, then you would use

$value = $sites[2]["LIVE_DIR"]

(The Puppet documentation describes the syntax for referencing array and 
hash elements 
.


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/4b3a722f-7cc3-441a-96bb-dc3e83a54f20%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Fact is incorrect when show all facts, correct when on commandline

[jcbollinger]

On Sunday, February 8, 2015 at 3:47:58 PM UTC-6, John D'Ausilio wrote:
>
> So I have a custom fact which works fine from the commandline: facter 
> last_interface  (it returns the ip address of the last of a sorted list of 
> interface names)
>
> If I just run facter without parameters, the value in last_interface is 
> incorrect!
>
> Is there something different between the environment when running facter 
> without args and the environment when asking for a specific fact?
>
> Facter.add('last_interface') do
>   setcode do
> name = Facter::Core::Execution.exec('ip -o l | grep -v loopback | perl 
> -lane\'$F[1]=~s/://g;print $F[1]\' | sort -n | tail -1')
> Facter.value("ipaddress_"+name)
>   end
> end
>
>

No. The environment provided to Facter (or to any command) is determined by 
how you launch the command.  The arguments to the command cannot affect its 
environment.

We might be able to offer better insight if you explained what fact value 
you expect, and why, and what you actually see in the incorrect case.

I will say right now, however, that it is awfully strange and heavyweight 
to use Perl as part of determining the fact value when the fact computation 
is already running in Ruby.  Even if you want to do the whole job with an 
external pipeline, 'sed' would be a lighter-weight (and simple-syntax) 
choice.  Nevertheless, I don't see how that could contribute to differing 
results.


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/f0aa94a6-aa55-4420-97f0-1f82c55c6207%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Requiring a subclass?

[Guy Matz]

Sorry!  Yes, accounts::account is a defined type!  :-(  Sorry . . .

Working now!!  Thanks!!

On Mon, Feb 9, 2015 at 9:01 AM, jcbollinger 
wrote:

>
>
> On Friday, February 6, 2015 at 3:45:30 PM UTC-6, guymatz wrote:
>>
>> Hello!  Is there a way to set the dependency for a resource that is a
>> subclass?  I have an accounts module, and "within" that is
>> accounts::account which contains declarations to create user, group, etc. .
>> . .  I would like to do something like:
>>
>> file {'sdfdsf':
>>  contents => 'sdkfjdsf',
>>  owner=> 'username',
>>  *requires Accounts::account['username'] *
>> }
>>
>> But that doesn't work.  (Error 400 on SERVER: Syntax error at
>> '::account'; expected ']')
>>
>
>
> It doesn't make sense.
>
>1. If accounts::account is a (sub)*class* then its name is
>"accounts::account", and no 'username' has anything to do with it.  In that
>case, a reference to it would be spelled Class['accounts::account'],
>as Thomas said.
>2. Whether it is a subclass (of another class) or not has nothing to
>do with it, but anyway, nothing in what you presented is related to whether
>or not it actually is a subclass.
>3. Except, if the 'username' part is in fact relevant in any way, it
>can only be because accounts::account is a defined type, not a class
>at all (sub- or otherwise).  If it is a defined type, then a reference to
>an instance of it would be spelled "Accounts::Account['username']"
>(every name segment capitalized).
>
>
>
>>
>> I also thought I should be able to say:
>>
>> file {'sdfdsf':
>>  contents => 'sdkfjdsf',
>>  owner=> 'username',
>>  *requires User['username'] *
>> }
>>
>> since it's really the user resource that's at the heart of the matter,
>> but that didn't work either!  Puppet still complains that it "Could not
>> find dependency User[username]"
>>
>
>
> If Puppet even gets to the point of determining whether it can find the
> dependency, then what you in fact tried was different from what you wrote
> above, as the declaration above misspells the 'require' metaparameter and
> omits the association arrow (=>) between that parameter name and its
> value.  We can help you better when you post the code that you are actually
> using, so cut&paste is your friend.
>
> Anyway, if you use a syntactically correct variation on the above, and
> Puppet complains that it could not find the dependency, then the problem is
> that you did not declare the dependency.  The 'require' metaparameter does
> not (indeed cannot) do that for you.  Puppet doesn't need to have
> *already* processed the declaration of User['username'] (or
> Account::Accounts['username']) when it processes the File declaration, but
> it needs to see such a declaration somewhere among the resources declared
> for the target node before it finishes building the catalog.
>
>
> 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/73a1d4ec-6ad0-481a-b6ab-2381c3308a18%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/CABnTgtUqpcafCrX8q%3DHqtiy0buYbpyez5bQ-fmbOhwcLpQGYvg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Fact is incorrect when show all facts, correct when on commandline

[John D'Ausilio]

Point taken on perl overkill .. trying to get something working and
copy/pasted someone else's solution ;)

In any case, I expect this to get all of the non-localhost interface
names, sort them, and return me the IP address of the last in the
list.
When run from commandline by name it works great. When I run facter
alone (show all facts) or Puppet runs it it appears to instead give me
the first one in the list.

On Mon, Feb 9, 2015 at 9:25 AM, jcbollinger  wrote:
>
>
> On Sunday, February 8, 2015 at 3:47:58 PM UTC-6, John D'Ausilio wrote:
>>
>> So I have a custom fact which works fine from the commandline: facter
>> last_interface  (it returns the ip address of the last of a sorted list of
>> interface names)
>>
>> If I just run facter without parameters, the value in last_interface is
>> incorrect!
>>
>> Is there something different between the environment when running facter
>> without args and the environment when asking for a specific fact?
>>
>> Facter.add('last_interface') do
>>   setcode do
>> name = Facter::Core::Execution.exec('ip -o l | grep -v loopback | perl
>> -lane\'$F[1]=~s/://g;print $F[1]\' | sort -n | tail -1')
>> Facter.value("ipaddress_"+name)
>>   end
>> end
>>
>
>
> No. The environment provided to Facter (or to any command) is determined by
> how you launch the command.  The arguments to the command cannot affect its
> environment.
>
> We might be able to offer better insight if you explained what fact value
> you expect, and why, and what you actually see in the incorrect case.
>
> I will say right now, however, that it is awfully strange and heavyweight to
> use Perl as part of determining the fact value when the fact computation is
> already running in Ruby.  Even if you want to do the whole job with an
> external pipeline, 'sed' would be a lighter-weight (and simple-syntax)
> choice.  Nevertheless, I don't see how that could contribute to differing
> results.
>
>
> 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/f0aa94a6-aa55-4420-97f0-1f82c55c6207%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/CAO1ctWey1Vn6CYr9y6-nqwH0iLBx-qp9yXV6yrxGPo-YsUuDtQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Fact is incorrect when show all facts, correct when on commandline

[John D'Ausilio]

Just to make sure .. simplified without perl ..

[root@uc-01 ~]# cat
/opt/wdts/puppet/production/modules/puppet/lib/facter/last_interface.rb
Facter.add('last_interface') do
  setcode do
name = Facter::Core::Execution.exec('ip -o l | grep -v loopback | sed
\'s/://g\' | cut -d\' \' -f2 | sort -n | tail -1')
Facter.value("ipaddress_"+name)
  end
end

[root@uc-01 ~]# ip -o l
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN \
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0:  mtu 1500 qdisc pfifo_fast state
UP qlen 1000\link/ether 08:00:27:b6:de:19 brd ff:ff:ff:ff:ff:ff
3: eth1:  mtu 1500 qdisc pfifo_fast state
UP qlen 1000\link/ether 08:00:27:1d:eb:14 brd ff:ff:ff:ff:ff:ff
4: eth2:  mtu 1500 qdisc pfifo_fast state
UP qlen 1000\link/ether 08:00:27:90:be:4c brd ff:ff:ff:ff:ff:ff
[root@uc-01 ~]# facter | grep last_interface
last_interface => 10.0.2.15
[root@uc-01 ~]# facter last_interface
10.200.111.100
[root@uc-01 ~]#

On Mon, Feb 9, 2015 at 10:34 AM, John D'Ausilio  wrote:

> Point taken on perl overkill .. trying to get something working and
> copy/pasted someone else's solution ;)
>
> In any case, I expect this to get all of the non-localhost interface
> names, sort them, and return me the IP address of the last in the
> list.
> When run from commandline by name it works great. When I run facter
> alone (show all facts) or Puppet runs it it appears to instead give me
> the first one in the list.
>
> On Mon, Feb 9, 2015 at 9:25 AM, jcbollinger 
> wrote:
> >
> >
> > On Sunday, February 8, 2015 at 3:47:58 PM UTC-6, John D'Ausilio wrote:
> >>
> >> So I have a custom fact which works fine from the commandline: facter
> >> last_interface  (it returns the ip address of the last of a sorted list
> of
> >> interface names)
> >>
> >> If I just run facter without parameters, the value in last_interface is
> >> incorrect!
> >>
> >> Is there something different between the environment when running facter
> >> without args and the environment when asking for a specific fact?
> >>
> >> Facter.add('last_interface') do
> >>   setcode do
> >> name = Facter::Core::Execution.exec('ip -o l | grep -v loopback |
> perl
> >> -lane\'$F[1]=~s/://g;print $F[1]\' | sort -n | tail -1')
> >> Facter.value("ipaddress_"+name)
> >>   end
> >> end
> >>
> >
> >
> > No. The environment provided to Facter (or to any command) is determined
> by
> > how you launch the command.  The arguments to the command cannot affect
> its
> > environment.
> >
> > We might be able to offer better insight if you explained what fact value
> > you expect, and why, and what you actually see in the incorrect case.
> >
> > I will say right now, however, that it is awfully strange and
> heavyweight to
> > use Perl as part of determining the fact value when the fact computation
> is
> > already running in Ruby.  Even if you want to do the whole job with an
> > external pipeline, 'sed' would be a lighter-weight (and simple-syntax)
> > choice.  Nevertheless, I don't see how that could contribute to differing
> > results.
> >
> >
> > 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/f0aa94a6-aa55-4420-97f0-1f82c55c6207%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/CAO1ctWfDcGSvP69Jd9hKhXJHHA%2B__7aeK4%2BeRzHCCE_G1UhZ3g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Virtual Resource Visibility

[Peter Berghold]

OK.. so I'm having a major brain fart here...

I have a class thusly:

class scripts::myscript {
 @file{'my neat script':
   path=>"/path/to/the/script",
   source=>"puppet:///modules/scripts/myscript.pl"
  }
   realize File['my neat script']
}


and in a module far far away I have the following sniglet:

   cmd { 'do my thing':
 command =>'/path/to/the/script',
  require => File['my neat script']
}


Shouldn't the file resource be visible to the other module?

(it's not acting that way...)

-- 

Peter L. Berghold   salty.cowd...@gmail.com

h ttp://science-fiction.berghold.net

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

[Puppet Users] representing undef in hiera?

[Christopher Wood]

How would I represent an undef in hiera such that a class parameter will be 
populated as undef? Like this, but in hiera:

#class testing::cwood1 ( $param1 = undef ) {
class testing::cwood1 ( $param1 ) {
  if str2bool($param1) {
notify { 'mn':
  message => "param1 is ${param1}"
}
  }
}

I'm dealing with a config file template where most options are always turned 
off. I'm also trying to get our puppet agent runs to fail with catalog 
compilation errors if they can't look up a hiera value, so there are no default 
values in the class parameters. (Exploring if catalog compilation failure is 
safer than the possibility of populating a config with default values.)

If I could list a bunch of obvious 'undef' style items in hiera that might be 
handier than listing 'false', given that the meaning of 'configitem=false' is 
different in this config than an absent configitem.

Details:

In the node yaml doing ~ or null both give me the same result.

testing::cwood1::param1: ~

But that parameter isn't looked up.

Feb  9 10:18:55 pt1 puppet-agent[22696]: Could not retrieve catalog from remote 
server: Error 400 on SERVER: Must pass param1 to Class[Testing::Cwood1] at 
/etc/puppet/environments/production/modules/testing/manifests/init.pp:3 on node 
pt1.hostopia.com

I've checked that the yaml is readable by ruby and the appropriate key shows up 
with pp as 

 "testing::cwood1::param1"=>nil}

so not sure what is up here.

When I use the empty string in the yaml the puppet catalog applies but I do not 
see anything in the log (so the class parameter was accepted).

testing::cwood1::param1: ''

Not really sure if I'm just mucking about with edge cases and should 
special-case my template or what. (http://yaml.org/type/null.html)

-- 
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/20150209163717.GA26376%40iniquitous.heresiarch.ca.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] External Facts in //facts.d/

[Dan White]

Puppet 3.7.3
Facter 2.3.0
running on RHEL 6

Reference: 
https://docs.puppetlabs.com/facter/2.2/custom_facts.html#fact-locations

I put a simple fact_file.txt in one of my modules to try this new feature.
When I run puppet agent, I see the fact file deployed to 
/var/lib/puppet/facts.d/
However, I cannot get it to come out on a command line.

Here's the text file:

patch_fact_1=hello
patch_fact_2=there
patch_fact_3=every
patch_fact_4=one

(Module name is "patch")

facter -p patch_fact_1 returns a blank line

# facter -p patch_fact_1 --debug
Found no suitable resolves of 1 for ec2_metadata
value for ec2_metadata is still nil

And a full "facter -p" list does not show my 4 new facts
I am using /etc/facter/facts.d thru stdlib.  Do the two not play nice in the 
same puppet-sandbox ?

I tried restarting the puppetmaster and re-running the agent - no change.
I copied the file to /etc/facter/facts.d/ , prefixing the file name and all the fact names with 
"other_" to keep them separate.  The "other_" facts appeared immediately (no 
surprise), but the originals remain unavailable.

A clue or two, please ?

“Sometimes I think the surest sign that intelligent life exists elsewhere in the 
universe is that none of it has tried to contact us.”  (Bill Waterson: Calvin & 
Hobbes)

--
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/579294ee-0d31-4829-bec5-1426378f235d%40me.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] manage users and ssh_authorized_key from hiera

[Garrett Honeycutt]

On 1/30/15 4:53 PM, Sans wrote:
> This is the class I have for the user creation:
> 
> /*#users.pp
> */
> 
> class common::users {
> 
> create_resources('group', hiera_hash('groups'))
>
> define create_ssh_users () {
> user { $name:
> password   => $password,
> managehome => $managehome,
> groups => $groups,
> ensure => $ensure,
> } ->
> 
> ssh_authorized_key { $name:
> user   => $name,
> type   => $type,
> key=> $key,
> ensure => $ensure,
> purge_ssh_keys => $purge_ssh_keys,
> }
> }
> create_resources('create_ssh_users', hiera_hash('ssh_users'))
> }
> 
> 
> in my */nodes.pp/*: 
> 
> hiera_include('classes')
> 
> 
> 
> and the associated hiera file is like this:
> 
> /*#users.yaml*/
> 
> classes:
> - 'common::users'
> 
> groups:
> 'admins':
> ensure: present
> gid: '2001'
> 'network':
> ensure: present
> gid: '2002'
> 
> ssh_users:
> 'sans':
> password: '$1$33mRSE$deEDRKq2aGPu0'
> managehome: true
> key: 'B3NzaC1yc2EAAAzdqs8etdh'
> purge_ssh_keys: true
> groups:
> - 'admins'
> - 'networks'
> 
> ensure: present
> 
> 'joe':
> 
> 
> 
> 
> 
> When I run puppet, I see errors like:
> 
> Error: Invalid parameter managehome on
> Common::Users::Create_ssh_users[andy] on node p19-d-nagios-001
> or
> Error: Invalid parameter purge_ssh_keys on
> Common::Users::Create_ssh_users[sans] on node p19-d-nagios-001
> 
> 
> The errors are pretty inconsistent - changes the parameter (i.e.
> sometimes it's managehome, next time is key etc.) and the user-name over
> time. Can anyone tell what am I missing please?
> Best!
> 

Hi,

I have a module with all of this functionality and tests :)

https://github.com/ghoneycutt/puppet-module-common#usage

Best regards,
-g


-- 
Garrett Honeycutt
@learnpuppet
Puppet Training with LearnPuppet.com
Mobile: +1.206.414.8658

-- 
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/54D8EC16.6040009%40garretthoneycutt.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Virtual Resource Visibility

[Garrett Honeycutt]

On 2/9/15 5:33 PM, Peter Berghold wrote:
> OK.. so I'm having a major brain fart here...
> 
> I have a class thusly:
> 
> class scripts::myscript { 
>  @file{'my neat script':
>path=>"/path/to/the/script",
>source=>"puppet:///modules/scripts/myscript.pl
> "
>   }
>realize File['my neat script']
> }
> 
> 
> and in a module far far away I have the following sniglet:
> 
>cmd { 'do my thing':
>  command =>'/path/to/the/script',
>   require => File['my neat script']
> }
> 
> 
> Shouldn't the file resource be visible to the other module?  
> 
> (it's not acting that way...)
> 
> -- 
> 
> Peter L. Berghold   salty.cowd...@gmail.com
> 
> 
> h ttp://science-fiction.berghold.net
> 
> 

Hi,

The virtual file is not realized when you call it from your farfaraway
class. Add `include scripts::myscript` before your cmd resource in that
class and it should work.

Best regards,
-g


-- 
Garrett Honeycutt
@learnpuppet
Puppet Training with LearnPuppet.com
Mobile: +1.206.414.8658

-- 
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/54D8ED5F.2070401%40garretthoneycutt.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Fact is incorrect when show all facts, correct when on commandline

[John D'Ausilio]

I have more information .. it seems almost like facter is caching a stale
result. While troubleshooting at the commandline I commented out the second
line (Facter::value) and had it just return the name it was finding. After
I made that change 'facter last_interface' returned the (correct) interface
name, while 'facter | grep last_interface' produced the same IP address as
before!

It appears that this problem is happening only on the target box (Centos
6.6 minimal, running in virtualbox) but not on my development system
(Ubuntu 14.04 on real hardware). Is there anything weird about behaviour in
virtualbox vms?

On Mon, Feb 9, 2015 at 11:12 AM, John D'Ausilio  wrote:

> Just to make sure .. simplified without perl ..
>
> [root@uc-01 ~]# cat
> /opt/wdts/puppet/production/modules/puppet/lib/facter/last_interface.rb
> Facter.add('last_interface') do
>   setcode do
> name = Facter::Core::Execution.exec('ip -o l | grep -v loopback | sed
> \'s/://g\' | cut -d\' \' -f2 | sort -n | tail -1')
> Facter.value("ipaddress_"+name)
>   end
> end
>
> [root@uc-01 ~]# ip -o l
> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN \
>  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> 2: eth0:  mtu 1500 qdisc pfifo_fast state
> UP qlen 1000\link/ether 08:00:27:b6:de:19 brd ff:ff:ff:ff:ff:ff
> 3: eth1:  mtu 1500 qdisc pfifo_fast state
> UP qlen 1000\link/ether 08:00:27:1d:eb:14 brd ff:ff:ff:ff:ff:ff
> 4: eth2:  mtu 1500 qdisc pfifo_fast state
> UP qlen 1000\link/ether 08:00:27:90:be:4c brd ff:ff:ff:ff:ff:ff
> [root@uc-01 ~]# facter | grep last_interface
> last_interface => 10.0.2.15
> [root@uc-01 ~]# facter last_interface
> 10.200.111.100
> [root@uc-01 ~]#
>
> On Mon, Feb 9, 2015 at 10:34 AM, John D'Ausilio 
> wrote:
>
>> Point taken on perl overkill .. trying to get something working and
>> copy/pasted someone else's solution ;)
>>
>> In any case, I expect this to get all of the non-localhost interface
>> names, sort them, and return me the IP address of the last in the
>> list.
>> When run from commandline by name it works great. When I run facter
>> alone (show all facts) or Puppet runs it it appears to instead give me
>> the first one in the list.
>>
>> On Mon, Feb 9, 2015 at 9:25 AM, jcbollinger 
>> wrote:
>> >
>> >
>> > On Sunday, February 8, 2015 at 3:47:58 PM UTC-6, John D'Ausilio wrote:
>> >>
>> >> So I have a custom fact which works fine from the commandline: facter
>> >> last_interface  (it returns the ip address of the last of a sorted
>> list of
>> >> interface names)
>> >>
>> >> If I just run facter without parameters, the value in last_interface is
>> >> incorrect!
>> >>
>> >> Is there something different between the environment when running
>> facter
>> >> without args and the environment when asking for a specific fact?
>> >>
>> >> Facter.add('last_interface') do
>> >>   setcode do
>> >> name = Facter::Core::Execution.exec('ip -o l | grep -v loopback |
>> perl
>> >> -lane\'$F[1]=~s/://g;print $F[1]\' | sort -n | tail -1')
>> >> Facter.value("ipaddress_"+name)
>> >>   end
>> >> end
>> >>
>> >
>> >
>> > No. The environment provided to Facter (or to any command) is
>> determined by
>> > how you launch the command.  The arguments to the command cannot affect
>> its
>> > environment.
>> >
>> > We might be able to offer better insight if you explained what fact
>> value
>> > you expect, and why, and what you actually see in the incorrect case.
>> >
>> > I will say right now, however, that it is awfully strange and
>> heavyweight to
>> > use Perl as part of determining the fact value when the fact
>> computation is
>> > already running in Ruby.  Even if you want to do the whole job with an
>> > external pipeline, 'sed' would be a lighter-weight (and simple-syntax)
>> > choice.  Nevertheless, I don't see how that could contribute to
>> differing
>> > results.
>> >
>> >
>> > 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/f0aa94a6-aa55-4420-97f0-1f82c55c6207%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/CAO1ctWe0xJPd43M5ck%2BJcmYA32YZ%3DO-mCk6jSyuLV7s0ng%2Bi5Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] hiera - multiple yaml backends

[Brett Swift]

I'm wondering if anyone has this unique use case. 

We're going to experiment by giving our ops team their own hieradata 
repository, and keep our internal repository separate. 

(If you're curious,  we'll be giving them control over the %{::hostname} 
 tier,  and we'll keep common  / roles / project  layers in the hierarchy 
tied at the 'dev' hieradata). 

The reason we're trying this is to experiment with different controls over 
different repositories.  Ops owns one, so they don't have to have the rigor 
of feature branches and pull requests and the rest of the SDLC that comes 
with our dynamic environment testing approach. 


*Ultimately: *I want this: 

:backends:
- opsyaml
- yaml
:yaml:
:datadir: /etc/puppetlabs/puppet/hieradata/%{::environment}
:opsyaml:
:datadir: /etc/puppetlabs/puppet/hostdata
:extension: yaml


but am limited because of this 
code: 
https://github.com/puppetlabs/hiera/blob/60f9d2d4b8b36e6dd47c3713dd64dc793b9745c0/lib/hiera/config.rb#L74-L82


*Possible solutions:*

1) create our own simple backend
2) symlink hostyaml_backend.rb  to yaml_backend.rb
3) use eyaml, and yaml backends,  just because it's easy .. :)

Does anyone have the same requirements?   What worked for you?

-- 
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/73086f39-fbe9-4a51-bdde-e562de88efe8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] hiera - multiple yaml backends

[Ramin K]

	In the past I've used yaml for Ops and json for Dev. That worked well 
and it was mostly automated scripts that we dropping files into a 
different path.


	While it's much more work you might consider Redis as a Hiera backend 
coupled with an http user interface and api. I did some work around 
allowing Jenkins to post to an API to update new version for Puppet to 
push. I stole the idea directly from this talk at the 2013 Puppet COnf.


Ramin

On 2/9/15 12:12 PM, Brett Swift wrote:

I'm wondering if anyone has this unique use case.

We're going to experiment by giving our ops team their own hieradata
repository, and keep our internal repository separate.

(If you're curious,  we'll be giving them control over the %{::hostname}
  tier,  and we'll keep common  / roles / project  layers in the
hierarchy tied at the 'dev' hieradata).

The reason we're trying this is to experiment with different controls
over different repositories.  Ops owns one, so they don't have to have
the rigor of feature branches and pull requests and the rest of the SDLC
that comes with our dynamic environment testing approach.


*Ultimately: *I want this:

|
:backends:
-opsyaml
-yaml
:yaml:
:datadir:/etc/puppetlabs/puppet/hieradata/%{::environment}
:opsyaml:
:datadir:/etc/puppetlabs/puppet/hostdata
:extension:yaml
|


but am limited because of this
code: 
https://github.com/puppetlabs/hiera/blob/60f9d2d4b8b36e6dd47c3713dd64dc793b9745c0/lib/hiera/config.rb#L74-L82


*Possible solutions:*
*
*
1) create our own simple backend
2) symlink hostyaml_backend.rb  to yaml_backend.rb
3) use eyaml, and yaml backends,  just because it's easy .. :)

Does anyone have the same requirements?   What worked for you?

--
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/73086f39-fbe9-4a51-bdde-e562de88efe8%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/54D91A86.20707%40badapple.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] hiera - multiple yaml backends

[Ramin K]

gah, link is https://www.youtube.com/watch?v=7NBJAC10ato

On 2/9/15 12:37 PM, Ramin K wrote:

 In the past I've used yaml for Ops and json for Dev. That worked
well and it was mostly automated scripts that we dropping files into a
different path.

 While it's much more work you might consider Redis as a Hiera
backend coupled with an http user interface and api. I did some work
around allowing Jenkins to post to an API to update new version for
Puppet to push. I stole the idea directly from this talk at the 2013
Puppet COnf.

Ramin

On 2/9/15 12:12 PM, Brett Swift wrote:

I'm wondering if anyone has this unique use case.

We're going to experiment by giving our ops team their own hieradata
repository, and keep our internal repository separate.

(If you're curious,  we'll be giving them control over the %{::hostname}
  tier,  and we'll keep common  / roles / project  layers in the
hierarchy tied at the 'dev' hieradata).

The reason we're trying this is to experiment with different controls
over different repositories.  Ops owns one, so they don't have to have
the rigor of feature branches and pull requests and the rest of the SDLC
that comes with our dynamic environment testing approach.


*Ultimately: *I want this:

|
:backends:
-opsyaml
-yaml
:yaml:
:datadir:/etc/puppetlabs/puppet/hieradata/%{::environment}
:opsyaml:
:datadir:/etc/puppetlabs/puppet/hostdata
:extension:yaml
|


but am limited because of this
code:
https://github.com/puppetlabs/hiera/blob/60f9d2d4b8b36e6dd47c3713dd64dc793b9745c0/lib/hiera/config.rb#L74-L82



*Possible solutions:*
*
*
1) create our own simple backend
2) symlink hostyaml_backend.rb  to yaml_backend.rb
3) use eyaml, and yaml backends,  just because it's easy .. :)

Does anyone have the same requirements?   What worked for you?

--
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/73086f39-fbe9-4a51-bdde-e562de88efe8%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/54D91BFE.1070309%40badapple.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] hiera - multiple yaml backends

[Brett Swift]

Yea I've tested a redis backend as an ENC but we haven't enabled it yet as 
we'll likely ditch it for the console enc in 3.7. 

The problem with Redis is lack of version control, which our Ops guys do 
want.   ( unless you did an http backend that served up a file system with 
your yaml files..  errr.   )


Sounds like I'm not the only one with this use case.   I might put in a 
feature request and/or hiera code if I can find the time. 




On Monday, 9 February 2015 13:43:49 UTC-7, Ramin K wrote:
>
> gah, link is https://www.youtube.com/watch?v=7NBJAC10ato 
>
> On 2/9/15 12:37 PM, Ramin K wrote: 
> >  In the past I've used yaml for Ops and json for Dev. That worked 
> > well and it was mostly automated scripts that we dropping files into a 
> > different path. 
> > 
> >  While it's much more work you might consider Redis as a Hiera 
> > backend coupled with an http user interface and api. I did some work 
> > around allowing Jenkins to post to an API to update new version for 
> > Puppet to push. I stole the idea directly from this talk at the 2013 
> > Puppet COnf. 
> > 
> > Ramin 
> > 
> > On 2/9/15 12:12 PM, Brett Swift wrote: 
> >> I'm wondering if anyone has this unique use case. 
> >> 
> >> We're going to experiment by giving our ops team their own hieradata 
> >> repository, and keep our internal repository separate. 
> >> 
> >> (If you're curious,  we'll be giving them control over the 
> %{::hostname} 
> >>   tier,  and we'll keep common  / roles / project  layers in the 
> >> hierarchy tied at the 'dev' hieradata). 
> >> 
> >> The reason we're trying this is to experiment with different controls 
> >> over different repositories.  Ops owns one, so they don't have to have 
> >> the rigor of feature branches and pull requests and the rest of the 
> SDLC 
> >> that comes with our dynamic environment testing approach. 
> >> 
> >> 
> >> *Ultimately: *I want this: 
> >> 
> >> | 
> >> :backends: 
> >> -opsyaml 
> >> -yaml 
> >> :yaml: 
> >> :datadir:/etc/puppetlabs/puppet/hieradata/%{::environment} 
> >> :opsyaml: 
> >> :datadir:/etc/puppetlabs/puppet/hostdata 
> >> :extension:yaml 
> >> | 
> >> 
> >> 
> >> but am limited because of this 
> >> code: 
> >> 
> https://github.com/puppetlabs/hiera/blob/60f9d2d4b8b36e6dd47c3713dd64dc793b9745c0/lib/hiera/config.rb#L74-L82
>  
> >> 
> >> 
> >> 
> >> *Possible solutions:* 
> >> * 
> >> * 
> >> 1) create our own simple backend 
> >> 2) symlink hostyaml_backend.rb  to yaml_backend.rb 
> >> 3) use eyaml, and yaml backends,  just because it's easy .. :) 
> >> 
> >> Does anyone have the same requirements?   What worked for you? 
> >> 
> >> -- 
> >> 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/73086f39-fbe9-4a51-bdde-e562de88efe8%40googlegroups.com
>  
> >> 
> >> <
> https://groups.google.com/d/msgid/puppet-users/73086f39-fbe9-4a51-bdde-e562de88efe8%40googlegroups.com?utm_medium=email&utm_source=footer>.
>  
>
> >> 
> >> 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/6ebfde9c-63fe-4235-bbdf-70fdf3282bba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Fact is incorrect when show all facts, correct when on commandline

[John Warburton]

No idea what virtual box is doing, I'd try to keep it internal and use
existing facts like "interfaces", lop off the loopback interface and grab
the last element of the "array" and use Facter.value as you are doing

John

On 10 February 2015 at 05:31, John D'Ausilio  wrote:

> I have more information .. it seems almost like facter is caching a stale
> result. While troubleshooting at the commandline I commented out the second
> line (Facter::value) and had it just return the name it was finding. After
> I made that change 'facter last_interface' returned the (correct) interface
> name, while 'facter | grep last_interface' produced the same IP address as
> before!
>
> It appears that this problem is happening only on the target box (Centos
> 6.6 minimal, running in virtualbox) but not on my development system
> (Ubuntu 14.04 on real hardware). Is there anything weird about behaviour in
> virtualbox vms?
>
> On Mon, Feb 9, 2015 at 11:12 AM, John D'Ausilio 
> wrote:
>
>> Just to make sure .. simplified without perl ..
>>
>> [root@uc-01 ~]# cat
>> /opt/wdts/puppet/production/modules/puppet/lib/facter/last_interface.rb
>> Facter.add('last_interface') do
>>   setcode do
>> name = Facter::Core::Execution.exec('ip -o l | grep -v loopback | sed
>> \'s/://g\' | cut -d\' \' -f2 | sort -n | tail -1')
>> Facter.value("ipaddress_"+name)
>>   end
>> end
>>
>> [root@uc-01 ~]# ip -o l
>> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN \
>>  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>> 2: eth0:  mtu 1500 qdisc pfifo_fast
>> state UP qlen 1000\link/ether 08:00:27:b6:de:19 brd ff:ff:ff:ff:ff:ff
>> 3: eth1:  mtu 1500 qdisc pfifo_fast
>> state UP qlen 1000\link/ether 08:00:27:1d:eb:14 brd ff:ff:ff:ff:ff:ff
>> 4: eth2:  mtu 1500 qdisc pfifo_fast
>> state UP qlen 1000\link/ether 08:00:27:90:be:4c brd ff:ff:ff:ff:ff:ff
>> [root@uc-01 ~]# facter | grep last_interface
>> last_interface => 10.0.2.15
>> [root@uc-01 ~]# facter last_interface
>> 10.200.111.100
>> [root@uc-01 ~]#
>>
>> On Mon, Feb 9, 2015 at 10:34 AM, John D'Ausilio 
>> wrote:
>>
>>> Point taken on perl overkill .. trying to get something working and
>>> copy/pasted someone else's solution ;)
>>>
>>> In any case, I expect this to get all of the non-localhost interface
>>> names, sort them, and return me the IP address of the last in the
>>> list.
>>> When run from commandline by name it works great. When I run facter
>>> alone (show all facts) or Puppet runs it it appears to instead give me
>>> the first one in the list.
>>>
>>> On Mon, Feb 9, 2015 at 9:25 AM, jcbollinger 
>>> wrote:
>>> >
>>> >
>>> > On Sunday, February 8, 2015 at 3:47:58 PM UTC-6, John D'Ausilio wrote:
>>> >>
>>> >> So I have a custom fact which works fine from the commandline: facter
>>> >> last_interface  (it returns the ip address of the last of a sorted
>>> list of
>>> >> interface names)
>>> >>
>>> >> If I just run facter without parameters, the value in last_interface
>>> is
>>> >> incorrect!
>>> >>
>>> >> Is there something different between the environment when running
>>> facter
>>> >> without args and the environment when asking for a specific fact?
>>> >>
>>> >> Facter.add('last_interface') do
>>> >>   setcode do
>>> >> name = Facter::Core::Execution.exec('ip -o l | grep -v loopback |
>>> perl
>>> >> -lane\'$F[1]=~s/://g;print $F[1]\' | sort -n | tail -1')
>>> >> Facter.value("ipaddress_"+name)
>>> >>   end
>>> >> end
>>> >>
>>> >
>>> >
>>> > No. The environment provided to Facter (or to any command) is
>>> determined by
>>> > how you launch the command.  The arguments to the command cannot
>>> affect its
>>> > environment.
>>> >
>>> > We might be able to offer better insight if you explained what fact
>>> value
>>> > you expect, and why, and what you actually see in the incorrect case.
>>> >
>>> > I will say right now, however, that it is awfully strange and
>>> heavyweight to
>>> > use Perl as part of determining the fact value when the fact
>>> computation is
>>> > already running in Ruby.  Even if you want to do the whole job with an
>>> > external pipeline, 'sed' would be a lighter-weight (and simple-syntax)
>>> > choice.  Nevertheless, I don't see how that could contribute to
>>> differing
>>> > results.
>>> >
>>> >
>>> > 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/f0aa94a6-aa55-4420-97f0-1f82c55c6207%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...@

Re: [Puppet Users] hiera - multiple yaml backends

[Matthew Burgess]

On 9 February 2015 at 20:12, Brett Swift  wrote:
> I'm wondering if anyone has this unique use case.
>
> We're going to experiment by giving our ops team their own hieradata
> repository, and keep our internal repository separate.

We have a similar requirement whereby our infrastructure team
(handling core FW, networking and OS-level resources) and project
teams (largely deploying application-layer RPMs, but perhaps also
opening up additional host-level firewall ports) need access to 2
different Git repositories so the baddies (app dev) can't stomp over
the goodies' (infrastructure) hard work :-)

We've ended up rolling our own synchronisation script; a common Git
user has read-only access to both repositories and clones/pulls them
to a staging area.  It then composes them into a single YAML backend
hierarchy, unlike your example where you have a 1-1 mapping between
sources and backends.

Regards,

Matt.

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

[Puppet Users] Does the "Learning VM" image actually work?

[Brad Knowles]

Folks,

I tried downloading the Learning VM image for VMware, and while there does 
seem to be a .vmdk file inside the zip archive, along with various other 
parts I would expect to find, so far as I can tell this is not something 
that I can successfully import into VMware Fusion 7.

Has this image been tested and confirmed to work with VMware Fusion 7?

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/69b205dc-d04a-4fcf-ae33-950ebe47b13b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Puppet Learning VM?

[Brad Knowles]

Folks,

I tried posting a message to this effect from my Google Groups account, but it 
doesn’t seem to have gone through.  I’ll try to post it again via e-mail to the 
Google Groups address.


Anyway, I’m wondering if anyone has managed to actually use the latest version 
of the Puppet Learning VM with VMware Fusion 7?  I saw that VMware Fusion was 
preferred over VirtualBox, and so I downloaded the zip archive and extracted 
it, and I can see that there are various files inside the archive that would 
appear to be typical for a VMware image.  However, I can’t seem to get it to 
load under Fusion 7.

If you have used this VM recently with Fusion 7, can you share with me your 
system details so that I can compare those with my own?

Thanks!

-- 
Brad Knowles 
LinkedIn Profile: 

-- 
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/8CA4BDE5-C490-4E69-8BBA-C2B4E58C7A81%40shub-internet.org.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Cant remove depreciated warning message

[David LeVene]

Hi John,

To clarify, this should only be run on the puppet master as that's where 
the catalog complication takes place?

That seems to be all good - the base environment points to production and 
other environments point to their correct location.

puppet_master ~]#  puppet master --configprint manifest
> /etc/puppet/environments/production/manifests
> puppet_master ~]# puppet master --configprint manifest 
> --environment=dlscratch
> /etc/puppet/environments/dlscratch/manifests


when I view the site.pp in both of those locations, they are as expected - 
the one in my scratch branch has the additional information around the 
allow_packages = false & I'm seeing the notify, which tells me the file is 
being compiled.

Any other suggestions?

Regards
David



On Monday, 9 February 2015 20:26:52 UTC+10:30, Johan De Wit wrote:
>
>  You could start checking your manifest dir for your environment :
>
> puppet master --configprint manifest
>
> mine says :
>
> /data/puppet/environments/production/manifests
>
> There you should have your site.pp for that environment.
>
> hth
>
> Johan
>
> On 09/02/15 05:56, David LeVene wrote:
>  
>  Hey All,
>
>  I've started to upgrade a few puppet clients to the latest version and 
> have hit the issue which everyone had a while ago around this error
>
>  "Warning: The package type's allow_virtual parameter will be changing 
> its default value from false to true in a future release. If you do not 
> want to allow virtual packages, please explicitly set allow_virtual to 
> false.
>(at /usr/lib/ruby/site_ruby/1.8/puppet/type/package.rb:430:in 
> `default')"
>
>  I've implemented the fix in manfests/sites.pp in my test environment but 
> the error message isn't going away!
>
>  Puppet masters are 3.7.4, but are setup under RVM so i can run > ruby 
> 1.8.7 due to an ordering issue.
>
>  Why is puppet not picking up the config is it a bug or am I missing 
> something obvious?
>
>  The below is what i'm using in my site.pp and yes, i do see the notify 
> message.
>
>  if versioncmp($::puppetversion,'3.6.1') >= 0 {
>   notify {'I Am here':}
>
>  
>$allow_virtual_packages = hiera('allow_virtual_packages',false)
>
>  
>Package {
> allow_virtual => $allow_virtual_packages,
>   }
> }
>
>  
>  # puppet agent -t --environment=dlscratch --server=int-puppet-dev
> Info: Retrieving pluginfacts
> Info: Retrieving plugin
> Info: Loading facts
> Warning: The package type's allow_virtual parameter will be changing its 
> default value from false to true in a future release. If you do not want to 
> allow virtual packages, please explicitly set allow_virtual to false.
>(at /usr/lib/ruby/site_ruby/1.8/puppet/type/package.rb:430:in `default')
> Info: Caching catalog for xxx
> Info: Applying configuration version '1423457136'
> Notice: I Am here
> Notice: /Stage[main]/Base/Notify[I Am here]/message: defined 'message' as 
> 'I Am here'
> Notice: Finished catalog run in 6.62 seconds
>
>  Any suggestions as to where to look next?
>
>  I am aware that I can add this into the puppet.conf to disable all 
> warnings, but i'd prefer to keep the config inside the manifests and only 
> disable this one warning.
>
>  Cheers
> David
>
>  -- 
> 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/a5380933-a138-4f76-9f23-8b16df92f117%40googlegroups.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> -- 
> Johan De Wit
>
> Open Source Consultant
>
> Red Hat Certified Engineer  (805008667232363)
> Puppet Certified Professional 2013/2014 (PCP006)
> blog : http://johan.koewacht.net/
> _
>  
> Open-Future Phone +32 (0)2/255 70 70
> Zavelstraat 72  Fax   +32 (0)2/255 70 71
> 3071 KORTENBERG Mobile+32 (0)474/42 40 73
> BELGIUM http://www.open-future.be
> _
>  
>
>
> Upcoming Events:
>
> Puppet Fundamentals | 
> http://www.open-future.be/puppet-fundamentals-training-26th-till-28th-january
>
> Puppet Architect | 
> http://www.open-future.be/puppet-architect-training-29th-till-30th-january
>
> Linux Training | 
> http://www.open-future.be/linux-training-9th-till-13th-february
>
> Puppet Practitioner | 
> http://www.open-future.be/puppet-practitioner-training-17th-till-19th-february
>
> Bacula Administrator 1 | 
> http://www.open-future.be/bacula-administrator-i-training-24th-till-26th-february
>
> Subscribe to our newsletter: http://eepurl.com/BUG8H
>  
>  

-- 
You received this me

Re: [Puppet Users] Re: how to prevent certificate revocation list (CRL) from expiring

[Felix Frank]

On 02/06/2015 05:15 PM, Josh Bronson wrote:
> I just filed https://tickets.puppetlabs.com/browse/ENTERPRISE-515 for
> this. The workaround is to disable CRL checking:
>
> 1. Add "certificate_revocation = false" to the [agent] section of the
> puppet.conf file as described at
> https://docs.puppetlabs.com/puppet/latest/reference/config_ssl_external_ca.html,
> and
> 2. comment out the line containing SSLCARevocationFile in
> /etc/puppetlabs/httpd/conf.d/puppetdashboard.conf.

Yes, and honestly, I really don't see what else Puppet could do in this
situation to help you out.

> I'm using FreeIPA as a certificate authority, and it uses that field
> to communicate to users when the next update will be ready. It seems
> to like to update it a few times a day. The trouble is, there is
> always going to be a moment *after* the update is ready but *before* a
> script has had a chance to update the CRL and restart the
> Puppetmaster. During this time, Puppet agent runs will fail. Is there
> any way to tell Puppet that slightly out-of-date CRLs are okay?
> Otherwise, I think the next step is to try disabling checks to the
> CRL, but I like the fact that Puppet checks it by default.

This is actually an issue with the CA, from my point of view. It should
really specify next update times that are sufficiently late after the
actual update, so that SSL clients don't run a risk of hitting that time
window. Perhaps there is a configuration setting to that effect?

Cheers,
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/54D952A3.3050406%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.