[Puppet Users] Puppet Agent not sync with Puppet Master

[Saravanan Veeran]

Dear Team,

Currently, we have deployed "puppet-enterprise-2.6.0-el-6-x86_64" in our 
environment.
Master Details: Red Hat Enterprise Linux Server release 6.1 (Santiago) 
x86_64. 
We have installed the Master as per instructions and it is working fine. 

We installed a windows package(puppet-enterprise-2.6.1) in Agent system.
Agent Details: Windows Server 2008 R2(64 bit). It is added to domain 
"coetools.com".

When I'm running "Run Puppet Agent" in agent machine. I'm getting the 
following error. *

Running Puppet agent on demand ...
err: Could not request certificate: getaddrinfo: The storage control blocks 
were destroyed.
Exiting; failed to retrieve certificate and waitforcert is disabled
Press any key to continue . . .*

I referred the following link.
http://docs.puppetlabs.com/windows/troubleshooting.html#installation

They have said like below.
This error can occur when the agent cannot resolve a DNS name into an IP 
address (for example the server, ca_server, etc properties).

In the agent machine, 
While installation, I have mentioned the IP for Puppet Master hostname.
In host file, I have mentioned the Master machine with IP and fqdn.
In network configuration, 1st dns is the IP of the domain(coetools.com). 
2nd dns is the IP of the Puppet master.

In the Master machine,
This is my host file configuration.
*127.0.0.1   localhost localhost.coetools.com
172.19.77.93 PuppetCOE PuppetCOE.coetools.com*

In order to sync the agent with the Master, I'm giving the "Run Puppet 
Agent" in windows machine. It shows the above mentioned error.
So, I'm not getting the agent list when I'm giving the *"puppet cert list*" 
command in Master in order to proceed.

Is this the problem with the hostfile? DNS issue? I have mentioned the host 
files FYI. Please guide me on the same.

Thank You.

With Regards,
Saravanan V

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/H-sGvqffsZEJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: puppet instllation error

[Saravanan Veeran]

This webpage has a redirect loop
I also had the same problem. The RC is with the hostname in hosts file.
Change your host name in /etc/hosts with fqdn. 
That's it.
Now, the redirection won't happen.

Regards,
VSARA90

On Tuesday, 2 October 2012 01:25:08 UTC+5:30, skrishna12 wrote:
>
> Can you  any one let me know  what could be the issue on this?
>
>
> On Friday, September 28, 2012 3:56:53 PM UTC-7, skrishna12 wrote:
>>
>> I tried the credential (mail id and password) stored in answer.lastun.xxx 
>>  and got the following error. Even after clearing the cookies and caches .. 
>> no luck with  the mail id and password 
>>
>>
>> This webpage has a redirect loop
>> The webpage at *
>> https://puppet-master.etouch.net:3000/?ticket=ST-1348829403r7DD1A83EF03491318C
>> * has resulted in too many redirects. Clearing your cookies for this 
>> site or allowing third-party cookies may fix the problem. If not, it is 
>> possibly a server configuration issue and not a problem with your computer.
>> Here are some suggestions:
>>
>>- 
>> Reload
>>  this 
>>webpage later.
>>- Learn 
>> more
>>  about 
>>this problem.
>>
>> Error 310 (net::ERR_TOO_MANY_REDIRECTS): There were too many redirects.
>>
>> On Friday, September 28, 2012 2:37:39 PM UTC-7, Matthaus Litteken wrote:
>>>
>>> Glad that helped you get through the installation. The installer 
>>> should have asked you those questions during the interview, and they 
>>> are saved in the answers file as well. 
>>>
>>> The console admin user and password will be in the 
>>> puppet-enterprise-2.6.0-el5-x86_64 directory (wherever you have the 
>>> installer located) in a file named answers.lastrun. 
>>> (which for you will be 'answers.lastrun.puppet-master.etouch.net') 
>>>
>>> The answers you need to look for in that file are: 
>>>
>>> q_puppet_enterpriseconsole_auth_password= 
>>> q_puppet_enterpriseconsole_auth_user_email= 
>>>
>>> HTH 
>>>
>>> On Fri, Sep 28, 2012 at 2:16 PM, skrishna12  wrote: 
>>> > The  auto generated user name password is here 
>>> > 
>>> > # cat  etc/puppetlabs/installer/database_info.install 
>>> > 
>>> > q_puppet_enterpriseconsole_auth_database_name=console_auth 
>>> > q_puppet_enterpriseconsole_auth_database_password=c8ZwU6TVlgcdvTA5ysv6 
>>> > q_puppet_enterpriseconsole_auth_database_user=console_auth 
>>> > q_puppet_enterpriseconsole_database_install=n 
>>> > q_puppet_enterpriseconsole_database_name=console 
>>> > q_puppet_enterpriseconsole_database_password=2kjrLEVGna95KXQPHac3 
>>> > q_puppet_enterpriseconsole_database_remote=n 
>>> > q_puppet_enterpriseconsole_database_root_password=eTouch6789 
>>> > q_puppet_enterpriseconsole_database_user=console 
>>> > 
>>> > thanks 
>>> > 
>>> > On Friday, September 28, 2012 2:13:32 PM UTC-7, skrishna12 wrote: 
>>> >> 
>>> >> Thanks!! 
>>> >> I removed all  mysql pkg and reinstall PE . I got the following 
>>> messages. 
>>> >> I can see admin console but not sure about the username and passwd. 
>>> This 
>>> >> time when i installed . the installer didnot ask any console username 
>>> and 
>>> >> password. Pls  help me this out 
>>> >> 
>>> >> 
>>> >> 
>>> >> Puppet Enterprise has been installed to "/opt/puppet," and its 
>>> >> configuration files are located in "/etc/puppetlabs". 
>>> >> ## Answers from this session saved to 
>>> >> './answers.lastrun.puppet-master.etouch.net' 
>>> >> ## In addition, auto-generated database users and passwords, 
>>> including the 
>>> >> ROOT MySQL password, have been saved to 
>>> >> "/etc/puppetlabs/installer/database_info.install" 
>>> >>!!! WARNING: Do not discard these files! All auto-generated 
>>> database 
>>> >> users and passwords, including the ROOT Mysql password, have been 
>>> saved in 
>>> >> them. 
>>> >> 
>>> >> 
>>> =
>>>  
>>>
>>> >> 
>>> >> The console can be reached at the following URI: 
>>> >>  *  https://puppet-master.etouch.net:3000 
>>> >> 
>>> >>If you have a firewall running, please ensure the following TCP 
>>> ports 
>>> >> are open: 8140, 61613, 3000 
>>> >>NOTICE: This system has 1.96 GB of memory, which is below the 4 GB 
>>> we 
>>> >> recommend for the puppet master role. Although this node will be a 
>>> fully 
>>> >>functional puppet master, you may experience poor performance with 
>>> >> large numbers of nodes. You can improve the puppet master's 
>>> performance by 
>>> >>increasing its memory. 
>>> >> Thanks 
>>> >> 
>>> >> 
>>> >> On Friday, September 28, 2012 11:26:26 AM UTC-7, skrishna12 wrote: 
>>> >>> 
>>> >>> Hi 
>>> >>> 
>>> >>> I downloaded puppet master   puppet-enterprise-2.6.0-el-5-x86_64 on 
>>> >>> centos 5.2 server. When I tried to install , I got the following 
>>> erro

Re: [Puppet Users] New puppet based service: ServerBishop.com

[Radu Spineanu]

Hi Guzmán,

I'm really glad you like it. Yes, I'm planning to add support for importing 
modules. Though it will be limited at first (it will not support all the 
features of puppet's syntax language).

-R.

On Monday, October 22, 2012 9:46:23 PM UTC-7, Guzmán Brasó wrote:
>
> Hi!
>
> I like very much the visual interface :)
>
> It's importing recipes in the plan already?
>
> Most of us already have our recipes we would like to test with
>
> Thanks!
>
> Guzman
>
> On Mon, Oct 22, 2012 at 10:27 PM, Radu Spineanu 
> 
> > wrote:
>
>> Hi.
>>
>> I've been working on a way to quickly create, share, and deploy puppet 
>> recipes. It's called serverbishop and you can see it here: 
>> http://serverbishop.com/.
>>
>> Here is how it works: you create recipes visually, like 
>> http://serverbishop.com/radu-spineanu/graphite-debian-squeeze. Each 
>> recipe can be deployed using one command.  That command downloads the 
>> recipe and executes it locally. It does not connect servers to 
>> ServerBishop. However you can send reports back to it. Recipes can be 
>> public or private.
>>
>> My vision is to create something like Github for Puppet, with 
>> repositories, issues, and collaboration.
>>
>> I'd love to get your input. If you're in the Bay Area and you have an 
>> hour free I'd also love to buy you coffee/beers.
>>
>> -Radu
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Puppet Users" group.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msg/puppet-users/-/HqL4dUzI2tEJ.
>> To post to this group, send email to puppet...@googlegroups.com
>> .
>> To unsubscribe from this group, send email to 
>> puppet-users...@googlegroups.com .
>> For more options, visit this group at 
>> http://groups.google.com/group/puppet-users?hl=en.
>>
>
>
>
> -- 
> GuruHub - Guzmán Brasó
> http://www.guruhub.com.uy - +59898674020
> Rivera 3565 - CP11400 - Montevideo, Uruguay
>
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/p5KfPD2b5t4J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] New puppet based service: ServerBishop.com

[Guzman Braso]

Hi!

I like very much the visual interface :)

It's importing recipes in the plan already?

Most of us already have our recipes we would like to test with

Thanks!

Guzman

On Mon, Oct 22, 2012 at 10:27 PM, Radu Spineanu wrote:

> Hi.
>
> I've been working on a way to quickly create, share, and deploy puppet
> recipes. It's called serverbishop and you can see it here:
> http://serverbishop.com/.
>
> Here is how it works: you create recipes visually, like
> http://serverbishop.com/radu-spineanu/graphite-debian-squeeze. Each
> recipe can be deployed using one command.  That command downloads the
> recipe and executes it locally. It does not connect servers to
> ServerBishop. However you can send reports back to it. Recipes can be
> public or private.
>
> My vision is to create something like Github for Puppet, with
> repositories, issues, and collaboration.
>
> I'd love to get your input. If you're in the Bay Area and you have an hour
> free I'd also love to buy you coffee/beers.
>
> -Radu
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/HqL4dUzI2tEJ.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>



-- 
GuruHub - Guzmán Brasó
http://www.guruhub.com.uy - +59898674020
Rivera 3565 - CP11400 - Montevideo, Uruguay

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] New puppet based service: ServerBishop.com

[Radu Spineanu]

Hi.

I've been working on a way to quickly create, share, and deploy puppet 
recipes. It's called serverbishop and you can see it 
here: http://serverbishop.com/.

Here is how it works: you create recipes visually, 
like http://serverbishop.com/radu-spineanu/graphite-debian-squeeze. Each 
recipe can be deployed using one command.  That command downloads the 
recipe and executes it locally. It does not connect servers to 
ServerBishop. However you can send reports back to it. Recipes can be 
public or private.

My vision is to create something like Github for Puppet, with repositories, 
issues, and collaboration.

I'd love to get your input. If you're in the Bay Area and you have an hour 
free I'd also love to buy you coffee/beers.

-Radu

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/HqL4dUzI2tEJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] How to trace puppet execution to troubleshoot odd problems

[Jeff McCune]

On Sat, Oct 20, 2012 at 7:09 PM, Jakov Sosic  wrote:

> On 10/16/2012 08:49 PM, Jeff McCune wrote:
>
>  With the --debug flag, providers will print out the exact command
>> they're executing to modify the system.
>>
>
> What should a custom type/provider author put in provider code for --debug
> to print the command out, or is it automatic


It's automatic (but customizable) when the RAL synchronizes the "is" value
to the "should" value.

See:
https://github.com/puppetlabs/puppet/blob/master/lib/puppet/property.rb#L101-118

-Jeff

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] err: Could not retrieve catalog from remote server: Error 400 on SERVER: allocator undefined for Proc

[Jeff McCune]

Thanks, I didn't get a chance to dive into this today, but I'll try my best
to investigate the problem soon.  If it's Thursday and I haven't replied
please ping me again.

Am I correct in my understanding that this is only affecting one node?

Could you also paste the output of facter --puppet --yaml on the affected
node?

Thanks,
-Jeff

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: Puppet 3.0: Not authorized to call find on /file_metadata, more issues?

[Forrie]

Wow, thank you Nick for taking the time to post that.  Much appreciated!

I have moved Puppet 3.0.x onto a staging system to test out all the kinks 
before I upgrade our primary master.   So I will test out your suggestions 
-- otherwise this bug pretty much brings all of our Puppet down and makes 
it useless.


Thank you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/rrH3xQwAMdwJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: How catch a notify inside a define

[Caio Cezar Zapater de Souza]

Thanks,

I will try this.

On Friday, October 19, 2012 11:07:08 AM UTC-3, jcbollinger wrote:
>
>
>
> On Friday, October 19, 2012 9:01:01 AM UTC-5, jcbollinger wrote:
>
> Oops, I sent my response a bit prematurely.  Strike the two appearances of
>
>
>> notify => Mount["${path}"];
>>
>>
> from my suggested solution; they are replaced by subscriptions in the 
> opposite direction.
>
>
> John
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/Tiyg2Kzfhu8J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] custom type with array property?

[Stefan Schulte]

On Mon, Oct 22, 2012 at 10:53:44PM +0200, Jakov Sosic wrote:
> On 10/21/2012 10:43 PM, Nan Liu wrote:
> 
> > Puppet::Type.newtype(:customtype) do
> >   newproperty(:myarray, array_matching => :all) do
> >   end
> > end
> 
> Thank you!
> 
> Although you have syntax error, it should be:
> 
>  newproperty(:myarray, :array_matching => :all) do
> 
> Note the collon in front of array_matching.
> 
> 
> Also, what I did notice is that this code:
> 
>   newproperty(:nameservers, :array_matching => :all) do
> desc "list of nameservers"
> defaultto []
>   end
> 
> Doesn't revert to default if I remove the 'nameservers' property from my
> manifest.
> 
> I had to overload insync? for it to work, and now type looks like this:
> 
>   newproperty(:nameservers, :array_matching => :all) do
> desc "list of nameservers added to profile"
> defaultto []
> def insync?(is)
>   # if members of arrays are not the same, something
>   # was added or removed from manifest, so return false
>   return false unless is == should
>   true
> end
>   end
> 
> 
> Although I don't get it because I didn't do anything special in the
> overloaded insync? :) And without it won't work. It won't work even if I
> set:
> 
>  nameservers => []
> 
> in my manifest.
> 
> But never mind, I got it working so I'm satisfied so far.

Yeah I also consider this a bug. There is a ticket for the issue though
http://projects.puppetlabs.com/issues/10237

-Stefan

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Puppet/Passenger :: Could not retrieve catalog from remote server:Error 403 on server

[Scott Cameron]

On Wednesday, 3 October 2012 22:45:11 UTC-4, Jo wrote:
>
> On Oct 1, 2012, at 5:00 PM, Lunixer wrote:
>
> I'll try strace instead of tcpdump, being that this is not a TCP 
> communication problem over the wire but rather a file or directory access 
> problem.
>
>
> Um, no. Puppet client talks to the server over the network, even on the 
> same host. You really should listen to advice we provide. 
>
>
So if the server responds with a 403 error over the network, what exactly 
do you think a tcpdump will show?  The exact same error message.

This is why you would use strace, to see what is happening inside the 
actual process.

Try not being so condescending, particularly when you're wrong. 

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/DP9BCccRLqEJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: Duplicate class declaration because of counterintuitive class scoping

[Kristof Willaert]

Hi John,

I think the behavior you discovered is a natural and expected consequence
> of Puppet's name scoping and resolution rules. The current namespace is
> searched first for unqualified class names.  Only if no matching class is
> found there will other namespaces be considered.
>
> The difference between the behavior with parametrized-class syntax and
> 'include' for declaring the tomcat class is also normal.  It turned out
> well in your case by alerting you to the problem, but usually it is a
> problem that you need to work around.  It is only a bug to declare a class
> multiple times when the second or some later declaration is made in the
> parametrized style, and then only because of the possibility of
> inconsistent parametrization.  You can 'include' a class as many times as
> you want.
>

I understand the difference between the parameterized style and the include
syntax. That is something that is explained thoroughly in the documentation.


> Finally, although it is usually unnecessary to use absolute class names
> (e.g. "::tomcat") to declare classes, that's because name clashes are
> fairly rare.  Although you found Puppet's behavior surprising, I wouldn't
> call it buggy.
>

What I found surprising, was the fact that the "include tomcat" or "class {
'tomcat': }" syntax is documented everywhere as the declaration of the main
class of a module, without any mention of it possibly being "overridden" by
this kind of namespace clash. For variables it seems to be well documented
that we should use namespacing and top-scoping to avoid these clashes.

I used a similar setup to what is described by Craig Dunn (now a Puppetlabs
employee) at http://www.craigdunn.org/2012/05/239/, which happens to have
the exact same invocation as I did:

class profile::tomcat {
  class { "jdk": }
  class { "tomcat": }
}

As this is a blog post, it probably wasn't tested, but it shows there are
others who find this kind of invocation intuitive.

While it is easy to work around this by top-scoping the class, some form of
documented warning might prevent some hairpulling :)

Kind regards,

k

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: Puppet 3.0: Not authorized to call find on /file_metadata, more issues?

[Nick Fagerlund]

Hi everybody, 

This is a bug, and we're working on it. I'm about to update the auth.conf 
docs with info about allow_ip. Additionally, have a complete workaround for 
anyone being affected by this today. This offers complete equivalence to 
the fileserver.conf behavior that worked in 2.x and broke in 3.0.0.

**In fileserver.conf:**

Put the name of your mount point, the path, and an `allow *` directive. 

[files]
  path /etc/puppet/files
  allow *

**In auth.conf:**

Use a regular expression path to match both the `file_metadata` and 
`file_content` endpoints followed by the name of your custom mount point. 
Then, use any combination of `allow` and `allow_ip` directives to control 
access. 

path ~ ^/file_(metadata|content)/files/
auth yes
allow /^(.+\.)?example.com$/
allow_ip 192.168.100.0/24

**Effect:**

This fully re-implements the previous behavior of the following 
fileserver.conf:

[files]
  path /etc/puppet/files
  allow *.example.com
  allow 192.168.100.0/24

It does this by: 

* Allowing any request to fulfill fileserver.conf's requirements...
* ...but using auth.conf to ensure that only authorized requests ever reach 
fileserver.conf.

This pattern will be forward-compatible with whatever permanent fix we 
implement for this bug. It's not very attractive, but it works.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/US8om8O0U0AJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Your number of resources and time of your catalog runs

[Bostjan Skufca]

Hi Jakov,

On 22 October 2012 23:11, Jakov Sosic wrote:

> We're not as near in the number of resources per node yet, so no point
> in comparing :) Let's just say my client run is less then 10 seconds on
> average :)
>

Those were the nice old days, when puppet catalog was still small and it 
run fast :)


But as a side note, I'm wondering at what number of nodes one must
> replace puppetmaster with Apache+Passanger? Just a rough estimate, let's
> say master runs on 2 socket quadcore.
>
> Is it 50 agents? 100 agents? 200 agents?
>

I'm thinking about it now, but at the distributed deployment, where each 
puppetmaster serves around 20-30 nodes it is really not worth a hassle by 
itself, but I will do it soon anyway, curiosity reasons. Also, nodes 
connect to master only once every hour, seems often enough.

b.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/b2XfLOTIeFYJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] File optimizations

[Bostjan Skufca]

Hi Stephen,

On Monday, 22 October 2012 21:28:23 UTC+2, Stephen Gran wrote:
>
> Turn the question around for a moment: why do you have so many file 
> resources? 
>

These systems are puppet-controlled from the /etc/inittab through the whole 
boot process and each and every service startup file definition, along with 
their packages, which are compiled (unfurtunately, this requires at least 
one file resource - install script) and service configuration files.
Why? Let's put it this way: if you have a cluster of redundant machines, 
you can do a rolling upgrade to newer OSes etc. If not, then uptime must 
not be disturbed and this is the only way we can run recent/fresh software 
on quite old distributions (install bare! distro, no libs, then compile 
everything in a controlled maner.).

I hope I have given you a decent answer, because Borat tends to disagree 
with me:)
http://twitter.com/DEVOPS_BORAT/status/209720453881798656

b.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/pBm9LlYO5OsJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: Variables and autoloading

[jcbollinger]

On Monday, October 22, 2012 12:26:15 PM UTC-5, Nan Liu wrote:
>
> On Mon, Oct 22, 2012 at 7:37 AM, jcbollinger 
> > 
> wrote: 
> > PL put a lot of effort into improving parametrized classes for Puppet 3, 
> and 
> > they are indeed better.  As I have lately written, I think the result 
> > rescues a lot of parametrized classes that are already in use.  That 
> doesn't 
> > mean that it's a good idea to write new parametrized classes even for 
> Puppet 
> > 3, however. 
>
> I'm curious what's your perceived shortcomings in Puppet 3 with 
> parametrized classes with hiera lookup builtin? 
>
>
The key problem is not with the parametrized classes themselves, but with 
using parametrized-style class declarations.  Puppet 3 still will not 
accept a parametrized-style class declaration except as the first 
declaration of that class, and that makes such declarations dangerous at 
best and useless at worst.  Given that Puppet cannot accept inconsistent 
declarations of a given class, why does it make sense for the language to 
facilitate them?  Isn't this similar in kind to the problem with dynamic 
scoping?

Sure, you can use 'include' everywhere instead, but then what did you need 
class parametrization for in the first place?  We had a bit of a discussion 
on that question last week, actually: 
https://groups.google.com/forum/#!topic/puppet-users/dICUPHn3azY .  I'm not 
persuaded that class parametrization any longer has any value beyond 
backwards compatibility now that hiera is in the core.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/UT-8Kb_aQkMJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] File optimizations

[Bostjan Skufca]

Inline

On Monday, 22 October 2012 23:28:03 UTC+2, Brice Figureau wrote:
>
> Hi, 
>
> For development questions, feel free to post in puppet-dev :) 
>
> You're not the first irritated by those md5 computations taking time. 
> That's something I'd like to really optimize since a lng time. 
> That's simple quite difficult. 
>

Damn it, two Google Groups tabs open, for this topic it was intended to go 
to puppet-dev :/ 


> 1: On puppetmaster: 
> > For files with "source => 'puppet:///modules...' puppetmaster should 
> > already calculate md5 and send it with the catalog. 
>
> That's what the static compiler does, if I'm not mistaken. The static 
> compiler is part of puppet since 2.7. 
>

Documentation is scarce at best. What I could find, I see that it maintains 
another copy of the file in the bucket, which is not the best option (my 
usecase, if someone wants even speedier approach, this is the way to go).

b.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/rPKVJhK03zMJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: Failed to set group to '0': Operation not permitted

[jcbollinger]

On Monday, October 22, 2012 12:55:25 PM UTC-5, Dominic wrote:
>
> Hi JCBollinger, Thank you so much for your suggestions.
>
> Here goes my manifests:
>
>
> #init.pp
>
> class rabbitmq {
> include rabbitmq::source, rabbitmq::service
> } 
>
>
> #source.pp
>
> class rabbitmq::source {
> file { "/home/user": ensure => directory }
> file { "/home/user/rabbitmq-server-generic-unix-2.8.7.tar.gz":
> source => 
> "puppet:///modules/rabbitmq/rabbitmq-server-generic-unix-2.8.7.tar.gz",
> alias => "rabbitmq-source-tgz",
> before => Exec["untar-rabbitmq-source"]
> }
> exec { "/bin/tar xzvf rabbitmq-server-generic-unix-2.8.7.tar.gz":
> cwd => "/home/user/",
> creates => "/home/user/rabbitmq_server-2.8.7",
> alias => "untar-rabbitmq-source",
> subscribe => File["rabbitmq-source-tgz"]
> }
> } 
>
> #service.pp
>
> class rabbitmq::service  {
>   exec { "rabbitmq_service":
>   environment => "HOME=/home/user",
>   command=> "/home/user/rabbitmq_server-2.8.7/sbin/rabbitmq-server 
> -detached ",
>   require => Class["rabbitmq::source"]
>}
>   }
>
> We dont have root permissions, as we are hosting it in the Cloud.
>


I'm not sure why that inherently means you don't have root, but whatever.

So, supposing the issue is with 
File["/home/user/rabbitmq-server-generic-unix-2.8.7.tar.gz"], it's not 
immediately clear to me whether Puppet's behavior is correct here.  It 
seems to be defaulting the target group to 0 (since you don't specify a 
group, that has to be coming in as a default).  That's not documented 
behavior, but it may still be intentional.  On the other hand, it is usual 
for the agent to run as root, which would mask this behavior.  I would 
suggest that you file a ticket.

In the mean time, I would try to work around the issue by adding a 'group' 
parameter to the file that specifies the correct target group (presumably 
the primary group of the user who is running Puppet).

Good luck,

John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/JpSUJqdNUt4J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: Duplicate class declaration because of counterintuitive class scoping

[jcbollinger]

On Monday, October 22, 2012 3:21:57 PM UTC-5, Kristof Willaert wrote:
>
> Hi,
>
> I bumped into the following this afternoon (on a 2.7.19 puppet 
> master/agent combo):
>
> consider a class profile::tomcat in module profile with the following 
> content:
>
> $ cat modules/profile/manifests/tomcat.pp 
> class profile::tomcat {
>
> class { 'tomcat': }
> notice('Class profile::tomcat in module profile')
> }
>
> and
>
> $ cat modules/tomcat/manifests/init.pp
> class tomcat {
>
> notice('Class tomcat in module tomcat')
> ...
> }
>
> When I include this class profile::tomcat in a node definition, I would 
> expect it to apply the resources
> contained in the main class of the tomcat module (in 
> modules/tomcat/manifests/init.pp).
>
> Instead I get: 
>
> $ puppet apply --modulepath modules --verbose site.pp 
> Duplicate declaration: Class[Profile::Tomcat] is already declared; cannot 
> redeclare at /home/bkkrw/Desktop/test/modules/profile/manifests/tomcat.pp:3 
> on node XX
>
> If I instead use 
>
> class profile::tomcat {
>
> include tomcat
> notice('Class profile::tomcat in module profile')
> }
>
> then the catalog compiles successfully, but instead of applying the tomcat 
> class from modules/tomcat/manifests/init.pp,
> puppet applies the profile::tomcat class:
>
> $ puppet apply --modulepath modules --verbose site.pp 
> notice: Scope(Class[Profile::Tomcat]): Class profile::tomcat in module 
> profile
> info: Applying configuration version '1350936327'
> notice: Finished catalog run in 0.04 seconds
>
> So, apparently the tomcat class included in class profile::tomcat seems to 
> resolve to the profile::tomcat class itself
> instead of the class defined in modules/tomcat/manifests/init.pp.
>
> I can force the behaviour I want by using:
>
> class { '::tomcat':} 
>
> or
>
> include ::tomcat
>
> $ puppet apply --modulepath modules --verbose site.pp 
> notice: Scope(Class[Tomcat]): Class tomcat in module tomcat
> notice: Scope(Class[Profile::Tomcat]): Class profile::tomcat in module 
> profile
> info: Applying configuration version '1350936684'
> notice: Finished catalog run in 0.05 seconds
>
> I haven't come across this syntax for class declaration before, and 
> although it seems to work, it is at least
> quite counterintuitive, and possibly a bug.
> Everything I find seems to confirm that a declaration like "include 
> tomcat" should just apply the resources
> contained in the main class in module tomcat (in manifests/init.pp).
>
> What do you guys think ?
>
>
I think the behavior you discovered is a natural and expected consequence 
of Puppet's name scoping and resolution rules. The current namespace is 
searched first for unqualified class names.  Only if no matching class is 
found there will other namespaces be considered.

The difference between the behavior with parametrized-class syntax and 
'include' for declaring the tomcat class is also normal.  It turned out 
well in your case by alerting you to the problem, but usually it is a 
problem that you need to work around.  It is only a bug to declare a class 
multiple times when the second or some later declaration is made in the 
parametrized style, and then only because of the possibility of 
inconsistent parametrization.  You can 'include' a class as many times as 
you want.

Finally, although it is usually unnecessary to use absolute class names 
(e.g. "::tomcat") to declare classes, that's because name clashes are 
fairly rare.  Although you found Puppet's behavior surprising, I wouldn't 
call it buggy.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/uIGHSv7XSZ0J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Your number of resources and time of your catalog runs

[Ramin K]

On 10/22/2012 2:11 PM, Jakov Sosic wrote:


But as a side note, I'm wondering at what number of nodes one must
replace puppetmaster with Apache+Passanger? Just a rough estimate, let's
say master runs on 2 socket quadcore.

Is it 50 agents? 100 agents? 200 agents?



	Available CPU has no bearing on your question. Webrick is single 
threaded so the limiting factor is concurrency > 1. If your client 
requests aren't overlapping then webrick will work fine. However if 
you're using Puppet to support production servers I'd use 
Passenger/Apache regardless of whether you're likely to hit the limits 
of webrick.


Ramin

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] File optimizations

[Nikola Petrov]

On Mon, Oct 22, 2012 at 11:17:52PM +0200, Brice Figureau wrote:
> On 23/10/12 01:39, Nikola Petrov wrote:
> > On Mon, Oct 22, 2012 at 12:09:45PM -0700, Bostjan Skufca wrote:
> >> Hi there,
> >>
> >> I'm running into slow catalog runs because of many files that are managed. 
> >> I was thinking about some optimizations of this functionality.
> >>
> >> 1: On puppetmaster:
> >> For files with "source => 'puppet:///modules...' puppetmaster should 
> >> already calculate md5 and send it with the catalog.
> >>
> >> 2: On managed node:
> >> As md5s for files are already there once catalog is received, there is no 
> >> need for x https calls (x is the number of files managed with source=> 
> >> parameter)
> >>
> >> 3. Puppetmaster md5 cache
> >> This would of course put some strain on puppetmaster, which would then 
> >> benefit from some sort of file md5 cache:
> >> - when md5 is calculated, put in into cache, key is filename. Also add 
> >> file 
> >> mtime and time of cache insert.
> >> - on each catalog request, for each file in the catalog check if mtime has 
> >> changed, and if so, recalculate md5 hash, else just retrieve md5 hash from 
> >> cache
> >> - some sort of stale cache entries removal, based on cache insert time, 
> >> maybe at the end of each puppet catalog compilation, maybe controlled with 
> >> probability 1:100 or something
> >>
> >> Do you have any comments about these optimizations? They will be greatly 
> >> appreciated... really :)
> >>
> >> b.
> >>
> > Hi,
> > 
> > When using puppet I found that it is a far better idea to serf files
> > with something else. You will be far better with something else for this
> > job like sftp or ssh. My conclusions just came from the fact that we
> > were trying to import a big dump(2GB seems ok to me but who knows) and
> > puppet just died because they are not streaming the file but it is
> > *fully* loaded into memory.
> 
> This assertion is not true anymore since at least 2.6.0.
> Also, for big files you can activate http compression on the client,
> this might help (or not, YMMV).

Nice to hear that. It is true that the version with which I tested this
was somewhat old.

Best, Nikola

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Change Tab behavior in 3.0+

[Jo Rhett]

On Oct 15, 2012, at 2:23 PM, Matt Zagrabelny wrote:
> There are a truckload of reasons to not use them.


No, there is only one reason: force everybody on the project to use the 
indentation you prefer.

Every editor and command line tool allows for personalized tab adjustments. 
Logic based on how editors worked in v7 unix isn't relevant now. 
Linux/FreeBSD/Solaris/etc have never had any problem supporting flexible 
spacing arrangements. The logic named in those posts is only relevant if you 
are using 30 years old operating systems that can't run Puppet nor Eclipse 
anyway.

-- 
Jo Rhett
Net Consonance : net philanthropy to improve open source and internet projects.



-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Your number of resources and time of your catalog runs

[llowder]

On Monday, October 22, 2012 4:12:15 PM UTC-5, Jakov Sosic wrote:
>
> On 10/22/2012 09:04 PM, Bostjan Skufca wrote: 
> > Hi, 
> > 
> > I was just wondering what is someone else's number of manager resources 
> > and catalog run time. 
> > Mine is 1,700 resources and average catalog run of 70-100 seconds (40 
> > seconds for catalog retrieval, 30-60 for catalog run), depending on the 
> > network distance between puppetmaster and managed node. 
> > Then there are few more seconds for provider cache stuff, and report 
> > uploading takes it's tool too, together adding some 20 seconds. 
> > 
> > Care to share your puppet agent performance details? 
>
> We're not as near in the number of resources per node yet, so no point 
> in comparing :) Let's just say my client run is less then 10 seconds on 
> average :) 
>
>
> But as a side note, I'm wondering at what number of nodes one must 
> replace puppetmaster with Apache+Passanger? Just a rough estimate, let's 
> say master runs on 2 socket quadcore. 
>
>
I replaced it at around 35 nodes I think. I've currently got 42. Before 
making the change to Apache + Passenger, we were seeing timeouts with 
webrick.

And in all honestly, I would make that change if you were using puppet in 
any sort of production environment. The only time I use webrick is for 
throwaway VMs where I have 1-3 nodes (including the master itself) running 
off a master so I can test something outside of my main master.

 

> Is it 50 agents? 100 agents? 200 agents? 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/Uwq22fPQi5gJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] File optimizations

[Brice Figureau]

Hi,

For development questions, feel free to post in puppet-dev :)

You're not the first irritated by those md5 computations taking time.
That's something I'd like to really optimize since a lng time.
That's simple quite difficult.

On 22/10/12 21:09, Bostjan Skufca wrote:
> Hi there,
> 
> I'm running into slow catalog runs because of many files that are
> managed. I was thinking about some optimizations of this functionality.
> 
> 1: On puppetmaster:
> For files with "source => 'puppet:///modules...' puppetmaster should
> already calculate md5 and send it with the catalog.

That's what the static compiler does, if I'm not mistaken. The static
compiler is part of puppet since 2.7.

> 2: On managed node:
> As md5s for files are already there once catalog is received, there is
> no need for x https calls (x is the number of files managed with
> source=> parameter)
> 
> 3. Puppetmaster md5 cache
> This would of course put some strain on puppetmaster, which would then
> benefit from some sort of file md5 cache:
> - when md5 is calculated, put in into cache, key is filename. Also add
> file mtime and time of cache insert.
> - on each catalog request, for each file in the catalog check if mtime
> has changed, and if so, recalculate md5 hash, else just retrieve md5
> hash from cache
> - some sort of stale cache entries removal, based on cache insert time,
> maybe at the end of each puppet catalog compilation, maybe controlled
> with probability 1:100 or something

Actually checking the mtime/size prior to do any md5 computations could
be a big win.

But that's not all, in fact there are 3 md5 computations per files
taking place during a puppet run:
* one by the master when computing file metadata
* one by the agent on the existing file (this helps to know if the file
changed)
* and finally one after writing the change to the files to make sure we
wrote it correctly.

A potential solution would be to implement a different checksum type
(maybe less powerful than a md5, but faster).

> Do you have any comments about these optimizations? They will be greatly
> appreciated... really :)

Well, I believe we're (at least myself) very aware of those issues. The
fact that it never got fixed (except by the static compiler) is that
it's a complex stuff. Last time I tried to fiddle with the checksumming,
I never quite got anywhere :)

As I said in the preamble, feel free to chime in puppet-dev to talk
about this, and check the various redmine tickets regarding those issues.
-- 
Brice Figureau
My Blog: http://www.masterzen.fr/

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] File optimizations

[Brice Figureau]

On 23/10/12 01:39, Nikola Petrov wrote:
> On Mon, Oct 22, 2012 at 12:09:45PM -0700, Bostjan Skufca wrote:
>> Hi there,
>>
>> I'm running into slow catalog runs because of many files that are managed. 
>> I was thinking about some optimizations of this functionality.
>>
>> 1: On puppetmaster:
>> For files with "source => 'puppet:///modules...' puppetmaster should 
>> already calculate md5 and send it with the catalog.
>>
>> 2: On managed node:
>> As md5s for files are already there once catalog is received, there is no 
>> need for x https calls (x is the number of files managed with source=> 
>> parameter)
>>
>> 3. Puppetmaster md5 cache
>> This would of course put some strain on puppetmaster, which would then 
>> benefit from some sort of file md5 cache:
>> - when md5 is calculated, put in into cache, key is filename. Also add file 
>> mtime and time of cache insert.
>> - on each catalog request, for each file in the catalog check if mtime has 
>> changed, and if so, recalculate md5 hash, else just retrieve md5 hash from 
>> cache
>> - some sort of stale cache entries removal, based on cache insert time, 
>> maybe at the end of each puppet catalog compilation, maybe controlled with 
>> probability 1:100 or something
>>
>> Do you have any comments about these optimizations? They will be greatly 
>> appreciated... really :)
>>
>> b.
>>
> Hi,
> 
> When using puppet I found that it is a far better idea to serf files
> with something else. You will be far better with something else for this
> job like sftp or ssh. My conclusions just came from the fact that we
> were trying to import a big dump(2GB seems ok to me but who knows) and
> puppet just died because they are not streaming the file but it is
> *fully* loaded into memory.

This assertion is not true anymore since at least 2.6.0.
Also, for big files you can activate http compression on the client,
this might help (or not, YMMV).
-- 
Brice Figureau
My Blog: http://www.masterzen.fr/

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Your number of resources and time of your catalog runs

[Jakov Sosic]

On 10/22/2012 09:04 PM, Bostjan Skufca wrote:
> Hi,
> 
> I was just wondering what is someone else's number of manager resources
> and catalog run time.
> Mine is 1,700 resources and average catalog run of 70-100 seconds (40
> seconds for catalog retrieval, 30-60 for catalog run), depending on the
> network distance between puppetmaster and managed node.
> Then there are few more seconds for provider cache stuff, and report
> uploading takes it's tool too, together adding some 20 seconds.
> 
> Care to share your puppet agent performance details?

We're not as near in the number of resources per node yet, so no point
in comparing :) Let's just say my client run is less then 10 seconds on
average :)


But as a side note, I'm wondering at what number of nodes one must
replace puppetmaster with Apache+Passanger? Just a rough estimate, let's
say master runs on 2 socket quadcore.

Is it 50 agents? 100 agents? 200 agents?

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] custom type with array property?

[Jakov Sosic]

On 10/21/2012 10:43 PM, Nan Liu wrote:

> Puppet::Type.newtype(:customtype) do
>   newproperty(:myarray, array_matching => :all) do
>   end
> end

Thank you!

Although you have syntax error, it should be:

 newproperty(:myarray, :array_matching => :all) do

Note the collon in front of array_matching.


Also, what I did notice is that this code:

  newproperty(:nameservers, :array_matching => :all) do
desc "list of nameservers"
defaultto []
  end

Doesn't revert to default if I remove the 'nameservers' property from my
manifest.

I had to overload insync? for it to work, and now type looks like this:

  newproperty(:nameservers, :array_matching => :all) do
desc "list of nameservers added to profile"
defaultto []
def insync?(is)
  # if members of arrays are not the same, something
  # was added or removed from manifest, so return false
  return false unless is == should
  true
end
  end


Although I don't get it because I didn't do anything special in the
overloaded insync? :) And without it won't work. It won't work even if I
set:

 nameservers => []

in my manifest.

But never mind, I got it working so I'm satisfied so far.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] File optimizations

[Nikola Petrov]

On Mon, Oct 22, 2012 at 12:09:45PM -0700, Bostjan Skufca wrote:
> Hi there,
> 
> I'm running into slow catalog runs because of many files that are managed. 
> I was thinking about some optimizations of this functionality.
> 
> 1: On puppetmaster:
> For files with "source => 'puppet:///modules...' puppetmaster should 
> already calculate md5 and send it with the catalog.
> 
> 2: On managed node:
> As md5s for files are already there once catalog is received, there is no 
> need for x https calls (x is the number of files managed with source=> 
> parameter)
> 
> 3. Puppetmaster md5 cache
> This would of course put some strain on puppetmaster, which would then 
> benefit from some sort of file md5 cache:
> - when md5 is calculated, put in into cache, key is filename. Also add file 
> mtime and time of cache insert.
> - on each catalog request, for each file in the catalog check if mtime has 
> changed, and if so, recalculate md5 hash, else just retrieve md5 hash from 
> cache
> - some sort of stale cache entries removal, based on cache insert time, 
> maybe at the end of each puppet catalog compilation, maybe controlled with 
> probability 1:100 or something
> 
> Do you have any comments about these optimizations? They will be greatly 
> appreciated... really :)
> 
> b.
> 
Hi,

When using puppet I found that it is a far better idea to serf files
with something else. You will be far better with something else for this
job like sftp or ssh. My conclusions just came from the fact that we
were trying to import a big dump(2GB seems ok to me but who knows) and
puppet just died because they are not streaming the file but it is
*fully* loaded into memory.

Apart from that these ideas seems reasonable but I am not a commiter.

Best, Nikola

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Duplicate class declaration because of counterintuitive class scoping

[Kristof Willaert]

Hi,

I bumped into the following this afternoon (on a 2.7.19 puppet master/agent
combo):

consider a class profile::tomcat in module profile with the following
content:

$ cat modules/profile/manifests/tomcat.pp
class profile::tomcat {

class { 'tomcat': }
notice('Class profile::tomcat in module profile')
}

and

$ cat modules/tomcat/manifests/init.pp
class tomcat {

notice('Class tomcat in module tomcat')
...
}

When I include this class profile::tomcat in a node definition, I would
expect it to apply the resources
contained in the main class of the tomcat module (in
modules/tomcat/manifests/init.pp).

Instead I get:

$ puppet apply --modulepath modules --verbose site.pp
Duplicate declaration: Class[Profile::Tomcat] is already declared; cannot
redeclare at /home/bkkrw/Desktop/test/modules/profile/manifests/tomcat.pp:3
on node XX

If I instead use

class profile::tomcat {

include tomcat
notice('Class profile::tomcat in module profile')
}

then the catalog compiles successfully, but instead of applying the tomcat
class from modules/tomcat/manifests/init.pp,
puppet applies the profile::tomcat class:

$ puppet apply --modulepath modules --verbose site.pp
notice: Scope(Class[Profile::Tomcat]): Class profile::tomcat in module
profile
info: Applying configuration version '1350936327'
notice: Finished catalog run in 0.04 seconds

So, apparently the tomcat class included in class profile::tomcat seems to
resolve to the profile::tomcat class itself
instead of the class defined in modules/tomcat/manifests/init.pp.

I can force the behaviour I want by using:

class { '::tomcat':}

or

include ::tomcat

$ puppet apply --modulepath modules --verbose site.pp
notice: Scope(Class[Tomcat]): Class tomcat in module tomcat
notice: Scope(Class[Profile::Tomcat]): Class profile::tomcat in module
profile
info: Applying configuration version '1350936684'
notice: Finished catalog run in 0.05 seconds

I haven't come across this syntax for class declaration before, and
although it seems to work, it is at least
quite counterintuitive, and possibly a bug.
Everything I find seems to confirm that a declaration like "include tomcat"
should just apply the resources
contained in the main class in module tomcat (in manifests/init.pp).

What do you guys think ?

Kind regards,

k

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: Node specific exported resources

[Alex C]

We're not ready to roll out hiera just yet.

I ended up storing the extra config in a parameter in puppet-dashboard and 
I'm appending that variable to the existing configuration:


  $extra = regsubst($::munin_extra, '\\n', "
", 'G')

  @@file { "/etc/munin/munin.conf.d/${::fqdn}.node":
content => "[All Hosts;${::fqdn}]
  address ${ipaddress_eth0}
  use_node_name yes
  ${extra}\n\n",
tag => 'munin-node',
  }

It's not the most elegant solution, but it will work for the 4 or 5 nodes 
that I have that need additional configuration options for munin.

Thanks for the ideas everyone!

-- Alex

On Monday, October 22, 2012 9:10:06 AM UTC-4, jcbollinger wrote:
>
>
>
> On Friday, October 19, 2012 9:03:39 AM UTC-5, Alex C wrote:
>>
>> Greetings,
>>
>> I'm trying to wrap my head around a solution to a problem I'm facing with 
>> an exported resources configuration I have.  I'm using the following simple 
>> config to build a munin configuration:
>>
>> @@file { "/etc/munin/munin.conf.d/${::fqdn}.node":
>>   content => "[All Hosts;${::fqdn}]
>>   address ${ipaddress_eth0}
>>   use_node_name yes\n\n",
>>   tag => 'munin-node',
>> }
>>
>> File <<| tag == 'munin-node' |>>
>>
>> I'd like to add the following configuration lines to specifically one of 
>> the nodes:
>>
>>   diskstats_latency.sda.avgrdwait.warning 0:5
>>   diskstats_latency.sda.avgwrwait.warning 0:5
>>
>> Is there a way to cleanly append those configuration lines to the content 
>> of the exported resource on that node without redeclaring the entire 
>> contents of the file?
>>
>
>
> You cannot append to the already-declared content property, but you may be 
> able to build the content you want in the first place.  For example, you 
> could initially declare the file along these lines:
>
> $munin_extra = hiera('munin_extra')
> @@file { "/etc/munin/munin.conf.d/${::fqdn}.node":
>   content => "[All Hosts;${::fqdn}]
>   address ${ipaddress_eth0}
>   use_node_name yes
>   ${munin_extra}\n\n",
>   tag => 'munin-node',
> }
>
> if you're not already using hiera and you don't want to start, then you 
> could achieve something similar via conditional statements and data in your 
> manifests, or perhaps more flexibly by converting your content to a 
> template and putting whatever processing logic you want into it.
>
>
> John
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/AxTHFGR6x9AJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] File optimizations

[Stephen Gran]

Hi,

On Mon, 2012-10-22 at 12:09 -0700, Bostjan Skufca wrote:
> Hi there,
> 
> 
> I'm running into slow catalog runs because of many files that are
> managed. I was thinking about some optimizations of this
> functionality.

Your suggestions look reasonable to me, but I'm not a puppetlabs person,
so can't make an official comment.

Turn the question around for a moment: why do you have so many file
resources?

Cheers,
-- 
Stephen Gran
Senior Systems Integrator - guardian.co.uk

Please consider the environment before printing this email.
--
Visit guardian.co.uk - newspaper of the year

www.guardian.co.ukwww.observer.co.uk www.guardiannews.com 

On your mobile, visit m.guardian.co.uk or download the Guardian
iPhone app www.guardian.co.uk/iphone and iPad edition www.guardian.co.uk/iPad 
 
Save up to 37% by subscribing to the Guardian and Observer - choose the papers 
you want and get full digital access. 
Visit guardian.co.uk/subscribe 

-
This e-mail and all attachments are confidential and may also
be privileged. If you are not the named recipient, please notify
the sender and delete the e-mail and all attachments immediately.
Do not disclose the contents to another person. You may not use
the information for any purpose, or store, or copy, it in any way.
 
Guardian News & Media Limited is not liable for any computer
viruses or other material transmitted with or as part of this
e-mail. You should employ virus checking software.

Guardian News & Media Limited

A member of Guardian Media Group plc
Registered Office
PO Box 68164
Kings Place
90 York Way
London
N1P 2AP

Registered in England Number 908396

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] File optimizations

[Bostjan Skufca]

Hi there,

I'm running into slow catalog runs because of many files that are managed. 
I was thinking about some optimizations of this functionality.

1: On puppetmaster:
For files with "source => 'puppet:///modules...' puppetmaster should 
already calculate md5 and send it with the catalog.

2: On managed node:
As md5s for files are already there once catalog is received, there is no 
need for x https calls (x is the number of files managed with source=> 
parameter)

3. Puppetmaster md5 cache
This would of course put some strain on puppetmaster, which would then 
benefit from some sort of file md5 cache:
- when md5 is calculated, put in into cache, key is filename. Also add file 
mtime and time of cache insert.
- on each catalog request, for each file in the catalog check if mtime has 
changed, and if so, recalculate md5 hash, else just retrieve md5 hash from 
cache
- some sort of stale cache entries removal, based on cache insert time, 
maybe at the end of each puppet catalog compilation, maybe controlled with 
probability 1:100 or something

Do you have any comments about these optimizations? They will be greatly 
appreciated... really :)

b.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/_2z4LaLw_IoJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Your number of resources and time of your catalog runs

[Bostjan Skufca]

Hi,

I was just wondering what is someone else's number of manager resources and 
catalog run time.
Mine is 1,700 resources and average catalog run of 70-100 seconds (40 
seconds for catalog retrieval, 30-60 for catalog run), depending on the 
network distance between puppetmaster and managed node.
Then there are few more seconds for provider cache stuff, and report 
uploading takes it's tool too, together adding some 20 seconds.

Care to share your puppet agent performance details?

b.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/-BnVWSmxIIUJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: Failed to set group to '0': Operation not permitted

[Dominic]

Hi JCBollinger, Thank you so much for your suggestions.

Here goes my manifests:


#init.pp

class rabbitmq {
include rabbitmq::source, rabbitmq::service
} 


#source.pp

class rabbitmq::source {
file { "/home/user": ensure => directory }
file { "/home/user/rabbitmq-server-generic-unix-2.8.7.tar.gz":
source => 
"puppet:///modules/rabbitmq/rabbitmq-server-generic-unix-2.8.7.tar.gz",
alias => "rabbitmq-source-tgz",
before => Exec["untar-rabbitmq-source"]
}
exec { "/bin/tar xzvf rabbitmq-server-generic-unix-2.8.7.tar.gz":
cwd => "/home/user/",
creates => "/home/user/rabbitmq_server-2.8.7",
alias => "untar-rabbitmq-source",
subscribe => File["rabbitmq-source-tgz"]
}
} 

#service.pp

class rabbitmq::service  {
  exec { "rabbitmq_service":
  environment => "HOME=/home/user",
  command=> "/home/user/rabbitmq_server-2.8.7/sbin/rabbitmq-server 
-detached ",
  require => Class["rabbitmq::source"]
   }
  }

We dont have root permissions, as we are hosting it in the Cloud.

But when I do extract the unix.tar.gz in user mode without any root 
permissions manually ,  and execute the ./sbin/rabbitmq-server, it gets 
executed.

I really appreciate your suggestions and thoughts.

Thanks again,

Dominic.




On Monday, October 22, 2012 6:54:47 AM UTC-7, jcbollinger wrote:
>
>
>
> On Friday, October 19, 2012 9:38:25 AM UTC-5, Dominic wrote:
>>
>> Hi everyone,
>>
>> Here is the task, I just need to get the file from master, untar it and 
>> execute a file.
>>
>> Step 1: 
>>
>> Working as a root user,having the default puppet.conf for root and the 
>> agent could get the source file  from master , untar it and execute it.
>>
>> Step 2: 
>>
>> Moving to non-root user, I have a different puppet.conf with the conf the 
>> master validates the agent and gets me the source , and untar it to the 
>> agent , but on the agent side I got the error. 
>>
>>
>> Here is my puppet.conf
>>
>> [main]
>> logdir = /home/user/var/log/puppet
>> rundir = /home/user/var/run/puppet
>> vardir = /home/user/var/lib/puppet
>> ssldir = $vardir/ssl
>>  
>> server=puppetmaster.example.com
>> [agent]
>> classfile = $vardir/classes.txt
>> localconfig = $vardir/localconfig
>> [master]
>> certname=puppetmaster.example.com
>>
>> On executing, 
>>
>> puppet agent --confdir-/home/user/etc -t, 
>>
>> Error: Failed to set group to '0': Operation not permitted - 
>> /home/user/unix.tar.gz
>> Error: /File[/home/user/unix.tar.gz]/ensure: change from absent to file 
>> failed: Failed to set group to '0': Operation not permitted - 
>> /home/user/.tar.gz
>>
>> Though I set the tarball of the source in master to 777 permissions, I 
>> get the same error.
>>
>> Your help is great appreciated, please let me know if you need any 
>> further info.
>>
>>
> This problem is not directly related to puppet.conf.  It is probably in 
> issue in your init.pp file on the master (because that appears to be where 
> you declare File[/home/user/unix.tar.gz]).  The manifest leads Puppet to 
> believe that the target file is supposed to have group 0, but changing the 
> downloaded file's group requires the agent to run as root.
>
> If you post the declaration of that file, then we may be able to tell you 
> more.
>
> I have a question, though: what is the purpose of having this run by an 
> unprivileged user in the first place?
>
>
> John
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/pW5PcOypT24J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: How do design next-gen modules, any guidelines ? a question for gurus...

[Jakov Sosic]

On 10/22/2012 06:17 PM, jcbollinger wrote:
> 
> 
> On Monday, October 22, 2012 2:33:18 AM UTC-5, Thomas Guthmann wrote:
> 
> Hi,
> 
> My dilemma is how should I write my module to be "next-gen" ?
> Not from a code point of view but from a design/layout point of view.
> 
> 
> 
> I don't think much has changed in that area in a long time.  Styles have
> come and gone, but the only new thing I can think of since 0.24 that had
> much impact on the fundamental questions is hiera.
> 
>  
> 
> 
> We wrote our modules for 2.6.x like every beginner would have done:
> write everything in init.pp.
> 
> But now, the fashion is to use parameterized classes and Hiera which we
> will use with puppet 2.7.x.
> 
> 
> 
> It would be wise to make your decisions based on an evaluation of
> technical merit, not based on what happens to be fashionable in some
> segment of the Internet at the moment.  And naturally, you should be
> wary of taking advice from random people on the 'net.  (Except me -- I'm
> TOTALLY reliable.  :-))
> 
>  
> 
> 
> I mainly followed/watched what Example42 was doing. They were using
> $classname::{install|remove|disable|blah} to actually call an action in
> their old modules. It was almost a sub class ($subclass.pp) per action.
> It was easy to read and possibly to maintain.
> 
> 
> 
> I am all for modular code (including inside Puppet 'modules'), but what
> I think you're asking about here is not so much module implementation,
> but rather modules' interfaces to the rest of Puppet.  Thus I take it as
> a question about whether to convey information about the desired
> configuration details via class names or data (parameters or external
> data).  The two approaches provide different advantages.
> 
> Controlling everything via data (meaning either / both class parameters
> and external data) can make your main manifests very simple, and / or it
> may have advantages for the design of complementary ENCs.  On the other
> hand, putting information into class names can enable class dependencies
> to depend on that information.  For example: "Class['tomcat::running']
> -> Class['mywebapp::running']".  As you say, using class names in that
> way also can make manifests clearer to human readers.
> 
>  
> 
> 
> But now Alessandro from Example42 seems to put everything back in
> init.pp with his nextgen modules...
> 
> I like the idea of segregating types or action per files to avoid
> mistakes during edits but at the same time I am wondering why this
> change for example42, is it a limitation for parameterized classes ?
> 
> 
> 
> I cannot speak for Example42, but if you've been following this group
> you will know by now that my technical opinion of parametrized classes
> is that you should not write them, and as much as possible you should
> avoid using them (unless via the 'include' or 'require' function).  I
> have not studied the Example42 modules, but it is conceivable that some
> of the technical limitations of parametrized classes influenced the
> decision to move to unitary interfaces.

IMHO it's OK to write them as long as you don't declare them as
resources. Benefits:

- backwards compatible
- no direct hiera calls in classes
- "class::params" has all the defaults

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: Variables and autoloading

[Nan Liu]

On Mon, Oct 22, 2012 at 7:37 AM, jcbollinger  wrote:
> PL put a lot of effort into improving parametrized classes for Puppet 3, and
> they are indeed better.  As I have lately written, I think the result
> rescues a lot of parametrized classes that are already in use.  That doesn't
> mean that it's a good idea to write new parametrized classes even for Puppet
> 3, however.

I'm curious what's your perceived shortcomings in Puppet 3 with
parametrized classes with hiera lookup builtin?

Thanks,

Nan

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: Variables and autoloading

[Guzman Braso]

John:

Very concise and helpful answer, thank you very much for your time!

Best regards from Montevideo,

Guzmán
On Mon, Oct 22, 2012 at 12:37 PM, jcbollinger wrote:

>
>
> On Sunday, October 21, 2012 6:02:39 PM UTC-5, Guzmán Brasó wrote:
>>
>> John,
>>
>> I'm new to puppet and your mails confuse me a little bit... if
>> parameterized classes are not recommended and you suggest when dealing with
>> someone else parameterized class to set it through hiera (Puppet 3).
>> Then I don't understand how to proceed with puppet 2 modules...
>>
>
>
> Here are some of your better choices, none of them especially good:
>
>1. Upgrade your master to Puppet 3.  The clients can stay at 2.7 if
>you wish.
>2. Avoid third-party modules whose interfaces involve parametrized
>classes, unless they have built-in hiera support.
>3. Be very careful and deliberate with the placement of your
>parametrized-style class declarations, and expect to troubleshoot parse
>order issues from time to time.
>
>
>
>>
>> Should I hack every module I need to set the defaults inside the module?
>>
>
>
> That's an option too, but I wouldn't recommend it.
>
>
>>
>> And if making a module, without using parameters, how I can reuse the
>> module with different defaults ? Should I create a different params.pp for
>> each scenario I need and then include it inheriting each one of the
>> defaults, this would be a mess to deal with large arquitectures with many
>> different types of nodes.
>>
>
>
> That is what hiera is for.  Although not integrated into the core until
> Puppet 3, hiera is a widely-used add-on to Puppet 2.  Instead of
>
> class mymodule::foo (
>   $param1 = 'default1',
>   $param2 = 'default2' ) {
>   # declarations
> }
>
> I recommend some variation on
>
> class mymodule::foo {
>   $param1 = hiera('foo::param1', 'default1')
>   $param2 = hiera('foo::param2', 'default2')
>   # declarations
> }
>
> Then put any needed 'parameter' customizations into your hiera data.  That
> way not only can you avoid parametrized-style class declarations, but you
> also achieve separation of your data from your code.
>
>
>
>>
>> I'm sorry to ask but since we started using puppet (a few months ago) we
>> started doing everything with parameters as puppet docs said on
>> http://docs.puppetlabs.com/**guides/parameterized_classes.**html
>>  and
>> since then we had no issue (yet) with it.  And now you say that parameters
>> are a sickness and should not be used. Then how on Puppet 2? And why it's
>> still puppet docs still recommending it?
>>
>>
> Puppetlabs heavily promoted parametrized classes starting with their
> release as part of Puppet 2.6.  Evidently, they perceived and continue to
> perceive substantial demand for such a feature.  That doesn't mean it was
> ever a good idea.
>
> Having promoted the feature so effectively puts PuppetLabs in a difficult
> position.  At least some of their people will acknowledge the problems with
> parametrized classes, at least in Puppet 2.x.  I can only speculate about
> company policy here, but it would be reasonable for PL to judge that doing
> an about-face on parametrized classes could present credibility and trust
> issues for the company.
>
> PL put a lot of effort into improving parametrized classes for Puppet 3,
> and they are indeed better.  As I have lately written, I think the result
> rescues a lot of parametrized classes that are already in use.  That
> doesn't mean that it's a good idea to write new parametrized classes even
> for Puppet 3, however.
>
> And of course, a lot of people are using parametrized classes
> successfully.  My argument has never been that they don't work, only that
> they exact unneeded costs in productivity and stability relative to the
> best available alternative.  Those costs will scale with the number of
> dependencies between classes.
>
>
> John
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/r53hq-Tk8CsJ.
>
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>



-- 
GuruHub - Guzmán Brasó
http://www.guruhub.com.uy - +59898674020
Rivera 3565 - CP11400 - Montevideo, Uruguay

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Chicago Puppet UG: Chat with Puppet Labs folks on Oct 24

[Dawn Foster]

I wanted to make sure that people in and around Chicago are aware of
an upcoming Puppet UG meetup on October 24.

Here are the details that were posted on the meetup site, but you
should visit the meetup page for more info:
http://www.meetup.com/Chicago-Puppet-users-group/events/87307142/

Chat with Puppet Labs folks
Wednesday, October 24, 2012 at 6:00 PM
Backstop Solutions Group
233 South Wacker Drive, Chicago, IL
http://www.meetup.com/Chicago-Puppet-users-group/events/87307142/

A few people from Puppet Labs are in town for the Puppet Fundamentals
training. Who wants to meet up and talk about Puppet? Please RSVP with
your full name - building security needs a list before they'll let you
up.

RSVP and post questions here on the Meetup page:
http://www.meetup.com/Chicago-Puppet-users-group/events/87307142/

Thanks,
Dawn

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: How do design next-gen modules, any guidelines ? a question for gurus...

[jcbollinger]

On Monday, October 22, 2012 2:33:18 AM UTC-5, Thomas Guthmann wrote:
>
> Hi, 
>
> My dilemma is how should I write my module to be "next-gen" ? 
> Not from a code point of view but from a design/layout point of view.
>


I don't think much has changed in that area in a long time.  Styles have 
come and gone, but the only new thing I can think of since 0.24 that had 
much impact on the fundamental questions is hiera.

 

>
> We wrote our modules for 2.6.x like every beginner would have done: 
> write everything in init.pp. 
>
> But now, the fashion is to use parameterized classes and Hiera which we 
> will use with puppet 2.7.x. 
>


It would be wise to make your decisions based on an evaluation of technical 
merit, not based on what happens to be fashionable in some segment of the 
Internet at the moment.  And naturally, you should be wary of taking advice 
from random people on the 'net.  (Except me -- I'm TOTALLY reliable.  :-))

 

>
> I mainly followed/watched what Example42 was doing. They were using 
> $classname::{install|remove|disable|blah} to actually call an action in 
> their old modules. It was almost a sub class ($subclass.pp) per action. 
> It was easy to read and possibly to maintain. 
>


I am all for modular code (including inside Puppet 'modules'), but what I 
think you're asking about here is not so much module implementation, but 
rather modules' interfaces to the rest of Puppet.  Thus I take it as a 
question about whether to convey information about the desired 
configuration details via class names or data (parameters or external 
data).  The two approaches provide different advantages.

Controlling everything via data (meaning either / both class parameters and 
external data) can make your main manifests very simple, and / or it may 
have advantages for the design of complementary ENCs.  On the other hand, 
putting information into class names can enable class dependencies to 
depend on that information.  For example: "Class['tomcat::running'] -> 
Class['mywebapp::running']".  As you say, using class names in that way 
also can make manifests clearer to human readers.

 

>
> But now Alessandro from Example42 seems to put everything back in 
> init.pp with his nextgen modules... 
>
> I like the idea of segregating types or action per files to avoid 
> mistakes during edits but at the same time I am wondering why this 
> change for example42, is it a limitation for parameterized classes ? 
>


I cannot speak for Example42, but if you've been following this group you 
will know by now that my technical opinion of parametrized classes is that 
you should not write them, and as much as possible you should avoid using 
them (unless via the 'include' or 'require' function).  I have not studied 
the Example42 modules, but it is conceivable that some of the technical 
limitations of parametrized classes influenced the decision to move to 
unitary interfaces.

The main potential issue there would be that any parametrized-style 
declaration for a given class must be the *first* declaration Puppet parses 
for that class.  It follows that there can only be one such declaration of 
each class (whereas there can be any number of 'include' or 'require' 
declarations of a class).  There are many implications, among them that if 
the module supports users declaring, say, mymodule::installed, then other 
classes in the module (mymodule::running, for instance) must not use 
parametrized-style declarations of that class.  That's a bit of a catch-22, 
however, because if the user *doesn't* declare the first class, then other 
classes in the module may need to declare it with parameters.

Alternatively, if the example42 modules are truly subclassing (which is not 
inherently implied by namespace nesting ala "classname::blah") then the 
perception may just be that conditionalizing resource declarations based on 
class parameters is preferable to inheriting/overriding resources.  There 
are valid arguments for that position, but I think the jury is very much 
still out.
 

>
> Like everybody, I'd like to write my module using the best and most 
> flexible way so it will be easy to modify and to maintain. I don't like 
> to redo my modules from scratch each time :) 
>
> So, any inputs/insights are welcome. What direction should I/we take ?
>


It's just too broad a question.  I don't think there are very many rules 
that would reasonably apply to every module in every context.  Here are two 
that you should consider adopting, however:

   - Declarations of interface classes (those intended to be declared 
   outside the module) should be performed via the 'include' or 'require' 
   function, as appropriate, not via the newer parametrized-style class 
   declaration syntax.  Such classes should rely on hiera for any needed 
   customization data.  In Puppet 2.x, that probably means avoiding 
   parametrizing such classes in the first place.
   - Class, definition, and parameter names should be nouns or n

Re: [Puppet Users] Razor Mongodb related questions

[Hong]

Thanks so much for your reply on my questions. I will move this topic to 
dev list :)

On Sunday, October 21, 2012 9:20:15 PM UTC-7, Daniel Pittman wrote:
>
> On Sun, Oct 21, 2012 at 10:12 AM, Hong > 
> wrote: 
> > I'm new to Razor and have two questions related to Razor Mongodb: 
>
> Hey.  A better place for developer type questions like this is 
> probably the dev list, just because the volume of mail here on the 
> user list can make it easy to miss. 
>
> > 1. Is there available Razor object relationship diagram that describes 
> > relationships between Razor slices? 
>
> Not really.  There is some per-slice documentation that kind of covers 
> this here: https://github.com/puppetlabs/Razor/wiki 
>
> What, concretely, were you looking for?  I know that better 
> documentation is needed, but having real stories about the questions 
> people were trying to answer will help make it much better, much 
> sooner. :) 
>
> > 2. Does Razor make use of Mongo's JSON doc store features like automatic 
> > secondary indexing on all JSON attributes? 
>
> ...not really, in the sense that Razor doesn't actually have *any* 
> sort of query across the data, just key lookup or full collection 
> lookup. 
>
> Why do you ask? 
>
> -- 
> Daniel Pittman 
> ⎋ Puppet Labs Developer – http://puppetlabs.com 
> ♲ Made with 100 percent post-consumer electrons 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/7ziAa3zbHg4J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Puppet on OpenSuSE & SLES

[Darin Perusich]

Hi Niels,

The only thing those SuSE packages are missing, imo, is the
ruby-shadow packages and dependency.  I've been meaning to submit
ruby-shadow and an updated spec to systemsmanagement:puppet just
haven't had the time.

--
Later,
Darin


On Mon, Oct 22, 2012 at 1:18 AM, Niels Abspoel  wrote:
> Or you can go to https://build.opensuse.org/
>
> They have two projects running:
> 2.7.19: systemsmanagement-puppet
>
> 3.0.0:  systemsmanagement-puppet-devel-package=puppet
>
> and my own
> 3.0.1: home-Aaboe76-branches-systemsmanagement-puppet-devel
>
> These are packages build for suse and tested on my machine.
>
> Greetz,
> Niels
>
>
> Op donderdag 29 maart 2012 15:03:36 UTC+2 schreef Darin Perusich het
> volgende:
>>
>> You can grab the .spec from the build service project or the srpm links
>> below.
>>
>> http://download.opensuse.org/repositories/home:/eclipseagent:/puppet/
>>
>> https://build.opensuse.org/project/show?project=home%3Aeclipseagent%3Apuppet
>>
>> --
>> Later,
>> Darin
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/-vYDo6vaqmIJ.
>
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] How do design next-gen modules, any guidelines ? a question for gurus...

[Ryan Coleman]

On Mon, Oct 22, 2012 at 12:33 AM, Thomas Guthmann wrote:

>
> But now, the fashion is to use parameterized classes and Hiera which we
> will use with puppet 2.7.x.
>

On this point, I'd suggest you read this docs page with some points on
writing classes with other versions in mind. Personally, if you're starting
from scratch, I'd suggest you write with Puppet 3.0 in mind.

http://docs.puppetlabs.com/puppet/3/reference/lang_classes.html#aside-writing-for-multiple-puppet-versions


>
>
> Note: I like the puppet style guide but it only talks about syntax not
>   how to design module the best way.
>
>
Indeed! I'm quite interested in writing such a guide. It's only a matter of
getting the time at this point to start a draft and get everyone involved
in hacking on it.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] err: Could not retrieve catalog from remote server: Error 400 on SERVER: allocator undefined for Proc

[Fabrice Bacchella]

Here it is :
[2012-10-22 17:18:50] puppet-master[25373]: allocator undefined for Proc
[2012-10-22 17:18:50] puppet-master[25373]: /usr/lib/ruby/1.8/yaml.rb:133:in 
`transfer'
[2012-10-22 17:18:50] puppet-master[25373]: /usr/lib/ruby/1.8/yaml.rb:133:in 
`node_import'
[2012-10-22 17:18:50] puppet-master[25373]: /usr/lib/ruby/1.8/yaml.rb:133:in 
`load'
[2012-10-22 17:18:50] puppet-master[25373]: /usr/lib/ruby/1.8/yaml.rb:133:in 
`load'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/site_ruby/1.8/puppet/util/rails/reference_serializer.rb:6:in 
`unserialize_value'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/site_ruby/1.8/puppet/rails/param_value.rb:64:in 
`find_all_params_from_host'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/site_ruby/1.8/puppet/rails/param_value.rb:63:in `each'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/site_ruby/1.8/puppet/rails/param_value.rb:63:in 
`find_all_params_from_host'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/site_ruby/1.8/puppet/rails/host.rb:232:in 
`find_resources_parameters'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/site_ruby/1.8/puppet/rails/host.rb:119:in 
`find_resources_parameters_tags'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/site_ruby/1.8/puppet/rails/host.rb:101:in `merge_resources'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/site_ruby/1.8/puppet/rails/benchmark.rb:23:in `debug_benchmark'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/site_ruby/1.8/puppet/rails/benchmark.rb:13:in `railsmark'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/gems/1.8/gems/activesupport-2.1.1/lib/active_support/core_ext/benchmark.rb:8:in
 `realtime'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/site_ruby/1.8/puppet/rails/benchmark.rb:13:in `railsmark'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/site_ruby/1.8/puppet/rails/benchmark.rb:23:in `debug_benchmark'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/site_ruby/1.8/puppet/rails/host.rb:100:in `merge_resources'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/catalog/active_record.rb:25:in 
`save'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/site_ruby/1.8/puppet/rails/benchmark.rb:13:in `railsmark'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/gems/1.8/gems/activesupport-2.1.1/lib/active_support/core_ext/benchmark.rb:8:in
 `realtime'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/site_ruby/1.8/puppet/rails/benchmark.rb:13:in `railsmark'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/catalog/active_record.rb:24:in 
`save'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/store_configs.rb:24:in `save'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:195:in `find'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/handler.rb:108:in `do_find'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/handler.rb:71:in `send'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/handler.rb:71:in `process'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick/rest.rb:24:in `service'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/1.8/webrick/httpserver.rb:104:in `service'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/1.8/webrick/httpserver.rb:65:in `run'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:33:in `listen'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/1.8/webrick/server.rb:173:in `call'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/1.8/webrick/server.rb:173:in `start_thread'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/1.8/webrick/server.rb:162:in `start'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/1.8/webrick/server.rb:162:in `start_thread'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/1.8/webrick/server.rb:95:in `start'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/1.8/webrick/server.rb:92:in `each'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/1.8/webrick/server.rb:92:in `start'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/1.8/webrick/server.rb:23:in `start'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/1.8/webrick/server.rb:82:in `start'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:30:in `listen'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:29:in `initialize'
[2012-10-22 17:18:50] puppet-master[25373]: 
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.

Re: [Puppet Users] Puppet on OpenSuSE & SLES

[Niels Abspoel]

Or you can go to https://build.opensuse.org/

They have two projects running:
2.7.19: 
systemsmanagement-puppet

3.0.0:  
systemsmanagement-puppet-devel-package=puppet

and my own
3.0.1: 
home-Aaboe76-branches-systemsmanagement-puppet-devel

These are packages build for suse and tested on my machine.

Greetz,
Niels

Op donderdag 29 maart 2012 15:03:36 UTC+2 schreef Darin Perusich het 
volgende:
>
> You can grab the .spec from the build service project or the srpm links 
> below.
>
> http://download.opensuse.org/repositories/home:/eclipseagent:/puppet/
>
> https://build.opensuse.org/project/show?project=home%3Aeclipseagent%3Apuppet
>
> --
> Later,
> Darin
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/-vYDo6vaqmIJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Puppet on OpenSuSE & SLES

[Niels Abspoel]

If you don't want to compile it yourself:

Look at these:
home project:
https://build.opensuse.org/package/show?package=puppet&project=home%3Aaboe76%3Abranches%3Asystemsmanagement%3Apuppet%3Adevel

devel project maintainer opensuse
https://build.opensuse.org/project/show?project=systemsmanagement%3Apuppet%3Adevel

official maintainer project:
https://build.opensuse.org/package/show?package=puppet&project=systemsmanagement%3Apuppet


Op donderdag 29 maart 2012 15:03:36 UTC+2 schreef Darin Perusich het 
volgende:
>
> You can grab the .spec from the build service project or the srpm links 
> below.
>
> http://download.opensuse.org/repositories/home:/eclipseagent:/puppet/
>
> https://build.opensuse.org/project/show?project=home%3Aeclipseagent%3Apuppet
>
> --
> Later,
> Darin
>
> On Thu, Mar 29, 2012 at 5:03 AM, r0k5t4r > 
> wrote:
> > Hi,
> >
> > would you mind sharing the specfile you have used to build ruby-shadow?
> >
> > Regards,
> > Oliver
> >
> > Am Montag, 12. März 2012 17:46:17 UTC+1 schrieb Jeffrey Watts:
> >>
> >> I took the RHEL/EPEL RPMs for ruby-shadow and puppet and rebuilt them 
> for
> >> SLES.  There are very few things that need changing.  The RHEL/EPEL RPMs
> >> have really well put together SPECfiles.
> >>
> >> I believe I posted the SPECfile diff for puppet to this list a month or 
> so
> >> ago.  You might search the archives.  Mostly what I did was comment out 
> the
> >> Red Hat specific dependencies - it was really easy.  You can build 
> without
> >> Augeas if you're not using it.
> >>
> >> Good luck.
> >> Jeffrey.
> >>
> >> On Mon, Mar 12, 2012 at 5:19 AM, Julien C. 
> >> > 
> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I'm a big fan of Puppet and managed to have my company accept it.
> >>> However, I'm having issues deploying it (I'm used to the debian version
> >>> which works perfectly out of the box) :
> >>>
> >>> - There doesn't seem to be an official repository for Suse (I've seen 
> it
> >>> mentionned in the bugtracker but yum.puppetlabs.com doesn't contain 
> SUSE
> >>> packages).
> >>> - I can't find a package for ruby-shadow.
> >>> - I can't find a package for augeas either.
> >>>
> >>> I circumvented these problems by installing Puppet by hand (tarball) 
> and
> >>> writing ugly code (execs) to manage config files and user passwords.
> >>> However, I'd like to know if I missed anything or if you can suggest
> >>> solutions for any of these 3 issues...
> >>>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Puppet Users" group.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msg/puppet-users/-/z_oXvCuaLJsJ.
> >
> > To post to this group, send email to puppet...@googlegroups.com
> .
> > To unsubscribe from this group, send email to
> > puppet-users...@googlegroups.com .
> > For more options, visit this group at
> > http://groups.google.com/group/puppet-users?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/jTcQeG0uAvwJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: Nginx + passenger + puppetmaster

[Geert Booster]

Hello,

Op donderdag 7 juni 2012 08:44:54 UTC+2 schreef vulzscht het volgende:
>
> i will dig into it a bit more and provide my results here in case of 
> success 
>
>
Did you found any solution? I am looking at the same problems, after a 
fresh puppetmaster install with passenger, getting:

err: Could not retrieve catalog from remote server: Error 403 on SERVER: 
Forbidden request: FQDN(IP.Addr) access to /catalog/fqdn [find] at line 93

./ssl/certs/ca.pem is available...

Regards,

Geert
 

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/dLYkHC9sYxAJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: use regex to ensure multiple directories are absent or exist

[jcbollinger]

On Sunday, October 21, 2012 11:37:25 AM UTC-5, Panaman wrote:
>
> Is it possible to use regex to ensure directories are deleted.
>
> I want to be able to do something like:
>
> file { '/var/directory[1-9]':
>   ensure => absent,
> }
>
> Would also be nice to use regex to ensure directories are present...
>


Puppet is not a scripting language.

You can dress up this sort of thing in various ways, but in the end you 
need to either create a separate resource for each file you want to manage 
(directly), or use an Exec.  For example, you could do this:

define patternfile($pattern, $replace) {
  $filename = regsubst($pattern, $replace, $name)
  file { $filename:
ensure => absent
  }
}

patternfile { [1, 2, 3, 4, 5, 6, 7, 8, 9]:
  pattern => '/var/directoryREPLACEME',
  $replace => 'REPLACEME'
}

You could write something slightly more concise in Puppet's Ruby DSL, but 
it would still amount to declaring a separate resource for each file you 
want to ensure absent.

In practice, what you ask, in the general form about which you ask, is not 
often the best approach to the task.  It may help to step back and look at 
the bigger picture.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/t2p2h6GEZ8MJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: Variables and autoloading

[jcbollinger]

On Sunday, October 21, 2012 6:02:39 PM UTC-5, Guzmán Brasó wrote:
>
> John,
>
> I'm new to puppet and your mails confuse me a little bit... if 
> parameterized classes are not recommended and you suggest when dealing with 
> someone else parameterized class to set it through hiera (Puppet 3). 
> Then I don't understand how to proceed with puppet 2 modules...
>


Here are some of your better choices, none of them especially good:

   1. Upgrade your master to Puppet 3.  The clients can stay at 2.7 if you 
   wish.
   2. Avoid third-party modules whose interfaces involve parametrized 
   classes, unless they have built-in hiera support.
   3. Be very careful and deliberate with the placement of your 
   parametrized-style class declarations, and expect to troubleshoot parse 
   order issues from time to time.
   
 

>
> Should I hack every module I need to set the defaults inside the module?
>


That's an option too, but I wouldn't recommend it.
 

>
> And if making a module, without using parameters, how I can reuse the 
> module with different defaults ? Should I create a different params.pp for 
> each scenario I need and then include it inheriting each one of the 
> defaults, this would be a mess to deal with large arquitectures with many 
> different types of nodes.
>


That is what hiera is for.  Although not integrated into the core until 
Puppet 3, hiera is a widely-used add-on to Puppet 2.  Instead of

class mymodule::foo (
  $param1 = 'default1',
  $param2 = 'default2' ) {
  # declarations
}

I recommend some variation on

class mymodule::foo {
  $param1 = hiera('foo::param1', 'default1')
  $param2 = hiera('foo::param2', 'default2')
  # declarations
}

Then put any needed 'parameter' customizations into your hiera data.  That 
way not only can you avoid parametrized-style class declarations, but you 
also achieve separation of your data from your code.

 

>
> I'm sorry to ask but since we started using puppet (a few months ago) we 
> started doing everything with parameters as puppet docs said on 
> http://docs.puppetlabs.com/guides/parameterized_classes.html and since 
> then we had no issue (yet) with it.  And now you say that parameters are a 
> sickness and should not be used. Then how on Puppet 2? And why it's still 
> puppet docs still recommending it?
>
>
Puppetlabs heavily promoted parametrized classes starting with their 
release as part of Puppet 2.6.  Evidently, they perceived and continue to 
perceive substantial demand for such a feature.  That doesn't mean it was 
ever a good idea.

Having promoted the feature so effectively puts PuppetLabs in a difficult 
position.  At least some of their people will acknowledge the problems with 
parametrized classes, at least in Puppet 2.x.  I can only speculate about 
company policy here, but it would be reasonable for PL to judge that doing 
an about-face on parametrized classes could present credibility and trust 
issues for the company.

PL put a lot of effort into improving parametrized classes for Puppet 3, 
and they are indeed better.  As I have lately written, I think the result 
rescues a lot of parametrized classes that are already in use.  That 
doesn't mean that it's a good idea to write new parametrized classes even 
for Puppet 3, however.

And of course, a lot of people are using parametrized classes 
successfully.  My argument has never been that they don't work, only that 
they exact unneeded costs in productivity and stability relative to the 
best available alternative.  Those costs will scale with the number of 
dependencies between classes.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/r53hq-Tk8CsJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: Failed to set group to '0': Operation not permitted

[jcbollinger]

On Friday, October 19, 2012 9:38:25 AM UTC-5, Dominic wrote:
>
> Hi everyone,
>
> Here is the task, I just need to get the file from master, untar it and 
> execute a file.
>
> Step 1: 
>
> Working as a root user,having the default puppet.conf for root and the 
> agent could get the source file  from master , untar it and execute it.
>
> Step 2: 
>
> Moving to non-root user, I have a different puppet.conf with the conf the 
> master validates the agent and gets me the source , and untar it to the 
> agent , but on the agent side I got the error. 
>
>
> Here is my puppet.conf
>
> [main]
> logdir = /home/user/var/log/puppet
> rundir = /home/user/var/run/puppet
> vardir = /home/user/var/lib/puppet
> ssldir = $vardir/ssl
>  
> server=puppetmaster.example.com
> [agent]
> classfile = $vardir/classes.txt
> localconfig = $vardir/localconfig
> [master]
> certname=puppetmaster.example.com
>
> On executing, 
>
> puppet agent --confdir-/home/user/etc -t, 
>
> Error: Failed to set group to '0': Operation not permitted - 
> /home/user/unix.tar.gz
> Error: /File[/home/user/unix.tar.gz]/ensure: change from absent to file 
> failed: Failed to set group to '0': Operation not permitted - 
> /home/user/.tar.gz
>
> Though I set the tarball of the source in master to 777 permissions, I get 
> the same error.
>
> Your help is great appreciated, please let me know if you need any further 
> info.
>
>
This problem is not directly related to puppet.conf.  It is probably in 
issue in your init.pp file on the master (because that appears to be where 
you declare File[/home/user/unix.tar.gz]).  The manifest leads Puppet to 
believe that the target file is supposed to have group 0, but changing the 
downloaded file's group requires the agent to run as root.

If you post the declaration of that file, then we may be able to tell you 
more.

I have a question, though: what is the purpose of having this run by an 
unprivileged user in the first place?


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/m_CIZDBB3B0J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: Puppet spuriously removing classes from classes.txt

[jcbollinger]

On Friday, October 19, 2012 10:55:03 AM UTC-5, Matt Carroll wrote:
>
> I've been asked to look at a problem on an overseas rig whereby certain 
> bits of config were going awry. This was down to the fact that they were 
> querying the mcollective registration database and feeding back in to the 
> configs, using queries based on class data. The mcollective + mongodb setup 
> is working fine, but it would appear that the classes.txt file which 
> mcollective reads to get configuration management classes is, on certain 
> servers, spuriously being emptied of all classes other than 'settings'
>
> Seeing as the settings class is being left in, I can only assume that it 
> must be puppet doing the modification. Has anyone ever seen behaviour like 
> this before? It's truly bizarre, and even stranger is that after this has 
> happened, sometimes the classes populate again. Every time I've run puppet 
> manually  with puppetd --test or run it --noop, it's run just fine and 
> without noop it always seems to fix the problem, but later the node will 
> show up as having only one class again and even later fix itself, so it's 
> next to impossible to pin down.
>
> This is 2.6.7 on Ubuntu running against a centralised puppetmaster.
>


Are you certain the behavior is buggy?  The fact that Puppet rights itself 
makes me think that Puppet itself is not the problem.

What if there is a cron job (or a human admin) that periodically does 
something like "puppetd --onetime --no-daemonize --tags settings"?  Or what 
if the affected node's manifests use schedules in a way that occasionally 
excludes all classes except 'settings'?  The former, at least, should show 
up in the system log.

You might also get some insight by wrapping puppetd in a script that makes 
a timestamped backup of classes.txt after each run.  Done right, that ought 
to establish whether Puppet is the one writing the unexpected content, and 
if so then the timestamps when the bad files appear might tell you 
something useful.  Perhaps you could dredge the same information out of 
your system logs, but the timestamped backups might be easier to analyze 
(and they would pinpoint where in your logs to look for additional 
information).


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/1RlbAp6sTdMJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: Using Hiera with Parameters set for the Puppet Node

[jcbollinger]

On Friday, October 19, 2012 3:18:59 PM UTC-5, Thomas Biddle wrote:
>
> Is it possible to have Hiera look at a key set for the node first, before 
> looking at other items in the hierarchy?
>
> In particular - I'm using Puppet Dashboard and am setting keys & params 
> for there, so I would like for any value set there for a node to be used 
> over another item in the hiera hierachy. What value would I have to specify 
> in the hierarchy for this, if it is possible?
>


If you specify the levels of your data hierarchy in the conventional way -- 
from most specific to least -- then the hiera() function should do what you 
want automatically.  Do not use hiera_array() or hiera_hash() for this 
purpose, as those are specifically intended for collecting values declared 
at all levels of your hierarchy.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/f5MQvrr3v8kJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: Node specific exported resources

[jcbollinger]

On Friday, October 19, 2012 9:03:39 AM UTC-5, Alex C wrote:
>
> Greetings,
>
> I'm trying to wrap my head around a solution to a problem I'm facing with 
> an exported resources configuration I have.  I'm using the following simple 
> config to build a munin configuration:
>
> @@file { "/etc/munin/munin.conf.d/${::fqdn}.node":
>   content => "[All Hosts;${::fqdn}]
>   address ${ipaddress_eth0}
>   use_node_name yes\n\n",
>   tag => 'munin-node',
> }
>
> File <<| tag == 'munin-node' |>>
>
> I'd like to add the following configuration lines to specifically one of 
> the nodes:
>
>   diskstats_latency.sda.avgrdwait.warning 0:5
>   diskstats_latency.sda.avgwrwait.warning 0:5
>
> Is there a way to cleanly append those configuration lines to the content 
> of the exported resource on that node without redeclaring the entire 
> contents of the file?
>


You cannot append to the already-declared content property, but you may be 
able to build the content you want in the first place.  For example, you 
could initially declare the file along these lines:

$munin_extra = hiera('munin_extra')
@@file { "/etc/munin/munin.conf.d/${::fqdn}.node":
  content => "[All Hosts;${::fqdn}]
  address ${ipaddress_eth0}
  use_node_name yes
  ${munin_extra}\n\n",
  tag => 'munin-node',
}

if you're not already using hiera and you don't want to start, then you 
could achieve something similar via conditional statements and data in your 
manifests, or perhaps more flexibly by converting your content to a 
template and putting whatever processing logic you want into it.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/EKz49aJBJCMJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Possible to exclude an event in Puppet dashboard?

[Calvin Walton]

On Mon, 2012-10-22 at 10:28 +0200, Martin Willemsma wrote:
> Hi All,
> 
> I was wondering if it is possible to NOT show an event in puppet dashboard.
> I have an exec resource that fires of a ruby script. This is triggering a
> changed event on every run, but actually I want to exclude this from
> showing up as "CHANGED"
> 
> Is this possible, if so how can I achieve this?

There's actually a trick you can do with the 'onlyif' and 'unless'
options to the exec type that can accomplish what you want. The expense
is that you no longer get log output from the command on failure:

exec {
"run_myscript" :
unless => "/usr/bin/env ruby ${my_script} ${csv_files}",
command => "/bin/false",
cwd => "${myscript_dir}",
timeout => 0,
logoutput => "on_failure",
}

(This will show up as an error in the puppet run if the command fails,
but not show up at all if it succeeds.)

However, you mentioned something about facts generation in a later post?
Do keep in mind that facts are uploaded to the puppet master *before*
any of the code in your manifest executes, so anything done in your
manifest will only affect the facts for the next puppet run.

-- 
Calvin Walton 


smime.p7s
Description: S/MIME cryptographic signature

Re: [Puppet Users] Possible to exclude an event in Puppet dashboard?

[Martin Willemsma]

2012/10/22 Stephen Gran 

> Hi,
>
> On Mon, 2012-10-22 at 10:28 +0200, Martin Willemsma wrote:
> > Hi All,
> >
> > I was wondering if it is possible to NOT show an event in puppet
> > dashboard. I have an exec resource that fires of a ruby script. This
> > is triggering a changed event on every run, but actually I want to
> > exclude this from showing up as "CHANGED"
>
> The traditional way to have a script run periodically is to put
> something in cron.  Puppet can help you with that.
>
> Cheers,
> --
> Stephen Gran
> Senior Systems Integrator - guardian.co.uk
>
> Please consider the environment before printing this email.
> --
> Visit guardian.co.uk - newspaper of the year
>
> www.guardian.co.ukwww.observer.co.uk www.guardiannews.com
>
> On your mobile, visit m.guardian.co.uk or download the Guardian
> iPhone app www.guardian.co.uk/iphone and iPad edition
> www.guardian.co.uk/iPad
>
> Save up to 37% by subscribing to the Guardian and Observer - choose the
> papers you want and get full digital access.
> Visit guardian.co.uk/subscribe
>
> -
> This e-mail and all attachments are confidential and may also
> be privileged. If you are not the named recipient, please notify
> the sender and delete the e-mail and all attachments immediately.
> Do not disclose the contents to another person. You may not use
> the information for any purpose, or store, or copy, it in any way.
>
> Guardian News & Media Limited is not liable for any computer
> viruses or other material transmitted with or as part of this
> e-mail. You should employ virus checking software.
>
> Guardian News & Media Limited
>
> A member of Guardian Media Group plc
> Registered Office
> PO Box 68164
> Kings Place
> 90 York Way
> London
> N1P 2AP
>
> Registered in England Number 908396
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>
Thank you Steven,

I'm aware of cron resources I also use them. This particular script is
creating a couple of custom facts, that I'm uploading to the
inventory_service  using puppet facts upload preferably I would like to
have in the same or right after the puppet run.

I was hoping to be able to specify a debug level to logging. ( to dashboard
)

Like debug => true

For now I will create a cron to fire off the script.

Thanks for your reply.

-- 
Kind Regards,

Martin Willemsma

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] stages examples/advices

[Danie van Zyl]

My 2cents,

Why not use the stdlib that puppet provides. It contains the following 
stage presets,

class stdlib::stages {

  stage { 'setup':  before => Stage['main'] }
  stage { 'runtime': require => Stage['main'] }
  -> stage { 'setup_infra': }
  -> stage { 'deploy_infra': }
  -> stage { 'setup_app': }
  -> stage { 'deploy_app': }
  -> stage { 'deploy': }

}


I'm going to start using this going forward.

On Wednesday, 20 October 2010 12:48:47 UTC+2, David Schmitt wrote:
>
> On 10/18/2010 6:14 PM, Hunter Haugen wrote:
> > so you could do this:
> >
> > class orden {
> >stage { [ 'repos', 'os', 'gLite', 'post' ]: }
> >Stage['repos'] ->  Stage['os'] ->  Stage['main'] ->  Stage['gLite'] ->
> > Stage['post']
> > }
>
> A style question: wouldn't it be preferable to write it like this:
>
>class orden {
>  stage { 'repos': } -> stage { 'os': } -> stage { 'main': } -> stage 
> { 'gLite': } -> stage { 'post': }
>}
>
>
> Best Regards, David
> -- 
> dasz.at OG  Tel: +43 (0)664 2602670 Web: http://dasz.at
> Klosterneuburg UID: ATU64260999
>
> FB-Nr.: FN 309285 g  FB-Gericht: LG Korneuburg
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/N8wgSj8I07AJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: How to find the utilization of agents

[SRIRAAM DHILIBAN]

Want to know in which yaml file the inventory details of the agents are 
getting saved

On Sunday, 21 October 2012 09:16:21 UTC+5:30, SRIRAAM DHILIBAN wrote:
>
> Is there any way to get the report about how much the agent is 
> utilized and how much time the agent is powered ON using PE ? . Will the 
> agent  send any report when it is powering ON and powering OFF. Or Will the 
> uptime and downtime detail gets saved in the db 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/hDLt_GttNssJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Puppet spuriously removing classes from classes.txt

[R.I.Pienaar]

- Original Message -
> From: "Matt Carroll" 
> To: puppet-users@googlegroups.com
> Sent: Monday, October 22, 2012 10:43:44 AM
> Subject: Re: [Puppet Users] Puppet spuriously removing classes from 
> classes.txt
> 
> Hmm, I'm not sure that this is the same issue... the issue details
> the classes.txt only containing a newline wheras I'm experiencing a
> problem whereby the file sometimes only contains the default class
> 'settings'. It appears as if the node is compiling spuriously
> against a different environment with an empty default class every
> now and again.
> 
> I'm going to look in to the possibility Of upgrading the rig, as it
> may fix the problem, and seeing as it's quite an old version it's
> not really too necessary to know exactly what was causing the
> behaviour.
> 

depending on version it also writes resources.txt, so you can determine
if when classes.txt is empty if it really was not managing any resources.

Being someone who cares deeply for classes.txt, I've not observed this
behavior

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Puppet spuriously removing classes from classes.txt

[Matt Carroll]

Hmm, I'm not sure that this is the same issue... the issue details the 
classes.txt only containing a newline wheras I'm experiencing a problem whereby 
the file sometimes only contains the default class 'settings'. It appears as if 
the node is compiling spuriously against a different environment with an empty 
default class every now and again.

I'm going to look in to the possibility Of upgrading the rig, as it may fix the 
problem, and seeing as it's quite an old version it's not really too necessary 
to know exactly what was causing the behaviour.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/3NhJKOAfRjQJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Possible to exclude an event in Puppet dashboard?

[Stephen Gran]

Hi,

On Mon, 2012-10-22 at 10:28 +0200, Martin Willemsma wrote:
> Hi All, 
> 
> I was wondering if it is possible to NOT show an event in puppet
> dashboard. I have an exec resource that fires of a ruby script. This
> is triggering a changed event on every run, but actually I want to
> exclude this from showing up as "CHANGED" 

The traditional way to have a script run periodically is to put
something in cron.  Puppet can help you with that.

Cheers,
-- 
Stephen Gran
Senior Systems Integrator - guardian.co.uk

Please consider the environment before printing this email.
--
Visit guardian.co.uk - newspaper of the year

www.guardian.co.ukwww.observer.co.uk www.guardiannews.com 

On your mobile, visit m.guardian.co.uk or download the Guardian
iPhone app www.guardian.co.uk/iphone and iPad edition www.guardian.co.uk/iPad 
 
Save up to 37% by subscribing to the Guardian and Observer - choose the papers 
you want and get full digital access. 
Visit guardian.co.uk/subscribe 

-
This e-mail and all attachments are confidential and may also
be privileged. If you are not the named recipient, please notify
the sender and delete the e-mail and all attachments immediately.
Do not disclose the contents to another person. You may not use
the information for any purpose, or store, or copy, it in any way.
 
Guardian News & Media Limited is not liable for any computer
viruses or other material transmitted with or as part of this
e-mail. You should employ virus checking software.

Guardian News & Media Limited

A member of Guardian Media Group plc
Registered Office
PO Box 68164
Kings Place
90 York Way
London
N1P 2AP

Registered in England Number 908396

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Possible to exclude an event in Puppet dashboard?

[Martin Willemsma]

Hi All,

I was wondering if it is possible to NOT show an event in puppet dashboard.
I have an exec resource that fires of a ruby script. This is triggering a
changed event on every run, but actually I want to exclude this from
showing up as "CHANGED"

Is this possible, if so how can I achieve this?

---
myscript:
---

exec {
"run_myscript" :
# run myscript
command => "/usr/bin/env ruby ${my_script} ${csv_files}",
cwd => "${myscript_dir}",
timeout => 0,
logoutput => "on_failure",
}

-- 
Regards,
Martin Willemsma

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] How do design next-gen modules, any guidelines ? a question for gurus...

[Thomas Guthmann]

Hi,

My dilemma is how should I write my module to be "next-gen" ?
Not from a code point of view but from a design/layout point of view.

We wrote our modules for 2.6.x like every beginner would have done: 
write everything in init.pp.


But now, the fashion is to use parameterized classes and Hiera which we 
will use with puppet 2.7.x.


I mainly followed/watched what Example42 was doing. They were using 
$classname::{install|remove|disable|blah} to actually call an action in 
their old modules. It was almost a sub class ($subclass.pp) per action. 
It was easy to read and possibly to maintain.


But now Alessandro from Example42 seems to put everything back in 
init.pp with his nextgen modules...


I like the idea of segregating types or action per files to avoid 
mistakes during edits but at the same time I am wondering why this 
change for example42, is it a limitation for parameterized classes ?


Like everybody, I'd like to write my module using the best and most 
flexible way so it will be easy to modify and to maintain. I don't like 
to redo my modules from scratch each time :)


So, any inputs/insights are welcome. What direction should I/we take ?

I really believe that puppetlabs or a set of gurus should set these 
guidelines so everybody would develop the same way. At the moment, it's 
like "there is more than one way to do it" (perl) but a lot of people 
are after a "this is the best way to do it", to not be confused with 
"there is only way to do it" :)


Note: I like the puppet style guide but it only talks about syntax not
  how to design module the best way.

-Thomas

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.