[Puppet Users] ANNOUNCE: Puppet 2.6.3 - Release Candidate 1 available!

[James Turnbull]

All too quickly we're back with a maintenance release: 2.6.3.  This
release addresses some issues in the 2.6.2 release.

2.6.3 is a maintenance release in the 2.6.x branch and it contains only
bug fixes and no new features or other changes.

The release candidate is available for download at:

http://puppetlabs.com/downloads/puppet/puppet-2.6.3rc1.tar.gz

Please note that all final releases of Puppet are signed with the
Puppet Labs key.

See the Verifying Puppet Download section at
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet

Please test this release candidate and report feedback via the
Puppet Labs Redmine site:

http://projects.puppetlabs.com

Please select an affected version of 2.6.3rc1.

CHANGELOG
3c56705  Fix for #4832 -- Making PSON handle arbitrary binary data
e232770  Minimal fix for #4975 -- only call chage when managing password
age rules
a090e86  Fix for #4963 -- Use correct commands for password expiry on
solaris

Regards

James Turnbull

-- Puppet Labs - http://www.puppetlabs.com C: 503-734-8571

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Puppetrun reports certificates were not trusted

[Douglas Garstang]

On Tue, Oct 12, 2010 at 10:32 AM, Christian <
berwangerchrist...@googlemail.com> wrote:

> Hi all,
>
> All my nodes are signed successfully with the puppetmaster. A manual
> puppetd run works perfectly on every node. A report is generated for
> each run in puppet-dashboard.
>
> All machines are correctly synchronised via ntp.
>
> Using puppetrun on one of my node works without problem. However using
> puppetrun on the rest of the nodes does suddenly not work.
>
> Following is reported:
>
>  Certificates were not trusted: certificate erify failed.
>  finished with exit code 2
>
> Under [puppetmasterd] i set the certname = 
>
> I tried as well to delete the /ssl folder on the client and
> regenerated them but with out success on the puppetrun result.
>
> Has somebody an idea what is going wrong here.
>
>
I've seen this too. Did your time change during a previous puppet run on
your client?

Doug.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] variable modules per client

[Nigel Kersten]

On Wed, Oct 13, 2010 at 8:06 PM, Nigel Kersten  wrote:
> On Wed, Oct 13, 2010 at 10:56 AM, EAMiller  wrote:
>> Hi all - new to puppet - and have gotten as far as configuring a
>> staging server with two of our web apps through puppet.
>>
>> Now we plan to have developer workstations get dev environments
>> through puppet. We have ~8 developers and ~5 web apps we develop. Not
>> every developer works on every project.
>>
>> From my limited experience with puppet I plan to:
>>  1. Ask each developer what their workstation is called, and which
>> apps they work on
>>  2. Create a stanza in node.pp along the lines of:
>>
>> node "devstation-bob" inherits "default" {
>>    include appB;
>>    include abbE;
>> }
>>
>> This is fine for my purposes - but I wonder if there's a better way -
>> I can't imagine scaling the up too far.
>
> Write a custom fact that reads a simple data source like a text file
> that the developers can write to like:
>
> (tested briefly, may have bugs)
>
> webapps_conf = "/etc/webapps.conf"

I should have maybe clarified that this file simply contains lists of
the apps on lines, with no spaces.

appA
appB
appD

etc. You'll want to do a little bit more input validation on the data,
as people are human.

>
> if File.readable?(webapps_conf)
>  f = File.open(webapps_conf, 'r')
>  f.readlines.each do |line|
>    webapp = line.chomp
>    Facter.add("webapp_#{webapp}_enabled") do
>      setcode do
>        "true"
>      end
>    end
>  end
>  f.close
> end
>
> and then you'll have a data source the developers can control that
> specifies what apps they work on, and you can do conditional work in
> your manifests based upon these values.
>
> if $webapp_bar_enabled == "true" {
>  include webapps::bar
> }
>
> etc etc.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] variable modules per client

[Nigel Kersten]

On Wed, Oct 13, 2010 at 10:56 AM, EAMiller  wrote:
> Hi all - new to puppet - and have gotten as far as configuring a
> staging server with two of our web apps through puppet.
>
> Now we plan to have developer workstations get dev environments
> through puppet. We have ~8 developers and ~5 web apps we develop. Not
> every developer works on every project.
>
> From my limited experience with puppet I plan to:
>  1. Ask each developer what their workstation is called, and which
> apps they work on
>  2. Create a stanza in node.pp along the lines of:
>
> node "devstation-bob" inherits "default" {
>    include appB;
>    include abbE;
> }
>
> This is fine for my purposes - but I wonder if there's a better way -
> I can't imagine scaling the up too far.

Write a custom fact that reads a simple data source like a text file
that the developers can write to like:

(tested briefly, may have bugs)

webapps_conf = "/etc/webapps.conf"

if File.readable?(webapps_conf)
  f = File.open(webapps_conf, 'r')
  f.readlines.each do |line|
webapp = line.chomp
Facter.add("webapp_#{webapp}_enabled") do
  setcode do
"true"
  end
end
  end
  f.close
end

and then you'll have a data source the developers can control that
specifies what apps they work on, and you can do conditional work in
your manifests based upon these values.

if $webapp_bar_enabled == "true" {
  include webapps::bar
}

etc etc.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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 client log events, centralized?

[Bruce Richardson]

On Wed, Oct 13, 2010 at 04:09:34PM -0700, Forrie wrote:
> I've noticed that events for puppet client are logged locally (I'm
> just starting out with puppet).   Is there a way to have these events
> sent to a central parser so they might be easily parsed/sorted/acted-
> upon?
> 
> I probably missed a configuration directive.

http://projects.puppetlabs.com/projects/1/wiki/Reports_And_Reporting

-- 
Bruce

Get thee behind me, Stan: for it is written, thou hast gotten me into
another fine mess.  -- Oliver 4:8


signature.asc
Description: Digital signature

Re: [Puppet Users] Puppet client log events, centralized?

[Scott Smith]

Syslog server

On Wed, Oct 13, 2010 at 4:09 PM, Forrie  wrote:

> I've noticed that events for puppet client are logged locally (I'm
> just starting out with puppet).   Is there a way to have these events
> sent to a central parser so they might be easily parsed/sorted/acted-
> upon?
>
> I probably missed a configuration directive.
>
>
> Thanks.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@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.
>
>


-- 
http://about.me/scoot
http://twitter.com/ohlol

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Puppet client log events, centralized?

[Forrie]

I've noticed that events for puppet client are logged locally (I'm
just starting out with puppet).   Is there a way to have these events
sent to a central parser so they might be easily parsed/sorted/acted-
upon?

I probably missed a configuration directive.


Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Exec in 2.6 and environment variables

[Carl.caum]

Well yes, that's true. But I wanted to use an example variable that I knew all 
systems would have. 

On Oct 13, 2010, at 5:16 PM, Patrick  wrote:

> 
> On Oct 13, 2010, at 2:16 PM, Carl Caum wrote:
> 
>> Hello everyone. I'm running in to trouble setting/changing environment 
>> variables for exec resources in 2.6.2.  If the environment variable exists 
>> before I try to run the command, puppet can't seem to change it. For example,
>> 
>> exec {"foo":
>>  environment => "PATH=/blah",
>>  command  => "/bin/bash -c \"echo \$PATH\"",
>>  logoutput   => true;
>> }
>> 
>> returns the old PATH value.  Now, if I make up a new variable that didn't 
>> exist prior to the exec, like MYVAR, it works.
>> 
>> exec {"foo2":
>>  environment => "MYVAR=MYVAL",
>>  command  => "/bin/bash -c \"echo \$MYVAR\"",
>>  logoutput   =>  true;
>> }
>> 
>> returns MYVAL.  Here's where it gets weird.  I get the same exact behavior 
>> if I set the variable in the bash command string.
>> 
>> exec {"foo3":
>>  command  => "/bin/bash -c \"export PATH=/blah; echo \$PATH\"",
>>  logoutput   => true;
>> }
>> 
>> returns the old PATH value.  While this returns MYVAL,
>> 
>> exec {"foo4":
>>  command => "/bin/bash -c \"export MYVAR=MYVAL; echo \$MYVAR\"",
>>  logoutput  =>  true;
>> }
>> 
>> Is this an actual bug or am I missing something?
> 
> PATH is usually declared using the resource variable "path" so I wouldn't be 
> surprised if it acts strange if you declare it in "environment". Might be a 
> bug, but it wouldn't surprise me.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@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-us...@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] Exec in 2.6 and environment variables

[Patrick]

On Oct 13, 2010, at 2:16 PM, Carl Caum wrote:

> Hello everyone. I'm running in to trouble setting/changing environment 
> variables for exec resources in 2.6.2.  If the environment variable exists 
> before I try to run the command, puppet can't seem to change it. For example,
> 
> exec {"foo":
>   environment => "PATH=/blah",
>   command  => "/bin/bash -c \"echo \$PATH\"",
>   logoutput   => true;
> }
> 
> returns the old PATH value.  Now, if I make up a new variable that didn't 
> exist prior to the exec, like MYVAR, it works.
> 
> exec {"foo2":
>   environment => "MYVAR=MYVAL",
>   command  => "/bin/bash -c \"echo \$MYVAR\"",
>   logoutput   =>  true;
> }
> 
> returns MYVAL.  Here's where it gets weird.  I get the same exact behavior if 
> I set the variable in the bash command string.
> 
> exec {"foo3":
>   command  => "/bin/bash -c \"export PATH=/blah; echo \$PATH\"",
>   logoutput   => true;
> }
> 
> returns the old PATH value.  While this returns MYVAL,
> 
> exec {"foo4":
>   command => "/bin/bash -c \"export MYVAR=MYVAL; echo \$MYVAR\"",
>   logoutput  =>  true;
> }
> 
> Is this an actual bug or am I missing something?

PATH is usually declared using the resource variable "path" so I wouldn't be 
surprised if it acts strange if you declare it in "environment". Might be a 
bug, but it wouldn't surprise me.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Variable of define is used more than once

[Dennis Hoppe]

Hello Bruce,

Am 13.10.2010 23:14, schrieb Bruce Richardson:
> On Wed, Oct 13, 2010 at 09:20:18PM +0200, Dennis Hoppe wrote:
>>> This is almost certainly because of where you have included the monit
>>> class, which is not visible in the modules you have attached here.   I
>>> could speculate about that, but I don't know how you've written the rest
>>> of your manifests.
>>
>> maybe you are right. If i use something like that, my problem seems to
>> be solved. Because in this case i am making a node specific declaration,
>> which i have to made for all my nodes and services. But i was looking
>> for some kind of automatism, because the "monit" module should come with
>> certain modules, which are choosing the right "monit" config.
>>
>> node "rumpel" inherits "default" {
>>include apticron
>>include ldap::slave
>>include metche
>>include monit
>>monit::lenny::config { "puppet": }
>>monit::lenny::config { "puppetmaster": }
>>monit::lenny::config { "rsyslog": }
>>monit::lenny::config { "ssh": }
>>include puppet::master
>>include rsyslog::master
>> }
> 
> What a lot of us do is create classes that describe a particular role
> (like "role::storage_server") and put all the smaller classes and
> specialized behaviour in that.  Then you include the "role" class in the
> node and declare any variables that need to be set (or overridden from
> their defaults) in the node as well.  That keeps the node definition
> tidy but also means, since all classes are included at the individual
> node level, that the classes pick up the variable values specific to
> them.
> 
> So I might define a site::role::basic_server class which included monit
> and apticron.  Then I'd define site::role::puppetmaster, make that
> either inherit from or include site::role::basic_server (whichever is
> most appropriate), have it define monit::config { "puppetmaster" } and
> include puppet::master (and so on).  Then I'd have the rumpel node
> include site::role::puppetmaster.
> 
> The benefits I get from this are a) the ability to assign the same role
> to multiple nodes (or to reassign the role from one node to another)
> simply and clearly, b) to be sure that the value of any important
> variable can be overridden for any one node, c) ... oh, there are other
> benefits but those two are good.
> 
> I'm not saying that you shouldn't include more than one class in a node,
> particularly if you have specialist classes which aren't often used, but
> roles are very helpful, especially where you want to establish
> particular dependencies between particular modules or classes.
> 
>>> You have so many duplicate classes that you're bound to slip somewhere
>>> and make the change in one version and not in the other (or do it
>>> slightly differently in the other).  That kind of thing can be very
>>> difficult to trace.
>>
>> Right, some other people at this mailing list already gave me that
>> advice. I know that i have a lot of duplicated code, but i thought this
>> would be easier to maintain, if a release is getting end of live status.
> 
> Which Debian release you are using is really a minor detail; the intent
> behind (for example) a monit module remains the same.  In fact, in the
> two modules you have included, your twinned lenny/squeeze classes are
> *identical* apart from the class names themselves.  Even the templates
> are identical.  You are wasting a lot of time duplicating things that
> are the same.  I'm a litle confused to see no package dependencies in
> those modules - really, a module should be a self-contained unit that
> contains everything that describes the core function.  Even if you
> decide you want a special package-handling module (which can look
> attractive when you first come to Puppet but really is normally not
> worth it), you should be realizing those packages in the relevant
> module.

thank you for your detailed answer. I have not thougt about roles
before, but it really makes sense. I also reviewed my modules and took
notice that this massive use of release declaration has to end. ;)

Regards, Dennis



signature.asc
Description: OpenPGP digital signature

Re: [Puppet Users] Variable of define is used more than once

[Bruce Richardson]

On Wed, Oct 13, 2010 at 09:20:18PM +0200, Dennis Hoppe wrote:
> > This is almost certainly because of where you have included the monit
> > class, which is not visible in the modules you have attached here.   I
> > could speculate about that, but I don't know how you've written the rest
> > of your manifests.
> 
> maybe you are right. If i use something like that, my problem seems to
> be solved. Because in this case i am making a node specific declaration,
> which i have to made for all my nodes and services. But i was looking
> for some kind of automatism, because the "monit" module should come with
> certain modules, which are choosing the right "monit" config.
> 
> node "rumpel" inherits "default" {
>include apticron
>include ldap::slave
>include metche
>include monit
>monit::lenny::config { "puppet": }
>monit::lenny::config { "puppetmaster": }
>monit::lenny::config { "rsyslog": }
>monit::lenny::config { "ssh": }
>include puppet::master
>include rsyslog::master
> }

What a lot of us do is create classes that describe a particular role
(like "role::storage_server") and put all the smaller classes and
specialized behaviour in that.  Then you include the "role" class in the
node and declare any variables that need to be set (or overridden from
their defaults) in the node as well.  That keeps the node definition
tidy but also means, since all classes are included at the individual
node level, that the classes pick up the variable values specific to
them.

So I might define a site::role::basic_server class which included monit
and apticron.  Then I'd define site::role::puppetmaster, make that
either inherit from or include site::role::basic_server (whichever is
most appropriate), have it define monit::config { "puppetmaster" } and
include puppet::master (and so on).  Then I'd have the rumpel node
include site::role::puppetmaster.

The benefits I get from this are a) the ability to assign the same role
to multiple nodes (or to reassign the role from one node to another)
simply and clearly, b) to be sure that the value of any important
variable can be overridden for any one node, c) ... oh, there are other
benefits but those two are good.

I'm not saying that you shouldn't include more than one class in a node,
particularly if you have specialist classes which aren't often used, but
roles are very helpful, especially where you want to establish
particular dependencies between particular modules or classes.

> > You have so many duplicate classes that you're bound to slip somewhere
> > and make the change in one version and not in the other (or do it
> > slightly differently in the other).  That kind of thing can be very
> > difficult to trace.
> 
> Right, some other people at this mailing list already gave me that
> advice. I know that i have a lot of duplicated code, but i thought this
> would be easier to maintain, if a release is getting end of live status.

Which Debian release you are using is really a minor detail; the intent
behind (for example) a monit module remains the same.  In fact, in the
two modules you have included, your twinned lenny/squeeze classes are
*identical* apart from the class names themselves.  Even the templates
are identical.  You are wasting a lot of time duplicating things that
are the same.  I'm a litle confused to see no package dependencies in
those modules - really, a module should be a self-contained unit that
contains everything that describes the core function.  Even if you
decide you want a special package-handling module (which can look
attractive when you first come to Puppet but really is normally not
worth it), you should be realizing those packages in the relevant
module.

-- 
Bruce

It is impolite to tell a man who is carrying you on his shoulders that
his head smells.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Exec in 2.6 and environment variables

[Carl Caum]

Hello everyone. I'm running in to trouble setting/changing environment 
variables for exec resources in 2.6.2.  If the environment variable exists 
before I try to run the command, puppet can't seem to change it. For example,

exec {"foo":
   environment => "PATH=/blah",
   command  => "/bin/bash -c \"echo \$PATH\"",
   logoutput   => true;
}

returns the old PATH value.  Now, if I make up a new variable that didn't exist 
prior to the exec, like MYVAR, it works.

exec {"foo2":
   environment => "MYVAR=MYVAL",
   command  => "/bin/bash -c \"echo \$MYVAR\"",
   logoutput   =>  true;
}

returns MYVAL.  Here's where it gets weird.  I get the same exact behavior if I 
set the variable in the bash command string.

exec {"foo3":
   command  => "/bin/bash -c \"export PATH=/blah; echo \$PATH\"",
   logoutput   => true;
}

returns the old PATH value.  While this returns MYVAL,

exec {"foo4":
   command => "/bin/bash -c \"export MYVAR=MYVAL; echo \$MYVAR\"",
   logoutput  =>  true;
}

Is this an actual bug or am I missing something?

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Variable of define is used more than once

[Dennis Hoppe]

Hello Bruce,

Am 13.10.2010 19:36, schrieb Bruce Richardson:
> On Wed, Oct 13, 2010 at 07:05:29PM +0200, Dennis Hoppe wrote:
>>
>> node "rumpel" inherits "default" {
>>  include apticron
>>  include ldap::slave
>>  include metche
>>  include puppet::master
>>  include rsyslog::master
>> }
>>
>> node "samson" inherits "default" {
>>  include apticron
>>  include ldap::node
>>  include metche
>>  include puppet::node
>>  include rsyslog::node
>> }
>>
>> If i run "puppetd --test --verbose" on host "rumpel" it is getting the
>> "monit" configs for "puppetd" and "puppetmaster", which is intended to
>> be. But the host "samson" is also getting the config for "puppetmaster",
>> which is reproducible.
> 
> This is almost certainly because of where you have included the monit
> class, which is not visible in the modules you have attached here.   I
> could speculate about that, but I don't know how you've written the rest
> of your manifests.

maybe you are right. If i use something like that, my problem seems to
be solved. Because in this case i am making a node specific declaration,
which i have to made for all my nodes and services. But i was looking
for some kind of automatism, because the "monit" module should come with
certain modules, which are choosing the right "monit" config.

node "rumpel" inherits "default" {
   include apticron
   include ldap::slave
   include metche
   include monit
   monit::lenny::config { "puppet": }
   monit::lenny::config { "puppetmaster": }
   monit::lenny::config { "rsyslog": }
   monit::lenny::config { "ssh": }
   include puppet::master
   include rsyslog::master
}

> One thing, though: you have a huge amount of duplicated code there; it's
> more work than you need to do and a potential source of error.  Your
> lenny and squeeze monit classes, for example, are almost identical; it
> would make much more sense to have one class and use selectors ("if",
> "case" etc.) for the minor bits which are different.  As things stand,
> if you change the structure of your monit module, you'll have to make
> changes twice: once in the lenny version, once in the squeeze version.
> You have so many duplicate classes that you're bound to slip somewhere
> and make the change in one version and not in the other (or do it
> slightly differently in the other).  That kind of thing can be very
> difficult to trace.

Right, some other people at this mailing list already gave me that
advice. I know that i have a lot of duplicated code, but i thought this
would be easier to maintain, if a release is getting end of live status.

Anyway, i am experiencing the first trouble with the way how i choose
the releases and should think about a redesign of my puppet modules.
Fortunately i am just at the beginning. ;)

Regards, Dennis



signature.asc
Description: OpenPGP digital signature

[Puppet Users] Re: ANNOUNCE: Puppet Dashboard 1.0.4 Release Candidate 2!

[binaryred]

I've found that version 1.0.4rc2 has a much quicker response on the
web interface than even the 1.0.4rc1 version.  This is great news, as
I find that this was the biggest drawback to using this tool.  I also
appreciate the rpm packages for RHEL4 and 5.  One more step to making
my life easier!

Great progress, and keep up the good work.
Jason

On Oct 13, 2:07 pm, Igal Koshevoy  wrote:
> The Puppet Labs development team would really appreciate your feedback
> on Puppet Dashboard v1.0.4rc2, described below. Please try it out and
> report your experiences, even if it's just, "It works great!"
>
> Puppet Dashboard 1.0.4 is a big step forward in improving the
> application's reliability, user interface, performance and
> documentation. We've done a lot of testing and think this is solid.
> We'd like to ship the final release this week. Upgrading from this
> release candidate to the final release will be trivial.
>
> Thanks!
>
> -igal
>
> On Sat, Oct 9, 2010 at 3:01 PM, James Turnbull  wrote:
> > We're pleased to announce the availability of Puppet Dashboard 1.0.4rc2!
>
> > The 1.0.4 release is a maintenance release, it fixes a number of bugs,
> > improves the user interface, significantly boosts performance and
> > includes better RPM and DEB packages.
>
> > Please try this release candidate and let us know about any issues on
> > the mailing list (http://groups.google.com/group/puppet-users/), or in
> > the ticket tracker with an "Affected Version" of 1.0.4
> > (http://projects.puppetlabs.com/projects/dashboard/).
>
> > If you're interested in what we're hoping to work on next, please see
> > our roadmap and watch or comment on those tickets that are important to
> > you:
>
> >http://projects.puppetlabs.com/projects/dashboard/roadmap
>
> > INSTALLING AND UPGRADING:
>
> > New installation and upgrading instructions are available in the
> > included README, which you can also read online at:
>
> >http://github.com/puppetlabs/puppet-dashboard/blob/v1.0.4rc2/README.m...
>
> > IMPORTANT: This release involves database migrations.  Please see the
> > README.markdown for instructions on applying them.
>
> > USING PACKAGES:
>
> > We're making 1.0.4rc2 packages available for download. The final
> > released packages for 1.0.4 will be available in the Puppet Labs package
> > repository.
>
> > You can install the RPM package for CentOS or RHEL 5.5 by running the
> > following from your shell:
> >  sudo sh -c "rpm -Uvh
> >http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.no...
> > \
> >    cd /tmp/ \
> >    && wget -c
> >http://www.puppetlabs.com/downloads/dashboard/puppet-dashboard-1.0.4r...
> > \
> >    && gpg --keyserver x-hkp://pgp.mit.edu --recv-keys 4bd6ec30 \
> >    && gpg --armor --export 4bd6ec30 > /tmp/puppetlabs.asc \
> >    && rpm --import /tmp/puppetlabs.asc \
> >    && yum install ./puppet-dashboard-1.0.4rc2-1.noarch.rpm"
>
> > Or install the DEB package for Ubuntu 10.04 by running:
> >  sudo sh -c "cd /tmp/ && \
> >    wget -c
> >http://www.puppetlabs.com/downloads/dashboard/puppet-dashboard_1.0.4r...
> > \
> >    dpkg -i puppet-dashboard_1.0.4rc2-1_all.deb; \
> >    apt-get install -f"
>
> > USING THE SOURCE:
>
> > You can download the release candidate from:
> >  http://puppetlabs.com/downloads/dashboard/puppet-dashboard-1.0.4rc2.tgz
>
> > Or check it out using git:
>
> >    git clone git://github.com/puppetlabs/puppet-dashboard.git && \
> >    cd puppet-dashboard && \
> >    git checkout v1.0.4rc2
>
> > RELEASE NOTES:
>
> > v1.0.4rc2
> > -
>
> > * MIGRATION: Fixed slow database queries and improved table indexes when
> > counting nodes and selecting nodes over time.
> > * Fixed node's reports listing page to not throw exceptions.
> > * Fixed .rpm and .deb packages to include all required files, declare
> > all dependencies, set correct permissions and include working startup
> > scripts.
> > * Fixed views to display all dates and times in the same timezone and
> > format.
> > * Fixed views to generate all internal links relative to RAILS_ROOT
> > enabling the site to be served from sub-URIs (Ex: example.com/dashboard/).
> > * Added documentation describing some simple ways to improve the
> > application's performance, see README.
> > * Added task to optimize the database tables which can be run using
> > `rake RAILS_ENV=production db:raw:optimize`.
>
> > v1.0.4rc1
> > -
>
> > * MIGRATION: Fixed truncation of long reports and deleted these invalid
> > records. Please reimport your reports (see README) after migrating to
> > readd these deleted reports.
> > * MIGRATION: Fixed slow database queries on the home page, reports
> > listing page, and site-wide sidebar.
> > * MIGRATION: Fixed orphaned records left behind when classes or groups
> > were deleted, and removed these orphans from the database.
> > * MIGRATION: Fixed duplicate membership records by removing them and
> > preventing new ones from being added, e.g. a node belongs to the same
> > class or group multiple time

Re: [Puppet Users] Problems with Solaris 10 & adduser

[Bruce Richardson]

On Tue, Oct 12, 2010 at 07:59:40AM -0700, nickt wrote:
> 
> err: /Stage[main]/User::Virtual/User[user1]/ensure: change from absent
> to present failed: Could not create user user1: Execution of '/usr/
> sbin/useradd -s /bin/bash -c "Full Name" -d /u/user1 -m user1 returned
> 1:"

What happens if you run 

 /usr/sbin/useradd -s /bin/bash -c "Full Name" -d /u/user1 -m user1

from the command line.

-- 
Bruce

Hierophant: someone who remembers, when you are on the way down,
everything you did to them on the way up.


signature.asc
Description: Digital signature

Re: [Puppet Users] err: Could not retrieve catalog: Could not parse for environment production: Could not find file /etc/puppet/manifests/site.pp warning: Not using cache on failed catalog

[Patrick]

On Oct 12, 2010, at 2:04 AM, spacelee wrote:

> I change my ubuntu to mac os, and rsync my puppet file to the puppet
> server. I run puppetd -tv in the client, and then this error happens
> puppetd -tv
> err: Could not retrieve catalog: Could not parse for environment
> production: Could not find file /etc/puppet/manifests/site.pp
> warning: Not using cache on failed catalog

1) Make SURE you know which server your client is connecting to.
2) Does the file /etc/puppet/manifests/site.pp exist on that server?

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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: ANNOUNCE: Puppet Dashboard 1.0.4 Release Candidate 2!

[Igal Koshevoy]

The Puppet Labs development team would really appreciate your feedback
on Puppet Dashboard v1.0.4rc2, described below. Please try it out and
report your experiences, even if it's just, "It works great!"

Puppet Dashboard 1.0.4 is a big step forward in improving the
application's reliability, user interface, performance and
documentation. We've done a lot of testing and think this is solid.
We'd like to ship the final release this week. Upgrading from this
release candidate to the final release will be trivial.

Thanks!

-igal

On Sat, Oct 9, 2010 at 3:01 PM, James Turnbull  wrote:
> We're pleased to announce the availability of Puppet Dashboard 1.0.4rc2!
>
> The 1.0.4 release is a maintenance release, it fixes a number of bugs,
> improves the user interface, significantly boosts performance and
> includes better RPM and DEB packages.
>
> Please try this release candidate and let us know about any issues on
> the mailing list (http://groups.google.com/group/puppet-users/), or in
> the ticket tracker with an "Affected Version" of 1.0.4
> (http://projects.puppetlabs.com/projects/dashboard/).
>
> If you're interested in what we're hoping to work on next, please see
> our roadmap and watch or comment on those tickets that are important to
> you:
>
> http://projects.puppetlabs.com/projects/dashboard/roadmap
>
> INSTALLING AND UPGRADING:
>
> New installation and upgrading instructions are available in the
> included README, which you can also read online at:
>
> http://github.com/puppetlabs/puppet-dashboard/blob/v1.0.4rc2/README.markdown
>
> IMPORTANT: This release involves database migrations.  Please see the
> README.markdown for instructions on applying them.
>
> USING PACKAGES:
>
> We're making 1.0.4rc2 packages available for download. The final
> released packages for 1.0.4 will be available in the Puppet Labs package
> repository.
>
> You can install the RPM package for CentOS or RHEL 5.5 by running the
> following from your shell:
>  sudo sh -c "rpm -Uvh
> http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm;
> \
>    cd /tmp/ \
>    && wget -c
> http://www.puppetlabs.com/downloads/dashboard/puppet-dashboard-1.0.4rc2-1.noarch.rpm
> \
>    && gpg --keyserver x-hkp://pgp.mit.edu --recv-keys 4bd6ec30 \
>    && gpg --armor --export 4bd6ec30 > /tmp/puppetlabs.asc \
>    && rpm --import /tmp/puppetlabs.asc \
>    && yum install ./puppet-dashboard-1.0.4rc2-1.noarch.rpm"
>
> Or install the DEB package for Ubuntu 10.04 by running:
>  sudo sh -c "cd /tmp/ && \
>    wget -c
> http://www.puppetlabs.com/downloads/dashboard/puppet-dashboard_1.0.4rc2-1_all.deb;
> \
>    dpkg -i puppet-dashboard_1.0.4rc2-1_all.deb; \
>    apt-get install -f"
>
> USING THE SOURCE:
>
> You can download the release candidate from:
>  http://puppetlabs.com/downloads/dashboard/puppet-dashboard-1.0.4rc2.tgz
>
> Or check it out using git:
>
>    git clone git://github.com/puppetlabs/puppet-dashboard.git && \
>    cd puppet-dashboard && \
>    git checkout v1.0.4rc2
>
> RELEASE NOTES:
>
> v1.0.4rc2
> -
>
> * MIGRATION: Fixed slow database queries and improved table indexes when
> counting nodes and selecting nodes over time.
> * Fixed node's reports listing page to not throw exceptions.
> * Fixed .rpm and .deb packages to include all required files, declare
> all dependencies, set correct permissions and include working startup
> scripts.
> * Fixed views to display all dates and times in the same timezone and
> format.
> * Fixed views to generate all internal links relative to RAILS_ROOT
> enabling the site to be served from sub-URIs (Ex: example.com/dashboard/).
> * Added documentation describing some simple ways to improve the
> application's performance, see README.
> * Added task to optimize the database tables which can be run using
> `rake RAILS_ENV=production db:raw:optimize`.
>
> v1.0.4rc1
> -
>
> * MIGRATION: Fixed truncation of long reports and deleted these invalid
> records. Please reimport your reports (see README) after migrating to
> readd these deleted reports.
> * MIGRATION: Fixed slow database queries on the home page, reports
> listing page, and site-wide sidebar.
> * MIGRATION: Fixed orphaned records left behind when classes or groups
> were deleted, and removed these orphans from the database.
> * MIGRATION: Fixed duplicate membership records by removing them and
> preventing new ones from being added, e.g. a node belongs to the same
> class or group multiple times.
> * Fixed user interface for specifying classes and groups to work with
> standards-compliant browsers, autocomplete on keystroke rather than
> submitting, etc.
> * Fixed default node search, it was incorrectly using the "ever failed"
> node query rather than the "all" nodes query.
> * Fixed run-failure chart to correctly count the reports by day.
> * Fixed run-time chart to correctly display its unit-of-measure labels
> as seconds, not milliseconds.
> * Fixed report display and sorting to use the time the report was
> crea

[Puppet Users] variable modules per client

[EAMiller]

Hi all - new to puppet - and have gotten as far as configuring a
staging server with two of our web apps through puppet.

Now we plan to have developer workstations get dev environments
through puppet. We have ~8 developers and ~5 web apps we develop. Not
every developer works on every project.

>From my limited experience with puppet I plan to:
 1. Ask each developer what their workstation is called, and which
apps they work on
 2. Create a stanza in node.pp along the lines of:

node "devstation-bob" inherits "default" {
include appB;
include abbE;
}

This is fine for my purposes - but I wonder if there's a better way -
I can't imagine scaling the up too 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-us...@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] err: Could not retrieve catalog: Could not parse for environment production: Could not find file /etc/puppet/manifests/site.pp warning: Not using cache on failed catalog

[spacelee]

I change my ubuntu to mac os, and rsync my puppet file to the puppet
server. I run puppetd -tv in the client, and then this error happens
puppetd -tv
err: Could not retrieve catalog: Could not parse for environment
production: Could not find file /etc/puppet/manifests/site.pp
warning: Not using cache on failed catalog

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Problems with Solaris 10 & adduser

[nickt]

I maybe be something stupid (just starting to learn Puppet :), but I'm
getting problems trying to create new users.  I just have a really
simple /etc/puppet/modules/user/virtual.pp that looks like this:


class user::virtual {
  @user { "user1":
ensure => "present",
comment => "\"Full Name\"",
home => "/u/user1",
shell => "/bin/bash",
managehome => "true",
  }
}

Then /etc/puppet/modules/user/init.pp that loads it:

import "virtual"

class user::unixteam inherits user::virtual {
  realize(
User["user1"]
  )

}

Then a really simple /etc/puppet/manifests/nodes.pp (loaded by
site.pp):

import "user"


node "mynode.localnet.com" {
   include user::unixteam
}


I start puppetmasterd on the server (an Ubuntu 10.10 box) with "/usr/
local/sbin/puppetmasterd --no-daemonize --verbose --trace debug --
debug" and see no errors.

I run puppetd on the client (a Solaris 10 9/10 box) with "/usr/local/
sbin/puppetd --verbose --no-daemonize --server puppet.mynet.com" and
get errors:

err: /Stage[main]/User::Virtual/User[user1]/ensure: change from absent
to present failed: Could not create user user1: Execution of '/usr/
sbin/useradd -s /bin/bash -c "Full Name" -d /u/user1 -m user1 returned
1:"

Does this sound familiar to anyone?  I know there's an open bug with a
problem in Solaris since puppet 2.6.2 came out, but I applied the
patch (*ONLY* to user_role_add.rb), but that doesn't seem like it's
the same thing.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Variable of define is used more than once

[Bruce Richardson]

On Wed, Oct 13, 2010 at 07:05:29PM +0200, Dennis Hoppe wrote:
> 
> node "rumpel" inherits "default" {
>   include apticron
>   include ldap::slave
>   include metche
>   include puppet::master
>   include rsyslog::master
> }
> 
> node "samson" inherits "default" {
>   include apticron
>   include ldap::node
>   include metche
>   include puppet::node
>   include rsyslog::node
> }
> 
> If i run "puppetd --test --verbose" on host "rumpel" it is getting the
> "monit" configs for "puppetd" and "puppetmaster", which is intended to
> be. But the host "samson" is also getting the config for "puppetmaster",
> which is reproducible.

This is almost certainly because of where you have included the monit
class, which is not visible in the modules you have attached here.   I
could speculate about that, but I don't know how you've written the rest
of your manifests.

One thing, though: you have a huge amount of duplicated code there; it's
more work than you need to do and a potential source of error.  Your
lenny and squeeze monit classes, for example, are almost identical; it
would make much more sense to have one class and use selectors ("if",
"case" etc.) for the minor bits which are different.  As things stand,
if you change the structure of your monit module, you'll have to make
changes twice: once in the lenny version, once in the squeeze version.
You have so many duplicate classes that you're bound to slip somewhere
and make the change in one version and not in the other (or do it
slightly differently in the other).  That kind of thing can be very
difficult to trace.

-- 
Bruce

What would Edward Woodward do?

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Training in Sydney and London

[James Turnbull]

Hi all

Just to let you all know we're running some new user training. 
Including, for the very first time, Puppet Labs down under!


We'll be training in Sydney from Tuesday, November 09, 2010 to Thursday, 
November 11, 2010 at North Ryde - see 
http://puppetlabs-sydney-nov10.eventbrite.com/


And we'll also be in London on Tuesday, November 30, 2010 to Thursday, 
December 02, 2010 - see http://puppet-london-nov-2010.eventbrite.com/


Cheers

James

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To post to this group, send email to puppet-us...@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] Variable of define is used more than once

[Dennis Hoppe]

Hello Nigel,

Am 13.10.2010 18:26, schrieb Nigel Kersten:
> ...
> Can you post the actual error messages you're getting? Is there any
> chance you can isolate the problem such that we have a bit less to
> trawl through?

actually there is no real error message. It is more about the behavior
of the define, especially the $name variable.

I have a module called "puppet" which is able to handle "puppetd" and
"puppetmaster" specific configs. It also includes the "monit" module and
should deploy "/etc/monit/conf.d/puppetmaster" for the host "rumpel" and
"/etc/monit/conf.d/puppet" for "samson".

node "rumpel" inherits "default" {
include apticron
include ldap::slave
include metche
include puppet::master
include rsyslog::master
}

node "samson" inherits "default" {
include apticron
include ldap::node
include metche
include puppet::node
include rsyslog::node
}

If i run "puppetd --test --verbose" on host "rumpel" it is getting the
"monit" configs for "puppetd" and "puppetmaster", which is intended to
be. But the host "samson" is also getting the config for "puppetmaster",
which is reproducible.

I think this has something to do with the place or order, where i
include the monit module. Of course i could use the ressource "File[]"
instead of calling the define, but i wanted to learn somthing new and
could not know that it would be so hard to use define over several
modules. ;)

Regards, Dennis



signature.asc
Description: OpenPGP digital signature

Re: [Puppet Users] Variable of define is used more than once

[Nigel Kersten]

On Wed, Oct 13, 2010 at 9:01 AM, Nigel Kersten  wrote:
> On Wed, Oct 13, 2010 at 8:54 AM, Dennis Hoppe
>  wrote:
>> Hello Felix,
>>
>> Am 13.10.2010 16:43, schrieb Felix Frank:
>>> On 10/13/2010 04:37 PM, Disconnect wrote:
    - lenny (stable)  (admin):
    centralised configuration management for networks
    0.24.5-3: all
    - lenny-backports
 (admin):
 centralised configuration management for networks
    0.25.4-2~bpo50+1 [*backports* ]: all

 Looks pretty out of date to me. Lets see.. 0.24.5-1 was packaged on "Thu, 
 24
 Jul 2008 10:58:08 +0100". (Days after release, which is good, but over 2
 years ago, which is bad..) Looks like 12 releases since then.

 0.25.4 was released upstream in January and is -also- not "up to date"
 (minor, major, then another minor revs since then..)
>>>
>>> What's with the nitpicking? They call it "Debian stable" because it is,
>>> well, stable. You get what you choose.
>>>
>>> I think the OP suggest that Reductive Labs offer the download of
>>> packages that both
>>> a) will install on Debian (stable?) and
>>> b) offer varying amounts of bleeding-edged-ness.
>>>
>>> This idea is not without merit, I might add.
>>
>> i know Debian is very stable, but they also have really long release
>> cycles and sometimes you just want to have the current features.
>>
>> There is a reason, why many companies are offering her own Debian
>> packages and i have had many discussions with some of my colleagues,
>> which are debian developers.
>
> We have an enthusiastic and active Debian packaging group (Hi Stig
> Mathias Russ!) and I think we're managing to balance Debian policy and
> user needs pretty well.
>
> If you want the current features, grab the more recent packages. This
> is standard Debian practice, and working with distro policy is a good
> thing for upstream vendors to do in my opinion.
>
> http://www.debian.org/doc/FAQ/ch-choosing.en.html#s3.1.3
>
> "As you can see, stability and novelty are two opposing ends of the
> spectrum. If stability is required: install stable distribution. If
> you want to work with the latest packages, then install unstable."
>
> We do need to post up decent instructions on using git-buildpackage to
> package your own debs if needed, as it's a simple couple of commands.
> I've sent it to this list at least once, but we need to document this
> on the puppet deb pkg site.
>
>
>> But that is not the point. I need help with my module. ;)
>
> Lets get it back on the rails then :)
>
> You might find more luck if you put the manifests into pastebin.com or
> directly inline, as it's much easier for people to glance at your
> setup without requiring them to download attachments and unpack them.
>

I did just unpack all your manifests and it's hard to work out what
the actual problem is Dennis, as you've provided a lot of stuff.

Can you post the actual error messages you're getting? Is there any
chance you can isolate the problem such that we have a bit less to
trawl through?


-- 
nigel

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] "No source module metadata found"??

[Jon Charette]

Trying to debug something simple that I'm sure I'm just missing.

I create a module, mysql.  Code is at http://www.pastie.org/1218470

I try to apply it and I get the following error:

err: No source module metadata provided for mysql

Server is 2.6.2, client is 2.6.1.

Ideas?

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Variable of define is used more than once

[Nigel Kersten]

On Wed, Oct 13, 2010 at 8:54 AM, Dennis Hoppe
 wrote:
> Hello Felix,
>
> Am 13.10.2010 16:43, schrieb Felix Frank:
>> On 10/13/2010 04:37 PM, Disconnect wrote:
>>>    - lenny (stable)  (admin):
>>>    centralised configuration management for networks
>>>    0.24.5-3: all
>>>    - lenny-backports
>>> (admin):
>>> centralised configuration management for networks
>>>    0.25.4-2~bpo50+1 [*backports* ]: all
>>>
>>> Looks pretty out of date to me. Lets see.. 0.24.5-1 was packaged on "Thu, 24
>>> Jul 2008 10:58:08 +0100". (Days after release, which is good, but over 2
>>> years ago, which is bad..) Looks like 12 releases since then.
>>>
>>> 0.25.4 was released upstream in January and is -also- not "up to date"
>>> (minor, major, then another minor revs since then..)
>>
>> What's with the nitpicking? They call it "Debian stable" because it is,
>> well, stable. You get what you choose.
>>
>> I think the OP suggest that Reductive Labs offer the download of
>> packages that both
>> a) will install on Debian (stable?) and
>> b) offer varying amounts of bleeding-edged-ness.
>>
>> This idea is not without merit, I might add.
>
> i know Debian is very stable, but they also have really long release
> cycles and sometimes you just want to have the current features.
>
> There is a reason, why many companies are offering her own Debian
> packages and i have had many discussions with some of my colleagues,
> which are debian developers.

We have an enthusiastic and active Debian packaging group (Hi Stig
Mathias Russ!) and I think we're managing to balance Debian policy and
user needs pretty well.

If you want the current features, grab the more recent packages. This
is standard Debian practice, and working with distro policy is a good
thing for upstream vendors to do in my opinion.

http://www.debian.org/doc/FAQ/ch-choosing.en.html#s3.1.3

"As you can see, stability and novelty are two opposing ends of the
spectrum. If stability is required: install stable distribution. If
you want to work with the latest packages, then install unstable."

We do need to post up decent instructions on using git-buildpackage to
package your own debs if needed, as it's a simple couple of commands.
I've sent it to this list at least once, but we need to document this
on the puppet deb pkg site.


> But that is not the point. I need help with my module. ;)

Lets get it back on the rails then :)

You might find more luck if you put the manifests into pastebin.com or
directly inline, as it's much easier for people to glance at your
setup without requiring them to download attachments and unpack them.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Variable of define is used more than once

[Dennis Hoppe]

Hello Felix,

Am 13.10.2010 16:43, schrieb Felix Frank:
> On 10/13/2010 04:37 PM, Disconnect wrote:
>>- lenny (stable)  (admin):
>>centralised configuration management for networks
>>0.24.5-3: all
>>- lenny-backports
>> (admin):
>> centralised configuration management for networks
>>0.25.4-2~bpo50+1 [*backports* ]: all
>>
>> Looks pretty out of date to me. Lets see.. 0.24.5-1 was packaged on "Thu, 24
>> Jul 2008 10:58:08 +0100". (Days after release, which is good, but over 2
>> years ago, which is bad..) Looks like 12 releases since then.
>>
>> 0.25.4 was released upstream in January and is -also- not "up to date"
>> (minor, major, then another minor revs since then..)
> 
> What's with the nitpicking? They call it "Debian stable" because it is,
> well, stable. You get what you choose.
> 
> I think the OP suggest that Reductive Labs offer the download of
> packages that both
> a) will install on Debian (stable?) and
> b) offer varying amounts of bleeding-edged-ness.
> 
> This idea is not without merit, I might add.

i know Debian is very stable, but they also have really long release
cycles and sometimes you just want to have the current features.

There is a reason, why many companies are offering her own Debian
packages and i have had many discussions with some of my colleagues,
which are debian developers.

But that is not the point. I need help with my module. ;)

Regards, Dennis






signature.asc
Description: OpenPGP digital signature

Re: [Puppet Users] Variable of define is used more than once

[Patrick]

On Oct 13, 2010, at 8:44 AM, Stu Teasdale wrote:

> On Wed, Oct 13, 2010 at 10:37:03AM -0400, Disconnect wrote:
>>   - lenny (stable)  (admin):
>>   centralised configuration management for networks
>>   0.24.5-3: all
>>   - lenny-backports
>> (admin):
>> centralised configuration management for networks
>>   0.25.4-2~bpo50+1 [*backports* ]: all
>> 
>> Looks pretty out of date to me. Lets see.. 0.24.5-1 was packaged on "Thu, 24
>> Jul 2008 10:58:08 +0100". (Days after release, which is good, but over 2
>> years ago, which is bad..) Looks like 12 releases since then.
>> 
>> 0.25.4 was released upstream in January and is -also- not "up to date"
>> (minor, major, then another minor revs since then..)
> 
> Sid has 0.26.0, and experimental has 0.26.1. In my experience 
> (admittedly not with 0.26.x) versions from sid have always installed 
> fine on current debian stable, otherwise backporting yourself is usually 
> fairly easy.

This might have been what you meant, but I've heard t's usually a good idea to 
pick a version of facter that's kind of close to puppets version.  (or newer 
than puppet's version)

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Variable of define is used more than once

[Stu Teasdale]

On Wed, Oct 13, 2010 at 10:37:03AM -0400, Disconnect wrote:
>- lenny (stable)  (admin):
>centralised configuration management for networks
>0.24.5-3: all
>- lenny-backports
> (admin):
> centralised configuration management for networks
>0.25.4-2~bpo50+1 [*backports* ]: all
> 
> Looks pretty out of date to me. Lets see.. 0.24.5-1 was packaged on "Thu, 24
> Jul 2008 10:58:08 +0100". (Days after release, which is good, but over 2
> years ago, which is bad..) Looks like 12 releases since then.
> 
> 0.25.4 was released upstream in January and is -also- not "up to date"
> (minor, major, then another minor revs since then..)

Sid has 0.26.0, and experimental has 0.26.1. In my experience 
(admittedly not with 0.26.x) versions from sid have always installed 
fine on current debian stable, otherwise backporting yourself is usually 
fairly easy.

Stu
-- 
>From the prompt of Stu Teasdale

Start the day with a smile.  After that you can be your nasty old self again.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Variable of define is used more than once

[Nigel Kersten]

On Wed, Oct 13, 2010 at 7:43 AM, Felix Frank
 wrote:
> On 10/13/2010 04:37 PM, Disconnect wrote:
>>    - lenny (stable)  (admin):
>>    centralised configuration management for networks
>>    0.24.5-3: all
>>    - lenny-backports
>> (admin):
>> centralised configuration management for networks
>>    0.25.4-2~bpo50+1 [*backports* ]: all
>>
>> Looks pretty out of date to me. Lets see.. 0.24.5-1 was packaged on "Thu, 24
>> Jul 2008 10:58:08 +0100". (Days after release, which is good, but over 2
>> years ago, which is bad..) Looks like 12 releases since then.
>>
>> 0.25.4 was released upstream in January and is -also- not "up to date"
>> (minor, major, then another minor revs since then..)
>
> What's with the nitpicking? They call it "Debian stable" because it is,
> well, stable. You get what you choose.
>
> I think the OP suggest that Reductive Labs offer the download of
> packages that both
> a) will install on Debian (stable?) and
> b) offer varying amounts of bleeding-edged-ness.
>
> This idea is not without merit, I might add.

Have you tried running the recent packages on Debian stable? They do
work, you're more than welcome to go to a bleeding edge release if you
wish.

This is all pretty standard practice for Debian...

I wasn't being sarcastic. I was pointing out the more recent packages
you're welcome to try.

>
> Cheers,
> Felix
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@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.
>
>



-- 
nigel

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] modifiying facts that facter collects

[David Grundy]

Thanks Patrick.

Almost immediately after sending this post I came across this

http://projects.puppetlabs.com/projects/1/wiki/Adding_Facts

Just what I was looking for.

Cheers,

David


On Tue, Oct 12, 2010 at 5:49 PM, Patrick  wrote:

> The phrase you're looking for to add facts to a single machine is "custom
> facts". (Google it)
>
> If you want to push them out automatically using puppet, try "adding
> facts". (Google it)
>
>
> On Oct 12, 2010, at 4:20 PM, David Grundy wrote:
>
> > Hello All.
> >
> > Is there some way to create new facts for facter to report?  Is there a
> configuration file somewhere for facter?  Thanks in advance.
> >
> > David
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> > To post to this group, send email to puppet-us...@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-us...@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-us...@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 and Augeas

[Kikanny]

Yeah. Was just wondering if there was a better way. Thanks though!

On Oct 13, 11:06 am, Patrick  wrote:
> There isn't an easy way that I know of without writing your own puppet 
> runner.  I only know of this being an issue with Augeas and Mysql though.  
> Why not just install libaugeas-ruby (or whatever it's called) when you 
> install puppet?
>
> On Oct 13, 2010, at 6:58 AM, Kikanny wrote:
>
> > Is it possible for Puppet to make those two runs automatically back to
> > back? For example, the first run does modules A and B. The second run
> > includes module C right after the first run is completed. I hope that
> > made sense!
>
> > On Oct 13, 9:52 am, Felix Frank 
> > wrote:
> >> On 10/13/2010 03:48 PM, Kikanny wrote:
>
> >>> Hi. Is there any way to make puppet run a particular module first
> >>> before another module is run. For example, I'm using the augeas
> >>> resource type in one of the modules. But libaugeas-ruby1.8 is not
> >>> installed in the client machine. So when the catalog is run, I get the
> >>> following error: Could not find a default provider for augeas. So I
> >>> built another module that will install the libaugeas-ruby1.8 package.
> >>> However, I still get the same error. So I thought making this module
> >>> run first would solve the problem. Is this possible? Or is there any
> >>> other smart way to go about this? Thanks!
>
> >> Hi,
>
> >> you won't solve this inside puppet. Puppet cannot enhance itself with
> >> additional providers *during* a run.
> >> So your manifest will require at least two runs, no matter the order of
> >> execution.
>
> >> Cheers,
> >> Felix
>
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Puppet Users" group.
> > To post to this group, send email to puppet-us...@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > puppet-users+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://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-us...@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] Variable of define is used more than once

[Bruce Richardson]

On Wed, Oct 13, 2010 at 11:07:27AM -0400, Disconnect wrote:
> 
> Note that I didn't reply to the OP, I replied to Nigel's sarcasm.
> 

You could take this up with one of the Debian puppet package
maintainers.  Oh, but then you already have...

-- 
Bruce

I unfortunately do not know how to turn cheese into gold.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Variable of define is used more than once

[Disconnect]

Sure, Debian stable -is- stable, and there is a lot to be said for that.
(Ditto for Ubuntu LTS.) The statement was (somewhat rudely) "they aren't
outdated, go here and see". 2+ years counts as "outdated".
Last-major-version and most of a year old is "outdated".

Note that I didn't reply to the OP, I replied to Nigel's sarcasm.

On Wed, Oct 13, 2010 at 10:43 AM, Felix Frank <
felix.fr...@alumni.tu-berlin.de> wrote:

> On 10/13/2010 04:37 PM, Disconnect wrote:
> >- lenny (stable)  (admin):
> >centralised configuration management for networks
> >0.24.5-3: all
> >- lenny-backports
> > (admin):
> > centralised configuration management for networks
> >0.25.4-2~bpo50+1 [*backports* ]: all
> >
> > Looks pretty out of date to me. Lets see.. 0.24.5-1 was packaged on "Thu,
> 24
> > Jul 2008 10:58:08 +0100". (Days after release, which is good, but over 2
> > years ago, which is bad..) Looks like 12 releases since then.
> >
> > 0.25.4 was released upstream in January and is -also- not "up to date"
> > (minor, major, then another minor revs since then..)
>
> What's with the nitpicking? They call it "Debian stable" because it is,
> well, stable. You get what you choose.
>
> I think the OP suggest that Reductive Labs offer the download of
> packages that both
> a) will install on Debian (stable?) and
> b) offer varying amounts of bleeding-edged-ness.
>
> This idea is not without merit, I might add.
>
> Cheers,
> Felix
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@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-us...@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 and Augeas

[Patrick]

There isn't an easy way that I know of without writing your own puppet runner.  
I only know of this being an issue with Augeas and Mysql though.  Why not just 
install libaugeas-ruby (or whatever it's called) when you install puppet?

On Oct 13, 2010, at 6:58 AM, Kikanny wrote:

> Is it possible for Puppet to make those two runs automatically back to
> back? For example, the first run does modules A and B. The second run
> includes module C right after the first run is completed. I hope that
> made sense!
> 
> On Oct 13, 9:52 am, Felix Frank 
> wrote:
>> On 10/13/2010 03:48 PM, Kikanny wrote:
>> 
>>> Hi. Is there any way to make puppet run a particular module first
>>> before another module is run. For example, I'm using the augeas
>>> resource type in one of the modules. But libaugeas-ruby1.8 is not
>>> installed in the client machine. So when the catalog is run, I get the
>>> following error: Could not find a default provider for augeas. So I
>>> built another module that will install the libaugeas-ruby1.8 package.
>>> However, I still get the same error. So I thought making this module
>>> run first would solve the problem. Is this possible? Or is there any
>>> other smart way to go about this? Thanks!
>> 
>> Hi,
>> 
>> you won't solve this inside puppet. Puppet cannot enhance itself with
>> additional providers *during* a run.
>> So your manifest will require at least two runs, no matter the order of
>> execution.
>> 
>> Cheers,
>> Felix
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@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-us...@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] Variable of define is used more than once

[Felix Frank]

On 10/13/2010 04:37 PM, Disconnect wrote:
>- lenny (stable)  (admin):
>centralised configuration management for networks
>0.24.5-3: all
>- lenny-backports
> (admin):
> centralised configuration management for networks
>0.25.4-2~bpo50+1 [*backports* ]: all
> 
> Looks pretty out of date to me. Lets see.. 0.24.5-1 was packaged on "Thu, 24
> Jul 2008 10:58:08 +0100". (Days after release, which is good, but over 2
> years ago, which is bad..) Looks like 12 releases since then.
> 
> 0.25.4 was released upstream in January and is -also- not "up to date"
> (minor, major, then another minor revs since then..)

What's with the nitpicking? They call it "Debian stable" because it is,
well, stable. You get what you choose.

I think the OP suggest that Reductive Labs offer the download of
packages that both
a) will install on Debian (stable?) and
b) offer varying amounts of bleeding-edged-ness.

This idea is not without merit, I might add.

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Variable of define is used more than once

[Disconnect]

   - lenny (stable)  (admin):
   centralised configuration management for networks
   0.24.5-3: all
   - lenny-backports
(admin):
centralised configuration management for networks
   0.25.4-2~bpo50+1 [*backports* ]: all

Looks pretty out of date to me. Lets see.. 0.24.5-1 was packaged on "Thu, 24
Jul 2008 10:58:08 +0100". (Days after release, which is good, but over 2
years ago, which is bad..) Looks like 12 releases since then.

0.25.4 was released upstream in January and is -also- not "up to date"
(minor, major, then another minor revs since then..)

On Wed, Oct 13, 2010 at 10:26 AM, Nigel Kersten  wrote:

> > BTW: I would love to see that Puppet Labs is offering his own packages,
> > like VirtualBox or other companies, because the Debian packages are
> > often out-of-date.
>
> They are?
>
> http://packages.debian.org/puppet
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Variable of define is used more than once

[Nigel Kersten]

On Wed, Oct 13, 2010 at 12:31 AM, Dennis Hoppe
 wrote:
> Hello,
>
> i am using "puppet 0.25.4" at "debian 5.0.6" and have noticed, that the
> "puppet" or "puppetmaster" process sometimes is dying. Of course i could
> use the "cron" instead of the "deamon", but i have decided to write a
> module for "monit".
>
> To make this module much dynamic as possible, it is using a define which
> will be called at several other modules to ship out a service specific
> config file.
>
> In this case the variable "$name" is used more than once and other hosts
> are getting the file "puppetmaster". I am pretty sure that this is my
> fault, but at this point i did not see a solution. Please, give me a hint.
>
> BTW: I would love to see that Puppet Labs is offering his own packages,
> like VirtualBox or other companies, because the Debian packages are
> often out-of-date.

They are?

http://packages.debian.org/puppet



>
> Regards, Dennis
>



-- 
nigel

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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 and Augeas

[Kikanny]

Is it possible for Puppet to make those two runs automatically back to
back? For example, the first run does modules A and B. The second run
includes module C right after the first run is completed. I hope that
made sense!

On Oct 13, 9:52 am, Felix Frank 
wrote:
> On 10/13/2010 03:48 PM, Kikanny wrote:
>
> > Hi. Is there any way to make puppet run a particular module first
> > before another module is run. For example, I'm using the augeas
> > resource type in one of the modules. But libaugeas-ruby1.8 is not
> > installed in the client machine. So when the catalog is run, I get the
> > following error: Could not find a default provider for augeas. So I
> > built another module that will install the libaugeas-ruby1.8 package.
> > However, I still get the same error. So I thought making this module
> > run first would solve the problem. Is this possible? Or is there any
> > other smart way to go about this? Thanks!
>
> Hi,
>
> you won't solve this inside puppet. Puppet cannot enhance itself with
> additional providers *during* a run.
> So your manifest will require at least two runs, no matter the order of
> execution.
>
> Cheers,
> Felix

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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 and Augeas

[Felix Frank]

On 10/13/2010 03:48 PM, Kikanny wrote:
> Hi. Is there any way to make puppet run a particular module first
> before another module is run. For example, I'm using the augeas
> resource type in one of the modules. But libaugeas-ruby1.8 is not
> installed in the client machine. So when the catalog is run, I get the
> following error: Could not find a default provider for augeas. So I
> built another module that will install the libaugeas-ruby1.8 package.
> However, I still get the same error. So I thought making this module
> run first would solve the problem. Is this possible? Or is there any
> other smart way to go about this? Thanks!
> 

Hi,

you won't solve this inside puppet. Puppet cannot enhance itself with
additional providers *during* a run.
So your manifest will require at least two runs, no matter the order of
execution.

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Puppet and Augeas

[Kikanny]

Hi. Is there any way to make puppet run a particular module first
before another module is run. For example, I'm using the augeas
resource type in one of the modules. But libaugeas-ruby1.8 is not
installed in the client machine. So when the catalog is run, I get the
following error: Could not find a default provider for augeas. So I
built another module that will install the libaugeas-ruby1.8 package.
However, I still get the same error. So I thought making this module
run first would solve the problem. Is this possible? Or is there any
other smart way to go about this? Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] [0.25.5] Default provider

[Stefan Goethals]

A few things.

David Schmitt has made mysql modules.
http://forge.puppetlabs.com/DavidSchmitt/mysql
maybe you can take a look at them.

Even with his modules i get the same error when configuring a new node.

The problem i saw is that the mysql plugins are synced at the beginning of a
run with pluginsync.
The module is 'checked' at that time. My recepies install MySQL but have not
run at that time obviously.
The plugin does not find the provider 'mysql' so it fails and as a result
MySQL never gets installed.
This is a vicious circle. The only way i have found so far is to disable the
use of that module before having MySQL installed.

This seems to be a problem in the way plugins get installed.

I don't know if there is a bug in David Schmitt's plugins or if a bug needs
to be opened about this for puppet.

Regards,

Stefan - Zipkid - Goethals.


On Tue, Oct 12, 2010 at 2:56 PM, Tim Stoop  wrote:

> Hi all,
>
> To start, using puppet 0.25.5 on Debian Lenny with Ruby
> 1.8.7.72-3lenny1.
>
> I'm giving ruby a shot and am trying to build my own types for several
> applications and modify available types found on the 'net for our
> usage. However, I keep running into problems with the default provider
> it selects. Is there a document somewhere that describes how the
> default provider is selected? I am currently modifying the mysql types
> from the camptocamp repo[0] and trying to get it to work on Debian. I
> only modified the command so it would include --defaults-file=/etc/
> mysql/debian.cnf. But when I try to use the type, I get:
>
> err: Could not run Puppet configuration client: Could not find a
> default provider for mysql_database
>
> So I tried adding the line:
>
> defaultfor :operatingsystem => :debian
>
> To the providers. But I'm still getting the message the it cannot find
> the default provider. I've been searching online for documentation on
> how to modify the type so it would know which provider to select, but
> although there are a lot of types findable, it's very hard to find
> specific documentation about the API used in types. Unless I'm missing
> something, then please point me to this API! Otherwise, I'd appreciate
> any clues on why my server cannot find the default provider. It only
> has this problem with types I added to modules. I'm a bit at a loss.
>
> [0] http://github.com/camptocamp/puppet-mysql/tree/master/lib/puppet
>
> --
> Kind regards,
> Tim (tim|mac on irc)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@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-us...@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: [0.25.5] Default provider

[Patrick]

Yes.  Check if it's a client or server error.  Try 

On Oct 13, 2010, at 1:39 AM, Tim Stoop wrote:

> Hi Patrick,
> 
> On Oct 12, 10:34 pm, Patrick  wrote:
>> I think this means the plugin(the .rb files) are getting found or aren't all 
>> getting found.  What's the complete local path to mysql_database.rb?
>> 
>> Mine would be in:
>> /etc/puppet/modules/whatever/lib/puppet/type/mysql_database.rb
>> /etc/puppet/modules/whatever/lib/puppet/type/provider/mysql_database/mysql_ 
>> database.rb
>> 
>> (Note that those are two different files.)
> 
> I've got two different files too:
> 
> /srv/puppet/generic/mysql/lib/puppet/type/mysql_database.rb
> /srv/puppet/generic/mysql/lib/puppet/provider/mysql_database/mysql.rb
> 
> And I've noticed they get copied to the client, because they're in /
> var/lib/puppet/lib/puppet. I'm a bit at a loss... Any more things I
> should check?

You want to find out if the error is coming from the master or client.  I don't 
remember how to do this.

Then, you want to make sure that what ever is having trouble is loading plugins 
from /var/lib/puppet/lib/puppet.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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: [0.25.5] Default provider

[Tim Stoop]

Hi Patrick,

On Oct 12, 10:34 pm, Patrick  wrote:
> I think this means the plugin(the .rb files) are getting found or aren't all 
> getting found.  What's the complete local path to mysql_database.rb?
>
> Mine would be in:
> /etc/puppet/modules/whatever/lib/puppet/type/mysql_database.rb
> /etc/puppet/modules/whatever/lib/puppet/type/provider/mysql_database/mysql_ 
> database.rb
>
> (Note that those are two different files.)

I've got two different files too:

/srv/puppet/generic/mysql/lib/puppet/type/mysql_database.rb
/srv/puppet/generic/mysql/lib/puppet/provider/mysql_database/mysql.rb

And I've noticed they get copied to the client, because they're in /
var/lib/puppet/lib/puppet. I'm a bit at a loss... Any more things I
should check?

--
Kind regards,
Tim

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Variable of define is used more than once

[Dennis Hoppe]

Hello,

i am using "puppet 0.25.4" at "debian 5.0.6" and have noticed, that the
"puppet" or "puppetmaster" process sometimes is dying. Of course i could
use the "cron" instead of the "deamon", but i have decided to write a
module for "monit".

To make this module much dynamic as possible, it is using a define which
will be called at several other modules to ship out a service specific
config file.

In this case the variable "$name" is used more than once and other hosts
are getting the file "puppetmaster". I am pretty sure that this is my
fault, but at this point i did not see a solution. Please, give me a hint.

BTW: I would love to see that Puppet Labs is offering his own packages,
like VirtualBox or other companies, because the Debian packages are
often out-of-date.

Regards, Dennis


monit.tar.gz
Description: application/gzip


puppet.tar.gz
Description: application/gzip


signature.asc
Description: OpenPGP digital signature