Hi, trying to get LDAP working and have gotten everything installed and at the plugin configuration stage but I'm hitting this error, hoping someone can point be in the right direction please.
Commenting our the test lines in ldap/properties.py shows the LDAP Inspector on the config page which , when opened, correctly binds and shows a list of expected containers.
When clicking one of the listed containers the debug shell outputs the following error :
ERROR Zope.SiteErrorLog 1490765253.00.938157870691 http://192.168.x.x:8080/Plone2/@@plone_ldapnodeattributes
Traceback (innermost last):
Module ZPublisher.Publish, line 138, in publish
Module ZPublisher.mapply, line 77, in mapply
Module ZPublisher.Publish, line 48, in call_object
Module pas.plugins.ldap.plonecontrolpanel.inspector, line 50, in node_attributes
Module node.ext.ldap._node, line 443, in node_by_dn
ValueError: Invalid base DN
Users container DN is ou=Users,ou=OFFICE,dc=businessname,dc=local (making the OU=, DC= capitals causes a Unicode decode error out of interest)
This is likely a PEBKC error, but any hints gratefully accepted.
UnicodeDecodeError errors occur usually when a unicode string and a byte string are combined by a string operation or (more generally) when you use a byte string at a place where a unicode string is expected. In those cases, the byte string is decoded with the so called "default encoding" to get the corresponding unicode string -- and you get a UnicodeDecodeError when this fails.
Capitalizing the "ou" does not introduce a problem for the "default encoding". This means that the real problem is somewhere else.
One possibility would be that the lower case "ou" has caused an error before the UnicodeDecodeError was reached (maybe, the bad base_dn).
Anyway, somewhere, you have a byte string used at a place where a unicode string is required and it contains characters not handled by the employed encoding (maybe, the "default encoding").
Thanks Dieter, I set the system local to en_US (previously en_NZ) and this has removed that unicode error, but unfortunately the primary DN error still exists.
As a test I spun up a Ubuntu 14.04 VM and installed there with the same resulting error.
I also note that the other active LDAP issue reported by @cfa on this forum is now hitting the same error.
That error has caused a ValueError. In the corresponding traceback, you will find which function has raised the exception. Look at its source code.
The error has either initiated in the LDAP server (less likely) or in the client. In the latter case, you should be able to determine from the source code, what precisely it does not like about the DN -- and modify the configuration accordingly. In the former case, the LDAP server logs may provide additional information about what it did not like.