new REST auth system...
Nigel Kersten
I've got a few minor bugs I've found, but the major one I have at the moment is that I simply can't get /file_metadata requests to work at all.
Not authorized to call find on /file_metadata/modulename/filename
Is this just me, or is there a bug here? I started with the supplied auth.conf, but haven't gotten far twiddling it myself.
--
Nigel Kersten
nig...@google.com
System Administrator
Google, Inc.
Brice Figureau
On Thu, June 18, 2009 00:38, Nigel Kersten wrote:
> so I guess this is primarily aimed at Brice... but I'm wondering if I'm
> the
> only one having issues getting the new auth setup working with multiple
> environments....
>
> I've got a few minor bugs I've found, but the major one I have at the
> moment
> is that I simply can't get /file_metadata requests to work at all.
>
> Not authorized to call find on /file_metadata/modulename/filename
>
> Is this just me, or is there a bug here? I started with the supplied
> auth.conf, but haven't gotten far twiddling it myself.
>
This error message doesn't come from the REST authorization system but the
file serving indirection system.
Check your fileserver.conf, it might not be set properly.
You still need one fileserver.conf until we remove the XMLRPC system
completely.
--
Brice Figureau
My Blog: http://www.masterzen.fr
Nigel Kersten
So I assumed that as my 0.24.8 clients are working happily against this same configuration, that the 0.25.0 client auth errors must have been due to the REST auth system as the XMLRPC system works happily with 0.24.8 clients.
Everything I do is with modules in environments, so I only have plugins/facts fileserver modules defined.
What should I have in my fileserver.conf to cope with the new behaviour then?
--
Brice Figureau
My Blog: http://www.masterzen.fr
Brice Figureau
Then you should be fine.
> What should I have in my fileserver.conf to cope with the new behaviour
> then?
Hmm, I really don't know :-(
I'll try to replicate the issue, but I think you might have found a bug.
--
Brice Figureau
Days of Wonder
Nigel Kersten
Yeah. Even if I use a ~ match with a regexp that matches everything,
and take everything else out, I get the same error.
Brice Figureau
The issue is not with the REST auth, it is with the indirector handling of
fileserver.conf. Is there anything fancy in this file?
I didn't had time to try setting up environments to test your issue yet.
I'll try that tomorrow.
Brice Figureau
I set up a few environments and modules, but couldn't replicate the issue
you are facing.
I'm wondering what are you doing that I'm not doing...
Can you post some config files?
Can you intrument the master with some debug instructions to see what
triggers the error?
--
Brice Figureau
My Blog: http://www.masterzen.fr/
Nigel Kersten
Sorry, somehow I lost track of this in my todo list.
> I set up a few environments and modules, but couldn't replicate the issue
> you are facing.
> I'm wondering what are you doing that I'm not doing...
> Can you post some config files?
So I have almost a generic puppet.conf file generated from genconfig.
I set up a simple webrick server. puppetmasterd --no-daemonize
--verbose --debug --trace
I set up an environment called "test"
[test]
modulepath = /var/lib/puppet/environments/test/modules
site.pp:
node default { include base }
/var/lib/puppet/environments/test/modules/base/manifests/init.pp:
class base {
notice("in base now")
file { "/tmp/testfile.txt":
ensure => file,
owner => root,
group => wheel,
mode => 0644,
source => "puppet:///base/testfile.txt",
}
}
and the corresponding file in:
/var/lib/puppet/environments/test/modules/base/files/testfile.txt
I get exactly the same errors.
client-side:
err: //Node[default]/base/File[/tmp/testfile.txt]: Failed to retrieve
current state of resource: Server returned 400: Not authorized to call
find on /file_metadata/base/testfile.txt Could not retrieve file
metadata for puppet:///base/testfile.txt: Server returned 400: Not
authorized to call find on /file_metadata/base/testfile.txt at
/var/lib/puppet/environments/test/modules/base/manifests/init.pp:11
server-side:
debug: importing
'/var/lib/puppet/environments/test/modules/base/manifests/init.pp'
info: Autoloaded module base
notice: Scope(Class[base]): in base now
notice: Compiled catalog for nigelk-laptop.corp.google.com in 0.03 seconds
/usr/lib/ruby/1.8/puppet/indirector/indirection.rb:283:in `check_authorization'
/usr/lib/ruby/1.8/puppet/indirector/indirection.rb:299:in `prepare'
/usr/lib/ruby/1.8/puppet/indirector/indirection.rb:186:in `find'
/usr/lib/ruby/1.8/puppet/indirector.rb:51:in `find'
/usr/lib/ruby/1.8/puppet/network/http/handler.rb:97:in `do_find'
/usr/lib/ruby/1.8/puppet/network/http/handler.rb:66:in `send'
/usr/lib/ruby/1.8/puppet/network/http/handler.rb:66:in `process'
/usr/lib/ruby/1.8/puppet/network/http/webrick/rest.rb:23:in `service'
/usr/lib/ruby/1.8/webrick/httpserver.rb:104:in `service'
/usr/lib/ruby/1.8/webrick/httpserver.rb:65:in `run'
/usr/lib/ruby/1.8/webrick/server.rb:173:in `start_thread'
/usr/lib/ruby/1.8/webrick/server.rb:162:in `start'
/usr/lib/ruby/1.8/webrick/server.rb:162:in `start_thread'
/usr/lib/ruby/1.8/webrick/server.rb:95:in `start'
/usr/lib/ruby/1.8/webrick/server.rb:92:in `each'
/usr/lib/ruby/1.8/webrick/server.rb:92:in `start'
/usr/lib/ruby/1.8/webrick/server.rb:23:in `start'
/usr/lib/ruby/1.8/webrick/server.rb:82:in `start'
/usr/lib/ruby/1.8/puppet/network/http/webrick.rb:40:in `listen'
/usr/lib/ruby/1.8/puppet/network/http/webrick.rb:40:in `initialize'
/usr/lib/ruby/1.8/puppet/network/http/webrick.rb:40:in `new'
/usr/lib/ruby/1.8/puppet/network/http/webrick.rb:40:in `listen'
/usr/lib/ruby/1.8/puppet/network/http/webrick.rb:37:in `synchronize'
/usr/lib/ruby/1.8/puppet/network/http/webrick.rb:37:in `listen'
/usr/lib/ruby/1.8/puppet/network/server.rb:131:in `listen'
/usr/lib/ruby/1.8/puppet/network/server.rb:146:in `start'
/usr/lib/ruby/1.8/puppet/daemon.rb:128:in `start'
/usr/lib/ruby/1.8/puppet/application/puppetmasterd.rb:96:in `main'
/usr/lib/ruby/1.8/puppet/application.rb:226:in `send'
/usr/lib/ruby/1.8/puppet/application.rb:226:in `run_command'
/usr/lib/ruby/1.8/puppet/application.rb:217:in `run'
/usr/sbin/puppetmasterd:66
err: Not authorized to call find on /file_metadata/base/testfile.txt
> Can you intrument the master with some debug instructions to see what
> triggers the error?
poking at it now.
Brice, are you perhaps not serving files out of modules using
puppet:///module/file URIs ?
Nigel Kersten
so I think I've found the problem, and it seems like you mustn't have
been using module mounts Brice?
puppet/file_serving/configuration.rb
find_mount(mount_name, node) will always fail as @mounts never
contains the module mountpoints.
This seems like kind of a killer bug for 0.25.x to me...
Brice Figureau
Nigel, thanks for trying again, and giving your config. That way I could
replicate the issue, which is not in the REST auth system but way down
in the file_serving code (see below for the explanation).
I'll file a ticket with the proper information.
I did, but in fact I had my testing environment badly setup, so puppet
was finding the module path from the regular modulepath instead of
trying in the said "testing" environement; so it wasn't failing.
> so I think I've found the problem, and it seems like you mustn't have
> been using module mounts Brice?
>
> puppet/file_serving/configuration.rb
>
> find_mount(mount_name, node) will always fail as @mounts never
> contains the module mountpoints.
It should contains the "modules" mount point which is enough.
> This seems like kind of a killer bug for 0.25.x to me...
The whole issue is the following:
* when the web server gets the request, it creates an indirection
request, filling attributes like ip or node from the HTTP request.
To do this, all the interesting attributes are given in a hash (called
options, see P::I::Request#new)
Once the request is properly initialized the options hash doesn't
contain the ip or node information.
* the request is transmitted to the file_serving layer, which happily
wants to use the node attribute to find environments. Unfortunately it
fetches the node value from the request options, not the request itself
(it even propagates the options hash all around the mounts). Since this
node information is empty, puppet fails to find the proper mount point,
and fails.
Possible cure:
1) In P::I::Request#set_attribute do not remove the attr from the
hash. Instant reward: it fixes everything with a one liner (ok there's
another one-line to change :ipaddress to :ip in P::I::FileServer)
or
2) Fix all the file_serving sub-system to transmit the whole request
instead of only its "options". This seems to me to be the best. I'm
afraid this might break xmlrpc fileserving.
I filed ticket #2424 to discuss the possible solutions (Luke I assigned
you the ticket, but I can fix the issue once directed to the correct
solution).