LDAP2010/2010-06-13.
This week, my work was prevented by the recruitment office, in spite of the fact that I am a student, and besides, already have military ID, them tried to recruit me :-). Somehow I ended up in their lists of recruits, and the university for some reason did not send them a confirmation that I'm learning, and I have brought the matter of evasion of military duty. Tuesday I went to Chelyabinsk, in the regional recruitment office, from where I was sent to a medical examination, but I got rid of a repetition of medical commission (I have asthma, I have already passed their examination, after which I was given a military ID). Thus, from Tuesday to Friday, I almost did not work.
On Monday, I faced with the problem in my openldap configuration, a two slapd instances behind a slapd-ldap backend. When sending a filter like (|(cn=*)(mail=*\ff\ff*)) system does not give results. This is due to the fact that under the scheme attribute mail may contain only ascii. In a typical installation this problem does not arise - the invalid part of the filter is treated as Undefined, and slapd gives the desired result. But slapd-ldap (which forwards requests to the two real slapd instance) can not generate invalid request, and on this I get a blank result.
Also, when I tried to generate a large amount of users i faced with a problem with a unicode. I want to use LDIFWriter with StringIO, but i I try it raises "TypeError: can't write str to text stream" because of StringIO expect unicode, and LDIFWriter sends an str. I solved it with a simple hack:
class StrIO(io.StringIO): "A little hack to make StringIO usable with LDIFWriter." def write(self, a): return io.StringIO.write(self, unicode(a))
So, it is usable now, but I spent a half of saturday on it... Now I stucked with "TypeError: ('expected a string in the list', u'organizationalUnit')" when I trying to add generated LDIF into LDAP... Looks like it somehow violating the LDIF format, but I can not yet understand what the problem... There is a head of LDIF - http://paste.pocoo.org/show/224976/, it fails on User0...
Also, I searched again for a Kerberos libraries, I think that we should use python-kerberos used in debian (it is also used in the calendarserver.org project).
Also, I looked again at the implementation of other group backends. What do you think I need to complete the tests for LDAPGroups and switch to Kerberos? Or it may be better to refine (though rather rewrite) LDAPGroups, that they support nested groups and try to make use of GroupsBackendTest from MoinMoin.datastruct.backends._tests?