problem authenticating, even with emergency user
Hello A Zope site which is running fine, is refusing all authentication with the error below. I have tried the emergency user and restarted Zope, but the emergency user gets the same error: Site Error An error was encountered while publishing this resource. AttributeError Sorry, a site error occurred. Traceback (innermost last): Module ZPublisher.Publish, line 188, in publish_module_standard Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish Module ZPublisher.Publish, line 145, in publish Module Zope2.App.startup, line 222, in zpublisher_exception_hook Module ZPublisher.Publish, line 105, in publish Module ZPublisher.BaseRequest, line 446, in traverse Module ZPublisher.BaseRequest, line 550, in old_validation AttributeError: __getitem__ (Also, the following error occurred while attempting to render the standard error message, please see the event log for full details: getUserById) ____________________________________________________________ Receive Notifications of Incoming Messages Easily monitor multiple email accounts & access them with a click. Visit http://www.inbox.com/notifier and check it out!
On Jan 17, 2008, at 14:39 , Ben Bartrum wrote:
Hello
A Zope site which is running fine, is refusing all authentication with the error below. I have tried the emergency user and restarted Zope, but the emergency user gets the same error:
Site Error An error was encountered while publishing this resource. AttributeError Sorry, a site error occurred. Traceback (innermost last): Module ZPublisher.Publish, line 188, in publish_module_standard Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish Module ZPublisher.Publish, line 145, in publish Module Zope2.App.startup, line 222, in zpublisher_exception_hook Module ZPublisher.Publish, line 105, in publish Module ZPublisher.BaseRequest, line 446, in traverse Module ZPublisher.BaseRequest, line 550, in old_validation AttributeError: __getitem__ (Also, the following error occurred while attempting to render the standard error message, please see the event log for full details: getUserById)
I bet you're running a non-standard user folder, and for some reason the user folder instance is broken. If you can't find why it is broken and the broken user folder is at the root of your Zope instance then fixing it would involve work in the debugger to delete the old one and create a new standard user folder. jens
-----Original Message----- From: jens@dataflake.org Sent: Thu, 17 Jan 2008 15:00:40 +0100 To: zope@zope.org Subject: Re: [Zope] problem authenticating, even with emergency user
On Jan 17, 2008, at 14:39 , Ben Bartrum wrote:
Hello
A Zope site which is running fine, is refusing all authentication with the error below. I have tried the emergency user and restarted Zope, but the emergency user gets the same error:
Site Error An error was encountered while publishing this resource. AttributeError Sorry, a site error occurred. Traceback (innermost last): Module ZPublisher.Publish, line 188, in publish_module_standard Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish Module ZPublisher.Publish, line 145, in publish Module Zope2.App.startup, line 222, in zpublisher_exception_hook Module ZPublisher.Publish, line 105, in publish Module ZPublisher.BaseRequest, line 446, in traverse Module ZPublisher.BaseRequest, line 550, in old_validation AttributeError: __getitem__ (Also, the following error occurred while attempting to render the standard error message, please see the event log for full details: getUserById)
I bet you're running a non-standard user folder, and for some reason the user folder instance is broken. If you can't find why it is broken and the broken user folder is at the root of your Zope instance then fixing it would involve work in the debugger to delete the old one and create a new standard user folder.
jens
Thanks Jens The live server is a Sun server - the Zope installation was copied over from an older Sun server about a month ago, and seemed to run fine unless we try to log in. The root folder of Zope does not have a MySQLUserfolder, but the main subfolder - which hosts the website - has. When authenticating to the website (MySQLUserfolder) I get the traceback. But I can also not authenticate to the ZMI (I get access denied with a known good password and with the emergency user.) But I know I should have access to the ZMI, because I can copy the Data.fs to a test server and login to that. So somehow now authentication is broken for both Zope and MySQL authentication. This led me to think the problem is in the Zope files, and I ran a diff between my test system (Debian) and the live Sun server. Many files differ, but in a way one would expect - the Python path is not the same, so the first line of every .py file is different. Also, *.pyc and *.pyo differ - likely because of the different Python paths. But a number of file names on the Sun server worry me. They miss the last letter - for example __init__.p instead of __init__.py. I worry that the system admins (who I haven't met yet) may somehow have managed to lose the last letters of some file names, although I have no idea how that would be possible. Is it possible that Zope can run sucessfully with these incorrect filenames, and only the authentication is broken? Only in Sunsrv/lib/python/Products/Five/doc/products/InterfaceTutorial: __init__.p Only in Debian/lib/python/Products/Five/doc/products/InterfaceTutorial: __init__.py Only in Sunsrv/lib/python/Products/PageTemplates/tests/input: CheckPathNothing.htm Only in Debian/lib/python/Products/PageTemplates/tests/input: CheckPathNothing.html Only in Sunsrv/lib/python/Products/PageTemplates/tests/input: StringExpression.htm Only in Debian/lib/python/Products/PageTemplates/tests/input: StringExpression.html Only in Sunsrv/lib/python/Products/PluginIndexes/DateIndex/tests: test_DateIndex.p Only in Debian/lib/python/Products/PluginIndexes/DateIndex/tests: test_DateIndex.py Only in Sunsrv/lib/python/Products/PluginIndexes/TextIndex/dtml: addVocabulary.dtm Only in Debian/lib/python/Products/PluginIndexes/TextIndex/dtml: addVocabulary.dtml Only in Sunsrv/lib/python/Products/PythonScripts/tests/tscripts: mutate_literals.p Only in Debian/lib/python/Products/PythonScripts/tests/tscripts: mutate_literals.ps Only in Sunsrv/lib/python/Testing/ZopeTestCase/zopedoctest: testFunctionalDocTest.p Only in Debian/lib/python/Testing/ZopeTestCase/zopedoctest: testFunctionalDocTest.py Only in Sunsrv/lib/python/zope/app/apidoc/codemodule/browser: class_index.p Only in Debian/lib/python/zope/app/apidoc/codemodule/browser: class_index.pt Only in Sunsrv/lib/python/zope/app/apidoc/codemodule/browser: configure.zcm Only in Debian/lib/python/zope/app/apidoc/codemodule/browser: configure.zcml Only in Sunsrv/lib/python/zope/app/apidoc/codemodule/browser: static_menu.p Only in Debian/lib/python/zope/app/apidoc/codemodule/browser: static_menu.pt Only in Sunsrv/lib/python/zope/app/onlinehelp: onlinehelp-configure.zcm Only in Sunsrv/lib/python/zope/app/pagetemplate/ftests: configure.zcm Only in Debian/lib/python/zope/app/pagetemplate/ftests: configure.zcml Only in Sunsrv/lib/python/zope/app/pagetemplate/ftests: test_nested.p Only in Debian/lib/python/zope/app/pagetemplate/ftests: test_nested.py Only in Sunsrv/lib/python/zope/app/pagetemplate/tests: test_binding.p Only in Debian/lib/python/zope/app/pagetemplate/tests: test_binding.py Only in Sunsrv/lib/python/zope/app/pagetemplate/tests: test_viewzpt.p Only in Debian/lib/python/zope/app/pagetemplate/tests: test_viewzpt.py Only in Sunsrv/lib/python/zope/app/preference: preference-configure.zcm Only in Sunsrv/lib/python/zope/app/publisher/browser/tests: testi18nfileresource.p Only in Debian/lib/python/zope/app/publisher/browser/tests: testi18nfileresource.py Only in Sunsrv/lib/python/zope/documenttemplate/tests: dtmltestbase.p Only in Debian/lib/python/zope/documenttemplate/tests: dtmltestbase.py Only in Sunsrv/lib/python/zope/documenttemplate/untrusted: __init__.p Only in Sunsrv/lib/python/zope/pagetemplate/tests/input: checknothing.htm Only in Debian/lib/python/zope/pagetemplate/tests/input: checknothing.html Only in Sunsrv/lib/python/zope/pagetemplate/tests/input: checkpathalt.htm Only in Debian/lib/python/zope/pagetemplate/tests/input: checkpathalt.html Only in Sunsrv/lib/python/zope/pagetemplate/tests/testpackage: __init__.p Only in Sunsrv/lib/python/zope/structuredtext/regressions: examples1.re Only in Debian/lib/python/zope/structuredtext/regressions: examples1.ref Only in Sunsrv/lib/python/zope/structuredtext/regressions: examples1.st Only in Debian/lib/python/zope/structuredtext/regressions: examples1.stx ____________________________________________________________ GET FREE 5GB EMAIL - Check out spam free email with many cool features! Visit http://www.inbox.com/email to find out more!
On Jan 26, 2008, at 00:20 , Ben Bartrum wrote:
The live server is a Sun server - the Zope installation was copied over from an older Sun server about a month ago, and seemed to run fine unless we try to log in.
The root folder of Zope does not have a MySQLUserfolder, but the main subfolder - which hosts the website - has. When authenticating to the website (MySQLUserfolder) I get the traceback. But I can also not authenticate to the ZMI (I get access denied with a known good password and with the emergency user.) But I know I should have access to the ZMI, because I can copy the Data.fs to a test server and login to that. So somehow now authentication is broken for both Zope and MySQL authentication. This led me to think the problem is in the Zope files, and I ran a diff between my test system (Debian) and the live Sun server.
Many files differ, but in a way one would expect - the Python path is not the same, so the first line of every .py file is different. Also, *.pyc and *.pyo differ - likely because of the different Python paths. But a number of file names on the Sun server worry me. They miss the last letter - for example __init__.p instead of __init__.py. I worry that the system admins (who I haven't met yet) may somehow have managed to lose the last letters of some file names, although I have no idea how that would be possible. Is it possible that Zope can run sucessfully with these incorrect filenames, and only the authentication is broken?
One thing that comes to mind is broken tar implementations on Solaris. Don't use their tar implementation, use gnutar instead. jens
Ben Bartrum wrote at 2008-1-25 15:20 -0800:
...
Module ZPublisher.Publish, line 105, in publish Module ZPublisher.BaseRequest, line 446, in traverse Module ZPublisher.BaseRequest, line 550, in old_validation AttributeError: __getitem__ (Also, the following error occurred while attempting to render the standard error message, please see the event log for full details: getUserById)
This looks like a broken "UserFolder" instance (one that cannot be loaded). As a consequence, its "validate" method cannot be found and "old_validation" (usually no longer used in modern Zope versions) is tried. Check your logfile for warnings about not being able to load a class. -- Dieter
-----Original Message----- From: dieter@handshake.de
This looks like a broken "UserFolder" instance (one that cannot be loaded). As a consequence, its "validate" method cannot be found and "old_validation" (usually no longer used in modern Zope versions) is tried.
Check your logfile for warnings about not being able to load a class.
Yes, thanks - you are right. 2008-01-29T16:25:00 ERROR Zope Could not import Products.ZMySQLDA Traceback (most recent call last): File "/www/Zope-2.9.1/lib/python/OFS/Application.py", line 714, in import_product product=__import__(pname, global_dict, global_dict, silly) File "/www/zope/instance2.9.1/Products/ZMySQLDA/__init__.py", line 91, in ? import DA File "/www/zope/instance2.9.1/Products/ZMySQLDA/DA.py", line 92, in ? from db import DB File "/www/zope/instance2.9.1/Products/ZMySQLDA/db.py", line 89, in ? import _mysql ImportError: ld.so.1: python2.4: fatal: libmysqlclient.so.12: open failed: No such file or directory If on the command line I do: python2.4 -c 'import _mysql' I get: ImportError: ld.so.1: python2.4: fatal: libmysqlclient.so.12: open failed: No such file or directory But if I do: setenv LD_LIBRARY_PATH /usr/local/lib/ and then python2.4 -c 'import _mysql' it returns no error. So to get the same effect for Zope, I have tried this in the zope.conf: <environment> LD_LIBRARY_PATH /usr/local/lib/ </environment> Unfortunately, this has no effect. Any ideas?
Ben Bartrum wrote at 2008-1-29 08:51 -0800:
... File "/www/zope/instance2.9.1/Products/ZMySQLDA/db.py", line 89, in ? import _mysql ImportError: ld.so.1: python2.4: fatal: libmysqlclient.so.12: open failed: No such file or directory
If on the command line I do: python2.4 -c 'import _mysql' I get: ImportError: ld.so.1: python2.4: fatal: libmysqlclient.so.12: open failed: No such file or directory
But if I do: setenv LD_LIBRARY_PATH /usr/local/lib/ and then python2.4 -c 'import _mysql' it returns no error.
So to get the same effect for Zope, I have tried this in the zope.conf:
<environment> LD_LIBRARY_PATH /usr/local/lib/ </environment>
Unfortunately, this has no effect. Any ideas?
This is too late. The dynamic loader looks at "LD_LIBRARY_PATH" on startup and then caches the value. Later modification have no effect on the current process. You need to set "LD_LIBRARY_PATH" before you start Zope. -- Dieter
FWIW, it is typically better to install mysql-python with an --rpath, e.g. python setup.py build_ext --rpath=/path/to/mysql/lib python setup.py install This prevents you from ever needing to set LD_LIBRARY_PATH in programs that use the library. You might need to change the mysql-python's site.cfg file too (to be able to find mysql_config). - C Dieter Maurer wrote:
Ben Bartrum wrote at 2008-1-29 08:51 -0800:
... File "/www/zope/instance2.9.1/Products/ZMySQLDA/db.py", line 89, in ? import _mysql ImportError: ld.so.1: python2.4: fatal: libmysqlclient.so.12: open failed: No such file or directory
If on the command line I do: python2.4 -c 'import _mysql' I get: ImportError: ld.so.1: python2.4: fatal: libmysqlclient.so.12: open failed: No such file or directory
But if I do: setenv LD_LIBRARY_PATH /usr/local/lib/ and then python2.4 -c 'import _mysql' it returns no error.
So to get the same effect for Zope, I have tried this in the zope.conf:
<environment> LD_LIBRARY_PATH /usr/local/lib/ </environment>
Unfortunately, this has no effect. Any ideas?
This is too late.
The dynamic loader looks at "LD_LIBRARY_PATH" on startup and then caches the value. Later modification have no effect on the current process.
You need to set "LD_LIBRARY_PATH" before you start Zope.
-----Original Message----- From: dieter@handshake.de Sent: Wed, 30 Jan 2008 19:29:05 +0100
This is too late.
The dynamic loader looks at "LD_LIBRARY_PATH" on startup and then caches the value. Later modification have no effect on the current process.
You need to set "LD_LIBRARY_PATH" before you start Zope.
Thank you Dieter, I think you are right, and I am going to add the LD_LIBRARY_PATH to zopectl
participants (4)
-
Ben Bartrum -
Chris McDonough -
Dieter Maurer -
Jens Vagelpohl