Problem with Zentyal LDAP and Schooltool (on other server) [SOLVED]

[astana]

Thanks for your feedback both of you.

Christian is right, the aim was to have SchoolTool on a separate server, not installed on a Zentyal one. Although if I have to go down that route then I'll look into using Apache as the server.

Christian: The error messages I was getting was from the SchoolTool server config, 5 pages of error log with "Value must be a string, cannot be NULL" (paraphrased as I don't have access the the VM to verify exactly).

I'm trying to get a setup with a bunch of VM's running single applications (SchoolTool, HelpDesk, Forums etc) which I can then spread out over a LAN Clould for HA. I would take a few more resources to use Zentyal BDC for any service that needs LDAP, but acceptable. The point that is uncomfortable is it should work from an external box.

[christian]

Indeed, it should work from "external" server but I didn't succeed.
Configuring LDAP works. Access to LDAP works too but LDAP based authentication doesn't work and I don't know why. You should ask Schooltool forum once you reach this stage.

Notice that I was not using VM 

I'm too old now to think that introducing such technology in the middle of the test bed is as transparent as replacing green twisted ethernet cable with a blue one 

VM is very convenient in production once you know that what you're going to deploy does work already. You can focus on potential VM related problem.
VM is also very convenient for testing purpose (I'm happily using Proxmox f.i.) but at least you have to describe it from the begining because it can have an impact. We are discussing your problem now since quite a while and, unless I'm wring, I discover now that you deploy on VM 

Anyway... one last comment, nothing to do with SchoolTool but general or philosophical comment about fashion in IT:
Microsoft Windows is not a very bad operating system, not unstable neither having poor performance. The main drawback with Windows is the shared DLL concept that is introducing a lot of potential conflicts between applications thus instability and BSOD.
Because of this, good practice, long time ago, has been, for IT people, to deploy a much as possible, one and only one application per Windows server.
This permitted to reach high degree of stability and reliability even running Windows in prod but this was also very inefficient for hardware use standpoint.
When VM concept has been invented, it brought a lot because it permitted to deploy many Windows servers, one per application, on one single hardware.

So far so good 

but when I see same reasoning about slicing when it comes to deploy web based applications, I'm wondering whenever it makes sense  especially when  all applications are running on Linux system not suffering from the same "shared DLLs" issue 
Yes, sure, VM bring other potential advantages like easy snapshot and move to different hardware but this is reached only once everything else work with, furthermore, extra level of complexity.

I'm explaining this just to convince you guys, when you're testing some new application, to quickly switch to the old way of working in case you face too many problems and do not understand whenever this could be VM related or not   

[astana]

Sorry for the delay getting the error messages back. I was getting this:

Code: [Select]

An internal server error has occurred. This most likely means that you have found a bug in SchoolTool. Please report it on the issue tracker.
Exception

TypeError: must be string or read-only buffer, not None
 

Traceback

File "/usr/lib/python2.7/dist-packages/zope/publisher/publish.py", line 132, in publish
  result = publication.callObject(request, obj)
File "/usr/lib/python2.7/dist-packages/zope/app/publication/zopepublication.py", line 207, in callObject
  return mapply(ob, request.getPositionalArguments(), request)
File "/usr/lib/python2.7/dist-packages/zope/publisher/publish.py", line 107, in mapply
  return debug_call(obj, args)
Extra information: <schooltool.skin.flourish.zcml_content.LoginView_login.html object at 0xdb667ec>
File "/usr/lib/python2.7/dist-packages/zope/publisher/publish.py", line 113, in debug_call
  return obj(*args)
File "/usr/lib/python2.7/dist-packages/schooltool/app/browser/app.py", line 657, in __call__
  self.update()
File "/usr/lib/python2.7/dist-packages/schooltool/app/browser/app.py", line 666, in update
  self.request['password'])
File "/usr/lib/python2.7/dist-packages/schooltool/app/security.py", line 252, in setCredentials
  self.authPlugin.setCredentials(request, username, password)
File "/usr/lib/python2.7/dist-packages/schooltool/ldap/security.py", line 327, in setCredentials
  if not self.checkPlainTextPassword(username, password):
File "/usr/lib/python2.7/dist-packages/schooltool/ldap/security.py", line 287, in checkPlainTextPassword
  return client.login(username, password)
File "/usr/lib/python2.7/dist-packages/schooltool/ldap/security.py", line 243, in login
  for user in self.find(username):
File "/usr/lib/python2.7/dist-packages/schooltool/ldap/security.py", line 238, in find
  users = self.search(base, scope, filter=filter)
File "/usr/lib/python2.7/dist-packages/schooltool/ldap/security.py", line 149, in search
  self.connect()
File "/usr/lib/python2.7/dist-packages/schooltool/ldap/security.py", line 135, in connect
  new_connection.bind_s(who=dn, cred=password)
File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 221, in bind_s
  msgid = self.bind(who,cred,method)
File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 215, in bind
  return self.simple_bind(who,cred)
File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 200, in simple_bind
  return self._ldap_call(self._l.simple_bind,who,cred,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls))
File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 98, in _ldap_call
  result = func(*args,**kwargs)
 
But I thought it was linked to the web configuration, so delete the school tool database and removed school tool. On re-installing SchoolTool I now have exactly what you've been getting Christian, it can see 173 users, but I can't login.

I'll investigate some logs and let you know if I get any further.

[astana]

I've got it working 

The only differences between the configs are as follows:

Code: [Select]

default_login_attr uid
query_users uid ou=Users,dc=xxx,dc=xxx?one

I'm not sure which one if the 2 changes were responsible for making it work but if I've time later to investigate further I'll repost.

Just as a note for further reference:
SchoolTool is installed in a standard ubuntu server running in a virtual machine. There are no zentyal components installed on this server.
python-schooltool.ldap was installed, and I used the config that Christian posted on page 1 with the above modifications.
Now I can log in using any domain login.
 

[astana]

I would like to mark this topic [Solved] but don't appear to be able to!

[christian]

1 - in order to stamp this topic as [SOLVED], just edit your own very first post title.

2 - I can't see what's different between what you did and what I did (and reported in previous post) except that you have removed in the LDAP query, which means you're selecting all entries matching (objectclass=*). Odd isn't it because whatever the LDAP filter, what was strange enough is that schooltool application was never searching LDAP while I tried to authenticate using LDAP account although allLDAP entries were shown as found.

Anyway, if it work, that's a good news 

[astana]

There were 2 changes!

1:
Making sure default_login_attr uid wasn't commented out.
2:
Removing restriction on search as you noted.

I wish I had more time to really proof debug which one made it work, but I'm always being called to solve a problem somewhere else.

Thanks so much for your help on this post and others Christian!

[christian]

Be sure that I did try indeed to activate the default login directive. BTW, I even kept is bu default enabled despite what my conf is reflecting here. Never go any chance to have LDAP request while authenticating.
So I suppose this is most likely changes you made on LDAP filter, although this one is odd too: I did set this filter with (objectclass=*) too without any success.

Doesn't matter. What does matter is that is works now