Re: [Puppet Users] Re: parameterized classes and variable inheritance

[Ashley Gould]

On Fri, Mar 18, 2011 at 11:15:56AM -0700, jcbollinger wrote:
> 
> 
> On Mar 17, 6:03 pm, Ashley Gould  wrote:
> > I'm hoping to avoid using subclasses, because there would have to
> > be oodles of them to accomodate the all the variations between nodes.
> >
> > node default {
> >     class { sudoers: }
> >
> > }
> >
> > node 'sl11lab02' inherits default {
> >
> >     # this runs but does nothing
> >     Class[sudoers] { additional_rules => [ "$rules_uas" ] }
> >
> >     # this errors with "Cannot assign to variables in other namespaces"
> >     #$sudoers::additional_rules = [ "$rules_uas" ]
> >
> >     # this errors with "Class[Sudoers] is already defined"
> >     #class { sudoers: additional_rules => [ "$rules_uas" ] }
> >
> > }
> 
> Node inheritance is not the same as class inheritance.  Only the
> latter allows you to override resource properties, and I'm not sure
> whether even that allows you to override class parameters.  I had
> thought not.
> 
> If you have many nodes with various small differences between them,
> then perhaps it's time to look into an external node classifier.
> Alternatively, make your classes smarter: instead of parameterizing
> them, put the erstwhile parameter-selection logic inside them.


You touched the heart of the matter:  Is there a way to override
class parameters?


-- 
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] Monitoring abstraction and test driven infrastructure deployment

[Al @ Lab42]

On Friday, March 18, 2011 5:33:25 PM UTC+1, T.J. Yang wrote:
>
> Hi, Al
>
>
> I am interested to participate the effort to  add system monitoring
> function/feature into puppet.
>
> I like following equation ;)
>
> puppet=configuration management + asset management + system monitoring
>
Yeah, I totally agree,

I am a xymon(hobbit/bb) user, I only see your doc mention nagios, so I
> could be helpful.
>
Interesting. If you want contact me privately, if you give me few quick 
hints and best practices on how to configure Xymon I think I can do the 
connector and the relevant module quite quickly. 

> Should open up wiki page on puppet wiki to document this effort ?
> I can do the wiki init work if you agree.
>
Well, why not, but I think we should ask to the PuppetLabs guys.
While generally the monitoring automation and abstraction is something 
probably interesting for everybody, my own implementation implies choices 
that might not be generally approved.

All the best
Al 

-- 
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 Camp Announcements

[Al @ Lab42]

+1 for Deepak as Master of Ceremonies!

-- 
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] Puppet Camp Announcements

[Jose Palafox]

Hi,

We've set up a speaker line up, menu, and a bunch of other useful
information about Puppet Camp on our website. The event is going to be
awesome, we've got some great speakers, and social events planned. Nearly
half the team at Puppet Labs will be in attendance at the event, and we're
really looking forward to meeting everyone. I'd like to encourage everyone
that's been waiting to register to sign up, even if you're local in
Amsterdam, by signing up a bit in advance you'll get a pre printed name
badge and everyone's more likely to get shirts that fit rather than whatever
sizes I guess.

If you have any questions please feel free to e-mail, call, tweet or send
carrier pigeon.

Registration page and Updated Puppet Camp EU Page:

http://bit.ly/dSZGu5

Schedule, Menu, Map of locations:

http://bit.ly/hFLxK0

Updated General Page:

http://bit.ly/hPocAI




-- 
Jose Cruz Palafox Jr.
Operations | Puppet Labs
(503) 877-2403  | @Cruzfox
j...@puppetlabs.com
*
*

-- 
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] apache service start problem

[Marc Zampetti]

The root issue is that the "service" resource only depends upon the 
Package. You need to include all of the other resources in the require, 
or chain the requires in such a way that all of the other work is done 
before puppet tries to start apache. That will fix the "double run" issue.


Marc Zampetti

On 3/17/11 6:06 PM, Denmat wrote:

Hi,
Looks like you're over engineering a bit here. You are creating directories 
that I think will be created by the package manager. You can obviously sets 
perms on those directories but I would drop unnecessary creates.

Also you don't have any order in the structure. You need to include 'notify', 
'requires' and 'before' as mentioned on the other thread.

Cheers,

On 17/03/2011, at 9:04, Tim Dunphy  wrote:


Hey guys,

Thanks for your input!

   I have yet to start paring down the execs as per your suggestion,
however I did implement your suggestion of using the absent attribute
as opposed to the Tidy resource type.


   file { "/etc/httpd/conf.d/ssl.conf":
 ensure =>  absent,
 require =>  Package["httpd.$architecture"]
   }


   service { "httpd":
   enable =>  "true",
   ensure =>  "running",
   hasrestart =>  "true",
   hasstatus =>  "true",
   require =>  Package["httpd.$architecture"]
   }



However this issue still persists.. I still need to run the puppet
run at least twice in order for the apache service to start... the
full apache class is shown below as it stands now... thanks again for
your input!




class apache {

$packagelist =
["httpd.$architecture","httpd-devel.$architecture","webalizer.$architecture","php.$architecture","php-common.$architecture","php-devel.$architecture","php-xmlrpc.$architecture","php-gd.$architecture",
"php-pear.noarch", "php-pdo.$architecture",
"php-mcrypt.$architecture", "php-mhash.$architecture",
"php-mysql.$architecture", "php-cli.$architecture",
"php-soap.$architecture", "php-xml.$architecture",
"mod_ssl.$architecture"]

package { $packagelist:
   ensure =>  "installed"
}




   exec { "create httpd dir":
command =>  "/bin/mkdir -p /etc/httpd",
creates =>  "/etc/httpd"

   }

   exec {"create apache module dir":
command =>  "/bin/mkdir -p /usr/lib/httpd/modules",
creates =>  "/usr/lib/httpd/modules/mod_file_cache.so"
   }

   exec { "create apache module link":
  command =>  "/bin/ln -s /usr/lib/httpd/modules /etc/httpd/modules",
  require =>  Exec["create apache module dir"],
  creates =>  "/etc/httpd/modules"
   }

   exec { "create apache log dir":
command =>  "/bin/mkdir -p /var/log/httpd/logs",
creates =>  "/var/log/httpd/logs"
   }


   exec { "create apache error log":
command =>  "/bin/touch /etc/httpd/logs/error_log",
require =>   Exec["create apache log dir"],
creates =>  "/etc/httpd/logs/error_log"
   }

   exec { "create apache log link":
 command =>  "/bin/ln -s /var/log/httpd/logs /etc/httpd/logs",
 require =>  Exec["create apache log dir"],
 creates =>  "/etc/httpd/logs"
}



exec { "create apache run dir":
command =>  "/bin/mkdir -p /var/run/httpd",
creates =>  "/var/run/httpd"
   }


   exec { "create apache run link":
 command =>  "/bin/ln -s /var/run/httpd /etc/httpd/run",
 require =>  Exec["create apache log dir"],
 creates =>  "/etc/httpd/run"
}

exec { "create httpd conf dir":
command =>  "/bin/mkdir -p /etc/httpd/conf.d",
creates =>  "/etc/httpd/conf.d"

   }


   exec { "create httpd vhost conf dir":
command =>  "/bin/mkdir -p /etc/httpd/conf",
creates =>  "/etc/httpd/conf"

   }


   file { "/etc/php.ini":
  owner =>  root,
  group =>  root,
  mode =>  440,
  source =>  "puppet:///apache/php.ini"
   }

   file { "/usr/lib/httpd/modules/mod_file_cache.so":
 owner =>  root,
 group =>  root,
 mode =>  766,
 require =>  Exec["create apache module dir"],
 source =>  "puppet:///apache/krome/httpd/modules/mod_file_cache.so"
   }

   file {
   "/etc/httpd/conf/httpd.conf":
owner =>  root,
group =>  root,
mode =>  440,
require =>  Exec["create httpd conf dir"],
source =>  "puppet:///apache/krome/httpd/conf/httpd.conf"
   }


   file {
"/usr/lib/httpd/modules/mod_auth_basic.so":
 owner =>  root,
 group =>  root,
 mode =>  766,
 source =>  "puppet:///apache/krome/httpd/modules/mod_auth_basic.so"
   }



   file {
   "/etc/httpd/conf.d/000-ssl.conf":
owner =>  root,
group =>  root,
mode =>  440,
require =>  Exec["create httpd conf dir"],
source =>  "puppet:///apache/krome/httpd/conf.d/000-ssl.conf"
   }

file {
   "/etc/httpd/conf.d/001-chrome-ssl.conf":
owner =>  root,
group =>  root,
mode =>  440,
require =>  Exec["create httpd conf dir"],
source =>  "puppet:///apache/krome/httpd/conf.d/001-chrome-ssl.conf"
   }

   f

[Puppet Users] Re: parameterized classes and variable inheritance

[jcbollinger]

On Mar 17, 6:03 pm, Ashley Gould  wrote:
> I'm hoping to avoid using subclasses, because there would have to
> be oodles of them to accomodate the all the variations between nodes.
>
> node default {
>     class { sudoers: }
>
> }
>
> node 'sl11lab02' inherits default {
>
>     # this runs but does nothing
>     Class[sudoers] { additional_rules => [ "$rules_uas" ] }
>
>     # this errors with "Cannot assign to variables in other namespaces"
>     #$sudoers::additional_rules = [ "$rules_uas" ]
>
>     # this errors with "Class[Sudoers] is already defined"
>     #class { sudoers: additional_rules => [ "$rules_uas" ] }
>
> }

Node inheritance is not the same as class inheritance.  Only the
latter allows you to override resource properties, and I'm not sure
whether even that allows you to override class parameters.  I had
thought not.

If you have many nodes with various small differences between them,
then perhaps it's time to look into an external node classifier.
Alternatively, make your classes smarter: instead of parameterizing
them, put the erstwhile parameter-selection logic inside them.


John

-- 
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] Inventory service and dashboard 1.1.0 rc1

[Jacob Helwig]

On Thu, 17 Mar 2011 21:32:29 -0700, Luke Baker wrote:
> 
> I just set up the latest dashboard release candidate in hopes of
> trying out the new inventory service. After modifying the puppet-
> dashboard config to use the inventory service and after changing my
> auth.conf I gave it a whirl but ran into some issues..
> 
> I initially tried using fact_terminus = yaml and was able to do some
> queries via curl. I'm currently using storeconfigs so setting up
> another database for the inventory service was pretty easy, however
> when I set fact_terminus to 'inventory_active_record' I receive this
> error when performing a puppet run,
> 
> "Could not find terminus inventory_active_record for indirection
> facts"
> 
> Should this be set to something else for use with puppet-dashboard?
> 

Are you also using a 2.6.7rc1 puppet master?  We probably didn't call
this out well enough, but the inventory service features in Dashboard
require the new version of Puppet on the master.

-- 
Jacob Helwig


signature.asc
Description: Digital signature

Re: [Puppet Users] Monitoring abstraction and test driven infrastructure deployment

[TJ Yang]

Hi, Al


I am interested to participate the effort to  add system monitoring
function/feature into puppet.

I like following equation ;)

puppet=configuration management + asset management + system monitoring

I am a xymon(hobbit/bb) user, I only see your doc mention nagios, so I
could be helpful.

Should open up wiki page on puppet wiki to document this effort ?
I can do the wiki init work if you agree.

tj

On Fri, Mar 18, 2011 at 8:34 AM, Al @ Lab42  wrote:
> Good afternoon (morning|night) all,
> I've just posted an article on how I manage automatic monitoring with Puppet
> http://www.example42.com/?q=Test_Driven_Puppet_Infrastructures_deployment
> and besides the shameless spam on this list I'd like to take this occasion
> to raise again a topic discussed with Nigel, Dan and others in the last
> Puppetcamp, in this list and somewhere else in the past.
>
> We all think, I suppose, that Puppet should somehow manage automatically the
> monitoring of the resources it provides.
> How this is done is a whole universe of complexity, alternative approaches
> and design decisions.
>
> What I've done is an attempt to use standard naming to define what to
> monitor in an abstract way (without reference to the tool actually used for
> monitoring) and a (working in different productions) implementation entirely
> based on Puppet DSL that prefers linearity and extendability over
> performance and optimization of resources.
>
> I think it would be interesting to know how people are dealing with this
> topic and how/when this will eventually implemented directly in Puppet code.
>
> All the best
> Al
>
> --
> 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.
>



-- 
T.J. Yang

-- 
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: Adding a mailer to Postfix master.cf via Augeas

[Luke Bigum]

On Mar 18, 2:50 pm, Jeremy  wrote:
>                 "set aws-email/command pipe flags=R user=nobody argv=/
> usr/local/bin/ses-send-email -r -k /etc/postfix/aws-credentials -f $
> {sender} ${recipient}",

Try:

'set aws-email/command "pipe flags=R user=nobody argv=/ usr/local/bin/
ses-send-email -r -k /etc/postfix/aws-credentials -f $ {sender} $
{recipient}"'

Single quotes around the string in Puppet, double quotes around the
Augeas string.

-- 
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] Adding a mailer to Postfix master.cf via Augeas

[Jeremy]

Has anyone had any success with adding a new mailer to the Postfix
master.cf using Augeas? I know the commands work if I use augtool but
I'm having problems translating it into a Puppet module configuration.
I'm attempting to set Postfix up to use Amazon Web Services Simple
Email Service as suggested at 
http://netwiser.blogspot.com/2011/02/setup-amazon-ses-to-relay-email-by.html.

This is what I have currently and it truncates the command+args
section after only "pipe". When I use augtool I would put the whole
command+args section within quotes but that doesn't seem to work with
Puppet+Augeas.

augeas {
"Postfix Master Config":
context => "/files/etc/postfix/master.cf",
changes => [
"set aws-email/type unix",
"set aws-email/private -",
"set aws-email/unpriviliged n",
"set aws-email/chroot n",
"set aws-email/wakeup -",
"set aws-email/limit -",
"set aws-email/command pipe flags=R user=nobody argv=/
usr/local/bin/ses-send-email -r -k /etc/postfix/aws-credentials -f $
{sender} ${recipient}",
],
require => Package["postfix"],
notify  => Service["postfix"];
}

-- 
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: ANNOUNCE: Facter 1.5.9rc2

[Emiliano Gabrielli (aka AlberT)]

Confirmed and already opened a ticket: 
https://projects.puppetlabs.com/issues/6763


On Mar 18, 2011, at 12:38 PM, Thomas Bendler wrote:

> Hi Todd,
> 
> 2011/3/18 Todd Zullinger 
> [...]
> If you find problems with the packaging, please let me know.  If you
> find other bugs, please file them in redmine:
> 
>http://projects.puppetlabs.com/projects/facter/issues
> [...]
> 
> don't know if it's a bug or related to the packages but facter search arp at 
> /usr/sbin/arp but on CentOS 5 it is at /sbin/arp.
> 
> Regards, 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.

-- 
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] Debian 6 puppetmaster package

[Jon]

Hi,

I'm trying to get puppet and puppetmaster running on a fresh Debian 6
VM. I've installed both using 'apt-get install'. The client seems
fine, however when I try to start puppetmaster I get the following
error:

/usr/lib/ruby/1.8/openssl/x509-internal.rb:22:in `create_ext':
subjectAltName = DNS:puppet ..[snip].. : missing value
(OpenSSL::X509::ExtensionError)
from /usr/lib/ruby/1.8/openssl/x509-internal.rb:22:in
`create_extension'
from /usr/lib/ruby/1.8/puppet/ssl/certificate_factory.rb:72:in
`build_extensions'
from /usr/lib/ruby/1.8/puppet/ssl/certificate_factory.rb:32:in
`result'
from /usr/lib/ruby/1.8/puppet/ssl/certificate_authority.rb:239:in
`sign'
from /usr/lib/ruby/1.8/puppet/ssl/host.rb:188:in `generate'
from /usr/lib/ruby/1.8/puppet/ssl/host.rb:28:in `init_localhost'
from /usr/lib/ruby/1.8/puppet/util/cacher.rb:106:in `send'
from /usr/lib/ruby/1.8/puppet/util/cacher.rb:106:in `cached_value'
from /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
from /usr/lib/ruby/1.8/puppet/util/cacher.rb:98:in `cached_value'
from /usr/lib/ruby/1.8/puppet/util/cacher.rb:48:in `localhost'
from /usr/lib/ruby/1.8/puppet/application/master.rb:86:in `main'
from /usr/lib/ruby/1.8/puppet/application/master.rb:46:in
`run_command'
from /usr/lib/ruby/1.8/puppet/application.rb:287:in `run'
from /usr/lib/ruby/1.8/puppet/application.rb:393:in `exit_on_fail'
from /usr/lib/ruby/1.8/puppet/application.rb:287:in `run'
from /usr/sbin/puppetmasterd:4

Could anyone help with the required steps to get this running?

-- 
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] Monitoring abstraction and test driven infrastructure deployment

[Al @ Lab42]

Good afternoon (morning|night) all,
I've just posted an article on how I manage automatic monitoring with Puppet
http://www.example42.com/?q=Test_Driven_Puppet_Infrastructures_deployment 
and besides the shameless spam on this list I'd like to take this occasion 
to raise again a topic discussed with Nigel, Dan and others in the last 
Puppetcamp, in this list and somewhere else in the past.

We all think, I suppose, that Puppet should somehow manage automatically the 
monitoring of the resources it provides.
How this is done is a whole universe of complexity, alternative approaches 
and design decisions.

What I've done is an attempt to use standard naming to define what to 
monitor in an abstract way (without reference to the tool actually used for 
monitoring) and a (working in different productions) implementation entirely 
based on Puppet DSL that prefers linearity and extendability over 
performance and optimization of resources.

I think it would be interesting to know how people are dealing with this 
topic and how/when this will eventually implemented directly in Puppet code. 


All the best
Al

-- 
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] [PATCH/facter] (#6763) Use Facter::Util::Resolution.exec for arp

[Todd Zullinger]

The arp command is in /sbin on Fedora/RHEL, not /usr/sbin.  Using
Facter::Util::Resolution.exec is preferable to hard-coding the path.
---
 lib/facter/arp.rb |8 +---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/lib/facter/arp.rb b/lib/facter/arp.rb
index 65cf4c3..5035ad0 100644
--- a/lib/facter/arp.rb
+++ b/lib/facter/arp.rb
@@ -4,9 +4,11 @@ Facter.add(:arp) do
   confine :kernel => :linux
   setcode do
 arp = []
-output = %x{/usr/sbin/arp -a}
-output.each_line do |s|
-  arp.push($1) if s =~ /^\S+\s\S+\s\S+\s(\S+)\s\S+\s\S+\s\S+$/
+output = Facter::Util::Resolution.exec('arp -a')
+if not output.nil?
+  output.each_line do |s|
+arp.push($1) if s =~ /^\S+\s\S+\s\S+\s(\S+)\s\S+\s\S+\s\S+$/
+  end
 end
 arp[0]
   end
-- 
1.7.4.1

-- 
ToddOpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~
In the beginning the Universe was created. This has made a lot of
people very angry and has been widely regarded as a bad move.
-- Douglas Adams

-- 
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: ANNOUNCE: Facter 1.5.9rc2

[AlberT]

I can confirm, already opened a ticket: 
https://projects.puppetlabs.com/issues/6763

-- 
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] MCollective facts with uppercase

[R.I.Pienaar]

- Original Message -
> Hi @all,
> 
> don't know if this is the correct list for a question like this, but
> maybe someone knows. Is there a reason why mc-facts don't support
> facts with uppercase inside but mc-inventory does?

best place is the mcollective-users list

> thbe@ocean:~$ mc-facts custRole
> Could not call remote agent: Input fact does not match validation
> regex ^[a-z_0-9]+$
> thbe@ocean:~$ mc-inventory node1.domain.tld | grep custRole
> custRole => standard
> thbe@ocean:~$

you can tweak the rpcutil.ddl file changing the regex for this. It looks
like an oversight on my part, if you file a ticket at projects.puppetlabs.com
in the mcollective project I'll sort it for the next release

-- 
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] MCollective facts with uppercase

[Thomas Bendler]

Hi @all,

don't know if this is the correct list for a question like this, but maybe
someone knows. Is there a reason why mc-facts don't support facts with
uppercase inside but mc-inventory does?

thbe@ocean:~$ mc-facts custRole
Could not call remote agent: Input fact does not match validation regex
^[a-z_0-9]+$
thbe@ocean:~$ mc-inventory node1.domain.tld | grep custRole
  custRole => standard
thbe@ocean:~$

Kind regards, 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.

Re: [Puppet Users] Re: ANNOUNCE: Facter 1.5.9rc2

[Thomas Bendler]

Hi Todd,

2011/3/18 Todd Zullinger 

> [...]
> If you find problems with the packaging, please let me know.  If you
> find other bugs, please file them in redmine:
>
>http://projects.puppetlabs.com/projects/facter/issues
> [...]
>

don't know if it's a bug or related to the packages but facter search arp at
/usr/sbin/arp but on CentOS 5 it is at /sbin/arp.

Regards, 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.

Re: [Puppet Users] State of the pkgutil provider?

[Dominic Cleal]

On 17/03/11 16:07, Mark Phillips wrote:
> On 17 Mar 2011, at 05:42, James Turnbull wrote:
> 
>> Dominic Cleal wrote:
>>> Nobody has been looking at it, it would be great if you and Mark want to
>>> and I'd be happy to help.  I haven't even seen any examples of pkgutil
>>> catalogs with multiple versions, so it'd be good to check it copes
>>> properly in its current form too.  (Unit tests!)
>>>
>>> I think it's best to first collect some evidence about the output format
>>> of pkgutil with multiple versions and what's possible compared to say
>>> yum, then work out how to integrate that into the provider.
>>>
>>
>> And tests.  Tests are always awesome. :)
> 
> And on that subject James, do Puppetlabs have any recommendations for 
> testing - types of evidence, frameworks, etc. My only experience is Perl
> Test::More and the likes, if you've any tips on what we could produce for
> Puppet/Ruby that'd be great.

Just to add to Daniel and James, I recently wrote a test for the pkgutil
provider based on the current implementation.  You'll find it in the
latest branch (Juerg's) at spec/unit/provider/package/pkgutil_spec.rb.
Hopefully it's fairly easy to follow and extend.

Also see:
http://projects.puppetlabs.com/projects/puppet/wiki/Development_Writing_Tests

Actually, it looks Juerg's recent commits have caused it to break, so
I'll go through later and update it to cover the changes.  Will update
#4258 when it's done.

$ ruby spec/unit/provider/package/pkgutil_spec.rb
.F.FFF.F..F.

Failures:

  1) Puppet::Type::Package::ProviderPkgutil when updating should use a
command without versioned package
[... etc ...]

-- 
Dominic Cleal
Red Hat Consulting
m: +44 (0)7818 512168

-- 
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] parameterized classes and variable inheritance

[Guillaume Rousse]

Le 18/03/2011 00:03, Ashley Gould a écrit :
> I am exploring usage of parameterized classes.  I hit a wall when
> trying to override values of parameters in a node definition that 
> inherits the class from a parent node.  Is there a way to do this,
> or must I include the class only in the child node?
I'm also facing the same issue, except I'm rather interested in the
result (managing specific case of a policy applied everywhere from basic
node definition) rather than the exact way to achieve it (parameterized
classes, defined type, whatever).

This is true for instance for ntp, ssh, syslog, etc... Basically every
kind of service running as server on all machines with the same
configuration excepted in a specific node, the master (smtp or ssh
gateway, ntp master, etc...).

Currently, I'm managing this by hardcoding conditional in the class, but
I don't like mixing the semantic of "how to run a service" with "how do
map my services to my infrastructure".

node "basenode" {
include ntp::server
}

node "ntp.tld" inherits basenode {
}

class ntp::server {
$servers = $hostname ? {
ntp => ["ntp.foo", "ntp.bar", "ntp.baz"],
default => "ntp.tld"
}
}

I could potentialy move the conditional into the "basenode" definition,
which would achieve a bit more separation of concerns, but would be
quite ugly. What I'd really like would be some way to express:

node "basenode" {
include ntp::server (with servers = "ntp.tld")
}

node "ntp.tld" inherits basenode {
include ntp::server (with servers = ["ntp.foo", "ntp.bar", "ntp.baz"])
}
-- 
BOFH excuse #82:

Yeah, yo mama dresses you funny and you need a mouse to delete files.

-- 
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] RFC: Refactoring the mount provider.

[Christian Kauhaus]

Am 17.03.2011 18:40, schrieb Nigel Kersten:
> TL;DR The mount provider has used a mish-mash of checking fstab and
> actual mount state to determine state. A possible solution we're
> looking at is splitting into two types, one that manages /etc/fstab
> (or /etc/filesystem on other OSes), and one that manages actual mount
> state.

+1

Regards

Christian

-- 
Dipl.-Inf. Christian Kauhaus <>< · k...@gocept.com · systems administration
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 11 · fax +49 345 1229889 1
Zope and Plone consulting and development

-- 
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] Problem defining exported resources

[Greg Sutcliffe]

On Thursday, March 17, 2011 2:41:06 PM UTC, Felix.Frank wrote:
>
> I call possible bug on this one. I don't see an open issue that sounds
> quite like this, so you may want to report this.
>
> http://projects.puppetlabs.com/projects/puppet/issues/new
>
> Cheers,
> Felix
>

Thanks Felix - nice to know I'm not going mad. I'll double check it later 
today on the latest Puppet to make sure it's still an issue, and then get it 
filed.

Cheers, Greg 

-- 
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.