Re: [Puppet Users] virtual resource realizing by require?
Frederik Wagner a écrit :
Hi .*,
I'm wondering if there is a way to have a virtual resource realize
other virtual resources which it requires.
Background: I want to create a module which provides all possible
mountpoints from a NAS Filer as virtual resources, like @mount{xyz}.
These mounts depend on some directory which must exists, and should
only be created if the mount is realized (furthermore some nfs client
options are only needed to be set if a nfs mount takes place at all).
I would think that something like the following would do the job, but
it doesn't.
in some class:
@file{/mountpoint: ensure = directory }
@mount{/mountpoint:
...,
require = File[/mountpoint]
}
in some other class:
Mount| title == /mountpoint |
What am I missing? Or is this not possible at all?
Hello
I never really played with virtual ressources but it seems you forgot to also
realize the file object for your mountpoint?
--
Aurelien Degremont
CEA
--
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] virtual resource realizing by require?
Hi Aurelien,
On Tue, Feb 9, 2010 at 9:32 AM, Aurelien Degremont
aurelien.degrem...@cea.fr wrote:
Frederik Wagner a écrit :
Hi .*,
I'm wondering if there is a way to have a virtual resource realize
other virtual resources which it requires.
Background: I want to create a module which provides all possible
mountpoints from a NAS Filer as virtual resources, like @mount{xyz}.
These mounts depend on some directory which must exists, and should
only be created if the mount is realized (furthermore some nfs client
options are only needed to be set if a nfs mount takes place at all).
I would think that something like the following would do the job, but
it doesn't.
in some class:
@file{/mountpoint: ensure = directory }
@mount{/mountpoint:
...,
require = File[/mountpoint]
}
in some other class:
Mount| title == /mountpoint |
What am I missing? Or is this not possible at all?
Hello
I never really played with virtual ressources but it seems you forgot to
also realize the file object for your mountpoint?
this is exactly the point of my problem, I would like to automatically
realize all resources required by the mount without explicitly stating
it in the module realizing the mount. All requirements should be
encapsulated in the module providing the @mount.
Bye
Frederik
--
Aurelien Degremont
CEA
--
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] virtual resource realizing by require?
Frederik Wagner a écrit :
Hi Aurelien,
On Tue, Feb 9, 2010 at 9:32 AM, Aurelien Degremont
aurelien.degrem...@cea.fr wrote:
Frederik Wagner a écrit :
Hi .*,
I'm wondering if there is a way to have a virtual resource realize
other virtual resources which it requires.
Background: I want to create a module which provides all possible
mountpoints from a NAS Filer as virtual resources, like @mount{xyz}.
These mounts depend on some directory which must exists, and should
only be created if the mount is realized (furthermore some nfs client
options are only needed to be set if a nfs mount takes place at all).
I would think that something like the following would do the job, but
it doesn't.
in some class:
@file{/mountpoint: ensure = directory }
@mount{/mountpoint:
...,
require = File[/mountpoint]
}
in some other class:
Mount| title == /mountpoint |
What am I missing? Or is this not possible at all?
Hello
I never really played with virtual ressources but it seems you forgot to
also realize the file object for your mountpoint?
this is exactly the point of my problem, I would like to automatically
realize all resources required by the mount without explicitly stating
it in the module realizing the mount. All requirements should be
encapsulated in the module providing the @mount.
You need to create your own type with a define
define mymount($mountpoint) {
file { $mountpoint:
ensure = directory
}
mount { $mountpoint:
require = File[$mountpoint],
}
}
@mymount{ /mountpoint:
mountpoint = /mountpoint
}
Mymount| title == /mount_point |
Not sure, but i think this is the good way.
--
Aurelien Degremont
CEA
--
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] virtual resource realizing by require?
Frederik Wagner wrote:
I would think that something like the following would do the job, but
it doesn't.
in some class:
@file{/mountpoint: ensure = directory }
@mount{/mountpoint:
...,
require = File[/mountpoint]
}
in some other class:
Mount| title == /mountpoint |
What am I missing? Or is this not possible at all?
It's not possible to do it that exact way. But, you can use a define:
define foomount($device, $fstype, ...)
{
File | name == $name |
mount { $name: ..., require = File[$name]; }
}
@file { /mountpoint: ensure = directory; }
@foomount { /mountpoint: ...; }
Foomount | title == /mountpoint |
Unless you really want to declare the virtual file resource in some
other place than where you define foomount, it probably makes more
sense to inline that in foomount, though:
define foomount($device, $fstype, ...)
{
file { $name: ensure = directory; }
mount { $name: ..., require = File[$name]; }
}
Hope this helps.
/Bellman
--
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] virtual resource realizing by require?
On Tue, Feb 9, 2010 at 10:55 AM, Aurelien Degremont
aurelien.degrem...@cea.fr wrote:
Frederik Wagner a écrit :
Hi Aurelien,
On Tue, Feb 9, 2010 at 9:32 AM, Aurelien Degremont
aurelien.degrem...@cea.fr wrote:
Frederik Wagner a écrit :
Hi .*,
I'm wondering if there is a way to have a virtual resource realize
other virtual resources which it requires.
Background: I want to create a module which provides all possible
mountpoints from a NAS Filer as virtual resources, like @mount{xyz}.
These mounts depend on some directory which must exists, and should
only be created if the mount is realized (furthermore some nfs client
options are only needed to be set if a nfs mount takes place at all).
I would think that something like the following would do the job, but
it doesn't.
in some class:
@file{/mountpoint: ensure = directory }
@mount{/mountpoint:
...,
require = File[/mountpoint]
}
in some other class:
Mount| title == /mountpoint |
What am I missing? Or is this not possible at all?
Hello
I never really played with virtual ressources but it seems you forgot to
also realize the file object for your mountpoint?
this is exactly the point of my problem, I would like to automatically
realize all resources required by the mount without explicitly stating
it in the module realizing the mount. All requirements should be
encapsulated in the module providing the @mount.
You need to create your own type with a define
define mymount($mountpoint) {
file { $mountpoint:
ensure = directory
}
mount { $mountpoint:
require = File[$mountpoint],
}
}
@mymount{ /mountpoint:
mountpoint = /mountpoint
}
Mymount| title == /mount_point |
Not sure, but i think this is the good way.
good idea and I was thining in a similar direction, but in this way
all the possible mounts are/must be created in the same way, i.e. in
this case a file + a moutn ressource.
I was looking for a generic way, let's say somthing like
@mount{/mountpoint:
...,
require = File| title == /mountpoint] |
}
which would be great. The requirement is realized only when it is needed.
Bye,
Frederik
--
Aurelien Degremont
CEA
--
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] virtual resource realizing by require?
On Tue, 09 Feb 2010, Frederik Wagner wrote:
@file{/mountpoint: ensure = directory }
@mount{/mountpoint:
...,
require = File[/mountpoint]
}
in some other class:
Mount| title == /mountpoint |
I would like to automatically realize all resources required by the
mount without explicitly stating it in the module realizing the
mount. All requirements should be encapsulated in the module providing
the @mount.
There is a feature request for this:
http://projects.reductivelabs.com/issues/2084. Until that is
implemented, I think you'll need to work around it using a define.
--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.
Re: [Puppet Users] virtual resource realizing by require?
On Tue, Feb 9, 2010 at 11:35 AM, Alan Barrett a...@cequrux.com wrote:
On Tue, 09 Feb 2010, Frederik Wagner wrote:
@file{/mountpoint: ensure = directory }
@mount{/mountpoint:
...,
require = File[/mountpoint]
}
in some other class:
Mount| title == /mountpoint |
I would like to automatically realize all resources required by the
mount without explicitly stating it in the module realizing the
mount. All requirements should be encapsulated in the module providing
the @mount.
thanks for the information!
There is a feature request for this:
http://projects.reductivelabs.com/issues/2084. Until that is
implemented, I think you'll need to work around it using a define.
very good, i suppose there is no time schedule for this yet?
I just tried using the define, and hit a problem which I would avoid
(and actually need to avoid) by using the not implemented feature.
Realizing the virtual define across modules forces me to give the
namespace of the define explicitly, i.e. creating the virtual define
@mymount in a class nas-1::virtual (in the Module nas-1) forces me to
realize it in a second module as Nas-1::Virtual::Mymount| |, instead
of just Mymount| |.
But this I have to avoid - and would be avoided by the feature request
- since I use a versioning of the modules which should not be part of
the realize statement, as well as the modules should not know about
each others classnames anyway.
Any idea to work around this?
Thanks a whole lot!
Bye
Frederik
--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.
--
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] Living with Puppet...
Thanks you both for the answers, I'm going to spend some time parsing them :-P Let me clarify - I'm not looking for help or consulting in implementing Puppet on a particular site right now. The objective of my work now is just to make the company aware this exist and see if it is something useful to have in our arsenal, so to say. So my request is not for somebody to help me migrate to Puppet - is to just have a chat (30 minutes or less) with somebody that is actually using it and get the feeling of the tool being used as part of your workflow, not just learning the syntax of the language and things like that. I'm suso on IRC so probably you will see me there pestering you :-P How do you deal with dynamic changes or process (been a theme of discussion lately here) and having Puppet enforcing a state? One time activities are usually not done via puppet, and most people use ssh for this kind of things. Puppet goal is to enforce a state, so that's the default behavior. Yes, but with this kind of automation tools there is always the worry that whatever manual work you are doing now is going to be obliterated later or interfered during your work. So I guess if you have are a Puppet shop, you have a different way to go about things that if you just have N servers around handconfigured and go SSH for everything. When you get a request or find the need to do a change, you try to see if its something to change on a manifest,or just a one time task to run in between puppetd runs, or to have an schedule defining a maintenance window, or... Do changes get to the Puppet admins first to check that? I guess having your infrastructure managed by Puppet makes you have to think more about what is that state that you are mantaining and what are the deviations for that state that can happen and how to manage them... -- -- Jesús Couto F. -- 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] Only send report email if resource failed during run
Hi I have configured puppet to send reports via email using tagsmail. The problem is that it sends all the log messages every run (without a metric summary), which is not so useful. Is it possible to only send a report with the metrics only if one or more resources failed? 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] Only send report email if resource failed during run
Hi, Latest version of foreman (http://theforeman.org) supports this feature. cheers, Ohad On Tue, Feb 9, 2010 at 9:00 PM, symfrog wpdut...@gmail.com wrote: Hi I have configured puppet to send reports via email using tagsmail. The problem is that it sends all the log messages every run (without a metric summary), which is not so useful. Is it possible to only send a report with the metrics only if one or more resources failed? 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.compuppet-users%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Exec doesn't work with Ubuntu Server 10.04 (Lucid Lynx) 64bit
I installed ruby on the above server and tried with a simple exec-
test :
class testmodule {
exec {TEST-EXEC :
cwd = /tmp/,
command =/usr/bin/touch /tmp/ /tmp/123 21,
timeout = 5,
logoutput= on_failure
}
}
This simple thing gets the following output from puppet --debug --
test
debug: Loaded state in 0.00 seconds
info: Applying configuration version '1265719507'
debug: //testmodule/Exec[TEST-EXEC]: Changing returns
debug: //testmodule/Exec[TEST-EXEC]: 1 change(s)
debug: //testmodule/Exec[TEST-EXEC]: Executing '/usr/bin/touch /tmp/
'
debug: Executing '/usr/bin/touch /tmp/'
err: //testmodule/Exec[TEST-EXEC]/returns: change from notrun to 0
failed: Command exceeded timeout at /etc/puppet/modules/testmodule/
manifests/init.pp:6
debug: Finishing transaction 69914685668640 with 1 changes
debug: Storing state
debug: Stored state in 0.01 seconds
debug: Format pson not supported for Puppet::Transaction::Report; has
not implemented method 'from_pson'
debug: Format s not supported for Puppet::Transaction::Report; has not
implemented method 'from_s'
What can I do ? Did i make a mistake, or is exec broken ?
--
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 doesn't work with Ubuntu Server 10.04 (Lucid Lynx) 64bit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/02/10 12:06 AM, kai.steverding wrote: I installed ruby on the above server and tried with a simple exec- test : What Puppet and Ruby versions? Regards James Turnbull - -- Author of: * Pro Linux System Administration (http://tinyurl.com/linuxadmin) * Pulling Strings with Puppet (http://tinyurl.com/pupbook) * Pro Nagios 2.0 (http://tinyurl.com/pronagios) * Hardening Linux (http://tinyurl.com/hardeninglinux) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEVAwUBS3FfxCFa/lDkFHAyAQIdnwf9FVevibgcjvympW3YknpQQlIbgl9MPJIt LoB0JKwqFOs4LjXY+YdP8j3CyIMTtQUGHKTpz5OpPLCBUIUN3spaIfZ/jSfCvozE S20adBerNJKEtU7JMk1JGNCYVimOARJIWf31bpWnB9NiRuJltc7Cjcez/uJ0QpI7 VGYw3rkjwzZDpE7joajcwyalwaY8KkYprRXXGdQWcBfawyHlay0kj8WUNB4BSK/s 9I+RxoFtNehfF8yt+r4VkOpuGgYXnKKG+1lTmQQw/0W7WWOuKWkhYYM00wPU46DX ny3oGioYYIK5eH3YQYVBxVbvH/cD5bLQWgRQT94V2SQ1JkemQiJmPA== =aQtA -END PGP SIGNATURE- -- 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: Only send report email if resource failed during run
Maybe someone has created a simple custom report for this? On Feb 9, 3:03 pm, Ohad Levy ohadl...@gmail.com wrote: Hi, Latest version of foreman (http://theforeman.org) supports this feature. cheers, Ohad On Tue, Feb 9, 2010 at 9:00 PM, symfrog wpdut...@gmail.com wrote: Hi I have configured puppet to send reports via email using tagsmail. The problem is that it sends all the log messages every run (without a metric summary), which is not so useful. Is it possible to only send a report with the metrics only if one or more resources failed? 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.compuppet-users%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: How to disable file checksums?
Hi Brice, Thanks for your suggestion, but alas, it seems to default to mtime 'checksum' then. On 8 feb, 22:43, Brice Figureau brice-pup...@daysofwonder.com wrote: In 0.24.x I know it was possible to: checksum = undef Honestly, knowing how other parts work, I'd expect it to default to mtime checksum in 0.24.x too... Thanks for the suggestion, though. Any other thoughts? -- Kind regards, Tim -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Error 400 on SERVER: private method `gsub' called for nil:NilClass
Thanks for the response. I did try putting in the subdirectory path as
well, but the same thing occurs. I continued to play around with it
and the error message disappears if I remove the recurse parameter.
The trace dump is below, but I can't find the problem from it (I don't
know ruby):
/usr/lib/ruby/1.8/webrick/httprequest.rb:342:in `parse_query'
/usr/lib/ruby/1.8/webrick/httprequest.rb:122:in `query'
/usr/lib/site_ruby/1.8/puppet/network/http/webrick/rest.rb:16:in
`params'
/usr/lib/site_ruby/1.8/puppet/network/http/handler.rb:64:in `process'
/usr/lib/site_ruby/1.8/puppet/network/http/webrick/rest.rb:23:in
`service'
/usr/lib/ruby/1.8/webrick/httpserver.rb:92:in `service'
/usr/lib/ruby/1.8/webrick/httpserver.rb:54:in `run'
/usr/lib/site_ruby/1.8/puppet/network/http/webrick.rb:45:in `listen'
/usr/lib/site_ruby/1.8/puppet/network/http/webrick.rb:42:in `call'
/usr/lib/ruby/1.8/webrick/server.rb:151:in `start_thread'
/usr/lib/ruby/1.8/webrick/server.rb:145:in `start'
/usr/lib/ruby/1.8/webrick/server.rb:145:in `start_thread'
/usr/lib/ruby/1.8/webrick/server.rb:95:in `start'
/usr/lib/ruby/1.8/webrick/server.rb:89:in `each'
/usr/lib/ruby/1.8/webrick/server.rb:89:in `start'
/usr/lib/ruby/1.8/webrick/server.rb:79:in `start'
/usr/lib/ruby/1.8/webrick/server.rb:79:in `start'
/usr/lib/site_ruby/1.8/puppet/network/http/webrick.rb:42:in `listen'
/usr/lib/site_ruby/1.8/puppet/network/http/webrick.rb:41:in
`initialize'
/usr/lib/site_ruby/1.8/puppet/network/http/webrick.rb:41:in `new'
/usr/lib/site_ruby/1.8/puppet/network/http/webrick.rb:41:in `listen'
/usr/lib/site_ruby/1.8/puppet/network/http/webrick.rb:38:in
`synchronize'
/usr/lib/site_ruby/1.8/puppet/network/http/webrick.rb:38:in `listen'
/usr/lib/site_ruby/1.8/puppet/network/server.rb:131:in `listen'
/usr/lib/site_ruby/1.8/puppet/network/server.rb:146:in `start'
/usr/lib/site_ruby/1.8/puppet/daemon.rb:128:in `start'
/usr/lib/site_ruby/1.8/puppet/application/puppetmasterd.rb:122:in
`main'
/usr/lib/site_ruby/1.8/puppet/application/puppetmasterd.rb:80:in
`main'
/usr/lib/site_ruby/1.8/puppet/application.rb:226:in `send'
/usr/lib/site_ruby/1.8/puppet/application.rb:226:in `run_command'
/usr/lib/site_ruby/1.8/puppet/application.rb:217:in `run'
/usr/lib/site_ruby/1.8/puppet/application.rb:217:in `exit_on_fail'
/usr/lib/site_ruby/1.8/puppet/application.rb:217:in `run'
/usr/sbin/puppetmasterd:66
err: private method `gsub' called for nil:NilClass
On Feb 8, 5:20 pm, Daniel dan...@linuxaddicted.de wrote:
You are missing the path to sync. The full path may be something like
puppet://$server/modules/dev_oracle_dev_tools/the_tools_folder
dev_oracle_dev_tools just identifies the module
On Mon, Feb 8, 2010 at 11:13 PM, eblack black.e...@gmail.com wrote:
Hi all,
I'm new to puppet and I can't seem to figure out how to get rid of
this error on the client or to get the recursive copy of files to the
client:
err: //dev_oracle_dev_tools::install/File[/tmp/oracle_dev_tools]:
Failed to generate additional resources using 'eval_generate': Error
400 on SERVER: private method `gsub' called for nil:NilClass
My module is called 'dev_oracle_dev_tools' and it is defined as:
class dev_oracle_dev_tools {
include dev_oracle_dev_tools::install
}
class dev_oracle_dev_tools::install {
file { /tmp/oracle_dev_tools:
recurse = true,
ensure = directory,
group = root,
owner = eblack,
mode = 750,
source = puppet://$server/modules/
dev_oracle_dev_tools,
}
}
And I call it like:
node file01.eblack.dev.gg.net {
include dev_oracle_dev_tools
}
All the other file parameters directives are followed on the client;
ie: directory is created if it doesn't exist and mode, group, owner
are set.
The error goes away if I comment out the 'source' parameter.
Hoping someone can help me because I've spent a couple hours on this
and I couldn't find any answers anywhere.
Thanks,
Eric
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/puppet-users?hl=en.
--
Cheers,
Daniel
--
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-dev] Re: [Puppet Users] Plugins in modules with environments and the puppetmaster libdir
On Mon, Feb 8, 2010 at 2:45 PM, Luke Kanies l...@reductivelabs.com wrote: On Feb 5, 2010, at 8:47 AM, Nigel Kersten wrote: On Fri, Feb 5, 2010 at 3:29 AM, Thomas Bellman bell...@nsc.liu.se wrote: Nigel Kersten wrote: So facter plugins are kind of different, as they're not actually required to be in the puppetmaster libdir. Say this was a type/provider, and you wanted to add a new parameter, but only roll it out to your testing environments. Functions also have this limitation, by the way. What do you do then? If the version in the puppetmaster libdir doesn't accept that parameter, the manifest compilation will fail for clients who *are* getting a version of the plugin that supports that parameter. You lose... Well, there are a couple of things you can do to work around this limitation. For one thing, you could run a second puppetmaster process, perhaps on another port, or listening on another IP address, or perhaps even on another machine. Another thing you can do, is to run puppet with local manifests, instead of puppetd connecting to puppetmasterd, when developing the new version of the plugin. That's what I do. It does get a bit iffy if your manifests want to fetch files from the puppetmaster (i.e. that aren't in the modules namespace) though, or otherwise need to access files that are only available on the puppetmaster. Good news, though, is that the upcoming Rowlf version of Puppet is supposed to solve this for at least resource types. At least Luke has posted patches to the devel list that I gather will do that. But it will probably still be a problem for custom functions (I have somewhat volunteered to take a look at it, but I'm unlikely to find the time before Rowlf is supposed to be out). + puppet-dev Luke, how is this going to be solved in practice? The puppetmasterd will automatically add modules/*/lib dirs to it's own libdir in the context/environment of the current client? Hmm, not quite true yet. At this point, rowlf has a bunch of refactoring around just the language stuff, not the pure-ruby stuff. We're on the path to converging the language resource types and the pure ruby Puppet::Type classes, but we're still a ways away. Part of that convergence will be fixing this problem, but I don't expect to see a real long-term fix until at least the release after rowlf - mostly just because we don't want to delay rowlf too much further. Can you give us an overview of the way this is intended to work? I'm thinking that in the meantime I may need to encode plugin versions in their names, so when a client's manifest contains a given plugin, it's always going to refer to that version, and I script something that collates all the lib/... directories into the puppetmasterd libdir. I feel dirty. Yeah, that's ugly. I think it'd be way easier to run environment-specific masters on a different port or server, wouldn't it? Not for the number of environments we have... BTW, if this is a big priority to someone, I think it's approachable today - far more than six months ago, with recent refactoring - and I'm happy to work with someone who's committed to getting it fixed. And I know this has been coming up a lot recently, so it's getting pushed up on my priority list. What would you need from those of us who are interested in working on this with you Luke? -- Men never do evil so completely and cheerfully as when they do it from a religious conviction. --Blaise Pascal - Luke Kanies -|- http://reductivelabs.com -|- +1(615)594-8199 -- You received this message because you are subscribed to the Google Groups Puppet Developers group. To post to this group, send email to puppet-...@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.compuppet-dev%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/puppet-dev?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] Re: Exec doesn't work with Ubuntu Server 10.04 (Lucid Lynx) 64bit
I could narrow down the problem : The exec call works in 2 CPU machine. It does not work in a single CPU machine. I can switch my VM from 2 to 1 CPU's and break puppet with this change. Here are the informations you requested : r...@puppet:/etc/puppet/manifests# ruby -v ruby 1.8.7 (2010-01-10 patchlevel 249) [x86_64-linux] r...@puppet:/etc/puppet/manifests# puppet -V 0.25.4 On 9 Feb., 14:14, James Turnbull ja...@lovedthanlost.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/02/10 12:06 AM, kai.steverding wrote: I installed ruby on the above server and tried with a simple exec- test : What Puppet and Ruby versions? Regards James Turnbull - -- Author of: * Pro Linux System Administration (http://tinyurl.com/linuxadmin) * Pulling Strings with Puppet (http://tinyurl.com/pupbook) * Pro Nagios 2.0 (http://tinyurl.com/pronagios) * Hardening Linux (http://tinyurl.com/hardeninglinux) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/ iQEVAwUBS3FfxCFa/lDkFHAyAQIdnwf9FVevibgcjvympW3YknpQQlIbgl9MPJIt LoB0JKwqFOs4LjXY+YdP8j3CyIMTtQUGHKTpz5OpPLCBUIUN3spaIfZ/jSfCvozE S20adBerNJKEtU7JMk1JGNCYVimOARJIWf31bpWnB9NiRuJltc7Cjcez/uJ0QpI7 VGYw3rkjwzZDpE7joajcwyalwaY8KkYprRXXGdQWcBfawyHlay0kj8WUNB4BSK/s 9I+RxoFtNehfF8yt+r4VkOpuGgYXnKKG+1lTmQQw/0W7WWOuKWkhYYM00wPU46DX ny3oGioYYIK5eH3YQYVBxVbvH/cD5bLQWgRQT94V2SQ1JkemQiJmPA== =aQtA -END PGP SIGNATURE- -- 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: Only send report email if resource failed during run
My tagmail.conf file looks like this: warning, err: someem...@example.com This only sends me email if warning or err events are seen. -Doug On 02/09/2010 08:52 AM, symfrog wrote: Maybe someone has created a simple custom report for this? On Feb 9, 3:03 pm, Ohad Levy ohadl...@gmail.com wrote: Hi, Latest version of foreman (http://theforeman.org) supports this feature. cheers, Ohad On Tue, Feb 9, 2010 at 9:00 PM, symfrog wpdut...@gmail.com wrote: Hi I have configured puppet to send reports via email using tagsmail. The problem is that it sends all the log messages every run (without a metric summary), which is not so useful. Is it possible to only send a report with the metrics only if one or more resources failed? 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.compuppet-users%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. signature.asc Description: OpenPGP digital signature
Re: [Puppet Users] Making the new users experience easier
I honestly think the most important thing for new users is to clean up the documentation. Not a lot of the existing docs on the wiki read as being particularly authoritative. They're full of lines like: Exporting and collecting resources is an extension of virtual resourceshttp://reductivelabs.com/trac/puppet/wiki/VirtualResources. Puppet provides an experimental superset of virtual resources, using a similar syntax. - are exported resources really experimental anymore? Something that has been noted in the past as being problematic was the fact that it's not always clear what version of puppet given functionality appeared in. This was a much bigger problem in the 0.24.x series where new features were being added, and the new approach to releases should make this easier, but it was definitely a problem in the past. I like having a community contributed wiki, but wikis are prone to producing documentation that isn't authoritative ( I managed to get foo to work by doing blah) without a clear sense of direction. On Sat, Feb 6, 2010 at 4:38 AM, Julian Simpson simpsonjul...@gmail.comwrote: Late to the party here. I thought Gepetto looked useful for new puppet users. Similar to the Chef Repository on GitHub that new Chef users are encouraged to clone: http://wiki.opscode.com/display/chef/Chef+Repository I have a hunch that the Chef users are more likely to be Ruby developers and hence be used to git. Gepetto will let the new user create a well-structured repository without needing to be a git/github user. J. On 6 February 2010 01:16, Michael DeHaan mich...@reductivelabs.com wrote: On Fri, Feb 5, 2010 at 2:38 PM, Patrick kc7...@gmail.com wrote: Great info everyone, thanks for all the feedback.Look for a lot of improvements, especially in the documentation/example space soon. --Michael -- 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.compuppet-users%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- Julian Simpson Software Build and Deployment http://www.build-doctor.com http://twitter.com/builddoctor -- 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.compuppet-users%2bunsubscr...@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: How to disable file checksums?
On Tue, Feb 9, 2010 at 6:30 AM, Tim Stoop tim.st...@gmail.com wrote: Hi Brice, Thanks for your suggestion, but alas, it seems to default to mtime 'checksum' then. On 8 feb, 22:43, Brice Figureau brice-pup...@daysofwonder.com wrote: In 0.24.x I know it was possible to: checksum = undef Honestly, knowing how other parts work, I'd expect it to default to mtime checksum in 0.24.x too... Thanks for the suggestion, though. Any other thoughts? If you don't specify source or content, then it should just touch the file. I am still missing the exact use case for this though. -- Kind regards, Tim -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.compuppet-users%2bunsubscr...@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] Living with Puppet...
I've written an application, which aims to solve all of the missing peaces around puppet - http://theforeman.org Ohad, as you've said I've written an application, which aims to solve all of the missing peaces around puppet. Obviously you've done a lot of work here, but I need to communicate something from a community perspective -- the proper place to fix missing pieces in Puppet is by contributing to Puppet -- our vision is to have no such missing pieces. Hence things done outside of core tend to fragment the userbase and make things harder to install/use/manage/maintain. The future of this workflow tool is going to be Puppet's Dashboard. Where there are barriers to doing this, we will remove them. If folks have feature requests, please send them along, and let's work on making Puppet core (and dashboard) strong so there are less external dependencies to manage -- so they can install all easily in the box, that we have linked bug tracking, linked releases, and a united community. That's one of my goals over the coming year -- to make Puppet even easier to contribute to, and make it clear to folks how they may do so. External integrations are of course very important to us -- but the out of the box Puppet experience will be as complete as we can make it rather than fragmenting workarounds between various external tools. --Michael -- 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] Living with Puppet...
hello, - Michael DeHaan mich...@reductivelabs.com wrote: I've written an application, which aims to solve all of the missing peaces around puppet - http://theforeman.org Ohad, as you've said I've written an application, which aims to solve all of the missing peaces around puppet. Obviously you've done a lot of work here, but I need to communicate something from a community perspective -- the proper place to fix missing pieces in Puppet is by contributing to Puppet -- our vision is to have no such missing pieces. Hence things done outside of core tend to fragment the userbase and make things harder to install/use/manage/maintain. The future of this workflow tool is going to be Puppet's Dashboard. Where there are barriers to doing this, we will remove them. As a non affiliated community member who spend a lot of my time on Puppet I think this is a particularly unfriendly and in fact alarming statement for someone from RL to make. -- 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] Living with Puppet...
On Tue, Feb 9, 2010 at 9:39 AM, R.I.Pienaar r...@devco.net wrote: hello, - Michael DeHaan mich...@reductivelabs.com wrote: I've written an application, which aims to solve all of the missing peaces around puppet - http://theforeman.org Ohad, as you've said I've written an application, which aims to solve all of the missing peaces around puppet. Obviously you've done a lot of work here, but I need to communicate something from a community perspective -- the proper place to fix missing pieces in Puppet is by contributing to Puppet -- our vision is to have no such missing pieces. Hence things done outside of core tend to fragment the userbase and make things harder to install/use/manage/maintain. The future of this workflow tool is going to be Puppet's Dashboard. Where there are barriers to doing this, we will remove them. As a non affiliated community member who spend a lot of my time on Puppet I think this is a particularly unfriendly and in fact alarming statement for someone from RL to make. It also goes against what I saw as a rather wonderful development at Puppet Camp this year, namely puppet evolving to become a viable component of in-house software stacks. I understand the situation with Foreman and Puppet Dashboard is a little complicated, but it's a good thing to have competition in the Puppet ecosystem. I'm not sure you communicated this from a community perspective at all Michael. -- 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] Living with Puppet...
On 9 February 2010 17:39, R.I.Pienaar r...@devco.net wrote: hello, - Michael DeHaan mich...@reductivelabs.com wrote: I've written an application, which aims to solve all of the missing peaces around puppet - http://theforeman.org Ohad, as you've said I've written an application, which aims to solve all of the missing peaces around puppet. Obviously you've done a lot of work here, but I need to communicate something from a community perspective -- the proper place to fix missing pieces in Puppet is by contributing to Puppet -- our vision is to have no such missing pieces. Hence things done outside of core tend to fragment the userbase and make things harder to install/use/manage/maintain. The future of this workflow tool is going to be Puppet's Dashboard. Where there are barriers to doing this, we will remove them. As a non affiliated community member who spend a lot of my time on Puppet I think this is a particularly unfriendly and in fact alarming statement for someone from RL to make. I agree, I'm sure Michael didn't mean to be offensive hear, but it comes off as arrogant. The community exists around puppet and there should be room for innovation within it. We want to encourage tool writing systems administration, not a centralized single company based environment. Obviously Reductive needs to make money and keep going but dismissing the work of active and contributing members of the community and stating it's from a community perspective feels disingenuous. I personally don't think it's a good statement of the community perspective. Paul -- 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] Living with Puppet...
On Tue, Feb 9, 2010 at 12:39 PM, R.I.Pienaar r...@devco.net wrote: hello, - Michael DeHaan mich...@reductivelabs.com wrote: I've written an application, which aims to solve all of the missing peaces around puppet - http://theforeman.org Ohad, as you've said I've written an application, which aims to solve all of the missing peaces around puppet. Obviously you've done a lot of work here, but I need to communicate something from a community perspective -- the proper place to fix missing pieces in Puppet is by contributing to Puppet -- our vision is to have no such missing pieces. Hence things done outside of core tend to fragment the userbase and make things harder to install/use/manage/maintain. The future of this workflow tool is going to be Puppet's Dashboard. Where there are barriers to doing this, we will remove them. As a non affiliated community member who spend a lot of my time on Puppet I think this is a particularly unfriendly and in fact alarming statement for someone from RL to make. Not in the least; we welcome all contributions... and we want to encourage folks here to contribute to the core. The statement this is broken, go use my tool is less interesting than let's all come together and work and build better software. This is how OSS really works best ... joining together as one. If you take a look at my experience with Cobbler and Func, enabling external integration (see OpenSymbolic for a fine example) was something I am very much in favor of doing. However, I'm also very much interested in raising contributions to Puppet proper -- which we can do much better at. We do that by encouraging everyone to work together. We don't do this by saying Puppet is broke, go use this... that is a mindset we need to shift. This is where OSS really shines. Right now we have about 80 or so committers to the core.For a project of this size, I'd like it to be much larger. This is one of the things we want to enable. We also want to make it clear that Dashboard is our future, and we welcome contributions there and will be better positioned to help keep that and Puppet working better in sync. --Michael -- 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] Living with Puppet...
hello, Not in the least; we welcome all contributions... and we want to encourage folks here to contribute to the core. . . We also want to make it clear that Dashboard is our future, and we welcome contributions there and will be better positioned to help keep that and Puppet working better in sync. I think you're in desperate need of a history lesson in what happened in the cases where people tried to contribute or suggest improvements wrt dashboard. -- R.I.Pienaar -- 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] Living with Puppet...
On Tue, Feb 9, 2010 at 12:47 PM, Paul Nasrat pnas...@googlemail.com wrote: On 9 February 2010 17:39, R.I.Pienaar r...@devco.net wrote: hello, - Michael DeHaan mich...@reductivelabs.com wrote: I've written an application, which aims to solve all of the missing peaces around puppet - http://theforeman.org Ohad, as you've said I've written an application, which aims to solve all of the missing peaces around puppet. Obviously you've done a lot of work here, but I need to communicate something from a community perspective -- the proper place to fix missing pieces in Puppet is by contributing to Puppet -- our vision is to have no such missing pieces. Hence things done outside of core tend to fragment the userbase and make things harder to install/use/manage/maintain. The future of this workflow tool is going to be Puppet's Dashboard. Where there are barriers to doing this, we will remove them. As a non affiliated community member who spend a lot of my time on Puppet I think this is a particularly unfriendly and in fact alarming statement for someone from RL to make. I agree, I'm sure Michael didn't mean to be offensive hear, but it comes off as arrogant. The community exists around puppet and there should be room for innovation within it. We want to encourage tool writing systems administration, not a centralized single company based environment. Obviously Reductive needs to make money and keep going but dismissing the work of active and contributing members of the community and stating it's from a community perspective feels disingenuous. I personally don't think it's a good statement of the community perspective. Paul Paul -- I'm as community oriented as you'll get. Moving forward, our efforts should be in contributing around one common tool that everyone in our community can contribute to. Unfortunately due to some IP issues we can't do this around Foreman -- and /we/ can't contribute to it. Similarly, since we are looking at doing some very powerful and tightly coupled features in Dashboard, it is non-strategic to be avertising that users should be investing in Foreman. Features that go into Foreman are lost to Puppet... Rather than look at this as dismissive, I think we need to look at this as a chance to rally our efforts. Ohad is enormously helpful here and I don't want to take away from his contributions. ---Michael -- 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] Living with Puppet...
I think you're in desperate need of a history lesson in what happened in the cases where people tried to contribute or suggest improvements wrt dashboard. If there is such a percieved lack of interest, this is something I would like to rectify. (Also don't miscontrue an inability to implement RFEs with a lack of interest... the phrase patches accepted is often thrown around but exists for a reason, right?) That all being said, the past is just that. A seperate list for dashboard discussion and development probably makes sense so we can get this going in higher gear. While it mainly serves external nodes now, there are a lot of interesting places it can go -- and we would definitely like everyone's ideas on that. --Michael -- 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] Living with Puppet...
On 9 February 2010 17:53, Michael DeHaan mich...@reductivelabs.com wrote: On Tue, Feb 9, 2010 at 12:47 PM, Paul Nasrat pnas...@googlemail.com wrote: On 9 February 2010 17:39, R.I.Pienaar r...@devco.net wrote: hello, - Michael DeHaan mich...@reductivelabs.com wrote: I've written an application, which aims to solve all of the missing peaces around puppet - http://theforeman.org Ohad, as you've said I've written an application, which aims to solve all of the missing peaces around puppet. Obviously you've done a lot of work here, but I need to communicate something from a community perspective -- the proper place to fix missing pieces in Puppet is by contributing to Puppet -- our vision is to have no such missing pieces. Hence things done outside of core tend to fragment the userbase and make things harder to install/use/manage/maintain. The future of this workflow tool is going to be Puppet's Dashboard. Where there are barriers to doing this, we will remove them. As a non affiliated community member who spend a lot of my time on Puppet I think this is a particularly unfriendly and in fact alarming statement for someone from RL to make. I agree, I'm sure Michael didn't mean to be offensive hear, but it comes off as arrogant. The community exists around puppet and there should be room for innovation within it. We want to encourage tool writing systems administration, not a centralized single company based environment. Obviously Reductive needs to make money and keep going but dismissing the work of active and contributing members of the community and stating it's from a community perspective feels disingenuous. I personally don't think it's a good statement of the community perspective. Paul Paul -- I'm as community oriented as you'll get. Show don't tell, I'm aware of your work on other projects. But being part of the community around puppet is earned not transitioned with a role. Whilst I think you're background and skills make you Moving forward, our efforts should be in contributing around one common tool that everyone in our community can contribute to. So you don't believe an ecosystem of tools can exist around puppet and facter? You believe that one solution fits all? This really is coming across in a light I don't think you intend. Unfortunately due to some IP issues we can't do this around Foreman -- and /we/ can't contribute to it. I'm aware of that. What I'm objecting to is a myopic vision that there can't be an ecosystem. Paul -- 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] Living with Puppet...
On Tue, Feb 9, 2010 at 1:04 PM, Paul Nasrat pnas...@googlemail.com wrote: On 9 February 2010 17:53, Michael DeHaan mich...@reductivelabs.com wrote: On Tue, Feb 9, 2010 at 12:47 PM, Paul Nasrat pnas...@googlemail.com wrote: On 9 February 2010 17:39, R.I.Pienaar r...@devco.net wrote: hello, - Michael DeHaan mich...@reductivelabs.com wrote: I've written an application, which aims to solve all of the missing peaces around puppet - http://theforeman.org Ohad, as you've said I've written an application, which aims to solve all of the missing peaces around puppet. Obviously you've done a lot of work here, but I need to communicate something from a community perspective -- the proper place to fix missing pieces in Puppet is by contributing to Puppet -- our vision is to have no such missing pieces. Hence things done outside of core tend to fragment the userbase and make things harder to install/use/manage/maintain. The future of this workflow tool is going to be Puppet's Dashboard. Where there are barriers to doing this, we will remove them. As a non affiliated community member who spend a lot of my time on Puppet I think this is a particularly unfriendly and in fact alarming statement for someone from RL to make. I agree, I'm sure Michael didn't mean to be offensive hear, but it comes off as arrogant. The community exists around puppet and there should be room for innovation within it. We want to encourage tool writing systems administration, not a centralized single company based environment. Obviously Reductive needs to make money and keep going but dismissing the work of active and contributing members of the community and stating it's from a community perspective feels disingenuous. I personally don't think it's a good statement of the community perspective. Paul Paul -- I'm as community oriented as you'll get. Show don't tell, I'm aware of your work on other projects. But being part of the community around puppet is earned not transitioned with a role. Whilst I think you're background and skills make you Moving forward, our efforts should be in contributing around one common tool that everyone in our community can contribute to. So you don't believe an ecosystem of tools can exist around puppet and facter? You believe that one solution fits all? This really is coming across in a light I don't think you intend. Sounds like it. So imagine my intent. Unfortunately due to some IP issues we can't do this around Foreman -- and /we/ can't contribute to it. I'm aware of that. What I'm objecting to is a myopic vision that there can't be an ecosystem. Paul There can and must be an ecosystem. We want to encourage as many integration points and projects as possible. -- 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: error on puppet 25.4 with passenger 2.2.2
Aha! Fixes my problem too. I knew if I procrastinated enough someone
would find an answer. :-)
On Tue, Feb 9, 2010 at 2:54 AM, Christophe Bonnaud takyo...@hotmail.com wrote:
On Feb 9, 9:50 am, Eric Sorenson ahp...@gmail.com wrote:
On Feb 8, 2010, at 4:20 PM, Christophe Bonnaud wrote:
I've seen the same thing with my setup...the solution for me was to
put the RequestHeader lines found on the Puppet Passenger wiki page
(http://www.reductivelabs.com/trac/puppet/wiki/UsingPassenger) into my
Apache virtual host config:
RequestHeader set X-SSL-Subject %{SSL_CLIENT_S_DN}e
RequestHeader set X-Client-DN %{SSL_CLIENT_S_DN}e
RequestHeader set X-Client-Verify %{SSL_CLIENT_VERIFY}e
...not sure why that section isn't included in the provided template
(./ext/rack/files/apache2.conf) from the puppet sources (I'm using
v0.25.4), but adding them fixed things up for me. Note that I also
don't have an auth.conf file, and even if I add one and take these
lines out, I'm back to getting the err: Could not retrieve catalog
from remote server: Error 403 on SERVER: message. Hope that helps!
Indeed this was the solution... thanks so much for your help!!
I'm agree it's strange that those lines are not in the provided
template...
Anyone know why?
The documented suggestion -- though I agree it's not on the wiki page; once
we resolve this question here I'd be happy to update UsingPassenger this as
I've just gone through it myself -- is to go at it from the other direction.
Instead of changing apache to match puppet's defaults, you tell puppet the
names of the apache variables:
(from ext/rack/README)
Required puppet.conf settings:
[puppetmasterd]
ssl_client_header = SSL_CLIENT_S_DN
ssl_client_verify_header = SSL_CLIENT_VERIFY
Then the required httpd.conf line is just
SSLOptions +StdEnvVars
which *is* in the config file in the distribution.
I'm not enough of an expert to know whether one is preferable to the other,
though.
-=Eric
hum yes indeed it works fine in that way too. I though I already tried
that because I saw that in the documentation but I may have done
something else wrong at this moment...
Thanks Eric!
--
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] Making the new users experience easier
On Tue, Feb 9, 2010 at 11:15 AM, Nigel Kersten nig...@google.com wrote: I honestly think the most important thing for new users is to clean up the documentation. Not a lot of the existing docs on the wiki read as being particularly authoritative. They're full of lines like: Exporting and collecting resources is an extension of virtual resources. Puppet provides an experimental superset of virtual resources, using a similar syntax. - are exported resources really experimental anymore? Something that has been noted in the past as being problematic was the fact that it's not always clear what version of puppet given functionality appeared in. This was a much bigger problem in the 0.24.x series where new features were being added, and the new approach to releases should make this easier, but it was definitely a problem in the past. I like having a community contributed wiki, but wikis are prone to producing documentation that isn't authoritative ( I managed to get foo to work by doing blah) without a clear sense of direction. Yeah, I like Wiki's too... I think there's a bit of best practices kind of stuff we'll want as well, in those docs, so we don't lead people too far astray and get them frustrated. So we'll still have a Wiki for those things, because that's really great info to capture as well.Gotta have that. I believe the docs are all in SVN now, and I realize the idea of submitting a bug to change a page is suboptimal, though you can check them all out in github. Patches and help reviewing would be *VERY* welcome. If anyone wants to just send me email about portions that suck (in the static docs), let me know, and I'll get those cleaned up. --Michael -- 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] Living with Puppet...
R.I.Pienaar wrote: hello, - Michael DeHaan mich...@reductivelabs.com wrote: I've written an application, which aims to solve all of the missing peaces around puppet - http://theforeman.org Ohad, as you've said I've written an application, which aims to solve all of the missing peaces around puppet. Obviously you've done a lot of work here, but I need to communicate something from a community perspective -- the proper place to fix missing pieces in Puppet is by contributing to Puppet -- our vision is to have no such missing pieces. Hence things done outside of core tend to fragment the userbase and make things harder to install/use/manage/maintain. The future of this workflow tool is going to be Puppet's Dashboard. Where there are barriers to doing this, we will remove them. As a non affiliated community member who spend a lot of my time on Puppet I think this is a particularly unfriendly and in fact alarming statement for someone from RL to make. Though I have nowhere near the contributor-status that Nigel or R.I have, I basically agree with Michael here. Foreman is a great tool in wide-use as I understand it, but I'm not sure the best action for the future of both Foreman AND puppet is to continue development on two separate tracks. This could have possibly been better elucidated by Michael, but I don't think many of us are experts in communications. Let's not forget that Luke's original vision was to create a tool to bring us all together (hopefully that didn't sound too hippie like) because there was such a huge amount of fragmentation in the infrastructure management community. -- Joe McDonagh AIM: YoosingYoonickz IRC: joe-mac on freenode L'ennui est contre-révolutionnaire -- 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: How to disable file checksums?
Hi Dan,
On 9 feb, 17:40, Dan Bode d...@reductivelabs.com wrote:
I am still missing the exact use case for this though.
I made a ticket out of it, #3170. If I have something like:
file { /tmp: mode = 1777 }
Every puppetd run gives me something like:
notice: //kbp_debian/File[/tmp]/checksum: checksum changed '{mtime}Mon
Feb 08 22:50:00 +0100 2010' to '{mtime}Tue Feb 09 21:11:06 +0100 2010'
If you have this for a lot of resources, it kind of clutters :) Since
I do not need checksumming for these resources, it would be nice if I
could simply disable checksumming.
--
Kind regards,
Tim
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Living with Puppet...
On Tue, Feb 9, 2010 at 12:39 PM, R.I.Pienaar r...@devco.net wrote: hello, - Michael DeHaan mich...@reductivelabs.com wrote: Ohad, as you've said I've written an application, which aims to solve all of the missing peaces around puppet. Obviously you've done a lot of work here, but I need to communicate something from a community perspective -- the proper place to fix missing pieces in Puppet is by contributing to Puppet -- our vision is to have no such missing pieces. Hence things done outside of core tend to fragment the userbase and make things harder to install/use/manage/maintain. The future of this workflow tool is going to be Puppet's Dashboard. Where there are barriers to doing this, we will remove them. As a non affiliated community member who spend a lot of my time on Puppet I think this is a particularly unfriendly and in fact alarming statement for someone from RL to make. Soliciting contributions of code for improvements to an open source project isn't what I'd classify as unfriendly and I'd expect RL people to take a leadership role when it comes to maintaining a solid foundation for the project. It is very difficult to infer tone from a mailing list posting, perhaps you've misread here? Or maybe I am but I'm willing to give Michael the benefit of the doubt. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet and Drupal
On Mon, Feb 08, 2010 at 03:35:18PM +, John Arundel wrote:
Hi,
Unlike a lot of CMSes out there, Drupal has an excellent automation
tool in the form of Drush. With a bit of Puppet magic, you can
automate most of the common tasks and components in building a Drupal
site (or managing a multisite install). I've written up some example
recipes which I use for managing a bunch of Drupal installs:
http://bitfieldconsulting.com/puppet-drupal
Is anyone else managing Drupal with Puppet? Have you done things
differently, or do you have extra things which I've missed out? Is
there a better way to do the stuff that I've shown in the article? I'd
love to get some feedback. In particular I'd like to hear about
staging and deployment issues with Drupal.
One interesting thing that already came up in comments is embedding
secrets into Puppet code, which was discussed here recently. I think
that would be my first thing to improve.
Hi John,
We actually just finished a bunch of recipes to deploy Drupal using Puppet, but
we didn't know about Drush, which would have saved me a lot of work :-)
But I really like your post, it's going to help us a bit when we revisit this.
We mostly did the same thing you did, except that we wrote our own substitute
for Drush.
One thing we did which we like is that we set up a git repository for our
themes. The theme designer can check into the development or production
branches of that repo, and the appropriate server will pull down the changes.
With the existence of Drush, I think the next step would be to actually roll
that into a package provider so you could write:
package { content:
ensure = present,
provider = drupal-module,
target = /etc/drupal/6/sites/all
}
or the like.
Cheers,
--
Eric Gerlach, Network Administrator
Federation of Students
University of Waterloo
p: (519) 888-4567 x36329
e: egerl...@feds.uwaterloo.ca
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet and Drupal
On Tue, Feb 9, 2010 at 7:58 PM, Eric Gerlach egerl...@feds.uwaterloo.ca wrote:
One thing we did which we like is that we set up a git repository for our
themes. The theme designer can check into the development or production
branches of that repo, and the appropriate server will pull down the changes.
Coincidence - I've done the same thing (but each site is its own Git
repo, including themes, images and so on).
This way I can check out and edit CSS code in Textmate and then commit
it back and push to the server.
With the existence of Drush, I think the next step would be to actually roll
that into a package provider so you could write:
package { content:
ensure = present,
provider = drupal-module,
target = /etc/drupal/6/sites/all
}
That sounds like a great idea - I haven't yet taken the step of having
Puppet actually deploy the content to the site.
Regards,
J
--
Bitfield Consulting: we make software that makes things work
http://bitfieldconsulting.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] Making the new users experience easier
On Feb 9, 2010, at 10:40 AM, Michael DeHaan mich...@reductivelabs.com wrote: On Tue, Feb 9, 2010 at 11:15 AM, Nigel Kersten nig...@google.com wrote: I honestly think the most important thing for new users is to clean up the documentation. Not a lot of the existing docs on the wiki read as being particularly authoritative. They're full of lines like: Exporting and collecting resources is an extension of virtual resources. Puppet provides an experimental superset of virtual resources, using a similar syntax. - are exported resources really experimental anymore? Something that has been noted in the past as being problematic was the fact that it's not always clear what version of puppet given functionality appeared in. This was a much bigger problem in the 0.24.x series where new features were being added, and the new approach to releases should make this easier, but it was definitely a problem in the past. I like having a community contributed wiki, but wikis are prone to producing documentation that isn't authoritative ( I managed to get foo to work by doing blah) without a clear sense of direction. Yeah, I like Wiki's too... I think there's a bit of best practices kind of stuff we'll want as well, in those docs, so we don't lead people too far astray and get them frustrated. So we'll still have a Wiki for those things, because that's really great info to capture as well.Gotta have that. I believe the docs are all in SVN now, and I realize the idea of submitting a bug to change a page is suboptimal, though you can check them all out in github. Patches and help reviewing would be *VERY* welcome. I think patches tickets are probably the best way to manage community contributions to the curated docs, which need to be kept to a much higher standard of quality than the wild west of wiki docs. If anyone wants to just send me email about portions that suck (in the static docs), let me know, and I'll get those cleaned up. This sounds great, but please keep feedback going through tickets. Bruce --Michael -- 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] Making the new users experience easier
This sounds great, but please keep feedback going through tickets. Totally, I'll file tickets for any comments we recieve.There's sometimes a bit of a barrier to people opening a ticket (might not have an account, etc). Obviously if folks can file tickets directly that's better :) --Michael -- 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] Making the new users experience easier
While getting started I had some problems. 1) I couldn't find a simple skeleton puppet configuration. I tried the tutorial, but there's lots of things that can go wrong, and figuring out what's wrong can be be a pain if you don't know what you're doing. A sample.tar.gz that has a module that does nothing but create a file in /tmp would be really helpful. Just getting a configuration that works and does something can be rather hard. gepetto has some good ideas here. I think the module library (puppet common modules) will help too. ... snip (good comments) ... 5) Error ambiguity: sometimes it's hard to tell if an error is happening on the client-side or server-side. -Patrick One idea I had here is just prefixing the errors with [Client] or [Server] ... though that could be a little verbose. Any better ideas on how we might handle this? I am thinking we need to use more magenta and orange :) /kidding -- 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] Making the new users experience easier
On Fri, Feb 5, 2010 at 4:53 AM, Dick Davies rasput...@hellooperator.net wrote: On Tue, Feb 2, 2010 at 5:08 PM, Michael DeHaan mich...@reductivelabs.com wrote: With Puppet, if you're just learning it, what were some of your stumbling blocks? If you are an existing user, think back to that time, or times when you were talking with new users? #1 has to be variable scope and the inability to redefine variables. That and the knock on impact on things like inheritance, and the need for storeconfigs to 'know about' the variables of another node. Lexical scope is in work here, so that should help immensely. #2 is the difficulty to test manifests reliably (the reliance on Facts makes it tricky to even syntax check recipes without actually running it on a node). Makes #1 more of an issue. I keep getting bitten by interactions between modules, so it needs to be some sort of integration test. #3 is a best practice guide - e.g. is it best to have a separate class heirarchy per OS / role, or fill your modules with case statements? Very much so. We are totally doing this. The common modules pool will also enforce those best practices so we can have examples. Definitely looking to all of you to help define and evolve what these best practices are along with things that Teyo has picked up, among others. -- 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] Living with Puppet...
On Feb 9, 2010, at 9:25 AM, Michael DeHaan wrote: I've written an application, which aims to solve all of the missing peaces around puppet - http://theforeman.org Ohad, as you've said I've written an application, which aims to solve all of the missing peaces around puppet. Obviously you've done a lot of work here, but I need to communicate something from a community perspective -- the proper place to fix missing pieces in Puppet is by contributing to Puppet -- our vision is to have no such missing pieces. Hence things done outside of core tend to fragment the userbase and make things harder to install/use/manage/maintain. The future of this workflow tool is going to be Puppet's Dashboard. Where there are barriers to doing this, we will remove them. If folks have feature requests, please send them along, and let's work on making Puppet core (and dashboard) strong so there are less external dependencies to manage -- so they can install all easily in the box, that we have linked bug tracking, linked releases, and a united community. Just to clarify this a bit: Puppet never has been and never will be a complete solution, and it will always require other tools. There are areas that Puppet should do but doesn't, and we intend to expand it in those areas, but in general, our goal is to make Puppet a focused tool with a specific purview. I don't believe there can ever be a single tool that fills all of the gaps, but clearly at least one person disagrees. When it comes to those other tools, some of them are things that we've been promising to implement for ages, and now that we have the resources we're finally working on them. You can go back to 2006 and find threads, started by me, about creating external node tools (e.g., nodify), and I added general support for them so anyone could create and use one. However, I always maintained that I'd be building one at the company, and I've discussed the conceptual tools with lots of people, including Ohad, individually. Probably my biggest disappointment in the last few years is that I didn't have the bandwidth to develop the tools around Puppet that I wanted to create and discussed at such length, such as a node tool (of which there are many, including iClassify (abandoned), Foreman, and our Dashboard) and a message bus (of which mcollective is a good example). Even in discussing those, I always wanted our tools to stand on their own. If our node tool isn't the best node tool for you, then don't use it - find something better, and we'll try to catch you on the next upgrade. If Puppet isn't the best config mgmt tool but our node tool is, then hey, that's great, too. So, having tools like Foreman is great, especially since Ohad is spending so much time maintaining it, and his development mentality really gels well with a lot of other sysadmins. However, it's quite a stretch to say that any tool solves all of the missing pieces around Puppet. There are lots of things I want our dashboard to do that neither it nor Foreman does, and there are things Foreman does that I wouldn't recommend to my customers. Foreman is a great tool for some set of people, and it's a great example of the power of an open ecosystem. I *never* want to shut that ecosystem down, and in fact, we're moving as quickly and thoroughly as possible to a *more* open ecosystem. As Michael said, there are also IP issues with our relying on Foreman. There is a significant difference between a lone developer producing an open source project and a commercial enterprise making promises to customers about a project. One of the big drivers for my creation of Puppet is that I found I couldn't keep promises I made to customers because my goals didn't mesh with the goals of Cfengine's maintainer. Since the day I started Puppet, I have had a commercial company backing it and funding its development. It's been my full time job since March of 2005, and one of my prerequisites for it has always been that I be able to make and keep promises to customers. The problem with Foreman, for us, is that its IP is in a sufficient state for Ohad's purposes but not for ours. That doesn't by any means invalidate Ohad's effort, it just means that we can't build a business on it. We're planning on producing commercial extensions to our Dashboard, which requires very clear IP control, at least for GPL'd software, but more importantly for me, I don't think it's a wise business decision for my company to base its future plans on a tool that someone else controls. Beyond the IP issues, though, there are just plain differences in what we want to build. It's quite possible that Ohad's vision of what this tool should look like is more correct than my own, but I'm here to build my own vision. I have a clear idea of what our dashboard should look like, and that's what I intend to build, because I
Re: [Puppet Users] Making the new users experience easier
On Feb 9, 2010, at 2:28 PM, Michael DeHaan mich...@reductivelabs.com wrote: This sounds great, but please keep feedback going through tickets. Totally, I'll file tickets for any comments we recieve.There's sometimes a bit of a barrier to people opening a ticket (might not have an account, etc). Obviously if folks can file tickets directly that's better :) Agreed; there's also the Feedback tab directly from the docs site, using GetSatisfaction; a little less formal than Redmine tickets, at least. The more communication paths the merrier, provided there's a canonical backlog. Cheers, Bruce -- Bruce Williams http://reductivelabs.com --Michael -- 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-dev] Re: [Puppet Users] Plugins in modules with environments and the puppetmaster libdir
On Feb 9, 2010, at 6:55 AM, Nigel Kersten wrote: On Mon, Feb 8, 2010 at 2:45 PM, Luke Kanies l...@reductivelabs.com wrote: On Feb 5, 2010, at 8:47 AM, Nigel Kersten wrote: On Fri, Feb 5, 2010 at 3:29 AM, Thomas Bellman bell...@nsc.liu.se wrote: Nigel Kersten wrote: So facter plugins are kind of different, as they're not actually required to be in the puppetmaster libdir. Say this was a type/provider, and you wanted to add a new parameter, but only roll it out to your testing environments. Functions also have this limitation, by the way. What do you do then? If the version in the puppetmaster libdir doesn't accept that parameter, the manifest compilation will fail for clients who *are* getting a version of the plugin that supports that parameter. You lose... Well, there are a couple of things you can do to work around this limitation. For one thing, you could run a second puppetmaster process, perhaps on another port, or listening on another IP address, or perhaps even on another machine. Another thing you can do, is to run puppet with local manifests, instead of puppetd connecting to puppetmasterd, when developing the new version of the plugin. That's what I do. It does get a bit iffy if your manifests want to fetch files from the puppetmaster (i.e. that aren't in the modules namespace) though, or otherwise need to access files that are only available on the puppetmaster. Good news, though, is that the upcoming Rowlf version of Puppet is supposed to solve this for at least resource types. At least Luke has posted patches to the devel list that I gather will do that. But it will probably still be a problem for custom functions (I have somewhat volunteered to take a look at it, but I'm unlikely to find the time before Rowlf is supposed to be out). + puppet-dev Luke, how is this going to be solved in practice? The puppetmasterd will automatically add modules/*/lib dirs to it's own libdir in the context/environment of the current client? Hmm, not quite true yet. At this point, rowlf has a bunch of refactoring around just the language stuff, not the pure-ruby stuff. We're on the path to converging the language resource types and the pure ruby Puppet::Type classes, but we're still a ways away. Part of that convergence will be fixing this problem, but I don't expect to see a real long-term fix until at least the release after rowlf - mostly just because we don't want to delay rowlf too much further. Can you give us an overview of the way this is intended to work? Not sure exactly how to answer this question, since there's a lot there. The convergence of the two classes (Puppet::Type and Puppet::Resource::Type) is complex to describe. Basically, current resource types are subclasses of Puppet::Type, and resources are instances of those subclasses. We'll be changing things so that resource types are instances of Puppet::Resource::Type, and resources are instances of Puppet::Resource. In terms of observable differences, other than the constants involved there won't really be any - it'll just make contribution, maintenance, and custom development much easier. However, it'll also enable us to do a lot of things we currently can't, like maintain non-global (i.e., environment-specific) resource types. The refactoring I did to enable the pure-ruby DSL was the main step toward this: When you use 'define' in the language, you're creating an environment-specific resource type, it's just not as functional as a builtin resource type. I think the next major release will normalize the functionality between the two, and hopefully also make it possible to use existing providers with new-style resource types. Then it's just a question of porting over the existing types to use the new class structure. I'm thinking that in the meantime I may need to encode plugin versions in their names, so when a client's manifest contains a given plugin, it's always going to refer to that version, and I script something that collates all the lib/... directories into the puppetmasterd libdir. I feel dirty. Yeah, that's ugly. I think it'd be way easier to run environment- specific masters on a different port or server, wouldn't it? Not for the number of environments we have... Ah. BTW, if this is a big priority to someone, I think it's approachable today - far more than six months ago, with recent refactoring - and I'm happy to work with someone who's committed to getting it fixed. And I know this has been coming up a lot recently, so it's getting pushed up on my priority list. What would you need from those of us who are interested in working on this with you Luke? Code? :) -- Finn's Law: Uncertainty is the final test of innovation. - Luke Kanies -|- http://reductivelabs.com -|- +1(615)594-8199 -- You received this message because you are
Re: [Puppet Users] Only send report email if resource failed during run
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ohad Levy wrote: Hi, Latest version of foreman (http://theforeman.org) supports this feature. cheers, Ohad On Tue, Feb 9, 2010 at 9:00 PM, symfrog wpdut...@gmail.com wrote: Hi I have configured puppet to send reports via email using tagsmail. The problem is that it sends all the log messages every run (without a metric summary), which is not so useful. Is it possible to only send a report with the metrics only if one or more resources failed? 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.compuppet-users%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. Puppet has supported an 'err' tag since like .24.6, however if your distro comes with something old, you may not have success trying to use this. - -- Joe McDonagh AIM: YoosingYoonickz IRC: joe-mac on freenode L'ennui est contre-révolutionnaire -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEUEARECAAYFAktyBF8ACgkQRkBieEaRmuY36ACeNRfJiTCyM4GNAyrbgQmUYLET yMMAlRPRBoCknJyi3rUxRJKomC4ghVE= =is5Z -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Puppet 0.25.4 and Facter 1.5.7 debs available in debian unstable.
packages.debian.org is lagging in terms of what it's showing, but
$ rmadison -u debian {puppet,facter} | grep unstable
puppet | 0.25.4-1 | unstable | source, all
facter |1.5.7-1 | unstable | source, all
they're both up there now.
--
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] Puppet 0.25.4 and Facter 1.5.7 debs available in debian unstable.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nigel Kersten wrote:
packages.debian.org is lagging in terms of what it's showing, but
$ rmadison -u debian {puppet,facter} | grep unstable
puppet | 0.25.4-1 | unstable | source, all
facter |1.5.7-1 | unstable | source, all
they're both up there now.
--
nigel
What is rmadison???
- --
Joe McDonagh
AIM: YoosingYoonickz
IRC: joe-mac on freenode
L'ennui est contre-révolutionnaire
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAktyBNsACgkQRkBieEaRmuZ+oACeLL1MQaet6adDl3PBXtusGvVV
dPMAn3tPsihxfyB/lRrsXicu5Hh/PXs3
=cv6U
-END PGP SIGNATURE-
--
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] dashboard, foreman etc (was: Living with Puppet...)
Hi All, I'm sorry if I offended anyone by saying that Foreman solves all of puppet problems, I mainly meant that there are areas which puppet simply doesn't deal with, but we as sysadmins need to. My goal with Foreman is to make our life easier, Foreman would be extremely difficult to made if Puppet was not around, and I'm grateful for puppet and RL. As far it goes to the history, Foreman is inspired on another tool which I was responsible for and was developed internally for the company I work for in 2008, I've tried hard to opensource that tool, but once I've failed I've started rewriting foreman from scratch on my free time. I spend a lot of my time on Foreman, mainly because I wanted to contribute something back, I truly believe in opensource, and for the first time, was able to release something that people might find useful. Our initial goals (RL and myself) were to share the code, however we've learned that there is a mismatch between what RL needs, and what I can deliver, RL need to make money, while I didn't feel its right that in order to do opensource development I need to get a lawyer. saying that, I would love to find a way to share/merge, I do know that there are areas, where we have different aim - while that could be probably solved with a plugins architecture, at this point of time, I'll be happy to integrate foreman, share code, libs or what ever that we all benefit from our strong community. I've developed foreman to be useful for me, hoping others will find it useful too, I've been doing my best to add feature requests from the community, so it fits to us all, at any point of time I didn't aim to take away clients from RL. Not everyone needs to use foreman, but one of its goal is to make puppet more accessible for others (e.g. someone mentioned something about SSL hell recently? ;)) and at the end act as best practice approach to system administrations tasks around puppet. Michael - I'm sure you didnt mean any harm, it just sounded wrong, I'm sure that no one at RL wants to make its community members feel bad about just using puppet (because its so great) and not contribute code, and for the ones who do contribute code, if it doesn't fit exactly to RL profitable model, there must be other alternatives. Ohad -- 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] dashboard, foreman etc (was: Living with Puppet...)
Ohad Levy wrote: Hi All, I'm sorry if I offended anyone by saying that Foreman solves all of puppet problems, I mainly meant that there are areas which puppet simply doesn't deal with, but we as sysadmins need to. My goal with Foreman is to make our life easier, Foreman would be extremely difficult to made if Puppet was not around, and I'm grateful for puppet and RL. As far it goes to the history, Foreman is inspired on another tool which I was responsible for and was developed internally for the company I work for in 2008, I've tried hard to opensource that tool, but once I've failed I've started rewriting foreman from scratch on my free time. I spend a lot of my time on Foreman, mainly because I wanted to contribute something back, I truly believe in opensource, and for the first time, was able to release something that people might find useful. Our initial goals (RL and myself) were to share the code, however we've learned that there is a mismatch between what RL needs, and what I can deliver, RL need to make money, while I didn't feel its right that in order to do opensource development I need to get a lawyer. saying that, I would love to find a way to share/merge, I do know that there are areas, where we have different aim - while that could be probably solved with a plugins architecture, at this point of time, I'll be happy to integrate foreman, share code, libs or what ever that we all benefit from our strong community. I've developed foreman to be useful for me, hoping others will find it useful too, I've been doing my best to add feature requests from the community, so it fits to us all, at any point of time I didn't aim to take away clients from RL. Not everyone needs to use foreman, but one of its goal is to make puppet more accessible for others (e.g. someone mentioned something about SSL hell recently? ;)) and at the end act as best practice approach to system administrations tasks around puppet. Michael - I'm sure you didnt mean any harm, it just sounded wrong, I'm sure that no one at RL wants to make its community members feel bad about just using puppet (because its so great) and not contribute code, and for the ones who do contribute code, if it doesn't fit exactly to RL profitable model, there must be other alternatives. Ohad Yeah totally. I screwed up here -- I didn't quite voice the let's figure out how to collaborate and fix what is broken even remotely correctly. Thanks for the response. You have done great things here. I would correct just that last part of what you said though -- if you want to contribute code, we welcome it, regardless. By no means do we want to imply that contributions have to be profitable or anything like that. Puppet would not be possible without this community and the wellspring of ideas that flows from it. We'll never forget this and I think you can look to the history of everything that has happened here and in the community to show both that this holds true and where the future can go. Anyway, it should have been said thus: when something sucks, let us know, and we welcome fixing it... we don't neccessarily want to always see that be fixed outside of Puppet and welcome those additions and need (really need) to talk about them and address them.Things added to Foreman often highlight those things we need to improve. Further, we also want to welcome ideas for dashboard too ... and such a plugin architecture I think is a very very logical extension that will happen there to enable such integrations. Thanks! --Michael -- 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] ssh_authorized_key creating multiple entries on repeated runs
Hello,
Newbie here. Question regarding the reference type
ssh_authorized_key. Is this part of the designed behaviour?
I have:
ssh_authorized_key { someuser:
ensure = present,
key = some id_rsa.pub key,
type = ssh-rsa,
user = someuser
}
It keeps appending to /home/someuser/.ssh/authorized_keys
Is this the best way to manage 1 or 2 admin type of users in the
system?
Thanks
Simon
--
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] Israeli Puppet meetup?
Hey Guys, Wondering if anyone here is from Israel, I'll be visiting Israel next week and would love to have a good puppet talk cheers, Ohad -- 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] Living with Puppet...
On 2/9/10 9:57 AM, Michael DeHaan wrote: If there is such a percieved lack of interest, this is something I would like to rectify. (Also don't miscontrue an inability to implement RFEs with a lack of interest... the phrase patches accepted is often thrown around but exists for a reason, right?) I have submitted a pull request for a feature, and have at least two tickets to the dashboard's redmine project. Currently there are something like 8 open bugs, none of which have even been reviewed. :( That all being said, the past is just that. A seperate list for dashboard discussion and development probably makes sense so we can get this going in higher gear. OK by me, if the demand is there. Although given the volume of traffic in Redmine for it, I don't know that there is just yet...? Have no idea how many people use it. While it mainly serves external nodes now, there are a lot of interesting places it can go -- and we would definitely like everyone's ideas on that. --Michael ...so in the mean time I have forked the project on Github and fix what I can. I've added a handful of Rake tasks to add/modify nodes, prune reports, etc. Very useful stuff if you're maintaining a decent number of hosts, IMO! (I currently have ~400, but that will grow by 10x or more in a couple months.) BTW, I'm working on setting up partitions for the reports table to make it way more scalable (doing a select * on 30k rows just sucks, and I plan to have ~7M at any given time). Also will be changing the schema to add indexes where necessary. So right now if anyone wants to use my fixes/changes they have to clone my repo. Bummer! -scott -- 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.
