Re: [Puppet Users] Geppetto + Github,com configurations

[Henrik Lindberg]

On 2015-04-12 6:58, Warron French wrote:

Hello, I am trying to learn how to write Puppet Modules.  I have taken
the free training within the PuppetLabs Learning VM (which was very
informative, and self-paced) and wanted to use my Windows 7 machine
where I have installed Geppetto-4.3.1.  I already had (months ago)
installed and configured Github client pointing to my online repository
and configured it with my working directory.

*How though, do I configure Geppetto, */with the hooks?,/ so that I can
post changes I make on my system up to my repository on the Github,com site?

I have been looking for the last 2 weeks, and, in the evening when I am
at home from my long day of working.  Any instructions or document or
website that actually /tells me/ how to configure Geppetto, so that I
can start, write and post my Puppet Modules up to my Github repository
would be greatly appreciated.



What you are looking for is how the Git support works in Geppetto.
You can follow any on-line tutorial for Eclipse E-Git.

Basically: add your repository to the set of Git repositories in the Git 
Repository View. You have several options there (create new, clone a 
remote, use existing local repository). You probably already have it on 
disk so just add a reference to that.


You can then import your module from that repository as a general 
project. Once that is done change the project's nature to be a puppet 
project.


You should after that be able to edit, track changes, commit, push, etc. 
etc.


The only puppet specific part on all of this is that puppet projects 
have a "puppet nature".


Once this is set up, you get some eclipse/geppetto specific hidden files 
in the project. It is beneficial to check those in as it is the easier 
for others (or you the next time) you want to import the project.


Done.

Hope that helps you a little - I do recommend online tutorials for E-Git.

- henrik



Thank you,
Warron


--
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/0f583153-cb20-49f0-ab59-e95198f6645c%40googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.



--

Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/n3s1oa%24rqn%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: why does the create_resource functio not contain in local scope?

[jcbollinger]

On Thursday, December 3, 2015 at 11:09:47 PM UTC-6, Haani Niyaz wrote:
>
> Thanks for the clarification. I did forget to mention that I tried the 
> ordering of my classes as well:
>
> class { 'server_packages':
> # list of packages
> server_packages  => hiera('server_packages'), 
> enable_repo  => 'my-rpms,base', 
>   } ->
>
> class { 'some_class': 
># params here
>   }
>
>

I see no reason to change my earlier remarks, but looking more closely, it 
does appear that you have a containment problem 
.  
Although the evidence is in your log, it would have been more apparent if 
you had given a more complete representation of your Class[some_class].

Note in particular that your log excerpt does not show any resource 
belonging to Class[some_class] applied before Package[mysql-devel.x86_64] 
or any other resource declared by Class[server_packages].  What it shows is 
resources declared by *other* classes (e.g. Class[some_class::Service]) 
being applied in that window.  When one end of a relationship is a class, 
C, the relationship is transitive to the resources declared directly by C, 
but it is *not* automatically transitive to other *classes* declared by C.  
That is, although classes serve as containers for the resources they 
declare, they do not automatically contain the other classes they declare.

That (lack of) class containment behavior is intentional and desirable as a 
default, but often enough you do want classes to contain other classes.  
For that, there is the `contain` function, which provides include-like 
class declarations with containment semantics, and which therefore can be 
used also in addition to another declaration of the same class to add 
containment semantics.  Although the details of your Class[some_class] are 
unclear, you probably want something more or less along these lines:

class some_class (
# params here
) {
  contain some_class::install
  contain some_class::config
  contain some_class::gem_Install
  contain some_class::service

  Class[some_class::install]
-> Class[some_class::config]
-> Class[some_class::gem_install]
-> Class[some_class::service]
}


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/d346ca91-8016-4e45-b448-604fb6e1b786%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Custom facts per node.. only via /etc/facter/facts.d/fact_xyz.txt per node?

[Hubert Schmoll]

Hello everyone,

here's what i wanna accomplish: 
i am havin 4 so called servergroups

- ci
- dev
- stage
- production

and i want them to have specific facts depending on the group they are in. 
so in every node i created a file /etc/facter/facts.d/servergroup.txt, 
containing e.g.
*servergroup=stage* 

where then a 

*facter -d servergroup *in the clienthost
gives me an:

*stage *

on puppet master, my hiera.yaml looks like this:

:hierarchy:
  - "servergroup/%{::servergroup}"
  - "nodes/%{::clientcert}"
  - common

and i've got on my hieradata a folder servergroup with an file stage.yaml, 
which, then again, holds:

message: '***   Preparing STAGE environment   ***'
repo_stage_enabled: '1'
repo_prod_enabled:  '0'
nrpe_allowed_hosts: '192.168.3.4'

my module which installes a nrpe uses then these values. like:

$nrpe_allowed_hosts = hiera('nrpe_allowed_hosts')


so far this works, every stage node gets this values, productive of ci 
nodes get different values. all good.
What  i do not like is that i have on each node to create the file 
"/etc/facter/facts.d/servergroup.txt".

I'd rather like to have this information which servergroup each node 
belongs on my puppetmaster. 

Any ideas? Use ENC? Create kinda custom facts on the puppet master ?

Thanks and best regards

Hubert

-- 
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/07ef5bc5-a62a-4b0a-950e-50f0d16b3491%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Custom facts per node.. only via /etc/facter/facts.d/fact_xyz.txt per node?

[Luke Bigum]

An ENC can be used to insert a sort of "Puppet Master defined Fact" (which is 
actually a top scope variable/parameter) before catalog compilation. Note that 
this will never appear in "facter -p" on the Agents, because it's not really a 
Fact.

Code:

https://gist.github.com/lukebigum/20231e70545a298b7dc5

And the data file looks like:

[root@master ~]# head -n10 /etc/puppet/roles.yaml 
#Managed by Puppet
---
host.example.com:
  parameters:
role: woof
server.example.com:
  parameters:
role: cows

--
Luke Bigum
Senior Systems Engineer

Information Systems


- Original Message -
From: "Hubert Schmoll" 
To: "Puppet Users" 
Cc: s...@tetralog.de
Sent: Friday, 4 December, 2015 9:31:33 AM
Subject: [Puppet Users] Custom facts per node.. only via 
/etc/facter/facts.d/fact_xyz.txt per node?

Hello everyone,

here's what i wanna accomplish: 
i am havin 4 so called servergroups

- ci
- dev
- stage
- production

and i want them to have specific facts depending on the group they are in. 
so in every node i created a file /etc/facter/facts.d/servergroup.txt, 
containing e.g.
*servergroup=stage* 

where then a 

*facter -d servergroup *in the clienthost
gives me an:

*stage *

on puppet master, my hiera.yaml looks like this:

:hierarchy:
  - "servergroup/%{::servergroup}"
  - "nodes/%{::clientcert}"
  - common

and i've got on my hieradata a folder servergroup with an file stage.yaml, 
which, then again, holds:

message: '***   Preparing STAGE environment   ***'
repo_stage_enabled: '1'
repo_prod_enabled:  '0'
nrpe_allowed_hosts: '192.168.3.4'

my module which installes a nrpe uses then these values. like:

$nrpe_allowed_hosts = hiera('nrpe_allowed_hosts')


so far this works, every stage node gets this values, productive of ci 
nodes get different values. all good.
What  i do not like is that i have on each node to create the file 
"/etc/facter/facts.d/servergroup.txt".

I'd rather like to have this information which servergroup each node 
belongs on my puppetmaster. 

Any ideas? Use ENC? Create kinda custom facts on the puppet master ?

Thanks and best regards

Hubert

-- 
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/07ef5bc5-a62a-4b0a-950e-50f0d16b3491%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
---

LMAX Exchange, Yellow Building, 1A Nicholas Road, London W11 4AN
http://www.LMAX.com/

#1 Fastest Growing Tech Company in the UK - Sunday Times Tech Track 100 (2014) 

2015 Best Margin Sector Platform - Profit & Loss Readers' Choice Awards
2015 Best FX Trading Venue - ECN/MTF - WSL Institutional Trading Awards
2014 Best Margin Sector Platform - Profit & Loss Readers' Choice Awards
2014 Best FX Trading Venue - ECN/MTF - WSL Institutional Trading Awards
2014 Best Infrastructure/Technology Initiative - WSL Institutional Trading 
Awards
2013 #15 Fastest Growing Tech Company in the UK - Sunday Times Tech Track 100
2013 Best Overall Testing Project - The European Software Testing Awards
2013 Best Margin Sector Platform - Profit & Loss Readers' Choice Awards
2013 Best FX Trading Platform - ECN/MTF - WSL Institutional Trading Awards
2013 Best Executing Venue - Forex Magnates Awards

---

FX and CFDs are leveraged products that can result in losses exceeding your 
deposit. They are not suitable for everyone so please ensure you fully 
understand the risks involved.

This message and its attachments are confidential, may not be disclosed or used 
by any person other than the addressee and are intended only for the named 
recipient(s). This message is not intended for any recipient(s) who based on 
their nationality, place of business, domicile or for any other reason, is/are 
subject to local laws or regulations which prohibit the provision of such 
products and services. This message is subject to the following terms 
(http://lmax.com/pdf/general-disclaimers.pdf), if you cannot access these, 
please notify us by replying to this email and we will send you the terms. If 
you are not the intended recipient, please notify the sender immediately and 
delete any copies of this message.

LMAX Exchange is the trading name of LMAX Limited. LMAX Limited operates a 
multilateral trading facility. LMAX Limited is authorised and regulated by the 
Financial Conduct Authority (firm registration number 509778) and is a company 
registered in England and Wales (number 6505809).

LMAX Hong Kong Limited is a wholly-owned subsidiary of LMAX Limited. LMAX Hong 
Kong is licensed by the Securities and Futures Commission in Hong Kong to 
conduct Type 3 (leveraged foreign exchange trading) regulated activity with CE 
Number BDV088.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Use

[Puppet Users] Puppet Exec resource with complex Environment Variables...

[Sean]

Greetings,

I am working on streamlining some older puppet code, that uses a lot of 
Exec resources to accomplish it's purposes.  It's not terribly elegant and 
we're working on design to replace it with code that leverages puppet 
features.  One of the pieces I'm struggling with is how to set complex 
environment variables that are available to use in onlyif/unless statements 
as well as the command itself.  I'm wondering if this just isn't possible?

Here's an example with the aide.  NOTE that we're not in a spot where I can 
make puppet manage the aide config file, and thus use an aide module and 
parameters instead of shell variables.  All of these commands run 
successfully in a bash shell for the various conditions that would apply. 
 I have other similar scenarios, but aide is one of the more complex ones.

  exec { 'init-aide-database':
path=> 
'/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin',
environment => [ 'DBDIR=$(egrep \'^@@define DBDIR \' /etc/aide.conf|awk 
\'{print $NF}\')',
  'DBFILE=$(egrep \'^database=file\' /etc/aide.conf|awk -F/ \'{print 
$NF}\')',
  'DBNEW=$(egrep \'^database_out=file\' /etc/aide.conf|awk -F/ \'{print 
$NF}\')',
  ],
command => '/usr/sbin/aide --init >/dev/null 2>&1 && cp -p 
${DBDIR}/${DBNEW} ${DBDIR}/${DBFILE}',
unless  => 'test -f ${DBDIR}/${DBNEW} && test -f ${DBDIR}/${DBFILE}'
,
require => Package['aide'],
logoutput   => true,
timeout => 0,
  }

When executing, puppet always runs the exec because the env var's are 
empty, so the unless case always fails.  Then we get a scenario where we're 
running aide --init when it's not needed and the cp command throws an error 
due to empty variables.

My thought at the moment is that I need to build two shell scripts as file 
resources.  One to call in the unless test, and another to call in the 
command if the unless script fails.  Perhaps that's more elegant, but we're 
hoping to avoid delivering script files to the nodes wherever possible. 
 I'm hoping the gurus out here might point me in the best direction!

Thank you kindly!


-- 
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/d4a7a101-cb24-46e3-98a6-4ad42b2345cc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Puppet 4: default value of a parameter in a module and dependency

[Francois Lafont]

On 02/12/2015 23:55, Henrik Lindberg wrote:

>>> In Puppet 4.3.0 we also added the ability to use hiera data in modules.
>>
>> Same remark: can you explain a little?
> 
> Start here: 
> https://docs.puppetlabs.com/puppet/4.3/reference/release_notes.html#new-feature-puppet-lookup

Thanks for the link Henrik, even if I'm not sure to have understood which is 
new in 4.3.0 concerning the lookup() function. ;)

>> Do you know if this bug will be resolved soon?
>> https://tickets.puppetlabs.com/browse/PUP-5209
>>
> 
> We seemed to have dropped the ball on that one and it did not show up on our 
> board. We will take a look at it. Thanks for reporting back on the ticket.

No problem. ;)

François Lafont

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

Re: [Puppet Users] Re: Using Package and Yumrepo together? Why is yumrepo creating a corrupt .repo file?

[Stefan Lasiewski]

I'm trying Augeas as a workaround. This seems to work as expected-- the 
Package is installed first, and the file is modified second.

class stefanl::remi (

  $ensure   = 'latest', 

  $enabled  = true, 

  $priority = '80', 
  

) { 

  package { 'remi-release': 

ensure  => $ensure, 

  }

  augeas { 'remi-safe': 

context => '/files/etc/yum.repos.d/remi-safe.repo/remi-safe',   

changes => [   
 
  "set enable   ${enabled}",   
 
  "set priority ${priority}",   

], 
 
require => Package['remi-release'], 

  } 


}




-= Stefan

On Tuesday, November 17, 2015 at 4:50:15 PM UTC-8, Stefan Lasiewski wrote:
>
> Unfortunately, I do not have a workaround, short of "Don't use the Yumrepo 
> and Package types together".
>
> Does anyone else have a better way to workaround this bug?
>
> -= Stefan
>
> On Friday, November 13, 2015 at 9:58:26 AM UTC-8, Stefan Lasiewski wrote:
>>
>> On Fri, Nov 13, 2015 at 6:36 AM, jcbollinger  wrote:
>>>
>>>
>>> That chain of events seems unlikely.  In the first place, I'm not 
>>> prepared to believe that when applying a catalog corresponding to the 
>>> declarations you presented, the agent fails to successfully apply 
>>> Package['remi-release'] before it applies Yumrepo['remi-safe'].  If you 
>>> truly observe such behavior -- via the agent's log output, for example -- 
>>> then it follows that the catalog applied was not built based on those 
>>> declarations.
>>>
>>
>> Thanks for that sanity check. Now that I read the logs more closely, I 
>> was mistaken.
>>  
>>
>>> Under some circumstances, however, the RPM's version of the files might 
>>> be installed with an additional .rpmnew extension to avoid replacing 
>>> pre-existing versions of the same file.
>>>
>>
>> That is my understanding as well. However, these .rpmnew files aren't 
>> being created either, which is strange. If I remove the Yumrepo resource 
>> from my manifest, the .rpmnew files will be created if I create a 
>> remo-safe.repo file by hand.
>>
>> It is conceivable that your Yumrepo resource is clobbering unmanaged 
>>> properties of the managed repository.  That would constitute a bug and a 
>>> regression, and you can test for it by installing the release package 
>>> manually, verifying it good, and then applying the specified class to the 
>>> node and observing damage to the repo definition.  There are any number of 
>>> other possibilities, but I decline to speculate further.
>>>
>>
>> I think I ran into a longstanding bug with the Yumrepo resource type:
>>
>> * https://tickets.puppetlabs.com/browse/PUP-723 "Due to prefetching, 
>> Yumrepo clobbers any definition that it does not create"
>> * Historical data is in https://projects.puppetlabs.com/issues/1238
>>
>>
>> At the head of my log output I see that Puppet is prefetching some Yum 
>> resources:
>>
>> Info: Applying configuration version '1447376917'
>> Debug: Prefetching yum resources for package
>> ...
>> ... and further down, it executes the Yumrepo type with cached content:
>> Debug: Executing '/usr/bin/yum -d 0 -e 0 -y list remi-release'
>> Debug: Package[remi-release](provider=yum): Ensuring => latest
>> Debug: Executing '/usr/bin/yum -d 0 -e 0 -y install remi-release'
>> Notice: /Stage[main]/stefanl_yum::Remi/Package[remi-release]/ensure: 
>> created
>> Debug: /Stage[main]/stefanl_yum::Remi/Package[remi-release]: The 
>> container Class[stefanl_yum::Remi] will propagate my refresh event
>> Notice: /Stage[main]/stefanl_yum::Remi/Yumrepo[remi-safe]/ensure: created
>> Debug: /Stage[main]/stefanl_yum::Remi/Yumrepo[remi-safe]: The container 
>> Class[stefanl_yum::Remi] will propagate my refresh event
>>
>> From reading the bug, it looks like what is actually happening here might 
>> be:
>>
>> 1. yumrepo prefetches a yum resource. At this point, the 
>> /etc/yum.repos.d/remi*.repo files don't exist, so yumrepo assumes that 
>> the files won't exist later.
>> 2. Later, Package[remi-release] is created
>> 3. Then, Yumrepo[remi-safe] is created. B

Re: [Puppet Users] Re: Puppet 4: default value of a parameter in a module and dependency

[Francois Lafont]

Hi John,

Sorry for my late answer, right now I'm pretty busy. ;)

On 02/12/2015 15:18, jcbollinger wrote:

> On Tuesday, December 1, 2015 at 11:26:15 PM UTC-6, François Lafont wrote:
>  
> 
>> No, no. You can see 
>> http://puppet-on-the-edge.blogspot.fr/2015/01/puppet-40-data-in-modules-and.html
>>  
>> With puppet 4, the "data philosophy" has changed. 
>>
>>
> I think "the data philosophy has changed" is a bit of an overreach.  Two 
> things relevant to the current discussion have happened:
> 
>1. Puppet has adopted a data-in-modules mechanism into the core.  This 
>has been long desired, and was available -- in different form -- as a 
>third-party module for Puppet 3.  This, I already knew about.
>2. Puppet has added a mechanism to write custom functions in Puppet DSL, 
>including such functions as underpin the data-in-modules mechanism.  This, 
>I had overlooked.
> 
> None of that impacts my primary thesis, however. It still is impossible to 
> reliably predict what value a class parameter of an as-yet undeclared class 
> would take if that class were declared later, by unspecified means.  You 
> can determine what value Puppet would choose via automated data binding, 
> but even supposing that yields a value at all -- it does not need to do -- 
> you cannot, in general, be certain that automated data binding is the 
> mechanism that ultimately will be used to set that parameter's value.  That 
> is, you cannot, in general, predict what value a class parameter *will *take. 
> If you are willing to ensure that the class is declared, however, then you 
> can easily determine what value any of its parameters *does* take.

Yes, you are absolutely right and your explanations show me that I was not
precise enough when I have described my question. Sorry for that. I will
try to fix it.

1. My question was in fact only about _public_ classes of my modules.

2. These classes are _always_ called via "require" or "include", never
with parameters. (The only case where I can call sometimes classes with
parameters is when a class in a module calls another private class of
the same module.)

So I fact my question is, for a node, the ENC will trigger this puppet code:

# Only "include" or "require".
include moda
include modb
include modc::fooc
include modc::barc
include modd::food
include modd::bard
include mode
etc...

and I would like to have the default value of ::modb::param equal to
the value of the parameter ::moda::param. And I think it's possible (if
1. and 2. are satisfied) with this code in ./modules/modc/functions/data.pp:

function modb::data {

  # We assume that the type expected here is a non-empty string.
  $param = lookup('moda::param', String[1], 'first')

  # code...

  {
...
modb::param => $param,
...
  }

}

And mabe (but I'm not completely sure on this point), it could be a good
idea to put in ./modules/modb/metadata.json a dependency ("modb depends on
moda"). But I have lot of doubts on this point...?

John, are we agreed in these conditions?

> If you conceive a module to be in a position to control or even to know 
> whether and how a class from a different module is declared, then that's a 
> strong signal that you should combine or refactor your modules.  If you 
> think one module has need for direct access to in-module data of a 
> different module, then that is also a signal that you should combine or 
> refactor.

And in the conditions which I have described above, do you still think that
a refactor is needed?

According to me, 2 modules moda modb can be independent but sometimes it can
be relevant (and handy) that the default value of modb::param is equal to
the value of moda::param, no? For instance for the password shared between
a server and the clients ie "server::pwd" and "client::pwd".

Sorry again for my lack of details in my previous posts.

François Lafont

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