[bind10-dev] #1292 and data source configuration

[JINMEI Tatuya / 神明達哉]

At Wed, 23 Nov 2011 13:07:18 +0100,
Jelte Jansen <jelte at isc.org> wrote:

> > This leads to a more generic topic of how we configure data sources
> > (or data source (client) modules) system-wide.  I guess we'll
> > eventually have some global configuration (i.e., config not specific
> > to a particular process) like TSIG keys, to provide minimum
> > information to create data source clients for a particular type of
> > data source.  That would include a path to the corresponding loadable
> > module:

> side note; We are getting so many 'global' options, should we start
> grouping them?

Do we have many?  Do you specifically mean we now have "global" config
for logging and and TSIG and are now possibly introducing for data
source?

In any case, I've not thought about that and right now don't have a
strong opinion.  Maybe we can have a single top level category (at the
same level as "Auth", "Resolver", etc) such as "System" where
TSIG/logging/data source/etc configs belong.  Or maybe not.

> > "data_sources":
> >   {"module_path": "/usr/local/lib", <=== the default path when unspecified
> >    "sqlite3":
[...]
> > dlopen() would then use the "module_path" information to locate the
> > correct place of the loadable module.
> 
> (as you noted, mostly out of scope for this ticket, but depending on
> this discussion we can make whatever we build now work towards this)
> 
> The code would still need to override the default module_path then if we
> run from source...
> 
> And, if we do that anyway, I wonder how much we need the module path
> setting; but rather have the option to also provide a full absolute path
> to a loadable module instead of a 'short name'; so where we currently
> enter "sqlite3" and the code adds "_ds.so" to the end; we still do:
> - - if not ending with ".so", add "_ds.so" to the end
> - - if absolute, leave as is, and pass directly
> - - if not absolute, prepend module_path.
>
> Should we do that, I am not even sure we need to make module_path a
> settable feature, we'd just install our ones in some
> <prefix>/share/bind10/data_sources (or whatever), and use that
> directory, unless we are running from source (in which case it should be
> builddir/src/ etc)

The example with "module_path" is just for example.  I'm not
necessarily pushing it or don't even necessarily thought that was the
best idea.  I actually don't have a strong preference, but maybe we
should follow common convention (if any).  From a quick look, BIND 9's
dlz just uses an absolute file name.  apache seems to have a hybrid
style:
LoadModule ssl_module libexec/apache22/mod_ssl.so
The complete absolute path is constructed by prepending the value of
ServerRoot to the specified relative path.  (I guess an absolute path
can also be specified for LoadModule).

> I agree that our call to dlopen() should use a full path (as obviously
> different implementations use different algorithms for searching), but
> depending on the resolution of the ticket above, I'm not sure whether
> the middle-term way would need additional (and, more importantly,
> temporary) values used in configuration.

I don't have a strong opinion on the specific solution in the context
of #1292.  As long as it's not too ad hoc and not too generic (and
possibly complicated) for the immediate need, I'm okay with any
solution.

---
JINMEI, Tatuya