Re: [Puppet Users] Re: Problem loading custom modules
On Wed, Jan 12, 2011 at 12:41, Thomas Bellman wrote: > Felix Frank wrote: > >> That's why I originally asked for pastes of configs, manifests *and* >> filesystem listings (not to the list preferably, use pastebin services). > > I strongly disagree! Having things on a website instead of in > the actual mail I'm reading and possibly responding to sucks. > It's one more step I have to do to actually look at the code > or whatever is causing the problem, it distrupts the flow of > reading and understanding the mail, and I have to be able to > actually access the website at the moment I'm reading the > mail. The biggest problem I have with it is the websites expire much faster than email does, so this information often gets lost later. In any case, generally we at Puppet Labs encourage people to post these details to the list for ease of developer interaction – and because you folks out there in the community are so good at spotting the problems from them! If your data is really huge, to the point that it isn't reasonable, we are happy to work without, but would usually ask for excerpts first – we don't want to download a gigabyte for a one line issue either. :) Regards, Daniel -- ✉ Daniel Pittman ⌨ dan...@rimspace.net (XMPP) ☎ +1 503 893 2285 ♻ made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-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, mongrel and apache
On Wed, Jan 12, 2011 at 14:13, Jake - USPS wrote: > I'm trying to setup my puppetmaster to use apache/mongrel. I've > followed the guide at > http://projects.puppetlabs.com/projects/1/wiki/Using_Mongrel > for doing this. > > My puppetmaster starts fine. When I have a client hit the > puppetmaster I get the following. > > From master: > err: uninitialized constant Mongrel::Const::REQUEST_PATH Hrm. Can you tell us which version of Mongrel you have on that machine? To my eye that looks like something isn't correctly loading, and I wonder if it is because we have not specified a sufficiently recent version of Mongrel; they changed that way back in time, so older versions didn't have that contstant... > Did I mis-configure something, and if so can someone help point me in > the correct direction? I don't think this is your fault, and it really doesn't look like something your configuration could have caused. :) Regards, Daniel -- ✉ Daniel Pittman ⌨ dan...@rimspace.net (XMPP) ☎ +1 503 893 2285 ♻ made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-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] Using Puppet to create a banner when logging in a server
On Wed, Jan 12, 2011 at 14:33, Gary Law wrote: > On 12 January 2011 19:08, Zman112233 wrote: > >> I'd like to create a banner for anyone logging into a list of servers >> to see (i.e. Unauthorized access prohibited, you're being watched, >> etc...). > > I have a "prettymotd" module. The init.pp reads: [...] So, Gary had that pretty much nailed down, but a few bits I would add as pointers you can ask to expand or read up on yourself: You should put this in a module, so that it is nicely self-contained, and include the appropriate class in your nodes. For a single task like this that isn't going to be much different to doing it without, but it makes good practice for doing modules when you get to the jobs that *do* benefit from them. If you were looking to base it of the existing issue files then I would take the view that you should copy them into your module, modify them as required, and then go on. Regards, Daniel -- ✉ Daniel Pittman ⌨ dan...@rimspace.net (XMPP) ☎ +1 503 893 2285 ♻ made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-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: error when require is used within a parameterized class
Hey there. Thanks for this detailed problem report, and especially for the manifest that reproduces the problem. I will make sure we generate a test case for this tomorrow so that we don't lose track of it. I can't promise a specific timeframe for fixing it, but that test will make sure that does happen, and that we don't regress on this case afterwards. Thanks for your patience, Daniel On Wed, Jan 12, 2011 at 14:35, bobics wrote: > I forgot to mention, the other annoying issue is that the error > message points to the file and line number of the parameterized class > declaration, NOT the require statement. Enabling verbose/debug output > doesn't help in finding the offending require statement. I basically > had to figure out for myself where the error was. > > On Jan 12, 2:11 pm, bobics wrote: >> I have the following use case, which I think is a very valid use case, >> but puppet is throwing an error. Puppet's implementation of how >> parameterized classes work with include/require breaks the >> *declarative* nature of Puppet. I believe this is the same bug as: >> >> http://projects.puppetlabs.com/issues/5046 >> >> It seems there is a lot of discussion in that ticket, and IMO this use >> case should be supported. >> >> # this works fine >> node default { >> class { ruby: version => "1.8" } >> class { rails: version => "3.0" } >> >> } >> >> # this throws an error "Must pass version to Class[Ruby] at ... >> site.pp:13" >> node baderror { >> class { rails: version => "3.0" } >> class { ruby: version => "1.8" } >> >> } >> >> class ruby ($version) { # line 13 >> >> } >> >> class rails ($version) { >> require ruby >> >> } >> >> The reason I ran into this bug now is because I'm also using class >> inheritance (for simplicity, I have not shown this in my example >> above). > > -- > 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. > > -- ✉ Daniel Pittman ⌨ dan...@rimspace.net (XMPP) ☎ +1 503 893 2285 ♻ made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-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: Could not retrieve catalog from remote server
Thanks a lot. I setup and fired up httpd/passenger if I don't post again on this thread, it means it fixed it :) On Wed, Jan 12, 2011 at 4:39 PM, Denmat wrote: > I get it too. It's not related to the compilation of the modules but I figure > it's possibly related to the webrick server. I don't see it on my > passenger/apache set up(which I run on another master). > > For what it is worth this is good reading for checking the validity of of > your modules before you test on hosts (--parseonly). > http://www.devco.net/archives/2009/08/19/tips_and_tricks_for_puppet_debugging.php > > For your actual issue, I ignore it. > > Cheers > Den > On 13/01/2011, at 4:23, Mohamed Lrhazi wrote: > >> I get this very often... I only have a 4 or 5 hosts setup right now... >> with version 2.6.3 everywhere. >> Sometimes I run "puppetd --verbose --onetime --no-daemonize", get the >> error, then run again and not get it. >> Sometimes I run it dozens of times in a row and get it all the >> time it's driving me crazy... is this related to my >> modules/classes themselves? am in the middle of developing them, so >> sometimes I think its happening because of mistakes in the actual >> source of my configs could it be? >> >> Mohamed. >> >> On Wed, Jan 12, 2011 at 5:35 AM, Sven Sporer wrote: >>> I sometimes get the same error on puppet 2.6.4 and don't know the >>> cause. Restarting the agent helps, but I would welcome a solution to >>> this. >>> >>> On Jan 12, 1:25 am, Mohamed Lrhazi wrote: What does this error mean or what does it indicate? puppet-agent: Could not retrieve catalog from remote server: Could not intern from pson: source did not contain any PSON! What can I try to resolve it? uninstall/reinstall puppet on the client? I found a bug report, but not much info in it:http://projects.puppetlabs.com/issues/5547 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. >>> >>> >> >> >> >> -- >> يوم نلقاك يوم فرحي و هنايا >> >> -- >> 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. > > -- يوم نلقاك يوم فرحي و هنايا -- 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] Send Reports to Puppet Dashboard
On Jan 12, 2011 2:02 PM, "Patrick" wrote: > On Jan 12, 2011, at 11:37 AM, wrote: >> I have already done the setup which you mention below. I followed the puppet-dashboard configuration guide to the tee, >> which is why I’m surprised that this feature is not working. I have verified that the puppet.conf entries on the client and >> master are correct. I’m wondering if this problem is a bug? Thanks for your help. Well, I can assure you that HTTP reports going in to dashboard *can* work, so while I can't rule out a bug it isn't as gross as never working at all. > At this point, I don't think you're going to get much help unless you post a lot more from your puppet.conf files. For instance, we should be seeing section names. At this point, you're saying you did everything right, but evidently something isn't right so that doesn't help us much. This is pretty much on the money. Can you post the config bits and the logs from master and dashboard so we can see what they have to say about it? Specifically, logs from an agent sending back the report to the master and all. :) Regards, 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.
[Puppet Users] Re: change from notrun to 0 failed: returned 1 instead of 0
On Wed, Jan 12, 2011 at 3:56 PM, Asif Iqbal wrote: > # cat iddmi.pp > > class iddmi { > # define pkg variable > $pkg = $hardwareisa ? { > "sparc" => "Iddmi_SunOS_sparc.pkg", > "i386" => "Iddmi_SunOS_i386.pkg", > default => undef, > } > $ftpsystems = "ftp.example.net/download" > > # define path deafult for exec > Exec { path => > "/usr/bin:/usr/sbin:/bin:/usr/local/bin:/usr/local/sbin", > cwd => "/tmp", > } > > case $operatingsystem { > "Solaris": { > exec { "HP_Disc_Agnt_Prep": > command => "wget -O $pkg ftp://$ftpsystems/$pkg; wget > -O default ftp://$ftpsystems/default";, > unless => [ "test -f $pkg", "test -f default" ], > before => Exec["HP_Disc_Agnt_Install"], > } > exec { "HP_Disc_Agnt_Install": > command => "pkgadd -a default -d $pkg Iddmi", > unless => "pkginfo Iddmi", > require => Exec["HP_Disc_Agnt_Prep"], > } > } > default: { } > } > } > > include iddmi > > > # puppet -d iddmi.pp > > debug: Exec[HP_Disc_Agnt_Install]: Adding default for cwd > debug: Exec[HP_Disc_Agnt_Install]: Adding default for path > debug: Exec[HP_Disc_Agnt_Prep]: Adding default for cwd > debug: Exec[HP_Disc_Agnt_Prep]: Adding default for path > debug: Creating default schedules > debug: Loaded state in 0.62 seconds > debug: //iddmi/Exec[HP_Disc_Agnt_Install]/require: requires > Exec[HP_Disc_Agnt_Prep] > debug: //iddmi/Exec[HP_Disc_Agnt_Prep]/before: requires > Exec[HP_Disc_Agnt_Install] > debug: Failed to load library 'shadow' for feature 'libshadow' > debug: //iddmi/Exec[HP_Disc_Agnt_Prep]: Executing check 'test -f > Iddmi_SunOS_sparc.pkg' > debug: Executing 'test -f Iddmi_SunOS_sparc.pkg' > debug: //iddmi/Exec[HP_Disc_Agnt_Install]: Executing check 'pkginfo Iddmi' > debug: Executing 'pkginfo Iddmi' > debug: //iddmi/Exec[HP_Disc_Agnt_Install]: Changing returns > debug: //iddmi/Exec[HP_Disc_Agnt_Install]: 1 change(s) > debug: //iddmi/Exec[HP_Disc_Agnt_Install]: Executing 'pkgadd -a > default -d Iddmi_SunOS_sparc.pkg Iddmi' > debug: Executing 'pkgadd -a default -d Iddmi_SunOS_sparc.pkg Iddmi' > err: //iddmi/Exec[HP_Disc_Agnt_Install]/returns: change from notrun to > 0 failed: pkgadd -a default -d Iddmi_SunOS_sparc.pkg Iddmi returned 1 > instead of 0 at /opt/home/iqbala/iddmi.pp:26 > debug: Finishing transaction 8296656 with 1 changes > debug: Storing state > debug: Stored state in 4.72 seconds > debug: Calling puppetreports.report I had a permission issue with /tmp which is defined as cwd. It is working now > > > puppet client is 0.24.7 and puppet server is 2.6.1 > > -- > Asif Iqbal > PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > -- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Puppetmaster 2.6.x on Ubuntu Lucid
Well, your instructions also can work for upgrading puppet with a few small changes. Might even work without changes. On Jan 12, 2011, at 2:54 PM, Luc Suryo wrote: > that would be a catch 22 :) > > the instruction was an answer to how to install puppet on a Lucid > server, there is no puppet installed yet! > > So how will one automate 'with' puppet while puppet is not installed? -- 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] puppetmaster immediately disconnects
Hello, I'm running 0.25.4 on Ubuntu 10.04 LTS. Recently when I start puppetmaster the 8140 port opens but if any client machine connects to it (ie telnet localhost 8140), the connection immediately dies. Network wise I see a syn, syn-ack, ack then a fin-ack in both directions and then a final ack. It sounds like something accepts the connection and immediately disconnects. There's no time to present a cert or anything. I cannot find any system level problems so I'm wondering if it's a known problem or a configuration problem of mine? Machines eventually can connect in, but I don't understand how. Thanks, Jason -- 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: Puppetmaster 2.6.x on Ubuntu Lucid
that would be a catch 22 :) the instruction was an answer to how to install puppet on a Lucid server, there is no puppet installed yet! So how will one automate 'with' puppet while puppet is not installed? On Jan 12, 10:49 am, Patrick wrote: > Except that, knowing this list, someone will automate it with puppet. > > On Jan 12, 2011, at 8:14 AM, Luc Suryo wrote: > > > these are manual step to be taken so one can install puppet from the > > backport repo > > so not sure what you ref. too ? the order of step 1, 2 and 3 does not > > matter but need to be done before 4 (apt-get update) > > > On Jan 11, 2:25 pm, Patrick wrote: > >> On Jan 11, 2011, at 8:52 AM, Luc Suryo wrote: > > >>> 1. in file /etc/apt/preferences I made several adjustment but for > >>> puppet this is the relevant lines > > >>> # Backport for puppetlabs > >>> Package: puppet puppet-common puppetmaster facter > >>> Pin: release a=lenny-backports > >>> Pin-Priority: 900 > > >>> 2. then created the /etc/apt/sources.list.d/backports.list with the > >>> following line > > >>> debhttp://backports.debian.org/debian-backportslenny-backportsmain > >>> contrib non-free > > >> You said this, but I want to make this very clear. > > >> If you're using puppet to deploy this, "Make sure that step 2 will not > >> happen until step 1 is complete". Remember, it's possible for file copies > >> to fail if the server is overloaded or if you just have bad luck. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Puppet Users" group. > > To post to this group, send email to puppet-us...@googlegroups.com. > > To unsubscribe from this group, send email to > > puppet-users+unsubscr...@googlegroups.com. > > For more options, visit this group > > athttp://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: error when require is used within a parameterized class
I forgot to mention, the other annoying issue is that the error message points to the file and line number of the parameterized class declaration, NOT the require statement. Enabling verbose/debug output doesn't help in finding the offending require statement. I basically had to figure out for myself where the error was. On Jan 12, 2:11 pm, bobics wrote: > I have the following use case, which I think is a very valid use case, > but puppet is throwing an error. Puppet's implementation of how > parameterized classes work with include/require breaks the > *declarative* nature of Puppet. I believe this is the same bug as: > > http://projects.puppetlabs.com/issues/5046 > > It seems there is a lot of discussion in that ticket, and IMO this use > case should be supported. > > # this works fine > node default { > class { ruby: version => "1.8" } > class { rails: version => "3.0" } > > } > > # this throws an error "Must pass version to Class[Ruby] at ... > site.pp:13" > node baderror { > class { rails: version => "3.0" } > class { ruby: version => "1.8" } > > } > > class ruby ($version) { # line 13 > > } > > class rails ($version) { > require ruby > > } > > The reason I ran into this bug now is because I'm also using class > inheritance (for simplicity, I have not shown this in my example > above). -- 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] Using Puppet to create a banner when logging in a server
On 12 January 2011 19:08, Zman112233 wrote: > I'd like to create a banner for anyone logging into a list of servers > to see (i.e. Unauthorized access prohibited, you're being watched, > etc...). I have a "prettymotd" module. The init.pp reads: class prettymotd { file { "/etc/motd": content => template("prettymotd/motd.erb"), ensure => present } } and the motd.erb is:- hostname: <%= fqdn %> type: <%= operatingsystem %> <%= operatingsystemrelease %> <%= kernelversion %> <%= kernel %> hardware: <%= hardwaremodel %> HTH Gary -- Gary Law Email/Chat googletalk/messenger: gary@gmail.com -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] puppet, mongrel and apache
I'm trying to setup my puppetmaster to use apache/mongrel. I've followed the guide at http://projects.puppetlabs.com/projects/1/wiki/Using_Mongrel for doing this. My puppetmaster starts fine. When I have a client hit the puppetmaster I get the following. >From master: err: uninitialized constant Mongrel::Const::REQUEST_PATH >From client: info: Retrieving plugin err: /File[/var/lib/puppet/lib]: Failed to generate additional resources using 'eval_generate': Error 400 on SERVER: uninitialized constant Mongrel::Const::REQUEST_PATH err: /File[/var/lib/puppet/lib]: Could not evaluate: Error 400 on SERVER: uninitialized constant Mongrel::Const::REQUEST_PATH Could not retrieve file metadata for puppet://puppet/plugins: Error 400 on SERVER: uninitialized constant Mongrel::Const::REQUEST_PATH info: Loading facts in hcs_service info: Loading facts in memorysize info: Loading facts in os_version info: Loading facts in hcs_service info: Loading facts in memorysize info: Loading facts in os_version err: Could not retrieve catalog from remote server: Error 400 on SERVER: uninitialized constant Mongrel::Const::REQUEST_PATH warning: Not using cache on failed catalog err: Could not retrieve catalog; skipping run Did I mis-configure something, and if so can someone help point me in the correct direction? This is on a SLES10 SP3 server/client systems. I compiled puppet 2.6.4 from source using SLES provided packages to meet dependencies (ruby). Thanks, Jake -- 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] error when require is used within a parameterized class
I have the following use case, which I think is a very valid use case, but puppet is throwing an error. Puppet's implementation of how parameterized classes work with include/require breaks the *declarative* nature of Puppet. I believe this is the same bug as: http://projects.puppetlabs.com/issues/5046 It seems there is a lot of discussion in that ticket, and IMO this use case should be supported. # this works fine node default { class { ruby: version => "1.8" } class { rails: version => "3.0" } } # this throws an error "Must pass version to Class[Ruby] at ... site.pp:13" node baderror { class { rails: version => "3.0" } class { ruby: version => "1.8" } } class ruby ($version) { # line 13 } class rails ($version) { require ruby } The reason I ran into this bug now is because I'm also using class inheritance (for simplicity, I have not shown this in my example above). -- 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] Send Reports to Puppet Dashboard
On Jan 12, 2011, at 11:37 AM, wrote: > Hi Daniel, > > I have already done the setup which you mention below. I followed the > puppet-dashboard configuration guide to the tee, > which is why I’m surprised that this feature is not working. I have verified > that the puppet.conf entries on the client and > master are correct. I’m wondering if this problem is a bug? Thanks for your > help. At this point, I don't think you're going to get much help unless you post a lot more from your puppet.conf files. For instance, we should be seeing section names. At this point, you're saying you did everything right, but evidently something isn't right so that doesn't help us much. -- 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: Could not retrieve catalog from remote server
I get it too. It's not related to the compilation of the modules but I figure it's possibly related to the webrick server. I don't see it on my passenger/apache set up(which I run on another master). For what it is worth this is good reading for checking the validity of of your modules before you test on hosts (--parseonly). http://www.devco.net/archives/2009/08/19/tips_and_tricks_for_puppet_debugging.php For your actual issue, I ignore it. Cheers Den On 13/01/2011, at 4:23, Mohamed Lrhazi wrote: > I get this very often... I only have a 4 or 5 hosts setup right now... > with version 2.6.3 everywhere. > Sometimes I run "puppetd --verbose --onetime --no-daemonize", get the > error, then run again and not get it. > Sometimes I run it dozens of times in a row and get it all the > time it's driving me crazy... is this related to my > modules/classes themselves? am in the middle of developing them, so > sometimes I think its happening because of mistakes in the actual > source of my configs could it be? > > Mohamed. > > On Wed, Jan 12, 2011 at 5:35 AM, Sven Sporer wrote: >> I sometimes get the same error on puppet 2.6.4 and don't know the >> cause. Restarting the agent helps, but I would welcome a solution to >> this. >> >> On Jan 12, 1:25 am, Mohamed Lrhazi wrote: >>> What does this error mean or what does it indicate? >>> >>> puppet-agent: Could not retrieve catalog from remote server: Could >>> not intern from pson: source did not contain any PSON! >>> >>> What can I try to resolve it? uninstall/reinstall puppet on the client? >>> >>> I found a bug report, but not much info in >>> it:http://projects.puppetlabs.com/issues/5547 >>> >>> 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-us...@googlegroups.com. >> To unsubscribe from this group, send email to >> puppet-users+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en. >> >> > > > > -- > يوم نلقاك يوم فرحي و هنايا > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-us...@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Using Puppet to create a banner when logging in a server
Hello everyone, I'm new to the Puppet world and I was looking for a little beginning help... I'd like to create a banner for anyone logging into a list of servers to see (i.e. Unauthorized access prohibited, you're being watched, etc...). I'd like to base it off the /etc/issue and /etc/issue.net files. I thought it might be easier if I had an example to work though as I'm learning Puppet. Any suggestions? -- 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] Silence reports for one specific resource?
hey, - Original Message - > Thanks you so much Bellman, the loglevel seems to be missing corner > stone :) This is great, I never know the loglevel meta param did this. Updated the mcollective wiki to reflect this :) > > Mohamed. > > On Wed, Jan 12, 2011 at 2:16 PM, Thomas Bellman > wrote: > > Mohamed Lrhazi wrote: > > > >> Thanks a lot guys... but how do I do this, both silencing reporting > >> and overriding noop mode, for a resource other than "exec"... mine > >> is: > >> > >> file { > >> "/etc/puppet/facts.yaml": > >> ensure => file, > >> content => inline_template("<%= scope.to_hash.reject { |k,v| > >> !( > >> k.is_a?(String) && v.is_a?(String) ) }.to_yaml %>"), > >> } > > > > There is a metaparameter called 'loglevel'. If you set that > > to something lower than "notice" (i.e. either "info" or "debug"), > > then Puppet won't report that it applied the resource: > > > > file { > > "/etc/puppet/facts.yaml": > > ..., > > loglevel => debug, noop => false; > > } > > > > > > Myself, I do somewhat the opposite: I also run Puppet from cron, > > but not in noop mode. Since I'm not interrested in getting dozens > > or hundreds of mails every time I make a configuration change, I > > filter away all the notice messages, with a simple grep: > > > > puppetd ... | egrep -v '^notice:' > > > > However, on one resources I set 'loglevel => warning', so I get > > a warning message whenever Puppet fixes that particular resource, > > because when that situation happens I want to check manually that > > it was the correct action to take. (Specifically, in grub.conf > > I set the parameter 'default' to 0 so it will always default to > > boot the first kernel. I do this since I have sometimes found > > that after installing a new kernel, grub.conf still defaulted to > > boot the old kernel. But I don't yet quite trust that setting > > default=0 will always be the right thing.) > > > > > > /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. > > > > > > > > -- > يوم نلقاك يوم فرحي و هنايا > > -- > 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. -- 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] Re: Could not retrieve catalog from remote server
Thanks Patrick. I see no clues at all: $sudo /opt/ruby-enterprise/bin/ruby /opt/ruby-enterprise/bin/puppet master --no-daemonize --debug --verbose --trace ... notice: Starting Puppet master version 2.6.3 ... info: Expiring the node cache of akubra.example.com info: Not using expired node for akubra.example.com from cache; expired at Wed Jan 12 15:35:15 -0500 2011 debug: Using cached facts for akubra.example.com info: Caching node for akubra.example.com debug: template[inline]: Bound template variables for inline template in 0.00 seconds debug: template[inline]: Interpolated template inline template in 0.00 seconds notice: Compiled catalog for akubra.example.com in environment testing in 0.12 seconds info: Caching catalog for akubra.example.com debug: Searched for resources in 0.00 seconds debug: Searched for resource params and tags in 0.01 seconds debug: Resource removal in 0.00 seconds debug: Resource merger in 0.05 seconds debug: Resource addition in 0.00 seconds debug: Performed resource comparison in 0.05 seconds debug: Using cached node for akubra.example.com debug: Saved catalog to database in 0.07 seconds err: //akubra.example.com/Puppet: Could not retrieve catalog from remote server: Could not intern from pson: source did not contain any PSON! notice: //akubra.example.com/Puppet: Using cached catalog info: //akubra.example.com/Puppet: Applying configuration version '1294864403' Thanks, Mohamed. On Wed, Jan 12, 2011 at 1:48 PM, Patrick wrote: > Are you using Passenger? If you don't know, the answer is probably no. If > not, do this: > > Shutdown your puppet server. This might work: > service puppetmaster stop > > Start it in debug: > puppetmasterd --verbose --debug --no-daemonize --trace > > Then watch the output on the console for hints while running the clients > against it. > > > On Jan 12, 2011, at 9:23 AM, Mohamed Lrhazi wrote: > >> I get this very often... I only have a 4 or 5 hosts setup right now... >> with version 2.6.3 everywhere. >> Sometimes I run "puppetd --verbose --onetime --no-daemonize", get the >> error, then run again and not get it. >> Sometimes I run it dozens of times in a row and get it all the >> time it's driving me crazy... is this related to my >> modules/classes themselves? am in the middle of developing them, so >> sometimes I think its happening because of mistakes in the actual >> source of my configs could it be? >> >> Mohamed. >> >> On Wed, Jan 12, 2011 at 5:35 AM, Sven Sporer wrote: >>> I sometimes get the same error on puppet 2.6.4 and don't know the >>> cause. Restarting the agent helps, but I would welcome a solution to >>> this. >>> >>> On Jan 12, 1:25 am, Mohamed Lrhazi wrote: What does this error mean or what does it indicate? puppet-agent: Could not retrieve catalog from remote server: Could not intern from pson: source did not contain any PSON! What can I try to resolve it? uninstall/reinstall puppet on the client? I found a bug report, but not much info in it:http://projects.puppetlabs.com/issues/5547 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-us...@googlegroups.com. >>> To unsubscribe from this group, send email to >>> puppet-users+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/puppet-users?hl=en. >>> >>> >> >> >> >> -- >> يوم نلقاك يوم فرحي و هنايا >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To post to this group, send email to puppet-us...@googlegroups.com. >> To unsubscribe from this group, send email to >> puppet-users+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-us...@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > > -- 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] change from notrun to 0 failed: returned 1 instead of 0
# cat iddmi.pp class iddmi { # define pkg variable $pkg = $hardwareisa ? { "sparc" => "Iddmi_SunOS_sparc.pkg", "i386" => "Iddmi_SunOS_i386.pkg", default => undef, } $ftpsystems = "ftp.example.net/download" # define path deafult for exec Exec { path => "/usr/bin:/usr/sbin:/bin:/usr/local/bin:/usr/local/sbin", cwd => "/tmp", } case $operatingsystem { "Solaris": { exec { "HP_Disc_Agnt_Prep": command => "wget -O $pkg ftp://$ftpsystems/$pkg; wget -O default ftp://$ftpsystems/default";, unless => [ "test -f $pkg", "test -f default" ], before => Exec["HP_Disc_Agnt_Install"], } exec { "HP_Disc_Agnt_Install": command => "pkgadd -a default -d $pkg Iddmi", unless => "pkginfo Iddmi", require => Exec["HP_Disc_Agnt_Prep"], } } default: { } } } include iddmi # puppet -d iddmi.pp debug: Exec[HP_Disc_Agnt_Install]: Adding default for cwd debug: Exec[HP_Disc_Agnt_Install]: Adding default for path debug: Exec[HP_Disc_Agnt_Prep]: Adding default for cwd debug: Exec[HP_Disc_Agnt_Prep]: Adding default for path debug: Creating default schedules debug: Loaded state in 0.62 seconds debug: //iddmi/Exec[HP_Disc_Agnt_Install]/require: requires Exec[HP_Disc_Agnt_Prep] debug: //iddmi/Exec[HP_Disc_Agnt_Prep]/before: requires Exec[HP_Disc_Agnt_Install] debug: Failed to load library 'shadow' for feature 'libshadow' debug: //iddmi/Exec[HP_Disc_Agnt_Prep]: Executing check 'test -f Iddmi_SunOS_sparc.pkg' debug: Executing 'test -f Iddmi_SunOS_sparc.pkg' debug: //iddmi/Exec[HP_Disc_Agnt_Install]: Executing check 'pkginfo Iddmi' debug: Executing 'pkginfo Iddmi' debug: //iddmi/Exec[HP_Disc_Agnt_Install]: Changing returns debug: //iddmi/Exec[HP_Disc_Agnt_Install]: 1 change(s) debug: //iddmi/Exec[HP_Disc_Agnt_Install]: Executing 'pkgadd -a default -d Iddmi_SunOS_sparc.pkg Iddmi' debug: Executing 'pkgadd -a default -d Iddmi_SunOS_sparc.pkg Iddmi' err: //iddmi/Exec[HP_Disc_Agnt_Install]/returns: change from notrun to 0 failed: pkgadd -a default -d Iddmi_SunOS_sparc.pkg Iddmi returned 1 instead of 0 at /opt/home/iqbala/iddmi.pp:26 debug: Finishing transaction 8296656 with 1 changes debug: Storing state debug: Stored state in 4.72 seconds debug: Calling puppetreports.report puppet client is 0.24.7 and puppet server is 2.6.1 -- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Problem loading custom modules
Felix Frank wrote: That's why I originally asked for pastes of configs, manifests *and* filesystem listings (not to the list preferably, use pastebin services). I strongly disagree! Having things on a website instead of in the actual mail I'm reading and possibly responding to sucks. It's one more step I have to do to actually look at the code or whatever is causing the problem, it distrupts the flow of reading and understanding the mail, and I have to be able to actually access the website at the moment I'm reading the mail. So please *do* post such things directly to the list. /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] Silence reports for one specific resource?
Thanks you so much Bellman, the loglevel seems to be missing corner stone :) Mohamed. On Wed, Jan 12, 2011 at 2:16 PM, Thomas Bellman wrote: > Mohamed Lrhazi wrote: > >> Thanks a lot guys... but how do I do this, both silencing reporting >> and overriding noop mode, for a resource other than "exec"... mine is: >> >> file { >> "/etc/puppet/facts.yaml": >> ensure => file, >> content => inline_template("<%= scope.to_hash.reject { |k,v| !( >> k.is_a?(String) && v.is_a?(String) ) }.to_yaml %>"), >> } > > There is a metaparameter called 'loglevel'. If you set that > to something lower than "notice" (i.e. either "info" or "debug"), > then Puppet won't report that it applied the resource: > > file { > "/etc/puppet/facts.yaml": > ..., > loglevel => debug, noop => false; > } > > > Myself, I do somewhat the opposite: I also run Puppet from cron, > but not in noop mode. Since I'm not interrested in getting dozens > or hundreds of mails every time I make a configuration change, I > filter away all the notice messages, with a simple grep: > > puppetd ... | egrep -v '^notice:' > > However, on one resources I set 'loglevel => warning', so I get > a warning message whenever Puppet fixes that particular resource, > because when that situation happens I want to check manually that > it was the correct action to take. (Specifically, in grub.conf > I set the parameter 'default' to 0 so it will always default to > boot the first kernel. I do this since I have sometimes found > that after installing a new kernel, grub.conf still defaulted to > boot the old kernel. But I don't yet quite trust that setting > default=0 will always be the right thing.) > > > /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. > > -- يوم نلقاك يوم فرحي و هنايا -- 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: RE: [Puppet Users] Send Reports to Puppet Dashboard
Hi Daniel, I have already done the setup which you mention below. I followed the puppet-dashboard configuration guide to the tee, which is why I'm surprised that this feature is not working. I have verified that the puppet.conf entries on the client and master are correct. I'm wondering if this problem is a bug? Thanks for your help. Mike From: puppet-users@googlegroups.com [mailto:puppet-us...@googlegroups.com] On Behalf Of Daniel Pittman Sent: Wednesday, January 12, 2011 12:26 PM To: puppet-users@googlegroups.com Subject: Re: RE: [Puppet Users] Send Reports to Puppet Dashboard Hey. You need to do two things, both of which should be in the install instructions - so please file a bug if they are not, or are unclear. The first is to turn on the report option on your clients so they send data to the master. (Kiterally, report=true in the agent config) The second is to set "reporturl" to "http://dashboard.url:3000/reports";, and "reports=http" in the master config. Regards, Daniel On Jan 12, 2011 6:09 AM, wrote: -- 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. _ PLEASE NOTE: Florida has a very broad public records law (F. S. 119). All e-mails to and from County Officials are kept as a public record. Your e-mail communications, including your e-mail address may be disclosed to the public and media at any time. -- 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] Silence reports for one specific resource?
Mohamed Lrhazi wrote: Thanks a lot guys... but how do I do this, both silencing reporting and overriding noop mode, for a resource other than "exec"... mine is: file { "/etc/puppet/facts.yaml": ensure => file, content => inline_template("<%= scope.to_hash.reject { |k,v| !( k.is_a?(String) && v.is_a?(String) ) }.to_yaml %>"), } There is a metaparameter called 'loglevel'. If you set that to something lower than "notice" (i.e. either "info" or "debug"), then Puppet won't report that it applied the resource: file { "/etc/puppet/facts.yaml": ..., loglevel => debug, noop => false; } Myself, I do somewhat the opposite: I also run Puppet from cron, but not in noop mode. Since I'm not interrested in getting dozens or hundreds of mails every time I make a configuration change, I filter away all the notice messages, with a simple grep: puppetd ... | egrep -v '^notice:' However, on one resources I set 'loglevel => warning', so I get a warning message whenever Puppet fixes that particular resource, because when that situation happens I want to check manually that it was the correct action to take. (Specifically, in grub.conf I set the parameter 'default' to 0 so it will always default to boot the first kernel. I do this since I have sometimes found that after installing a new kernel, grub.conf still defaulted to boot the old kernel. But I don't yet quite trust that setting default=0 will always be the right thing.) /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] Re: Puppetmaster 2.6.x on Ubuntu Lucid
Except that, knowing this list, someone will automate it with puppet. On Jan 12, 2011, at 8:14 AM, Luc Suryo wrote: > these are manual step to be taken so one can install puppet from the > backport repo > so not sure what you ref. too ? the order of step 1, 2 and 3 does not > matter but need to be done before 4 (apt-get update) > > > On Jan 11, 2:25 pm, Patrick wrote: >> On Jan 11, 2011, at 8:52 AM, Luc Suryo wrote: >> >>> 1. in file /etc/apt/preferences I made several adjustment but for >>> puppet this is the relevant lines >> >>> # Backport for puppetlabs >>> Package: puppet puppet-common puppetmaster facter >>> Pin: release a=lenny-backports >>> Pin-Priority: 900 >> >>> 2. then created the /etc/apt/sources.list.d/backports.list with the >>> following line >> >>> debhttp://backports.debian.org/debian-backportslenny-backports main >>> contrib non-free >> >> You said this, but I want to make this very clear. >> >> If you're using puppet to deploy this, "Make sure that step 2 will not >> happen until step 1 is complete". Remember, it's possible for file copies >> to fail if the server is overloaded or if you just have bad luck. > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-us...@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Could not retrieve catalog from remote server
Are you using Passenger? If you don't know, the answer is probably no. If not, do this: Shutdown your puppet server. This might work: service puppetmaster stop Start it in debug: puppetmasterd --verbose --debug --no-daemonize --trace Then watch the output on the console for hints while running the clients against it. On Jan 12, 2011, at 9:23 AM, Mohamed Lrhazi wrote: > I get this very often... I only have a 4 or 5 hosts setup right now... > with version 2.6.3 everywhere. > Sometimes I run "puppetd --verbose --onetime --no-daemonize", get the > error, then run again and not get it. > Sometimes I run it dozens of times in a row and get it all the > time it's driving me crazy... is this related to my > modules/classes themselves? am in the middle of developing them, so > sometimes I think its happening because of mistakes in the actual > source of my configs could it be? > > Mohamed. > > On Wed, Jan 12, 2011 at 5:35 AM, Sven Sporer wrote: >> I sometimes get the same error on puppet 2.6.4 and don't know the >> cause. Restarting the agent helps, but I would welcome a solution to >> this. >> >> On Jan 12, 1:25 am, Mohamed Lrhazi wrote: >>> What does this error mean or what does it indicate? >>> >>> puppet-agent: Could not retrieve catalog from remote server: Could >>> not intern from pson: source did not contain any PSON! >>> >>> What can I try to resolve it? uninstall/reinstall puppet on the client? >>> >>> I found a bug report, but not much info in >>> it:http://projects.puppetlabs.com/issues/5547 >>> >>> 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-us...@googlegroups.com. >> To unsubscribe from this group, send email to >> puppet-users+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en. >> >> > > > > -- > يوم نلقاك يوم فرحي و هنايا > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-us...@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: RE: [Puppet Users] Send Reports to Puppet Dashboard
Hey. You need to do two things, both of which should be in the install instructions - so please file a bug if they are not, or are unclear. The first is to turn on the report option on your clients so they send data to the master. (Kiterally, report=true in the agent config) The second is to set "reporturl" to "http://dashboard.url:3000/reports";, and "reports=http" in the master config. Regards, Daniel On Jan 12, 2011 6:09 AM, wrote: -- 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: Could not retrieve catalog from remote server
I get this very often... I only have a 4 or 5 hosts setup right now... with version 2.6.3 everywhere. Sometimes I run "puppetd --verbose --onetime --no-daemonize", get the error, then run again and not get it. Sometimes I run it dozens of times in a row and get it all the time it's driving me crazy... is this related to my modules/classes themselves? am in the middle of developing them, so sometimes I think its happening because of mistakes in the actual source of my configs could it be? Mohamed. On Wed, Jan 12, 2011 at 5:35 AM, Sven Sporer wrote: > I sometimes get the same error on puppet 2.6.4 and don't know the > cause. Restarting the agent helps, but I would welcome a solution to > this. > > On Jan 12, 1:25 am, Mohamed Lrhazi wrote: >> What does this error mean or what does it indicate? >> >> puppet-agent: Could not retrieve catalog from remote server: Could >> not intern from pson: source did not contain any PSON! >> >> What can I try to resolve it? uninstall/reinstall puppet on the client? >> >> I found a bug report, but not much info in >> it:http://projects.puppetlabs.com/issues/5547 >> >> 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-us...@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > > -- يوم نلقاك يوم فرحي و هنايا -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Puppetmaster 2.6.x on Ubuntu Lucid
these are manual step to be taken so one can install puppet from the backport repo so not sure what you ref. too ? the order of step 1, 2 and 3 does not matter but need to be done before 4 (apt-get update) On Jan 11, 2:25 pm, Patrick wrote: > On Jan 11, 2011, at 8:52 AM, Luc Suryo wrote: > > > 1. in file /etc/apt/preferences I made several adjustment but for > > puppet this is the relevant lines > > > # Backport for puppetlabs > > Package: puppet puppet-common puppetmaster facter > > Pin: release a=lenny-backports > > Pin-Priority: 900 > > > 2. then created the /etc/apt/sources.list.d/backports.list with the > > following line > > > debhttp://backports.debian.org/debian-backportslenny-backports main > > contrib non-free > > You said this, but I want to make this very clear. > > If you're using puppet to deploy this, "Make sure that step 2 will not happen > until step 1 is complete". Remember, it's possible for file copies to fail > if the server is overloaded or if you just have bad luck. -- 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: Best Practices/Style: add stuff to a file for each host?
On Tue, Jan 11, 2011 at 12:07:30PM -0800, Robin Lee Powell wrote: > On Tue, Jan 11, 2011 at 05:20:38AM -0800, Al @ Lab42 wrote: > > > > You can build a file based on different "fragments" at least in > > 2 ways: > > > > - When you specify an array of templates , when using the > > content => argument, these templates are actually appended in > > the defined order. > > Can you use exported resources to generate such an array? Anybody? I can see how to generate resources from lots of hosts and run it on one host, but I can't see how to generate a config file out of all of that information. -Robin -- http://singinst.org/ : Our last, best hope for a fantastic future. Lojban (http://www.lojban.org/): The language in which "this parrot is dead" is "ti poi spitaki cu morsi", but "this sentence is false" is "na nei". My personal page: http://www.digitalkingdom.org/rlp/ -- 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] Send Reports to Puppet Dashboard
Hello Patrick, I have the puppet-dashboard up and running and get the gui. What I am seeing there is that none of my clients(nodes) are reporting. When I click on nodes the dashboard lists all of my nodes but also states each has not reported. What I am trying to get working is that the puppet clients report to the dashboard. Thanks for the tips, and if you have another please send it to me. Mike -Original Message- From: puppet-users@googlegroups.com [mailto:puppet-us...@googlegroups.com] On Behalf Of Patrick Sent: Tuesday, January 11, 2011 5:20 PM To: puppet-users@googlegroups.com Subject: Re: [Puppet Users] Send Reports to Puppet Dashboard On Jan 11, 2011, at 12:13 PM, Mike wrote: > [main] > > node_terminus = exec > external_nodes = /etc/puppet/bin/external_node reports = http, store > reporturl = fedorahost.ocfl.net:3000/reports > > However, when I restart the puppet master daemon I get the errors > below. Has anyone seen this problem before, and if so, can you > possibly tell me how to fix it? When I comment out the entries I made > in [main], the puppet master and puppet clients work perfectly. I > believe that the connection refused and No route to host are spurious > messages and not truly indicative of the problem. Load up a webbrowser and point it to http://fedorahost.ocfl.net:3000/ . You should get a webpage. I'm guessing that you don't have Dashboard started. (Or possibly misconfigured) If Dashboard isn't started, your webbrowser will tell you "connection refused" or "webpage not found" or something similar. -- 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. _ PLEASE NOTE: Florida has a very broad public records law (F. S. 119). All e-mails to and from County Officials are kept as a public record. Your e-mail communications, including your e-mail address may be disclosed to the public and media at any time. -- 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: Dependency resolution for packages
On Jan 12, 7:09 am, Sven Sporer wrote: [...] > The initial problem still stands: why do I need a second run? What > changes in between for the client? Or should I blame it on this > version of yum? ;) > > Here's the log output:http://pastie.org/1452205 The log shows Puppet attempting to install Package[vim-data] and Package[vim-base] before it updates Package[vim]. It follows that resource dependencies are not being set up properly. Does anything change if you replace your current vim resource with this: package { "vim.x86_64": ensure => latest, require => Class["yum::repos"], before => [ Package["vim-enhanced.x86_64"], Package["vim- data.x86_64"] ] } ? John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Dependency resolution for packages
> > What do you mean by "the last"? Everything is installed as intended > > after the third run. Sometimes, even after the second run. > > That's what he means. Why this inconsistency? > > > So I'm not > > really sure what causes this inconsistency, but it has something to do > > with yum dependency resolution and the dependencies as defined in the > > manifest. > > Are you sure that all the machines were in precisely the same state > with regard to packages before the upgrades? 100% sure, as those runs are based on a snapshot on the same virtual machine. I reset to the snapshot after testing this, so the baseline is the same. You're right anyway, because I think that inconsistency is due to me updating the manifests and not restarting the puppet master. I can't reproduce the need for a third run now. The initial problem still stands: why do I need a second run? What changes in between for the client? Or should I blame it on this version of yum? ;) Here's the log output: http://pastie.org/1452205 -- 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 Clients requesting classes
Stig Sandbeck Mathisen writes: > , > | node *.desktops.example.org { > | case $server_role { > | /:desktop:/ { include my::desktop::class } > | /:mission_critical:/ { include corp::absolutely::vital:class } > | /:whohooo:/ { include rubber::ducky } > | } > | } > ` This should perhaps use a series of if tests instead, or you'll only get the classes from the first match. -- Stig Sandbeck Mathisen Oooo, shiny! -- 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: Dependency resolution for packages
On Wed, Jan 12, 2011 at 03:43:42AM -0800, Sven Sporer wrote: > > This makes no sense to me that the last doesn't always work. > > Someone might come up with an answer, but logs with "--verbose > > --debug" would probably help. Even if you sanitize it with "grep > > vim" it would probably help a lot. > > What do you mean by "the last"? Everything is installed as intended > after the third run. Sometimes, even after the second run. That's what he means. Why this inconsistency? > So I'm not > really sure what causes this inconsistency, but it has something to do > with yum dependency resolution and the dependencies as defined in the > manifest. Are you sure that all the machines were in precisely the same state with regard to packages before the upgrades? -- Bruce Get thee behind me, Stan: for it is written, thou hast gotten me into another fine mess. -- Oliver 4:8 -- 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: Dependency resolution for packages
On Jan 12, 12:27 pm, Patrick wrote: > On Jan 12, 2011, at 2:30 AM, Sven Sporer wrote: > > > > > > > > > > > Hi, I have a simple use case, but can't get the dependency resolution > > to work on first run. This is not critical, but I want to understand > > what's going on. Here's the szenario: > > > * puppet --version: 2.6.4 > > * on the bare system, I have vim 6.4 installed (no vim-base) > > * I first want to upgrade to the latest version in repo, which is 7.1, > > * and then install vim extensions for 7.1 (vim-enhanced, vim-data) > > > My definition: > > > class packages::vim { > > $addons = ["vim-enhanced.x86_64", "vim-data.x86_64"] > > > package { "vim.x86_64": > > ensure => latest, > > require => Class["yum::repos"], > > before => Package[$addons], > > } > > > package { $addons: > > ensure => present, > > } > > } > > > The agent complains that vim-base-7.1 is not compatible with the > > installed vim-6.4 (vim-base is needed for the addons). This would not > > be a problem if the vim would be updated to 7.1 "before". > > > (* I run puppet agent --test to see what happens on every run) > > * So, this fails on first run. > > * On second run, vim updates from 7.1 and installs $addons. > > * Sometimes, a third run is needed to install the $addons. > > This makes no sense to me that the last doesn't always work. Someone might > come up with an answer, but logs with "--verbose --debug" would probably > help. Even if you sanitize it with "grep vim" it would probably help a lot. What do you mean by "the last"? Everything is installed as intended after the third run. Sometimes, even after the second run. So I'm not really sure what causes this inconsistency, but it has something to do with yum dependency resolution and the dependencies as defined in the manifest. -- 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] Dependency resolution for packages
On Jan 12, 2011, at 2:30 AM, Sven Sporer wrote: > Hi, I have a simple use case, but can't get the dependency resolution > to work on first run. This is not critical, but I want to understand > what's going on. Here's the szenario: > > * puppet --version: 2.6.4 > * on the bare system, I have vim 6.4 installed (no vim-base) > * I first want to upgrade to the latest version in repo, which is 7.1, > * and then install vim extensions for 7.1 (vim-enhanced, vim-data) > > My definition: > > class packages::vim { > $addons = ["vim-enhanced.x86_64", "vim-data.x86_64"] > > package { "vim.x86_64": >ensure => latest, >require => Class["yum::repos"], >before => Package[$addons], > } > > package { $addons: >ensure => present, > } > } > > The agent complains that vim-base-7.1 is not compatible with the > installed vim-6.4 (vim-base is needed for the addons). This would not > be a problem if the vim would be updated to 7.1 "before". > > (* I run puppet agent --test to see what happens on every run) > * So, this fails on first run. > * On second run, vim updates from 7.1 and installs $addons. > * Sometimes, a third run is needed to install the $addons. This makes no sense to me that the last doesn't always work. Someone might come up with an answer, but logs with "--verbose --debug" would probably help. Even if you sanitize it with "grep vim" it would probably help a lot. -- 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] Dependency resolution for packages
On 01/12/2011 11:30 AM, Sven Sporer wrote: > Hi, I have a simple use case, but can't get the dependency resolution > to work on first run. This is not critical, but I want to understand > what's going on. Here's the szenario: > > * puppet --version: 2.6.4 > * on the bare system, I have vim 6.4 installed (no vim-base) > * I first want to upgrade to the latest version in repo, which is 7.1, > * and then install vim extensions for 7.1 (vim-enhanced, vim-data) > > My definition: > > class packages::vim { > $addons = ["vim-enhanced.x86_64", "vim-data.x86_64"] > > package { "vim.x86_64": > ensure => latest, > require => Class["yum::repos"], > before => Package[$addons], > } > > package { $addons: > ensure => present, > } > } > > The agent complains that vim-base-7.1 is not compatible with the > installed vim-6.4 (vim-base is needed for the addons). This would not > be a problem if the vim would be updated to 7.1 "before". > > (* I run puppet agent --test to see what happens on every run) > * So, this fails on first run. > * On second run, vim updates from 7.1 and installs $addons. > * Sometimes, a third run is needed to install the $addons. > > From the command line, a "yum update vim" shows the following > dependencies: > * updating: vim => 7.1 > * installing for dependencies: vim-base => 7.1 > > So, vim-7.1 has vim-base-7.1 as dependency, which is not compatible > with the installed vim-6.4. Should I include a package vim-base in the > manifest? Or is yum (2.4.2) wrong here? > So one of your dependencies has a conflict. Does yum not resolve this for you automatically? To play it safe, you could ensure the offending vim-6 related packages be absent before installing vim7. Cheers, Felix -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Could not retrieve catalog from remote server
I sometimes get the same error on puppet 2.6.4 and don't know the cause. Restarting the agent helps, but I would welcome a solution to this. On Jan 12, 1:25 am, Mohamed Lrhazi wrote: > What does this error mean or what does it indicate? > > puppet-agent: Could not retrieve catalog from remote server: Could > not intern from pson: source did not contain any PSON! > > What can I try to resolve it? uninstall/reinstall puppet on the client? > > I found a bug report, but not much info in > it:http://projects.puppetlabs.com/issues/5547 > > 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-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] Dependency resolution for packages
Hi, I have a simple use case, but can't get the dependency resolution to work on first run. This is not critical, but I want to understand what's going on. Here's the szenario: * puppet --version: 2.6.4 * on the bare system, I have vim 6.4 installed (no vim-base) * I first want to upgrade to the latest version in repo, which is 7.1, * and then install vim extensions for 7.1 (vim-enhanced, vim-data) My definition: class packages::vim { $addons = ["vim-enhanced.x86_64", "vim-data.x86_64"] package { "vim.x86_64": ensure => latest, require => Class["yum::repos"], before => Package[$addons], } package { $addons: ensure => present, } } The agent complains that vim-base-7.1 is not compatible with the installed vim-6.4 (vim-base is needed for the addons). This would not be a problem if the vim would be updated to 7.1 "before". (* I run puppet agent --test to see what happens on every run) * So, this fails on first run. * On second run, vim updates from 7.1 and installs $addons. * Sometimes, a third run is needed to install the $addons. >From the command line, a "yum update vim" shows the following dependencies: * updating: vim => 7.1 * installing for dependencies: vim-base => 7.1 So, vim-7.1 has vim-base-7.1 as dependency, which is not compatible with the installed vim-6.4. Should I include a package vim-base in the manifest? Or is yum (2.4.2) wrong here? -- 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's direction in theory?
On 01/11/2011 07:59 PM, Robin Lee Powell wrote: > On Tue, Jan 11, 2011 at 10:41:13AM -0800, Daniel Pittman wrote: >> The other thing I keep in mind is that using a 'define' that wraps >> some file and exec operations *is* keeping with the spirit of that >> statement, if not the letter: sure, it defines the type in the >> DSL, but it means that your nodes are referring to high level >> types and concepts, not low level implementation details. >> >> For example, you could rewrite your 'define apache::site' into a >> Ruby type/provider pair and *nothing* would have to change for >> users of it – the fact that it happens to be implemented one way >> or the other is encapsulated. > > I didn't realize it was that clean, actually. Thanks. In practice, I'd say it's not. Sure, your manifest is equally simple if the custom provider is implemented in DSL. But for users who are in the habit of applying new configs using puppet agent --test, the output will be quite cluttered because all resources that work together to form the provider chirp their respective change notices. On the other hand, if there's an actual piece of ruby code that "knows" how to set a FooResource's "ensure" to "present", the puppet agent will confirm just that. But then, this is all merely cosmetic, and it is by no means unsound to implement your custom providers in DSL. 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-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] Exactly how do people replace include with parametrised classes?
On 01/09/2011 09:11 PM, Stefan Schulte wrote: > On Fri, Jan 07, 2011 at 09:41:39PM +, R.I.Pienaar wrote: >> (forced to top post due to your html email) >> >> You cant avoid the scoping issues cos its broken. You can work around them >> though. >> > > To be honest I always found the current scoping kind of clear (because I > thought of include like of »open a new block/subscope and drop the class > contents right here«. What I always considered wrong was that you can include > a > class more then once and it surprised me that it works. So you state > that the include should always happen in top (node) scope? At least the > multiple include whould then be sane. The thing with this is: You cannot get "sane" and "working" all at once when taking this use case into account: class common { $ssh_listen_ip = "10.0.0.1" include ssh_server } where $ssh_listen_ip is used in ssh_server. This dynamic scoping is the only way of making classes dynamic where parameterized classes are not used (or not available). Putting all classes in the top scope implicitly kills dynamic scoping. I'd estimate that lots of manifests (possibly all that aren't extlookup based) cannot suffer the removal of dynamic scoping at this point. The insanity this can induce is a huge problem (e.g. http://projects.puppetlabs.com/issues/4748), as you mention, so it's important (imho) for the puppet team to get the concept of parameterized classes right. Once that's done, scoping may or may not be obsolete, but at least the dynamic scoping as used in the above example could safely go out the window. Cheers, Felix -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.