Hallvard B Furuseth wrote:
Gavin Henry writes:
What's the best practice for choosing the numbers in OLcfgOvAt:14.1 Above is taken from translucent.c
Not sure what you mean. OLcfgOvAt:14.1 is an attribute type defined in translucent.c, you shouldn't take OIDs below it.
If you want to add another config attribute to translucent, grab OLcfgOvAt:14.3 - the first free OLcfgOvAt:14.* OID in translucent.c. If you want an OID arc for another overlay/backend in OpenLDAP, add a new OID arc in the OID registry in bconfig.c.
I notice:
* (FIXME: separate arc for contribware?)
This is where mine would fit in if it existed, but I see smbk5pwd sneaked in there.
When I'm not doing doc project work (and Suretec work), I'm hacking on valsort.c for learning, and making valregex.c from it.
This uses PCRE to apply regex to attribute values and apply your captures to a configured string etc., then return that in a search response.
Kind of like a sed on attribute values. For things like:
"/home/users/(.*)" and returning "/home/$1" etc.
valregex-attr homeDirectory ou=Users,dc=example,dc=com /home/user/(.*) /home/$1
I thought a new overlay for this, rather than trying to get my head round rwm would be better. As rwm only does attribute name stuff, not values.
Then next on my list is to add a local db search to translucent.c so you can search for attributes not just on the remote db.
This will all help for our docs (I'll know more internals), and I can help with the devel docs (creating more).
That's just another plan for the future.
Gavin.