[Puppet Users] Re: Warning: appears to have a negative number of dependencies
Hi Yan, Can you provide details about your manifests. May be manifests helps us to find the solution to problem. Thanks and Regards, Rahul Khengare NTT DATA OSS Center, Pune, India. On Saturday, October 12, 2013 6:22:00 AM UTC+5:30, Yan Xiaofei wrote: Hello After add some packagelist to puppet class. I get lots of warning message appears to have a negative number of dependencies. My puppet master and agent version are 3.3.1. Here is the log out: [root@gpu022 ~]# puppet agent --test Info: Retrieving plugin Info: Loading facts in /var/lib/puppet/lib/facter/puppet_vardir.rb Info: Loading facts in /var/lib/puppet/lib/facter/puppi_projects.rb Info: Loading facts in /var/lib/puppet/lib/facter/pe_version.rb Info: Loading facts in /var/lib/puppet/lib/facter/last_run.rb Info: Loading facts in /var/lib/puppet/lib/facter/concat_basedir.rb Info: Loading facts in /var/lib/puppet/lib/facter/root_home.rb Info: Loading facts in /var/lib/puppet/lib/facter/facter_dot_d.rb Info: Caching catalog for gpu022.ihep.ac.cn Info: Applying configuration version '1381473104' Warning: /Stage[main]/Afs::Client/Service[afs]: appears to have a negative number of dependen Warning: Class[Afs::Client]: appears to have a negative number of dependencies Warning: Class[Afs::Client]: appears to have a negative number of dependencies Warning: /Stage[main]/Afs::Client/File[ThisCell]: appears to have a negative number of depend Warning: /Stage[main]/Afs::Client/File[CellServDB]: appears to have a negative number of depe Warning: Class[Afs::Client]: appears to have a negative number of dependencies Warning: Class[Afs::Client]: appears to have a negative number of dependencies Warning: Stage[main]: appears to have a negative number of dependencies Warning: Stage[main]: appears to have a negative number of dependencies Warning: Stage[main]: appears to have a negative number of dependencies Warning: Stage[main]: appears to have a negative number of dependencies Warning: /root/wn58packages.lst: appears to have a negative number of dependencies Warning: Class[Wn58packages]: appears to have a negative number of dependencies Warning: Stage[main]: appears to have a negative number of dependencies Notice: Finished catalog run in 150.52 seconds -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Managing /etc/hosts without using exported resources
Hi All,
I am using Puppet 3.2.4 and I'd like Puppet to manage /etc/hosts for me and
add neighbouring hosts only to /etc/hosts. These hosts are determined to
be neighbours based on where they are (city/country).
For example ($::city and $::country are custom facts):
@@host { $::fqdn:
ip = $::ipaddress,
host_aliases = [ $::hostname ],
tag = [ $::city, $::country ],
}
Host | tag == $::city and tag == $::country |
As I have never used exported resources before, I gave this a try and
realised there is more to them than the above config. It looks like I need
to install PuppetDB to make it work, which looks challenging given that the
puppet master is on SLES 11.
Apart from using exported resources, does anyone have any ideas on how to
achieve this?
One nasty way of doing it was to create a Puppet function that looks at
/var/lib/puppet/yaml/node/*.yaml and matches filenames based on a regex
passed in as an argument, then parses each yaml file and returns
'ipaddress', 'fqdn' and 'hostname' from them to update /etc/hosts, but it's
way too hacky for my liking.
- Gonzalo
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] LAMP stack with strange dependencies
Indeed, I should have paid more attention t the actual error.
Thanks for the info.
Harm
On Sunday, October 13, 2013 9:18:37 PM UTC+2, Ramin K wrote:
On 10/13/2013 1:47 AM, Harm De Weirdt wrote:
Hello everyone.
I've been toying around with puppet and something happened that seems
strange to me.
In site.pp I have the following:
node default {
# This is where you can declare classes for all nodes.
# Example:
# class { 'my_class': }
# class { 'lamp': }
package {'php':
ensure = present,
before = File['/etc/php.ini'],
}
file {'/etc/php.ini':
ensure = file,
}
package {'httpd':
ensure = present,
}
service {'httpd':
ensure = running,
enable= true,
require = Package['httpd'],
subscribe = File['/etc/php.ini'],
}
package {'mysql-server':
ensure = 'present',
}
service {'mysqld':
ensure = running,
enable= true,
require = Package['mysql-server'],
}
}
[I know about classes etc, this was just for easy testing. ]
Now, if I change the httpd resource to
package {'httpd':
ensure = absent,
}
I get the following error:
Error: Execution of '/bin/rpm -e httpd-2.2.3-82.el5.centos.i386'
returned 1: error: Failed dependencies:
httpd-mmn = 20051115 is needed by (installed)
php-5.1.6-40.el5_9.i386
Error: /Stage[main]//Node[default]/Package[httpd]/ensure: change
from 2.2.3-82.el5.centos to absent failed: Execution of
'/bin/rpm -e httpd-2.2.3-82.el5.centos.i386' returned 1: error:
Failed dependencies:
httpd-mmn = 20051115 is needed by (installed)
php-5.1.6-40.el5_9.i386
Notice: /Stage[main]//Node[default]/Service[httpd]: Dependency
Package[httpd] has failures: true
Warning: /Stage[main]//Node[default]/Service[httpd]: Skipping
because of failed dependencies
Notice: Finished catalog run in 15.00 seconds
This seems strange to me, because I never declared a require dependency
from php to httpd.
The only thing is that the httpd service subscribes to the php.ini
file. I could understand this error if the direction of this dependency
was the other way around, but not this way.
It's important when troubleshooting Puppet to separate the Puppet
error
reported from the subsystem error that may have caused Puppet to report
a failure. This seems to confuse more frequently that I would have
thought.
In the case above the Puppet error is: Error:
/Stage[main]//Node[default]/Package[httpd]/ensure: change from
2.2.3-82.el5.centos to absent failed and the error Puppet is passing on
comes from rpm is Failed dependencies: httpd-mmn = 20051115 is needed
by (installed) php-5.1.6-40.el5_9.i386
Ramin
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: Warning: appears to have a negative number of dependencies
Hello I resolved the problem. I define same packages in deferent modules, and some dependences to these packages. Delete multiple package define, the warning message was gone. Cheers Xiaofei 于 2013/10/14 14:12, Rahul Khengare wrote: Hi Yan, Can you provide details about your manifests. May be manifests helps us to find the solution to problem. Thanks and Regards, Rahul Khengare NTT DATA OSS Center, Pune, India. On Saturday, October 12, 2013 6:22:00 AM UTC+5:30, Yan Xiaofei wrote: Hello After add some packagelist to puppet class. I get lots of warning message appears to have a negative number of dependencies. My puppet master and agent version are 3.3.1. Here is the log out: [root@gpu022 ~]# puppet agent --test Info: Retrieving plugin Info: Loading facts in /var/lib/puppet/lib/facter/puppet_vardir.rb Info: Loading facts in /var/lib/puppet/lib/facter/puppi_projects.rb Info: Loading facts in /var/lib/puppet/lib/facter/pe_version.rb Info: Loading facts in /var/lib/puppet/lib/facter/last_run.rb Info: Loading facts in /var/lib/puppet/lib/facter/concat_basedir.rb Info: Loading facts in /var/lib/puppet/lib/facter/root_home.rb Info: Loading facts in /var/lib/puppet/lib/facter/facter_dot_d.rb Info: Caching catalog for gpu022.ihep.ac.cn http://gpu022.ihep.ac.cn Info: Applying configuration version '1381473104' Warning: /Stage[main]/Afs::Client/Service[afs]: appears to have a negative number of dependen Warning: Class[Afs::Client]: appears to have a negative number of dependencies Warning: Class[Afs::Client]: appears to have a negative number of dependencies Warning: /Stage[main]/Afs::Client/File[ThisCell]: appears to have a negative number of depend Warning: /Stage[main]/Afs::Client/File[CellServDB]: appears to have a negative number of depe Warning: Class[Afs::Client]: appears to have a negative number of dependencies Warning: Class[Afs::Client]: appears to have a negative number of dependencies Warning: Stage[main]: appears to have a negative number of dependencies Warning: Stage[main]: appears to have a negative number of dependencies Warning: Stage[main]: appears to have a negative number of dependencies Warning: Stage[main]: appears to have a negative number of dependencies Warning: /root/wn58packages.lst: appears to have a negative number of dependencies Warning: Class[Wn58packages]: appears to have a negative number of dependencies Warning: Stage[main]: appears to have a negative number of dependencies Notice: Finished catalog run in 150.52 seconds -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Why does the Puppet-Agent on Windows use a batch file?
Why does the Puppet-Agent on Windows use a batch file? I posted a question in the Ask PuppetLabs section and was directed to create post here as well; https://ask.puppetlabs.com/question/3506/why-does-the-puppet-agent-on-windows-use-a-batch-file/ Original question The Puppet Enterprise for Windows Agent runs as a windows service, basically a deamonised version of Puppet, which is all fine. However the Windows Service calls a batch file which seems extremely strange. While it does work, i.e. the Service starts and runs, using CMD.EXE as a service executable is generally considered a really bad idea. It does not respond to the usual SCM (Service Control Manager) calls and in it's current state is misconfigured e.g. The service says that it can respond to Pause and Continue events but CMD.EXE can't fulfill those requests. Also CMD.EXE does not monitor the ruby process (except for the basic operation of is it running) and vice versa. I can kill the cmd.exe process and the service manager will report that the Puppet Agent has stopped however the ruby process is still quite happily running. Either I'm missing something and CMD.EXE is an appropriate service executable or perhaps the community or puppet labs could create a better native wrapper to the ruby based puppet process. So I did a few tests; - You can send pause and continue messages to the service but they're just ignored even though the Services says it's Paused. - You can kill CMD.EXE service process but the Puppet Agent is still running (It becomes an orphaned process). You can then start the service again, and you'll end up with two Puppet Agents running daemonised at the same time. I'm not sure what will happen if they both try to do a catalog run at the same time, but nothing good can come of it. - CMD.EXE doesn't respond to power events e.g. going into Standby/Hibernate; but I have no idea how any service wrapper could raise that kind of event in Puppet so that it could deal with it. Does it even matter if the host goes into Standby in the middle of Puppet run? Admittedly this would be very unlikely scenario as Puppet seems to be more always-on server orientated rather than for laptop configuration management. - If you start Puppet and then quickly attempt to stop it, it get's stuck in the Stopping state and you have to kill Ruby manually. Thtat's because the service control manager raises events in a multithreaded manner, however CMD is running a single thread. If CMD.EXE is too busy to process the event then things get into a funny state. This would probably occur during a catalog run too but I haven't confirmed it. - From a troubleshooting perspective, there are no logs or diagnostic information created by CMD.EXE I'd be happy to write a service wrapper in C# and give it to the community, but before I do I want to make sure that it's really needed and I'm not trying to solve a problem that doesn't really exist. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: [Puppet-dev] Status of Data in modules
On 13 October 2013 12:40, Alessandro Franceschi a...@lab42.it wrote: Thanks for the update Eric, very useful to understand the ongoing works on data in modules. On Friday, October 11, 2013 9:01:19 PM UTC+2, Dan Bode wrote: On Fri, Oct 11, 2013 at 11:09 AM, Eric Sorenson eric.s...@puppetlabs.com wrote: Thanks to everyone who kicked the tires on the experimental data in modules feature included in Puppet 3.3.0. We got a lot of feedback, some cool proof-of-concept modules, and a definitive conclusion to the experiment. The idea of including a module-specific hiera backend is centered around one primary use case: replacing the 'params class pattern', a common idiom in Puppet modules that's described in the [Using Parameterized Classes][param-classes] guide. The problem that most testers ran into though is that for non-trivial modules they ended up having to re-implement the Puppet DSL logic encoded in their params.pp in convoluted, non-obvious ways. The solutions to this led to more contortions until we'd ended up with the ability to execute parser functions in the right-hand-side of a yaml value. So something which started out trying to help separate data from code ended up putting code back into data! Additionally, even after multiple attempts to simplify the surface area and user experience with the bindings system (described in ARM-9) that underlay the data-in-modules implementation, users still found its complexity daunting. There are some important bits of scaffolding (like an actual type system for Puppet!) that will prove valuable as more of the future parser and evaluator work that Henrik is building makes its way into the product, but in the final analysis the data in modules feature was the wrong vehicle to introduce them. Refocusing on the problems users were trying to solve (and here I have to give shout-outs to Ashley Penney for his [puppetlabs-ntp][] branch and the dynamic duo of Spencer Krug/William van Hevelingen for their [startrek][] module) and the problems with the 'params' pattern lent some clarity. We've gotten into a situation of disparity with regard to hiera and data bindings, because data bindings enable module _users_ to use their site-wide hiera data but don't provide moduel _authors_ the same affordance. But rather than introduce additional complexity, we can close the gap for existing code patterns. So the proposed solution at this point is: - enable an implicit data-binding lookup against the hiera-puppet backend for a value of 'classname::variable' in the file 'modules/classname/manifests/**params.pp', which simplifies class definition and provides consistency with other hiera backends. As a module author, you'd still leave your logic for variables in params.pp, but they'd be implicitly looked up via data bindings as the class is declared, after consulting site-wide hiera. +1 Really happy to see this solved in a way that will not lead to complex migrations to Puppet 4. Although, to play devil's advocate, two concerns: the special nature of params as a namespace suffix: - how do users know not to use this namespace for anything else? - What if user declares resources in params? Does this fail? Do they always get realized when anything else from that namespace is applied? the magic mapping from x::parameter x::params::parameter may be something hard to grok for new users who are not already familiar with the params pattern. This is probably solvable with documentation and --debug logging, but still worth noting. Yes worth noting, but as you said proper documentation might suffice. Anyway +1 also for me on the lookup to params.pp (Dan this, + Puppet 3 data bindings, reminds me https://github.com/example42/puppi/blob/master/lib/puppet/parser/functions/params_lookup.rb;-) I'd like to add to the complexity cases , in case you haven't still sorted it out, the situations where some of the modules' params change according to user provided values to other params. For example look here: https://github.com/stdmod/puppet-elasticsearch/blob/master/manifests/init.pp#L124 the path of the configuration dir ($dir param here) change according to the value of the $install param, and in order to manage this the code in the linked line is necessary. I wonder how such a case could be managed with data in modules (without replicating a similar logic). Isn't that possible to solve by allowing one hiera value to use another hiera value for interpolation? https://projects.puppetlabs.com/issues/21367 al - remove the user-facing '--binder' functionality - fix known problems with the hiera-puppet lookups ([Redmine 15746][15746], namely, but if there are others that are important to you please speak up!) To show how this would work, I'll rework the ['smart parameter defaults' example][param-classes] I linked above, with my commentary behind `##` comments: #
[Puppet Users] Re: Duplicate declaration for files.
Hello Mike,
Here the baseos file[/etc/hosts] resource get propagated to all the
nodes because of inheritance. You again changing the same file in
newnode.example.com again.
Puppet does not allow to edit the same file twice (same resource again) in
single run.
Work around to that,
Create a new folders for each node in baseos module as per node name and
put node specific /etc/hosts file in that folder.
e.g
baseos
node1.example.com
- hosts
node2.example.com
- hosts
node3.example.com
- hosts
newnode.example.com
- hosts
All nodes inherit basenode, Inside the class baseos i've declared the
archive host table and various other parameters
[.]
file { /etc/hosts:
ensure = present,
owner = root,
group = root,
mode= '664',
# source = puppet:///modules/baseos/hosts,
source =
puppet:///modules/baseos/$hostname/hosts,
Add $hostname facter as above in source parameter.
This will add dynamic nature to source.
Source attribute resolve to
- puppet:///modules/baseos/node1.example.com/hosts
- puppet:///modules/baseos/node2.example.com/hosts
- puppet:///modules/baseos/node3.example.com/hosts
- puppet:///modules/baseos/newnode.example.com/hosts
depending upon the node(host) name.
Hope this will solve your problem.
Thanks and Regards,
Rahul Khengare
NTT DATA OSS Center, Pune, India.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: External Facts on Windows with Powershell
Also of note.. facts.d support is broken in windows 2003 :( (and it breaks puppet - so it won't even run) - see http://projects.puppetlabs.com/issues/22622 -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: [Puppet-dev] Status of Data in modules
On Monday, October 14, 2013 9:19:10 AM UTC+2, Erik Dalén wrote: On 13 October 2013 12:40, Alessandro Franceschi a...@lab42.itjavascript: wrote: Thanks for the update Eric, very useful to understand the ongoing works on data in modules. On Friday, October 11, 2013 9:01:19 PM UTC+2, Dan Bode wrote: On Fri, Oct 11, 2013 at 11:09 AM, Eric Sorenson eric.s...@puppetlabs.com wrote: Thanks to everyone who kicked the tires on the experimental data in modules feature included in Puppet 3.3.0. We got a lot of feedback, some cool proof-of-concept modules, and a definitive conclusion to the experiment. The idea of including a module-specific hiera backend is centered around one primary use case: replacing the 'params class pattern', a common idiom in Puppet modules that's described in the [Using Parameterized Classes][param-classes] guide. The problem that most testers ran into though is that for non-trivial modules they ended up having to re-implement the Puppet DSL logic encoded in their params.pp in convoluted, non-obvious ways. The solutions to this led to more contortions until we'd ended up with the ability to execute parser functions in the right-hand-side of a yaml value. So something which started out trying to help separate data from code ended up putting code back into data! Additionally, even after multiple attempts to simplify the surface area and user experience with the bindings system (described in ARM-9) that underlay the data-in-modules implementation, users still found its complexity daunting. There are some important bits of scaffolding (like an actual type system for Puppet!) that will prove valuable as more of the future parser and evaluator work that Henrik is building makes its way into the product, but in the final analysis the data in modules feature was the wrong vehicle to introduce them. Refocusing on the problems users were trying to solve (and here I have to give shout-outs to Ashley Penney for his [puppetlabs-ntp][] branch and the dynamic duo of Spencer Krug/William van Hevelingen for their [startrek][] module) and the problems with the 'params' pattern lent some clarity. We've gotten into a situation of disparity with regard to hiera and data bindings, because data bindings enable module _users_ to use their site-wide hiera data but don't provide moduel _authors_ the same affordance. But rather than introduce additional complexity, we can close the gap for existing code patterns. So the proposed solution at this point is: - enable an implicit data-binding lookup against the hiera-puppet backend for a value of 'classname::variable' in the file 'modules/classname/manifests/**params.pp', which simplifies class definition and provides consistency with other hiera backends. As a module author, you'd still leave your logic for variables in params.pp, but they'd be implicitly looked up via data bindings as the class is declared, after consulting site-wide hiera. +1 Really happy to see this solved in a way that will not lead to complex migrations to Puppet 4. Although, to play devil's advocate, two concerns: the special nature of params as a namespace suffix: - how do users know not to use this namespace for anything else? - What if user declares resources in params? Does this fail? Do they always get realized when anything else from that namespace is applied? the magic mapping from x::parameter x::params::parameter may be something hard to grok for new users who are not already familiar with the params pattern. This is probably solvable with documentation and --debug logging, but still worth noting. Yes worth noting, but as you said proper documentation might suffice. Anyway +1 also for me on the lookup to params.pp (Dan this, + Puppet 3 data bindings, reminds me https://github.com/example42/puppi/blob/master/lib/puppet/parser/functions/params_lookup.rb;-) I'd like to add to the complexity cases , in case you haven't still sorted it out, the situations where some of the modules' params change according to user provided values to other params. For example look here: https://github.com/stdmod/puppet-elasticsearch/blob/master/manifests/init.pp#L124 the path of the configuration dir ($dir param here) change according to the value of the $install param, and in order to manage this the code in the linked line is necessary. I wonder how such a case could be managed with data in modules (without replicating a similar logic). Isn't that possible to solve by allowing one hiera value to use another hiera value for interpolation? https://projects.puppetlabs.com/issues/21367 Didn't know of this function which actually looks interesting. Is the hiera value usable in the same hierarchy structure ? I mean, would it be possibile to have an hiera.yaml like: --- version: 3 hierarchy: - category: 'osfamily' - category: 'operatingsystem' -
[Puppet Users] Re: Custom type and provider development
Rich, On Sunday, 7 April 2013 08:04:52 UTC+2, Rich Siegel wrote: In other news, I am about to mark functional the baremetal build. I managed to inject puppet/facter into WinPE and can take a host through a fully unattended install of win2008r2 including manage unattend.xml as a file template. On a vm where ive tested it takes 10 minutes and fully bootstraps itself 2x. The best part is I scripted the pe build, uses only native supported tooling so anyone who clones the repo can build the iso in 15 min themselves. I think it could be a game changer with some refinement, and could lure a lot of people away from massive sccm, wds, altiris or other commercial tooling. One tool. One module. Automated. Puppet ftw What is the status of this? This is something I could definitely use for my current customer, and within these working hours also contribute to. However, a guiding hand will be needed as I'm still in my uphill battle to get to know Puppet. Ringo -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] puppet-dashboard cert::create_key_pair and cert::request fails
Hi! I am already successfully using puppet with puppet-dashboard in my environment and would like to extend this to display the facts in puppet-dashboard. I understand that I need a puppetdb for that. Which I installed and I already get successfull log messages there that facts are stored. So until now everything seems to work. Now I want to connect dashboard to puppetmaster and from the documentation I read that I need to do the following: $ sudo -u puppet-dashboard rake cert:create_key_pair $ sudo -u puppet-dashboard rake cert:request Well, I used the puppetlabs apt repository to install, so the users are different. But what I do is: cd /usr/share/puppet-dashboard su www-data -c rake cert:create_key_pair --trace su www-data -c rake cert:request --trace The first thing is that with create_key_pair I get a Key(s) already exist. error message. Because for some reason the method is called twice. I ignore this, as afterwards I successfully find a public and private key in the /usr/share/puppet-dashboard/certs directory. But nothing else. If there should be more there at this point, please tell me so. Just the public and private pem. At issuing the cert:request command, I get the following error: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed and I don't find any request on the puppetmaster. (puppet cert list) My setup is that, puppetmaster, puppetdb and puppet-dashboard are all running on the same host. What I already tried: - Copying certs from the /var/lib/puppet/ssl directory and skip the create and sign steps. But this doesn't work. Could easily be that I copied wrong files. The puppet-dashboard issues the same error message on the node view btw. (With or without keys in the puppet-dashboard/certs directory. The only time I get another error there is when I give the files in the certs directory a wrong permission. So it looks like it is looking at the expected location) - Debugging a little bit. But couldn't find out more. And I don't get a better error message from the ssl code. - Playing around for a day now. So I'm giving up. I need help :) Installed puppet packages: ii puppet 3.3.1-1puppetlabs1all Centralized configuration management - agent startup and compatibility scripts ii puppet-common 3.3.1-1puppetlabs1all Centralized configuration management ii puppet-dashboard1.2.23-1puppetlabs1 all Dashboard for Puppet ii puppetdb1.5.0-1puppetlabs1all PuppetDB Centralized Storage. ii puppetdb-terminus 1.5.0-1puppetlabs1all Connect Puppet to PuppetDB by setting up a terminus for PuppetDB. ii puppetlabs-release 1.0-7 all Package to install Puppet Labs gpg key and apt repo ii puppetmaster3.3.1-1puppetlabs1all Centralized configuration management - master startup and compatibility scripts ii puppetmaster-common 3.3.1-1puppetlabs1all Puppet master common scripts Debian Version: wheezy Thanks in advance for any help, Robert -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Managing /etc/hosts without using exported resources
Hi Gonzalo,
First of all you don't need puppetdb to use exported resources. A simple
mysql database will do it, even sqlite works, not recommended though.
Specifically what you need is stored configs configured in your puppet
master. The problem with exported resources is that sometimes they can be
slow... depends obviously on the amount of nodes, resources, etc.
Regarding your question if it can be done in a different way... I would
definitely use DNS if possible... if not exported resources if very easy to
implement. The function idea I don't think is that bad... I would prefer
to query a database rather than parsing files.
Another way I can think about is to use a custom ENC to export those
parameter. The ENC would take the information from some type of database
that you have to update as well. That would be definitely faster and a more
elegant solution
Depending on the size of your infrastructure and performance I would go for
exported resources and if that is too slow I would consider some of the
other options
Cheers
Juan
On Monday, October 14, 2013 7:19:56 AM UTC+1, Gonzalo wrote:
Hi All,
I am using Puppet 3.2.4 and I'd like Puppet to manage /etc/hosts for me
and add neighbouring hosts only to /etc/hosts. These hosts are determined
to be neighbours based on where they are (city/country).
For example ($::city and $::country are custom facts):
@@host { $::fqdn:
ip = $::ipaddress,
host_aliases = [ $::hostname ],
tag = [ $::city, $::country ],
}
Host | tag == $::city and tag == $::country |
As I have never used exported resources before, I gave this a try and
realised there is more to them than the above config. It looks like I need
to install PuppetDB to make it work, which looks challenging given that the
puppet master is on SLES 11.
Apart from using exported resources, does anyone have any ideas on how to
achieve this?
One nasty way of doing it was to create a Puppet function that looks at
/var/lib/puppet/yaml/node/*.yaml and matches filenames based on a regex
passed in as an argument, then parses each yaml file and returns
'ipaddress', 'fqdn' and 'hostname' from them to update /etc/hosts, but it's
way too hacky for my liking.
- Gonzalo
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: Managing /etc/hosts without using exported resources
- Original Message - From: JuanBrein juan.br...@gmail.com To: puppet-users@googlegroups.com Sent: Monday, October 14, 2013 12:45:05 PM Subject: [Puppet Users] Re: Managing /etc/hosts without using exported resources Hi Gonzalo, First of all you don't need puppetdb to use exported resources. A simple mysql database will do it, even sqlite works, not recommended though. Specifically what you need is stored configs configured in your puppet master. The problem with exported resources is that sometimes they can be slow... depends obviously on the amount of nodes, resources, etc. note the old stored configs are deprecated and will be removed real soon, would not recommend you head down that route at this point. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Status of Data in modules
On Friday, October 11, 2013 1:09:23 PM UTC-5, Eric Sorenson wrote: Thanks to everyone who kicked the tires on the experimental data in modules feature included in Puppet 3.3.0. We got a lot of feedback, some cool proof-of-concept modules, and a definitive conclusion to the experiment. The idea of including a module-specific hiera backend is centered around one primary use case: replacing the 'params class pattern', a common idiom in Puppet modules that's described in the [Using Parameterized Classes][param-classes] guide. I guess I wasn't following this closely enough to realize that getting rid of the params class pattern was an objective. I thought this was a somewhat more general initiative. [...] So the proposed solution at this point is: - enable an implicit data-binding lookup against the hiera-puppet backend for a value of 'classname::variable' in the file 'modules/classname/manifests/params.pp', which simplifies class definition and provides consistency with other hiera backends. As a module author, you'd still leave your logic for variables in params.pp, but they'd be implicitly looked up via data bindings as the class is declared, after consulting site-wide hiera. Do I understand correctly that you set out to get rid of the ::params class pattern, but now you favor an approach that depends on that pattern? Why is that better than being more general: enable an implicit lowest-priority hierarchy level for values of form 'modulename::variable', drawing on data from per-module data files such as modules/modulename/data.yaml? John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Duplicate declaration for files.
On Friday, October 11, 2013 11:24:44 AM UTC-5, mike wrote:
Hello,
I'm configuring my linux server with puppet open and is ok. My question is
the next; I've a declared in mi nodes.pp the next:
[.]
node 'basenode' {
include 'baseos'
include 'motd'
import 'useradd.pp'
}
#All nodes for my domain
node /.*\.example\.com/ inherits basenode {
}
[.]
All nodes inherit basenode, Inside the class baseos i've declared the
archive host table and various other parameters
[.]
file { /etc/hosts:
ensure = present,
owner = root,
group = root,
mode= '664',
source = puppet:///modules/baseos/hosts,
}
[.]
But I need add other node in nodes.pp and this need apply the class
baseos but without /etc/hots because this use other hosts table that I
declared as follows:
[.]
node 'newnode.example.com' inherits basenode {
file { /etc/hosts:
ensure = file,
source = puppet:///modules/baseos/newnode/hosts,
mode = 644,
}
}
[.]
But when I go newnode and run puppet give error for duplicate /etc/hosts
declaration
[.]
Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
Duplicate declaration: File[/etc/hosts] is already declared in file
/etc/puppet/modules/baseos/manifests/config.pp:21; cannot redeclare at
/etc/puppet/manifests/nodes.pp:55 on node newnode.example.com
[.]
How I can assign different tables hosts for different nodes in this case?
You need to do one of these things
- modify your baseos class so that it does not manage /etc/hosts on
those nodes where you want to specify a different hosts file (and perhaps
not on *any* node), or
- modify your baseos class so that it manages /etc/hosts correctly for
all nodes, and stop re-declaring that file in node blocks, or
- stop assigning class baseos to those nodes for which it declares the
wrong /etc/hosts content (relying only on node blocks or on a different
class in those cases).
Implicit in all of the above is this:do not assign a class to a node if you
don't want all the resources it declares. (There is a last-ditch
workaround for that, but it would cause you more harm than good at your
level of Puppet experience.)
There are multiple ways to go about those, but I hesitate to suggest
specifics without understanding why the new node is an exception to your
general rule.
John
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] puppet class if
On Friday, October 11, 2013 8:59:10 AM UTC-5, Werner Flamme wrote: I'm not Jakub (the OP), it is not my problem. I'm only the one who wanted to know where the couple of errors are. Peter was mistaken. There are no actual errors in the OP's manifest, and it might work in some environments. In particular, the operator != performs a boolean test for non-equality, just as the OP expected it to do. The reason it didn't work for him is almost surely what Bernd pointed out: the $::hostname fact usually contains only a local name, not a fully-qualified domain name. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] exporting custom facts to puppet agents
On Sunday, October 13, 2013 4:53:10 PM UTC-5, Sans wrote: Hi Cristian, That sounds a workable solution. Unlikely. Custom functions run on the master during catalog compilation. If you need data from a local file on the node to compute the correct value for your erstwhile $::am_running_oss fact then changing the fact to a function will not improve that data's availablility. On the other hand, if the idea is that the content of /home/admin/OSs.txt is managed exclusively by Puppet in the first place, then what's the point? The master must already have enough information to determine what that file is supposed to contain, and thus what the fact value is supposed to be. Just set a variable in an appropriate class with the appropriate computed value, and skip the fact altogether. If you only needed the file to support the fact, then dump the file, too. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: Duplicate declaration for files.
Hello,
I fix the problem with a case statement:
[...]
class baseos::rhel-hosts {
case $fqdn {
'new-node.example.com': {
file { /etc/hosts:
ensure = present,
owner = root,
group = root,
mode= '664',
source =
puppet:///modules/baseos/new-node/hosts,
}
}
default: {
file { /etc/hosts:
ensure = present,
owner = root,
group = root,
ensure = file,
source =
puppet:///modules/baseos/hosts,
mode = 644,
}
}
}
}
[...]
Thanks.
2013/10/14 jcbollinger john.bollin...@stjude.org
On Friday, October 11, 2013 11:24:44 AM UTC-5, mike wrote:
Hello,
I'm configuring my linux server with puppet open and is ok. My question
is the next; I've a declared in mi nodes.pp the next:
[.]
node 'basenode' {
include 'baseos'
include 'motd'
import 'useradd.pp'
}
#All nodes for my domain
node /.*\.example\.com/ inherits basenode {
}
[.]
All nodes inherit basenode, Inside the class baseos i've declared the
archive host table and various other parameters
[.]
file { /etc/hosts:
ensure = present,
owner = root,
group = root,
mode= '664',
source = puppet:///modules/baseos/**hosts,
}
[.]
But I need add other node in nodes.pp and this need apply the class
baseos but without /etc/hots because this use other hosts table that I
declared as follows:
[.]
node 'newnode.example.com' inherits basenode {
file { /etc/hosts:
ensure = file,
source = puppet:///modules/baseos/**newnode/hosts,
mode = 644,
}
}
[.]
But when I go newnode and run puppet give error for duplicate
/etc/hosts declaration
[.]
Error: Could not retrieve catalog from remote server: Error 400 on
SERVER: Duplicate declaration: File[/etc/hosts] is already declared in file
/etc/puppet/modules/baseos/**manifests/config.pp:21; cannot redeclare at
/etc/puppet/manifests/nodes.**pp:55 on node newnode.example.com
[.]
How I can assign different tables hosts for different nodes in this case?
You need to do one of these things
- modify your baseos class so that it does not manage /etc/hosts on
those nodes where you want to specify a different hosts file (and perhaps
not on *any* node), or
- modify your baseos class so that it manages /etc/hosts correctly for
all nodes, and stop re-declaring that file in node blocks, or
- stop assigning class baseos to those nodes for which it declares the
wrong /etc/hosts content (relying only on node blocks or on a different
class in those cases).
Implicit in all of the above is this:do not assign a class to a node if
you don't want all the resources it declares. (There is a last-ditch
workaround for that, but it would cause you more harm than good at your
level of Puppet experience.)
There are multiple ways to go about those, but I hesitate to suggest
specifics without understanding why the new node is an exception to your
general rule.
John
--
You received this message because you are subscribed to a topic in the
Google Groups Puppet Users group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/puppet-users/Yw62zu_VhhY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit
[Puppet Users] Re: mcollective setup question
Was there ever a solution to this issue?
I appear to be having a similar (if not the same) issue:
By adding some debug code to client.rb, it appears that the replies I'm
getting have no requestid at all.
Log.warn(Ignoring a message that did not pass security
validations)
---
Log.warn(Ignoring a message that did not pass security
validations: requestid #{requestid} - #{reply.requestid})
Which produces the following message when I run mco ping (or any other
command):
warn 2013/10/14 10:26:13: client.rb:99:in `rescue in receive' Ignoring a
message that did not pass security validations: requestid
8d0b3938113259a3ac7d878b365ad522 -
Looking at mcollective.log on the server (set to 'debug' level), I see the
request being processed:
D, [2013-10-14T10:26:13.237675 #12265] DEBUG -- : runnerstats.rb:49:in
`received' Incrementing total stat
D, [2013-10-14T10:26:13.237794 #12265] DEBUG -- : pluginmanager.rb:83:in
`[]' Returning cached plugin security_plugin with class
MCollective::Security::Ssl
D, [2013-10-14T10:26:13.237896 #12265] DEBUG -- : ssl.rb:222:in
`deserialize' De-Serializing using marshal
D, [2013-10-14T10:26:13.238027 #12265] DEBUG -- : ssl.rb:175:in
`validrequest?' Validating request from cert=jeg-mc
D, [2013-10-14T10:26:13.238868 #12265] DEBUG -- : runnerstats.rb:38:in
`validated' Incrementing validated stat
D, [2013-10-14T10:26:13.238958 #12265] DEBUG -- : ssl.rb:222:in
`deserialize' De-Serializing using marshal
D, [2013-10-14T10:26:13.239067 #12265] DEBUG -- : pluginmanager.rb:83:in
`[]' Returning cached plugin security_plugin with class
MCollective::Security::Ssl
D, [2013-10-14T10:26:13.239186 #12265] DEBUG -- : pluginmanager.rb:83:in
`[]' Returning cached plugin security_plugin with class
MCollective::Security::Ssl
D, [2013-10-14T10:26:13.239316 #12265] DEBUG -- : base.rb:153:in
`validate_filter?' Message passed the filter checks
D, [2013-10-14T10:26:13.239487 #12265] DEBUG -- : runnerstats.rb:26:in
`passed' Incrementing passed stat
D, [2013-10-14T10:26:13.239557 #12265] DEBUG -- : runner.rb:80:in
`agentmsg' Handling message for agent 'discovery' on collective
'mcollective'
D, [2013-10-14T10:26:13.239624 #12265] DEBUG -- : agents.rb:119:in
`dispatch' Dispatching a message to agent discovery
D, [2013-10-14T10:26:13.239713 #12265] DEBUG -- : pluginmanager.rb:83:in
`[]' Returning cached plugin discovery_agent with class
MCollective::Agent::Discovery
D, [2013-10-14T10:26:13.239782 #12265] DEBUG -- : activemq.rb:233:in
`receive' Waiting for a message from ActiveMQ
D, [2013-10-14T10:26:13.240053 #12265] DEBUG -- : pluginmanager.rb:83:in
`[]' Returning cached plugin security_plugin with class
MCollective::Security::Ssl
D, [2013-10-14T10:26:13.240360 #12265] DEBUG -- : pluginmanager.rb:83:in
`[]' Returning cached plugin security_plugin with class
MCollective::Security::Ssl
D, [2013-10-14T10:26:13.240440 #12265] DEBUG -- : ssl.rb:208:in `serialize'
Serializing using marshal
D, [2013-10-14T10:26:13.240525 #12265] DEBUG -- : ssl.rb:307:in `makehash'
Creating message hash using /etc/mcollective/server_private.pem
D, [2013-10-14T10:26:13.243567 #12265] DEBUG -- : base.rb:168:in
`create_reply' Encoded a message for request
8d0b3938113259a3ac7d878b365ad522
D, [2013-10-14T10:26:13.243670 #12265] DEBUG -- : ssl.rb:208:in `serialize'
Serializing using marshal
D, [2013-10-14T10:26:13.243956 #12265] DEBUG -- : pluginmanager.rb:83:in
`[]' Returning cached plugin connector_plugin with class
MCollective::Connector::Activemq
D, [2013-10-14T10:26:13.244059 #12265] DEBUG -- : activemq.rb:266:in
`publish' Sending a broadcast message to ActiveMQ target
'/queue/mcollective.reply.wolf.shands.ufl.edu_24887' with headers '{}'
D, [2013-10-14T10:26:13.245763 #12265] DEBUG -- : runnerstats.rb:56:in
`sent' Incrementing replies stat
It looks suspiciously like the reply created by base.rb is empty-- But I'm
not sure how to proceed from here with troubleshooting since I don't know
what a valid reply looks like.
On Friday, June 7, 2013 4:25:19 AM UTC-4, Richard Knight wrote:
Anybody else had any luck solving this? I've tried on 3 separate boxes now
all seem to suffer the same problem, and the logs are somewhat unhelpful is
tracking down why this is occurring.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: External Facts on Windows with Powershell
Hi Klavs, On Mon, Oct 14, 2013 at 12:48 AM, Klavs Klavsen kl...@enableit.dk wrote: Also of note.. facts.d support is broken in windows 2003 :( (and it breaks puppet - so it won't even run) - see http://projects.puppetlabs.com/issues/22622 -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out. Bug #22622, if I understand correctly, is that facter (and puppet) can fail to run if there is an external executable fact that doesn't return any output, and that it affects all versions of windows, not just 2003. If that's not the case, please update the ticket with relevant details. Thanks, Josh -- Josh Cooper Developer, Puppet Labs -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Why does the Puppet-Agent on Windows use a batch file?
Hi Glenn, On Sun, Oct 13, 2013 at 6:28 PM, Glenn Sarti glenn.sar...@gmail.com wrote: Why does the Puppet-Agent on Windows use a batch file? Because the service and command line invocations, e.g. puppet apply, both need to setup their environment to run ruby, e.g. RUBYLIB, etc. The easiest way to do that was to create daemon.bat that calls environment.bat, and then invokes ruby. I posted a question in the Ask PuppetLabs section and was directed to create post here as well; https://ask.puppetlabs.com/question/3506/why-does-the-puppet-agent-on-windows-use-a-batch-file/ Original question The Puppet Enterprise for Windows Agent runs as a windows service, basically a deamonised version of Puppet, which is all fine. However the Windows Service calls a batch file which seems extremely strange. While it does work, i.e. the Service starts and runs, using CMD.EXE as a service executable is generally considered a really bad idea. It does not respond to the usual SCM (Service Control Manager) calls and in it's current state is misconfigured e.g. The service says that it can respond to Pause and Continue events but CMD.EXE can't fulfill those requests. The service is hosted in the ruby process that cmd.exe executes, not cmd.exe itself. Puppet does respond to SCM events like start stop. The puppet service does claim to support pause continue (due to the win32-service gem[1]), but the service does not implement the necessary handler logic. Please file a bug on that. Also CMD.EXE does not monitor the ruby process (except for the basic operation of is it running) and vice versa. I can kill the cmd.exe process and the service manager will report that the Puppet Agent has stopped however the ruby process is still quite happily running. Either I'm missing something and CMD.EXE is an appropriate service executable or perhaps the community or puppet labs could create a better native wrapper to the ruby based puppet process. So I did a few tests; - You can send pause and continue messages to the service but they're just ignored even though the Services says it's Paused. Puppet's daemon.rb[2] needs to override the default service_pause and service_continue. The pause method should set a flag that the main loop checks each time. - You can kill CMD.EXE service process but the Puppet Agent is still running (It becomes an orphaned process). You can then start the service again, and you'll end up with two Puppet Agents running daemonised at the same time. cmd.exe is not essential to the puppet service once it's running. - I'm not sure what will happen if they both try to do a catalog run at the same time, but nothing good can come of it. Puppet uses a lock file to ensure two processes don't apply a catalog at the same time. This scenario can come up in the normal case when puppet is running as a service, and you run `puppet apply` on the command line. - CMD.EXE doesn't respond to power events e.g. going into Standby/Hibernate; but I have no idea how any service wrapper could raise that kind of event in Puppet so that it could deal with it. Does it even matter if the host goes into Standby in the middle of Puppet run? Admittedly this would be very unlikely scenario as Puppet seems to be more always-on server orientated rather than for laptop configuration management. - If you start Puppet and then quickly attempt to stop it, it get's stuck in the Stopping state and you have to kill Ruby manually. Thtat's because the service control manager raises events in a multithreaded manner, however CMD is running a single thread. If CMD.EXE is too busy to process the event then things get into a funny state. This would probably occur during a catalog run too but I haven't confirmed it. The service control manager calls back into ruby.exe, not cmd.exe. Our daemon.rb is what calls StartServiceCtrlDispatcher... - From a troubleshooting perspective, there are no logs or diagnostic information created by CMD.EXE The daemon.rb code creates a log file (with different verbosity levels). I have been meaning to switch it over to using the application event log, but haven't yet, patches welcome! Josh [1] https://github.com/djberg96/win32-service/blob/ffi/lib/win32/daemon.rb#L86-87 [2] https://github.com/puppetlabs/puppet/blob/master/ext/windows/service/daemon.rb -- Josh Cooper Developer, Puppet Labs -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Puppet Dashboard Radiator view thru iframe
Is it possible to create an iframe in an html page and display the Radiator view in the Puppet Dashboard? For some reason all my other NOC iframe's are displaying with the exception of the Radiator view Matt -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] exporting custom facts to puppet agents
i understood that the file is only on the master? If so, I will try to write something tomorrow to implement this, If the value never changes, it will be better to put it in an external variable. On Mon, Oct 14, 2013 at 6:03 PM, jcbollinger john.bollin...@stjude.org wrote: On Sunday, October 13, 2013 4:53:10 PM UTC-5, Sans wrote: Hi Cristian, That sounds a workable solution. Unlikely. Custom functions run on the master during catalog compilation. If you need data from a local file on the node to compute the correct value for your erstwhile $::am_running_oss fact then changing the fact to a function will not improve that data's availablility. On the other hand, if the idea is that the content of /home/admin/OSs.txt is managed exclusively by Puppet in the first place, then what's the point? The master must already have enough information to determine what that file is supposed to contain, and thus what the fact value is supposed to be. Just set a variable in an appropriate class with the appropriate computed value, and skip the fact altogether. If you only needed the file to support the fact, then dump the file, too. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: Managing /etc/hosts without using exported resources
Hi Juan,
Thanks for your reply. I was going to look into using stored configs with
MySQL as per your suggestion, until I saw R.I.Pienaar's email :(
Yes, I would certainly use DNS if I could, but unfortunately DNS is not an
option in this setup.
I think I will have to either parse files (eek) or maybe look into that ENC
suggestion.
- Gonzalo
On Mon, Oct 14, 2013 at 10:45 PM, JuanBrein juan.br...@gmail.com wrote:
Hi Gonzalo,
First of all you don't need puppetdb to use exported resources. A simple
mysql database will do it, even sqlite works, not recommended though.
Specifically what you need is stored configs configured in your puppet
master. The problem with exported resources is that sometimes they can be
slow... depends obviously on the amount of nodes, resources, etc.
Regarding your question if it can be done in a different way... I would
definitely use DNS if possible... if not exported resources if very easy to
implement. The function idea I don't think is that bad... I would prefer
to query a database rather than parsing files.
Another way I can think about is to use a custom ENC to export those
parameter. The ENC would take the information from some type of database
that you have to update as well. That would be definitely faster and a more
elegant solution
Depending on the size of your infrastructure and performance I would go
for exported resources and if that is too slow I would consider some of the
other options
Cheers
Juan
On Monday, October 14, 2013 7:19:56 AM UTC+1, Gonzalo wrote:
Hi All,
I am using Puppet 3.2.4 and I'd like Puppet to manage /etc/hosts for me
and add neighbouring hosts only to /etc/hosts. These hosts are determined
to be neighbours based on where they are (city/country).
For example ($::city and $::country are custom facts):
@@host { $::fqdn:
ip = $::ipaddress,
host_aliases = [ $::hostname ],
tag = [ $::city, $::country ],
}
Host | tag == $::city and tag == $::country |
As I have never used exported resources before, I gave this a try and
realised there is more to them than the above config. It looks like I need
to install PuppetDB to make it work, which looks challenging given that the
puppet master is on SLES 11.
Apart from using exported resources, does anyone have any ideas on how to
achieve this?
One nasty way of doing it was to create a Puppet function that looks at
/var/lib/puppet/yaml/node/*.**yaml and matches filenames based on a
regex passed in as an argument, then parses each yaml file and returns
'ipaddress', 'fqdn' and 'hostname' from them to update /etc/hosts, but it's
way too hacky for my liking.
- Gonzalo
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an
email to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: Status of Data in modules
On 14.10.2013 16:16, jcbollinger wrote: So the proposed solution at this point is: - enable an implicit data-binding lookup against the hiera-puppet backend for a value of 'classname::variable' in the file 'modules/classname/manifests/params.pp', which simplifies class definition and provides consistency with other hiera backends. As a module author, you'd still leave your logic for variables in params.pp, but they'd be implicitly looked up via data bindings as the class is declared, after consulting site-wide hiera. Do I understand correctly that you set out to get rid of the ::params class pattern, but now you favor an approach that depends on that pattern? Why is that better than being more general: enable an implicit lowest-priority hierarchy level for values of form 'modulename::variable', drawing on data from per-module data files such as modules/modulename/data.yaml? AIUI, prototyping revealed that many params classes contain logic that cannot be expressed in .yaml to calculate default values. Making the fallback lookup check the params class, the logic can be preserved while avoiding verbose boilerplate code like the params_lookup calls in Alessandro's modules. Regards, David -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
