Re: [Puppet Users] Bootstrap

[Ohad Levy]

If you need to save some time, have a look at theforeman.org - which should
takes care for most of the work for you.

Ohad

On Fri, Jul 30, 2010 at 12:19 PM, Daniel Pittman wrote:

> "parag(PK)"  writes:
>
> > Can it be possible to boot up a bare metal client ,by downloding the
> > whole OS from server .when the client is powered on .
>
> Yes.  Feel free to research PXE booting, debootstrap, debconf preseeding,
> kickstart, satellite, jumpstart, FAI, and the other related technologies
> yourself.
>
> Regards,
>Daniel
> --
> ✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155
> 707
>   ♽ made with 100 percent post-consumer electrons
>
> --
> 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] Bootstrap

[Daniel Pittman]

"parag(PK)"  writes:

> Can it be possible to boot up a bare metal client ,by downloding the
> whole OS from server .when the client is powered on .

Yes.  Feel free to research PXE booting, debootstrap, debconf preseeding,
kickstart, satellite, jumpstart, FAI, and the other related technologies
yourself.

Regards,
Daniel
-- 
✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707
   ♽ made with 100 percent post-consumer electrons

-- 
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_Augeas: Working Examlples

[Andrei Pozolotin]

Rob, wow!

On Jul 29, 10:48 am, Rob McBroom  wrote:
> I just added a bunch of stuff starting here:
http://projects.puppetlabs.com/projects/puppet/wiki/Puppet_Augeas#Simple+Examples

thanks for sharing this; now this page is a real treasure; I learned a
lot about augeas;

Andrei

-- 
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 not finding shell builtins/functions?

[Daniel Pittman]

James Turnbull  writes:
> Richard Crowley wrote:
>> On Thu, Jul 29, 2010 at 3:23 PM, Greg Graf  wrote:

[...]

>> I saw the same thing happen with a few for-loops and had to wrap them
>> up in /bin/sh -c '...' for 2.6.  Now that I look for it, I can't find
>> anything about this behavior change in the release notes for 2.6.  Was
>> it coincidental that it ever worked?
>
> See:
>
> http://projects.puppetlabs.com/issues/4288
> http://projects.puppetlabs.com/issues/4299
>
> For some history and comments on this.  We'd welcome some input into
> what you think should be safe and expected behaviour here.

If this is a "voting" matter, let me put in a vote for passing a simple string
to the shell, and passing an array direct to exec, which is consistent with
the use of 'system' style commands in a whole bunch of sysadmin scripting
languages.

Eg, this:

   exec { "foo": command => ['/bin/ls', '|' 'foo'] }

will pass '|' 'foo' to the ls command, compared to:

   exec { "foo": command => "/bin/ls | foo" }

...which passes it to the default system shell.

Daniel
-- 
✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707
   ♽ made with 100 percent post-consumer electrons

-- 
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] Bootstrap

[Jeff McCune]

On Thu, Jul 29, 2010 at 10:02 PM, parag(PK)  wrote:
> Can it be possible to boot up a bare metal client ,by downloding the
> whole OS from server .when the client is powered on .

Yes.

Nearly all unix operating systems provide a technology to provision
from bare metal through the networt.  A short list of those
technologies:

Enterprise Linux (RedHat, CentOS) - kickstart
Debian - fai (Fully Automated Install)
Solaris - jumpstart
Mac OS X - NetBoot-Install

Puppet is usually run in the post-installation phase of the
provisioning system, e.g. %post in kickstart.

-- 
Jeff McCune
http://www.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-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] Bootstrap

[parag(PK)]

Can it be possible to boot up a bare metal client ,by downloding the
whole OS from server .when the client is powered on .

-- 
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] Certificate Signing Problem

[array of char]

I'm running into certificate signing problem with puppet 0.25.5

Master is running on Ubuntu server 10.04

I think the problem is with the master's puppetca. After the master
signs the certificate request from the client, there is an error in
the master's log:

[2010-07-29 15:25:39] ERROR OpenSSL::SSL::SSLError: SSL_accept
returned=1 errno=0 state=SSLv3 read client certificate A: sslv3 alert
\
bad certificate
/usr/local/lib/site_ruby/1.8/puppet/network/http/webrick.rb:
44:in `accept'
/usr/local/lib/site_ruby/1.8/puppet/network/http/webrick.rb:44
/usr/lib/ruby/1.8/webrick/server.rb:173:in `call'
/usr/lib/ruby/1.8/webrick/server.rb:173:in `start_thread'
/usr/lib/ruby/1.8/webrick/server.rb:162:in `start'
/usr/lib/ruby/1.8/webrick/server.rb:162:in `start_thread'
/usr/lib/ruby/1.8/webrick/server.rb:95:in `start'
/usr/lib/ruby/1.8/webrick/server.rb:92:in `each'
/usr/lib/ruby/1.8/webrick/server.rb:92:in `start'
/usr/lib/ruby/1.8/webrick/server.rb:23:in `start'
/usr/lib/ruby/1.8/webrick/server.rb:82:in `start'
/usr/local/lib/site_ruby/1.8/puppet/network/http/webrick.rb:
42:in `listen'
/usr/local/lib/site_ruby/1.8/puppet/network/http/webrick.rb:
41:in `initialize'
/usr/local/lib/site_ruby/1.8/puppet/network/http/webrick.rb:
41:in `new'
/usr/local/lib/site_ruby/1.8/puppet/network/http/webrick.rb:
41:in `listen'
/usr/local/lib/site_ruby/1.8/puppet/network/http/webrick.rb:
38:in `synchronize'
/usr/local/lib/site_ruby/1.8/puppet/network/http/webrick.rb:
38:in `listen'
/usr/local/lib/site_ruby/1.8/puppet/network/server.rb:131:in
`listen'
/usr/local/lib/site_ruby/1.8/puppet/network/server.rb:146:in
`start'
/usr/local/lib/site_ruby/1.8/puppet/daemon.rb:128:in `start'
/usr/local/lib/site_ruby/1.8/puppet/application/
puppetmasterd.rb:122:in `main'
/usr/local/lib/site_ruby/1.8/puppet/application.rb:226:in
`send'
/usr/local/lib/site_ruby/1.8/puppet/application.rb:226:in
`run_command'
/usr/local/lib/site_ruby/1.8/puppet/application.rb:217:in
`run'
/usr/local/lib/site_ruby/1.8/puppet/application.rb:306:in
`exit_on_fail'
/usr/local/lib/site_ruby/1.8/puppet/application.rb:217:in
`run'
/usr/sbin/puppetmasterd:66

And when the client tries to contact the master again (i.e. puppetd -
t), it gives the following error:

err: Could not retrieve catalog from remote server: SSL_connect
returned=1 errno=0 state=SSLv3 read server certificate B: certificate
verify failed
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run


I have already spent an entire day on this uninstalling (deleting all
of the puppet directories and executables) and reinstalling different
versions of puppet, and none of them worked, and I couldn't find
anything helpful with those errors.

My guess is that the ca might be different on the client and server.

Please help!

Thanks,

Bo

-- 
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] Figuring out Stages

[Jeff McCune]

On Thu, Jul 29, 2010 at 4:33 PM, James Turnbull  wrote:
> Jeff
>
> Fancy adding that to the Language Tutorial?
>
> James

Definitely.  I'll update the documentation this evening.

-- 
Jeff McCune
http://www.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-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 not finding shell builtins/functions?

[James Turnbull]

Richard Crowley wrote:
> On Thu, Jul 29, 2010 at 3:23 PM, Greg Graf  wrote:
>> Hello,
>>
>> We're running 2.6 on Ubuntu 10.04 and here's what I'm seeing (simplified 
>> test):
>>
>> class cdtest {
>>  exec {'cdtest': command => 'cd' }
>> }
>>
>> # puppet agent --test
>> info: Caching catalog for servername
>> info: Applying configuration version '1280441519'
>> err: /Stage[main]/Cdtest/Exec[cdtest]/returns: change from notrun to 0 
>> failed: Could not find command 'cd'
>> notice: Finished catalog run in 0.65 seconds
>> #
>>
>> Any ideas on why this is failing? I am running into this with rvm as well 
>> (since it is a function and not a binary).
> 
> I saw the same thing happen with a few for-loops and had to wrap them
> up in /bin/sh -c '...' for 2.6.  Now that I look for it, I can't find
> anything about this behavior change in the release notes for 2.6.  Was
> it coincidental that it ever worked?
> 

See:

http://projects.puppetlabs.com/issues/4288
http://projects.puppetlabs.com/issues/4299

For some history and comments on this.  We'd welcome some input into
what you think should be safe and expected behaviour here.

Cheers

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] exec not finding shell builtins/functions?

[Rohan McGovern]

Greg Graf said:
> Hello,
> 
> We're running 2.6 on Ubuntu 10.04 and here's what I'm seeing (simplified 
> test):
> 
> class cdtest {
>   exec {'cdtest': command => 'cd' }
> }
> 
> # puppet agent --test
> info: Caching catalog for servername
> info: Applying configuration version '1280441519'
> err: /Stage[main]/Cdtest/Exec[cdtest]/returns: change from notrun to 0 
> failed: Could not find command 'cd'
> notice: Finished catalog run in 0.65 seconds
> #
> 
> Any ideas on why this is failing? I am running into this with rvm as well 
> (since it is a function and not a binary).
> 

Isn't this by design?  Unless the puppet docs say that "exec" is always
run through a shell, then I wouldn't expect it to be.

In my manifests, if I want a shell, I explicitly use:

 command => '/bin/sh -c "some shell commands"'
-- 
Rohan McGovern
QA Engineer
Qt Development Frameworks, Nokia

-- 
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] Figuring out Stages

[James Turnbull]

Jeff McCune wrote:
> On Thu, Jul 29, 2010 at 9:45 AM, Ryan Y. Coleman  wrote:
>> I would like to stage them such that pre occurs first, followed by deploy, 
>> finished by configure.
>>
>> The documentation suggests you create new stages as resources. Does this 
>> mean that in each class I create the stage resource like this example?
> 
> The stages are resources like any other, which means they can only be
> declared in the catalog once.  Otherwise, you'll get duplicate
> declaration errors.


Jeff

Fancy adding that to the Language Tutorial?

James

-- 
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] exec not finding shell builtins/functions?

[Richard Crowley]

On Thu, Jul 29, 2010 at 3:23 PM, Greg Graf  wrote:
> Hello,
>
> We're running 2.6 on Ubuntu 10.04 and here's what I'm seeing (simplified 
> test):
>
> class cdtest {
>  exec {'cdtest': command => 'cd' }
> }
>
> # puppet agent --test
> info: Caching catalog for servername
> info: Applying configuration version '1280441519'
> err: /Stage[main]/Cdtest/Exec[cdtest]/returns: change from notrun to 0 
> failed: Could not find command 'cd'
> notice: Finished catalog run in 0.65 seconds
> #
>
> Any ideas on why this is failing? I am running into this with rvm as well 
> (since it is a function and not a binary).

I saw the same thing happen with a few for-loops and had to wrap them
up in /bin/sh -c '...' for 2.6.  Now that I look for it, I can't find
anything about this behavior change in the release notes for 2.6.  Was
it coincidental that it ever worked?

-- 
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] Figuring out Stages

[Jeff McCune]

On Thu, Jul 29, 2010 at 9:45 AM, Ryan Y. Coleman  wrote:
>
> I would like to stage them such that pre occurs first, followed by deploy, 
> finished by configure.
>
> The documentation suggests you create new stages as resources. Does this mean 
> that in each class I create the stage resource like this example?

The stages are resources like any other, which means they can only be
declared in the catalog once.  Otherwise, you'll get duplicate
declaration errors.

I'd declare them in their own class included in the node classification.
class runstages {
  stage { "pre":  before  => Stage["main"] }
  stage { "post": require => Stage["main"] }
}

> I got to this point and confused myself so I'm hoping one of you can clear me 
> up. Thanks!

Here's the rest of my example:

class one   { notify { "class one, first stage":   } }
class two   { notify { "class two, second stage":  } }
class three { notify { "class three, third stage": } }

# JJM We need Stage[pre] and Stage[post] in the catalog
include runstages

# place Class[pre] in stage "pre"
class { "one": stage => pre }
# default Class[main] to stage "main"
class { "two": }
# place Class[post] in stage "post"
class { "three": stage => post }

-- 
Jeff McCune
http://www.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-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.



run_stages.pp
Description: Binary data

[Puppet Users] exec not finding shell builtins/functions?

[Greg Graf]

Hello,

We're running 2.6 on Ubuntu 10.04 and here's what I'm seeing (simplified test):

class cdtest {
  exec {'cdtest': command => 'cd' }
}

# puppet agent --test
info: Caching catalog for servername
info: Applying configuration version '1280441519'
err: /Stage[main]/Cdtest/Exec[cdtest]/returns: change from notrun to 0 failed: 
Could not find command 'cd'
notice: Finished catalog run in 0.65 seconds
#

Any ideas on why this is failing? I am running into this with rvm as well 
(since it is a function and not a binary).

Thanks!

Greg Graf
Systems Engineer
Rackspace



Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
at ab...@rackspace.com, and delete the original message.
Your cooperation is appreciated.

-- 
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] Figuring out Stages

[Jeff McCune]

On Thu, Jul 29, 2010 at 9:45 AM, Ryan Y. Coleman  wrote:
> Hello All, I'm hoping to figure out how to use stages to reduce how many 
> require statements are used in a particular module.

I'm investigating run-stages as well.  I haven't sorted out a working
example yet, but will report back as soon as I have more information
about the issue.

For what it's worth, it does look like there's a bug in 2.6.0 and
2.6.1rc1 with run-stages.

Cheers,
-- 
Jeff McCune
http://www.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-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] render template

[Jeff McCune]

On Thu, Jul 29, 2010 at 12:32 PM, Christopher Johnston
 wrote:
> Is there a way in puppet to make the client render a template from a module
> and have it spit the contents of the template to stdout or to a file so it
> can be looked at before deploying?
> -Chris

You could just use it in a file resource as normal, just manage some
file other than the file you intend to deploy to:

file { "/tmp/foobar":
  content => template("mymodule/mytemplate.erb")
}

-- 
Jeff McCune
http://www.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-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] Setting Augeas values using an array

[Doug Warner]

I have a resource I'd like to manage via augeas (/etc/conf.d/net; it's a bash
variables file) but I"m having problems figuring out how to set the values so
that all of the values in the array go in.

I would like it to look like this:
# cat /etc/conf.d/net
config_eth4=("192.168.128.2/24")
config_eth5=("192.168.129.2/24")
routes_eth5=("192.168.130.0/24 via 192.168.131.1")

But it ends up looking like this:
config_eth4=192.168.128.2/24
config_eth5=192.168.129.2/24
routes_eth5=192.168.130.0/24

The goal is to be able to assign multiple values to "ip" or "routes" for an
interface.

Is this something I might have to do w/ a custom type?

-Doug


class net {
file { "/etc/conf.d/net":
owner => root, group => root, mode => 0644,
}

# TODO remove undefined routes
define interface($ip, $routes = undef) {
exec { "net_restart_$name":
#TODO: perform restart
command => "/bin/true",
refreshonly => true,
}

augeas { "conf.d_net_ip_$name":
notify => Exec["net_restart_$name"],
context => "/files/etc/conf.d/net",
changes => "set config_$name $ip",
}
if $routes {
augeas { "conf.d_net_routes_$name":
notify => Exec["net_restart_$name"],
context => "/files/etc/conf.d/net",
changes => "set routes_$name $routes",
}
}
else {
augeas { "conf.d_net_routes_$name":
notify => Exec["net_restart_$name"],
context => "/files/etc/conf.d/net",
changes => "rm routes_$name",
onlyif => "match routes_$name size > 0",
}
}
}
}

node 'example' {
include net
net::interface { "eth4": ip => ["192.168.128.2/24"], }
net::interface { "eth5": ip => ["192.168.129.2/24"],
routes => ["192.168.130.0/24 via 192.168.131.1"],}
}



signature.asc
Description: OpenPGP digital signature

[Puppet Users] Re: Newbie question - package installation

[Rustler]

I am using version 2.6 and it would be nice if you could use a puppet
url for the package source, but that does not appear to work (docs say
it has to be a local file).

My other choices seem to be an nfs mount, or a local repo server.

Thanks

On Jul 29, 11:23 am, Patrick Mohr  wrote:
> On Jul 29, 2010, at 9:45 AM, Rustler wrote:
>
> > This code is working - but due to the file declaration it keeps
> > downloading the rpm even after the package gets installed.
>
> > 1. How do I stop the rpm from downloading after the package is
> > installed?
>
> Best method:
> *) If at all possible you should just replace this with a real package 
> repository.
>
> Should also work:
> *) Put the rpm files on a webserver and download them as needed.  I think rpm 
> can take URLs instead of local paths.
> or
> *)Install from a network drive like nfs
>
> Not recommended:
> *) Just put the rpms into a folder you create.  It will keep growing forever, 
> but it probably won't ever get very big unless you release a lot of packages. 
>  Trust me on this, pushing out big files with puppet is probably a mistake.  
> It will put a large load on the puppetmaster, and if you are using a version 
> of puppet less than 2.6.0, the RAM requirements on the client and serve will 
> be horrendous.

-- 
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: Conary support

[Jeff McCune]

On Thu, Jul 29, 2010 at 2:31 PM, Yushu Yao  wrote:
>
> If I would like to create a new back-end to conary (which does the same like
> yum or apt). What is the best way to start?

You'd write a package provider for conary, the "back-end" you
mentioned is specifically called a provider in puppet.

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

I also recommend the puppet-dev mailing list and #puppet-dev on IRC.

Hope this helps,
-- 
Jeff McCune
http://www.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-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: Conary support

[Yushu Yao]

Hi Experts,

Replying to myself now:

If I would like to create a new back-end to conary (which does the same like
yum or apt). What is the best way to start?

-Yushu

+-+
| Yushu Yao
| Ph:1-510-486-4690
|
| Lawrence Berkeley National Lab
| Mailstop 50B-6222
| 1 Cyclotron Road
| Berkeley CA 94720-8147 - USA
+-+




On Tue, Jul 27, 2010 at 7:40 PM, Yushu Yao  wrote:

> Hi Users,
>
> Does anyone happen to have a conary backend of puppet? (Conary is the RPM
> equivalent in rPath-generated systems).
>
>  rPath claim of supporting puppet back in March, but they went silent after
> that.
>
> Thanks a lot!
>
> -Yushu
>
> +-+
> | Yushu Yao
> | Ph:1-510-486-4690
> |
> | Lawrence Berkeley National Lab
> | Mailstop 50B-6222
> | 1 Cyclotron Road
> | Berkeley CA 94720-8147 - USA
> +-+
>
>
>

-- 
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] Could not find resource type ...

[Jeff McCune]

On Thu, Jul 29, 2010 at 2:13 PM, bmort  wrote:
> ...
> debug: importing '/etc/puppet/modules/passenger/manifests/init.pp'
> info: Autoloaded module passenger
> Could not find resource type apache2::module at /etc/puppet/modules/
> passenger/manifests/init.pp:23 on node freebeerontuesdays.com

Have you also copied the apache2 puppet module into
/etc/puppet/modules?  Puppet is looking for a resource definition
named apache2::module, which likely exists in the apache2 puppet
module manifests directory as module.pp.  Here, module is overloaded
and module.pp is refering to an apache module, not a puppet module.

-- 
Jeff McCune
http://www.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-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] Could not find resource type ...

[bmort]

Let me start by saying, I am a puppet rookie.

I am trying to get a passenger module working and receive the
following messages.  I am trying to figure understand where the
'resource type ' should be?  Or, defined? Is it another module that I
should included under puppet/modules ?


the message:
_
...
debug: importing '/etc/puppet/modules/passenger/manifests/init.pp'
info: Autoloaded module passenger
Could not find resource type apache2::module at /etc/puppet/modules/
passenger/manifests/init.pp:23 on node freebeerontuesdays.com



from init.pp
__
...
  apache2::module {
"passenger": ensure => present, require_package => "libapache2-mod-
passenger";
  }
...
--


regards,

puppet_rookie



__


-- 
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] Reconciling resource defaults, dynamic scope, and the singleton nature of classes

[Jeff McCune]

On Thu, Jul 29, 2010 at 2:04 PM, R.I.Pienaar  wrote:
>
> I think so :) ::topclass isnt about scope its about resolution? I never 
> considered it would have scope implications.

Right, forgot about that case.

So what about another keyword in addition to require and include
(feels like we're running out...) that adds a class to the catalog at
top scope?  Something like "addclass" perhaps.

Modules would then avoid using "include mydependency" and prefer
"addclass mydependency"

--
Jeff McCune
http://www.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-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] Reconciling resource defaults, dynamic scope, and the singleton nature of classes

[Jeff McCune]

On Thu, Jul 29, 2010 at 2:00 PM, Jeff McCune  wrote:

> And...  Believe it or not, it actually already does almost exactly what I
> want it to do in 2.6, except I think I found a bug in 2.6.
>
>
Hrm, it appears to be just a tweak to the display...

include leaf and include ::leaf both result in the same display of:
notice: /Stage[main]/Leaf/Notify[leaf]/message: defined 'message' as
'baseone'

So it's still nesting the scope of leaf, however it's just no longer clearly
displaying it.

Rats.

-- 
Jeff McCune
http://www.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-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] Reconciling resource defaults, dynamic scope, and the singleton nature of classes

[R.I.Pienaar]

- "Jeff McCune"  wrote:

> 
> I think this is something that is really becoming an issue with the
> increasing number of modules published to the Forge. Modules need some
> way to satisfy their dependencies on other modules, and the current
> behavior of include just doesn't seem to cut it.
> 
> 
> What about include ::localyumrepository ?
> 
> 
> It's valid syntax in 0.24.9, 0.25.5, and 2.6.0
> 
> 
> And... Believe it or not, it actually already does almost exactly what
> I want it to do in 2.6, except I think I found a bug in 2.6.
> 
> 
> Here's my test manifest:
> #
> 
> class leaf { notify { "leaf": } }
> class baseone {
> Notify { message => "baseone" }
> notify { "baseone": }
> include ::leaf
> }
> class basetwo {
> Notify { message => "basetwo" }
> notify { "basetwo": }
> include ::leaf
> }
> include baseone, basetwo
> # include basetwo, baseone
> 
> 
> Here's the result in 0.25.5 and 0.24.9:
> 
> notice: baseone
> notice: //baseone/Notify[baseone]/message: defined 'message' as
> 'baseone'
> notice: baseone
> notice: //baseone/leaf/Notify[leaf]/message: defined 'message' as
> 'baseone'
> notice: basetwo
> notice: //basetwo/Notify[basetwo]/message: defined 'message' as
> 'basetwo'
> 
> 
> Notice how Notify[leaf]'s scope is within baseone, which was the first
> class to include it.
> 
> 
> Now, for the pleasant surprise: (in 2.6.0)
> 
> notice: basetwo
> notice: /Stage[main]/Basetwo/Notify[basetwo]/message: defined
> 'message' as 'basetwo'
> notice: baseone
> notice: /Stage[main]/Leaf/Notify[leaf]/message: defined 'message' as
> 'baseone'
> notice: baseone
> notice: /Stage[main]/Baseone/Notify[baseone]/message: defined
> 'message' as 'baseone'
> 
> 
> It *appears* Notify[leaf] is not within the scope of Baseone or
> Basetwo, however it's still getting the default value of the message
> parameter from the baseone class... Flipping in the order around to
> include basetwo, baseone we get:
> 
> notice: /Stage[main]/Leaf/Notify[leaf]/message: defined 'message' as
> 'basetwo'
> 
> 
> Again, it looks like the class is included into top scope, but the
> behavior is that we're still getting resource defaults from basetwo's
> scope.
> 
> 
> Thoughts? Am I insane for wanting include ::leaf to place Leaf at top
> scope?

I think so :) ::topclass isnt about scope its about resolution? I never 
considered it would have scope implications.

Only time you tend to see it is in:

class monitor { }
class foo::monitor { }
class foo::bar { include ::monitor }

to include class monitor and not foo::monitor, you wouldnt want that to do 
weird scope things

-- 
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] Reconciling resource defaults, dynamic scope, and the singleton nature of classes

[Jeff McCune]

On Thu, Jul 29, 2010 at 12:58 PM, Nigel Kersten  wrote:

> > How do you "know" what the scope is of those included classes will end
> > up as?  Are you not including the "edge" classes multiple times?
>
> Nope. That would be insane due to what sparked this thread off :)


I think this is something that is really becoming an issue with the
increasing number of modules published to the Forge.  Modules need some way
to satisfy their dependencies on other modules, and the current behavior of
include just doesn't seem to cut it.

What about include ::localyumrepository ?

It's valid syntax in 0.24.9, 0.25.5, and 2.6.0

And...  Believe it or not, it actually already does almost exactly what I
want it to do in 2.6, except I think I found a bug in 2.6.

Here's my test manifest:
#
class leaf { notify { "leaf": } }
class baseone {
  Notify { message => "baseone" }
  notify { "baseone": }
  include ::leaf
}
class basetwo {
  Notify { message => "basetwo" }
  notify { "basetwo": }
  include ::leaf
}
include baseone, basetwo
# include basetwo, baseone

Here's the result in 0.25.5 and 0.24.9:
notice: baseone
notice: //baseone/Notify[baseone]/message: defined 'message' as 'baseone'
notice: baseone
notice: //baseone/leaf/Notify[leaf]/message: defined 'message' as 'baseone'
notice: basetwo
notice: //basetwo/Notify[basetwo]/message: defined 'message' as 'basetwo'

Notice how Notify[leaf]'s scope is within baseone, which was the first class
to include it.

Now, for the pleasant surprise: (in 2.6.0)
notice: basetwo
notice: /Stage[main]/Basetwo/Notify[basetwo]/message: defined 'message' as
'basetwo'
notice: baseone
notice: /Stage[main]/Leaf/Notify[leaf]/message: defined 'message' as
'baseone'
notice: baseone
notice: /Stage[main]/Baseone/Notify[baseone]/message: defined 'message' as
'baseone'

It *appears* Notify[leaf] is not within the scope of Baseone or Basetwo,
however it's still getting the default value of the message parameter from
the baseone class...  Flipping in the order around to include basetwo,
baseone we get:
notice: /Stage[main]/Leaf/Notify[leaf]/message: defined 'message' as
'basetwo'

Again, it looks like the class is included into top scope, but the behavior
is that we're still getting resource defaults from basetwo's scope.

Thoughts?  Am I insane for wanting include ::leaf to place Leaf at top
scope?

-- 
Jeff McCune
http://www.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-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] Reconciling resource defaults, dynamic scope, and the singleton nature of classes

[Nigel Kersten]

On Thu, Jul 29, 2010 at 12:28 PM, R.I.Pienaar  wrote:
>
> - "Nigel Kersten"  wrote:
>
>> On Thu, Jul 29, 2010 at 12:11 PM, R.I.Pienaar  wrote:
>> >
>> > - "Jeff McCune"  wrote:
>> >
>> >> On Thu, Jul 29, 2010 at 12:07 PM, R.I.Pienaar  wro>
>> >> > - "Jeff McCune"  wrote:
>> >> >
>> >> >> I make the recommendation that classes should include the
>> classes
>> >> >> they depend on, but this appears to be problematic if the class
>> >> doing the
>> >> >> include sets resource defaults, particularity when setting a
>> >> >> relationship in a default like require, before, subscribe and
>> >> notify.
>> >> >> This opens up the door for resource cycles.
>> >> >
>> >> > recommendations are fine, but that is a lot of convention and
>> best
>> >> > practice something that is very hard to pass on to new people,
>> its
>> >> hard
>> >> > to audit and its hard to predict.  And ones established as a
>> best
>> >> practise
>> >> > that causes problems when ignored also lulls one into a false
>> sense
>> >> of
>> >> > safety.
>> >>
>> >> Agreed.  As you mentioned this has been on my mind for quite a
>> while
>> >> now.  The unpredictability of scope when a class is included
>> multiple
>> >> times has been pushed to front of my mind since it's been such a
>> >> common point of confusion when talking with many people, both new
>> and
>> >> experienced.
>> >>
>> >> > best avoided, it should do the right thing by default.
>> >>
>> >> Agreed.  This begs the question; what is the "right thing" puppet
>> >> should be doing by default?
>> >>
>> >> >> Perhaps it might be useful to set resource defaults only for
>> the
>> >> >> local scope, and not for any classes which get included into
>> this
>> >> scope.
>> >> >> How do you feel about this change to the language?
>> >> >
>> >> > I've thought about this problem before and thought the fact that
>> >> puppet
>> >> > did not behave in this way was a bug, so my vote is with this :)
>> >>
>> >> Do you think resource defaults should default to the local scope
>> if
>> >> the default isn't declared in the top or node scope?
>> >
>> > I had not considered the global scope defaults, I dont use them cos
>> I
>> > like the side effect of a manifest to be clear when looking at a
>> single
>> > pp file.  I'd only ever set a default that I expect to be localized
>> > to the class its in.  but thats just me as Nigel points out :)
>>
>> So we only do it for quite specific cases, turning off file backups
>> and forcing application, ensuring our desired provider is explicit
>> (we've had the odd issue where the automatic provider selection
>> didn't
>> behave the way we wanted) and ensuring that our apt packages all
>> require our "update-apt-stuff" class.
>>
>> File { force => true, backup => false, }
>
> I think this should be a configuration option tbh - to disable backups, not 
> force :)

Ah, but we have the odd little file that we do choose to backup :) so
a default makes sense here.

>
>>   Package {
>>     provider => "apt",
>>     require  => Class["package::apt::update"]
>>   }
>>
>> We basically have provider defaults explicitly set as global resource
>> defaults for package and service for each of our platforms.
>
> I've wrapped all my package access in a define that does this kind of thing
> among others, but it just means i can control all the specific behavior in
> one place and if i get a new site or new needs its one update.
>
> I do this with quite a lot of things, all about explicit behavior and not
> side effects of something not visible in diff's being mailed by post commit
> hooks.

I'm also moving things to defines rather than resource defaults,
primarily because you can append to the relationships rather than
replacing them, but I'm not sure it's any more explicit to have to go
look at the definition rather than resource default? I guess if you're
using defaults in a non-sane manner it might be :)



>
> --
> 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] Re: manage_internal_file_permissions, /etc/sysconfig, and/or command line startup...

[Chad Huneycutt]

Maybe I am missing one of your requirements, but I keep my puppet
master files somewhere other than /etc/puppet and /var/lib/puppet, and
I just use the --confdir option to puppetmasterd.

$ grep PUPPETMASTER_EXTRA_OPTS /etc/sysconfig/puppetmaster
PUPPETMASTER_EXTRA_OPTS="--confdir /tr01/puppet"


- Chad

On Thu, Jul 29, 2010 at 1:57 PM, Tom  wrote:
> That's what I thought, but it doesn't work.  So there's nothing wrong
> with what I'm doing?  Perhaps I should file a bug report...
>
>
> Centos 5.5, Puppet 2.6:
>
>
> # ls -ld /etc/puppet
> lrwxrwxrwx 1 root root 21 Jul 29 17:56 /etc/puppet -> /usr/local/etc/
> puppet
> # ls -ld /var/lib/puppet
> lrwxrwxrwx 1 root root 36 Jul 29 17:56 /var/lib/puppet -> /usr/local/
> etc/puppet/var/lib/puppet
>
>
> # puppetmasterd --no-manage_internal_file_permissions
>
>
> # ls -ld /etc/puppet
> drwxr-xr-x 4 root root 4096 Jul 29 17:57 /etc/puppet
> # ls -ld /var/lib/puppet
> drwxr-xr-x 12 root root 4096 Jul 29 17:57 /var/lib/puppet
>
>
>
>
>
> On Jul 29, 3:26 am, Alan Barrett  wrote:
>> On Wed, 28 Jul 2010, Tom wrote:
>> > "Note that you can set =??manage_internal_file_permissions=?? to false to
>> > disable this behaviour."
>>
>> > So that's what I was trying to do - use
>> > "manage_internal_file_permissions" to disable it.  But that doesn't
>> > seem to work either, does it?  You can't use this from the command
>> > line, can you?
>>
>> The command-line equivalent would be
>> "--no-manage_internal_file_permissions".
>> Be careful with the hyphens and underlines.
>>
>> --apb (Alan Barrett)
>
> --
> 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.
>
>



-- 
Chad M. Huneycutt

-- 
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] Reconciling resource defaults, dynamic scope, and the singleton nature of classes

[R.I.Pienaar]

- "Nigel Kersten"  wrote:

> On Thu, Jul 29, 2010 at 12:11 PM, R.I.Pienaar  wrote:
> >
> > - "Jeff McCune"  wrote:
> >
> >> On Thu, Jul 29, 2010 at 12:07 PM, R.I.Pienaar  wro>
> >> > - "Jeff McCune"  wrote:
> >> >
> >> >> I make the recommendation that classes should include the
> classes
> >> >> they depend on, but this appears to be problematic if the class
> >> doing the
> >> >> include sets resource defaults, particularity when setting a
> >> >> relationship in a default like require, before, subscribe and
> >> notify.
> >> >> This opens up the door for resource cycles.
> >> >
> >> > recommendations are fine, but that is a lot of convention and
> best
> >> > practice something that is very hard to pass on to new people,
> its
> >> hard
> >> > to audit and its hard to predict.  And ones established as a
> best
> >> practise
> >> > that causes problems when ignored also lulls one into a false
> sense
> >> of
> >> > safety.
> >>
> >> Agreed.  As you mentioned this has been on my mind for quite a
> while
> >> now.  The unpredictability of scope when a class is included
> multiple
> >> times has been pushed to front of my mind since it's been such a
> >> common point of confusion when talking with many people, both new
> and
> >> experienced.
> >>
> >> > best avoided, it should do the right thing by default.
> >>
> >> Agreed.  This begs the question; what is the "right thing" puppet
> >> should be doing by default?
> >>
> >> >> Perhaps it might be useful to set resource defaults only for
> the
> >> >> local scope, and not for any classes which get included into
> this
> >> scope.
> >> >> How do you feel about this change to the language?
> >> >
> >> > I've thought about this problem before and thought the fact that
> >> puppet
> >> > did not behave in this way was a bug, so my vote is with this :)
> >>
> >> Do you think resource defaults should default to the local scope
> if
> >> the default isn't declared in the top or node scope?
> >
> > I had not considered the global scope defaults, I dont use them cos
> I
> > like the side effect of a manifest to be clear when looking at a
> single
> > pp file.  I'd only ever set a default that I expect to be localized
> > to the class its in.  but thats just me as Nigel points out :)
> 
> So we only do it for quite specific cases, turning off file backups
> and forcing application, ensuring our desired provider is explicit
> (we've had the odd issue where the automatic provider selection
> didn't
> behave the way we wanted) and ensuring that our apt packages all
> require our "update-apt-stuff" class.
> 
> File { force => true, backup => false, }

I think this should be a configuration option tbh - to disable backups, not 
force :)

>   Package {
> provider => "apt",
> require  => Class["package::apt::update"]
>   }
> 
> We basically have provider defaults explicitly set as global resource
> defaults for package and service for each of our platforms.

I've wrapped all my package access in a define that does this kind of thing
among others, but it just means i can control all the specific behavior in 
one place and if i get a new site or new needs its one update.

I do this with quite a lot of things, all about explicit behavior and not 
side effects of something not visible in diff's being mailed by post commit
hooks.

-- 
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] Reconciling resource defaults, dynamic scope, and the singleton nature of classes

[Nigel Kersten]

On Thu, Jul 29, 2010 at 12:11 PM, R.I.Pienaar  wrote:
>
> - "Jeff McCune"  wrote:
>
>> On Thu, Jul 29, 2010 at 12:07 PM, R.I.Pienaar  wro>
>> > - "Jeff McCune"  wrote:
>> >
>> >> I make the recommendation that classes should include the classes
>> >> they depend on, but this appears to be problematic if the class
>> doing the
>> >> include sets resource defaults, particularity when setting a
>> >> relationship in a default like require, before, subscribe and
>> notify.
>> >> This opens up the door for resource cycles.
>> >
>> > recommendations are fine, but that is a lot of convention and best
>> > practice something that is very hard to pass on to new people, its
>> hard
>> > to audit and its hard to predict.  And ones established as a best
>> practise
>> > that causes problems when ignored also lulls one into a false sense
>> of
>> > safety.
>>
>> Agreed.  As you mentioned this has been on my mind for quite a while
>> now.  The unpredictability of scope when a class is included multiple
>> times has been pushed to front of my mind since it's been such a
>> common point of confusion when talking with many people, both new and
>> experienced.
>>
>> > best avoided, it should do the right thing by default.
>>
>> Agreed.  This begs the question; what is the "right thing" puppet
>> should be doing by default?
>>
>> >> Perhaps it might be useful to set resource defaults only for the
>> >> local scope, and not for any classes which get included into this
>> scope.
>> >> How do you feel about this change to the language?
>> >
>> > I've thought about this problem before and thought the fact that
>> puppet
>> > did not behave in this way was a bug, so my vote is with this :)
>>
>> Do you think resource defaults should default to the local scope if
>> the default isn't declared in the top or node scope?
>
> I had not considered the global scope defaults, I dont use them cos I
> like the side effect of a manifest to be clear when looking at a single
> pp file.  I'd only ever set a default that I expect to be localized
> to the class its in.  but thats just me as Nigel points out :)

So we only do it for quite specific cases, turning off file backups
and forcing application, ensuring our desired provider is explicit
(we've had the odd issue where the automatic provider selection didn't
behave the way we wanted) and ensuring that our apt packages all
require our "update-apt-stuff" class.

File { force => true, backup => false, }

  Package {
provider => "apt",
require  => Class["package::apt::update"]
  }

We basically have provider defaults explicitly set as global resource
defaults for package and service for each of our platforms.

I have had the odd situation where I couldn't use a resource default
due to the scope inheritance, but that's it. The vast majority of our
defaults are either global, or in a class that doesn't include any
other classes. The latter case we do for readability and to reduce
fat-fingering.

>
>
>> Perhaps it would be sufficient to prevent "include" from granting
>> access to the local scope and instead limit scope to namespaces and
>> class inheritance?
>>
>> I'm not too familiar with the code inside of puppet at this level, so
>> it may be far more sensible to just introduce a "local" keyword to
>> declare resource defaults in the local scope only, but I'm not sure
>> this wouldn't satisfy the "behave by default" goal we have.
>>
>
> I guess so, it sounds all a bit magic really.  If this doable then kewl,
> otherwise some new syntax for indicating global scoped defaults.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To post to this group, send email to puppet-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.

[Puppet Users] Multiple repositories under one file

[CraftyTech]

Hello All,

 In all the examples that I see you configure one repo per file;
i.e:

yumrepo { "testing.com-repo":
baseurl => "http://repos.testing.com/fedora/$lsbdistrelease/";,
descr => "Testing.com's YUM repository",
enabled => 1,
gpgcheck => 0,
}

But how do I specify multiple entries to the same file?.  For
instance, I just one to have one file "base.repo" to contains all the
entries for the repos for my environment.  i.e:
/etc/yum.repo.d/base.repo:
[base]
baseurl 
Desc 
[3rdParty]
baseurl 
Desc 

I'm running puppet 0.25.5.

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] Reconciling resource defaults, dynamic scope, and the singleton nature of classes

[R.I.Pienaar]

- "Jeff McCune"  wrote:

> On Thu, Jul 29, 2010 at 12:07 PM, R.I.Pienaar  wro>
> > - "Jeff McCune"  wrote:
> >
> >> I make the recommendation that classes should include the classes
> >> they depend on, but this appears to be problematic if the class
> doing the
> >> include sets resource defaults, particularity when setting a
> >> relationship in a default like require, before, subscribe and
> notify.
> >> This opens up the door for resource cycles.
> >
> > recommendations are fine, but that is a lot of convention and best
> > practice something that is very hard to pass on to new people, its
> hard
> > to audit and its hard to predict.  And ones established as a best
> practise
> > that causes problems when ignored also lulls one into a false sense
> of
> > safety.
> 
> Agreed.  As you mentioned this has been on my mind for quite a while
> now.  The unpredictability of scope when a class is included multiple
> times has been pushed to front of my mind since it's been such a
> common point of confusion when talking with many people, both new and
> experienced.
> 
> > best avoided, it should do the right thing by default.
> 
> Agreed.  This begs the question; what is the "right thing" puppet
> should be doing by default?
> 
> >> Perhaps it might be useful to set resource defaults only for the
> >> local scope, and not for any classes which get included into this
> scope.
> >> How do you feel about this change to the language?
> >
> > I've thought about this problem before and thought the fact that
> puppet
> > did not behave in this way was a bug, so my vote is with this :)
> 
> Do you think resource defaults should default to the local scope if
> the default isn't declared in the top or node scope?

I had not considered the global scope defaults, I dont use them cos I
like the side effect of a manifest to be clear when looking at a single
pp file.  I'd only ever set a default that I expect to be localized 
to the class its in.  but thats just me as Nigel points out :)


> Perhaps it would be sufficient to prevent "include" from granting
> access to the local scope and instead limit scope to namespaces and
> class inheritance?
> 
> I'm not too familiar with the code inside of puppet at this level, so
> it may be far more sensible to just introduce a "local" keyword to
> declare resource defaults in the local scope only, but I'm not sure
> this wouldn't satisfy the "behave by default" goal we have.
> 

I guess so, it sounds all a bit magic really.  If this doable then kewl,
otherwise some new syntax for indicating global scoped defaults.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-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] Reconciling resource defaults, dynamic scope, and the singleton nature of classes

[Nigel Kersten]

On Thu, Jul 29, 2010 at 11:51 AM, Jeff McCune  wrote:
> On Thu, Jul 29, 2010 at 12:37 PM, Nigel Kersten  wrote:
>> On Thu, Jul 29, 2010 at 10:48 AM, Jeff McCune  wrote:
>>
>>> Perhaps it might be useful to set resource defaults only for the local
>>> scope, and not for any classes which get included into this scope.
>>> How do you feel about this change to the language?
>>
>> So this would mean that you'd only be able to set truly global
>> resource defaults with an import in site.pp? and no longer inside a
>> base class that includes all your other classes?
>>
>> We make use of the current behavior of defaults being applied to
>> included classes quite a lot, and I find it useful just to provide a
>> counterpoint to RIP :)
>
> How do you "know" what the scope is of those included classes will end
> up as?  Are you not including the "edge" classes multiple times?

Nope. That would be insane due to what sparked this thread off :)


-- 
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] Reconciling resource defaults, dynamic scope, and the singleton nature of classes

[Jeff McCune]

On Thu, Jul 29, 2010 at 12:37 PM, Nigel Kersten  wrote:
> On Thu, Jul 29, 2010 at 10:48 AM, Jeff McCune  wrote:
>
>> Perhaps it might be useful to set resource defaults only for the local
>> scope, and not for any classes which get included into this scope.
>> How do you feel about this change to the language?
>
> So this would mean that you'd only be able to set truly global
> resource defaults with an import in site.pp? and no longer inside a
> base class that includes all your other classes?
>
> We make use of the current behavior of defaults being applied to
> included classes quite a lot, and I find it useful just to provide a
> counterpoint to RIP :)

How do you "know" what the scope is of those included classes will end
up as?  Are you not including the "edge" classes multiple times?

-- 
Jeff McCune
http://www.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-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] Reconciling resource defaults, dynamic scope, and the singleton nature of classes

[Jeff McCune]

On Thu, Jul 29, 2010 at 12:07 PM, R.I.Pienaar  wro>
> - "Jeff McCune"  wrote:
>
>> I make the recommendation that classes should include the classes
>> they depend on, but this appears to be problematic if the class doing the
>> include sets resource defaults, particularity when setting a
>> relationship in a default like require, before, subscribe and notify.
>> This opens up the door for resource cycles.
>
> recommendations are fine, but that is a lot of convention and best
> practice something that is very hard to pass on to new people, its hard
> to audit and its hard to predict.  And ones established as a best practise
> that causes problems when ignored also lulls one into a false sense of
> safety.

Agreed.  As you mentioned this has been on my mind for quite a while
now.  The unpredictability of scope when a class is included multiple
times has been pushed to front of my mind since it's been such a
common point of confusion when talking with many people, both new and
experienced.

> best avoided, it should do the right thing by default.

Agreed.  This begs the question; what is the "right thing" puppet
should be doing by default?

>> Perhaps it might be useful to set resource defaults only for the
>> local scope, and not for any classes which get included into this scope.
>> How do you feel about this change to the language?
>
> I've thought about this problem before and thought the fact that puppet
> did not behave in this way was a bug, so my vote is with this :)

Do you think resource defaults should default to the local scope if
the default isn't declared in the top or node scope?

Perhaps it would be sufficient to prevent "include" from granting
access to the local scope and instead limit scope to namespaces and
class inheritance?

I'm not too familiar with the code inside of puppet at this level, so
it may be far more sensible to just introduce a "local" keyword to
declare resource defaults in the local scope only, but I'm not sure
this wouldn't satisfy the "behave by default" goal we have.

-- 
Jeff McCune
http://www.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-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] Pro Puppet

[James Turnbull]

Al @ Lab42 wrote:
> This is actually a question for James, but I think it's interesting
> for many out there.
> When the new book about Puppet is going to be released? Will it cover
> 2.6?

It's been delayed because my move and some issues with the publisher.
Hopefully by the end of the year. It will cover 2.6.x.

James

-- 
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] Reconciling resource defaults, dynamic scope, and the singleton nature of classes

[Nigel Kersten]

On Thu, Jul 29, 2010 at 10:48 AM, Jeff McCune  wrote:

> Perhaps it might be useful to set resource defaults only for the local
> scope, and not for any classes which get included into this scope.
> How do you feel about this change to the language?

So this would mean that you'd only be able to set truly global
resource defaults with an import in site.pp? and no longer inside a
base class that includes all your other classes?

We make use of the current behavior of defaults being applied to
included classes quite a lot, and I find it useful just to provide a
counterpoint to RIP :)

>
> Is there some other organization of the class structure I'm overlooking?
>
> Thanks for your feedback,
> --
> Jeff McCune
> http://www.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-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.

[Puppet Users] render template

[Christopher Johnston]

Is there a way in puppet to make the client render a template from a module
and have it spit the contents of the template to stdout or to a file so it
can be looked at before deploying?

-Chris

-- 
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] Newbie question - package installation

[Patrick Mohr]

On Jul 29, 2010, at 9:45 AM, Rustler wrote:

> This code is working - but due to the file declaration it keeps
> downloading the rpm even after the package gets installed.
> 
> 1. How do I stop the rpm from downloading after the package is
> installed?


Best method:
*) If at all possible you should just replace this with a real package 
repository.

Should also work:
*) Put the rpm files on a webserver and download them as needed.  I think rpm 
can take URLs instead of local paths.
or
*)Install from a network drive like nfs


Not recommended:
*) Just put the rpms into a folder you create.  It will keep growing forever, 
but it probably won't ever get very big unless you release a lot of packages.  
Trust me on this, pushing out big files with puppet is probably a mistake.  It 
will put a large load on the puppetmaster, and if you are using a version of 
puppet less than 2.6.0, the RAM requirements on the client and serve will be 
horrendous.

-- 
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] Reconciling resource defaults, dynamic scope, and the singleton nature of classes

[R.I.Pienaar]

- "Jeff McCune"  wrote:

> I make the recommendation that classes should include the classes
> they depend on, but this appears to be problematic if the class doing the
> include sets resource defaults, particularity when setting a
> relationship in a default like require, before, subscribe and notify.
> This opens up the door for resource cycles.

recommendations are fine, but that is a lot of convention and best 
practice something that is very hard to pass on to new people, its hard
to audit and its hard to predict.  And ones established as a best practise
that causes problems when ignored also lulls one into a false sense of
safety.

best avoided, it should do the right thing by default.

> Perhaps it might be useful to set resource defaults only for the
> local scope, and not for any classes which get included into this scope.
> How do you feel about this change to the language?

I've thought about this problem before and thought the fact that puppet
did not behave in this way was a bug, so my vote is with this :)

-- 
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: manage_internal_file_permissions, /etc/sysconfig, and/or command line startup...

[Tom]

That's what I thought, but it doesn't work.  So there's nothing wrong
with what I'm doing?  Perhaps I should file a bug report...


Centos 5.5, Puppet 2.6:


# ls -ld /etc/puppet
lrwxrwxrwx 1 root root 21 Jul 29 17:56 /etc/puppet -> /usr/local/etc/
puppet
# ls -ld /var/lib/puppet
lrwxrwxrwx 1 root root 36 Jul 29 17:56 /var/lib/puppet -> /usr/local/
etc/puppet/var/lib/puppet


# puppetmasterd --no-manage_internal_file_permissions


# ls -ld /etc/puppet
drwxr-xr-x 4 root root 4096 Jul 29 17:57 /etc/puppet
# ls -ld /var/lib/puppet
drwxr-xr-x 12 root root 4096 Jul 29 17:57 /var/lib/puppet





On Jul 29, 3:26 am, Alan Barrett  wrote:
> On Wed, 28 Jul 2010, Tom wrote:
> > "Note that you can set =??manage_internal_file_permissions=?? to false to
> > disable this behaviour."
>
> > So that's what I was trying to do - use
> > "manage_internal_file_permissions" to disable it.  But that doesn't
> > seem to work either, does it?  You can't use this from the command
> > line, can you?
>
> The command-line equivalent would be
> "--no-manage_internal_file_permissions".
> Be careful with the hyphens and underlines.
>
> --apb (Alan Barrett)

-- 
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] Reconciling resource defaults, dynamic scope, and the singleton nature of classes

[Jeff McCune]

Hello,

I've been thinking about how best to handle the situation where a
single class is included multiple times from multiple classes who
themselves set resource defaults.  This situation poses an interesting
problem in Puppet because of dynamic scoping rather than lexical
scoping and appears to come up frequently as I travel and work with
the puppet community.  It's also come up quite a bit in my own work
and development of modules for the forge.

I'm looking for feedback from the community as to how best to handle
the unique situation in a maintainable and elegant manner.

This is pretty long, but it's a rather complex problem and fairly
common in my experience, so thanks in advance for taking the time to
read through if you do.

I believe an use case will illustrate the point.

Consider a module, perhaps publicly available in the Forge, which is
extremely common and many other modules require.  A good example is
the configuration of the packaging system for the node to use a local
repository.

# /etc/puppet/modules/localpackagerepository/manifests/init.pp
class localpackagerepository {
  $module = "localpackagerepository"
  file { "/etc/yum/yum.repos.d/local.repo": source =>
"puppet:///modules/${module}/local.repo"; }
}

Other classes will likely establish a relationship in the graph to
this localpackagerepository class to ensure custom packages are
available before trying to manage their state.  For example:

# /etc/puppet/modules/apache/manifests/init.pp
class apache {
  $module = "apache"
  include localpackagerepository
  File {
owner => "apache",
group => "apache",
require => Package["apache"],
notify => Service["apache"],
  }
  ###
  package { "apache":
ensure => installed,
require => Class["localpackagerepository"];
  }
  service { "apache": ensure => running }
  file { "/etc/httpd/httpd.conf": source =>
"puppet:///modules/${module}/apache.conf"; }
}

# /etc/puppet/modules/postfix/manifests/init.pp
class postfix {
  $module = "postfix"
  include localpackagerepository
  File {
owner => "mail",
group => "mail",
require => Package["postfix"],
notify => Service["postfix"],
  }
  package { "postfix":
ensure => installed,
require => Class["localpackagerepository"];
  }
  service { "postfix": ensure => running; }
  file { "/etc/postfix/main.cf": source =>
"puppet:///modules/${module}/main.cf"; }
}

Now, with these three modules we may include them in the node
classification like so:
include apache
include postfix

However, this will behave very differently than the classes included
in a different order:
include postfix
include apache

In the first ordering the localpackagerepository class will take on
the resource defaults of the apache class, while in the second
ordering the localpackagerepository class will take on the resource
defaults of the postfix class.

In both cases there will be a circular dependency (local.repo will
require a package, and the package will require local.repo), which is
clearly an issue.  In either case, local.repo will take on defaults
for owner and group which are invalid.

How are you handling this situation?  How do you think this situation
*should* be handled by puppet?

I can think of a number of work arounds, but they're not ideal and
they don't feel to me like they'll play well with public modules
posted to the forge.

I make the recommendation that classes should include the classes they
depend on, but this appears to be problematic if the class doing the
include sets resource defaults, particularity when setting a
relationship in a default like require, before, subscribe and notify.
This opens up the door for resource cycles.

Perhaps it might be useful to set resource defaults only for the local
scope, and not for any classes which get included into this scope.
How do you feel about this change to the language?

Is there some other organization of the class structure I'm overlooking?

Thanks for your feedback,
-- 
Jeff McCune
http://www.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-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] Newbie question - package installation

[Rustler]

This code is working - but due to the file declaration it keeps
downloading the rpm even after the package gets installed.

1. How do I stop the rpm from downloading after the package is
installed?

class svn {

$TMP = "/tmp"
$RPM = "CollabNetSubversion-client-1.6.12-1.i386.rpm"

package { "svn":
name => "CollabNetSubversion-client-1.6.12-1",
ensure   => installed,
provider => rpm,
source   => "$TMP/$RPM",
require  => file["$TMP/$RPM"]
}

file { "$TMP/$RPM":
source => "puppet://puppet.xxx.com/files/svn/$RPM"
}

file { "/usr/bin/svn":
ensure => symlink,
replace => true,
target  => "/opt/CollabNet_Subversion/bin/svn"
}

}

-- 
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] Figuring out Stages

[Ryan Y. Coleman]

Hello All, I'm hoping to figure out how to use stages to reduce how many 
require statements are used in a particular module. 

I'm using the brief examples in the documentation as a reference but I can't 
grep how to implement the staging. 
http://docs.puppetlabs.com/references/2.6.0/metaparameter.html#stage

Let's say I have three classes that I've separated my content into...

class foo::pre {}
class foo::deploy {}
class foo::configure {}

I would like to stage them such that pre occurs first, followed by deploy, 
finished by configure. 


The documentation suggests you create new stages as resources. Does this mean 
that in each class I create the stage resource like this example?

class foo::pre {
stage {pre: }
}
class foo::deploy {
stage {deploy: }
}
class foo::configure {
stage {configure: }
}


The documentation also suggests you use class parameters to specify your stage. 
It gives the example of class { foo: stage => pre}. Does this mean you must 
create the stages in a different class then you use to specify the stage? 

I got to this point and confused myself so I'm hoping one of you can clear me 
up. Thanks!

--Ryan

-- 
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: can not boot zone

[deet]

>
> I am using nested zfs filesystems:>zfs list -o name,zoned,mountpoint
>

  I used the following script to create a zone on zfs nested
filesystem and this worked

node default {
  zone { "nested":
  realhostname => "nested",
  autoboot => "true",
  path => "/nested/mount/zones/nested",
  ip   => ["e1000g0:10.1.16.240" ],
  sysidcfg => "zones/sysidcfg",
  }
}

puppet ./zone-works.pp
notice: //Node[default]/Zone[nested]/ensure: created

zoneadm -z nested list -v
  ID NAME STATUS PATH
BRANDIP
  10 nested   running/nested/mount/zones/nested
native   shared

zfs list |grep nested
rpool/nested  3.87G  85.1G
23K  /nested
rpool/nested/mount3.87G  85.1G
23K  /nested/mount
rpool/nested/mount/zones  3.87G  85.1G
23K  /nested/mount/zones
rpool/nested/mount/zones/nested   3.87G  85.1G
3.87G  /nested/mount/zones/nested

  The zoned setting appears to only matter for a dataset given to a
non-global zone.  I would suggest you try to spin up the same zone on
a non nested zfs filesystem to see if that works.   I've used zones on
all versions of Solaris 10 and have not encountered the error your
hitting but i've never used nested mounts and I've only used puppet to
spin up zones on update 8 nodes.   I'm thinking their may be something
related to the nested mounts and your Solaris patch level?

   HTH. Derek.



> NAME                               ZONED  MOUNTPOINT
> rootpool                             off  /rootpool
> rootpool/ROOT                        off  legacy
> rootpool/ROOT/s10x_u7                off  /
> rootpool/ROOT/s10x_u7/var            off  /var
> rootpool/dump                          -  -
> rootpool/export                      off  /export
> rootpool/export/home                 off  /export/home
> rootpool/export/zones                off  /export/zones
> rootpool/export/zones/test           off  /export/zones/test
> rootpool/swap                          -  -
>
> Here is my zonecfg:>zonecfg -z test info
>
> zonename: test
> zonepath: /export/zones/test
> brand: native
> autoboot: true
> bootargs:
> pool:
> limitpriv:
> scheduling-class:
> ip-type: shared
> net:
>         address: 192.168.1.100
>         physical: aggr10001
>         defrouter not specified
>
> I don't get the error when the zonepath is on a ufs filesystem.
> Originally I was thinking that the error was only on newer releases of
> solaris, but it probably has more to do with ufs vs. zfs.
>
> 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-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_Augeas: Working Examlples

[Rob McBroom]

On Jul 28, 2010, at 11:39 AM, Andrei Pozolotin wrote:

> and those of us who are no longer in the dark, please add there your
> working examples - for enlightenment, you know :-)

I just added a bunch of stuff starting here:

http://projects.puppetlabs.com/projects/puppet/wiki/Puppet_Augeas#Simple+Examples

I wonder if the discussions of numbered items and “onlyif” should be up in the 
main body of the doc before it gets into the working examples, since those are 
pretty fundamental things. Thoughts?

I don’t seem to have a lens for `/etc/exports`, but I’m pretty sure that 
example is wrong. Can anyone test it? (Not one of my examples. It’s one of the 
first up in the main body.)

I wrote everything in Markdown before I tried to edit the page. Happy to find 
out all I had to do was “Paste” and be done. :)

-- 
Rob McBroom


Don't try to tell me something is important to you if the whole of your 
“support” entails getting Congress to force *others* to spend time and money on 
it.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-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] Test if stored config is enabled?

[dom]

Hi

I'd like to be able to test if stored config is enabled and active,
and if not then react (eg. notice or die).

Is there any way of doing this?

Thanks
Dom

-- 
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_Augeas: Working Examlples

[Andrei Pozolotin]

Rob, hi

On Jul 29, 8:45 am, Rob McBroom  wrote:
> I wonder about wrapping things in a define for something as simple as 
> `sysctl.conf` though. > By doing that, every individual line will spawn it’s 
> own Augeas resource.

you are right; ideally I want this:

a) have "sysctl:conf" calls scattered where needed, so I do not have
to keep it in one place as you suggested;

b) avoid "new augeas per define"; it is indeed a cpu hog;

I do not know how to solve this yet;

James Turnbull, are you there? a drop of your wisdom, please? :-)

Thanks

Andrei

-- 
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] 2.6 and modules: Invalid resource type

[Rudy Gevaert]

Dear puppet community,

I am having problems using a module puppetlabs-vcsrepo from the forge.

I'm getting the error:
err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Puppet::Parser::AST::Resource failed with error ArgumentError:
Invalid resource type vcsrepo at /etc/puppet/development/manifests/
nodes.pp:37 on node puptest.ugent.be

server puppet.conf:

[main]
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
factpath=$vardir/lib/facter
pluginsync=true
environment=production
modulepath=$confdir/common/modules
templatedir=$confdir/common/templates

[development]
manifest=$confdir/development/manifests/site.pp
modulepath=$confdir/development/modules:$confdir/common/modules
templatedir=$confdir/development/templates:$confdir/common/templates

[production]
manifest=$confdir/production/manifests/site.pp
modulepath=$confdir/production/modules:$confdir/common/modules
templatedir=$confdir/production/templates:$confdir/common/templates

[master]
certname=puppet.ugent.be
reports = store,log
ssl_client_header = SSL_CLIENT_S_DN
ssl_client_verify_header = SSL_CLIENT_VERIFY

client puppet.conf:
[main]
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
factpath=$vardir/lib/facter
pluginsync=true
templatedir=$confdir/templates
runinterval=60
server=puppet.ugent.be

[agent]
environment=development

Server layout:

/etc/puppet/
|-- common
|   |-- modules
|   |   `-- lib
|   `-- templates
|-- development
|   |-- manifests
|   |   |-- classes
|   |   |-- definitions
|   |   |-- groups
|   |   |-- os
|   |   |-- templates
|   |   `-- users
|   |-- modules
|   |   |-- apache
|   |   |-- collectd
|   |   |-- netbackup
|   |   |-- ntp
|   |   |-- sysstat
|   |   `-- vcsrepo
|   `-- templates
|   `-- saslauthd
|-- files
|-- lib
|-- manifests
|-- production
|   |-- manifests
|   |-- modules
|   |   `-- lib
|   `-- templates


node config:

node ugent_node {
  include ugent
}

node "puptest.ugent.be" inherits ugent_node {
include vcsrepo
   vcsrepo { "/tmp/vcstest-svn-checkout":
 ensure => present,
 provider => svn,
source => 'http://svn.edgewall.org/repos/babel/trunk'
   }
}

vcsrepo (0.0.3 from the forge:)

wopr:/etc/puppet/development/modules# tree  vcsrepo/
vcsrepo/
|-- LICENSE
|-- Modulefile
|-- Rakefile
|-- examples
|   |-- bzr
|   |   |-- branch.pp
|   |   `-- init_repo.pp
|   |-- cvs
|   |   |-- local.pp
|   |   `-- remote.pp
|   |-- git
|   |   |-- bare_init.pp
|   |   |-- clone.pp
|   |   `-- working_copy_init.pp
|   |-- hg
|   |   |-- clone.pp
|   |   `-- init_repo.pp
|   `-- svn
|   |-- checkout.pp
|   `-- server.pp
|-- lib
|   `-- puppet
|   |-- provider
|   |   |-- vcsrepo
|   |   |   |-- bzr.rb
|   |   |   |-- cvs.rb
|   |   |   |-- git.rb
|   |   |   |-- hg.rb
|   |   |   `-- svn.rb
|   |   `-- vcsrepo.rb
|   `-- type
|   `-- vcsrepo.rb
|-- manifests
|   `-- init.pp
`-- spec
|-- fixtures
|   |-- bzr_version_info.txt
|   |-- git_branch_a.txt
|   |-- hg_parents.txt
|   |-- hg_tags.txt
|   `-- svn_info.txt
|-- spec.opts
|-- spec_helper.rb
|-- support
|   |-- filesystem_helpers.rb
|   |-- fixture_helpers.rb
|   `-- provider_example_group.rb
`-- unit
`-- puppet
|-- provider
|   `-- vcsrepo
|   |-- bzr_spec.rb
|   |-- cvs_spec.rb
|   |-- git_spec.rb
|   |-- hg_spec.rb
|   `-- svn_spec.rb
`-- type

The type and provider and synced to the client:
puptest:/tmp# find /var/lib/puppet/lib/puppet/
/var/lib/puppet/lib/puppet/
/var/lib/puppet/lib/puppet/provider
/var/lib/puppet/lib/puppet/provider/vcsrepo.rb
/var/lib/puppet/lib/puppet/provider/a2mod
/var/lib/puppet/lib/puppet/provider/a2mod/a2mod.rb
/var/lib/puppet/lib/puppet/provider/vcsrepo
/var/lib/puppet/lib/puppet/provider/vcsrepo/svn.rb
/var/lib/puppet/lib/puppet/provider/vcsrepo/git.rb
/var/lib/puppet/lib/puppet/provider/vcsrepo/bzr.rb
/var/lib/puppet/lib/puppet/provider/vcsrepo/cvs.rb
/var/lib/puppet/lib/puppet/provider/vcsrepo/hg.rb
/var/lib/puppet/lib/puppet/type
/var/lib/puppet/lib/puppet/type/vcsrepo.rb
/var/lib/puppet/lib/puppet/type/a2mod.rb

trace output:
...
info: /File[/var/lib/puppet/lib]: Storing newly-audited value  for
content
debug: Finishing transaction 70300949387920
debug: Storing state
debug: Stored state in 0.03 seconds
info: Loading facts in configured_ntp_servers
info: Loading facts in configured_ntp_servers
debug: catalog supports formats: b64_zlib_yaml dot marshal pson raw
yaml; using pson
/usr/lib/ruby/1.8/puppet/indirector/rest.rb:57:in `deserialize'
/usr/lib/ruby/1.8/puppet/indirector/rest.rb:71:in `find'
/usr/lib/ruby/1.8/puppet/indirector/indirection.rb:193:in `find'
/usr/lib/ruby/1.8/puppet/indirector.rb:50:in `find'
/usr/lib/ruby/1.8/puppet/configurer.rb:225:in `retrieve_new_catalog'
/u

[Puppet Users] Re: can not boot zone

[John Lyman]

Derek,

I am using nested zfs filesystems:
>zfs list -o name,zoned,mountpoint
NAME   ZONED  MOUNTPOINT
rootpool off  /rootpool
rootpool/ROOToff  legacy
rootpool/ROOT/s10x_u7off  /
rootpool/ROOT/s10x_u7/varoff  /var
rootpool/dump  -  -
rootpool/export  off  /export
rootpool/export/home off  /export/home
rootpool/export/zonesoff  /export/zones
rootpool/export/zones/test   off  /export/zones/test
rootpool/swap  -  -

Here is my zonecfg:
>zonecfg -z test info
zonename: test
zonepath: /export/zones/test
brand: native
autoboot: true
bootargs:
pool:
limitpriv:
scheduling-class:
ip-type: shared
net:
address: 192.168.1.100
physical: aggr10001
defrouter not specified

I don't get the error when the zonepath is on a ufs filesystem.
Originally I was thinking that the error was only on newer releases of
solaris, but it probably has more to do with ufs vs. zfs.

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-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_Augeas: Working Examlples

[Rob McBroom]

On Jul 28, 2010, at 11:39 AM, Andrei Pozolotin wrote:

> Hello Puppeteers;
> 
> for those of us who are still suffering in the darkness of
> Puppet_Augeas,
> I put  a couple of working examples here:
> 
> http://projects.puppetlabs.com/projects/puppet/wiki/Puppet_Augeas

Nice. I learned a few things I didn’t know (mostly about Puppet syntax).

I wonder about wrapping things in a define for something as simple as 
`sysctl.conf` though. By doing that, every individual line will spawn it’s own 
Augeas resource.

The only reason I bring it up is that when I look at the reports on my 
Puppetmaster, Augeas resources pretty consistently account for 75% of the time 
on each run. In other words, Augeas resources take 3 times as long as all other 
resources put together (and that’s with me combining all the changes for one 
file into a single resource).

> and those of us who are no longer in the dark, please add there your
> working examples - for enlightenment, you know :-)

I’ll see if I have anything worth sharing. Pretty sure I do.

While we’re on the subject, wouldn’t the "export foo” example (which I think 
was already part of the documentation) add a new line on every Puppet run as 
it’s currently written?

-- 
Rob McBroom



-- 
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] Catching failure with templates

[Rob McBroom]

On Jul 28, 2010, at 6:39 PM, Christopher Johnston wrote:

> To solve your pathing issue you could create a define to autocomplete the 
> path for you.

I got that part figured out.

I just set “templatedir” in the puppetmaster section of my `puppet.conf` to be 
the same as the path in my `fileserver.conf`.

Then, in the manifests, I can just do this:

content => template("$environment/path/file.erb"),

-- 
Rob McBroom


It's not that I think guns, drugs, prostitution, swimming, eating and reading 
should be legal. It's just that no one on Earth has the authority to make them 
illegal.

-- 
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: Pro Puppet

[CraftyTech]

Put me down for a copy...

On Jul 29, 5:45 am, "Al @ Lab42"  wrote:
> This is actually a question for James, but I think it's interesting
> for many out there.
> When the new book about Puppet is going to be released? Will it cover
> 2.6?
>
> 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-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: manage_internal_file_permissions, /etc/sysconfig, and/or command line startup...

[Alan Barrett]

On Wed, 28 Jul 2010, Tom wrote:
> "Note that you can set =??manage_internal_file_permissions=?? to false to
> disable this behaviour."
> 
> So that's what I was trying to do - use
> "manage_internal_file_permissions" to disable it.  But that doesn't
> seem to work either, does it?  You can't use this from the command
> line, can you?

The command-line equivalent would be
"--no-manage_internal_file_permissions".
Be careful with the hyphens and underlines.

--apb (Alan Barrett)

-- 
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] Pro Puppet

[Al @ Lab42]

This is actually a question for James, but I think it's interesting
for many out there.
When the new book about Puppet is going to be released? Will it cover
2.6?

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-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] Parameterised Classes in 2.6

[Thorsten Biel]

Hi Doug,

just to give you a 'me too'. Please file a bug, I'll
vote for it.

-Thorsten


On 29 Jul 2010, at 00:13, Douglas Garstang  wrote:

> Has anyone gotten parameterised classes to work in puppet 2.6 yet?
> 
> No luck for me... Seems to be totally broken but I haven't had a
> chance to file a bug against it yet.
> 
> 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.
> 

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