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.go...@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
