Hi everyone,
I've been developing an overlay and I got to a well working solution. But,I would really appreciate your opinions about it before sending it to the contribs. You can see my source on my site: http://www.dataworld.be/johan/openldap/parsearch/parsearch.htm
Since I'm a student and I needed to this for my stage, I'will have to write a rapport on how to write an overlay for OverLDAP, I'll be glad to share it as a tutorial for the next overlay developers.
Thanks allot!
Johan Jakus
Johan Jakus writes:
I've been developing an overlay and I got to a well working solution. But,I would really appreciate your opinions about it before sending it to the contribs. You can see my source on my site: http://www.dataworld.be/johan/openldap/parsearch/parsearch.htm
Some notes after a quick scan:
- Try to stay below 80-char line length. OpenLDAP mostly uses tab-width 4 and indentation 4, though it's gotten intermixed quite a bit of code written with tab-width 8 code over the years.
- Also OpenLDAP code triest to stay C90-compatible, so no '//' comments or declarations after executable statements.
- LDAP_DEBUG_ANY is for log messages which should always be output, so parsearch would be very chatty in the log. Use LDAP_DEBUG_TRACE for most of these messages. Sometimes LDAP_DEBUG_ARGS/ACL. See include/ldap_log.h.
- parsearch_response() should inspect rs->sr_type see what kind of kind of response this is - search entry, intermediate response etc. See e.g. valsort_response. It can look at op->o_tag to see what kind of request is being processed. Note that 'rs->sr_un.sru_search.r_entry != NULL' will be true for an intermediate response, because sr_un is a union and sru_extended.r_rspoid has been set.
Unfortunately the SlapReply flags are not always reliable. We've cleaned up a lot lately.
There are a bunch of macros like sr_entry = sr_un.sru_search.r_entry in slapd.conf, so these expresions can be written more briefly.
- This is wrong: Entry* dupEntry = entry_dup(rs->sr_un.sru_search.r_entry); rs->sr_un.sru_search.r_entry = dupEntry; rs->sr_flags = REP_ENTRY_MUSTFLUSH; You are not obeying the flags and flushing the old entry. You are resetting non-entry-related flags. And MUSTFLUSH = MUSTBEFREED | MUSTRELEASE, you want MUSTFREE since you have no release function.
Just use slap_overinst *on = (slap_overinst *) op->o_bd->bd_info; Entry *e; rs_entry2modifiable( op, rs, on ); e = rs->sr_entry; /* this is now modifiable */
Hallvard B Furuseth wrote:
Just use slap_overinst *on = (slap_overinst *) op->o_bd->bd_info; Entry *e; rs_entry2modifiable( op, rs, on ); e = rs->sr_entry; /* this is now modifiable */
Thanks allot for your opinions Hallvard,
I'm working on applying them! Since, I was working on the previous version of OpenLDAP (2.4.23). I needed to update to be able to use the "rs_entry2modifiable()" function. And, in the new version, I can no longer use : AttributeName* attName = op->oq_search.rs_attrs; int iAtt; for( iAtt=0; attName[iAtt].an_name.bv_val != NULL; iAtt++ ) { if ( attName[iAtt].an_name.bv_val[0] == dupPp->pp_symbol[0] ) ...
Because when there is a symbol ( _, §, £, ...) before the attribute, the 'attName[iAtt].an_name.bv_val' gives "1.1" instead of "_*attributename*" And I need to recover at least the attribute name to make my overlay work. Any ideas? Thanks!
Johan Jakus
Johan Jakus writes:
And, in the new version, I can no longer use : AttributeName* attName = op->oq_search.rs_attrs; int iAtt; for( iAtt=0; attName[iAtt].an_name.bv_val != NULL; iAtt++ ) { if ( attName[iAtt].an_name.bv_val[0] == dupPp->pp_symbol[0] ) ...
Because when there is a symbol ( _, §, £, ...) before the attribute,
I don't understand what you mean with "( _, §, £, ...)", but:
the 'attName[iAtt].an_name.bv_val' gives "1.1" instead of "_*attributename*"
Are you sure there is a problem? It's standard for clients to ask for attribute "1.1" when they want no attributes returned: Asking for any attribute suppresses the default behavior of returning all user attrs. And there should be no attribute with OID "1.1". So when slapd looks it up, that'll fail and be treated as any other unrecognized attribute.
And I need to recover at least the attribute name to make my overlay work. Any ideas? Thanks!
Thanks for you answer!
Hallvard B Furuseth wrote:
I don't understand what you mean with "( _, §, £, ...)", but:
To set what attributes needs to be looked up by the overlay I simply use a symbol before them, and I leave the possibility for the users to chose what symbol they want to use (default being "_" ).
Are you sure there is a problem? It's standard for clients to ask for
attribute "1.1" when they want no attributes returned: Asking for any
attribute suppresses the default behavior of returning all user attrs. And there should be no attribute with OID "1.1". So when slapd looks it up, that'll fail and be treated as any other unrecognized attribute.
For my tests I simply use the ldapsearch, no passing by a client program. Example: ldapsearch -x -b "dc=test,dc=com" "(sn=*)" street -> this gives "street" in attName[iAtt].an_name.bv_val ldapsearch -x -b "dc=test,dc=com" "(sn=*)" _street -> this gives "1.1" in attName[iAtt].an_name.bv_val In the 2.4.23 version of OpenLDAP this worked well. I found "_street" in the an_name. I would then remove the _ before the attribute name so it would be send as a valid attribute to the server.
Johan Jakus
I solved my problem by using a string before the attribute. Instead of a "_" I now use "ops-".
For the debugs, I made my overlay very chatty because for my project I needed to show the overlay worked. And It was easier to have everything in the same debug file. Those debugs aren't essential, but they can be useful to see how everything works. I could simply add a parameter to the slapd.conf file to enable debug or not for my overlay. Would this solution be good for you?
Johan
Johan Jakus writes:
Hallvard B Furuseth wrote:
I don't understand what you mean with "( _, §, £, ...)", but:
To set what attributes needs to be looked up by the overlay I simply use a symbol before them, and I leave the possibility for the users to chose what symbol they want to use (default being "_" ).
Duh.. I should have looked at some of the comments in the program. Looks like you've been hit by a tweak to schema checking introduced in ITS#6819. Valid attribute names start with a letter, followed by alphanumerics and hyphens. Or attrs are spelled as OIDs: Integers separated by dots.
You could put a prefix like "parsearch-" instead. Don't know if that'll work, and if it'll keep working. Reading ITS#6819, the question of what to do with unknown attribute descriptions seems a bit unsettled.
Or use an attribute option. E.g. for "cn" you'd request "cn;parsearch". See RFC 4512 section 2.5.2.*. Put "attributeoptions parsearch" in slapd.conf, or "attributeoptions parsearch lang-" to keep the default supported option range "lang-" if you have use for language options. Or call ad_define_option("parsearch", <config filename>, <config line>).
Neither variant is quite correct with respect to inheritance, but at least they have valid syntax and attribute options are standard.
For my tests I simply use the ldapsearch, no passing by a client program.
Nitpick: Then ldapsearch is the LDAP client you are using. Anyway,
openldap-technical@openldap.org
-
Hallvard B Furuseth -
Johan Jakus