When redeploying ,especailly after a new kinit, the webui fails to initialize. In the ipa init batch message I see the following error message:
"count": 5, "results": [ { "error": "'NoneType' object has no attribute 'attribute_types'" }, { "error": null, "messages": { "ajax": { "401": "Your Kerberos ticket is no longer valid. Please run kinit and then click 'Retry'. If this is your first time running the IPA Web UI <a href='/ipa/config/unauthorized.html'>follow these directions</a> to configure your browser." },
Once the kinit has been performed, we need to re-exec the ipa_init batch call.
Note that this is a problem if the ticket times out, but not if there is no ticket sent.
Problem seems to be that the Kerberos/Negotiate doesn't fail, but instead the RPC reports an error. This seems to be a problem with the JSON RPC, or mod_auth_krb
Need way more information on what you did to get to this point, starting with the definition of "redeploying".
What is a ticket timeout, do you mean expired?
Not sure exactly what is causing it. I do know that I often see it when I a ticket, possibly from a previous install, and I restart the app. It looks like the Kerberos layer is letting the request through, but the internal commands in the batch are failing, perhapos due to not having the Kerberos principal.
It is possible that the user has a (new) valid ticket, but the old (invalid) ticket is still cached and passed around in the wsgi layer. That would imply that the cause is re-running kinit.
jgalipea: happens after every new kinit ... most notably after fresh install .. Namita and I both seeing it too
More reproduction details please.
OK, just reproduced. Here is what I did:
Was working last night on a server. Came back this morning and opened the browser, pointed it at the webUI. I got the "Kerberos ticket is no longer valid" message, so I ran kinit, and then clicked the OK button. The batch request then proceeded, but with the errors shown above.
Reproduced it another way: rebuilt and installed the RPMS, then ran service ipa restart. The user still had a kerberos ticket from previous work.
Replying to [comment:4 admiyo]:
The problem of getting a ticket then re-installing IPA and trying the UI again is the UI assumes that all 401 errors from the server mean that the ticket is expired. This is not correct.
I've been unable to simulate this. It should be possible to create a soon-expiring ticket with: kinit -l -s 10s admin
Using that I can see the expired message. kinit again and it works as expected.
Here's the stack trace, from the lite server
ipa: ERROR: non-public: AttributeError: 'NoneType' object has no attribute 'attribute_types' Traceback (most recent call last): File "/home/ayoung/devel/freeipa/ipaserver/rpcserver.py", line 220, in wsgi_execute result = self.Command[name](*args, **options) File "/home/ayoung/devel/freeipa/ipalib/frontend.py", line 421, in __call__ ret = self.run(*args, **options) File "/home/ayoung/devel/freeipa/ipalib/frontend.py", line 727, in run return self.execute(*args, **options) File "/home/ayoung/devel/freeipa/ipalib/plugins/internal.py", line 66, in execute (o.name, json_serialize(o)) for o in self.api.Object() File "/home/ayoung/devel/freeipa/ipalib/plugins/internal.py", line 66, in <genexpr> (o.name, json_serialize(o)) for o in self.api.Object() File "/home/ayoung/devel/freeipa/ipalib/util.py", line 48, in json_serialize return json_serialize(obj.__json__()) File "/home/ayoung/devel/freeipa/ipalib/plugins/baseldap.py", line 397, in __json__ attrs = self.api.Backend.ldap2.schema.attribute_types(objectclasses) AttributeError: 'NoneType' object has no attribute 'attribute_types'
To reproduce with lite-server.py:
- kinit admin - python lite-server.py - kinit -l 1s lite-server.py - curl -v -H "Content-Type:application/json" -H "Accept:applicaton/json" --cacert /etc/ipa/ca.crt -d '{"method":"json_metadata","params":[[],{}]}' -X POST http://localhost:8888/ipa/json - Fails with Ticket Expired - kinit admin - curl -v -H "Content-Type:application/json" -H "Accept:applicaton/json" --cacert /etc/ipa/ca.crt -d '{"method":"json_metadata","params":[[],{}]}' -X POST http://localhost:8888/ipa/json - Fails with backtrace
attachment freeipa-rcrit-807-schema.patch
master: 1aee9df
ipa-2-0: fd56476
Metadata Update from @admiyo: - Issue assigned to rcritten - Issue set to the milestone: FreeIPA 2.1 - 2011/06
Login to comment on this ticket.