Fileserver error with Puppet 3.0

[Arnaud Gomes-do-Vale]

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

[Matthaus Owens]

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/).

> --
> You received this message because you are subscribed to the Google Groups "Puppet Users" group.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
>



--
Matthaus Owens
Release Manager, Puppet Labs

[Arnaud Gomes-do-Vale]

Matthaus Owens <matt...@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

[Wolfgang Miedl]

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