Re: [Puppet Users] Re: Puppet 2.7 v 3.0 in the PuppetLabs yum repo
On Sun, Oct 14, 2012 at 11:27 AM, Jakov Sosic wrote: > On 10/08/2012 09:21 PM, Jeff McCune wrote: > > I hope this helps and thank you again for reporting this issue, >> > > I think the easiest way of handling this issue is to have different > repositories for different versions of puppet. > I would certainly +1 this method! I was bitten by the puppet 3.x packages for 2 reasons. The first one is that in my kickstart configs, I have "puppet" specified as a package which gets installed during installation and performs some trickery to run Puppet for the first time on the client, and get the certificate signed. As Puppet 3.x was now being installed by yum, it broke our installations. My workaround was to set "puppet-2.7" in the kickstart file, but far from ideal :( I was then bitten by Puppet doing what it's supposed to do :) As I had ensure => latest for the Puppet client, it went around and upgraded a lot of my clients to 3.x, which broke things. I guess I never expected such incompatible packages to be made available in the puppetlabs yum repo, but there's always a first :) It looks like Puppetlabs are well aware of this issue, so I look forward to the resolution. Personally, I think packages should be grouped in a logical manner, so that any package in the group will not (or should not) break functionality if upgraded. - Gonzalo -- 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] One client out of 150 doesn't apply config changes
In regard to: [Puppet Users] One client out of 150 doesn't apply config...: I have one puppet client that suddenly stopped applying configuration changes during the. I'm running with -v to see errors - no errors are shown and the puppet run completes with: info: Caching catalog for info: Applying configuration version '1349982313' notice: Finished catalog run in 49.28 seconds Does it change if you also add '--no-noop' to the puppet apply command? Is it possible someone modified /etc/puppet.conf and added 'noop = true'? Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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] RHEL 5: Stuck on Puppet 2.7
On 10/09/2012 07:48 PM, Craig White wrote: different strokes for different folks. ruby and the various gem packages move so fast that no packaging > system really has a chance of keeping up. It's also extremely > likely that what we are talking about is a puppet master where > you will have to resort to gem packaging anyway to install rails/rack > and other things anyway. Yeah tell me about it... I'm building RPMs for few ruby-on-rails apps, and this is a net result for RedMine 2.0 only: http://ftp.srce.hr/srce-redhat/test/el6/x86_64/ it took me 2 days to get it done. But then again - this way I have a clean and maintainable way of both deploying and upgrading stuff on my servers, so although it's time consuming, if you have to replicate the solution on more then 1 server and if your server runs ANYTHING other then (in this example) RedMine, then it's worth it. Do-it-and-forget-it... -- Jakov Sosic www.srce.unizg.hr -- 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] Where to place Custom Facts in Puppet module structure
On 09/25/2012 10:44 AM, Leonig Mig wrote: Any ideas what might be going wrong :) We ideally would like custom factor facts to be simply dropped into a module and available as such. Do you have pluginsync enabled on the agents? -- Jakov Sosic www.srce.unizg.hr -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Puppet 2.7 v 3.0 in the PuppetLabs yum repo
On 10/08/2012 09:21 PM, Jeff McCune wrote: I hope this helps and thank you again for reporting this issue, I think the easiest way of handling this issue is to have different repositories for different versions of puppet. So for example yum/rhel-compatible distros would have * 'puppet26-release-6-6' for puppet 2.6 * 'puppet27-release-6-6' for puppet 2.7 * 'puppet30-release-6-6' for puppet 3.0 That way, user can add for example repo 27 and not worry about it. When one decides to upgrade, it can simply replace puppet27-release with puppet30-release, which would provide newer version of packages (with the same name) which offers seamless upgrade to latest and greatest. I surely would not like to see all versions of puppet in same repository but with different names (like puppet26, puppet27, puppet30), cause that's not the purpose of version-in-the-name naming scheme - and it makes upgrades impossible. One would have to remove old version first and then install new version, and I surely would not want to do that on hundreds of machines :( -- Jakov Sosic www.srce.unizg.hr -- 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] Systems Provisioning
On 10/13/2012 11:17 PM, Stefan Schulte wrote: > If puppet has to sync ensure it will not sync any other property. That > means if your type defines "ensurable" or you have defined an ensure > property manually and your system is not yet present, your create method > is called and puppet expects the create method to create your system with > interfaces. My understanding of the problem was along those lines too. Now I have confirmation... > Otherwise you will see the described behaviour: > > 1) First run: Puppet finds out ensure is out of sync (is absent, should > be present) and calls create > 2) Second run: Puppet finds out interfaces is out of sync and and calls > interfaces= (or whatever method you have defined for that) I am already detecting in my create method if 'system' is added to 'cobbler' (if it's present on the machine agent is running on), and if it is, I choose to edit it rather then to try to create it again. So, can I just call method "interface=", if I detect I have to create the 'system', or is there any way to solve this issue? Problem is that cobbler is used for provisioning (PXE+installation), so when you add new 'system' to cobbler, you are going to try to install the machine immediately afterwards (in 99% of cases), so two puppet runs in this case really stand in the way of usability of the whole idea of puppetizing Cobbler setup. So I would love to circumvent it somehow if possible. Thank you -- 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] Automate adding new host to nagios server?
On Thu, 11 Oct 2012 17:03:05 +0200 Brent Clark wrote: > I was wondering if someone could help me. > > Say I have three servers. One puppet master, one webserver, and one > nagios server. > > Is there a way to automate the process of adding the web server to > the nagios server for monitoring via a puppet. > > If someone could assists, or suggest a better means, it would be > appreciated. As others already said, there exists exported resources. But IMHO is puppet not very good for exchanging information between hosts und you shouldn't use the exported resources much. Instead you should model your hosts somewhere else, maybe in hiera or in a complete other DB and transform this model in something puppet can use. Puppet is *not* a model of your environment, it's a config management system, host by host. Regards Oli -- 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] Systems Provisioning
On Sat, Oct 13, 2012 at 10:50:05PM +0200, Jakov Sosic wrote: > On 10/13/2012 05:55 PM, Dan White wrote: > > Is this module posted somewhere public ? > > Looks interesting enough to try out. > > It's not posted yet but it will be soon. I'm currently rewriting some > providers from CLI cobbler to XMLRPC calls, and I'm not yet fully > satisfied with integration with puppetlabs/apache module. I had to > modify apache module to make it work... > > > Also I have some minor issues, like first run adds system without > interfaces to cobbler, and subsequent run add interfaces. So you have to > run it twice to properly add the system. > > Maybe someone can point out is there a way to fix this, because I've > implemented interfaces as property and not param, so provider has > separate methods for checking/modifying current state, and I don't quite > get it why it doesn't run seamlessly in the first run > If puppet has to sync ensure it will not sync any other property. That means if your type defines "ensurable" or you have defined an ensure property manually and your system is not yet present, your create method is called and puppet expects the create method to create your system with interfaces. Otherwise you will see the described behaviour: 1) First run: Puppet finds out ensure is out of sync (is absent, should be present) and calls create 2) Second run: Puppet finds out interfaces is out of sync and and calls interfaces= (or whatever method you have defined for that) (see lib/puppet/transaction/resource_harness.rb#perform_changes) -Stefan -- 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] Systems Provisioning
On 10/13/2012 05:55 PM, Dan White wrote: > Is this module posted somewhere public ? > Looks interesting enough to try out. It's not posted yet but it will be soon. I'm currently rewriting some providers from CLI cobbler to XMLRPC calls, and I'm not yet fully satisfied with integration with puppetlabs/apache module. I had to modify apache module to make it work... Also I have some minor issues, like first run adds system without interfaces to cobbler, and subsequent run add interfaces. So you have to run it twice to properly add the system. Maybe someone can point out is there a way to fix this, because I've implemented interfaces as property and not param, so provider has separate methods for checking/modifying current state, and I don't quite get it why it doesn't run seamlessly in the first run Also, I don't have documentation ready yet :) Although if you want I can send you current snapshot and help with ongoing issues that occur. And ofcourse you don't have to use the whole module, you can use just custom types if you wish. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet liveManagement very slow
Try su-ing to the peadmin account and issuing `mco ping`. What kind of time are you seeing there? Live Management is a GUI front end to using mcollective and the peadmin account has all of the mco subcommands added to its path. If there's a reason mcollective is running slowly it will bog down Live Management. Also, there's a pe-users list that might be more beneficial to you. HTH, Justin On Fri, Oct 12, 2012 at 4:05 PM, skrishna12 wrote: > Hi , > I have installed puppet enterprise , master and agent in two nodes in a > cluster. > > Everything works perfeclty except live mangement console . clicking this > option take lot of time and finally it doesnot come up. It came 1 or 2 > times. > Can you explain what could be reason? > > Thanks > Leo > > -- > 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/-/ucSgRa8vvjgJ. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet master and Servants inside DMZ
On 10/09/2012 06:10 PM, Peter Spatz wrote: Hey, my puppet works great now. Plans are going in know. My FW admin said, he dont wan´t s the servants polling from inside DMZ to the Master. What´s the strategy then? Use kick, is this one connection doing all, or just wake up agent and he creates own new connection? There were few threads about similar issues - basically you have two choices: run masterless setup for the nodes in DMZ, or keep separate puppetmaster in DMZ, only for those hosts. 'Kick' is deprecated in 3.0, and users are advised to look at Mcollective for that use-case. And yes, 'kick' only wakes agent up, so that solution requires access from DMZ to puppetmaster too. -- Jakov Sosic www.srce.unizg.hr -- 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] Systems Provisioning
Is this module posted somewhere public ?
Looks interesting enough to try out.
On Oct 13, 2012, at 8:52 AM, Jakov Sosic wrote:
> On 09/19/2012 01:59 PM, Nick wrote:
>> Hi,
>>
>> A have a question related to this thread. I'd like to ask, is the Foreman
>> smart
>> proxy amenable to being configured using Puppet, to the extent of being able
>> to
>> define the systems that are PXE booted within Puppet? Or is there some other
>> existing means of configuring PXE booted systems from Puppet?
>>
>> Cheers,
>
> I don't know about foreman, but I have written cobbler puppet module with 4
> custom types (distro, profile, repo, system), so we manage cobbler entirely
> through puppet. It's more readable and easier to edit properties. For
> example, this is how a typical system looks like:
>
>
> cobblersystem { 'typical-node':
>ensure=> present,
>profile => 'CentOS-6.3-x86_64',
>interface => { 'eth0' => { mac => '00:AA:BB:CC:DD:EE', ip_address =>
> '192.168.1.99', subnet => '255.255.255.0', static => '1' }, },
>netboot => false,
>gateway => '192.168.1.1',
>require => Service[$cobbler::service_name],
> }
>
>
> --
> Jakov Sosic
> www.srce.unizg.hr
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: The free software tarballs are now difficult to find
On Friday, October 12, 2012 10:10:54 AM UTC-4, windowsrefund wrote: > > Recently, there have been some changes made to the Puppetlabs website > which result in the free software releases being difficult to locate and > download. > > Visitors using the download links are taken directly to the non-free > "Enterprise" option rather than being presented with an option. > > Personally, I'd like to see the site reverted so users have the option. > > FYI, the wiki section still provides this useful content here: > > http://projects.puppetlabs.com/projects/1/wiki/downloading_puppet > > Best, > Adam Kosmin > I was asking this on IRC the other day. I understand the need to collect information for prospective customers, however requiring a pay wall (personal information) to access the open source tarballs does not seem to be in the spirit of free software[1]. [1] http://www.gnu.org/philosophy/free-sw.html -- 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/-/ELcaL9l4VwkJ. 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] Systems Provisioning
On 09/19/2012 01:59 PM, Nick wrote:
Hi,
A have a question related to this thread. I'd like to ask, is the Foreman smart
proxy amenable to being configured using Puppet, to the extent of being able to
define the systems that are PXE booted within Puppet? Or is there some other
existing means of configuring PXE booted systems from Puppet?
Cheers,
I don't know about foreman, but I have written cobbler puppet module
with 4 custom types (distro, profile, repo, system), so we manage
cobbler entirely through puppet. It's more readable and easier to edit
properties. For example, this is how a typical system looks like:
cobblersystem { 'typical-node':
ensure=> present,
profile => 'CentOS-6.3-x86_64',
interface => { 'eth0' => { mac => '00:AA:BB:CC:DD:EE', ip_address
=> '192.168.1.99', subnet => '255.255.255.0', static => '1' }, },
netboot => false,
gateway => '192.168.1.1',
require => Service[$cobbler::service_name],
}
--
Jakov Sosic
www.srce.unizg.hr
--
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.
