[Puppet Users] Re: puppet 3.7.4 using auth.conf file from github - default acl at end apparently preventing access?
Has anyone else come up with a solution for this? We just booted a new puppet master for the first time in a few weeks and it came up with Passenger 5 (we were on 4.0.69) -- and failed. For the time being we've patched our code to use an updated repo location with Passenger 4.x, but we'd like to be able to use 5. We are seeing the exact same behavior. Puppet 3.7.4 (installed via debian packages), Ubuntu 12.04. On Friday, March 13, 2015 at 5:14:32 PM UTC-7, Johnson Earls wrote: Operating System: Oracle Linux 6.5 Puppet version: Open Source Puppet 3.7.4 (installed via gems) Ruby version: 2.1.0 (locally built package) Apache version: 2.2.15 Passenger version: 5.0.4 I apologise in advance if this post sounds confused and wanders all over; it mirrors its author in that respect. I'm just getting started with puppet. I've got a small 5-node playground set up to play with. I set it up using the Installing Puppet: From Gems instructions (since I wanted to use a newer version of ruby than the 1.8.7 that Oracle Linux comes with), and I thought everything was going great, getting it running under apache/passenger and everything. Then I realized I'd forgotten to install the auth.conf file the last time I rebuilt the puppet directories. As soon as I installed that file and restarted httpd, my agents stopped being able to talk to the server, getting an Error 403 Forbidden for every access. The errors, listed here, indicate that the server is recognizing that the client is authenticated, so apparently it's just not recognizing the URLs being accessed: Warning: Error 403 on SERVER: Forbidden request: rac03n01-dc2.dc2.responsys.com(...) access to /node/ rac03n01-dc2.dc2.responsys.com [find] authenticated at :123 Error: /File[/var/lib/puppet/facts.d]: Failed to generate additional resources using 'eval_generate': Error 403 on SERVER: Forbidden request: rac03n01-dc2.dc2.responsys.com(...) access to /file_metadata/pluginfacts [search] authenticated at :123 Error: /File[/var/lib/puppet/facts.d]: Could not evaluate: Could not retrieve file metadata for puppet://puppet/pluginfacts: Error 403 on SERVER: Forbidden request: rac03n01-dc2.dc2.responsys.com(...) access to /file_metadata/pluginfacts [find] authenticated at :123 Error 403 on SERVER: Forbidden request: rac03n01-dc2.dc2.responsys.com(...) access to /file_metadata/pluginfacts [find] authenticated at :123 Error: /File[/var/lib/puppet/lib]: Failed to generate additional resources using 'eval_generate': Error 403 on SERVER: Forbidden request: rac03n01-dc2.dc2.responsys.com(...) access to /file_metadata/plugins [search] authenticated at :123 Error: /File[/var/lib/puppet/lib]: Could not evaluate: Could not retrieve file metadata for puppet://puppet/plugins: Error 403 on SERVER: Forbidden request: rac03n01-dc2.dc2.responsys.com(...) access to /file_metadata/plugins [find] authenticated at :123 Error 403 on SERVER: Forbidden request: rac03n01-dc2.dc2.responsys.com(...) access to /file_metadata/plugins [find] authenticated at :123 Error: Could not retrieve catalog from remote server: Error 403 on SERVER: Forbidden request: rac03n01-dc2.dc2.responsys.com(...) access to /catalog/ rac03n01-dc2.dc2.responsys.com [find] authenticated at :123 Error: Could not send report: Error 403 on SERVER: Forbidden request: rac03n01-dc2.dc2.responsys.com(...) access to /report/ rac03n01-dc2.dc2.responsys.com [save] authenticated at :123 I noticed that the URLs listed (/node/..., /catalog/..., /report/..., and /file_metadata/...) are not listed in the auth.conf at all, but are being inserted by the puppet master: Mar 13 16:43:06 ... puppet-master[13013]: Inserting default '~ ^/catalog/([^/]+)$' (auth true) ACL Mar 13 16:43:06 ... puppet-master[13013]: Inserting default '~ ^/node/([^/]+)$' (auth true) ACL Mar 13 16:43:06 ... puppet-master[13013]: Inserting default '/file' (auth ) ACL Mar 13 16:43:06 ... puppet-master[13013]: Inserting default '/certificate_revocation_list/ca' (auth true) ACL Mar 13 16:43:06 ... puppet-master[13013]: Inserting default '~ ^/report/([^/]+)$' (auth true) ACL Mar 13 16:43:06 ... puppet-master[13013]: Inserting default '/certificate/ca' (auth any) ACL Mar 13 16:43:06 ... puppet-master[13013]: Inserting default '/certificate/' (auth any) ACL Mar 13 16:43:06 ... puppet-master[13013]: Inserting default '/certificate_request' (auth any) ACL Mar 13 16:43:06 ... puppet-master[13013]: Inserting default '/status' (auth true) ACL Mar 13 16:43:06 ... puppet-master[13013]: Inserting default '/v2.0/environments' (auth true) ACL However,apparently, the default deny-all ACL at the end of auth.conf (at line 123 as shown in the errors above) is preventing those default ACLs from taking effect. Once I commented out the default deny-all ACL at the end of auth.conf, my access started working again. Am I reading the logs and auth.conf file
[Puppet Users] Re: Facts which depend on (not-yet-installed) packages
Can't you avoid this problem altogether by determining the PHP version in
your custom provider code? Then you wouldn't need a custom fact at all,
and in your manifest, have the custom type require the PHP package.
On Monday, March 16, 2015 at 6:04:53 AM UTC+11, 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?
Regards
Jan
--
http://dracoblue.net
--
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/235e5988-c74d-4bcb-84eb-9e2ed285c1c4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: Facts which depend on (not-yet-installed) packages
Hi,
You can write something that will lookup in the dpkg/yum cache (but I
don't like this), so you will have the future installed version at the
1st run
Exemple here :
https://github.com/fsalum/puppet-redis/blob/master/lib/facter/redis_version.rb
Best regards,
Le 16/03/2015 17:07, jcbollinger a écrit :
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
mailto: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
https://groups.google.com/d/msgid/puppet-users/7f0ccfaa-108b-44c3-a9d1-cbca6c0bde22%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/5507D612.2070204%40quake.fr.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Question about directory environment setting.
I don't have a PE3.7 handy to try it but it looks like you simply don't need a section in your environment.conf file, as the error message says. I think you need to look at this page: http://docs.puppetlabs.com/puppet/latest/reference/config_file_environment.html On Wednesday, March 18, 2015 at 1:31:10 PM UTC+11, Hiu wrote: hi all, I am pretty new to puppet, and installed puppet 3.7.4 and centos66. I have read some documentations about the directory environment setting. but i can't figure out how to make it work. My aim is create another environment e.g. development. May be it should a simple mistake but, please by all means point me out of a way. thanks! here is my master puppet.conf [main] environmentpath = /etc/puppet/environments certificate_expire_warning = 5184000 hostprivkey = /var/lib/puppet/ssl/private_keys/centos66-pm.localhost.pem httplog = /var/log/puppet/http.log publickeydir = /var/lib/puppet/ssl/public_keys plugindest = /var/lib/puppet/lib catalog_terminus = compiler route_file = /etc/puppet/routes.yaml localcacert = /var/lib/puppet/ssl/certs/ca.pem privatekeydir = /var/lib/puppet/ssl/private_keys pluginfactdest = /var/lib/puppet/facts.d facts_terminus = yaml node_cache_terminus = write_only_yaml immutable_node_data = false confdir = /etc/puppet passfile = /var/lib/puppet/ssl/private/password csr_attributes = /etc/puppet/csr_attributes.yaml hiera_config = /etc/puppet/hiera.yaml hostcert = /var/lib/puppet/ssl/certs/centos66-pm.localhost.pem factpath = /var/lib/puppet/lib/facter:/var/lib/puppet/facts default_file_terminus = rest ssldir = /var/lib/puppet/ssl libdir = /var/lib/puppet/lib rundir = /var/run/puppet hostpubkey = /var/lib/puppet/ssl/public_keys/centos66-pm.localhost.pem requestdir = /var/lib/puppet/ssl/certificate_requests pluginsource = puppet://puppet/plugins node_terminus = plain statedir = /var/lib/puppet/state logdir = /var/log/puppet environment_timeout = 180 privatedir = /var/lib/puppet/ssl/private pluginfactsource = puppet://puppet/pluginfacts data_binding_terminus = hiera vardir = /var/lib/puppet hostcrl = /var/lib/puppet/ssl/crl.pem http_keepalive_timeout = 4 hostcsr = /var/lib/puppet/ssl/csr_centos66-pm.localhost.pem inventory_terminus = yaml name = master certdir = /var/lib/puppet/ssl/certs filetimeout = 15 splaylimit = 1800 agent_catalog_run_lockfile = /var/lib/puppet/state/agent_catalog_run.lock classfile = /var/lib/puppet/state/classes.txt lastrunreport = /var/lib/puppet/state/last_run_report.yaml clientbucketdir = /var/lib/puppet/clientbucket ca_server = puppet graphdir = /var/lib/puppet/state/graphs report_server = puppet waitforcert = 120 statefile = /var/lib/puppet/state/state.yaml inventory_server = puppet puppetdlog = /var/log/puppet/puppetd.log client_datadir = /var/lib/puppet/client_data lastrunfile = /var/lib/puppet/state/last_run_summary.yaml agent_disabled_lockfile = /var/lib/puppet/state/agent_disabled.lock runinterval = 1800 resourcefile = /var/lib/puppet/state/resources.txt node_name_value = centos66-pm.localhost configtimeout = 120 ca_port = 8140 localconfig = /var/lib/puppet/state/localconfig report_port = 8140 clientyamldir = /var/lib/puppet/client_yaml inventory_port = 8140 reportdir = /var/lib/puppet/reports storeconfigs_backend = active_record bucketdir = /var/lib/puppet/bucket fileserverconfig = /etc/puppet/fileserver.conf yamldir = /var/lib/puppet/yaml #masterlog = /var/log/puppet/puppetmaster.log default_manifest = /etc/puppet/manifests/site.pp disable_per_environment_manifest = false #modulepath = /etc/puppet/modules:/usr/share/puppet/modules rest_authconfig = /etc/puppet/auth.conf basemodulepath = /etc/puppet/modules:/usr/share/puppet/modules server_datadir = /var/lib/puppet/server_data masterhttplog = /var/log/puppet/masterhttp.log #manifestdir = /etc/puppet/manifests pidfile = /var/run/puppet/master.pid config = /etc/puppet/puppet.conf autosign = /etc/puppet/autosign.conf cert_inventory = /var/lib/puppet/ssl/ca/inventory.txt csrdir = /var/lib/puppet/ssl/ca/requests ca_name = Puppet CA: centos66-pm.localhost capass = /var/lib/puppet/ssl/ca/private/ca.pass cacert = /var/lib/puppet/ssl/ca/ca_crt.pem ca_ttl = 15768 capub = /var/lib/puppet/ssl/ca/ca_pub.pem caprivatedir = /var/lib/puppet/ssl/ca/private serial = /var/lib/puppet/ssl/ca/serial signeddir = /var/lib/puppet/ssl/ca/signed cadir = /var/lib/puppet/ssl/ca cakey = /var/lib/puppet/ssl/ca/ca_key.pem cacrl = /var/lib/puppet/ssl/ca/ca_crl.pem module_skeleton_dir =
[Puppet Users] Question about directory environment setting.
hi all, I am pretty new to puppet, and installed puppet 3.7.4 and centos66. I have read some documentations about the directory environment setting. but i can't figure out how to make it work. My aim is create another environment e.g. development. May be it should a simple mistake but, please by all means point me out of a way. thanks! here is my master puppet.conf [main] environmentpath = /etc/puppet/environments certificate_expire_warning = 5184000 hostprivkey = /var/lib/puppet/ssl/private_keys/centos66-pm.localhost.pem httplog = /var/log/puppet/http.log publickeydir = /var/lib/puppet/ssl/public_keys plugindest = /var/lib/puppet/lib catalog_terminus = compiler route_file = /etc/puppet/routes.yaml localcacert = /var/lib/puppet/ssl/certs/ca.pem privatekeydir = /var/lib/puppet/ssl/private_keys pluginfactdest = /var/lib/puppet/facts.d facts_terminus = yaml node_cache_terminus = write_only_yaml immutable_node_data = false confdir = /etc/puppet passfile = /var/lib/puppet/ssl/private/password csr_attributes = /etc/puppet/csr_attributes.yaml hiera_config = /etc/puppet/hiera.yaml hostcert = /var/lib/puppet/ssl/certs/centos66-pm.localhost.pem factpath = /var/lib/puppet/lib/facter:/var/lib/puppet/facts default_file_terminus = rest ssldir = /var/lib/puppet/ssl libdir = /var/lib/puppet/lib rundir = /var/run/puppet hostpubkey = /var/lib/puppet/ssl/public_keys/centos66-pm.localhost.pem requestdir = /var/lib/puppet/ssl/certificate_requests pluginsource = puppet://puppet/plugins node_terminus = plain statedir = /var/lib/puppet/state logdir = /var/log/puppet environment_timeout = 180 privatedir = /var/lib/puppet/ssl/private pluginfactsource = puppet://puppet/pluginfacts data_binding_terminus = hiera vardir = /var/lib/puppet hostcrl = /var/lib/puppet/ssl/crl.pem http_keepalive_timeout = 4 hostcsr = /var/lib/puppet/ssl/csr_centos66-pm.localhost.pem inventory_terminus = yaml name = master certdir = /var/lib/puppet/ssl/certs filetimeout = 15 splaylimit = 1800 agent_catalog_run_lockfile = /var/lib/puppet/state/agent_catalog_run.lock classfile = /var/lib/puppet/state/classes.txt lastrunreport = /var/lib/puppet/state/last_run_report.yaml clientbucketdir = /var/lib/puppet/clientbucket ca_server = puppet graphdir = /var/lib/puppet/state/graphs report_server = puppet waitforcert = 120 statefile = /var/lib/puppet/state/state.yaml inventory_server = puppet puppetdlog = /var/log/puppet/puppetd.log client_datadir = /var/lib/puppet/client_data lastrunfile = /var/lib/puppet/state/last_run_summary.yaml agent_disabled_lockfile = /var/lib/puppet/state/agent_disabled.lock runinterval = 1800 resourcefile = /var/lib/puppet/state/resources.txt node_name_value = centos66-pm.localhost configtimeout = 120 ca_port = 8140 localconfig = /var/lib/puppet/state/localconfig report_port = 8140 clientyamldir = /var/lib/puppet/client_yaml inventory_port = 8140 reportdir = /var/lib/puppet/reports storeconfigs_backend = active_record bucketdir = /var/lib/puppet/bucket fileserverconfig = /etc/puppet/fileserver.conf yamldir = /var/lib/puppet/yaml #masterlog = /var/log/puppet/puppetmaster.log default_manifest = /etc/puppet/manifests/site.pp disable_per_environment_manifest = false #modulepath = /etc/puppet/modules:/usr/share/puppet/modules rest_authconfig = /etc/puppet/auth.conf basemodulepath = /etc/puppet/modules:/usr/share/puppet/modules server_datadir = /var/lib/puppet/server_data masterhttplog = /var/log/puppet/masterhttp.log #manifestdir = /etc/puppet/manifests pidfile = /var/run/puppet/master.pid config = /etc/puppet/puppet.conf autosign = /etc/puppet/autosign.conf cert_inventory = /var/lib/puppet/ssl/ca/inventory.txt csrdir = /var/lib/puppet/ssl/ca/requests ca_name = Puppet CA: centos66-pm.localhost capass = /var/lib/puppet/ssl/ca/private/ca.pass cacert = /var/lib/puppet/ssl/ca/ca_crt.pem ca_ttl = 15768 capub = /var/lib/puppet/ssl/ca/ca_pub.pem caprivatedir = /var/lib/puppet/ssl/ca/private serial = /var/lib/puppet/ssl/ca/serial signeddir = /var/lib/puppet/ssl/ca/signed cadir = /var/lib/puppet/ssl/ca cakey = /var/lib/puppet/ssl/ca/ca_key.pem cacrl = /var/lib/puppet/ssl/ca/ca_crl.pem module_skeleton_dir = /var/lib/puppet/puppet-module/skeleton module_working_dir = /var/lib/puppet/puppet-module #templatedir = /var/lib/puppet/templates railslog = /var/log/puppet/rails.log dblocation = /var/lib/puppet/state/clientconfigs.sqlite3 deviceconfig = /etc/puppet/device.conf devicedir = /var/lib/puppet/devices tagmap = /etc/puppet/tagmail.conf rrdinterval = 1800 rrddir = /var/lib/puppet/rrd archive_file_server = puppet and puppet
Re: [Puppet Users] Questions about PE
1) Does it work with Foreman? Yes, though if you are not using Foreman for anything other than Reporting and ENC, Puppet's console is pretty capable as a replacement. 2) Can it be installed from an internal RPM repository? Yes. There is a Foreman repo you'll need to sync for the base packages. In addition, you need the following repositories available for Foreman to resolve its dependencies: - EPEL - Red Hat SCL - Red Hat Optional channel/packages (I don't recall the exact name). 3) If it doesn't work with Foreman is there an equivalent ENC and front end for PE? Like I said, the Puppet console is pretty capable. I would suggest downloading an evaluation copy from PuppetLabs and get it deployed in your dev envionment (or even in your personal VM). They made it very easy to get it up and running. - Rilindo On 03/17/2015 11:49 AM, Peter Berghold wrote: HI folks, Six months into my project to bring Foreman/Puppet into my work environment someone has asked the question Hey! Can we get a licensed version of this with support? My answer, sure... where's the funding? That aside I have some questions about Puppet Enterprise: 1) Does it work with Foreman? 2) Can it be installed from an internal RPM repository? The platform this will happen on is RHEL 6 (possibly 7 in the future). 3) If it doesn't work with Foreman is there an equivalent ENC and front end for PE? -- 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/CAArvnv1G6OKzvgcr%2BZtJL6WreMyYsDqvTSKWmv%3DCBt4iK01E%2Bw%40mail.gmail.com https://groups.google.com/d/msgid/puppet-users/CAArvnv1G6OKzvgcr%2BZtJL6WreMyYsDqvTSKWmv%3DCBt4iK01E%2Bw%40mail.gmail.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/5508DC14.9030809%40gmail.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Restricting access to environments by IP or cert in puppetserver
Hi Luca, Yes, in a pre-puppetserver world I am using Apache and mod_passenger. But for scalability I'd really like to switch to puppetserver which is meant to do all its own SSL using Trapperkeeper. Putting APache in front of it will fail because of https://tickets.puppetlabs.com/browse/SERVER-213 and https://tickets.puppetlabs.com/browse/SERVER-217. It actually looks like I might be able to do what I need in auth.conf, since it has a way to specify blocks specific to an environment. I'll give it a shot and see if it still works in puppetserver. A quick search turned up an issue (https://tickets.puppetlabs.com/browse/SERVER-111) Thanks, Mike On Sunday, March 15, 2015 at 6:20:08 AM UTC-4, Luca Gervasi wrote: Hi Michael, I would strongly suggest to put an httpd/mod_phusion in front of your puppet (this leads to the Location syntax as you suggested). If, for whatever reason, your choice is to use webrick for your production, you could work on your filesterver.conf. This file is strongly commentend. Good luck. On Sunday, 15 March 2015 04:24:22 UTC+1, Michael Smith wrote: Hi, I'm setting up a puppetserver that will be shared by multiple projects and would like to enforce some control over access to environment resources - particularly puppet:///modules/... file server URLs. The environment name appears at the start of the URL, so with an Apache/Passenger setup I could put IP address-based access controls on an environment using a Location block so nodes in project A's subnet can't download files from project B's environment. I'm looking for ideas to do the same in a puppetserver world. Really what I want to do is block access to puppet:///modules/... from nodes with no node definition in the current environment, and the IP address access control is just an easy way of doing this in Apache/Passenger. I realize I could still put Apache in front of puppetserver and configure access controls there - modulo a couple of bugs like SERVER-213 and SERVER-217 - but maybe there's a better way using puppetserver. Thanks, Mike -- 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/676f9529-946f-4ffd-b2ea-80f100324c51%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: who updated my puppet.conf on puppet master
As a side node, that error (Attempt to assign to a reserved variable) seems to be caused by an error in your manifests. I don't see how it could be related to the dns_alt_names setting in puppet.conf. Regards, Martijn Op maandag 16 maart 2015 20:59:33 UTC+1 schreef Robert Chen: 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/da79567a-962a-4dad-ba7d-c56e7004be60%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Announce: Strings 0.2.0 Released
We’re happy to announce the latest release of the strings module. Strings 0.2.0 is a backward-compatible minor release. It includes improvements to the HTML output generated by strings and a few bug fixes. *The CHANGELOG can be found here: https://github.com/puppetlabs/puppetlabs-strings/blob/master/CHANGELOG.md *The module can be found on the Forge here: https://forge.puppetlabs.com/puppetlabs/strings *Installation and usage instructions can be found here: https://github.com/puppetlabs/puppetlabs-strings/blob/master/README.md To track issues related to this release or file new issues, head over to the PDOC JIRA Project: * JIRA Project: https://tickets.puppetlabs.com/browse/PDOC * Fixes for 0.2.0: https://tickets.puppetlabs.com/issues/?filter=13760 -- Hailee Kenney hai...@puppetlabs.com Associate Software Developer, Puppet Labs *PuppetConf 2015 http://2015.puppetconf.com/ is coming to Portland, Oregon! Join us October 5-9.* *Register now to take advantage of the Early Adopter discount https://www.eventbrite.com/e/puppetconf-2015-october-5-9-tickets-13115894995?discount=EarlyAdopter * *—**save $349!* -- 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/CALdYGa_hEy%3Dw8hYTg9ff4SvgCXFsR_w5AZogntTrL9QvaKx%2BqQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: who updated my puppet.conf on puppet master
On Monday, March 16, 2015 at 2:59:33 PM UTC-5, Robert Chen wrote: 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? Puppetdb does not modify your puppet.conf. Puppet itself might do, but this is a function of the classes and data assigned to the master in your manifests. By default, the agent logs resource changes it applies, so if it's the agent changing your configuration then you should find a record of it. 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/6c89aeed-cb3c-4c98-a06e-a25cbbee0980%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Could not retrieve file metadata ... end of file reached
I am not convinced that this is to do with an agent being busy then attempting the next connection. Info: Retrieving pluginfacts Info: Retrieving plugin Info: Loading facts Error: Could not retrieve catalog from remote server: end of file reached Warning: Not using cache on failed catalog Error: Could not retrieve catalog; skipping run The above all happened within a few seconds. I might argue within 4-5 seconds. Unless of course I'd misunderstood your hypothesis? On 13 March 2015 at 05:28, Josh Cooper j...@puppetlabs.com wrote: On Thu, Mar 12, 2015 at 4:21 AM, James Green james.mk.gr...@gmail.com wrote: I was running puppet agent -t --noop repeatedly with this error. Running again, this time omitting --noop, it succeeded. Not entirely clear what this tells me... On 12 March 2015 at 10:58, James Green james.mk.gr...@gmail.com wrote: Error: /Stage[main]/Our_unattended_upgrades/File[/etc/apt/apt.conf.d/20auto-upgrades]: Could not evaluate: Could not retrieve file metadata for puppet:///modules/our_unattended_upgrades/etc/apt/apt.conf.d/20auto-upgrades: end of file reached Wrapped exception: end of file reached Versions on the server: ii facter 2.4.1-1puppetlabs1 all Ruby module for collecting simple facts about a host operating system ii hiera1.3.4-1puppetlabs1 all A simple pluggable Hierarchical Database. ii puppet 3.7.4-1puppetlabs1 all Centralized configuration management - agent startup and compatibility scripts ii puppet-common3.7.4-1puppetlabs1 all Centralized configuration management ii puppetdb 2.2.2-1puppetlabs1 all PuppetDB Centralized Storage. ii puppetdb-terminus2.2.2-1puppetlabs1 all Connect Puppet to PuppetDB by setting up a terminus for PuppetDB. ii puppetlabs-release 1.0-11 all Package to install Puppet Labs gpg key and apt repo ii puppetmaster-common 3.7.4-1puppetlabs1 all Puppet master common scripts ii puppetmaster-passenger 3.7.4-1puppetlabs1 all Centralised configuration management - master setup to run under mod passenger Are we looking at a known bug or are we really going to need to debug this? James On 11 March 2015 at 09:47, James Green james.mk.gr...@gmail.com wrote: Hi, Sorry for the delayed response. In our case we are using Passenger. On 5 March 2015 at 15:24, Henrik Lindberg henrik.lindb...@cloudsmith.com wrote: On 2015-05-03 12:02, James Green wrote: We occasionally have an agent fail because of this. I'm told by others running the agents more frequently that it appears to be at random and not on anything particularly large. If you are using webrick then it is most likely a concurrency problem (more than one agent calling in at the same time). Webrick is not recommended for production use because of this. - henrik -- Visit my Blog Puppet on the Edge http://puppet-on-the-edge.blogspot.se/ -- 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/md9sfc%24r1e%241%40ger.gmane.org. 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/CAMH6%2Bay6EoB1zCZ587s%2B-gWno%3DGdHBR%3DKkhmD1aVHHXn66TsVw%40mail.gmail.com https://groups.google.com/d/msgid/puppet-users/CAMH6%2Bay6EoB1zCZ587s%2B-gWno%3DGdHBR%3DKkhmD1aVHHXn66TsVw%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. The fact that you are on puppet 3.7 and the error occasionally occurs, but not always, makes me think it's https://tickets.puppetlabs.com/browse/PUP-3238. Starting in puppet 3.7, we've added support for persistent HTTP connections, see https://docs.puppetlabs.com/puppet/latest/reference/subsystem_agent_master_comm.html#persistent-connections--keepalive . This eliminates the TCP/SSL handshake for every file metadata and content request, and greatly reduces the load on the master. But there is a possibility that a loadbalancer or puppetmaster may close an idle connection. Unfortunately, ruby does not surface socket errors when writing a request, only when reading. So often this issue manifests itself with end of file reached. To confirm if this is the case, make sure the puppet agent's http_keep_alive setting is
Re: [Puppet Users] Could not retrieve file metadata ... end of file reached
On Tue, Mar 17, 2015 at 4:52 AM, James Green james.mk.gr...@gmail.com wrote: I am not convinced that this is to do with an agent being busy then attempting the next connection. Info: Retrieving pluginfacts Info: Retrieving plugin Info: Loading facts Error: Could not retrieve catalog from remote server: end of file reached Warning: Not using cache on failed catalog Error: Could not retrieve catalog; skipping run The above all happened within a few seconds. I might argue within 4-5 seconds. Unless of course I'd misunderstood your hypothesis? Puppet's persistent http connection feature will attempt to reuse the connection for the duration of the run. There are several opportunities for the connection to remain idle while the puppet agent is busy doing other work, e.g. downloading a package from a repo, executing a long running process, evaluating facts (like your example above), etc. If the connection is idle longer than the master (or load-balancer's) keep alive or idle timeouts, then the server side will close the connection. For example, apache 2.4 defaults HTTP KeepAliveTimeout is 5 seconds[1], and I've seen customer environments where haproxy idle timeouts were set to 60 seconds. One way to check if the server side is closing the connection, is to disable keep alive on the agent as I mentioned earlier. If the problem seems to go away, then I'd try re-enabling keep alive on the agent, and running tcpdump during an agent run. You'll likely see the master/load-balancer sending a TCP RST some exact number of seconds after the agent last wrote to the socket. To resolve the issue, make sure your server side keep alive timeouts are greater than the agent's, either by increasing the server's timeout, or decreasing the agent's. [1] http://httpd.apache.org/docs/2.4/mod/core.html#keepalivetimeout On 13 March 2015 at 05:28, Josh Cooper j...@puppetlabs.com wrote: On Thu, Mar 12, 2015 at 4:21 AM, James Green james.mk.gr...@gmail.com wrote: I was running puppet agent -t --noop repeatedly with this error. Running again, this time omitting --noop, it succeeded. Not entirely clear what this tells me... On 12 March 2015 at 10:58, James Green james.mk.gr...@gmail.com wrote: Error: /Stage[main]/Our_unattended_upgrades/File[/etc/apt/apt.conf.d/20auto-upgrades]: Could not evaluate: Could not retrieve file metadata for puppet:///modules/our_unattended_upgrades/etc/apt/apt.conf.d/20auto-upgrades: end of file reached Wrapped exception: end of file reached Versions on the server: ii facter 2.4.1-1puppetlabs1 all Ruby module for collecting simple facts about a host operating system ii hiera1.3.4-1puppetlabs1 all A simple pluggable Hierarchical Database. ii puppet 3.7.4-1puppetlabs1 all Centralized configuration management - agent startup and compatibility scripts ii puppet-common3.7.4-1puppetlabs1 all Centralized configuration management ii puppetdb 2.2.2-1puppetlabs1 all PuppetDB Centralized Storage. ii puppetdb-terminus2.2.2-1puppetlabs1 all Connect Puppet to PuppetDB by setting up a terminus for PuppetDB. ii puppetlabs-release 1.0-11 all Package to install Puppet Labs gpg key and apt repo ii puppetmaster-common 3.7.4-1puppetlabs1 all Puppet master common scripts ii puppetmaster-passenger 3.7.4-1puppetlabs1 all Centralised configuration management - master setup to run under mod passenger Are we looking at a known bug or are we really going to need to debug this? James On 11 March 2015 at 09:47, James Green james.mk.gr...@gmail.com wrote: Hi, Sorry for the delayed response. In our case we are using Passenger. On 5 March 2015 at 15:24, Henrik Lindberg henrik.lindb...@cloudsmith.com wrote: On 2015-05-03 12:02, James Green wrote: We occasionally have an agent fail because of this. I'm told by others running the agents more frequently that it appears to be at random and not on anything particularly large. If you are using webrick then it is most likely a concurrency problem (more than one agent calling in at the same time). Webrick is not recommended for production use because of this. - henrik -- Visit my Blog Puppet on the Edge http://puppet-on-the-edge.blogspot.se/ -- 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/md9sfc%24r1e%241%40ger.gmane.org. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Puppet
[Puppet Users] Questions about PE
HI folks, Six months into my project to bring Foreman/Puppet into my work environment someone has asked the question Hey! Can we get a licensed version of this with support? My answer, sure... where's the funding? That aside I have some questions about Puppet Enterprise: 1) Does it work with Foreman? 2) Can it be installed from an internal RPM repository? The platform this will happen on is RHEL 6 (possibly 7 in the future). 3) If it doesn't work with Foreman is there an equivalent ENC and front end for PE? -- 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/CAArvnv1G6OKzvgcr%2BZtJL6WreMyYsDqvTSKWmv%3DCBt4iK01E%2Bw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
