[Puppet Users] Re: Puppet on Centos 6.0
Hi trey, I put it here: https://github.com/alexfouche/rvm On 19 oct, 21:07, Robert Mortimer wrote: > I got it installed in the end: > > 1) Only install dev libraries for the architecture you are using (gcc > and mysql dev) > 2) Gems from source (not RPM) were used > 3) Active record can not be the latest version (down grade was required) > > The only other option is to roll your own RPM or scavenge them from > elsewhere on the net. As that can screw up the whole OS update I would > avoid it unless you have a development environment and lots of time. > It is not ideal and I do feel that if puppet is in the EPEL then the > required ruby dependencies should be there but I only run one puppet > server and a moderate number of clients so this is not a project I > would take on. > > My contribution when I get a moment will be a how-to to prevent > someone else going through my pain > > > > On 19 October 2011 11:21, Alexandre wrote: > > > > > > > > > Why not use RVM ? It wll be easy to create a ruby env with its gems. > > It is in /usr/local and completely independant from the system ruby > > and all gems. I enforce not putting any files on the system which are > > not part of a RPM. > > > For example, i use the puppetmaster and puppet rpms, so that both run > > and use the standard ruby 1.8.7 without any need of gem (i do not use > > mysql). But for the cloud provisioner that needs a lot of gems which > > do not exist as RPM, i put RVM and told it to have a ruby-1.8.7 with > > my needed gems. I put the default on rvm to keep using the default > > ruby, so that it will not impact on anything for my system, but i > > created a RVM wrapper for the second ruby, so that that i use this > > wrapper to run my puppet command when needing to do cloud actions. > > > You could have a similar setup, but having your puppetmaster and > > puppet client using the rvm wrapped ruby and gems (eg the mysql gem), > > and you will not have to worry about trashing your system with files > > not part of RPMs > > > I have a Puppet recipe to install rvm, manage rubies, gems, etc... > > Tell me if you are interested, i could post it > > > On 18 oct, 23:56, jcbollinger wrote: > >> On Oct 18, 11:43 am, Michael Stahnke wrote: > > >> > On Tue, Oct 18, 2011 at 6:19 AM, jcbollinger > >> > wrote: > >> [...] > >> > > I, on the other hand, would recommend avoiding gems altogether if > >> > > you're using the system's Ruby (i.e. one you installed from an RPM, > >> > > whether via yum or otherwise). Ruby modules installed via RPM are not > >> > > (should not be) gems. Using both gem and rpm to manage the same Ruby > >> > > installation is begging for trouble. > > >> > Why? The packages of many ruby libraries are basically gems wrapped > >> > in RPM. Basically it allows the library/tool to be registered with > >> > the RPM and gem database. I admit it's not my favorite thing to have > >> > gems (and not RPMs), but technically there is almost nothing wrong > >> > with it, other than future RPMs can't depend on something from a gem > >> > install only. > > >> As others have described, if you use gems and RPMs on the same Ruby > >> installation then you have two different sources of truth. They can > >> and will disagree about what modules (to use a somewhat generic term) > >> are installed. Their respective repositories can and will provide > >> different versions of some modules, and different configurations of > >> some other modules. Using both together on the same Ruby installation > >> can and will make a hash of your Ruby library. Eventually. If you're > >> lucky, you'll notice. > > >> Even RPMs registering their Ruby payloads with the gem database does > >> not solve the problem, because gem is not so accommodating about > >> synchronizing the RPM database. In any case, it is not safe to assume > >> that *all* RPMs with Ruby payloads will install modules as gems. > > >> > There are plenty of other debates about rubygems, and whether or not > >> > they are useful or helpful or anything. But as far as having a system > >> > with ruby and using to gem to install things, it will work and is > >> > always all that bad. > > >> Please don't misunderstand: I have no particular complaint about gem > >> itself. If you want all its gemtacular goodness then install a local > >> Ruby build and go wild in it with gems. As long as you put it in a > >> reasonable place (e.g. /usr/local) no RPM will touch it, so no > >> problem. > > >> Of course, you have no obligation whatever to do as I advise. If you > >> choose to use both gems and RPMs on the same Ruby then I wish you luck > >> -- you're a braver man than I. > > >> John > > > -- > > You received this message because you are subscribed to the Google Groups > > "Puppet Users" group. > > To post to this group, send email to puppet-users@googlegroups.com. > > To unsubscribe from this group, send email to > > puppet-users+unsubscr...@googlegroups.com. > > For more options, visit this
[Puppet Users] Re: Puppet in the DMZ via proxy
I also had such a scheme, but having the puppetmaster on an internal private IP network, not even a DMZ. Puppet runs were triggered, there was no puppet client daemon or crontabed runs. server with Puppet client is on interent with public IP Local intranet: Puppetmaster a Squid proxy When i want to puppetize a machine, from my local workstation in the same network as the puppetmaster and squid, i connect with ssh creating a tunnel -L 3128:squidserver:3128 . Once logged, i launched puppet --server puppetmaster.local --test --http_proxy_host localhost --http_proxy_port 3128 -> The Puppet client connects to the intranet proxy though the tunnel. The proxy can route to the puppetmaster. I keep the tunnel open just for the time of the puppetize On 20 oct, 21:14, "Kinzel, David" wrote: > >On Thu, Oct 20, 2011 at 12:46 PM, Geoff Galitz > > wrote: > > >> We're thinking of ways to get our DMZ nodes managed by puppet, and in > >> the absence of a full-fledged push model we are thinking about > >> pointing puppets in our DMZ network at a bastion host > >running squid to > >> proxy back to our puppet master. > > >> In this scenario, the single bastion host would have an ACL allowing > >> access through our inner firewall to the master, but the > >various nodes > >> would have no direct access. That would give us a nice choke point > >> that we can monitor and isolate if needed. We'd still get all of our > >> reporting functions, too. > > >> Has anyone tried something along these lines? Any opinions? > > We have an allow-list of hosts which connect to a NAT IP that gets forwarded > internally. This is a simpler setup than having a proxy do it. > > This email communication and any files transmitted with it may contain > confidential and or proprietary information and is provided for the use of the > intended recipient only. Any review, retransmission or dissemination of this > information by anyone other than the intended recipient is prohibited. If you > receive this email in error, please contact the sender and delete this > communication and any copies immediately. Thank you. > > http://www.encana.com -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-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] Problem(s) with installing Puppet Dashboard
Hello! I'm trying to install puppet dashboard according to the instructions in the documentation : http://docs.puppetlabs.com/dashboard/manual/1.2/bootstrapping.html I am installing it from the .deb package, however after installation I cannot find the "settings.yml" file. Also, when trying to "prepare schema" by running rake RAILS_ENV=production db:migrate it returns: rake RAILS_ENV=production db:migrate rake aborted! No Rakefile found (looking for: rakefile, Rakefile, rakefile.rb, Rakefile.rb) /usr/lib/ruby/1.8/rake.rb:2377:in `raw_load_rakefile' (See full trace by running task with --trace) Am I missing something (doing something wrong)? -- 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: Module Dependency with a service
> On Fri, Oct 21, 2011 at 10:25 AM, Aaron Grewell > wrote: > > If tomcat::enable is in a separate file you'll want to 'include' it in > > tomcat::server to ensure it's in scope. On Oct 21, 3:50 pm, Douglas Garstang replied: > Isn't the net result of including something the same as it's really > there already? If so, the final result is the same... the service > resource ends up in the tomcat::server class no? The net result on the compiled catalog is the same, if the catalog compiles successfully, but the effect on the compilation process is not necessarily the same. I think it is an evaluation order issue. The bottom line is that you should ensure that every resource your manifests refer to is in scope (which probably means "already defined") at the point of reference, and one way to ensure a resource is in scope is to 'include' or 'require' the class containing it. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-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] Scalability, Dashboard/Foreman, and MCollective
I've been trying to find information, suggestions, etc. for how to combine scaling Puppet with the use of management tools like Dashboard/Foreman and MCollective. Our current thinking for an initial deployment is two VMs as Puppet Master worker nodes fronted by a pair of NetScalers. However, I'm not sure how to go about implementing Dashboard or Foreman and MCollective servers in a redundant Puppet Master server environment. Can anyone speak to their experience in this matter and/or point me to resources that discuss such architectures? FWIW, we'll later implement multiple pairs of redundant Puppet servers to support environments we want managed separately, e.g. Production vs. Test. Thanks, Justin -- 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] Chaining behavior
Hello
I'm experimenting with the new resource chaining syntax. Here's the
code:
class first { notice("first") }
class second { notice("second") }
class third { notice("third") }
include third
include second
include first
Class["first"] -> Class["second"] -> Class["third"]
Shouldn't the last line guarantee that the classes are executed in
that specific order?
Thanks in advance,
Andre
--
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] Chaining behavior
The ordering only applies to the order in which resources are applied, not
the order in which the code is processed.
It will work like you expect if you switch out the calls to the notice
function with notify resources.
On Mon, Oct 24, 2011 at 3:48 AM, Andre Nathan wrote:
> Hello
>
> I'm experimenting with the new resource chaining syntax. Here's the
> code:
>
> class first { notice("first") }
> class second { notice("second") }
> class third { notice("third") }
>
> include third
> include second
> include first
>
> Class["first"] -> Class["second"] -> Class["third"]
>
> Shouldn't the last line guarantee that the classes are executed in
> that specific order?
>
> Thanks in advance,
> Andre
>
> --
> 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: Scalability, Dashboard/Foreman, and MCollective
On Oct 24, 5:38 pm, Justin Lloyd wrote: > I've been trying to find information, suggestions, etc. for how to combine > scaling Puppet with the use of management tools like Dashboard/Foreman and > MCollective. Our current thinking for an initial deployment is two VMs as > Puppet Master worker nodes fronted by a pair of NetScalers. However, I'm not > sure how to go about implementing Dashboard or Foreman and MCollective > servers in a redundant Puppet Master server environment. Can anyone speak to > their experience in this matter and/or point me to resources that discuss > such architectures? > > FWIW, we'll later implement multiple pairs of redundant Puppet servers to > support environments we want managed separately, e.g. Production vs. Test. > > Thanks, > Justin -- 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: Scalability, Dashboard/Foreman, and MCollective
Excuse my first misclick ;) On Oct 24, 5:38 pm, Justin Lloyd wrote: > I've been trying to find information, suggestions, etc. for how to combine > scaling Puppet with the use of management tools like Dashboard/Foreman and > MCollective. Our current thinking for an initial deployment is two VMs as > Puppet Master worker nodes fronted by a pair of NetScalers. However, I'm not > sure how to go about implementing Dashboard or Foreman and MCollective > servers in a redundant Puppet Master server environment. Can anyone speak to > their experience in this matter and/or point me to resources that discuss > such architectures? Clustering Puppet Masters is relatively easy, you'll have to think about how you're going to handle the shared Certificate Authority problem though. I've run a cluster of PMs with a separate PM just to act as the CA server and it worked well. If you want to cluster Dashboard that should also be quite easy, you just need a shared MySQL database to back onto. I've never used the ENC capabilities of Dashboard so I can't help you there, but for Dashboard reporting, all PMs can send to any server so I'd have them send to a Dashboard VIP on your load balancer and then you can balance your report processing as well. I can't advise on The Foreman. For MCollective, start reading about subcollectives[1] and Stomp failover pools [2]. There's no reason why each of your Puppet Masters can't also be Stomp servers. ActiveMQ has some nice abilities to send messages between ActiveMQ servers that I started reading up on (useful for when you start segregating dev and prod) but then I ran into scalability issues with ActiveMQ so replaced it with RabbitMQ and haven't looked at what you can do with that yet. Hope that's a good starting point for you, -Luke [1] http://docs.puppetlabs.com/mcollective/reference/basic/subcollectives.html [2] http://docs.puppetlabs.com/mcollective/reference/plugins/connector_stomp.html > FWIW, we'll later implement multiple pairs of redundant Puppet servers to > support environments we want managed separately, e.g. Production vs. Test. > > Thanks, > Justin -- 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: Scalability, Dashboard/Foreman, and MCollective
- Original Message - > For MCollective, start reading about subcollectives[1] and Stomp > failover pools [2]. There's no reason why each of your Puppet Masters > can't also be Stomp servers. ActiveMQ has some nice abilities to send > messages between ActiveMQ servers that I started reading up on > (useful for when you start segregating dev and prod) but then I ran into > scalability issues with ActiveMQ so replaced it with RabbitMQ and > haven't looked at what you can do with that yet. at how many nodes did you have scalability issues with ActiveMQ? did you do any tuning on it? -- 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] Scalability, Dashboard/Foreman, and MCollective
On Mon, Oct 24, 2011 at 6:38 PM, Justin Lloyd wrote: > I've been trying to find information, suggestions, etc. for how to combine > scaling Puppet with the use of management tools like Dashboard/Foreman and > MCollective. Our current thinking for an initial deployment is two VMs as > Puppet Master worker nodes fronted by a pair of NetScalers. However, I'm not > sure how to go about implementing Dashboard or Foreman and MCollective > servers in a redundant Puppet Master server environment. Can anyone speak to > their experience in this matter and/or point me to resources that discuss > such architectures? > To scale out foreman, would be very similar to any rails app, normally you could: 1. use a load balancer across multiple foreman rails instances (e.g. on multiple machines) 2. cluster your db Foreman already supports both configuration (and has been implemented by various community members with large scale deployments). additionally, the enc script keeps a cache on each puppet master, so in case when foreman is down, it would serve the last good enc data that came from foreman. hope this helps, Ohad > FWIW, we'll later implement multiple pairs of redundant Puppet servers to > support environments we want managed separately, e.g. Production vs. Test. > > Thanks, > Justin > > -- > 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] /tmp and 1777 mode
I'm new to anything more than very basic puppet. I need to create a
(differently named) working directory which like /tmp has 1777 mode
and is also a mounted file system. I need to avoid the underlying
mount point picking up these permissions (it needs to be 755). How can
I arrange this with puppet. As I understand it both my
file ... { ensure directory }
recipies need to refer to the same directory name.
Chris Ritson.
--
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] Important Security Announcement: AltNames Vulnerability [new version of puppet]
We have discovered a security vulnerability (“AltNames Vulnerability”) whereby a malicious attacker can impersonate the Puppet master using credentials from a Puppet agent node. This vulnerability cannot cross Puppet deployments, but it can allow an attacker with elevated privileges on one Puppet-managed node to gain control of any other Puppet-managed node within the same infrastructure. All Puppet Enterprise deployments are vulnerable, and Puppet open source deployments may be, depending upon their site configuration. We believe this to be a serious risk, and we have confirmed this with security experts outside of Puppet Labs. For more information we have the following resources: * Blog Post with all the details: http://puppetlabs.com/blog/important-security-announcement-altnames-vulnerability/ * Security links and details: http://puppetlabs.com/security/cve/cve-2011-3872/ * Remediation module: http://links.puppetlabs.com/cve20113872_remediation As a result of this vulnerability (CVE-2011-3872) we have released new version of Puppet. * 2.6.12 * 2.7.6 We will be sending separate announcements about each of those releases. Michael Stahnke Release 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.
[Puppet Users] Announce: Puppet 2.6.12 Available [security update]
Puppet 2.6.12 is a security update release in the 2.6.x branch. The only changes since 2.6.11 are security fixes for the following vulnerability: * CVE-2011-3872, Altnames Vulnerability For more details on this vulnerability, follow the link on our blog post: http://puppetlabs.com/blog/important-security-announcement-altnames-vulnerability/ Other information available at: http://puppetlabs.com/security or visit http://puppetlabs.com/security/cve/cve-2011-3872 Features/fixes that were previously targeted at 2.6.12 have been moved to 2.6.13. Puppet 2.6.12 is available as of now. Changelog entries are available below. More detailed information is available on our Release Notes page. Release Notes have been updated: https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes#2.6.12 This release is available for download at: http://puppetlabs.com/downloads/puppet/puppet-2.6.12.tar.gz RPM's are available at http://yum.puppetlabs.com/el or /fedora Puppet is also available via Rubygems at http://rubygems.org See the Verifying Puppet Download section at: http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet Please report feedback via the Puppet Labs Redmine site, using an affected puppet version of 2.6.12: http://projects.puppetlabs.com/projects/puppet/ Commits: 3ed6499 Backport Enumerable#count to Rubies < 1.8.7 5f44c23 More 1.8.5 compatibility fixes. ef1b960 Better 1.8.5 compatible implementation of `lines`. 246e875 (#2848) Config options require '_', not '-'. 3bdeb3a Ruby 1.8.5 compatibility changes in tests and code. 6866d4b Add `lines` alias for `each_line` in Ruby 1.8.5. 2f9ec3c s/not_to/should_not/ for older versions of RSpec 2. 56320ea (#2848) Eliminate redundant `master_dns_alt_names`. de19861 (#2848) Remove the legacy SSLCertificates code cf008a6 (#2848) Rework the xmlrpc CA handler to use the modern SSL code 32be180 (#2848) Remove unused xmlrpc code 5f2a44d (#2848) Consistent return values from `subject_alt_names` accessors. 5e507f2 (#2848) Consistently use `subject_alt_names` as accessor name. 5ac2417 (#2848) Don't strip the subjectAltName label when listing. 44cf3a2 (#2848) Don't enable `emailProtection` for server keys. d66def9 (#2848) Only mark `subjectAltName` critical if `subject` is empty. 8174047 (#2848) Migrate `dns-alt-names` back to settings. f18df2b Wire up the `setbycli` slot in Puppet settings. efa61f2 (#2848) rename subject-alt-name option to dns-alt-names f103b20 (#2848) Rename `certdnsnames` to match new behaviour. 363b47b (#2848) Use `certdnsnames` when bootstrapping a local master. 49334ff (#2848) CSR subjectAltNames handling while signing. 5f2af93 (#2848) List subject alt names in output of puppet cert --list bb475ec (#7224) Add a helper to Puppet::SSL::Certificate to retrieve alternate names bab9310 (#2848) Rewrite SSL Certificate Factory, fixing `subjectAltName` leak. fca1ff0 (#2848) Reject unknown (== all) extensions on the CSR. 443a756 (#2848) extract the subjectAltName value from the CSR. 66101f1 (#2848) Set `certdnsnames` values into the CSR. 77b814f (#6928) Don't blow up when the method is undefined... 5427f1e (#6928) backport Symbol#to_proc for Ruby < 1.8.7 -- 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] Announce: Puppet 2.7.6 Available [ security/feature updates]
Puppet 2.7.6 is a feature and security update release in the 2.7.x branch. The security changes in 2.7.6 addres CVE-2011-3872 * CVE-2011-3872, Altnames Vulnerability For more details on this vulnerability, follow the link on our blog post: http://puppetlabs.com/blog/important-security-announcement-altnames-vulnerability/ Other information available at: http://puppetlabs.com/security or visit http://puppetlabs.com/security/cve/cve-2011-3872 Puppet 2.7.6 is available as of now. Changelog entries are available below. More detailed information is available on our Release Notes page. Detailed feature release notes are available: https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes#2.7.6 This release is available for download at: http://puppetlabs.com/downloads/puppet/puppet-2.7.6.tar.gz RPM's are available at http://yum.puppetlabs.com/el or /fedora Debs are available on http://apt.puppetlabs.com (lenny requires backports enabled) Puppet is also available via Rubygems at http://rubygems.org See the Verifying Puppet Download section at: http://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.6 http://projects.puppetlabs.com/projects/puppet/ Commits: = Changes for 2.7.6 = 0d4494c Updated CHANGELOG for 2.7.6 (See http://puppetlabs.com/blog/important-security-announcement-altnames-vulnerability/) = Fixes due to CVE-2011-3872: see 2011841 Improve the error message when a CSR is rejected afff3df Allow a master to bootstrap itself with dns_alt_names and autosign 388365e (maint) Remove ssl dir before starting a master with DNS alt names e4c64c7 Fix failing CA Interface specs on Ruby 1.9 9ee1215 Fix some inconsistencies from merging 8144939 Add support for DNS alt names to `puppet ca` 2ba56e3 More 1.8.5 compatibility fixes. 6257188 Better 1.8.5 compatible implementation of `lines`. 4ba4db7 (#2848) Config options require '_', not '-'. 493f8d1 Add --allow-dns-alt-names option to `puppet certificate sign` 0cc8936 Add support for dns-alt-names option to `puppet certificate generate` c65236d Ruby 1.8.5 compatibility changes in tests and code. 6c37623 Add `lines` alias for `each_line` in Ruby 1.8.5. e29eb6a s/not_to/should_not/ for older versions of RSpec 2. f1f5298 (#2848) Eliminate redundant `master_dns_alt_names`. 3a8b376 (#2848) Remove the legacy SSLCertificates code 28dead0 (#2848) Rework the xmlrpc CA handler to use the modern SSL code a644514 (#2848) Remove unused xmlrpc code 2b1ad43 (#2848) Consistent return values from `subject_alt_names` accessors. d8516d9 (#2848) Consistently use `subject_alt_names` as accessor name. 0b45f4c (#2848) Don't strip the subjectAltName label when listing. 99488f3 (#2848) Don't enable `emailProtection` for server keys. f1285a4 (#2848) Only mark `subjectAltName` critical if `subject` is empty. e65a88e (#2848) Migrate `dns-alt-names` back to settings. b876c39 Wire up the `setbycli` slot in Puppet settings. a53f2f2 (#2848) rename subject-alt-name option to dns-alt-names bc2267a (#2848) Rename `certdnsnames` to match new behaviour. a720499 (#2848) Use `certdnsnames` when bootstrapping a local master. 6e3f529 (#2848) CSR subjectAltNames handling while signing. 978b65c (#2848) List subject alt names in output of puppet cert --list 7460a5e (#7224) Add a helper to Puppet::SSL::Certificate to retrieve alternate names 94345eb (#2848) Rewrite SSL Certificate Factory, fixing `subjectAltName` leak. a729d90 (#2848) Reject unknown (== all) extensions on the CSR. f4fc11d (#2848) extract the subjectAltName value from the CSR. d64b01b (#2848) Set `certdnsnames` values into the CSR. 78a01a2 (#6928) Don't blow up when the method is undefined... 505d8d6 Updating for 2.7.6rc3 43d1e38 (#9996) Restore functionality for multi-line commands in exec resources bedf7d2 Updated CHANGELOG for 2.7.6rc2 d457763 (#9832) General StoreConfigs regression. 245dfb7 Updated CHANGELOG for 2.7.6rc1 2958b05 maint: Deal with [].to_s problem in 1.9.2 9c25af4 (#9027) Get rid of spurious info messages in groupadd 1f25c20 (#8411) Fix change group for POSIX file provider 599642d Fix problem with set_mode (chmod) behavior on different test environments. b43765d Undo change to failing test on 1.8.5 c275a51 Resist directory traversal attacks through indirections. d759f84 (#9838) Return the tranaction report when doing a ral save 127f83e (#9837) Split parameter pruning from manifest formatting 9d5ce00 (#9837) Move resource formatting method to Puppet::Resource 86230d8 (#9837) Move properties in prep to move proc to method bf952e1 (#9837) Make a clearer variable name in the specs 6885c36 (#9837) Call puppet apply to avoid deprecation warning 93f8057 (#9837) Extract methods from the main section of the resource application 5d33214 (#9837) Start the cleanup of the puppet resource application 54a2565 (#9832) Test failures with some ActiveRecord versions. 2bf8004 Updates for 2.6.11 8343077 (#9832)
[Puppet Users] puppet 2.6.12 for Solaris available at OpenCSW
In my experimental area at the moment - http://buildfarm.opencsw.org/experimental.html#markp It's been submitted to the catalog though. --Mark -- 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] extlookup not working correctly in 2.7.6
I'm trying to upgrade from 2.6.7 to to 2.7.6 and I'm running into an issue in my extlookup() calls. A lot of the variables which should be defined aren't defined within extlookup.rb. I've tested 2.6.7 agent and 2.7.5 agent against the 2.6.7 master and 2.7.6 master. I adjusted extlookup.rb slightly to provide some debug output. http://pastie.org/private/jsmyxrfhggcvflxcioibq shows: * my 2.7.5 puppet agent failure when run against the 2.7.6 puppet master * git diff of extlookup.rb in the 2.7.6 branch * debug extlookup log output from the 2.7.6 master * debug extlookup log output from the 2.6.7 master * extlookup precedence set in site.pp The same manifests/extlookup configuration work on the "newpuppet" environment when using a 2.6.7 agent against the 2.6.7 master. -- 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: extlookup not working correctly in 2.7.6
I diff'd the extlookup.rb between 2.6.7 and 2.7.6 and noticed this was
different, so I changed it back and things are working again:
--> git diff ./lib/puppet/parser/functions/extlookup.rb
diff --git a/lib/puppet/parser/functions/extlookup.rb b/lib/puppet/
parser/functions/extlookup.rb
index 5fbf26c..818f7c7 100644
--- a/lib/puppet/parser/functions/extlookup.rb
+++ b/lib/puppet/parser/functions/extlookup.rb
@@ -93,7 +93,7 @@ This is for back compatibility to interpolate
variables with %. % interpolation
extlookup_datadir = undef_as('',lookupvar('::extlookup_datadir'))
- extlookup_precedence =
undef_as([],lookupvar('::extlookup_precedence')).collect { |var|
var.gsub(/%\{(.+?)\}/) { lookupvar("::#{$1}") } }
+ extlookup_precedence =
undef_as([],lookupvar('::extlookup_precedence')).collect { |var|
var.gsub(/%\{(.+?)\}/) { lookupvar($1) } }
datafiles = Array.new
On Oct 24, 6:04 pm, Jason Koppe wrote:
> I'm trying to upgrade from 2.6.7 to to 2.7.6 and I'm running into an
> issue in my extlookup() calls. A lot of the variables which should be
> defined aren't defined within extlookup.rb. I've tested 2.6.7 agent
> and 2.7.5 agent against the 2.6.7 master and 2.7.6 master. I adjusted
> extlookup.rb slightly to provide some debug output.
>
> http://pastie.org/private/jsmyxrfhggcvflxcioibqshows:
> * my 2.7.5 puppet agent failure when run against the 2.7.6 puppet
> master
> * git diff of extlookup.rb in the 2.7.6 branch
> * debug extlookup log output from the 2.7.6 master
> * debug extlookup log output from the 2.6.7 master
> * extlookup precedence set in site.pp
>
> The same manifests/extlookup configuration work on the "newpuppet"
> environment when using a 2.6.7 agent against the 2.6.7 master.
--
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] extlookup not working correctly in 2.7.6
- Original Message - > I'm trying to upgrade from 2.6.7 to to 2.7.6 and I'm running into an > issue in my extlookup() calls. A lot of the variables which should > be > defined aren't defined within extlookup.rb. I've tested 2.6.7 agent > and 2.7.5 agent against the 2.6.7 master and 2.7.6 master. I > adjusted > extlookup.rb slightly to provide some debug output. > > http://pastie.org/private/jsmyxrfhggcvflxcioibq shows: > * my 2.7.5 puppet agent failure when run against the 2.7.6 puppet > master > * git diff of extlookup.rb in the 2.7.6 branch > * debug extlookup log output from the 2.7.6 master > * debug extlookup log output from the 2.6.7 master > * extlookup precedence set in site.pp > > The same manifests/extlookup configuration work on the "newpuppet" > environment when using a 2.6.7 agent against the 2.6.7 master. might be this, not sure. http://projects.puppetlabs.com/issues/9854 -- 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: extlookup not working correctly in 2.7.6
looks like that's it. i'll use the workaround nigel recommended in that issue (same as my diff above) until that issue is resolved. thanks for the quick response, R.I.! On Oct 24, 6:10 pm, "R.I.Pienaar" wrote: > - Original Message - > > I'm trying to upgrade from 2.6.7 to to 2.7.6 and I'm running into an > > issue in my extlookup() calls. A lot of the variables which should > > be > > defined aren't defined within extlookup.rb. I've tested 2.6.7 agent > > and 2.7.5 agent against the 2.6.7 master and 2.7.6 master. I > > adjusted > > extlookup.rb slightly to provide some debug output. > > >http://pastie.org/private/jsmyxrfhggcvflxcioibqshows: > > * my 2.7.5 puppet agent failure when run against the 2.7.6 puppet > > master > > * git diff of extlookup.rb in the 2.7.6 branch > > * debug extlookup log output from the 2.7.6 master > > * debug extlookup log output from the 2.6.7 master > > * extlookup precedence set in site.pp > > > The same manifests/extlookup configuration work on the "newpuppet" > > environment when using a 2.6.7 agent against the 2.6.7 master. > > might be this, not sure. > > http://projects.puppetlabs.com/issues/9854 -- 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: extlookup()
On Oct 24, 2:25 am, "ollies...@googlemail.com"
wrote:
> On Oct 21, 12:55 pm, Andrew Thompson wrote:> On Oct
> 20, 10:18 am, "ollies...@googlemail.com" wrote:
> > > Taking a brief look at extlookup()
>
> > > We have a module to setup resolv.conf based on location so we have a %
> > > {domain}.csv file
>
> > Can you post your $extlookup_datadir and $extlookup_precedence values?
>
> Sure it's set like this so host based, datacenter, country, region
> based on custom fact(s) which would out the location based on a subnet
> lookup to a backend system.
>
> #
> # Global configuration
> #
> $extlookup_datadir = "/etc/puppetlabs/puppet/envs/legacy/extdata"
> $extlookup_precedence = ["%{fqdn}", "%{datacentreid}", "%{ctryid}", "%
> {rgnid}", "common"]
My environment sets the $extlookup_precendence variable a little
different:
$extlookup_precedence = ["${fqdn}", "${datacentreid}", "${ctryid}", "$
{rgnid}", "common"]
I'm not sure of the difference but, the ${} syntax works just fine for
us.
Also you may want to check that the facts are set properly and keep in
mind that they are case sensitive. I make sure that my fqdn is
lowercase before doing anything.
>
>
>
>
>
>
>
>
>
> > > more /etc/puppetlabs/puppet/envs/legacy/extdata/ldt.csv
> > > domainname,my.domain.com
> > > resolvers,10.10.10.10 10.10.10.11
> > > searchpath,sub.my.domain.com sub2.my.domain.com
>
> > > class resolver::setup {
> > > $searchpath = extlookup("searchpath")
> > > $resolvers = extlookup("resolvers")
> > > $resolvdomainname = extlookup("domainname")
>
> > > }
>
> > This looks correct.
>
> > > Each value is getting set with the “domainname” value.
>
> > What happens if you change the order of the values in the csv file?
--
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] [ask] Upgrade for CVE-2011-3872 AltNames Vulnerability
Base on CVE-2011-3872, i want to upgrade all puppet master and agent, my plan upgrade puppet master first then the agent, whether the configuration I can still be used? if use version 2.6.12 as a puppet master and agent still 2.6.6 for temporary then after that i upgrade to 2.6.12 for the agent? because my configuration already complex, and also using certdnsnames. Or anybody have good plan for upgrading? i can't recreate CA because i have much hosts. Best regards, Heriyanto -- 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.
