Re: [Puppet Users] Supported Ruby Versions for Telly
I would have no problem trying either one of these, but the PHB-objections I face are that these do not come from Red Hat or a reliable source. They might trust them if they came from PuppetLabs' repository, but even that is no guarantee. They are inconsistently paranoid about what they will permit into their production environment. They had kittens when I initially pulled Cobbler and Puppet from EPEL, while they build replacements for some packages from source and install from the source build rather than with an RPM. Please tell me if I understand the versioning requirements: I need ruby 1.8.7 or 1.9.3 on the machine acting as Puppet Master. The clients/agents can use ruby 1.8.5 for now. Is that accurate ? On Apr 15, 2012, at 12:03 AM, Craig White wrote: enterprise ruby (1.8.7 only) http://www.rubyenterpriseedition.com/download.html Craig On Apr 15, 2012, at 12:55 AM, Gary Larizza wrote: Have you checked out the packages that Karanbir Singh has created? They work fairly well -- http://centos.karan.org/el5/ruby187/ On Sat, Apr 14, 2012 at 8:53 PM, Dan White y...@comcast.net wrote: Great to hear this, but I am now looking for a reliable way to get Ruby 1.8.7 or 1.9.3 onto a RHEL-5 system. The environment I am working still has RHEL 3 and 4 machines running, and I would not hold my breath waiting for transition to RHEL 6 (which does have ruby 1.8.7 in it) One more thing: When I say reliable, it has to be able to convince a non-technical PHB type. Suggestions ? On Apr 13, 2012, at 2:59 PM, Michael Stahnke wrote: Puppet Labs is happy to announce full support for Ruby 1.9.3 will be part of the next major release of Puppet, codenamed Telly. Ruby 1.8.7 and 1.9.3 are considered the primary supported Ruby versions, on all platforms including Unix, Linux, Windows, and MacOS-X. Ruby 1.8.5 is also supported, on the agent only. The Puppet 2.7 series featured initial support for the Ruby 1.9 series, and we are happy to see that work completed and brought forward to full production support in the forthcoming release. Other Ruby versions including 1.8.6, 1.9.1, and 1.9.2 are not officially supported. Ruby implementations other than the MRI series are not officially supported. We will accept patches that fix issues on other (non MRI) Ruby systems. 1.9.3 was selected due to its inclusion in Fedora 17 (Beefy Miracle) and Ubuntu Precise Pangolin. Previews of Telly should be available in May. If you'd like to see some of the changes happening today, you are also welcome to run Puppet's master branch. If you have questions or concerns, feel free to respond here. Mike Stahnke Community Manager -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- Gary Larizza Professional Services Engineer Puppet Labs -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Supported Ruby Versions for Telly
You might have the best luck going the route of Well, my puppetmaster needs RHEL6 and that's the only way it's supported because then you get 1.8.7 from an official source. I completely sympathise with your situation, having been in it before. Your understanding is right to the best of my knowledge, I wouldn't try and run the master on 1.8.5, but clients should work with the stock RHEL5 Ruby. On Sun, Apr 15, 2012 at 11:29 AM, Dan White y...@comcast.net wrote: I would have no problem trying either one of these, but the PHB-objections I face are that these do not come from Red Hat or a reliable source. They might trust them if they came from PuppetLabs' repository, but even that is no guarantee. They are inconsistently paranoid about what they will permit into their production environment. They had kittens when I initially pulled Cobbler and Puppet from EPEL, while they build replacements for some packages from source and install from the source build rather than with an RPM. Please tell me if I understand the versioning requirements: I need ruby 1.8.7 or 1.9.3 on the machine acting as Puppet Master. The clients/agents can use ruby 1.8.5 for now. Is that accurate ? On Apr 15, 2012, at 12:03 AM, Craig White wrote: enterprise ruby (1.8.7 only) http://www.rubyenterpriseedition.com/download.html Craig On Apr 15, 2012, at 12:55 AM, Gary Larizza wrote: Have you checked out the packages that Karanbir Singh has created? They work fairly well -- http://centos.karan.org/el5/ruby187/ On Sat, Apr 14, 2012 at 8:53 PM, Dan White y...@comcast.net wrote: Great to hear this, but I am now looking for a reliable way to get Ruby 1.8.7 or 1.9.3 onto a RHEL-5 system. The environment I am working still has RHEL 3 and 4 machines running, and I would not hold my breath waiting for transition to RHEL 6 (which does have ruby 1.8.7 in it) One more thing: When I say reliable, it has to be able to convince a non-technical PHB type. Suggestions ? On Apr 13, 2012, at 2:59 PM, Michael Stahnke wrote: Puppet Labs is happy to announce full support for Ruby 1.9.3 will be part of the next major release of Puppet, codenamed Telly. Ruby 1.8.7 and 1.9.3 are considered the primary supported Ruby versions, on all platforms including Unix, Linux, Windows, and MacOS-X. Ruby 1.8.5 is also supported, on the agent only. The Puppet 2.7 series featured initial support for the Ruby 1.9 series, and we are happy to see that work completed and brought forward to full production support in the forthcoming release. Other Ruby versions including 1.8.6, 1.9.1, and 1.9.2 are not officially supported. Ruby implementations other than the MRI series are not officially supported. We will accept patches that fix issues on other (non MRI) Ruby systems. 1.9.3 was selected due to its inclusion in Fedora 17 (Beefy Miracle) and Ubuntu Precise Pangolin. Previews of Telly should be available in May. If you'd like to see some of the changes happening today, you are also welcome to run Puppet's master branch. If you have questions or concerns, feel free to respond here. Mike Stahnke Community Manager -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- Gary Larizza Professional Services Engineer Puppet Labs -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Supported Ruby Versions for Telly
On Sun, Apr 15, 2012 at 08:29, Dan White y...@comcast.net wrote: I would have no problem trying either one of these, but the PHB-objections I face are that these do not come from Red Hat or a reliable source. They might trust them if they came from PuppetLabs' repository, but even that is no guarantee. They are inconsistently paranoid about what they will permit into their production environment. They had kittens when I initially pulled Cobbler and Puppet from EPEL, while they build replacements for some packages from source and install from the source build rather than with an RPM. Please tell me if I understand the versioning requirements: I need ruby 1.8.7 or 1.9.3 on the machine acting as Puppet Master. The clients/agents can use ruby 1.8.5 for now. That is spot-on. -- Daniel Pittman ⎋ Puppet Labs Developer – http://puppetlabs.com ♲ Made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Telly: Nagios types moving into Module
On Fri, Apr 13, 2012 at 12:06 PM, Ashley Penney apen...@gmail.com wrote: I think that would be OK. I'm actually fairly nervous about this new move towards dragging more and more out of the core into modules. It wouldn't be so bad if Puppet had a proper packaging system that handled dependencies and so forth, but as it stands I'm just worried about reaching a situation where we're constantly telling people in #puppet oh, well first you need to get stdlib, nagios, yum, this, that, etc, that's why you can't do this. It's important to note here that the version of the module tool we're talking about does indeed handle dependencies automatically, although prior versions didn't. However assuming this is going ahead then I think the error message should probably for now tell the user that they've been moved AND spit out an appropriate commandline to immediately import the module to the right place. On Fri, Apr 13, 2012 at 1:55 PM, Michael Stahnke stah...@puppetlabs.comwrote: For the next major Puppet version, code-named Telly, we have some changes coming. This is the first in a series of emails around these changes and may require some input from the community. For Telly, the nagios types will be moved into a module. This allows them to be iterated on in isolation from the rest of Puppet's core release cycle and process. In the future we have plans to move several other types into modules that can be individually maintained, improved, tested and used. The module for Nagios will be available on the Forge. The upgrade path is the thing we need some feedback about. The basic steps to upgrade would be to setup a Telly master, and then install the Nagios module via the Puppet Module Tool, which ships integrated with 2.7.13+ and Telly. The only caveat with this is that if, in the past, you were relying on the Nagios types and forget to install that module (or are unable to for some reason), you would get a failure. The best proposal we could come up with was to have the platform team add some code that lets the user know that the Nagios types have moved. This basically moves this into a 'fail-well' state. We'll try to provide the best information possible to the end-user about what is going on. Is that an acceptable path moving forward? Comments and discussion welcome. Mike Stahnke Community Manager -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- Nigel Kersten Product Manager, Puppet Labs -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] New CA, why do clients with old certs still work?
On Fri, Apr 13, 2012 at 11:40 AM, Chip Schweiss chip.schwe...@gmail.comwrote: I'm in the process of scalling my puppet master to two server with a separate CA. My plan was to establish a new CA and reissue certificates. Part way through the process I noticed a behavior that seems a bit alarming. With one of my clients pointing to the new CA and new Puppetmaster but with the old certificate I ran a 'puppetd --test --server puppet01.mydomain' I was expecting it to fail validation and then regenerate the client certificate. However it ran without error. Thinking maybe it's still hitting the orginal CA, I backed-up and wiped the ssl dir on the puppetmaster and restarted the pupetmaster to generate a new CA. The client still works. There are no signed certificates for this client on either puppetmaster or CA now and it still runs. Are you sure you're wiping the SSL dir that is actually in use? The master isn't being started with --no-ca and you have another CA with autosign on? Am I missing something about how the puppetmaster decides it's okay to talk to a client, or is all the security simply on the client side, and the puppetmaster trusts any puppet client? The agent and master need certs signed by the same CA. Are you positive this wasn't the case? What puppet version? -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Need puppet module for condition copy
On Apr 13, 10:49 am, Munna S 19.mu...@gmail.com wrote:
I followed your steps. now i am getting below error
Apr 13 17:42:44 pil-vm-pup-01 puppet-master[7899]: Could not find class
dev_jboss_jeeva for vm-jeeva2.aircell.prod at
...
i have jeeva_base.pp file under /etc/puppet/manifests/nodes and below is
its content
node jeeva_base {
include dev_jboss_jeeva}
--
also i have a another .pp file by name vm-jeeva2 under
/etc/puppet/manifests/nodes and below is its content. we have seperate .pp
file for each server name. one server is vm-jeeva2.
--
node vm-jeeva2 inherits jeeva_base {}
what could be the problem ?
Where is the class dev_jboss_jeeva defined? You mentioned above an
'init.pp', which would be usual if you were using modules, but it does
not seem like you are using modules.
It sounds like the problem you are having is wholly outside of the
complicated machinations of what you're trying to do. It looks more
like you have a much simpler class-loading problem.
Here are a few things to try:
* Comment out all of the stuff from dev_jboss_jeeva and replace it
with a warning function call, to log that everything is working
right:
class dev_jboss_jeeva {
warning(dev_jboss_jeeva has successfully loaded)
}
* Copy your class dev_jboss_jeeva { ... } right before the node
jeeva_base and see if you see your warning message (I suggest warning
instead of info because info sometimes requires using --verbose on the
command line; warning will always show):
class dev_jboss_jeeva {
warning(dev_jboss_jeeva was here)
}
node jeeva_base {
include dev_jboss_jeeva
}
If you see the message with the class defined right before the node,
but not wherever else you have it, then you know the problem is that
it is unable to actually find the class and you should give specifics
about that instead.
Wil
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Telly: Nagios types moving into Module
On 12-04-13 03:06 PM, Ashley Penney wrote: I'm actually fairly nervous about this new move towards dragging more and more out of the core into modules. It wouldn't be so bad if Puppet had a proper packaging system that handled dependencies and so forth, but as it stands I'm just worried about reaching a situation where we're constantly telling people in #puppet oh, well first you need to get stdlib, nagios, yum, this, that, etc, that's why you can't do this. humm I must agree with this. Since the types by themselves are not a module per-se, could it be better to package them in the same manner as the core is packaged, and made available through the same resources? so then, people could install those with gem, apt or yum. (and easily require those automatically from actual modules) -- Gabriel Filion -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Telly: Nagios types moving into Module
Well, i think there's a big difference between things that are standard in a linux distro and modules that are 3rd party software like nagios. Besides I think this is all adressed by what Nigel just mentioned: the moduel tool does dependency stuff starting with Telly. cheers, Walter On Mon, Apr 16, 2012 at 11:53, Gabriel Filion lelu...@gmail.com wrote: On 12-04-13 03:06 PM, Ashley Penney wrote: I'm actually fairly nervous about this new move towards dragging more and more out of the core into modules. It wouldn't be so bad if Puppet had a proper packaging system that handled dependencies and so forth, but as it stands I'm just worried about reaching a situation where we're constantly telling people in #puppet oh, well first you need to get stdlib, nagios, yum, this, that, etc, that's why you can't do this. humm I must agree with this. Since the types by themselves are not a module per-se, could it be better to package them in the same manner as the core is packaged, and made available through the same resources? so then, people could install those with gem, apt or yum. (and easily require those automatically from actual modules) -- Gabriel Filion -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- Walter Heck -- follow @walterheck on twitter to see what I'm up to! -- Check out my new startup: Server Monitoring as a Service @ http://tribily.com Follow @tribily on Twitter and/or 'Like' our Facebook page at http://www.facebook.com/tribily -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Telly: Nagios types moving into Module
On Friday, April 13, 2012 3:06:52 PM UTC-4, Ashley Penney wrote: I think that would be OK. I'm actually fairly nervous about this new move towards dragging more and more out of the core into modules. It wouldn't be so bad if Puppet had a proper packaging system that handled dependencies and so forth, but as it stands I'm just worried about reaching a situation where we're constantly telling people in #puppet oh, well first you need to get stdlib, nagios, yum, this, that, etc, that's why you can't do this. Newer versions of Puppet include an updated module tool that handles dependencies and some other niceties: Check out The Puppet Module Tool Screencast http://www.youtube.com/watch?v=nDTrmHW7I-A However assuming this is going ahead then I think the error message should probably for now tell the user that they've been moved AND spit out an appropriate commandline to immediately import the module to the right place. On Fri, Apr 13, 2012 at 1:55 PM, Michael Stahnke stah...@puppetlabs.comwrote: For the next major Puppet version, code-named Telly, we have some changes coming. This is the first in a series of emails around these changes and may require some input from the community. For Telly, the nagios types will be moved into a module. This allows them to be iterated on in isolation from the rest of Puppet's core release cycle and process. In the future we have plans to move several other types into modules that can be individually maintained, improved, tested and used. The module for Nagios will be available on the Forge. The upgrade path is the thing we need some feedback about. The basic steps to upgrade would be to setup a Telly master, and then install the Nagios module via the Puppet Module Tool, which ships integrated with 2.7.13+ and Telly. The only caveat with this is that if, in the past, you were relying on the Nagios types and forget to install that module (or are unable to for some reason), you would get a failure. The best proposal we could come up with was to have the platform team add some code that lets the user know that the Nagios types have moved. This basically moves this into a 'fail-well' state. We'll try to provide the best information possible to the end-user about what is going on. Is that an acceptable path moving forward? Comments and discussion welcome. Mike Stahnke Community Manager -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/87YHcX_tf9UJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
