[Pdns-dev] Extending the LDAP Backend

[adrian at inomial.com]

Hi Norbert,

Thanks for replying!
> Hi Adrian
>
>> I'm looking at extending the LDAP backend to allow a more flexible
>> schema for storing domain information.  Instead of having the user
>> locked into the dnsDomain2/domainRelatedObject schema, I'd like to be
> able to have a set of options in the configuration file like:
>
> I like the idea of giving the user the possibility to use something 
> different than the "dc" attribute for LDAP DNs. This could be useful 
> for some installations out there.

Well, my thinking on it was that, in LDAP, the dc attribute has a very 
specific purpose.  It's there to define the root of the LDAP tree, and 
nothing more than that (at least, as far as I'm concerned).  Plus, part 
of my job involves managing our LDAP database which has been very 
carefully designed to be a completely normalised Thing Of Beauty.  I 
like to use the right attribute for the right job, and I just don't 
feel that dc is the right attribute for this job.

> Why do you want to use custom attributes for certain record types? Do 
> you want to switch from an existing LDAP/DNS installation using a 
> different schema to PowerDNS? If yes, which one?

No, the closest I'm coming to migrating from another DNS server is when 
I eventually migrate our bind9 zones into PowerDNS.  That's a little 
bit down the track, though.  The reason I want to be able to use custom 
attributes -- and it's not just some attributes but all of them -- is 
because I'd like to hand control of the schema back to the user.  
Complete control, eventually.  Not quite on the scale of adding another 
lookup method besides tree (which makes the most sense to me *anyway*) 
but being able to tell PowerDNS that we want it to find, for example, 
it's A records in some other attribute.  It's all about giving options 
and control back to the user.  The user, in this case, being me!  But 
if this works, I'd like to submit patches to integrate this into the 
project.

>> One thing I am wondering about, though, is this: are default values
>> supported in the config file?  Can I leave an option out and just have
>> a default put in its place at run-time?  This would be, to me,
>> essential.  You might want to change the domain component attribute to
>> something other dc, but leave the rest of the attributes with their
>> default values by not putting any entries for them in the config
>
> You have to define the acceptable configuration values and can assign 
> default values to them. Please have a look at the bottom of the 
> ldapbackend.cc file.

Aha!  Found it.  Thanks.

I'm probably going to need to ask a bunch more questions, because 
although my initial alterations compile, and I've added a whole lot 
more Logger::Warning lines to try and see what's happening, the logs 
are telling me that the LDAP backend is getting the SOA request for 
example.com (which I've set up in my database) but the list_simple 
method isn't being queries to try and find the SOA record.  Or, if it 
is, the five or so lines I have to log each part of the process are not 
logging, and it's then completely failing to find the SOA record.  I'll 
keep bashing away at it to see what I can find, though.

> Norbert
> -- 
> OpenPGP public key
> http://www.linuxnetworks.de/norbert.pubkey.asc

Regards,

Adrian