Re: [Puppet Users] Detect when files are put in a directory? And alternatives?

[Peter Bukowinski]

This is antithetical to the way Puppet is normally used, but what you're asking 
for is possible if you look for custom facts in /etc/facter/facts.d and use 
them as triggers for specific software installs. Basically, you can create one 
or more .txt files in that location containing one or more 'key=value' pairs, 
then use those fact values with a selector to, for example, have puppet install 
a specific apache build.

See the puppet docs for specifics:

http://docs.puppetlabs.com/guides/custom_facts.html#external-facts

Note that I'm not condoning this particular use of puppet, just saying that 
it's possible.

-- Peter Bukowinski

> On Jan 2, 2014, at 6:39 PM, Shark Laser  wrote:
> 
> 
> I'm a puppet newbie but have gone through the tutorial and now read most of a 
> book on the subject.(So please tell me if I am approaching the problem 
> wrong conceptually).
> 
> Problem:   We want a directory where any user can put a file which will 
> signify a program that is to be installed by Puppet.   i.e.  If one were to 
> go to this special location and do 'touch someSpecialCompileOfApache' then 
> Puppet would see the new file in the directory and we would have additional 
> logic to then install a special compile of apache.  (just a simple contrived 
> example)
> 
> The first hurdle seems to be that 'notify' s don't get triggered on a 
> directory if files are merely put in the directory.Are my findings here 
> correct?   It seems the directory itself would have to change to trigger the 
> notify?  ie the name of the directory or a permission?  That seems to nix the 
> first attempt.
> 
> Assuming I am right so far,   I thought of a second possibly simpler 
> approach.   I wanted to have one text file.Each line in the text file 
> would contain an entry for a program that was to be installed.   I'm sure I 
> can get notify's when the single file is changed.   Is puppet sophisticated 
> enough that I could see what the change was in the text file and then 
> determine an action based on that?  
> 
> Thanks in advance.
> 
> -- 
> 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/7f71bfe0-2310-474b-a55e-f3bf9bfc3bf8%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
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/92634EA9-7719-44E3-9D9D-488BF9C4B220%40gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Cant install modules

[Ryan Coleman]

On Mon, Dec 23, 2013 at 12:07 PM, Grant Hardester wrote:

> I can't install any modules, I keep getting 404's.
>
> Any help would be greatly appreciated!
>
> Thanks!
>

Hi Grant, which version of Puppet are you using? The search output provided
suggests pre-2.7.14 but I'd like to know the exact version to figure out
what's wrong.

If you're in a hurry, each module page on forge.puppetlabs.com has a
'Download as a .tar.gz' link which you could use to curl/wget the module
tarball. Unpack that into your module path as just the module name. For
example, puppetlabs/ntp would be unpacked as ntp into
/etc/puppet/modules/ntp


-- 
Ryan Coleman | Modules & Forge | ryanycoleman on twitter & #puppet IRC

-- 
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/CAFkZv1s1QB8X%2BEdZbCxA2%3D2QM58rDxLtq9S8Dx19LZvYMdiBaQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] node_aws issue: undefined method

[Colin Cullinan]

Thanks for the quick response Justin,

I had received the same error before I tried adding the CP as its own gem. For 
completeness, I started from scratch, using Ubuntu 12.04.3 Puppet Ent 3.1.1 
and used only the CP included within the Puppet installer defined by 
*q_puppet_cloud_install=y* in the install answer file.

I launched an AWS Ubuntu Server 12.04.3 LTS Server micro instance and ran 
the following which resulted in the same error
I also received a new error when attempting to get the server agent node to 
report to itself in using *puppet agent -t*. This seems to be caused by the 
pe-puppetdb service not starting. Going backwards here...

*wget 
https://s3.amazonaws.com/pe-builds/released/3.1.1/puppet-enterprise-3.1.1-ubuntu-12.04-amd64.tar.gz
 

 
*

*tar -xzf puppet-enterprise-3.1.1-ubuntu-12.04-amd64.tar.gz*

*cd puppet-enterprise-3.1.1-ubuntu-12.04-amd64/*

*wget 
https://github.com/elcollie/publicscripts/blob/master/puppet.master.answer 
 
*

*Add fog file*

*vim ~/.fog*

*:default:*

* :aws_access_key_id:mykey*

* :aws_secret_access_key:mysecretkey*

*Add swap space 

 
for AWS micro instance*

*sudo /bin/dd if=/dev/zero of=/var/swap.1 bs=1M count=1024*

*sudo /sbin/mkswap /var/swap.1*

*sudo /sbin/swapon /var/swap.1*

*Add AWS internal hostname 
 to hosts 
file*

*sudo vim /etc/hosts*

*127.0.0.1 ip-172-31-15-16*

*sudo shutdown -r now*

*sudo puppet agent -t*

*Warning: Unable to fetch my node definition, but the agent run will 
continue:*

*Warning: Error 400 on SERVER: Could not retrieve facts for 
ec2-54-206-53-139.ap-southeast-2.compute.amazonaws.com: Failed to find 
facts from PuppetDB at 
ec2-54-206-53-139.ap-southeast-2.compute.amazonaws.com:8081: Connection 
refused - connect(2)*

*sudo puppet node_aws list*

*Error: undefined method `reject' for #*
*Error: Try 'puppet help node_aws list' for usage*


Cheers,

Colin

On Friday, 3 January 2014 08:50:54 UTC+11, Justin Stoller wrote:
>
>
>
>
> On Thu, Jan 2, 2014 at 1:23 PM, Colin Cullinan 
> > wrote:
>
>> Hello,
>>
>> I am attempting to manage EC2 instances using Puppet's node_aws but 
>> everytime I run 
>>
>> *~$ sudo puppet node_aws list*
>>
>>
>> I get the following response
>>
>> *Error: undefined method `reject' for #*
>> *Error: Try 'puppet help node_aws list' for usage*
>>
>>
>> I have installed Puppet Enterprise Master 3.3.1 on an AWS EC2 Ubuntu 
>> 12.04 x64 instance in the ap-southeast-2 region (following the instructions 
>> in the first video 
>> here 
>> to 
>> produce an installation answer 
>> file
>> ) 
>> I have also installed Ruby 2.0.0p353, Gem version: 2.1.11 and run the 
>> Cloud Provisioner install as outlined 
>> here
>> .
>>
>> You should follow the installation guide here as cloud provisioner comes 
> with PE:
> http://docs.puppetlabs.com/pe/latest/cloudprovisioner_configuring.html
>
> It seems you have CP installed as a module with a system wide ruby & gems 
> and then it is being used as a plugin by puppet (which has its own ruby). I 
> would try blowing away your CP install and then running the PE installer 
> and selecting the "Install Cloud Provisioner" option.
>
> HTH,
> Justin
>  
>
>> I also configured my ~/.fog file
>>
>> *:default:*
>> * :aws_access_key_id:MYKEY*
>> * :aws_secret_access_key:MYSECRETKEY*
>>
>>
>>  I successfully ran *sudo puppet agent -t* on the server to have its 
>> agent check and appear in the console.
>>
>> Any help would be greatly appreciated.
>>
>> Col
>>  
>> -- 
>> 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/f5ef9764-a003-433f-b037-79d1d82442cb%40googlegroups.com
>> .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

-- 
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/bca9b2b2-14d3-45b6-a73f-6ea66a8ab1f6%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Detect when files are put in a directory? And alternatives?

[Shark Laser]

I'm a puppet newbie but have gone through the tutorial and now read most of 
a book on the subject.(So please tell me if I am approaching the 
problem wrong conceptually).

Problem:   We want a directory where any user can put a file which will 
signify a program that is to be installed by Puppet.   i.e.  If one were to 
go to this special location and do 'touch someSpecialCompileOfApache' then 
Puppet would see the new file in the directory and we would have additional 
logic to then install a special compile of apache.  (just a simple 
contrived example)

The first hurdle seems to be that 'notify' s don't get triggered on a 
directory if files are merely put in the directory.Are my findings here 
correct?   It seems the directory itself would have to change to trigger 
the notify?  ie the name of the directory or a permission?  That seems to 
nix the first attempt.

Assuming I am right so far,   I thought of a second possibly simpler 
approach.   I wanted to have one text file.Each line in the text file 
would contain an entry for a program that was to be installed.   I'm sure I 
can get notify's when the single file is changed.   Is puppet sophisticated 
enough that I could see what the change was in the text file and then 
determine an action based on that?  

Thanks in advance.

-- 
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/7f71bfe0-2310-474b-a55e-f3bf9bfc3bf8%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] node_aws issue: undefined method

[Justin Stoller]

On Thu, Jan 2, 2014 at 1:23 PM, Colin Cullinan  wrote:

> Hello,
>
> I am attempting to manage EC2 instances using Puppet's node_aws but
> everytime I run
>
> *~$ sudo puppet node_aws list*
>
>
> I get the following response
>
> *Error: undefined method `reject' for #*
> *Error: Try 'puppet help node_aws list' for usage*
>
>
> I have installed Puppet Enterprise Master 3.3.1 on an AWS EC2 Ubuntu 12.04
> x64 instance in the ap-southeast-2 region (following the instructions in
> the first video 
> here 
> to
> produce an installation answer 
> file
> )
> I have also installed Ruby 2.0.0p353, Gem version: 2.1.11 and run the
> Cloud Provisioner install as outlined 
> here
> .
>
> You should follow the installation guide here as cloud provisioner comes
with PE:
http://docs.puppetlabs.com/pe/latest/cloudprovisioner_configuring.html

It seems you have CP installed as a module with a system wide ruby & gems
and then it is being used as a plugin by puppet (which has its own ruby). I
would try blowing away your CP install and then running the PE installer
and selecting the "Install Cloud Provisioner" option.

HTH,
Justin


> I also configured my ~/.fog file
>
> *:default:*
> * :aws_access_key_id:MYKEY*
> * :aws_secret_access_key:MYSECRETKEY*
>
>
> I successfully ran *sudo puppet agent -t* on the server to have its agent
> check and appear in the console.
>
> Any help would be greatly appreciated.
>
> Col
>
> --
> 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/f5ef9764-a003-433f-b037-79d1d82442cb%40googlegroups.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

[Puppet Users] node_aws issue: undefined method

[Colin Cullinan]

Hello,

I am attempting to manage EC2 instances using Puppet's node_aws but 
everytime I run 

*~$ sudo puppet node_aws list*


I get the following response

*Error: undefined method `reject' for #*
*Error: Try 'puppet help node_aws list' for usage*


I have installed Puppet Enterprise Master 3.3.1 on an AWS EC2 Ubuntu 12.04 
x64 instance in the ap-southeast-2 region (following the instructions in 
the first video 
here to 
produce an installation answer 
file
) 
I have also installed Ruby 2.0.0p353, Gem version: 2.1.11 and run the Cloud 
Provisioner install as outlined 
here
.

I also configured my ~/.fog file

*:default:*
* :aws_access_key_id:MYKEY*
* :aws_secret_access_key:MYSECRETKEY*


I successfully ran *sudo puppet agent -t* on the server to have its agent 
check and appear in the console.

Any help would be greatly appreciated.

Col

-- 
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/f5ef9764-a003-433f-b037-79d1d82442cb%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] How to do "base" setup in a role/profile configuration

[Jeff Bachtel]

On 01/02/2014 12:11 PM, mjuszc...@gmail.com wrote:
Thanks Jeff.  That all makes sense.  One final question: you suggest 
::site.  Is that literally a module named site?  Or do you often see 
::site replaced with the actual name of the site (IE: dfw01)?  I'd 
think you'd have a ::site module and then use hiera to define the 
actual sites and what values should be placed in each class within 
that module, correct?




Correct, literally a module named site, and correct as well regarding 
using hiera to customize for different sites/environments. There's 
probably a better or more descriptive name to use, that's just what I've 
seen most often. If you like ::general you should roll with it,


Jeff



Thank you!

On Thursday, January 2, 2014 6:47:02 AM UTC-8, Jeff Bachtel wrote:


On 01/01/2014 08:38 PM, mjus...@gmail.com  wrote:
> Hi all,
>
> I have a role/profile setup that's working quite well.  However,
I'm
> finding that there are *super* simple things that don't really
require
> the setup of their own module, such as installing "nano" or
setting up
> a yumrepo {}.  Do I really need an MOTD module?  I have a
> profile::base class which includes things like ::ntp, which because
> it's a daemon and requires monitoring/service statements, etc.
makes
> sense to keep separate.  But do I really need a yum module when I'm
> just calling yumrepo{} or package{} that install a few .rpm
files? And
> for installing general, un-managed packages like bash, nano, etc.,
> surely I shouldn't create a component/module for each of those?  I
> think that'd be overkill.
>
> I've thought about doing a few things.  Perhaps creating a
"general"
> class that includes subclasses, like so:
>
> include general::yum
> include general::motd
>
> Alternatively, inside the puppet "base" profile, I can have the
> include ::ntp statements, and then also add some package{} and
> yumrepo{} statements... but not sure if that's anti role/profile.
>

According to Craig Dunn's original blog post on the role/profile
model,
yes you should be defining modules for motd/yum repos and whatnot.
I've
seen that implemented most often under the ::site namespace, but
::general would work as well. And really, it's for the best if no one
working with your code base has to worry about a ::profile class
defining non-class resources directly. And the time overhead of
writing
"class site::motd { (blah blah)" is only marginally more than
writing it
directly in the profile class.

No one's going to call the Puppet police if you put a yumrepo{} in a
profile class, or create a ::site class that opaquely creates a motd,
sets yumrepo, and installs nano. Eventually you might regret it and
break things out more properly, but "eventually" can be pretty far in
the future. But the level of effort to create a bunch of tiny
::general
classes for piddly stuff is really pretty small, too.

Jeff

> Any thoughts would be appreciated.  Thank you!
>
> -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...@googlegroups.com .
> To view this discussion on the web visit
>

https://groups.google.com/d/msgid/puppet-users/68770970-0fee-4b11-a6d4-8484f3867265%40googlegroups.com

.

> For more options, visit https://groups.google.com/groups/opt_out
.


On Thursday, January 2, 2014 6:47:02 AM UTC-8, Jeff Bachtel wrote:


On 01/01/2014 08:38 PM, mjus...@gmail.com  wrote:
> Hi all,
>
> I have a role/profile setup that's working quite well.  However,
I'm
> finding that there are *super* simple things that don't really
require
> the setup of their own module, such as installing "nano" or
setting up
> a yumrepo {}.  Do I really need an MOTD module?  I have a
> profile::base class which includes things like ::ntp, which because
> it's a daemon and requires monitoring/service statements, etc.
makes
> sense to keep separate.  But do I really need a yum module when I'm
> just calling yumrepo{} or package{} that install a few .rpm
files? And
> for installing general, un-managed packages like bash, nano, etc.,
> surely I shouldn't create a component/module for each of those?  I
> think that'd be overkill.
>
> I've thought about doing a few things.  Perhaps creating a
"general"
> class that includes subclasses, like so:
>
> include general::yum
> include general::motd
>
> Alternatively, inside the puppet "base" profile, I can have t

Re: [Puppet Users] How to do "base" setup in a role/profile configuration

[Ramin K]

On 1/2/2014 6:47 AM, Jeff Bachtel wrote:


On 01/01/2014 08:38 PM, mjuszc...@gmail.com wrote:

Hi all,

I have a role/profile setup that's working quite well.  However, I'm
finding that there are *super* simple things that don't really require
the setup of their own module, such as installing "nano" or setting up
a yumrepo {}.  Do I really need an MOTD module?  I have a
profile::base class which includes things like ::ntp, which because
it's a daemon and requires monitoring/service statements, etc. makes
sense to keep separate.  But do I really need a yum module when I'm
just calling yumrepo{} or package{} that install a few .rpm files? And
for installing general, un-managed packages like bash, nano, etc.,
surely I shouldn't create a component/module for each of those?  I
think that'd be overkill.

I've thought about doing a few things.  Perhaps creating a "general"
class that includes subclasses, like so:

include general::yum
include general::motd

Alternatively, inside the puppet "base" profile, I can have the
include ::ntp statements, and then also add some package{} and
yumrepo{} statements... but not sure if that's anti role/profile.



According to Craig Dunn's original blog post on the role/profile model,
yes you should be defining modules for motd/yum repos and whatnot. I've
seen that implemented most often under the ::site namespace, but
::general would work as well. And really, it's for the best if no one
working with your code base has to worry about a ::profile class
defining non-class resources directly. And the time overhead of writing
"class site::motd { (blah blah)" is only marginally more than writing it
directly in the profile class.

No one's going to call the Puppet police if you put a yumrepo{} in a
profile class, or create a ::site class that opaquely creates a motd,
sets yumrepo, and installs nano. Eventually you might regret it and
break things out more properly, but "eventually" can be pretty far in
the future. But the level of effort to create a bunch of tiny ::general
classes for piddly stuff is really pretty small, too.

Jeff


I nearly lost a keyboard to coffee and "the Puppet police" this morning. 
Nice job. :-)


	I agree with Jeff that whatever works for you is fine. If it makes the 
most sense now, you should write it, push it, and move on to getting 
more work done. You may change your mind later and refactor, but that's 
a fact of life in any living code base.


	However I believe there are some organizational benefits to one module 
being the least amount of code. This keeps the module(one use) -> 
profile(many modules) -> role(many profiles) relationship intact. It 
should also make your code easier to read and reason about.
	Simpler modules will keep you from mixing logic between uses. If module 
motd is seperate from module yum you're unlikely to create accidental 
dependencies. Admittedly I can't think of any way deps could be created 
between those two examples.
	The other advantage of individual modules is that they are easier to 
extend. Your yum module today might be just repos, but tomorrow it might 
install assorted yum-* plugins, need to makecache, etc.


Ramin

--
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/52C5A6AA.5020007%40badapple.net.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] How to do "base" setup in a role/profile configuration

[mjuszczak]

Thanks Jeff.  That all makes sense.  One final question: you suggest 
::site.  Is that literally a module named site?  Or do you often see ::site 
replaced with the actual name of the site (IE: dfw01)?  I'd think you'd 
have a ::site module and then use hiera to define the actual sites and what 
values should be placed in each class within that module, correct?

Thank you!

On Thursday, January 2, 2014 6:47:02 AM UTC-8, Jeff Bachtel wrote:
>
>
> On 01/01/2014 08:38 PM, mjus...@gmail.com  wrote: 
> > Hi all, 
> > 
> > I have a role/profile setup that's working quite well.  However, I'm 
> > finding that there are *super* simple things that don't really require 
> > the setup of their own module, such as installing "nano" or setting up 
> > a yumrepo {}.  Do I really need an MOTD module?  I have a 
> > profile::base class which includes things like ::ntp, which because 
> > it's a daemon and requires monitoring/service statements, etc. makes 
> > sense to keep separate.  But do I really need a yum module when I'm 
> > just calling yumrepo{} or package{} that install a few .rpm files? And 
> > for installing general, un-managed packages like bash, nano, etc., 
> > surely I shouldn't create a component/module for each of those?  I 
> > think that'd be overkill. 
> > 
> > I've thought about doing a few things.  Perhaps creating a "general" 
> > class that includes subclasses, like so: 
> > 
> > include general::yum 
> > include general::motd 
> > 
> > Alternatively, inside the puppet "base" profile, I can have the 
> > include ::ntp statements, and then also add some package{} and 
> > yumrepo{} statements... but not sure if that's anti role/profile. 
> > 
>
> According to Craig Dunn's original blog post on the role/profile model, 
> yes you should be defining modules for motd/yum repos and whatnot. I've 
> seen that implemented most often under the ::site namespace, but 
> ::general would work as well. And really, it's for the best if no one 
> working with your code base has to worry about a ::profile class 
> defining non-class resources directly. And the time overhead of writing 
> "class site::motd { (blah blah)" is only marginally more than writing it 
> directly in the profile class. 
>
> No one's going to call the Puppet police if you put a yumrepo{} in a 
> profile class, or create a ::site class that opaquely creates a motd, 
> sets yumrepo, and installs nano. Eventually you might regret it and 
> break things out more properly, but "eventually" can be pretty far in 
> the future. But the level of effort to create a bunch of tiny ::general 
> classes for piddly stuff is really pretty small, too. 
>
> Jeff 
>
> > Any thoughts would be appreciated.  Thank you! 
> > 
> > -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...@googlegroups.com . 
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/puppet-users/68770970-0fee-4b11-a6d4-8484f3867265%40googlegroups.com.
>  
>
> > For more options, visit https://groups.google.com/groups/opt_out. 
>
>
On Thursday, January 2, 2014 6:47:02 AM UTC-8, Jeff Bachtel wrote:
>
>
> On 01/01/2014 08:38 PM, mjus...@gmail.com  wrote: 
> > Hi all, 
> > 
> > I have a role/profile setup that's working quite well.  However, I'm 
> > finding that there are *super* simple things that don't really require 
> > the setup of their own module, such as installing "nano" or setting up 
> > a yumrepo {}.  Do I really need an MOTD module?  I have a 
> > profile::base class which includes things like ::ntp, which because 
> > it's a daemon and requires monitoring/service statements, etc. makes 
> > sense to keep separate.  But do I really need a yum module when I'm 
> > just calling yumrepo{} or package{} that install a few .rpm files? And 
> > for installing general, un-managed packages like bash, nano, etc., 
> > surely I shouldn't create a component/module for each of those?  I 
> > think that'd be overkill. 
> > 
> > I've thought about doing a few things.  Perhaps creating a "general" 
> > class that includes subclasses, like so: 
> > 
> > include general::yum 
> > include general::motd 
> > 
> > Alternatively, inside the puppet "base" profile, I can have the 
> > include ::ntp statements, and then also add some package{} and 
> > yumrepo{} statements... but not sure if that's anti role/profile. 
> > 
>
> According to Craig Dunn's original blog post on the role/profile model, 
> yes you should be defining modules for motd/yum repos and whatnot. I've 
> seen that implemented most often under the ::site namespace, but 
> ::general would work as well. And really, it's for the best if no one 
> working with your code base has to worry about a ::profile class 
> defining non-class resources directly. And the time overhead of writing 
> "class site::motd { (blah blah)" is only marginal

[Puppet Users] Re: Run stages of virtual resources

[jcbollinger]

On Thursday, January 2, 2014 2:18:06 AM UTC-6, james.e...@fasthosts.com 
wrote:
>
> How about chaining the resources, ala 
> http://docs.puppetlabs.com/puppet/2.7/reference/lang_relationships.html#chaining-arrows
> .
>
> Yumrepo <| |> -> Package<| |>
>
> This declared in site.pp should apply globally to all nodes and would 
> avoid the use of run stages (if I understand it correctly).
>
>
It would indeed avoid the stated need for run stages.  It would also, 
however, realize every virtual Yumrepo and every virtual Package declared 
for each node, which is contrary to David's intent and purpose.

It might be possible to declare tags on repos, and on packages if 
necessary, and to use them to filter the repositories to be realized and 
chained.  However, if the use of stages is restricted to applying Yumrepos 
first then I think that would be clean and reasonably safe.  I say this as 
a person who is not particularly enamored of run stages in general.


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/f14dbfd8-4abd-4504-a6b3-e1e8d9030632%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: Run stages of virtual resources

[jcbollinger]

On Tuesday, December 31, 2013 10:47:33 AM UTC-6, David Arroyo wrote:
>
> Our site has several dozen yum repositories. Pushing all yum repositories 
> to all servers isn't practical; it hurts performance, some repositories are 
> OS-specific, and some repositories cause conflicts with each other (we have 
> a ruby187 repo and a ruby 193 repo, for example). 
>
> In our current setup, we have one module with all our yumrepos defined 
> virtually: 
>
> class yumrepos { 
>   @yumrepo{'puppet': 
> … 
>   } 
>   @yumrepo{'python26': 
> … 
>   } 
>   … 
> } 
>
> And our various modules realize those resources as needed: 
>
> class puppet(...) { 
>   realize Yumrepo['puppet'] 
>   … 
> } 
>
> However, this requires every package definition to require the Yumrepo 
> resource. I can ease the pain with resource defaults, but it doesn't go 
> away completely. I have found on puppet 2.7 that virtual resources are 
> evaluated in the run stage they are defined in, not the run stage they are 
> realized in, so that I can do in site.pp: 
>
> stage{'package-setup': before => Stage['main'] } 
> class{'yumrepos': stage => 'package-setup' } 
>
> Then all yum repositories that a node will use are on the machine before 
> any packages are installed. Is this a kosher use of run stages?



It is exactly the sort of thing that run stages are intended for.

 

> Am I going to be surprised by something I didn't consider? I have only 
> tested this behavior in Puppet 2.7 and don't know if it is subject to 
> change in later releases. How do others handle this problem? 
>
>

Run stages remain available in Puppet 3, and I see no reason to fear that 
they will go away in the foreseeable future.  As for surprises, however, 
you are wise to be wary.  Run stages are a pretty heavy tool, and they can 
indeed cause trouble if used carelessly or excessively.  The most common 
form of trouble they are involved in is resource dependency cycles, and 
that might happen even in your limited use if you have repositories that 
are managed via packages.  With care and restraint, however, it should be 
possible to use run stages as you suggest.


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/9266523c-d11b-47d2-a99b-24dc8b2d8ddd%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Roles/profile design

[jcbollinger]

On Thursday, December 26, 2013 12:25:38 PM UTC-6, Joseph Swick wrote:
>
> On 12/26/2013 12:48 PM, Josh wrote: 
> > Joseph, 
> > 
> > So, the problem with this method appears to be that once you specify 
> > "hiera_include('classes')" in the environment's site.pp, Puppet appears 
> to 
> > try and make Hiera the ONLY source for node classification.  I rely on 
> > roles from my ENC and profiles for classification as well. 
> > 
> > Josh 
> > 
>
> That's certainly another gotcha with hiera and classes that's good to 
> know.  We went to using hiera exclusively for our node classification, 
> so we didn't run into that issue as we're not using any other ENCs with 
> our current configuration. 
>
>

It's good to know only if it's in fact true.  The hiera_include() function 
is simply a wrapper around Puppet's 'include' function that selects the 
classes to include via an hiera() lookup.  (Look for yourself if you don't 
believe me: 
https://github.com/puppetlabs/puppet/blob/master/lib/puppet/parser/functions/hiera_include.rb
 
.)  Neither hiera_include() nor the underlying include() function 
inherently interferes with classification via ENC (or node block).

With that said, I like hiera for node classification, and I think there's 
much to be said for using only hiera for that purpose.


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/ae9a7242-0d7a-49e9-859a-e9991ac3f9ff%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: Puppet getting "Cannot allocate memory - fork(2)" error. Running without puppetmaster

[jcbollinger]

On Monday, December 23, 2013 2:48:31 AM UTC-6, Shay Lavi wrote:
>
> Hi,
> I'm running puppet on Centos VM server without puppet agent (and no 
> puppetmaster) just by using puppet apply.
> Lately i'm getting error while try to run puppet: "Cannot allocate memory 
> - fork(2)"
> By looking at the server memory consumption I can see the the ruby is 
> using a lot of memory until no more memory is available.
> I tried to overcome this by:
> 1) Increasing memory
> 2) Reinstall puppet
>
> These solutions didn't last long and the error returned.
> Any idea how to fix this?
>
> I'm using *puppet 3.3.2* and *ruby 1.9.2*
>
>

You could try running the agent periodically via a scheduler (such as cron) 
instead of running it in daemon mode.  You would want to pass at least the 
--no-daemonize flag to the agent in that context.  That should help if the 
problem involves Puppet / Ruby accumulating unneeded garbage from run to 
run.

You may also want to look at what you are trying to manage.  Does it 
include recursive File resources spanning large directory trees?  Does it 
include very large Files?  Does it include extremely large total numbers of 
resources?  Such things could inflate Puppet's memory use, and there are 
alternatives to many of them.


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/378d2e97-e973-408a-a6d2-75ef72c6f5d2%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: triggering 'apt-get update'?

[jcbollinger]

On Friday, December 20, 2013 9:58:33 AM UTC-6, Jon Yeargers wrote:
>
> I'm using the puppetforge 'apt' module to deal with some repositories. It 
> has 'always-apt-update' as a property and I've had it set to 'true' but I'm 
> wondering what happens if I don't. 
>
>

There are at least 8 'apt' modules by different authors available from the 
Forge.  By far the most commonly used one is puppetlabs's own, and its 
'apt' class does have a parameter such as you describe, so I will guess 
that that's the one you are using.

 

> Is the puppet package manager 'smart' enough to get the latest versions of 
> packages that it's monitoring ('ensure => latest') without being told to 
> keep the repository up to date?
>
> The main reason I'm asking is that the 'apt-get update' seems to always 
> run last in the 'agent' pass. IE it takes two runs to get the latest 
> packages - 1 to update the cache and the 2nd to get the latest versions. 
>


Puppet does not enforce any particular relative order of resource 
synchronization except to the extent you instruct it to do so.  Now you 
just need to instruct Puppet to manage Apt itself before it manages any 
packages that rely on Apt.  Stefan has a good suggestion there, but it 
suffers from a minor problem: in referring to resource Exec['apt_update'] 
it depends on implementation details of a particular 'apt' module.  It 
should be sufficient, at least for the puppetlabs-apt module, to instead say

Class['apt'] -> Package<| |>

That may appear at the top level of site.pp if you are managing only 
machines that rely on Apt; otherwise it should go into one or more classes 
or node blocks so that all apt-based machines get that declaration 
somewhere in their configurations.


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/70814371-ff92-40bc-b162-2ca3cabeb8d5%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Re: Problem using hiera-eyaml

[Kit Plummer]

Hey Werner.

I just added the 'read' permission to the global setting on the installed
gems' directories after the 'gem install' command.  I had to do it for
hiera-eyaml and the gems that were installed with it.

Kit.
On Jan 2, 2014 8:39 AM, "Werner Bahlke"  wrote:

> Hi Kit,
>
> I am glad you found the cause. Can you tell me a bit more how you resolved
> it? I probably can figure it out eventually but any hints will be greatly
> appreciated.
>
> Thanks,
>
> Werner
>
>
> On Mon, Dec 30, 2013 at 11:17 AM, Kit Plummer wrote:
>
>> Hey Werner.  I did resolve my issue.  It turned out to be a path issue,
>> with how the PE’s rubygems installs gems.  While the eyaml commands were
>> working, the directory for the hiera-eyaml (and it’s dependent gems) didn’t
>> allow the pe-puppet user (global perms) to get to the lib .rb files in the
>> installed gems.
>>
>> It’s a bug and I need to remember to file it.
>>
>> Kit
>>
>>
>> --
>> From: wernerbahlke werner.bah...@gmail.com
>> Reply: puppet-users@googlegroups.com puppet-users@googlegroups.com
>> Date: December 30, 2013 at 9:12:48 AM
>> To: puppet-users@googlegroups.com puppet-users@googlegroups.com
>> Subject:  [Puppet Users] Re: Problem using hiera-eyaml
>>
>> >
>> > Hi Kit,
>> >
>> > Thanks for posting. No, I did not resolve it and have put it on the
>> > back
>> > burner. Quite possible that it is a Ruby / gems issue.
>> >
>> > Keep us posted if you resolve it before me.
>> >
>> > Werner
>> >
>> > On Saturday, December 21, 2013 11:13:46 AM UTC-5, Kit Plummer
>> > wrote:
>> > >
>> > > Did you resolve this?
>> > >
>> > > I'm having a similar problem. But, I think it is because the eyaml
>> > > backend isn't getting loaded :) :
>> > >
>> > > "Cannot load backend eyaml: cannot load such file --
>> > > hiera/backend/eyaml_backend"
>> > >
>> > > I'm wondering if this is because the Ruby version/Gems that
>> > are used by PE.
>> > >
>> > > On Friday, December 6, 2013 8:10:35 AM UTC-7, wernerbahlke
>> > wrote:
>> > >>
>> > >> I am trying to use hiera-eyaml and have followed the README
>> > instructions.
>> > >>
>> > >> eyaml seems to work, I can encrypt and decrypt files and passwords.
>> > >>
>> > >> I can also use hiera -c to get at an encrypted value like so:
>> > >>
>> > >> hiera -c /etc/puppetlabs/puppet/hiera.yaml rootpwd
>> > >>
>> > >> But when running this simple test module it fails with cannot
>> > find the
>> > >> data item rootpwd defined in hieradata/defaults.eyaml.
>> > >>
>> > >> class test {
>> > >> $test = hiera('test')
>> > >> $rootpwd = hiera('rootpwd')
>> > >> notify { "Test: ${test}": }
>> > >> }
>> > >> If I just have the test variable defined in defaults.yaml it
>> > works fine.
>> > >> So it cannot find the defaults.eyaml file.
>> > >>
>> > >> Here is my hiera.yaml:
>> > >> --
>> > >>
>> > >> :backends:
>> > >>
>> > >> - yaml
>> > >> - eyaml
>> > >> - :hierarchy:
>> > >> - defaults
>> > >> - "%{clientcert}"
>> > >> - "%{environment}"
>> > >> - global
>> > >> - :yaml: :datadir: /etc/puppetlabs/puppet/modules/hieradata
>> > >> - :eyaml: :datadir: /etc/puppetlabs/puppet/modules/hieradata
>> > >> - :pkcs7_private_key:
>> > >> /etc/puppetlabs/puppet/secure/keys/private_key.pkcs7.pem
>> > >> - :pkcs7_public_key:
>> > >> /etc/puppetlabs/puppet/secure/keys/public_key.pkcs7.pem
>> > >>
>> > >> And my defaults.eyaml file:
>> > >> --
>> > >>
>> > >> rootpwd: >
>> > >>
>> ENC[PKCS7,MIIBeQYJKoZIhvcNAQcDoIIBajCCAWYCAQAxggEhMIIBHQIBADAFMAACAQAwDQYJKoZIhvcNAQE
>> > >> ...]
>> > >> Any hints will be greatly appreciated.
>> > >>
>> > >> I am running Puppet Enterprise 3.1.0 on Ubuntu 12.04.
>> > >>
>> > >
>> >
>> > --
>> > You received this message because you are subscribed to a topic
>> > in the Google Groups "Puppet Users" group.
>> > To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/puppet-users/qpia1_TR2dI/unsubscribe.
>> > To unsubscribe from this group and all its topics, 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/eed4dd1d-6fc0-4538-b1c5-1621f78ab509%40googlegroups.com
>> .
>> > For more options, visit https://groups.google.com/groups/opt_out.
>> >
>>
>>
>
>
> --
> *Werner Bahlke   | T: 503-438-9466
> <503-438-9466> | Skype: wernerbahlke*
>  
>

-- 
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/CAHUyvnpTnWsKH3Wu0rMVJ_ZK9tvKyEJ%3DBhOG6%2BYrzHndxAmLaA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Re: Problem using hiera-eyaml

[Werner Bahlke]

Hi Kit,

I am glad you found the cause. Can you tell me a bit more how you resolved
it? I probably can figure it out eventually but any hints will be greatly
appreciated.

Thanks,

Werner


On Mon, Dec 30, 2013 at 11:17 AM, Kit Plummer  wrote:

> Hey Werner.  I did resolve my issue.  It turned out to be a path issue,
> with how the PE’s rubygems installs gems.  While the eyaml commands were
> working, the directory for the hiera-eyaml (and it’s dependent gems) didn’t
> allow the pe-puppet user (global perms) to get to the lib .rb files in the
> installed gems.
>
> It’s a bug and I need to remember to file it.
>
> Kit
>
>
> --
> From: wernerbahlke werner.bah...@gmail.com
> Reply: puppet-users@googlegroups.com puppet-users@googlegroups.com
> Date: December 30, 2013 at 9:12:48 AM
> To: puppet-users@googlegroups.com puppet-users@googlegroups.com
> Subject:  [Puppet Users] Re: Problem using hiera-eyaml
>
> >
> > Hi Kit,
> >
> > Thanks for posting. No, I did not resolve it and have put it on the
> > back
> > burner. Quite possible that it is a Ruby / gems issue.
> >
> > Keep us posted if you resolve it before me.
> >
> > Werner
> >
> > On Saturday, December 21, 2013 11:13:46 AM UTC-5, Kit Plummer
> > wrote:
> > >
> > > Did you resolve this?
> > >
> > > I'm having a similar problem. But, I think it is because the eyaml
> > > backend isn't getting loaded :) :
> > >
> > > "Cannot load backend eyaml: cannot load such file --
> > > hiera/backend/eyaml_backend"
> > >
> > > I'm wondering if this is because the Ruby version/Gems that
> > are used by PE.
> > >
> > > On Friday, December 6, 2013 8:10:35 AM UTC-7, wernerbahlke
> > wrote:
> > >>
> > >> I am trying to use hiera-eyaml and have followed the README
> > instructions.
> > >>
> > >> eyaml seems to work, I can encrypt and decrypt files and passwords.
> > >>
> > >> I can also use hiera -c to get at an encrypted value like so:
> > >>
> > >> hiera -c /etc/puppetlabs/puppet/hiera.yaml rootpwd
> > >>
> > >> But when running this simple test module it fails with cannot
> > find the
> > >> data item rootpwd defined in hieradata/defaults.eyaml.
> > >>
> > >> class test {
> > >> $test = hiera('test')
> > >> $rootpwd = hiera('rootpwd')
> > >> notify { "Test: ${test}": }
> > >> }
> > >> If I just have the test variable defined in defaults.yaml it
> > works fine.
> > >> So it cannot find the defaults.eyaml file.
> > >>
> > >> Here is my hiera.yaml:
> > >> --
> > >>
> > >> :backends:
> > >>
> > >> - yaml
> > >> - eyaml
> > >> - :hierarchy:
> > >> - defaults
> > >> - "%{clientcert}"
> > >> - "%{environment}"
> > >> - global
> > >> - :yaml: :datadir: /etc/puppetlabs/puppet/modules/hieradata
> > >> - :eyaml: :datadir: /etc/puppetlabs/puppet/modules/hieradata
> > >> - :pkcs7_private_key:
> > >> /etc/puppetlabs/puppet/secure/keys/private_key.pkcs7.pem
> > >> - :pkcs7_public_key:
> > >> /etc/puppetlabs/puppet/secure/keys/public_key.pkcs7.pem
> > >>
> > >> And my defaults.eyaml file:
> > >> --
> > >>
> > >> rootpwd: >
> > >>
> ENC[PKCS7,MIIBeQYJKoZIhvcNAQcDoIIBajCCAWYCAQAxggEhMIIBHQIBADAFMAACAQAwDQYJKoZIhvcNAQE
> > >> ...]
> > >> Any hints will be greatly appreciated.
> > >>
> > >> I am running Puppet Enterprise 3.1.0 on Ubuntu 12.04.
> > >>
> > >
> >
> > --
> > You received this message because you are subscribed to a topic
> > in the Google Groups "Puppet Users" group.
> > To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/puppet-users/qpia1_TR2dI/unsubscribe.
> > To unsubscribe from this group and all its topics, 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/eed4dd1d-6fc0-4538-b1c5-1621f78ab509%40googlegroups.com
> .
> > For more options, visit https://groups.google.com/groups/opt_out.
> >
>
>


-- 
*Werner Bahlke   | T: 503-438-9466 | Skype:
wernerbahlke*


-- 
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/CAGc9q-jH8PhvKHNqEq2w7mTrVgJDjOA4evzb__x%3DVN4o3oQGRw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Re: Debugging execution error with vcsrepo

[jcbollinger]

On Wednesday, December 25, 2013 9:47:39 AM UTC-6, Felix.Frank wrote:
>
> Hi, 
>
> for what it's worth - the error seems to indicate that su considers 
> "/usr/local/bin/git config remote.origin.url" to be the name of an 
> executable file that contains a space. 
>


I agree that it looks like the whole command argument is being interpreted 
as a file name, but unless the su in question is very different from GNU 
su, that mistake is probably being committed by whatever shell su starts, 
not by su itself.  It is the shell's job to parse the command.  That 
distinction could be very important to tracing down the error.

According to its docs, GNU su uses the shell specified in the target user's 
passwd entry, falling back to /bin/sh if none is specified.  If the target 
user in this case has some weird shell configured, then perhaps it parses 
commands unfavorably.  On the other hand, if the user's shell is anything 
from the Bourne family (e.g. bash or zsh) then I would be inclined to guess 
that there is a problem related to the IFS environment variable.  On the 
third hand, [t]csh always splits words at blanks and tabs, so the problem I 
hypothesize should not occur if that's the configured shell.

I cannot speak directly to the environment Puppet provides to the su 
command, but in general Puppet provides a minimal environment to commands 
it spawns.


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/78e749a4-bffc-48b5-9885-10cd344f22f7%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] How to do "base" setup in a role/profile configuration

[Jeff Bachtel]

On 01/01/2014 08:38 PM, mjuszc...@gmail.com wrote:

Hi all,

I have a role/profile setup that's working quite well.  However, I'm 
finding that there are *super* simple things that don't really require 
the setup of their own module, such as installing "nano" or setting up 
a yumrepo {}.  Do I really need an MOTD module?  I have a 
profile::base class which includes things like ::ntp, which because 
it's a daemon and requires monitoring/service statements, etc. makes 
sense to keep separate.  But do I really need a yum module when I'm 
just calling yumrepo{} or package{} that install a few .rpm files? And 
for installing general, un-managed packages like bash, nano, etc., 
surely I shouldn't create a component/module for each of those?  I 
think that'd be overkill.


I've thought about doing a few things.  Perhaps creating a "general" 
class that includes subclasses, like so:


include general::yum
include general::motd

Alternatively, inside the puppet "base" profile, I can have the 
include ::ntp statements, and then also add some package{} and 
yumrepo{} statements... but not sure if that's anti role/profile.




According to Craig Dunn's original blog post on the role/profile model, 
yes you should be defining modules for motd/yum repos and whatnot. I've 
seen that implemented most often under the ::site namespace, but 
::general would work as well. And really, it's for the best if no one 
working with your code base has to worry about a ::profile class 
defining non-class resources directly. And the time overhead of writing 
"class site::motd { (blah blah)" is only marginally more than writing it 
directly in the profile class.


No one's going to call the Puppet police if you put a yumrepo{} in a 
profile class, or create a ::site class that opaquely creates a motd, 
sets yumrepo, and installs nano. Eventually you might regret it and 
break things out more properly, but "eventually" can be pretty far in 
the future. But the level of effort to create a bunch of tiny ::general 
classes for piddly stuff is really pretty small, too.


Jeff


Any thoughts would be appreciated.  Thank you!

-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/68770970-0fee-4b11-a6d4-8484f3867265%40googlegroups.com.

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


--
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/52C57BE6.7040601%40bericotechnologies.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] wondering if I want to much now.

[Jelle B.]

Hi all,

I have been kinda stuck  with the following few issues (all related to one 
and other)

What I want ot ddo is define a couple of standard actions in puppet that I 
can use across all my classes.
So for example I define a exec for apt-get update , or a reload. When built 
in to a class it works fine I would just have to redeclare it with an other 
name in the next class and I want to get away from it.

Now I have started working on importing it via my site.pp but I can not 
define say the exec for "service $service_name reload", it will generate an 
error when I include it : Must pass service_name to Class[Defaults] (class 
defaults being the collective class I brought all these snippets together)

So question one am I on the right path in creating this , using the top 
scope prinocipal in my design for this.

Second question how do I pass a variable in this setup , as I can not 
include the class in site.pp as it will generate the "must pass error" but 
just doing an import in my site.pp and then an include in my module init.pp 
does not actually work either but then silentlly. 

I am missing somethign I think just not sure what and where .

Here below the code snippets of what I am doing.

site.pp in /etc/puppet/environments/dev/manifests/
Exec { path => [ "/bin/", "/sbin/" , "/usr/bin/", "/usr/sbin/" ] }

import 'classes/*.pp'

the defaults.pp with the class from 
/etc/puppet/environments/dev/manifests/classes/ :
class defaults ( $service_name ){

case $::operatingsystem {
debian, ubuntu: {
exec { "apt update":
command => "/usr/bin/apt-get update",
#   onlyif => < snipped >
}
}
}

exec { "reload":
command => "/usr/sbin/service $service_name reload",
refreshonly => true,
require => Service[[$service_name]],
}

exec { "restart":
command => "/usr/sbin/service $service_name restart",
refreshonly => true,
require => Service[[$service_name]],
}


}

And the class calling it from 
/etc/puppet/environments/dev/modules/pdns/init.pp

include defaults

class pdns_33 ( $mysql_password, $srv_type, $web_password ) {
<-- snipped -->
   file { "/etc/powerdns/pdns.conf":
ensure => present,
owner => root,
group => root,
mode => 644,
content => template("pdns_33/pdns.conf.erb"),
notify => Exec[[reload]],
}
<-- snipped -->

-- 
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/a23685a3-4f2b-4abb-a7e0-6a20c7eb0323%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Provider must have features 'manages_symlinks' to set 'ensure' to 'link' shouldn't happen on Linux?

[Steph Gosling]

Hi, 

On Tuesday, December 31, 2013 1:33:25 PM UTC, jmslagle wrote:
>
>
>
>
> Out of curiosity, do you have both a package and the gem installed? 
> I've seen this behavior when the package got updated, but the gem was 
> still an older version.  Also make sure you bounce the master if the 
> package got upgraded. 
>
> Jason 
>

Jason you're a star. Gem said I had the puppet 3.2.1 gem installed as 
well and on removal that sorted the issue. As to why that was there I'm 
not sure but at this stage I'd put money on it being PEBKAC thing 
rather than a packaging issue.

Thank you again for the suggestion.

Cheers,

Steph

-- 
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/cc109a80-d77a-4b6c-92eb-6c27aeaa68e9%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: Run stages of virtual resources

[james . eckersall]

How about chaining the resources, ala 
http://docs.puppetlabs.com/puppet/2.7/reference/lang_relationships.html#chaining-arrows
.

Yumrepo <| |> -> Package<| |>

This declared in site.pp should apply globally to all nodes and would avoid 
the use of run stages (if I understand it correctly).

J

On Tuesday, 31 December 2013 16:47:33 UTC, David Arroyo wrote:
>
> Our site has several dozen yum repositories. Pushing all yum repositories 
> to all servers isn't practical; it hurts performance, some repositories are 
> OS-specific, and some repositories cause conflicts with each other (we have 
> a ruby187 repo and a ruby 193 repo, for example). 
>
> In our current setup, we have one module with all our yumrepos defined 
> virtually: 
>
> class yumrepos { 
>   @yumrepo{'puppet': 
> … 
>   } 
>   @yumrepo{'python26': 
> … 
>   } 
>   … 
> } 
>
> And our various modules realize those resources as needed: 
>
> class puppet(...) { 
>   realize Yumrepo['puppet'] 
>   … 
> } 
>
> However, this requires every package definition to require the Yumrepo 
> resource. I can ease the pain with resource defaults, but it doesn't go 
> away completely. I have found on puppet 2.7 that virtual resources are 
> evaluated in the run stage they are defined in, not the run stage they are 
> realized in, so that I can do in site.pp: 
>
> stage{'package-setup': before => Stage['main'] } 
> class{'yumrepos': stage => 'package-setup' } 
>
> Then all yum repositories that a node will use are on the machine before 
> any packages are installed. Is this a kosher use of run stages? Am I going 
> to be surprised by something I didn't consider? I have only tested this 
> behavior in Puppet 2.7 and don't know if it is subject to change in later 
> releases. How do others handle this problem? 
>
> -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/8d9ab53a-8f85-4646-baac-ebadd693a094%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.