Arnaud Gomes-do-Vale
2012-Oct-02 15:10 UTC
[Puppet Users] Fileserver error with Puppet 3.0
Hi, I am evaluating Puppet 3.0 on my test puppetmaster. I have what looks like a regression from Puppet 2.7.19: Info: Retrieving plugin Info: Loading facts in /var/lib/puppet/lib/facter/ircamnetwork.rb Info: Loading facts in /var/lib/puppet/lib/facter/root_home.rb Info: Loading facts in /var/lib/puppet/lib/facter/passenger_root.rb Info: Loading facts in /var/lib/puppet/lib/facter/raid_md.rb Info: Loading facts in /var/lib/puppet/lib/facter/mysql.rb Info: Loading facts in /var/lib/puppet/lib/facter/ircamserver.rb Info: Loading facts in /var/lib/puppet/lib/facter/facter_dot_d.rb Info: Loading facts in /var/lib/puppet/lib/facter/puppet_vardir.rb Info: Caching catalog for cobbler-staging.ircam.fr Info: Applying configuration version ''1349189813'' Error: /Stage[main]/Collectd::Node/Collectd::Collectd_service[network]/File[/etc/collectd.d/network.conf]: Could not evaluate: Error 400 on SERVER: Not authorized to call find on /file_metadata/private/modules/collectd/network.conf Could not retrieve file metadata for puppet:///private/modules/collectd/network.conf: Error 400 on SERVER: Not authorized to call find on /file_metadata/private/modules/collectd/network.conf /Stage[main]/Collectd/Service[collectd]: Dependency File[/etc/collectd.d/network.conf] has failures: true Warning: /Stage[main]/Collectd/Service[collectd]: Skipping because of failed dependencies Finished catalog run in 5.41 seconds I am aware of bug #16667 but I fail to see if it is relevant; I never saw the deprecation notice when running Puppet 2.7. To give a little more detail, here is the definition of collectd_service: define collectd_service () { file { "/etc/collectd.d/${name}.conf": source => [ "puppet:///private/modules/collectd/${name}.conf", "puppet:///modules/collectd/services/${name}.conf", ], owner => ''root'', group => ''root'', mode => ''0444'', require => Package[''collectd''], notify => Service[''collectd''], } } So IIUC, the client should first try the private mount on the fileserver, and fall back to the module in case of failure, right? And here is the contents of fileserver.conf, which defines the private mount: [files] path /etc/puppet/files allow 129.102.0.0/16 allow 2001:660:3004::/49 [private] path /etc/puppet/files-private/%H allow 129.102.0.0/16 allow 2001:660:3004::/49 Here are the debug logs on both sides if needed: http://files.glou.org/puppet/puppetmaster-fileserver-failure.log http://files.glou.org/puppet/puppet-agent-fileserver-failure.log -- A -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
In Puppet 3.x, allow directives are limited to hostnames, if you wish to allow an ip address, the allow_ip directive should be used. This was in response to CVE-2012-3408 (http://puppetlabs.com/security/cve/cve-2012-3408/). On Tue, Oct 2, 2012 at 8:10 AM, Arnaud Gomes-do-Vale <Arnaud.Gomes@ircam.fr> wrote:> Hi, > > I am evaluating Puppet 3.0 on my test puppetmaster. I have what looks > like a regression from Puppet 2.7.19: > > Info: Retrieving plugin > Info: Loading facts in /var/lib/puppet/lib/facter/ircamnetwork.rb > Info: Loading facts in /var/lib/puppet/lib/facter/root_home.rb > Info: Loading facts in /var/lib/puppet/lib/facter/passenger_root.rb > Info: Loading facts in /var/lib/puppet/lib/facter/raid_md.rb > Info: Loading facts in /var/lib/puppet/lib/facter/mysql.rb > Info: Loading facts in /var/lib/puppet/lib/facter/ircamserver.rb > Info: Loading facts in /var/lib/puppet/lib/facter/facter_dot_d.rb > Info: Loading facts in /var/lib/puppet/lib/facter/puppet_vardir.rb > Info: Caching catalog for cobbler-staging.ircam.fr > Info: Applying configuration version ''1349189813'' > Error: /Stage[main]/Collectd::Node/Collectd::Collectd_service[network]/File[/etc/collectd.d/network.conf]: Could not evaluate: Error 400 on SERVER: Not authorized to call find on /file_metadata/private/modules/collectd/network.conf Could not retrieve file metadata for puppet:///private/modules/collectd/network.conf: Error 400 on SERVER: Not authorized to call find on /file_metadata/private/modules/collectd/network.conf > /Stage[main]/Collectd/Service[collectd]: Dependency File[/etc/collectd.d/network.conf] has failures: true > Warning: /Stage[main]/Collectd/Service[collectd]: Skipping because of failed dependencies > Finished catalog run in 5.41 seconds > > I am aware of bug #16667 but I fail to see if it is relevant; I never > saw the deprecation notice when running Puppet 2.7. > > To give a little more detail, here is the definition of > collectd_service: > > define collectd_service () { > file { "/etc/collectd.d/${name}.conf": > source => [ > "puppet:///private/modules/collectd/${name}.conf", > "puppet:///modules/collectd/services/${name}.conf", > ], > owner => ''root'', > group => ''root'', > mode => ''0444'', > require => Package[''collectd''], > notify => Service[''collectd''], > } > } > > So IIUC, the client should first try the private mount on the > fileserver, and fall back to the module in case of failure, right? And > here is the contents of fileserver.conf, which defines the private > mount: > > [files] > path /etc/puppet/files > allow 129.102.0.0/16 > allow 2001:660:3004::/49 > > [private] > path /etc/puppet/files-private/%H > allow 129.102.0.0/16 > allow 2001:660:3004::/49 > > Here are the debug logs on both sides if needed: > > http://files.glou.org/puppet/puppetmaster-fileserver-failure.log > http://files.glou.org/puppet/puppet-agent-fileserver-failure.log > > -- > A > > -- > 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+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. >-- Matthaus Owens 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Arnaud Gomes-do-Vale
2012-Oct-03 11:52 UTC
Re: [Puppet Users] Fileserver error with Puppet 3.0
Matthaus Owens <matthaus@puppetlabs.com> writes:> In Puppet 3.x, allow directives are limited to hostnames, if you wish > to allow an ip address, the allow_ip directive should be used. This > was in response to CVE-2012-3408 > (http://puppetlabs.com/security/cve/cve-2012-3408/).Thank you for your help. Looks like something is still broken. I replaced all "allow" directoves in fileserver.conf with allow_ip; I still had the same errors: ### Broken! [files] path /etc/puppet/files allow_ip 129.102.0.0/16 allow_ip 2001:660:3004::/49 [private] path /etc/puppet/files-private/%H allow_ip 129.102.0.0/16 allow_ip 2001:660:3004::/49 # EOF I then replaced them with "allow *", which fixed the problem but introduces a change of behavior: ### Working [files] path /etc/puppet/files allow * [private] path /etc/puppet/files-private/%H allow * # EOF This is definitely a regression. -- A -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Wednesday, October 3, 2012 1:53:13 PM UTC+2, Arnaud Gomes-do-Vale wrote:> > Thank you for your help. Looks like something is still broken. > > I replaced all "allow" directoves in fileserver.conf with allow_ip; I > still had the same errors: >I ran into the same issue yesterday, which is caused by an incorrect handling of the allow_ip keyword in the parser for fileserver.conf, and have filed the following bug report: http://projects.puppetlabs.com/issues/16686 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/xjI9T4M0uRAJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.