I was looking through back-passwd search.c and I've a few oddities. 1) Bad DN The DN returned appears to be: "pw_name@SUFFIX" Instead of something like: uid=pw_name, SUFFIX 2) uid attribute is not part of objectclass 'person' 3) gecos field processing is incomplete. Here are a few suggestions for anyone interested in updating this code. 1) change objectclass to 'account', return both 'account' and 'person', return to 'posixAccount', or make it an option. 2) modify dn to be: attribute=pw_name, SUFFIX (hardcode the attribute to 'uid' or make it an option) 3) Construct full name from gecos, add as "cn" and "description" 4) Add full gecos field as "description" 5) extract 'telephone' and other info from gecos field (if person) 6) populate 'host' (w/ hostname) 7) populate 'l'ocality with domainname This would be a good project for someone wanting to get their feet wet in slapd code. NOTE: I consider this backend to be used solely for 'demonstration purposes.' It would need a lot more work to useful (such as actually supporting 'bind'). Kurt
moved from Incoming to Software
changed notes changed state Open to Suspended
moved from Software to Software Enhancements
changed notes changed state Suspended to Open
I have uploaded a patch against the devel source in ftp://ftp.openldap.org/incoming/hyc-990428.patch Addressing the problems in the original message: 1) The DN returned is of the form cn=pw_name, SUFFIX. 2) The uid attribute is gone. 3) The GECOS field is parsed for cn and sn fields. The BSD usage of '&' in the GECOS field is recognized. The cn is terminated at the first ',' in the GECOS. The sn is only shown if there is a space in the cn, in which case the tail of the cn is used as the sn. For the suggested changes: 1) I left the objectclass as person. Perhaps posixAccount would be more appropriate, but again, this is only a demo backend. 2) The DN is hardcoded to use cn= 3&4) The full name is processed, the description attribute contains the raw contents of the GECOS field. 5) There isn't enough agreement on usage of the rest of the GECOS field to warrant this. 6) didn't do it. 7) didn't do it. Some other fixes: I added an entry for the base of the backend itself, which is just an organizationalUnit. Also, I added a check to prevent searches within this backend from nesting endlessly. (E.g., in the original code, given the backend at ou=passwd; a onelevel or subtree search based at cn=root,ou=passwd would return the same results as a onelevel or subtree search based at ou=passwd. And so on and so on...)
I've committed a set of changes based upon your patches. The scope handling needed some minor improvement. I also modified the codes to use dn_*() and rdn_attr_*() routines and fix a couple of minor bugs. >Addressing the problems in the original message: >1) The DN returned is of the form cn=pw_name, SUFFIX. I left DN uid=pw_name. The rdn attribute type could be configuration item. >2) The uid attribute is gone. Added it back in. Also assigned cn=pw_name and sn=pw_name because cn,sn are both required attributes of person. >3) The GECOS field is parsed for cn and sn fields. The BSD usage of '&' >in the GECOS field is recognized. The cn is terminated at the >first ',' in the GECOS. The sn is only shown if there is a space in the cn, >in which case the tail of the cn is used as the sn. Left this alone. >For the suggested changes: >1) I left the objectclass as person. Perhaps posixAccount would be more >appropriate person is painful as it requires cn & sn attributes. objectclass(es) could be a configuration item. > this is only a demo backend. That's very true. It also serves as a "get your feet wet" backend for would-be slapd hackers. >2) The DN is hardcoded to use cn= See above. >3&4) The full name is processed, the description attribute contains the raw >contents of the GECOS field. Looks good. >5) There isn't enough agreement on usage of the rest of the GECOS field to >warrant this. Agreed. >6) didn't do it. >7) didn't do it. > >Some other fixes: I added an entry for the base of the backend itself, which >is just an organizationalUnit. Also, I added a check to prevent searches >within this backend from nesting endlessly. (E.g., in the original code, >given the backend at ou=passwd; a onelevel or subtree search based at >cn=root,ou=passwd would return the same results as a onelevel or subtree >search based at ou=passwd. And so on and so on...) I modified the code such that a one/sub search at the suffix would return the suffix entry and passwd entries (if they passed the filter). I also added some additional error handling. Also, as base and suffix are normalized (uppercase) DNs, I tolowerred the username during a 'base' search for an entry. And I added 'make passwd' in ldap/tests. For now, it just does a few searches using the local password file. See test-db/ldapsearch.out for results. Test inputs (data/passwd) and outputs (data/passwd.out) need to be written. - Kurt
changed notes changed state Suspended to Closed
Needs volunteer no takers.