[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Choosing OID for overlay config
Pierangelo Masarati wrote:
>> 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.
>
> RWM was designed that way because it was intended for remapping
> namingContexts and schema, as a DS should only muck with how stuff is
> presented, and not with contents.
Yes, of course.
> However, I see that in many cases
> having the possibility to muck with contents would be of great help. Of
> course, core code shouldn't allow that, but custom modules seem to be a
> good place to provide that functionality. So, I think sort of an rwm
> companion that mucks with values would be greatly appreciated.
Great. Docs first of course, but thanks for the encouragement.
This is just a great for me to make sense of what I see in the code
everyday ;-)
>
>> 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.
>
> I think this was already discussed. I think a big issue about that is
> that with complex filters (even with simple, if part of the values is
> local and part remote) need local + remote data knowledge at candidate
> selection. As a consequence, there's no (simple) way search candidates
> can be selected if part of the filter relies on local data. I don't see
> this an easy task from a theoretical point of view, not just in terms of
> implementation. For example, this is basically what prevents back-meta
> from building entries by joining partial entries residing on different
> remote servers.
>
Ha! A bit ambitious of me then I think. I should have realised if it was
simple enough, it would have been done.
Thanks for your comments,
Gavin.
--
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghenry@suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/