Re: [Puppet Users] REMOVE ME
Please step into my office, and I'll remove you :-) Or look at the mail headers and take appropriate action: List-Unsubscribe: http://groups.google.com/group/puppet-users/subscribe?hl=en_US, mailto:puppet-users+unsubscr...@googlegroups.com Regards, Martijn. On 25-01-11 07:48, ralph.gro...@itdz-berlin.de wrote: -- *From:* puppet-users@googlegroups.com [mailto:puppet-users@googlegroups.com] *On Behalf Of *puppet-users+nore...@googlegroups.com *Sent:* Monday, January 24, 2011 1:00 PM *To:* Abridged Recipients *Subject:* [Puppet Users] Abridged summary of puppet-users@googlegroups.com - 45 Messages in 9 Topics Today's Topic Summary Group: http://groups.google.com/group/puppet-users/topics * scheduler problem? #group_thread_0 [1 Update] * Do we need a new name for --test? #group_thread_1 [34 Updates] * mcollective for rhel 4 #group_thread_2 [2 Updates] * Puppet dashboard don't show current day #group_thread_3 [2 Updates] * Behavior of local modules and their included facts #group_thread_4 [1 Update] * problems with dependencies #group_thread_5 [2 Updates] * high 500 error rate on file metadata operations #group_thread_6 [1 Update] * PSA: Please use pre tags when reporting bugs. #group_thread_7 [1 Update] * another 2.6 question... stages #group_thread_8 [1 Update] Topic: scheduler problem? http://groups.google.com/group/puppet-users/t/e00eda15de69b533 Antony Mayi antonym...@yahoo.com Jan 24 11:29AM ^ #digest_top Hi Nan, thanks. I have removed the schedule (re)definition but it does still the same - the tidy is called on every run (every 30 minutes). the state.yaml after a typical run has following more... http://groups.google.com/group/puppet-users/msg/7199a3f934647c02 Topic: Do we need a new name for --test? http://groups.google.com/group/puppet-users/t/fbe7bcfe04b5f657 Nigel Kersten ni...@puppetlabs.com Jan 23 01:33PM -0800 ^ #digest_top https://projects.puppetlabs.com/issues/2476 This does seem to confuse a fair few new users. What would be a better name for --test? more... http://groups.google.com/group/puppet-users/msg/d3dd3cbe311368e8 Adam Nielsen a.niel...@shikadi.net Jan 24 07:50AM +1000 ^ #digest_top https://projects.puppetlabs.com/issues/2476 This does seem to confuse a fair few new users. What would be a better name for --test? Using Gentoo's emerge as an example, how about more... http://groups.google.com/group/puppet-users/msg/4f4c6c8b58c491c2 Nigel Kersten ni...@puppetlabs.com Jan 23 02:15PM -0800 ^ #digest_top This does seem to confuse a fair few new users. What would be a better name for --test? Using Gentoo's emerge as an example, how about --oneshot? It's more than that though. more... http://groups.google.com/group/puppet-users/msg/69a330193ef7d96d Denmat tu2bg...@gmail.com Jan 24 09:35AM +1100 ^ #digest_top I was thinking '--update' as that is what it does but then that doesn't describe the '--one-time' nature of it explicitly. I always felt funny updating hosts with 'test' though :) Hard one. more... http://groups.google.com/group/puppet-users/msg/1313878342cdbaa7 Patrick kc7...@gmail.com Jan 23 02:44PM -0800 ^ #digest_top On Jan 23, 2011, at 1:50 PM, Adam Nielsen wrote: This does seem to confuse a fair few new users. What would be a better name for --test? Using Gentoo's emerge as an example, how more... http://groups.google.com/group/puppet-users/msg/32700f78acf03e7 Daniel Pittman dan...@puppetlabs.com Jan 23 03:35PM -0800 ^ #digest_top My inclination is to say that ontime or verbose have stolen the name for another concept; perhaps interactive covers the standard use-case well enough? Daniel What would be a better more... http://groups.google.com/group/puppet-users/msg/ba3086cb22134102 Dan Bode d...@puppetlabs.com Jan 23 03:38PM -0800 ^ #digest_top
[Puppet Users] Another question concerning run stages
Hi all,
even though I've read some postings about run stages, I'm still having
trouble using them correctly.
First of all: Is it possible to add a stage directly when defining a
class? That question has already been asked here (in section 2):
http://groups.google.com/group/puppet-users/browse_thread/thread/a4c9ee83039ddff3/3cfe92dd495f069a
If that wasn't possible, I've gathered from other threads, that I
would have to add stages to my node definitions, like so:
node ab_basenode {
include baseconfig
include ab_baseconfig
class { afs: stage = first }
}
However, this does not work, as it produces: Duplicate definition:
Class[afs] is already defined; cannot redefine. This makes sense, as
class afs is indeed defined in module baseconfig. Does that mean,
that I can only use the above stage resource declaration syntax when
defining the class afs directly inside ab_basenode (instead of
including it)?
A few more words explaining the manifest/module structure:
I have the modules
baseconfig (default configuration for all nodes of our institute)
and
ab_baseconfig (default configuration for department AB).
Both modules have many classes, one of which configures the AFS file
system client (class afs).
The two modules above are included into node ab_basenode, which is a
default node for department AB.
The actual physical nodes of department AB are then defined by
inheritance
node taranaki.domainname.de inherits ab_basenode
and contain node-specific configuration (e.g. webserver config).
I hope, someone understands, what I am trying to do and might shed
some light onto the stage problem. As I'm new to puppet, I would also
appreciate criticism about the manifest/module structure - maybe I'm
doing things too complicated?
Best regards,
Jan
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Do we need a new name for --test?
On 25 Jan 2011, at 10:30, Felix Frank felix.fr...@alumni.tu-berlin.de wrote: On 01/24/2011 09:39 PM, R.I.Pienaar wrote: - Original Message - On Jan 24, 2011, at 11:17 AM, R.I.Pienaar wrote: - Original Message - If we don't want --manual you could go with --watch as that's really what I'm doing - watching puppet run. :) I like --watch too I hope this is a joke. I really think this name is a worse fit than --test. I run --test when I want to log into a machine and watch it do a run in a slightly more verbose and debug/observation friendly manner. 'watch' seems to describe this use case well, it doesnt imply that no changes will be made for example. I'd want to run --test when I want it to imply what --test does today but also --noop which is what most newcomers on irc also seem to think. The word 'test' seems to imply a dry run I was under the impression that there was consensus that the semantics of --test should not be changed, ever, in order not to break scripts out there in the wild. Deprecating and loosing --test altogether seems to be less of a problem. I wasn't suggesting a change merely stating the expectation the word test creates. I concur with Patrick in that puppetd --watch is about as misleading as --test itself. I'd expect such an invocation to allow me to monitor the regular proceedings of the background agent. It doesn't appear to imply a forced ad hoc action, much less the cache semantics. I still favor --manual. Regards, Felix -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Mirror folder with large files
On 24/01/11 20:57, Patrick wrote:
On Jan 24, 2011, at 9:14 AM, Daniel Piddock wrote:
Dear list,
I'm attempting to mirror a folder containing a few large files from an
NFS location to the local drive. Subsequent runs take a lot longer than
I'd have expected, after the first run.
Using the following block a puppet apply run is currently taking 30 seconds:
file { '/usr/share/target':
source = 'file:///home/archive/source/',
recurse = true,
backup = false,
checksum = mtime,
}
There are 42 files taking up 870MB. I'd have thought stating the files
in the source and target, comparing to each other (or a cache internal
to puppet as it doesn't set the mtime on files) would be a lot faster
than it is.
I was curious about what puppet was up to, so ran it in strace. It's
reading every file every run, multiple times! Reads the target twice,
then the source twice before reading the target again. Considering I
wasn't expecting it to open any of the files at all this is total over kill.
Is this horribly bugged or have I got a magic incantation that's causing
this behaviour? strace is rather verbose and I haven't exactly read all
80MB of the dump line by line.
Is there a neater way of just mirroring a folder based on modification
time? I suppose the easiest route would be an exec of rsync, at least I
have control over that.
I'm using Puppet 2.6.4.
Dan
I especially like the way Ruby searches for and loads the md5 library
every time it's used. What a performant language.
This sounds like a bug to me. I do know that I never use recurse=true except
when neccisary myself because it's too slow. In your position, I would
replace it with an rsync and file a bug.
Also, does it behave this badly when no changes are made or just when making
changes
This happens every single run, source and target have not changed state.
I tried stracing when just a single file is copied. Puppet is still
reading both source and target when checksum = mtime is used, although
just the once.
I think there might be two bugs here - checksum does not work with
timestamps and recurse is horribly broken.
Puppet issues 6003 and 6004 raised.
Dan
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Mirror folder with large files
On Mon, 2011-01-24 at 17:14 +, Daniel Piddock wrote:
Dear list,
I'm attempting to mirror a folder containing a few large files from an
NFS location to the local drive. Subsequent runs take a lot longer than
I'd have expected, after the first run.
Using the following block a puppet apply run is currently taking 30 seconds:
file { '/usr/share/target':
source = 'file:///home/archive/source/',
recurse = true,
backup = false,
checksum = mtime,
}
There are 42 files taking up 870MB. I'd have thought stating the files
in the source and target, comparing to each other (or a cache internal
to puppet as it doesn't set the mtime on files) would be a lot faster
than it is.
This is a naive view of the problem :)
The puppet file type is certainly the most complex resource abstraction
puppet embeds (just think about the fact that it handles dir, files,
link, remote recursion, local recursion, etc...).
I was curious about what puppet was up to, so ran it in strace. It's
reading every file every run, multiple times! Reads the target twice,
then the source twice before reading the target again. Considering I
wasn't expecting it to open any of the files at all this is total over kill.
Is this horribly bugged or have I got a magic incantation that's causing
this behaviour? strace is rather verbose and I haven't exactly read all
80MB of the dump line by line.
Is there a neater way of just mirroring a folder based on modification
time? I suppose the easiest route would be an exec of rsync, at least I
have control over that.
Yes, I think rsync is the sanest way to do this.
Recursive file resources (and especially sourced ones) are really tough
for puppet to handle in the current way the code is working.
Puppet manages individual file resources, and for every resource it
manages it as an instance of this resource in memory.
For deep/large file hierarchies, Puppet has to create/manage an
individual resource per file/directory present in this hierarchy, which
consumes both cpu and ram (due to the way the ruby GC is poorly
implemented and the time it takes to create a ruby object).
And I don't even talk about the scalability issues of the generation and
handling of billions of change event coming up each time a file is
changed (which happens for instance the first time puppet runs).
I think I remember mtime is a checksum valid only for directory, and
puppet automatically switches to md5 for files (I don't really know the
reason, but I'm sure redmine knows it).
(One of) The problem is that puppet reads the file once to compute the
md5 sum, then it also reads it again to perform the copy when it detects
a change. I don't exactly know why it would write multiple times, but
I'm sure you can debug this by adding debug statements in
puppet/type/file/content.rb where all the write happens.
I'm using Puppet 2.6.4.
Dan
I especially like the way Ruby searches for and loads the md5 library
every time it's used. What a performant language.
This certainly comes from this code in Puppet::Util::Checksums:
# Calculate a checksum of a file's content using Digest::MD5.
def md5_file(filename, lite = false)
require 'digest/md5'
digest = Digest::MD5.new
checksum_file(digest, filename, lite)
end
Notice how the require is in the function instead of being outside.
I'd think that ruby would be smart enough to understand the file has
already been required and not bother, but apparently it doesn't do
that for you. Can you give us what ruby version and what platform you're
using?
--
Brice Figureau
Follow the latest Puppet Community evolutions on www.planetpuppet.org!
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] scheduler problem?
the notify is executed only once but tidy still during each run. is this a bug or a feature? if a bug, is it fixed in some recent version? I would say a bug. Check the bug tracker: http://projects.puppetlabs.com/projects/puppet/issues for any open or closed bugs regarding that problem and if you don't find one: Please file a bug report. ~pete -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Puppet master cannot connect to self
On Mon, Jan 24, 2011 at 09:21 -0800, luke.bigum wrote: Down the bottom of Masterzen's blog post are some helpful openssl commands for checking certificates: http://www.masterzen.fr/2010/11/14/puppet-ssl-explained/ Thanks for the info, I figured it out! The key to the solution was the part where Masterzen explains about the server certificate. There he writes: If your master is also a client of itself (ie it runs a puppet agent), I recommend using this certificate as the client certificate. So what I did, was: # cp ca/ca_crt.pem ./ca/signed/puppet.xs4all.net.pem # cp ca/ca_crt.pem ./certs/puppet.xs4all.net.pem # cp ca/ca_key.pem ./private_keys/puppet.xs4all.net.pem # cp ca/ca_pub.pem ./public_keys/puppet.xs4all.net.pem Then this happened: # puppet agent --test --noop Enter PEM pass phrase: And when I entered the string from ca/private/ca.pass, it worked! So the only thing left to do, was remove the pass phrase from the client certificate: # mv ./private_keys/puppet.xs4all.net.pem /tmp/foo # openssl rsa -in /tmp/foo -out ./private_keys/puppet.xs4all.net.pem Enter pass phrase for /tmp/foo: writing RSA key And then it worked! # puppet agent --test --noop info: Caching catalog for puppet.xs4all.net info: Applying configuration version '1295962955' ... Thanks again for your help. Robert Scheer -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Another question concerning run stages
I am now trying without any module to make debugging easier. I've got
the following:
class afs {
service { openafs-client:
enable= true,
ensure= running,
}
}
class afs_staging inherits afs {
Class[afs] { stage = first }
}
Not quite correct.
You need this (some assumptions made):
class baseconfig {
class { afs: }
...
}
class baseconfig_afs_staging inherits baseconfig {
Class[afs] { stage = first }
}
Then include baseconfig_afs_staging.
HTH,
Felix
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Mirror folder with large files
On 25/01/11 12:45, Brice Figureau wrote:
On Mon, 2011-01-24 at 17:14 +, Daniel Piddock wrote:
Dear list,
I'm attempting to mirror a folder containing a few large files from an
NFS location to the local drive. Subsequent runs take a lot longer than
I'd have expected, after the first run.
Using the following block a puppet apply run is currently taking 30 seconds:
file { '/usr/share/target':
source = 'file:///home/archive/source/',
recurse = true,
backup = false,
checksum = mtime,
}
There are 42 files taking up 870MB. I'd have thought stating the files
in the source and target, comparing to each other (or a cache internal
to puppet as it doesn't set the mtime on files) would be a lot faster
than it is.
This is a naive view of the problem :)
The puppet file type is certainly the most complex resource abstraction
puppet embeds (just think about the fact that it handles dir, files,
link, remote recursion, local recursion, etc...).
Yes, it's a shame that the implication of checksum = mtime doesn't do
what it says on the tin, or the documentation doesn't really mention
anything about how the checksums differ or function. However md5summing
every file twice when recursing seems a bit broken.
I was curious about what puppet was up to, so ran it in strace. It's
reading every file every run, multiple times! Reads the target twice,
then the source twice before reading the target again. Considering I
wasn't expecting it to open any of the files at all this is total over kill.
Is this horribly bugged or have I got a magic incantation that's causing
this behaviour? strace is rather verbose and I haven't exactly read all
80MB of the dump line by line.
Is there a neater way of just mirroring a folder based on modification
time? I suppose the easiest route would be an exec of rsync, at least I
have control over that.
Yes, I think rsync is the sanest way to do this.
Recursive file resources (and especially sourced ones) are really tough
for puppet to handle in the current way the code is working.
Puppet manages individual file resources, and for every resource it
manages it as an instance of this resource in memory.
For deep/large file hierarchies, Puppet has to create/manage an
individual resource per file/directory present in this hierarchy, which
consumes both cpu and ram (due to the way the ruby GC is poorly
implemented and the time it takes to create a ruby object).
And I don't even talk about the scalability issues of the generation and
handling of billions of change event coming up each time a file is
changed (which happens for instance the first time puppet runs).
I think I remember mtime is a checksum valid only for directory, and
puppet automatically switches to md5 for files (I don't really know the
reason, but I'm sure redmine knows it).
(One of) The problem is that puppet reads the file once to compute the
md5 sum, then it also reads it again to perform the copy when it detects
a change. I don't exactly know why it would write multiple times, but
I'm sure you can debug this by adding debug statements in
puppet/type/file/content.rb where all the write happens.
In recursion, the source file is read twice, target is tested and if it
doesn't exist the source is read again for the copy. If the target did
exist, it's read twice as well. It does not matter if the checksum was
specified as md5 or mtime. I put more detail on issue 6003
http://projects.puppetlabs.com/issues/6003 .
Writing only happens once per changed file.
I'm using Puppet 2.6.4.
Dan
I especially like the way Ruby searches for and loads the md5 library
every time it's used. What a performant language.
This certainly comes from this code in Puppet::Util::Checksums:
# Calculate a checksum of a file's content using Digest::MD5.
def md5_file(filename, lite = false)
require 'digest/md5'
digest = Digest::MD5.new
checksum_file(digest, filename, lite)
end
Notice how the require is in the function instead of being outside.
I'd think that ruby would be smart enough to understand the file has
already been required and not bother, but apparently it doesn't do
that for you. Can you give us what ruby version and what platform you're
using?
The client I'm using for testing is Fedora 14, ruby-1.8.7.330-1.fc14.x86_64
Dan
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] How to update CA cert?
What happens if the generated CA cert expires? Does puppet detect that in time and generates and distributes a new CA cert? Or do I have to generate and distribute one myself? Robert Scheer -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] What's new about the Webrick/Mongrel situation ?
Hi, I've just finished James Turnbull book Pulling Strings With Puppet - which definitely an excellent introduction to Puppet, and I was wondering - as the book is a couple years old, what was the status of the all mongrel/webrick situation ? I guess it's still recommended to use Mongrel rather than Webrick for puppetmaster, at least for 0.25.5 (which I'm using), but it is still a sounded approach when using more recent version of puppet ? Does the new version brings something more in term of high availability ? -- Romain PELISSE, *The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it -- Terry Pratchett* http://belaran.eu/wordpress/belaran -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Syncing /modules --dir via Puppet
Hello All, For those who run multiple Puppetmasters; what's your method of syncing the modules directory? NFS, rsync, etc? I'm asking, because I'd like to use puppet itself to sync up the modules. I know that the normally the modules dir gets shared automatically, but what would be the implications to file serve the entire modules dir via /etc/puppet/fileserver.conf, to sync up with other masters? What's the best practices way of syncing modules dir across masters? 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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] puppet ca: Invalid method to apply
What does this message mean: [root@pirates puppet]# rm -rf /var/lib/puppet/ssl/ [root@pirates puppet]# puppet cert --version 2.6.3 [root@pirates puppet]# puppet cert notice: Signed certificate request for ca notice: Rebuilding inventory file Invalid method to apply It seems to have created the ca and other things just fine. Thanks, Mohamed. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] puppet ca: Invalid method to apply
On 01/25/2011 05:48 PM, Mohamed Lrhazi wrote: What does this message mean: [root@pirates puppet]# rm -rf /var/lib/puppet/ssl/ [root@pirates puppet]# puppet cert --version 2.6.3 [root@pirates puppet]# puppet cert Aren't you supposed to 'puppet cert --list', 'puppet cert --sign' etc. instead of plain 'puppet cert'? notice: Signed certificate request for ca notice: Rebuilding inventory file Invalid method to apply It seems to have created the ca and other things just fine. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Syncing /modules --dir via Puppet
We keep all of our puppet manifests and modules in git and use capistrano for deployment. Cheers, Atha On Tuesday, January 25, 2011 at 11:46 AM, CraftyTech wrote: Hello All, For those who run multiple Puppetmasters; what's your method of syncing the modules directory? NFS, rsync, etc? I'm asking, because I'd like to use puppet itself to sync up the modules. I know that the normally the modules dir gets shared automatically, but what would be the implications to file serve the entire modules dir via /etc/puppet/fileserver.conf, to sync up with other masters? What's the best practices way of syncing modules dir across masters? 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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] correct procedure for installing modules from http://forge.puppetlabs.com
I am trying to use a module from puppet forge and I don't understand the instructions at https://github.com/puppetlabs/puppet-module-tool Install a module release . What is meant by the sentence you can then add this module directory to your Puppet configuration files to use it.. I am just using the ghoneycutt-ssh module as an example. My module path is modulepath = /home/hughest/.puppet/modules:/usr/share/puppet/ modules so i changed directory to the local users modules directory and installed the module there and attempted to tun its test which fails cd /home/hughest/.puppet/modules puppet-module install ghoneycutt-ssh puppet --noop /home/hughest/.puppet/modules/ghoneycutt-ssh/tests/ init.pp This causes the following error Could not find class ssh at /home/hughest/.puppet/modules/ ghoneycutt-ssh/tests/init.pp:1 on node nitrogen If i then rename the module directory to 'ssh' from 'ghoneycutt-ssh' the test works correctly mv /home/hughest/.puppet/modules/ghoneycutt-ssh /home/ hughest/.puppet/modules/ssh puppet --noop /home/hughest/.puppet/modules/ssh/tests/init.pp Is this then the correct procedure for installing modules or am I missing something. The documentation in puppet-module seems to imply that renaming the module directory is the wrong thing to do and I should just be changing some config somewhere. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] What's new about the Webrick/Mongrel situation ?
On Tue, Jan 25, 2011 at 8:27 AM, Romain Pelisse bela...@gmail.com wrote: Hi, I've just finished James Turnbull book Pulling Strings With Puppet - which definitely an excellent introduction to Puppet, and I was wondering - as the book is a couple years old, what was the status of the all mongrel/webrick situation ? I guess it's still recommended to use Mongrel rather than Webrick for puppetmaster, at least for 0.25.5 (which I'm using), but it is still a sounded approach when using more recent version of puppet ? Does the new version brings something more in term of high availability ? The most common setup now uses Passenger, but Mongrel is certainly still valid. Webrick is still not recommended for production use. http://projects.puppetlabs.com/projects/1/wiki/Using_Passenger -- Romain PELISSE, The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it -- Terry Pratchett http://belaran.eu/wordpress/belaran -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] puppet ca: Invalid method to apply
I read that to generate CA certs, one simply runs: puppetca So for 2.6 I did: puppet cert On Tue, Jan 25, 2011 at 11:50 AM, Felix Frank felix.fr...@alumni.tu-berlin.de wrote: On 01/25/2011 05:48 PM, Mohamed Lrhazi wrote: What does this message mean: [root@pirates puppet]# rm -rf /var/lib/puppet/ssl/ [root@pirates puppet]# puppet cert --version 2.6.3 [root@pirates puppet]# puppet cert Aren't you supposed to 'puppet cert --list', 'puppet cert --sign' etc. instead of plain 'puppet cert'? notice: Signed certificate request for ca notice: Rebuilding inventory file Invalid method to apply It seems to have created the ca and other things just fine. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] high 500 error rate on file metadata operations
On 25/01/11 18:47, Jason Wright wrote: On Mon, Jan 24, 2011 at 9:24 PM, Daniel Pittman dan...@puppetlabs.com wrote: For the other two exceptions, do you have 'ArgumentError' Could not find hostname raised anywhere, or FileServerError, Fileserver module %s is not mounted? They also, ultimately, lead down to a place where I/O subsystem errors could cause a false failure, and it would be interesting to know if either of those two were thrown. These two lead to a fileserver module not mounted exception: /usr/lib/ruby/1.8/puppet/network/handler/fileserver.rb:401:in `splitpath' /usr/lib/ruby/1.8/puppet/network/handler/fileserver.rb:236:in `convert' /usr/lib/ruby/1.8/puppet/network/handler/fileserver.rb:133:in `list' /usr/lib/ruby/1.8/rubygems/custom_require.rb:31 /usr/lib/ruby/1.8/puppet/network/xmlrpc/processor.rb:52:in `call' /usr/lib/ruby/1.8/puppet/network/xmlrpc/processor.rb:52:in `protect_service' /usr/lib/ruby/1.8/puppet/network/xmlrpc/processor.rb:85 /usr/lib/ruby/1.8/xmlrpc/server.rb:338:in `call' /usr/lib/ruby/1.8/xmlrpc/server.rb:338:in `dispatch' /usr/lib/ruby/1.8/xmlrpc/server.rb:325:in `each' /usr/lib/ruby/1.8/xmlrpc/server.rb:325:in `dispatch' /usr/lib/ruby/1.8/xmlrpc/server.rb:368:in `call_method' /usr/lib/ruby/1.8/xmlrpc/server.rb:380:in `handle' /usr/lib/ruby/1.8/puppet/network/xmlrpc/processor.rb:44:in `process' /usr/lib/ruby/1.8/puppet/network/http/rack/xmlrpc.rb:35:in `process' /usr/lib/ruby/1.8/puppet/network/handler/fileserver.rb:401:in `splitpath' /usr/lib/ruby/1.8/puppet/network/handler/fileserver.rb:236:in `convert' /usr/lib/ruby/1.8/puppet/network/handler/fileserver.rb:68:in `describe' /usr/lib/ruby/1.8/rubygems/custom_require.rb:31 /usr/lib/ruby/1.8/puppet/network/xmlrpc/processor.rb:52:in `call' /usr/lib/ruby/1.8/puppet/network/xmlrpc/processor.rb:52:in `protect_service' /usr/lib/ruby/1.8/puppet/network/xmlrpc/processor.rb:85 /usr/lib/ruby/1.8/xmlrpc/server.rb:338:in `call' /usr/lib/ruby/1.8/xmlrpc/server.rb:338:in `dispatch' /usr/lib/ruby/1.8/xmlrpc/server.rb:325:in `each' /usr/lib/ruby/1.8/xmlrpc/server.rb:325:in `dispatch' /usr/lib/ruby/1.8/xmlrpc/server.rb:368:in `call_method' /usr/lib/ruby/1.8/xmlrpc/server.rb:380:in `handle' /usr/lib/ruby/1.8/puppet/network/xmlrpc/processor.rb:44:in `process' /usr/lib/ruby/1.8/puppet/network/http/rack/xmlrpc.rb:35:in `process' xmlrpc? Do you still have 0.24.x clients? You omitted one important piece of information which is the kind of exception along with the error message. Can you post it so that we can understand what happens? -- Brice Figureau My Blog: http://www.masterzen.fr/ -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] high 500 error rate on file metadata operations
On Tue, Jan 25, 2011 at 10:25 AM, Brice Figureau brice-pup...@daysofwonder.com wrote: On 25/01/11 18:47, Jason Wright wrote: On Mon, Jan 24, 2011 at 9:24 PM, Daniel Pittman dan...@puppetlabs.com wrote: For the other two exceptions, do you have 'ArgumentError' Could not find hostname raised anywhere, or FileServerError, Fileserver module %s is not mounted? They also, ultimately, lead down to a place where I/O subsystem errors could cause a false failure, and it would be interesting to know if either of those two were thrown. These two lead to a fileserver module not mounted exception: /usr/lib/ruby/1.8/puppet/network/handler/fileserver.rb:401:in `splitpath' /usr/lib/ruby/1.8/puppet/network/handler/fileserver.rb:236:in `convert' /usr/lib/ruby/1.8/puppet/network/handler/fileserver.rb:133:in `list' /usr/lib/ruby/1.8/rubygems/custom_require.rb:31 /usr/lib/ruby/1.8/puppet/network/xmlrpc/processor.rb:52:in `call' /usr/lib/ruby/1.8/puppet/network/xmlrpc/processor.rb:52:in `protect_service' /usr/lib/ruby/1.8/puppet/network/xmlrpc/processor.rb:85 /usr/lib/ruby/1.8/xmlrpc/server.rb:338:in `call' /usr/lib/ruby/1.8/xmlrpc/server.rb:338:in `dispatch' /usr/lib/ruby/1.8/xmlrpc/server.rb:325:in `each' /usr/lib/ruby/1.8/xmlrpc/server.rb:325:in `dispatch' /usr/lib/ruby/1.8/xmlrpc/server.rb:368:in `call_method' /usr/lib/ruby/1.8/xmlrpc/server.rb:380:in `handle' /usr/lib/ruby/1.8/puppet/network/xmlrpc/processor.rb:44:in `process' /usr/lib/ruby/1.8/puppet/network/http/rack/xmlrpc.rb:35:in `process' /usr/lib/ruby/1.8/puppet/network/handler/fileserver.rb:401:in `splitpath' /usr/lib/ruby/1.8/puppet/network/handler/fileserver.rb:236:in `convert' /usr/lib/ruby/1.8/puppet/network/handler/fileserver.rb:68:in `describe' /usr/lib/ruby/1.8/rubygems/custom_require.rb:31 /usr/lib/ruby/1.8/puppet/network/xmlrpc/processor.rb:52:in `call' /usr/lib/ruby/1.8/puppet/network/xmlrpc/processor.rb:52:in `protect_service' /usr/lib/ruby/1.8/puppet/network/xmlrpc/processor.rb:85 /usr/lib/ruby/1.8/xmlrpc/server.rb:338:in `call' /usr/lib/ruby/1.8/xmlrpc/server.rb:338:in `dispatch' /usr/lib/ruby/1.8/xmlrpc/server.rb:325:in `each' /usr/lib/ruby/1.8/xmlrpc/server.rb:325:in `dispatch' /usr/lib/ruby/1.8/xmlrpc/server.rb:368:in `call_method' /usr/lib/ruby/1.8/xmlrpc/server.rb:380:in `handle' /usr/lib/ruby/1.8/puppet/network/xmlrpc/processor.rb:44:in `process' /usr/lib/ruby/1.8/puppet/network/http/rack/xmlrpc.rb:35:in `process' xmlrpc? Do you still have 0.24.x clients? You omitted one important piece of information which is the kind of exception along with the error message. Can you post it so that we can understand what happens? Brice, I'm pretty sure we still had some XMLRPC left in 0.25.x, I don't believe we completely got rid of it until 2.6.x -- Brice Figureau My Blog: http://www.masterzen.fr/ -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] high 500 error rate on file metadata operations
On 25/01/11 19:27, Nigel Kersten wrote: On Tue, Jan 25, 2011 at 10:25 AM, Brice Figureau brice-pup...@daysofwonder.com wrote: On 25/01/11 18:47, Jason Wright wrote: On Mon, Jan 24, 2011 at 9:24 PM, Daniel Pittman dan...@puppetlabs.com wrote: For the other two exceptions, do you have 'ArgumentError' Could not find hostname raised anywhere, or FileServerError, Fileserver module %s is not mounted? They also, ultimately, lead down to a place where I/O subsystem errors could cause a false failure, and it would be interesting to know if either of those two were thrown. These two lead to a fileserver module not mounted exception: /usr/lib/ruby/1.8/puppet/network/handler/fileserver.rb:401:in `splitpath' /usr/lib/ruby/1.8/puppet/network/handler/fileserver.rb:236:in `convert' /usr/lib/ruby/1.8/puppet/network/handler/fileserver.rb:133:in `list' /usr/lib/ruby/1.8/rubygems/custom_require.rb:31 /usr/lib/ruby/1.8/puppet/network/xmlrpc/processor.rb:52:in `call' /usr/lib/ruby/1.8/puppet/network/xmlrpc/processor.rb:52:in `protect_service' /usr/lib/ruby/1.8/puppet/network/xmlrpc/processor.rb:85 /usr/lib/ruby/1.8/xmlrpc/server.rb:338:in `call' /usr/lib/ruby/1.8/xmlrpc/server.rb:338:in `dispatch' /usr/lib/ruby/1.8/xmlrpc/server.rb:325:in `each' /usr/lib/ruby/1.8/xmlrpc/server.rb:325:in `dispatch' /usr/lib/ruby/1.8/xmlrpc/server.rb:368:in `call_method' /usr/lib/ruby/1.8/xmlrpc/server.rb:380:in `handle' /usr/lib/ruby/1.8/puppet/network/xmlrpc/processor.rb:44:in `process' /usr/lib/ruby/1.8/puppet/network/http/rack/xmlrpc.rb:35:in `process' /usr/lib/ruby/1.8/puppet/network/handler/fileserver.rb:401:in `splitpath' /usr/lib/ruby/1.8/puppet/network/handler/fileserver.rb:236:in `convert' /usr/lib/ruby/1.8/puppet/network/handler/fileserver.rb:68:in `describe' /usr/lib/ruby/1.8/rubygems/custom_require.rb:31 /usr/lib/ruby/1.8/puppet/network/xmlrpc/processor.rb:52:in `call' /usr/lib/ruby/1.8/puppet/network/xmlrpc/processor.rb:52:in `protect_service' /usr/lib/ruby/1.8/puppet/network/xmlrpc/processor.rb:85 /usr/lib/ruby/1.8/xmlrpc/server.rb:338:in `call' /usr/lib/ruby/1.8/xmlrpc/server.rb:338:in `dispatch' /usr/lib/ruby/1.8/xmlrpc/server.rb:325:in `each' /usr/lib/ruby/1.8/xmlrpc/server.rb:325:in `dispatch' /usr/lib/ruby/1.8/xmlrpc/server.rb:368:in `call_method' /usr/lib/ruby/1.8/xmlrpc/server.rb:380:in `handle' /usr/lib/ruby/1.8/puppet/network/xmlrpc/processor.rb:44:in `process' /usr/lib/ruby/1.8/puppet/network/http/rack/xmlrpc.rb:35:in `process' xmlrpc? Do you still have 0.24.x clients? You omitted one important piece of information which is the kind of exception along with the error message. Can you post it so that we can understand what happens? Brice, I'm pretty sure we still had some XMLRPC left in 0.25.x, I don't believe we completely got rid of it until 2.6.x Oh, I'm well aware of this. I was asking about 0.24.x clients, because I thought the not-ported-to-REST handlers was only the filebucket. I was pretty sure file_metadata and file_content were handled through fullblown REST. BTW, I really think this is a thread race, as the first trace reminds me something I reported (and we fixed) for 2.6. Looking to the 0.25.5 code of the xmlrpc fileserver handler, when mounting it tries to find the current node, which might trigger a call to the ENC, if I'm not mistaken. If this operation lasts a long time, it is well possible that another threads trigger the same codepath. This same codepath also uses the environment cached_attr module: I also discovered a thread race in this code that was fixed in 2.6. Would it be possible to run passenger in a mode where it won't spawn more than one thread and see if the problem disappears? -- Brice Figureau My Blog: http://www.masterzen.fr/ -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] high 500 error rate on file metadata operations
On 25/01/11 20:10, Jason Wright wrote: On Tue, Jan 25, 2011 at 10:48 AM, Brice Figureau brice-pup...@daysofwonder.com wrote: xmlrpc? Do you still have 0.24.x clients? No. We're 0.25.5 across the board. You omitted one important piece of information which is the kind of exception along with the error message. Can you post it so that we can understand what happens? No, I can't. As I originally stated, the actual exception isn't making it into the apache error log and since the stack traces aren't timestamped, I can't correlate to the puppetmasterd logs. I'd love to understand why this is so I can provide better information to you. I've received some passenger pointers from a coworker and am going to play with the logging options to see if I can affect this. OK, I missed this fact in the discussion, sorry. Would it be possible to run passenger in a mode where it won't spawn more than one thread and see if the problem disappears? You mean setting PassengerMaxPoolSize to 1? I can try that on one of the production VMs but I'll have to revert it immediately if it causes any other problems. I really don't know anything about Passenger, but reading the documentation I don't think that's the correct settings. I couldn't find in the documentation how passenger or rack use ruby threads, so I'm unsure about what to do (one solution would be to add some sync on the puppet side). -- Brice Figureau My Blog: http://www.masterzen.fr/ -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Do we need a new name for --test?
Nigel Kersten wrote: On Mon, Jan 24, 2011 at 12:27 AM, DEGREMONT Aurelien aurelien.degrem...@cea.fr wrote: We never use puppetd in daemonized mode, and manual runs puppet when needed with -t option. You shouldn't be doing this. If you're running puppet agent out of cron, you should do something like: puppetd --onetime --no-daemonize and not bring in all the ignoring of cache settings that --test does. Why not? I run puppetd from cron with --no-usecacheonfailure. If I manage to insert an error into my production environment, I prefer that it does not try to apply an outdated catalog, and instead give me an error message. (Although when I tried it out now and introduced a deliberate fail() in my manifests and ran puppetd with --usecacheonfailure, I got an error when it couldn't parse the YAML it wrote on the previous run: err: Cached catalog for soncweb.nsc.liu.se failed: Could not parse YAML data for catalog soncweb.nsc.liu.se: syntax error on line 1234, col 43: ` !ruby/sym line: id:3:initdefault:' But relying on the fact that Puppet can't parse what it has written itself doesn't feel very robust, so I think I'll continue with --no-usecacheonfailure... [This is Puppet 0.25.5, by the way.]) /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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Compile Puppet on Ubuntu
Thanks a bunch. I don't know how I missed this information before. I used the instructions on http://docs.puppetlabs.com/guides/installation.html. I tried to first do the methodology using gems and it looked to install, but then I couldn't find any proof that it had installed, so I used the source methodology. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: puppetmaster 100%cpu usage on 2.6 (not on 0.24)
Brice Figureau brice-pup...@daysofwonder.com writes:
On 15/12/10 19:27, Ashley Penney wrote:
This issue is definitely a problem. I have a support ticket in with
Puppet Labs about the same thing. My CPU remains at 100% almost
constantly and it slows things down significantly. If you strace it you
can see that very little appears to be going on. This is absolutely not
normal behavior. Even when I had 1 client checking in I had all cores
fully used.
I do agree that it's not the correct behavior. I suggest you to strace
or use any other ruby introspection techniques to find what part of the
master is taking CPU.
I'm having a similar problem with 2.6.3. At this point, I can't get
reliable puppet runs, and I'm not sure what to do.
What seems to happen is things are working fine at the
beginning. Catalog compiles peg the CPU for the puppet process that is
doing them and take anywhere from between 20 seconds and 75
seconds. Then things get drastically worse after 4 compiles (note: I
have four mongrels too, coincidence?), catalog compiles shoot up to 115,
165, 209, 268, 273, 341, 418, 546, 692, 774, 822, then 1149
seconds... then things are really hosed. Sometimes hosts will fail
outright and complain about weird things, like:
Jan 25 14:04:34 puppetmaster puppet-master[30294]: Host is missing hostname
and/or domain: gull.example.com
Jan 25 14:04:55 puppetmaster puppet-master[30294]: Failed to parse template
site-apt/local.list: Could not find value for 'lsbdistcodename' at
/etc/puppet/modules/site-apt/manifests/init.pp:4 on node gull.example.com
All four of my mongrels are constantly pegged, doing 40-50% of the CPU
each, occupying all available CPUs. They never settle down. I've got 74
nodes checking in now, it doesn't seem like its that many, but perhaps
i've reached a tipping point with my puppetmaster (its a dual 1ghz,
2gigs of ram machine)?
I've tried a large number of different things to attempt to work around
this:
0. reduced my node check-in times to be once an hour (and splayed
randomly)
1. turn on puppetqd/stomp queuing
This didn't seem to make a difference, its off now
2. turn on thin stored configs
This sort of helped a little, but not enough
3. tried to upgrade rails from 2.3.5 (the debian version) to 2.3.10
I didn't see any appreciable difference here. I ended up going back to
2.3.5 because that was the packaged version.
4. tried to offload file content via nginx[1]
This maybe helped a little, but its clear that the problem isn't the
fileserving, it seems to be something in the catalog compilation.
5. tried to cache catalogs through adding a http front-end cache and
expiring that cache when manifests are updated[1]
I'm not sure this works at all.
6. set 'fair' queuing in my nginx.conf[3]
This seemed to help for a few days, but then things got bad again.
7. set --http_compression
I'm not sure if this actually hurts the master or not (because it has
to now occupy the CPU compressing catalogs?)
8. tried to follow the introspection technique[2]
this wasn't so easy to do, I had to operate really fast, because if I
was too slow the thread would exit, or it would get hung up on:
[Thread 0xb6194b70 (LWP 25770) exited]
[New Thread 0xb6194b70 (LWP 25806)]
Eventually I did manage to get somewhere:
0xb74f1b16 in memcpy () from /lib/i686/cmov/libc.so.6
(gdb) session-ruby
(gdb) redirect_stdout
$1 = 2
(gdb)
$2 = 2
(gdb) eval caller
$3 = 3
(gdb) rb_object_counts
Cannot get thread event message: debugger service failed
An error occurred while in a function called from GDB.
Evaluation of the expression containing the function
(rb_eval_string_protect) will be abandoned.
When the function is done executing, GDB will silently stop.
(gdb) eval total = \[\[ObjectSpace\]\].each_object(Array)\{\|x\| puts '---';
puts x.inspect \}; puts \\---\\nTotal Arrays: \#{total}\\
Invalid character '\' in expression.
... then nothing.
In the tail:
root@puppetmaster:/tmp# tail -f ruby-debug.28724
207
Puppet::Util::LoadedFile[/usr/lib/ruby/1.8/active_record/base.rb:2746:in
`attributes=', /usr/lib/ruby/1.8/active_record/base.rb:2742:in `each',
/usr/lib/ruby/1.8/active_record/base.rb:2742:in `attributes=',
/usr/lib/ruby/1.8/active_record/base.rb:2438:in `initialize',
/usr/lib/ruby/1.8/active_record/reflection.rb:162:in `new',
/usr/lib/ruby/1.8/active_record/reflection.rb:162:in `build_association',
/usr/lib/ruby/1.8/active_record/associations/association_collection.rb:423:in
`build_record',
/usr/lib/ruby/1.8/active_record/associations/association_collection.rb:102:in
`build', /usr/lib/ruby/1.8/puppet/rails/host.rb:145:in `merge_facts',
/usr/lib/ruby/1.8/puppet/rails/host.rb:144:in `each',
/usr/lib/ruby/1.8/puppet/rails/host.rb:144:in `merge_facts',
/usr/lib/ruby/1.8/puppet/rails/host.rb:140:in `each',
/usr/lib/ruby/1.8/puppet/rails/host.rb:140:in `merge_facts',
[Puppet Users] Re: Compile Puppet on Ubuntu
So, upon further review, it appears that install.rb does not work. I
found some threads addressing this issue:
According to
http://www.apacheserver.net/puppet-2-6-4-installation-options-for-redhat-centos-at1098441.htm:
(pasting below:)
I actually found the fix for the tar file method - the 'installation/
configuration' writeup on puppetlabs just miss setting ownership on /
etc/puppet and /var/lib/puppet.
The complete set of commands is (as root):
tar xzvf puppet-2.6.4.tar.gz
cd puppet-2.6.4
ruby install.rb
cd /etc/puppet
puppet --genconfig puppet.conf
mkdir -p /etc/puppet/manifests
cd /etc/puppet/manifests
cat EOF site.pp
# site.pp
file { /etc/sudoers:
owner = root, group = root, mode = 440
}
EOF
puppetmasterd --mkusers
cd /var/lib/puppet
chown -R puppet:puppet .
cd /etc/puppet
chown -R puppet:puppet .
puppetmasterd
On Jan 25, 2:57 pm, TT travis.tr...@gmail.com wrote:
Thanks a bunch. I don't know how I missed this information before.
I used the instructions onhttp://docs.puppetlabs.com/guides/installation.html.
I tried to first do the methodology using gems and it looked to
install, but then I couldn't find any proof that it had installed, so
I used the source methodology.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] RFC: erronously disabling apt-listchanges - #5604
Hi all, It seems that an isolated group of us has come to a mini-consensus about #5604, but I wanted to post to the list to get some wider discussion. As detailed in #5604, the puppet apt provider mysteriously, and rather aggressively, disables apt-listchanges using an environment variable. This is a big ugly, and makes use of apt-listchanges impossible. It turns out that in an effort to fix #4418, which has to do with apt-listBUGS, apt-listCHANGES was also impacted. The bug was about apt-listBUGS, not apt-listCHANGES. in /usr/lib/ruby/1.8/puppet/provider/package/apt.rb there is this: pre ENV['APT_LISTCHANGES_FRONTEND'] = none /pre Which is used by apt-listchanges in ./apt-listchanges/ALCConfig.py. According to git logs, this was changed in b0636354 (Dean Wilson 2010-08-13 13:50:52 +0100 19) with the commit msg: Skip apt-listbugs and apt-listchanges when installing from puppet, but with no rationale. I think that if puppet wants to help people who have configured some software wrong (which is possible to do with apt-listchanges, you can configure it to use a pager interface, which will make puppet hang), then puppet should detect that and error/warn. It shouldn't just silently break the program completely. A hack around this would be to detect if the front-end of apt-listchanges is set to anything other than 'mail' or 'text' and then notify the admin that this wont work. Or just whitelist known non-interactive front-ends, so that things that should work do work. It seems to me that the bug fixed in #4418 was just too aggressive. It shouldn't have touched apt-listchanges, as the bug doesn't even mention that program... it should have only dealt with apt-listbugs. If someone *did* file a bug about apt-listchanges, the right solution probably would be to tell the person to configure their apt-listchanges properly, rather than try to be really clever (and obscure) in puppet, although whitelisting might be a proactive way of heading that off at the pass. Thoughts? Micah -- pgp8d0I2mlX0Q.pgp Description: PGP signature
