Re: [Puppet Users] Puppet Open Source with own Certificates
Hi Hoize, To clarify, did you put Foreman on top of your existing Puppet infrastructure or did you use the Puppet Master that Foreman installed? It would make sense if it were the latter, because Foreman re-uses Puppet's certificates for its own SSL setup. That, in turn, would explain why the nodes stopped communicating with the master as it looks like you may have overwrote Puppet's certificates with your own. - Rilindo On 03/05/2015 01:33 AM, hoize wrote: Hello! Because I can't find anything with google search to my problem with Puppet Open Source, I hope someone of you can help me. On my masterserver there I have installed Foreman running on Apache and Puppet Master. I wanted to replace the certificates of Apache with own certificates to eradicate problems with the Browser (Certificate Trust). But then I got another problem: The nodes could not communicate with the Master. So I decided to replace all certs with own certs, on the nodes and on the master. But how could I do this? I hope you can help me. At PuppetLabs-Docs I only found the configuration for Puppet Enterprise for my issue. Thank You! Greets Manuel Holzner -- 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 mailto:puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/0f8d8e8d-6d72-4065-9325-8d9630a472af%40googlegroups.com https://groups.google.com/d/msgid/puppet-users/0f8d8e8d-6d72-4065-9325-8d9630a472af%40googlegroups.com?utm_medium=emailutm_source=footer. For more options, visit https://groups.google.com/d/optout. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/5506E576.606%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Puppet Open Source with own Certificates
Hi Hoize, To clarify, did you put Foreman on top of your existing Puppet infrastructure or did you use the Puppet Master that Foreman installed? It would make sense if it were the latter, because Foreman re-uses Puppet's certificates for its own SSL setup. That, in turn, would explain why the nodes stopped communicating with the master as it looks like you may have overwrote Puppet's certificates with your own. - Rilindo On 03/05/2015 01:33 AM, hoize wrote: Hello! Because I can't find anything with google search to my problem with Puppet Open Source, I hope someone of you can help me. On my masterserver there I have installed Foreman running on Apache and Puppet Master. I wanted to replace the certificates of Apache with own certificates to eradicate problems with the Browser (Certificate Trust). But then I got another problem: The nodes could not communicate with the Master. So I decided to replace all certs with own certs, on the nodes and on the master. But how could I do this? I hope you can help me. At PuppetLabs-Docs I only found the configuration for Puppet Enterprise for my issue. Thank You! Greets Manuel Holzner -- 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 mailto:puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/0f8d8e8d-6d72-4065-9325-8d9630a472af%40googlegroups.com https://groups.google.com/d/msgid/puppet-users/0f8d8e8d-6d72-4065-9325-8d9630a472af%40googlegroups.com?utm_medium=emailutm_source=footer. For more options, visit https://groups.google.com/d/optout. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/5506E57E.2040301%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] execution expired with a puppetmaster with more then enough resources
Hi, after a long time i found the mistake. My PuppetDB was only reachable over a hardware firewall - that's all. After the change from network interfaces all works perfect. Thanks for your help. Philipp Am Montag, 24. November 2014 15:10:31 UTC+1 schrieb jcbollinger: On Sunday, November 23, 2014 2:31:12 PM UTC-6, Felix.Frank wrote: On 11/23/2014 10:31 AM, Philipp Dallig wrote: Nov 23 10:08:06 puppetmaster01 puppet-master[21761]: Compiled catalog for xymon.x.com in environment production in 241.31 seconds There's some 120 second compiler runs, and some 240s. Multiples of 120 seconds? That certainly has a meaning, but I have no idea what that is. Good call. A distribution of compile times like that -- clustered around integer multiples of 120s -- is not natural. It's shouting timeout to me, with the most likely thing to be timing out being name service lookups. Check the master's name server configuration. My guess would be that one of its 2-3 configured domain name servers is offline or malfunctioning. You could test that hypothesis indirectly by performing a bunch of manual name service lookups, and seeing whether any of them suffer similar delays. On the master, look up an affected client's name via 'nslookup' or 'dig' (or whatever client is appropriate if you're relying on a name service different from DNS). You could test it indirectly by entering the name and address of one of the problematic clients in the master's 'hosts' file (and ensuring that it is checked first, see 'nsswitch.conf'). If that fixes the issue for that client, but others remain affected then you'll have pretty well tied it down to a name service issue. 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/daf13fec-422b-4241-b346-a40c1faffa3e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Facts which depend on (not-yet-installed) packages
On Sunday, March 15, 2015 at 2:04:53 PM UTC-5, Jan S. wrote:
Hello,
I have the following use case: For a custom class/type I need to know
which php_version is installed on the machine. So I wrote a custom fact
like this:
Facter.add('php_version') do
setcode do
Facter::Util::Resolution.exec('/usr/bin/php -i | /bin/egrep -e ^PHP
Version | /usr/bin/head -n 1 | /usr/bin/cut -d -f 4 | /usr/bin/cut -d
- -f 1')
end
end
It works great. Except: When php is not yet installed (there is a
Package['php'] definition, too). Then it will return an empty string.
Thus I have to run puppet two times to get the expected result.
I am sure that this is expected behavior of puppet. How do I handle such
case?
Fact values are computed before any part of the catalog is built, and they
reflect the state of the machine before Puppet applies any changes. If PHP
is not initially installed, then that's a plausible, valid state that your
fact value should reflect and your manifests should accommodate. In the
worst case, your manifests could accommodate absence of PHP by requiring
two Puppet runs to converge to a final configuration. That's what you have
now, evidently.
Consider carefully, however, what that fact value is telling you: what
version of PHP, if any, is installed *before* the run. If the target
configuration depends in any way on PHP version, then what you probably
want is the PHP version that will be present *after* the run. If there is
any chance that the run will ever update PHP to a new version, then even
when PHP is already installed, your manifests rely on an unsafe assumption
that the version present before the run will be the same as the version
present after.
Possibly what you want is a different (or additional) fact: not the version
of PHP currently installed, but the latest version available from the
configured repositories. This is the version that will be present after a
successful run if you have ...
package { 'php': ensure = 'latest' }
... it is also the version that will be present after the run if PHP is not
initially installed and you have ...
package { 'php': ensure = 'present' }
... provided that the package repository configuration is not changed so as
to affect which PHP packages are available. Given that, if you ensure that
the PHP package is managed before anything that depends on PHP version (as
you should already be doing) then all should be good.
If you want maximum reliability, however, you need to recognize that if
indeed what you want to know is which version of PHP will be present on the
machine after a successful catalog run, then your nodes simply cannot
provide that information. It depends on data they do not have. You need
to some mechanism other than (or in addition to) node facts to ascertain
that.
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 view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/7f0ccfaa-108b-44c3-a9d1-cbca6c0bde22%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Node key merging/overloading - node inheritance vs hiera
On Friday, March 13, 2015 at 12:12:12 PM UTC-5, Christopher Wood wrote: On Thu, Mar 12, 2015 at 06:32:21AM -0700, jcbollinger wrote: No, it is metadata. The metadata could be lumped in with the data the regular data -- and in fact, the default back end provides no other alternative if you want to provide that metadata at all -- but that's untidy, and it doesn't play nicely with automated data binding. Is any code unaware of the underlying data structure? Even if you have a single type of data (plain string-like variables) your code is implicitly aware that it can treat them as that type. You're commingling two different concepts: the structure of the data provided by Hiera to Puppet, and the structure of the data in the external storage on which Hiera relies. Puppet needs to know about the former, but it shouldn't have to know or care about the latter. THAT's the whole point. The fact that there are three different Hiera lookup functions, and that they can return different data for the same key -- even data with different structure -- makes Puppet sensitive to the internal layout of Hiera's data files. I grant that I'm not seeing the whole picture; I'm perfectly fine with the notion that code/data/metadata/structure are all subsets of the information required to correctly manage a host. I presume structure has to go somewhere and if it's not in the pp file it's just somewhere else I will have to know about and account for so I'm not really seeing what difference it makes. For instance, what breaks with the current thing that wouldn't if puppet just got data and the hiera_array vs hiera_hash determination was made elsewhere? The most prominent thing that breaks is automatic data binding. If the physical layout of your data for some key is designed for service via the hiera_array() or hiera_hash() function, then you cannot use automated data binding with that key. Or to put it the other way around, if you have a class parameter whose value you want to provide via automatic data binding (as you should), then you *must* structure the associated data for for priority lookup, not for array or hash-merge lookup. In a sense, this is an encapsulation issue: the physical layout of the data is the implementation, and the keys are the interface. You shouldn't need to know anything about the implementation to use the interface, but currently, you do. And it would be possible. For example, the YAML back end could be modified to refer to an ancillary metadata file that flagged certain keys for array or hash-merge lookup. That's a bit ugly, but sometimes ugly happens when you have to retrofit. I don't know that this is better or worse than having structural information about hiera in my pp files. I go from: having two places where things go (hiera and puppet) having structural information in each (yaml anchor/alias etc., puppet data bindings and hiera functions) To: having three places where things go (hiera, hiera metadata, puppet) having structural information in two (yaml anchor/alias etc., hiera key flagging) I've added a place and now I have more to think about, plus it's not obvious from my puppet code where my data is coming from. and I have a lab host where I don't actually want things tagged as merge-only to be merged while I'm experimenting. Ouch my brain. The design I presented was for proof-of-concept purposes. There are probably better alternatives. Even with that simple design, though, the information complexity does not increase. If you want to use any array- or hash-merge lookups *at all* then you already have to worry about manifests, data, and metadata, wherever each of those lives. The gain is in separation of concerns: when you're working with your manifests, you don't need to pay any attention to metadata, and when you're working with the data, you don't need to be worried (as much) about breaking manifests. This may even have impacted you personally, in the real-life failure case you described. I speculate that if the physical data layout had more clearly been associated directly with the data, then you would have been more likely to look for (and find) the problematic default value when you changed to hash-merge lookups. Having separate lookup functions for array- and hash-merge lookup styles can be a distraction from the fact that the physical data layout is important. It is not, in general, safe to switch from one mode to another for any given key. 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 view this discussion on the web visit
Re: [Puppet Users] Puppet Open Source with own Certificates
Hi! I took the foreman-installer, which installed PuppetMaster, Apache2, MySQL,... Yes, the certificates are used by puppet and by foreman.. But even if I only change the paths of the SSL-Engine in the Apache2 sites-config to my own certificates, the web-browser works fine, butt puppet can't communicate with the nodes.. Thank You! Hoize Am Montag, 16. März 2015 15:15:28 UTC+1 schrieb RIlindo Foster: Hi Hoize, To clarify, did you put Foreman on top of your existing Puppet infrastructure or did you use the Puppet Master that Foreman installed? It would make sense if it were the latter, because Foreman re-uses Puppet's certificates for its own SSL setup. That, in turn, would explain why the nodes stopped communicating with the master as it looks like you may have overwrote Puppet's certificates with your own. - Rilindo On 03/05/2015 01:33 AM, hoize wrote: Hello! Because I can't find anything with google search to my problem with Puppet Open Source, I hope someone of you can help me. On my masterserver there I have installed Foreman running on Apache and Puppet Master. I wanted to replace the certificates of Apache with own certificates to eradicate problems with the Browser (Certificate Trust). But then I got another problem: The nodes could not communicate with the Master. So I decided to replace all certs with own certs, on the nodes and on the master. But how could I do this? I hope you can help me. At PuppetLabs-Docs I only found the configuration for Puppet Enterprise for my issue. Thank You! Greets Manuel Holzner -- 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 javascript:. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/0f8d8e8d-6d72-4065-9325-8d9630a472af%40googlegroups.com https://groups.google.com/d/msgid/puppet-users/0f8d8e8d-6d72-4065-9325-8d9630a472af%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/950287ba-397a-48b1-a707-ca3e2cf83bc0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Puppet Open Source with own Certificates
Hi Hoize, To clarify, did you put Foreman on top of your existing Puppet infrastructure or did you use the Puppet Master that Foreman installed? It would make sense if it were the latter, because Foreman re-uses Puppet's certificates for its own SSL setup. That, in turn, would explain why the nodes stopped communicating with the master as it looks like you may have overwrote Puppet's certificates with your own. - Rilindo On 03/05/2015 01:33 AM, hoize wrote: Hello! Because I can't find anything with google search to my problem with Puppet Open Source, I hope someone of you can help me. On my masterserver there I have installed Foreman running on Apache and Puppet Master. I wanted to replace the certificates of Apache with own certificates to eradicate problems with the Browser (Certificate Trust). But then I got another problem: The nodes could not communicate with the Master. So I decided to replace all certs with own certs, on the nodes and on the master. But how could I do this? I hope you can help me. At PuppetLabs-Docs I only found the configuration for Puppet Enterprise for my issue. Thank You! Greets Manuel Holzner -- 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 mailto:puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/0f8d8e8d-6d72-4065-9325-8d9630a472af%40googlegroups.com https://groups.google.com/d/msgid/puppet-users/0f8d8e8d-6d72-4065-9325-8d9630a472af%40googlegroups.com?utm_medium=emailutm_source=footer. For more options, visit https://groups.google.com/d/optout. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/55071A97.3070006%40gmail.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Type/Provider Error: /Type[name]: Could not evaluate: No ability to determine if xxx exists
On Saturday, March 14, 2015 at 11:22:21 PM UTC+13, Krzysztof Suszyński
wrote:
You have declared a property ip. This means that it will be ensurable as
well and you should declare setter and getter for it:
def ip=(newip)
# Mayby like this
host = resource[:name]
postdata = {
'addr' = newip,
'hostnames' = [ host ]
}
RestClient.put(#{baseurl}#{host_uri}, postdata.to_json, header)
RestClient.get(#{baseurl}#{deploy_uri}, header)
end
def ip
# Mayby like this
result = RestClient.get(#{baseurl}#{deploy_uri}, header)
result.ip
end
Getters will be executed if type exists. Setters will be executed if
resource[:ip] value differ from one returned from your getter.
I recommend you read the book Puppet Types and Providers by Dan Bode.
Buy or search web for ebook.
Thank you. I ended up making it a param for now. :)
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/c9e2345e-2920-46e3-8112-2514a3ef10d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Upcoming changes in the PuppetDB 3.0 query API
With the 3.0 major release of PuppetDB in the next few months, we will be retiring the v2 and v3 PuppetDB query APIs and adopting v4 as the new stable. At the same time, we will release the final batch of new features for the v4 API, which means that v4 in 3.0 will be different than the current experimental v4 endpoint in 2.x. Moving to the v4 API has permitted the unification of our HTTP endpoints under a single central query engine, which has paid great dividends in consistency between endpoints and the ease and speed of new feature development. Nonetheless, we understand that the simultaneous promotion of v4 and retirement of v3 will cause some inconvenience, so we want to make sure users are aware of the changes. For information on the upcoming features and differences, please see the draft API migration guide: http://docs.puppetlabs.com/puppetdb/master/api/query/v4/upgrading-from-v3.html Note that the API is still under development and the document will be updated as new changes are merged. To test the latest changes, see our nightly snapshots: http://nightlies.puppetlabs.com/puppetdb/ Note that this is still unreleased code, and not suitable for production use. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/550733CD.3080203%40puppetlabs.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] who updated my puppet.conf on puppet master
I installed a puppetdb with puppet master. I need to add dns_alt_names = puppet.mydomain.com,puppet to make it works or else a lot of errors like: Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Attempt to assign to a reserved variable but my /etc/puppet/puppet.conf is always refreshed by some other processes? by puppetdb? please help -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/ac15f280-99a1-44e4-9e3f-522408e715db%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Puppet Open Source with own Certificates
Hi, Sorry I havn't been at work the last week. Thank you very much for your answer. At the moment I have installed the puppet own certs on my master. Did you replace the certs? If yes, could you give me a short introduction, please? Thank You! Hoize Am Freitag, 6. März 2015 15:16:30 UTC+1 schrieb Felix.Frank: On 03/05/2015 08:33 AM, hoize wrote: I hope you can help me. At PuppetLabs-Docs I only found the configuration for Puppet Enterprise for my issue. Hi, apart from some path names, it should be applicable to open source puppet. Can you link the specific howto you are following, and indicate where you stumbled? Thanks, Felix -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/70074a27-54c7-4a7b-903f-b9cc9e6efe24%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
