Re: [Puppet Users] Re: Puppet 3.0: Not authorized to call find on /file_metadata, more issues?
I see the ChangeLog in 3.0.2 and this bug is still not addressed? Is there a technical problem that is not yet resolved, or is this just a matter of priority and time. -- 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/-/aoZ7BtDcqwwJ. 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.
Re: [Puppet Users] Re: Puppet 3.0: Not authorized to call find on /file_metadata, more issues?
I found out that I was missing a change in puppet.conf due using Puppetmaster Passenger: from: ssl_client_header = SSL_CLIENT_S_DN to: ssl_client_header = HTTP_X_SSL_SUBJECT Now the permission issues are gone. Weird enough that my Puppetmaster 2.7.x environment works without this change. Felipe On Tuesday, November 13, 2012 2:28:29 PM UTC-8, Felipe Salum wrote: I'm also having the same issue on the other locations. Not sure what's wrong since this is a default installation of puppet 3 with the original auth.conf Error: /Stage[main]/Puppetdb::Master::Routes/File[/etc/puppet/routes.yaml]: Could not evaluate: Error 403 on SERVER: Forbidden request: puppet2.puppet.test(192.168.168.10) access to /file_metadata/modules/puppetdb/routes.yaml [find] at :102 Could not retrieve file metadata for puppet:///modules/puppetdb/routes.yaml: Error 403 on SERVER: Forbidden request: puppet2.puppet.test(192.168.168.10) access to /file_metadata/modules/puppetdb/routes.yaml [find] at :102 Error: Could not retrieve catalog from remote server: Error 403 on SERVER: Forbidden request: puppet2.puppet.test(192.168.168.10) access to /catalog/puppet2.puppet.test [find] at :101 Warning: Not using cache on failed catalog Error: Could not retrieve catalog; skipping run Error: Could not send report: Error 403 on SERVER: Forbidden request: puppet2.puppet.test(192.168.168.10) access to /report/puppet2.puppet.test [save] at :102 Maybe it is a naming resolution issue ? I'm using /etc/hosts since this is a vagrant environment only for testing purposes. If I start updating auth.conf to use 'auth no' everywhere it passes. I don't see the problem on my production servers, so it worries me more :) On Monday, November 12, 2012 4:27:41 PM UTC-8, Felipe Salum wrote: Hi Nick. Actually this is a new environment I'm setting up using vagrant, puppet 3 and the default auth.conf. I had to add allow_ip to the /reports request to make it work. Not sure why but it sometimes fail when using the puppet server provider from vagrant. Thanks, Felipe On Mon, Nov 12, 2012 at 4:22 PM, Nick Fagerlund nick.fagerl...@puppetlabs.com wrote: On Saturday, November 10, 2012 5:43:48 PM UTC-8, Felipe Salum wrote: Is this related to the same error I have when I run the puppet agent on my nodes ? Nov 11 01:40:09 squeeze puppet-agent[8683]: Could not send report: Error 403 on SERVER: Forbidden request: puppetdb1.puppet.test(192.168. **168.12) access to /report/puppetdb1.puppet.test [save] authenticated at :67 No, other than that they're both related to authentication in auth.conf. If you were upgrading from 2.6, note that the default value of the 'report' setting changed between 2.6 and 2.7: http://docs.puppetlabs.com/references/2.7.latest/configuration.html#report http://docs.puppetlabs.com/references/2.6.latest/configuration.html#report So if your auth.conf file doesn't allow authenticated nodes to send save requests to /report, you will get errors. Examine your auth.conf file and compare it to the one here: https://github.com/puppetlabs/puppet/blob/master/conf/auth.conf You should have AT LEAST all the same rules, although your site may have some extra rules as well. Be aware that order matters in this file. -- 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/-/rcFTBsu-IqkJ. 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. -- 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/-/PJt_eVvvh9gJ. 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.
Re: [Puppet Users] Re: Puppet 3.0: Not authorized to call find on /file_metadata, more issues?
I'm also having the same issue on the other locations. Not sure what's wrong since this is a default installation of puppet 3 with the original auth.conf Error: /Stage[main]/Puppetdb::Master::Routes/File[/etc/puppet/routes.yaml]: Could not evaluate: Error 403 on SERVER: Forbidden request: puppet2.puppet.test(192.168.168.10) access to /file_metadata/modules/puppetdb/routes.yaml [find] at :102 Could not retrieve file metadata for puppet:///modules/puppetdb/routes.yaml: Error 403 on SERVER: Forbidden request: puppet2.puppet.test(192.168.168.10) access to /file_metadata/modules/puppetdb/routes.yaml [find] at :102 Error: Could not retrieve catalog from remote server: Error 403 on SERVER: Forbidden request: puppet2.puppet.test(192.168.168.10) access to /catalog/puppet2.puppet.test [find] at :101 Warning: Not using cache on failed catalog Error: Could not retrieve catalog; skipping run Error: Could not send report: Error 403 on SERVER: Forbidden request: puppet2.puppet.test(192.168.168.10) access to /report/puppet2.puppet.test [save] at :102 Maybe it is a naming resolution issue ? I'm using /etc/hosts since this is a vagrant environment only for testing purposes. If I start updating auth.conf to use 'auth no' everywhere it passes. I don't see the problem on my production servers, so it worries me more :) On Monday, November 12, 2012 4:27:41 PM UTC-8, Felipe Salum wrote: Hi Nick. Actually this is a new environment I'm setting up using vagrant, puppet 3 and the default auth.conf. I had to add allow_ip to the /reports request to make it work. Not sure why but it sometimes fail when using the puppet server provider from vagrant. Thanks, Felipe On Mon, Nov 12, 2012 at 4:22 PM, Nick Fagerlund nick.fagerl...@puppetlabs.com wrote: On Saturday, November 10, 2012 5:43:48 PM UTC-8, Felipe Salum wrote: Is this related to the same error I have when I run the puppet agent on my nodes ? Nov 11 01:40:09 squeeze puppet-agent[8683]: Could not send report: Error 403 on SERVER: Forbidden request: puppetdb1.puppet.test(192.168. **168.12) access to /report/puppetdb1.puppet.test [save] authenticated at :67 No, other than that they're both related to authentication in auth.conf. If you were upgrading from 2.6, note that the default value of the 'report' setting changed between 2.6 and 2.7: http://docs.puppetlabs.com/references/2.7.latest/configuration.html#report http://docs.puppetlabs.com/references/2.6.latest/configuration.html#report So if your auth.conf file doesn't allow authenticated nodes to send save requests to /report, you will get errors. Examine your auth.conf file and compare it to the one here: https://github.com/puppetlabs/puppet/blob/master/conf/auth.conf You should have AT LEAST all the same rules, although your site may have some extra rules as well. Be aware that order matters in this file. -- 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/-/rcFTBsu-IqkJ. 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. -- 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/-/53V32bKqFYMJ. 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.
Re: [Puppet Users] Re: Puppet 3.0: Not authorized to call find on /file_metadata, more issues?
Hi Nick. Actually this is a new environment I'm setting up using vagrant, puppet 3 and the default auth.conf. I had to add allow_ip to the /reports request to make it work. Not sure why but it sometimes fail when using the puppet server provider from vagrant. Thanks, Felipe On Mon, Nov 12, 2012 at 4:22 PM, Nick Fagerlund nick.fagerl...@puppetlabs.com wrote: On Saturday, November 10, 2012 5:43:48 PM UTC-8, Felipe Salum wrote: Is this related to the same error I have when I run the puppet agent on my nodes ? Nov 11 01:40:09 squeeze puppet-agent[8683]: Could not send report: Error 403 on SERVER: Forbidden request: puppetdb1.puppet.test(192.168. **168.12) access to /report/puppetdb1.puppet.test [save] authenticated at :67 No, other than that they're both related to authentication in auth.conf. If you were upgrading from 2.6, note that the default value of the 'report' setting changed between 2.6 and 2.7: http://docs.puppetlabs.com/references/2.7.latest/configuration.html#report http://docs.puppetlabs.com/references/2.6.latest/configuration.html#report So if your auth.conf file doesn't allow authenticated nodes to send save requests to /report, you will get errors. Examine your auth.conf file and compare it to the one here: https://github.com/puppetlabs/puppet/blob/master/conf/auth.conf You should have AT LEAST all the same rules, although your site may have some extra rules as well. Be aware that order matters in this file. -- 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/-/rcFTBsu-IqkJ. 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. -- 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.
RE: [Puppet Users] Re: Puppet 3.0: Not authorized to call find on /file_metadata, more issues?
Does anyone remember the following deprecation warning: DEPRECATION NOTICE: Files found in modules without specifying 'modules' in file path will be deprecated in the next major release. Please fix module 'zabbix_agent' when no 0.24.x clients are present I believe I had the same problem you are having now, and the solution was to follow the above advise and add 'modules' to the file sources. Hope this helps you too. -Esther From: puppet-users@googlegroups.com [mailto:puppet-users@googlegroups.com] On Behalf Of Forrie Sent: woensdag 24 oktober 2012 23:41 To: puppet-users@googlegroups.com Subject: Re: [Puppet Users] Re: Puppet 3.0: Not authorized to call find on /file_metadata, more issues? I applied the fixes to my test/staging config and it's not very happy. I think I'll just wait for the official fix to be out before I move forward with 3.x. :-) For giggles, here's the log: # puppet agent --test Ignoring --listen on onetime run Warning: Unable to fetch my node definition, but the agent run will continue: Warning: Error 403 on SERVER: Forbidden request: stage1.myserver.com(127.0.0.1) access to /node/stage1.myserver.com [find] authenticated at :102 Info: Retrieving plugin Error: /File[/var/lib/puppet/lib]: Failed to generate additional resources using 'eval_generate: Error 403 on SERVER: Forbidden request: stage1.myserver.com(127.0.0.1) access to /file_metadata/plugins [search] authenticated at :102 Error: /File[/var/lib/puppet/lib]: Could not evaluate: Error 403 on SERVER: Forbidden request: stage1.myserver.com(127.0.0.1) access to /file_metadata/plugins [find] authenticated at :102 Could not retrieve file metadata for puppet://stage1.myserver.com/plugins: Error 403 on SERVER: Forbidden request: stage1.myserver.com(127.0.0.1) access to /file_metadata/plugins [find] authenticated at :102 Info: Caching catalog for stage1.myserver.com Info: Applying configuration version '1351113815' Error: /Stage[main]/Ntp-client/File[/etc/ntp.conf]: Could not evaluate: Error 403 on SERVER: Forbidden request: stage1.myserver.com(127.0.0.1) access to /file_metadata/etc/ntp.conf [find] authenticated at :102 Could not retrieve file metadata for puppet:///etc/ntp.conf: Error 403 on SERVER: Forbidden request: stage1.myserver.com(127.0.0.1) access to /file_metadata/etc/ntp.conf [find] authenticated at :102 /Stage[main]/Ntp-client/Service[ntpd]: Dependency File[/etc/ntp.conf] has failures: true Warning: /Stage[main]/Ntp-client/Service[ntpd]: Skipping because of failed dependencies Everything under /var/lib/puppet was created by the puppetmaster -- /var/lib/puppet/lib is owned by root:root as it is on my /working/ puppet master. [ fileserver.conf ] [files] path /etc/puppet/files allow * [ auth.conf ] path ~ ^/file_(metadata|content)/files/ auth yes allow /^(.+\.)?example.com$/ allow_ip 10.101.0.0/24 allow_ip 10.103.0.0/24 allow_ip 127.0.0.0/24 I tried the last one, 127/24, to see if the issue was with the client connecting locally; made no difference. Everything else in auth.conf is allow * We have a set of files in /etc/puppet/files/etc/blah-blah that are copied over to the clients. They are not in a module (don't need to be). I read somewhere that you need to put your files in the modules that belong to them, this doesn't apply here as far as I can tell. In any case... that's all going off on a tangent.I hope the fix will be out soon :-) Thanks. -- 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/-/cx8NwigZpBAJ. 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. -- 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.
Re: [Puppet Users] Re: Puppet 3.0: Not authorized to call find on /file_metadata, more issues?
On Wed, Oct 24, 2012 at 1:28 AM, imd ivan.degtyare...@gmail.com wrote: Changed the auth.conf and fileserver.conf in a way you suggested above, now client gives another error: err: /Stage[main]/Profiles/File[/etc/profile.d/wrkdir.py]: Could not evaluate: Error 400 on SERVER: Not authorized to call find on /file_metadata/files/shell/wrkdir.py Could not retrieve file metadata for puppet:///files/shell/wrkdir.py: Error 400 on SERVER: Not authorized to call find on /file_metadata/files/shell/wrkdir.py at /etc/puppet/manifests/classes/profiles.pp:42 With '/files/' or without, same error. I'm taking a look at reproducing this issue and augmenting the work-around. I hope to follow up with more information shortly. My suspicion is that there isn't an auth rule that matches the file_metadata call, which is a different REST URI than the file content call. -Jeff -- 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.
Re: [Puppet Users] Re: Puppet 3.0: Not authorized to call find on /file_metadata, more issues?
On Wed, Oct 24, 2012 at 1:28 AM, imd ivan.degtyare...@gmail.com wrote: Changed the auth.conf and fileserver.conf in a way you suggested above, now client gives another error: err: /Stage[main]/Profiles/File[/etc/profile.d/wrkdir.py]: Could not evaluate: Error 400 on SERVER: Not authorized to call find on /file_metadata/files/shell/wrkdir.py Could not retrieve file metadata for puppet:///files/shell/wrkdir.py: Error 400 on SERVER: Not authorized to call find on /file_metadata/files/shell/wrkdir.py at /etc/puppet/manifests/classes/profiles.pp:42 With '/files/' or without, same error. Did you add the auth.conf rules before the default `path /file` rule. For example, please see https://gist.github.com/3947951 Note how the default auth.conf file allows all requests. The rules Nick mentioned need to go before the path /file rule on line 74, otherwise they'll never be reached because first match wins. I was able to fully work-around the issue by using these rules, also shown in the patch files included in the gist: # JJM Lock down the files fileserver mount exported from filserver.conf # Remember, this file is parsed top to bottom and the first match wins so # more specific rules need to be above more generalized rules. # The following two rules mean the agent must posses a signed certificate and # must be connecting from the 192.168.0.0/16 subnet. path /file_metadata/files auth yes allow_ip 192.168.0.0/16 path /file_content/files auth yes allow_ip 192.168.0.0/16 # unconditionally allow access to all file services # which means in practice that fileserver.conf will # still be used path /file allow * Please note, I think Nick's original suggestion is slightly incorrect because it should now contain the allow *.example.com statement, as this would allow all agents who poses a signed certificate with a CN ending in example.com, regardless of their IP address. If you truly want to authorize based on IP address, please stick with `auth yes`, which means agents must posses a signed, trusted certificate, and allow_ip which will grant access. -Jeff -- 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.
Re: [Puppet Users] Re: Puppet 3.0: Not authorized to call find on /file_metadata, more issues?
On Wednesday, October 24, 2012 11:39:50 AM UTC-7, Jeff McCune wrote: Please note, I think Nick's original suggestion is slightly incorrect because it should now contain the allow *.example.com statement, as this would allow all agents who poses a signed certificate with a CN ending in example.com, regardless of their IP address. Hmm, really? I thought shell-style globbing didn't work in auth.conf allow directives, or at least that's what I discovered way back in the day. When we added globbing in 2.7.1, we implemented it with regular expressions instead of shell-style globs (http://docs.puppetlabs.com/guides/rest_auth_conf.html#allow), hence the allow /^(.+\.)?example.com$/ line in my example. -- 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/-/ngv1CaHCZ98J. 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.
Re: [Puppet Users] Re: Puppet 3.0: Not authorized to call find on /file_metadata, more issues?
On Wed, Oct 24, 2012 at 1:35 PM, Nick Fagerlund nick.fagerl...@puppetlabs.com wrote: On Wednesday, October 24, 2012 11:39:50 AM UTC-7, Jeff McCune wrote: Please note, I think Nick's original suggestion is slightly incorrect because it should now contain the allow *.example.com statement, as this would allow all agents who poses a signed certificate with a CN ending in example.com, regardless of their IP address. Hmm, really? I thought shell-style globbing didn't work in auth.conf allow directives, or at least that's what I discovered way back in the day. When we added globbing in 2.7.1, we implemented it with regular expressions instead of shell-style globs ( http://docs.puppetlabs.com/guides/rest_auth_conf.html#allow), hence the allow /^(.+\.)?example.com$/ line in my example. Right, sorry. The rules you posted are OK, it just took me a minute to grok them. -Jeff -- 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.
Re: [Puppet Users] Re: Puppet 3.0: Not authorized to call find on /file_metadata, more issues?
I applied the fixes to my test/staging config and it's not very happy. I think I'll just wait for the official fix to be out before I move forward with 3.x. :-) For giggles, here's the log: # puppet agent --test Ignoring --listen on onetime run Warning: Unable to fetch my node definition, but the agent run will continue: Warning: Error 403 on SERVER: Forbidden request: stage1.myserver.com(127.0.0.1) access to /node/stage1.myserver.com [find] authenticated at :102 Info: Retrieving plugin Error: /File[/var/lib/puppet/lib]: Failed to generate additional resources using 'eval_generate: Error 403 on SERVER: Forbidden request: stage1.myserver.com(127.0.0.1) access to /file_metadata/plugins [search] authenticated at :102 Error: /File[/var/lib/puppet/lib]: Could not evaluate: Error 403 on SERVER: Forbidden request: stage1.myserver.com(127.0.0.1) access to /file_metadata/plugins [find] authenticated at :102 Could not retrieve file metadata for puppet://stage1.myserver.com/plugins: Error 403 on SERVER: Forbidden request: stage1.myserver.com(127.0.0.1) access to /file_metadata/plugins [find] authenticated at :102 Info: Caching catalog for stage1.myserver.com Info: Applying configuration version '1351113815' Error: /Stage[main]/Ntp-client/File[/etc/ntp.conf]: Could not evaluate: Error 403 on SERVER: Forbidden request: stage1.myserver.com(127.0.0.1) access to /file_metadata/etc/ntp.conf [find] authenticated at :102 Could not retrieve file metadata for puppet:///etc/ntp.conf: Error 403 on SERVER: Forbidden request: stage1.myserver.com(127.0.0.1) access to /file_metadata/etc/ntp.conf [find] authenticated at :102 /Stage[main]/Ntp-client/Service[ntpd]: Dependency File[/etc/ntp.conf] has failures: true Warning: /Stage[main]/Ntp-client/Service[ntpd]: Skipping because of failed dependencies Everything under /var/lib/puppet was created by the puppetmaster -- /var/lib/puppet/lib is owned by root:root as it is on my /working/ puppet master. [ fileserver.conf ] [files] path /etc/puppet/files allow * [ auth.conf ] path ~ ^/file_(metadata|content)/files/ auth yes allow /^(.+\.)?example.com$/ allow_ip 10.101.0.0/24 allow_ip 10.103.0.0/24 allow_ip 127.0.0.0/24 I tried the last one, 127/24, to see if the issue was with the client connecting locally; made no difference. Everything else in auth.conf is allow * We have a set of files in /etc/puppet/files/etc/blah-blah that are copied over to the clients. They are not in a module (don't need to be). I read somewhere that you need to put your files in the modules that belong to them, this doesn't apply here as far as I can tell. In any case... that's all going off on a tangent.I hope the fix will be out soon :-) Thanks. -- 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/-/cx8NwigZpBAJ. 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.
Re: [Puppet Users] Re: Puppet 3.0: Not authorized to call find on /file_metadata, more issues?
On 10/19/2012 12:44 AM, Forrie wrote: I've just built a staging system, to work out the issues I've been having with Puppet 3.x. We now have 3.0.1 installed there. I am again running into this fileserver issue and the same errors. I read through some complaints here and I see mention that auth.conf is only able to use allow_ip. In that file, I have allow * under path /file which should allow everyone. I read that the allow_ip is not yet working for fileserver.conf. My fileserver.conf has allow 192.168.0.0/24 which was working until the upgrade. So, can someone explain to me in plain english how we're supposed to get this working properly now. I read through more notes and I don't see mention of this in upgrading, etc. Perhaps I missed something -- I just want to get it working. If it's an outstanding but that is preventing Puppet from working right now, I would think this would be a high-priority fix :-) I would be interested too, because I've hit the same problem with both 3.0.0 and 3.0.1: This is my /etc/puppet/fileserver.conf: [files] path /etc/puppet/files deny * allow * And client says: Could not evaluate: Error 400 on SERVER: Not authorized to call find on /file_metadata/files/users/home/user/jsosic Could not retrieve file metadata for puppet:///files/users/home/user/jsosic: Error 400 on SERVER: Not authorized to call find on /file_metadata/files/users/home/user/jsosic I've tried: chown -R puppet:puppet /etc/puppet/files just in case, but no luck. Solution I found so far is to remove deny * and leave only allow *. allow 192.168.0.0/16 doesn't work too. So this is definitely broken in many ways Documentation clearly says allow takes precedence. Anyway, this is just testing installation so I'll leave it as is... My fileserver.conf looks like this now: [files] path /etc/puppet/files allow * and that works... -- Jakov Sosic www.srce.unizg.hr -- 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.
