[bind10-dev] #1292 and data source configuration

JINMEI Tatuya / 神明達哉 jinmei at isc.org
Wed Nov 23 08:38:29 UTC 2011


Jelte,

As it didn't seem to be clear to you, I'll explain more specific about
the remaining issue of #1292.

BSD variants (and MacOS X) somehow cannot find data source loadable
module (in our case, it's specifically sqlite3_ds.so) by dlopen()
called from isc.datasrc.datasrc.so in *install environments*.  
To work this around we add a special quick hack in the boss program:

    def __ld_path_hack(self):
        env = dict(self.c_channel_env)
        if ADD_LIBEXEC_PATH:
            cur_path = os.getenv('DYLD_LIBRARY_PATH')
            cur_path = '' if cur_path is None else ':' + cur_path
            env['DYLD_LIBRARY_PATH'] = "/usr/home/jinmei/opt/lib" + cur_path

            cur_path = os.getenv('LD_LIBRARY_PATH')
            cur_path = '' if cur_path is None else ':' + cur_path
            env['LD_LIBRARY_PATH'] = "/usr/home/jinmei/opt/lib" + cur_path
        return env

Without this, for example, the installed version of b10-xfrin would
fail to perform zone transfer with the following log message:

2011-11-13 01:01:33.082 ERROR [b10-xfrin.xfrin] XFRIN_XFR_PROCESS_FAILURE AXFR transfer of zone kame.net./IN failed: Failed to create DataSourceClient of type sqlite3:Shared object "sqlite3_ds.so" not found, required by "python3.1"

Our immediate remaining goal in #1292 is to eliminate the need for
this special hack.

There can be several ways, but I personally think we should change how
we call dlopen(), i.e., rather than just passing the object name (like 
sqlite3_ds.so) and hoping the system to find the expected one, passing
the full path to the intended object file.  I believe we'll eventually
need the ability for this anyway, when users install their
experimental/proprietary data source module to some uncommon location.

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:

"data_sources":
  {"module_path": "/usr/local/lib", <=== the default path when unspecified
   "sqlite3":
     {"module_path": "/usr/local/lib/bind10-devel/modules/",
      "dbfile": "/usr/local/var/bind10-devel/zones.sqlite3" },
   "other DB":
     {"server_address": "192.0.2.1"...}}

dlopen() would then use the "module_path" information to locate the
correct place of the loadable module.

But even if we agree on the general idea, implementing the generic
configuration would be beyond the scope of #1292.  One middle term way
would be to have xfrin/xfrout(and notify_out, also soon auth)
specify the "module_path" in their code:

        datasrc_config = '{ "database_file": "' + \
            self._server.get_db_file() + '", ' +
            '"module_path": "' + MODULE_PATH '"}'
        self._datasrc_client = self.ClientClass('sqlite3', datasrc_config)

(where MODULE_PATH would be initialized to the install path by
autoconf, and tests would dynamically update it)

And, we also update factory.cc to take into account the "module_path"
parameter.

---
JINMEI, Tatuya



More information about the bind10-dev mailing list