I am seeing this problem with SchoolTool. Without python-schooltool.ldap installed, SchoolTool starts correctly, but as soon as it is installed it refuses to start. The following was found in /var/log/schooltool/paste.log:
Reading configuration from /etc/schooltool/standard/schooltool.conf
Traceback (most recent call last):
File "/usr/bin/start-schooltool-instance", line 9, in <module>
load_entry_point('schooltool==2.6.0.1', 'console_scripts', 'start-schooltool-instance')()
File "/usr/lib/python2.7/dist-packages/schooltool/paste/run.py", line 132, in main
paste.script.command.run(['serve', conf_file] + extra_options)
File "/usr/lib/python2.7/dist-packages/paste/script/command.py", line 104, in run
invoke(command, command_name, options, args[1:])
File "/usr/lib/python2.7/dist-packages/paste/script/command.py", line 143, in invoke
exit_code = runner.run(args)
File "/usr/lib/python2.7/dist-packages/paste/script/command.py", line 238, in run
result = self.command()
File "/usr/lib/python2.7/dist-packages/paste/script/serve.py", line 284, in command
relative_to=base, global_conf=vars)
File "/usr/lib/python2.7/dist-packages/paste/script/serve.py", line 321, in loadapp
**kw)
File "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 247, in loadapp
return loadobj(APP, uri, name=name, **kw)
File "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 272, in loadobj
return context.create()
File "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 710, in create
return self.object_type.invoke(self)
File "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 144, in invoke
**context.local_conf)
File "/usr/lib/python2.7/dist-packages/paste/deploy/util.py", line 56, in fix_call
val = callable(*args, **kw)
File "/usr/lib/python2.7/dist-packages/paste/urlmap.py", line 25, in urlmap_factory
app = loader.get_app(app_name, global_conf=global_conf)
File "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 350, in get_app
name=name, global_conf=global_conf).create()
File "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 710, in create
return self.object_type.invoke(self)
File "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 146, in invoke
return fix_call(context.object, context.global_conf, **context.local_conf)
File "/usr/lib/python2.7/dist-packages/paste/deploy/util.py", line 56, in fix_call
val = callable(*args, **kw)
File "/usr/lib/python2.7/dist-packages/schooltool/paste/main.py", line 45, in schooltool_app_factory
os.path.join(global_conf['here'], config_file))
File "/usr/lib/python2.7/dist-packages/schooltool/paste/main.py", line 34, in __init__
db = self.setup(options)
File "/usr/lib/python2.7/dist-packages/schooltool/app/main.py", line 666, in setup
self.configure(options)
File "/usr/lib/python2.7/dist-packages/schooltool/app/main.py", line 501, in configure
site_zcml=options.config.site_definition)
File "/usr/lib/python2.7/dist-packages/schooltool/app/main.py", line 446, in configureComponents
handler(options, context)
File "/usr/lib/python2.7/dist-packages/schooltool/ldap/config.py", line 288, in handle_configuration
fallback_login_filter=FALLBACK_LOGIN_FILTER)
File "/usr/lib/python2.7/dist-packages/schooltool/ldap/config.py", line 163, in parse
self.after_parse(config_file, cache)
File "/usr/lib/python2.7/dist-packages/schooltool/ldap/config.py", line 169, in after_parse
self.set_fallback_query(cache)
File "/usr/lib/python2.7/dist-packages/schooltool/ldap/config.py", line 200, in set_fallback_query
cleanup_ldap_filter(cache['fallback_filter'])
KeyError: 'fallback_filter'
I am running Ubuntu 12.04 LTS with the SchoolTool PPA, as the official guide says.
(I am the poster in the related question who triggered this bug report)
I have discovered the source of the problem. The default /etc/ldap.conf that exists in Ubuntu is an example file, containing incorrect configuration settings. With this file in place SchoolTool would die with the error quoted above. However, removing the file allowed SchoolTool to start normally.
If an invalid /etc/ldap.conf does exist, surely the desired behaviour would be to ignore it and require manual setting by the administrator? A full crash with poor error reporting is not very intuitive.