[bind10-dev] #1292 and data source configuration

[Jelte Jansen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/23/2011 09:38 AM, JINMEI Tatuya / 神明達哉 wrote:
> 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:
> 

Aha, I was under the impression that 1292 was just to fix the problem
that was actually appearing at this moment, and that the fundamental
change of removing the existing workaround was a different ticket.

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

ok

> 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.
> 

I was thinking,

> 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?

> "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.
> 

(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)

Additionally, we should probably do some version check when loading the
module so that we are sure we can fail cleanly and not with a segfault
if we ever add a function.

> 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.
> 

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.

Jelte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7M4fYACgkQ4nZCKsdOncUPzgCffL37OWTqnGQSF6g5TiIfaZES
C8sAn21BiJItANFHD4WHF8BCfzbBLQnd
=v1g8
-----END PGP SIGNATURE-----