Re: [Puppet Users] ruby issue
Hi, Back with some Sweet god news :) and found the missing part. As mention I tried to install on RHEL 6.4 testing server and failed on rubygems. Few days ago I had a remote session with one of my valuable friends that guess what, also had this issue and it's all was around rubygem installation. After trying to install it from rubygems official site using setup.rb I discovered it was just not the the same cup of tea my RHEL server likes. So, as I don't want to activate my RHN subscription, I downloaded it from CentOS free rpm online repository, that was suitable for my version (RHEL 6.4 - 64bit) at: * http://rpm.pbone.net/index.php3/stat/4/idpl/20348086/dir/centos_6/com/rubygems-1.3.7-1.el6.noarch.rpm.html *http://rpm.pbone.net/index.php3/stat/4/idpl/20348086/dir/centos_6/com/rubygems-1.3.7-1.el6.noarch.rpm.html (Strange thing its from 2010 but fits the ryby of RHEL 6.4 that in ver 1.8.7) OR better if already got Internet connection you can use: # wget * ftp://mirror.switch.ch/pool/3/mirror/centos/6.4/os/x86_64/Packages/rubygems-1.3.7-1.el6.noarch.rpm *ftp://mirror.switch.ch/pool/3/mirror/centos/6.4/os/x86_64/Packages/rubygems-1.3.7-1.el6.noarch.rpm After this using the yum command: yum localinstall rubygems-1.3.7-1.el6.noarch.rpm and Viola' the yum install puppet puppet-server (ver. 3.2.1) from puppet repo went just smooth. Thanks *Yev *for helping me out on this and for the community I'm attaching a full quick installation doc that help those novice out there :) My final thought/suggestion regards this issue: If you are already using Internet connection and you want to leave in the free world use CentOS. I could do it quicker and I think better using yum to solved all the issue I confront. I'll try to post the whole installation in few days as attached text file in here or in general issue. Good luck Puppeteers wherever U R ! Yizhar Don't ask what the community can contribute to you ? ask what you can contribute to the community On Monday, June 17, 2013 5:27:00 PM UTC+3, jcbollinger wrote: On Friday, June 14, 2013 9:13:19 PM UTC-5, Michael Stanhke wrote: Puppet Labs doesn't try to replace packages in provided by the upstream OS vendor. Yay! Thank you! PL has no business replacing vendor-supplied OS components. It especially has no business configuring repositories such that there is a risk of users installing such replacement components without realizing they are doing so. WTG, PL. 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] The handy Grail of Modules Standards
On Mon, 17 Jun 2013 07:32:36 -0700 (PDT) Alessandro Franceschi a...@lab42.it wrote: Thanks for your opinion, even if I don't fully agree with it. Puppet is a language and so people do the same things in different ways, and they all work and do what they are supposed to do. But if we think about modules REUSABILITY and INTEROPERABILITY some patterns have to be followed. Some of the parameters described in the document are somehow REQUIRED, IMHO, if you want to make a really reusable module (for example the ones that let you decide how to manage your configuration files... if you enforce a logic in a module or a specific template and don't allow override by users, then you are not making a reusable module, so for example a parameter like template is just needed). So, since, at least some of, these parameters are needed for a reusable module it's just a matter of defining few naming conventions (and managing external modules dependencies in a sane way) to make different modules happily live better together. Note, I don't say that ALL the modules should have ALL these parameters, I'd consider these Standard Namings as suggestions which people may decide to follow or not (somehow similar to the Code Style suggestions, which leverage the style of the Puppet code and have found tools like puppet-lint to validate them). Once enough good and prominent Puppet modules will follow these naming conventions, it will be easier for people to switch modules, integrate the best ones from different sources (without forking them) , use these parameters from a WEB interface, a a standard framework from smoke testing and have the benefits which are better described in the blog post. Note also that these proposals are based on the current Puppet language specifications, I want to start from what can be used now, with an eye on the evolution on Puppet, but with still feet on the ground: nothing new or to invent, just few basic naming convention to agree upon and *suggest*. I still think that this is at hands reach :-) This is definitely a good initiative, what I'm just saying is that you've opened a can of worms :-) The initial step of creating common guidelines for parameter names is nice, as it can create some consistency across modules, and ease work sharing as well as lower the learning curve for people using 3rd party modules. But it would need to be official (in the puppet documentation as best practices, for instance) and/or enforced on the forge, to become really useful. And after that, things quickly get exponentially complex IMHO. A few examples from the top of my head : * Naming the modules themselves. * Naming the classes and definitions inside the modules. * Multiple modules requiring the same packages (If my module needs rsync, yours too, where do we put the common virtual resource?). * The use of author-specific common modules (I don't like taking a johndoe/apache module and noticing I then need johndoe/common). But don't get me wrong, I like where this is headed, and will participate as much as I can. Matthias -- Matthias Saou ██ ██ ██ ██ Web: http://matthias.saou.eu/ ██ Mail/XMPP: matth...@saou.eu ██ ██ GPG: 4096R/E755CC63██ ██ ██ 8D91 7E2E F048 9C9C 46AF ██ ██ ██ ██ 21A9 7A51 7B82 E755 CC63 -- 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 3.x, rubygem pkg can't be found on a RHEL 6.4
Fixed. Was an issue of rubygems. Solved by downloading from external repo: As I don't want to activate my RHN subscription, I downloaded it from CentOS free rpm online repository, that was suitable for my version (RHEL 6.4 - 64bit) at: * http://rpm.pbone.net/index.php3/stat/4/idpl/20348086/dir/centos_6/com/rubygems-1.3.7-1.el6.noarch.rpm.html *http://rpm.pbone.net/index.php3/stat/4/idpl/20348086/dir/centos_6/com/rubygems-1.3.7-1.el6.noarch.rpm.html (Strange thing its from 2010 but fits the ryby of RHEL 6.4 that in ver 1.8.7) OR better if already got Internet connection you can use: # wget * ftp://mirror.switch.ch/pool/3/mirror/centos/6.4/os/x86_64/Packages/rubygems-1.3.7-1.el6.noarch.rpm *ftp://mirror.switch.ch/pool/3/mirror/centos/6.4/os/x86_64/Packages/rubygems-1.3.7-1.el6.noarch.rpm On Sunday, June 9, 2013 3:01:36 PM UTC+3, Yizhar A. wrote: Dear T.J./Keith Kind of getting the same issue T.J. got regards rubygems. Tried to run # yum-config-manager --enable rhel-6-server-optional-rpms BUT since I'm using RHEL 6.4 (.x86_64) in my test env. *with only puppetlabs repo* it's not working for me. Is it a repo issue ? What should I add since I don't want to activate my RHN subscrition as I'm only at the testing phase right now. Can I installed it seperatly for .rpm ? what version do I need than ? Thanks, Yizhar A. On Thursday, April 11, 2013 11:13:46 PM UTC+3, T.J. Yang wrote: Keith, Thanks for the following command, I can install puppet on RHEL 6.4 now. tj On Thu, Apr 11, 2013 at 5:12 AM, Keith Burdis ke...@burdis.org wrote: Try running: # yum-config-manager --enable rhel-6-server-optional-rpms - Keith On 10 April 2013 10:04, Yusup Ashrap aph...@gmail.com wrote: I have having the same problem with install puppet on redhat 6.2. -- 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...@googlegroups.com. To post to this group, send email to puppet...@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- 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/ZIx9U3Ai1ww/unsubscribe?hl=en . To unsubscribe from this group and all its topics, send an email to puppet-users...@googlegroups.com. To post to this group, send email to puppet...@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- T.J. Yang -- 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] The handy Grail of Modules Standards
On Tuesday, June 18, 2013 11:16:15 AM UTC+2, Matthias Saou wrote: On Mon, 17 Jun 2013 07:32:36 -0700 (PDT) Alessandro Franceschi a...@lab42.it javascript: wrote: Thanks for your opinion, even if I don't fully agree with it. Puppet is a language and so people do the same things in different ways, and they all work and do what they are supposed to do. But if we think about modules REUSABILITY and INTEROPERABILITY some patterns have to be followed. Some of the parameters described in the document are somehow REQUIRED, IMHO, if you want to make a really reusable module (for example the ones that let you decide how to manage your configuration files... if you enforce a logic in a module or a specific template and don't allow override by users, then you are not making a reusable module, so for example a parameter like template is just needed). So, since, at least some of, these parameters are needed for a reusable module it's just a matter of defining few naming conventions (and managing external modules dependencies in a sane way) to make different modules happily live better together. Note, I don't say that ALL the modules should have ALL these parameters, I'd consider these Standard Namings as suggestions which people may decide to follow or not (somehow similar to the Code Style suggestions, which leverage the style of the Puppet code and have found tools like puppet-lint to validate them). Once enough good and prominent Puppet modules will follow these naming conventions, it will be easier for people to switch modules, integrate the best ones from different sources (without forking them) , use these parameters from a WEB interface, a a standard framework from smoke testing and have the benefits which are better described in the blog post. Note also that these proposals are based on the current Puppet language specifications, I want to start from what can be used now, with an eye on the evolution on Puppet, but with still feet on the ground: nothing new or to invent, just few basic naming convention to agree upon and *suggest*. I still think that this is at hands reach :-) This is definitely a good initiative, what I'm just saying is that you've opened a can of worms :-) Lol, we have to do that sooner or later, I think :-D And the sooner, the better. The initial step of creating common guidelines for parameter names is nice, as it can create some consistency across modules, and ease work sharing as well as lower the learning curve for people using 3rd party modules. But it would need to be official (in the puppet documentation as best practices, for instance) and/or enforced on the forge, to become really useful. I definitively agree. This is something that should be endorsed if not managed directly by PuppetLabs. Anyway I would not enforce the use of standard params, but somehow certify the modules that provide them (eventually defining different levels of standard params coverage) so that you know you can use them with established patterns (and in the future maybe test them with standard procedures and integrate them in an ENC that explicitly supports and exposes these standard parameters) And after that, things quickly get exponentially complex IMHO. A few examples from the top of my head : * Naming the modules themselves. Right, even if, besides few cases with somehow flurry namings (apache or httpd? ssh or openssh?), generally the name of the module is already quite standard. * Naming the classes and definitions inside the modules. * Multiple modules requiring the same packages (If my module needs rsync, yours too, where do we put the common virtual resource?). This is a wide and tricky issue. My naif approach is the definition of a dependency_class parameter where external resources like rsync are managed (and you can provide a custom dependency_class where you manage the required resources in the way you want). For the installation of simple packages I'd currently use/recommend the not perfect if ! defined approach (always in the dependency_class). When the language will provide a smarter solution, we can follow it, some past discussion on possible solutions there has been in the list, in order to work they definitively have to be shared by the modules (so they fit well in the standard module pattern). Some of them required enhancements to the DSL some not, being a Puppet user I prefer to stick to current language syntax. * The use of author-specific common modules (I don't like taking a johndoe/apache module and noticing I then need johndoe/common). I'd try to leverage modules on stdlib as much as possible, but at the same time some local common modules are sometimes needed. It doesn't harm to have them in your modulepath, as long as there are no naming conflicts. But don't get me wrong, I like
Re: [Puppet Users] f5 module usage/debugging tips?
Hi Chris,
I think I've narrowed the issue down.
I'm able to use the 10.2.0.2 f5 gem in a simple script with F5 v11.3.0 to
create an f5_node so it looks like the F5 is keeping some
backwards-compatibility.
The problem is only occurring when the F5 gem is used within puppet. The f5
gem is using the ruby 1.8.7's built-in SOAP library that clashes with a
monkey-patch in Puppet to override the instance_variables method of the
basic Ruby Object class.
The patch was introduced in this
commit:
https://github.com/puppetlabs/puppet/commit/1f4e44c26a0d703d1192d26ef8ab555e4508e338
*lib/puppet/util/monkey_patches.rb*:
class Object
alias :puppet_original_instance_variables :instance_variables
def instance_variables
puppet_original_instance_variables.map(:to_sym)
end
end
This in turn clashes with the SOAP class in Ruby 1.8.7:
lib/soap/mapping/mapping.rb:
def self.get_attribute(obj, attr_name)
if obj.is_a?(::Hash)
obj[attr_name] || obj[attr_name.intern]
else
name = XSD::CodeGen::GenSupport.safevarname(attr_name)
if obj.instance_variables.include?('@' + name)
obj.instance_variable_get('@' + name)
elsif ((obj.is_a?(::Struct) or obj.is_a?(Marshallable)) and
obj.respond_to?(name))
obj.__send__(name)
end
end
end
Since Puppet has overridden the instance_variable method to return an Array
of Symbols, this breaks the obj.instance_variables.include?('@' + name)
line because it is trying to compare a Symbol with a String which will
always be false. This in turn causes the F5 gem to send SOAP requests to
the F5 with nil values so the nodes are never created on the F5.
This is a pretty strange issue as I thought that there would have been
other users of the puppetlabs-f5 module with Ruby 1.8.7 and so would have
hit the same issue, or am I missing something?
Anyway, it looks like to fix the problem we'll either need to patch the F5
gem to override the above method within Ruby or somehow revert the
monkeypatch in Puppet for the F5 puppet module, unless you can think of a
cleaner and better solution?
Jeff
On Wednesday, June 12, 2013 3:34:02 PM UTC+10, Christopher Wood wrote:
Unfortunately due to various non-puppet bigip upgrade issues I haven't
been able to back to this yet. If I get anything useful working I will
post.
On Tue, Jun 11, 2013 at 03:32:56AM -0700, jgm...@gmail.com
javascript:wrote:
Hi Chris,
How did you go with trying to use the Puppet F5 module with v11.3.0?
I
think I am having the same issue as you were.
The puppet output would say that the resource was created but the
iControl
debug logs shows that it is being sent an empty SOAP create message.
I've tried running a simple ruby script using the 10.2.0.2 f5 gem and
was
able to create the node successfully so it looks the Puppet is doing
something funny.
Any help would be greatly appreciated.
Thanks,
Jeff
On Tuesday, February 12, 2013 8:31:04 AM UTC+11, Christopher Wood
wrote:
On Mon, Feb 11, 2013 at 12:40:12PM -0800, Nan Liu wrote:
On Mon, Feb 11, 2013 at 8:27 AM, Christopher Wood
[1][1]christop...@pobox.com wrote:
(Following up to my own post for posterity's sake, see
[2][2]xkcd.com/979.)
Short form: for me this isn't yet as easy as a file resource
but
the
puppetized management payoff will be worth the work. My
issues
are most
likely a reflection of my own puppet/ruby/iControl/SOAP
skill.
I am going to explore a personalized set of F5
types/providers
that I
can use without first loading up the wsdl file for every
involved
iControl interface, version, and hotfix.
Points from my various BigIP/puppet experimentations:
a) The f5-icontrol-10.2.0.2.gem doesn't necessarily work
with LTM
11.1.0. (Or I haven't figured it out, also quite likely.)
This
could be
because the gem ships different wsdl files but I couldn't
get it
to work
with later iControl wsdl files anyway.
b) In LTM 11, F5 deprecated some interfaces so puppet f5
module
providers like f5_node are suddenly using deprecated
interfaces.
c) Some parts of the iControl api are being updated/fixed
over
time, for
instance the hotfix id 388590 reading Certificates can now
successfully
be updated using the iControl Management::KeyCertificate
interface,
see:
[3][3]
http://support.f5.com/kb/en-us/solutions/public/14000/100/sol14175.html
d) Judging by my soap-newbie eye the soap4r package appears
Re: [Puppet Users] PuppetDB + PuppetMaster with Passanger
I've actually just raised an issue for the problem I just posted, I found the solution. Please see: http://projects.puppetlabs.com/issues/21283 Alastair On Wednesday, 24 October 2012 21:58:19 UTC+1, Deepak Giridharagopal wrote: We ended up hashing this out on the #puppet IRC channel earlier today. Nikola helped us identify a problem with our packaging on Debian/Ubuntu systems that are using Ruby 1.9: http://projects.puppetlabs.com/issues/17178 We'll be cutting a new release soon that should have the above fix included. Stay tuned! deepak On Wed, Oct 24, 2012 at 7:16 AM, Nikola Petrov niko...@gmail.comjavascript: wrote: Hi everyone, I am trying to configure a puppet master with a puppetdb for storeconfigs backend. I am using Ubuntu 12.10 and the packages from puppetlabs repository. The option I chose for the master is to use passanger as I am far more familiar with apache than with the ruby web servers that are available as an option. I will also need puppetDB for proper nagios configuration so I got that as well from the ubuntu packages. Here is the full package list that I installed: apt-get install puppet-common puppetdb puppetdb-terminus puppetmaster-common puppetmaster-passenger I followed the guides on puppetlabs and everything worked fine for a vagrant virtual machine I have locally as an agent. The problem came when I tried to add puppetDB to the picture. I started getting strange error on puppet agent -t on the agent. I am also getting the following message in the system log when I try to connect to the master Could not configure routes from /etc/puppet/routes.yaml: Could not find terminus puppetdb for indirection facts Strangely enough I couldn't find any answers with googling so I decided to post here for help. Best, Nikola -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet...@googlegroups.comjavascript: . To unsubscribe from this group, send email to puppet-users...@googlegroups.com javascript:. 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 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] PuppetDB + PuppetMaster with Passanger
Hi, I'm currently receiving the above error trying to start the puppet master. I've followed the instructions to install PuppetDB and puppetdb-terminus, through packages, but I cannot get it to start up. The master would run successfully before setting up PuppetDB. The host system is running CentOS 6 and ruby 1.8, so this may not be the same issue you resolved in the above issue. Regards, Alastair On Wednesday, 24 October 2012 21:58:19 UTC+1, Deepak Giridharagopal wrote: We ended up hashing this out on the #puppet IRC channel earlier today. Nikola helped us identify a problem with our packaging on Debian/Ubuntu systems that are using Ruby 1.9: http://projects.puppetlabs.com/issues/17178 We'll be cutting a new release soon that should have the above fix included. Stay tuned! deepak On Wed, Oct 24, 2012 at 7:16 AM, Nikola Petrov niko...@gmail.comjavascript: wrote: Hi everyone, I am trying to configure a puppet master with a puppetdb for storeconfigs backend. I am using Ubuntu 12.10 and the packages from puppetlabs repository. The option I chose for the master is to use passanger as I am far more familiar with apache than with the ruby web servers that are available as an option. I will also need puppetDB for proper nagios configuration so I got that as well from the ubuntu packages. Here is the full package list that I installed: apt-get install puppet-common puppetdb puppetdb-terminus puppetmaster-common puppetmaster-passenger I followed the guides on puppetlabs and everything worked fine for a vagrant virtual machine I have locally as an agent. The problem came when I tried to add puppetDB to the picture. I started getting strange error on puppet agent -t on the agent. I am also getting the following message in the system log when I try to connect to the master Could not configure routes from /etc/puppet/routes.yaml: Could not find terminus puppetdb for indirection facts Strangely enough I couldn't find any answers with googling so I decided to post here for help. Best, Nikola -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet...@googlegroups.comjavascript: . To unsubscribe from this group, send email to puppet-users...@googlegroups.com javascript:. 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 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 cisco device
I'm trying to manage a cisco switch for testing purposes. When I'm running: puppet device verbose I get the following error Notice: Did not receive certificate When I'm trying to sign the device I receive: [root@pup-t01 etc]# puppet cert sign sw1 Error: Could not find certificate request for sw1 Any advice ho to get things going? -- 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 Management with Dual Boot Workstation
Hi, I'm trying to figure out what is the best way to handle a single system that dual boots with a puppet client running in each. In this case we are talking about Ubuntu 12.04 and Windows 8. Should I just copy the certificate from one OS to the other? Should I have a different certificate for each OS? In this case can they have the same hostname, as it is the same IP address for both OSes? Can I somehow use a different hostname for each that doesn't match DNS? I understand from a client point of view it probably doesn't matter a whole lot, but I am also using Foreman (and I imagine Puppet Dashboard would have a similar issue) and I'd like to be able to check on the facts and status of both Ubuntu and Windows at any given time, not just the OS that happens to be running at the moment. Puppet nodes are usually not identified based on hostname, but rather based on certificate name (which is usually the same as hostname). You most likely do not want to just copy the certificate over. I just run the initial puppet runs with --certname $hostname-$os.$domain to have separate certificates for each installation. Also my puppet.conf template has certname = %= @clientcert % , so that whatever is specified on the command line on the first run sticks. Cheers, Paul -- 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 Management with Dual Boot Workstation
Great, that makes sense, thanks! -- 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] The handy Grail of Modules Standards
On Monday, June 17, 2013 9:32:36 AM UTC-5, Alessandro Franceschi wrote: Puppet is a language and so people do the same things in different ways, and they all work and do what they are supposed to do. But if we think about modules REUSABILITY and INTEROPERABILITY some patterns have to be followed. Some of the parameters described in the document are somehow REQUIRED, IMHO, if you want to make a really reusable module (for example the ones that let you decide how to manage your configuration files... if you enforce a logic in a module or a specific template and don't allow override by users, then you are not making a reusable module, so for example a parameter like template is just needed). So, since, at least some of, these parameters are needed for a reusable module it's just a matter of defining few naming conventions (and managing external modules dependencies in a sane way) to make different modules happily live better together. Although I agree that to be reusable, modules need to provide certain types of levers, knobs, and switches, as appropriate for their scopes, I think the case is weak for those controls needing to be called by the same names. At best, naming conventions for such things might improve *ease* of (re)use for some people, but the key factor for reusability is not the names of the controls so much as their presence in the first place. I see implications for interoperability only insomuch as one imagines facilitating one module being a drop-in replacement for another, but (1) there's a lot more to that than just common naming, so (2) that kind of interoperability is unlikely to come about except by specific intention anyway, so in that case shared naming comes out as a project requirement. To me, that moots any general parameter-naming standard as far as interoperability goes. None of that is a fundamental reason to object to the effort, but I'm not seeing any promise of significant benefit to motivate me to participate actively. I do have a bona fide objection, however: although the effort is cast at this point as being aimed exclusively at parameter naming, by implication it also covers elements of module structure, organization, and style as well, as the things being named have to exist for the standard to be relevant. I do understand that the intention is not to make all the standardized controls mandatory for every module, but for those that a given module does provide, even the standard's limited reusability and interoperability goals are not served if those controls are not located where the standard anticipates (which is for the most part on a single front-end class). Personally, I would rather see a white paper explaining what kinds of controls need to be available to facilitate reusability of various kinds of modules, and, optionally, setting out one or more models of how a module can provide those controls. Regardless of the nature of the paper's authorship, this feels like it should be a position paper, not a proposed standard. 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] The handy Grail of Modules Standards
Although I agree that to be reusable, modules need to provide certain types of levers, knobs, and switches, as appropriate for their scopes, I think the case is weak for those controls needing to be called by the same names. At best, naming conventions for such things might improve ease of (re)use for some people, but the key factor for reusability is not the names of the controls so much as their presence in the first place. I see implications for interoperability only insomuch as one imagines facilitating one module being a drop-in replacement for another, but (1) there's a lot more to that than just common naming, so (2) that kind of interoperability is unlikely to come about except by specific intention anyway, so in that case shared naming comes out as a project requirement. To me, that moots any general parameter-naming standard as far as interoperability goes. I think being able to use another class in a drop-in way is not the value I see in parameter naming 'recommendations'. I personal see value in the ease of use more than anything, if parameters are similarly named between classes, when you go to use them you don't have to interrupt, double check with the docs what this class/define uses, then modify your parameter name accordingly. Its a reduction in surprise if anything. An example would be the 'package' parameter, versus 'packages' ... if I didn't have to stop and check which one it is for my XYZ class it might save time and mistakes *shrug*. Is that valuable? Alas, I'm more of developer then user these days so I would defer that to our users. As a developer though - I would find it handy to have a guide for common things, I'm a pedant when it comes to naming and if someone already came up with a name for me, I would probably use it, presuming others have thought through any naming consequences. None of that is a fundamental reason to object to the effort, but I'm not seeing any promise of significant benefit to motivate me to participate actively. I do have a bona fide objection, however: although the effort is cast at this point as being aimed exclusively at parameter naming, by implication it also covers elements of module structure, organization, and style as well, as the things being named have to exist for the standard to be relevant. I do understand that the intention is not to make all the standardized controls mandatory for every module, but for those that a given module does provide, even the standard's limited reusability and interoperability goals are not served if those controls are not located where the standard anticipates (which is for the most part on a single front-end class). I've been pondering this situation as well. I presume in a world where such recommendations become commonly used, the outcome would be surprise at a missing 'recommended' parameter, then a subsequent bug raised on the module due to its lack. This might be considered a positive or negative. If the parameter name was named 'something else' due to a feeling that the 'standard' is not covering a developers needs, then this could be annoying to have that discussion _yet again_. If however the functionality is simply missing - this becomes a BAU patch (like the lint patches we see all the time) and probably a positive feature request. Of course, this all depends on how good the recommendations are. Having looked through the document I think some of them are obvious, and require less debate while other recommendations are less obvious/contentious. Personally, I would rather see a white paper explaining what kinds of controls need to be available to facilitate reusability of various kinds of modules, and, optionally, setting out one or more models of how a module can provide those controls. Regardless of the nature of the paper's authorship, this feels like it should be a position paper, not a proposed standard. Fair point, its a difficult document to position precisely. I guess I foresee this as something that should be a part of a guide for writing modules then any hard/fast rule or 'standard'. ken. -- 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] Announce: Puppet 2.7.22 Available [ Security Release ]
Puppet 2.7.22 is now available. 2.7.22 addresses a security vulnerability discovered in the 2.7.x series of Puppet. This vulnerability has been assigned Mitre CVE number CVE-2013-3567. All users of Puppet 2.7.21 and earlier who cannot upgrade to the current version of Puppet, 3.2.2, are strongly encouraged to upgrade to 2.7.22. For more information on this vulnerability, please visit http://puppetlabs.com/security/cve/cve-2013-3567. Thanks to Ben Murphy, for discovering and responsibly disclosing the vulnerability. Downloads are available at: * Source https://downloads.puppetlabs.com/puppet/puppet-2.7.22.tar.gz Windows package is available at https://downloads.puppetlabs.com/windows/puppet-2.7.22.msi RPMs are available at https://yum.puppetlabs.com/el or /fedora Debs are available at https://apt.puppetlabs.com Mac package is available at https://downloads.puppetlabs.com/mac/puppet-2.7.22.dmg Gems are available via rubygems at https://rubygems.org/downloads/puppet-2.7.22.gem or by using `gem install puppet --version=2.7.22` See the Verifying Puppet Download section at: https://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet Please report feedback via the Puppet Labs Redmine site, using an affected puppet version of 2.7.22: http://projects.puppetlabs.com/projects/puppet/ ## Changelog ## Justin Stoller (1): fea3cb6 Improve CVE 2013 1654 SSLv2 Downgrade Master test Matthaus Owens (3): 96be982 (packaging) Update build_defaults to remove EOL platforms (natty, f15, f16). 7f40007 (packaging) Update debian build-depends to be ruby1.8 so that the shebang is correct after install and ruby1.9.1 isn't used on newer debians. e160e99 (packaging) Update CHANGELOG, PUPPETVERSION for 2.7.22 Moses Mendoza (1): ba8c021 [packaging] Update mocks for rpmbuilder mock format Patrick Carlisle (7): 788fdaf Don't keep Gemfile.lock checked in. 535da9b Add acceptance test for report processing 2333fa4 Add vendoring system into puppet ee741eb Fix installation of vendored libs e8c30cb Vendor safe_yaml 0.9.2 5926d1a (#20584) Only deserialize expected objects from YAML fd758ad Remove acceptance test for yaml parsing that was no longer valid -- 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] Announce: Puppet 3.2.2 Available [ Security Release ]
Puppet 3.2.2 is now available. 3.2.2 addresses a security vulnerability discovered in the 3.x series of Puppet. This vulnerability has been assigned Mitre CVE number CVE-2013-3567. All users of Puppet 3.2.1 and earlier are strongly encouraged to upgrade to 3.2.2. For more information on this vulnerability, please visit http://puppetlabs.com/security/cve/cve-2013-3567. Thanks to Ben Murphy, for discovering and responsibly disclosing the vulnerability. Downloads are available at: * Source https://downloads.puppetlabs.com/puppet/puppet-3.2.2.tar.gz Windows package is available at https://downloads.puppetlabs.com/windows/puppet-3.2.2.msi RPMs are available at https://yum.puppetlabs.com/el or /fedora Debs are available at https://apt.puppetlabs.com Mac package is available at https://downloads.puppetlabs.com/mac/puppet-3.2.2.dmg Gems are available via rubygems at https://rubygems.org/downloads/puppet-3.2.2.gem or by using `gem install puppet --version=3.2.2` See the Verifying Puppet Download section at: https://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet Please report feedback via the Puppet Labs Redmine site, using an affected puppet version of 3.2.2: http://projects.puppetlabs.com/projects/puppet/ ## Changelog ## Matthaus Owens (1): a6c08f9 (packaging) Update PUPPETVERSION to 3.2.2 Patrick Carlisle (6): 81eeace Add acceptance test for report processing 6a29171 Add vendoring system into puppet 40f2744 Fix installation of vendored libs 6f1b979 Vendor safe_yaml 0.9.2 ce50d4a (#20584) Only deserialize expected objects from YAML d06e1df Remove acceptance test for yaml parsing that was no longer valid -- 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] Announce: Puppet Enterprise 2.8.2 Available [ Security Release ]
Dear Puppet Enterprise Users, Puppet Enterprise 2.8.2 is now available. This is a security release of Puppet Enterprise. All users of Puppet Enterprise are strongly encouraged to upgrade when possible to Puppet Enterprise 2.8.2. Puppet Enterprise 2.8.2 includes fixes to address CVE-2013-3567. For more information on this vulnerability, please visit http://puppetlabs.com/security/cve/cve-2013-3567. As a current Puppet Enterprise user, you can upgrade to this new version as part of your annual subscription. If upgrading, it is recommended to upgrade your master and console servers first. As always, we want to hear about your experiences with Puppet Enterprise. If you have any questions about upgrading, be sure to get in touch with Puppet Labs Support. Thanks, Matthaus Owens 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] Re: Announce: Puppet 3.2.2 Available [ Security Release ]
Awesome! I tried using yum repo from puppetlab to install puppet client on centos5, it seems missing dependency virt-what and libselinux-ruby, can probably find those somewhere else but it would be nice if it is included in puppetlabs dependencies. Thanks! On Tuesday, June 18, 2013 10:07:50 AM UTC-7, Matthaus Litteken wrote: Puppet 3.2.2 is now available. 3.2.2 addresses a security vulnerability discovered in the 3.x series of Puppet. This vulnerability has been assigned Mitre CVE number CVE-2013-3567. All users of Puppet 3.2.1 and earlier are strongly encouraged to upgrade to 3.2.2. For more information on this vulnerability, please visit http://puppetlabs.com/security/cve/cve-2013-3567. Thanks to Ben Murphy, for discovering and responsibly disclosing the vulnerability. Downloads are available at: * Source https://downloads.puppetlabs.com/puppet/puppet-3.2.2.tar.gz Windows package is available at https://downloads.puppetlabs.com/windows/puppet-3.2.2.msi RPMs are available at https://yum.puppetlabs.com/el or /fedora Debs are available at https://apt.puppetlabs.com Mac package is available at https://downloads.puppetlabs.com/mac/puppet-3.2.2.dmg Gems are available via rubygems at https://rubygems.org/downloads/puppet-3.2.2.gem or by using `gem install puppet --version=3.2.2` See the Verifying Puppet Download section at: https://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet Please report feedback via the Puppet Labs Redmine site, using an affected puppet version of 3.2.2: http://projects.puppetlabs.com/projects/puppet/ ## Changelog ## Matthaus Owens (1): a6c08f9 (packaging) Update PUPPETVERSION to 3.2.2 Patrick Carlisle (6): 81eeace Add acceptance test for report processing 6a29171 Add vendoring system into puppet 40f2744 Fix installation of vendored libs 6f1b979 Vendor safe_yaml 0.9.2 ce50d4a (#20584) Only deserialize expected objects from YAML d06e1df Remove acceptance test for yaml parsing that was no longer valid -- 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] The handy Grail of Modules Standards
Some personal notes among the lines... On Tuesday, June 18, 2013 6:35:18 PM UTC+2, Ken Barber wrote: Although I agree that to be reusable, modules need to provide certain types of levers, knobs, and switches, as appropriate for their scopes, I think the case is weak for those controls needing to be called by the same names. At best, naming conventions for such things might improve ease of (re)use for some people, but the key factor for reusability is not the names of the controls so much as their presence in the first place. Well on this I definitively do not agree :-) For me a module is reusable when: 1- It supports many different OS (this is somehow implicit and does not involve naming conventions) 2- It leaves to the user freedom on how to populate and customize the provided configuration files ( I think this is the main point for most reusability cases) 3- It allows the user to manage some behaviours of the module (has a service to be restarted after a file change? Do I want to manage a service status (at runtime or boot) 4- In (somehow extreme) cases it allows the user to customize names of package/services, paths of files and so on 5- It allows seamless addition of custom resources, not managed by the module but related to it 6- It allows the user to decide where to place his data (also this is out of naming convention scope) Given these points, I think that some of the parameters names proposed in the draft actually DO inherently enhance a module reusability: For point 2: source, template, options (with might make useless almost any additional application specific configuration parameter), dir_source (and dir_* ) For point 3: status, autorestart (poor name), audits, noops For point 4: package, service, file_path, dir_path For point 5: my_class resources_hash But maybe we have different semantic nuances for the term modules' reusability. I see implications for interoperability only insomuch as one imagines facilitating one module being a drop-in replacement for another, but (1) there's a lot more to that than just common naming, so (2) that kind of interoperability is unlikely to come about except by specific intention anyway, so in that case shared naming comes out as a project requirement. To me, that moots any general parameter-naming standard as far as interoperability goes. I agree that the interoperability part is not fully dependent on naming standards. Aa a partial solution for this I have thought about the usage of a dependency_class to contain in a single, replaceable, class all the external dependencies, and eventually tweaking the Modulefile and the puppet module command to manage soft-dependencies and reduce conflicts modules Forge modules (more details on this on the blog post linked before). I don't see it as a perfect solution but that's something that can be done now (without extra code if not for the Forge integration) and very quickly. I think being able to use another class in a drop-in way is not the value I see in parameter naming 'recommendations'. I personal see value in the ease of use more than anything, if parameters are similarly named between classes, when you go to use them you don't have to interrupt, double check with the docs what this class/define uses, then modify your parameter name accordingly. Its a reduction in surprise if anything. An example would be the 'package' parameter, versus 'packages' ... if I didn't have to stop and check which one it is for my XYZ class it might save time and mistakes *shrug*. Let me clarify that hardly in my dreams I could imagine seamless drop-in replacements, but naming standards+dependency_class pattern CAN make interoperability much easier. For the other benefits, least surprise is one point, not small as it involves (let me copy and paste :-): - Better user experience (modules are easier to use and understand) - Quicker and more reliable Puppet manifests development (for basic functions you can expect predictable parameters) - More coherent and error proof Puppet setups but I see various other clear benefits, in the mid term: - The possibility to have an unified approach to smoke testing of common features - The possibility to have web front-ends and ENC that leverage on the standardized parameters - Easier integration with superclasses that expose their own parameters and use different modules to build up full applications stacks or complex setups that involve multiple modules. - A PuppetLabs and/or Community driven central repository of well tested and features rich unique Standard modules (it might be a subset of the Forge or a set of git repos with only one module for application) Is that valuable? Alas, I'm more of developer then user these days so I would defer that to our users. As a developer though - I would find it handy to have a guide for common things, I'm a pedant when it comes
[Puppet Users] Re: unable to install on Ubuntu 12.04
I know this post is 1 year old, but I was having a problem just like this and this was the first result on google. I'm just posting my experience in hopes that it might help someone else. I am using puppet enterprise 2.8.1 and installing the agents on a mix of Ubuntu 10.04 12.04 machines. The agents needed to be re-installed and whenever I tried I kept getting this pe-puppet-agent: unrecognized service message in the install log. My solution to re-installing the agent is to run the 'puppet-enterprise-uninstaller' script and run 'apt-get purge pe-puppet-agent' a combination of the allowed me to install the puppet agent successfully. However, the order of the two actions was different between the two versions. In 10.04, the purge command needs to be run before the uninstall script, otherwise it will fail. On Monday, August 6, 2012 5:21:25 PM UTC-7, alike wrote: This is my first time to install puppet and it's quite frustrating to me. If anyone can help me out that would be great. My current installation failed with the below error: ** /opt/puppet/bin/erb -T - './erb/send_cert_request.rb.erb' '/opt/puppet/bin/send_cert_request.rb' ** chmod a+rx /opt/puppet/bin/send_cert_request.rb ** /opt/puppet/bin/erb -T - './erb/receive_signed_cert.rb.erb' '/opt/puppet/bin/receive_signed_cert.rb' ** chmod a+rx /opt/puppet/bin/receive_signed_cert.rb ** chown -R pe-puppet:pe-puppet /var/opt/lib/pe-puppet/ /var/opt/lib/pe-puppetmaster/ /var/log/pe-puppet/ ** /opt/puppet/bin/puppet agent --configprint certname --color=false hadoop53 ** printf START=true\nDAEMON_OPTS=''\n /etc/default/pe-puppet-agent ** service pe-puppet-agent start pe-puppet-agent: unrecognized service I am stuck now and have no idea what to do. Here are the steps I took to see this error. 1. First time install. Got host not found error. I am using a simple host name hadoop53. 2. I added hadoop53 to my /etc/hosts file. 3. Uninstall mysql-server because I don't know the random password generated by puppet 4. uninstall puppet 5. Reinstall and got the error Thanks! Chang -- 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: Announce: Puppet Enterprise 2.8.2 Available [ Security Release ]
FYI, my bad! I had centos base repo disabled my first try. It is working now. :P === I tried using yum repo from puppetlab to install puppet client on centos5, it seems missing dependency virt-what and libselinux-ruby On Tuesday, June 18, 2013 10:09:59 AM UTC-7, Matthaus Litteken wrote: Dear Puppet Enterprise Users, Puppet Enterprise 2.8.2 is now available. This is a security release of Puppet Enterprise. All users of Puppet Enterprise are strongly encouraged to upgrade when possible to Puppet Enterprise 2.8.2. Puppet Enterprise 2.8.2 includes fixes to address CVE-2013-3567. For more information on this vulnerability, please visit http://puppetlabs.com/security/cve/cve-2013-3567. As a current Puppet Enterprise user, you can upgrade to this new version as part of your annual subscription. If upgrading, it is recommended to upgrade your master and console servers first. As always, we want to hear about your experiences with Puppet Enterprise. If you have any questions about upgrading, be sure to get in touch with Puppet Labs Support. Thanks, Matthaus Owens 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] undefined method `[]' for nil:NilClass
To diagnose this you'll want to get a full stack trace. Since the error is
on the master you run the master with --trace and then find the stack trace
in the log.
On Tue, Jun 18, 2013 at 11:08 AM, Greg Chavez greg.cha...@gmail.com wrote:
I upgrade our infrastructure (mostly RHEL5, some RHEL6) from 3.1 to
puppet-3.2.1-1.el5. Ruby sits at ruby-1.8.7.370-1.el5. I ran some
tests and everything seemed good so I pushed it out.
Since then, all my puppet clients are failing with this:
Error: Could not retrieve catalog from remote server: Error 400 on
SERVER: undefined method `[]' for nil:NilClass at
/etc/puppet/modules/site/manifests/init.pp:7 on node
maps-cs-vm-03u.streamsage.com
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run
Googling shows that this is a common error that crops up for any
number of reasons. I wonder what my reason is in this case. I use
Cobbler as my ENC, so I have no node statements. Since I'm not using
hiera yet, my site/init.pp looks like this:
class site {
if $::operatingsystem == RedHat {
include puppet
include ypbind
include sudo
if $::ipaddress =~ /^192\.168\./ {
Class[puppet] - Class[ypbind] - Class[sudo]
} else {
include snmp
Class[puppet] - Class[snmp] - Class[ypbind] -
Class[sudo]
}
if $::hostname =~ /[dqcpu]$/ {
include yum
include java
}
# Fixes for mayhem caused by Dell Puppet repos
package {dell-omsa-repository: ensure = absent }
file {/etc/yum.repos.d/dell-omsa-repository.repo: ensure = absent
}
file {/etc/yum.repos.d/puppet-delete-me.repo: ensure = absent}
notify {ENV == ${environment}:}
package { koan:
ensure = latest,
}
# artifact of setting the OOB IP in Cobbler
file { /etc/sysconfig/network-scripts/ifcfg-oob:
ensure = absent;
}
} elsif $::operatingsystem == Ubuntu {
notify {Howdies! I am running Ubuntu!: }
include ntp
include puppet
Class['ntp'] - Class['puppet']
}
}
Line 7 is include sudo. This is a modified version of saz-sudo-2.0.2.
Any ideas? Thanks.
--
\*..+.-
--Greg Chavez
+//..;};
--
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] augeas
Hello guys, I am facing a problem with puppet client installed via gem due Ruby EE. The problem is the following: puppetd -vt info: Caching catalog for #FQDN err: Could not run Puppet configuration client: Could not find a default provider for augeas I have tried to install ruby-augeas(gem install ruby-augeas) but it returns an error while compiling(make can not compile it). My ruby version is: ruby 1.8.7 (2009-12-24 patchlevel 248) [x86_64-linux], MBARI 0x6770, Ruby Enterprise Edition 2010.01 And my puppet client version is: 2.6.2 Do you guys have any idea on how to solve this problem ? Thank you -- 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] Pushing file updates - taking a long time
Hi. First off my situation is this; I have a module that's split up in such a way that it runs as follows: Install packages = Ensure files are present = insure service is running. Now say I have a stable cluster up and running. I want to push a new file change on a configuration to all slaves; Is there any reason puppet would try to install packages and start services again? Any help appreciated. Thank you. -- 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-dashboard work well but can't see any node
On 13-06-17 04:04 AM, Rajat Patel wrote: Hi Guys, We have Cent OS 6.4 server which is puppet master server, its take all mix environment(fedora/redhat/centos/windows). Right now we have add 2 node one from ubuntu 12.10 and fedora 18. If the dashboard is using ruby 1.8.x, it cannot process reports coming from puppet using ruby 1.9.x. I know F18 is ruby 1.9 and CentOS 6.4 is ruby 1.8, so that may be the problem. http://projects.puppetlabs.com/issues/10422 Do you see the error messages in Dashboard? -- Konrad Scherer, Sr. Engineer, Linux Products Group, Wind River direct 613-963-1342 fax 613-592-2283 -- 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] StartWait in Windows EXE Package Provider
I'm having some trouble getting a silent install of Firefox to run with the
windows package provider. My manifest looks like this:
package { Firefox Setup 21.0:
ensure = installed,
source = 'C:\\Files\\Firefox Setup 21.0.exe',
install_options = ['/S']
}
When this is executed by 'puppet apply', the following windows command line
is executed:
cmd.exe /c start /w C:\\Files\\Firefox Setup 21.0.exe /S
If this didn't have the '/S' parameter, it would work, but with the '/S'
parameter, it returns an Incorrect function error. According to some blog
posts I have found (e.g.
http://www.catonrug.net/2013/04/start-wait-quotes-invalid-switch.html ),
this is a result of the START command believing that the '/S' switch is
intended for the START command, rather than passing it to the Firefox
setup exe.
One way of resolving this is to add a title parameter to the START
command, which makes it interpret the rest of the line as parameters.
First, am I missing something? Is anybody else using the EXE package
provider and seeing this problem?
If this is a real problem, should I submit a bug and patch, or would
someone else like to verify my assumptions?
Thanks!
Josh
--
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: Accessing other parts of the Hiera tree
You might find it convenient and logical to structure it as one
large, complex, nested value, from which the individual
components would select the pieces they need. For example, a
hash with VM hostnames as keys, and hashes of VM names to VM
parameter hashes as values (i.e. a trebly-nested hash).
Alternatively, there are ways you could spread out the data over
multiple Hiera keys, but the overall logical structure is going
to be similar.
*nodnod* OK, that seems sane, thanks.
Thanks again for the push there; it really helped.
FWIW, what I've got is actually a hybrid, combining a structured
giant hiera data tree with hierarchical class overrides; this seems
useful so I'll show y'all.
Here's a snippet of the hosts structure, which lives in hosts.yaml:
-
hosts:
dev01.[snip]:
# type, environment, and site are all used to *find* what we
# inherit from in hiera, and hence cannot themselves be inherited,
# or at least not in a reasonable fashion
fqdn: dev01.[snip]
type: cytoweb
type_version: 3
environment: dev
site: dev01
ipv6: false
ipv4: true
ipv4_ip: [snip]
openvzid: 6222
openvzhost: ds518
qa01.[snip]:
# type, environment, and site are all used to *find* what we
# inherit from in hiera, and hence cannot themselves be inherited,
# or at least not in a reasonable fashion
fqdn: qa01.[snip]
type: cytoweb
type_version: 2
environment: qa
site: qa01
ipv6: false
ipv4: true
ipv4_ip: [snip]
openvzid: 8589
openvzhost: ds988
-
Here's the relevant bit of site.pp; *all* other puppet decisions are
hiera driven:
- -
$hosts = hiera_hash('hosts')
$host_type = $hosts[$fqdn]['type']
$host_type_version = $hosts[$fqdn]['type_version']
# Make sure our type can be loaded
$type_test = hiera('type_loaded')
notify{ sphtf: message = site.pp: host type file:
hiera/types/${::host_type}_v$host_type_version }
$host_environment = $hosts[$fqdn]['environment']
$host_site = $hosts[$fqdn]['site']
node default {
notify{ spht: message = site.pp: host type: $::host_type }
notify{ sphtv: message = site.pp: host type version:
$::host_type_version }
hiera_include('classes')
}
- -
So we grab some specific bits out of the host structure for the
current host, but then, and this is the fun part, we *turn them back
into hiera selectors*; this is my hiera.yaml:
- -
---
:backends:
- yaml
:yaml:
:datadir: /opt/puppet3/etc/hiera
:hierarchy:
- node/%{::fqdn}
- types/%{::host_type}_v%{::host_type_version}
- site/%{::host_site}
- environments/%{::host_environment}
- os/%{::operatingsystem}
- osfamily/%{::osfamily}
- hosts
- sites
- users
- common
# options are native, deep, deeper
:merge_behavior: deeper
- -
So this means that qa01.[snip] can have behaviour driven by
information in the global hosts structure, which can be accessed by
everybody for global things like generating an /etc/hosts file,
*and* it can have hiera/node/qa01.[snip] , which can have class
overrides like:
sudo::dev_sudo: true
or whatever.
Note in addition that with deeper merging setup, if you use
hiera_hash as I've done, you can actually override bits of the
structure.
We don't use this for the hosts structure, but we *do* use it for
users:
create_resources( users::user, hiera_hash('users::users') )
is how that structure gets used, and individual hosts can have
things like:
---
users::users:
stu:
ensure: present
until: 'Mon Jun 24 12:59:12 PDT 2013'
andrew:
ensure: present
until: 'Mon Jun 24 12:59:12 PDT 2013'
in their node/hostname.[snip] files, which will override those parts
of the users::user structure, in which those users default to
enable: false. users::user, like hosts, is a big giant nested
hash.
Hopefully this all is of use to someone.
-Robin
--
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] How can an ENC get the --environment value specified on a puppet agent commandline?
Is there any way to pass puppet run details to an ENC. Most importantly I want to know the Environment value the puppet Agent is asking for. More generally is it possible to query the puppet configuration values? One thought I had is to turn the puppet config into FACTS. Then the ENC can get the latest values from either Inventory Services or Foreman. But off hand I don't know how I could turn the puppet Agent command-line options into Facts without putting a wrapper around the puppet command itself. -- 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.
