Re: non-BDB support for DLZ in Bind9?
On Fri, Mar 25, 2016, at 05:03 PM, Evan Hunt wrote: > (And I didn't even remember to mention the fact that some DLZ modules now > support DNS UPDATE, which means you can have *dynamic* dynamically loadable > Dynamically Loadable Zones zones. It's a good thing we work on name > servers here at ISC because we're *excellent* at naming things.) Heh. Clearly, I'll need to wait for the new-and-improved natural-language documentation that'll accompany fully acronymi-zed DDLDLZZ v2 ... ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: non-BDB support for DLZ in Bind9?
On Fri, Mar 25, 2016 at 11:59:41PM +, Evan Hunt wrote: > (The name "Dynamically Loadable Zones" is, in retrospect, unfortunate. Now > that it's possible to load DLZ modules at runtime with dlopen(), that means > you can have dynamically loadable Dynamically Loadable Zones zones. Sorry > about that.) (And I didn't even remember to mention the fact that some DLZ modules now support DNS UPDATE, which means you can have *dynamic* dynamically loadable Dynamically Loadable Zones zones. It's a good thing we work on name servers here at ISC because we're *excellent* at naming things.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: non-BDB support for DLZ in Bind9?
On Fri, Mar 25, 2016 at 03:54:34PM -0700, PGNd wrote:
> I'm a mite confused about what the summary's telling me then.
>
> If I remove the 'unncessary' config items, the summary reports:
>
> Dynamically loadable zone (DLZ) drivers:
> None
>
> To my read, that says NO drivers will be dynamically loadable.
>
> Or does it mean something else here?
The distinction is between "DLZ drivers" and "DLZ modules". The drivers
(in contrib/dlz/drivers) have to be linked in to named when you compile,
and are reported as part of the configure summary. The runtime-loadable
modules don't need to be compiled in; you just build the .so file and add
something like this to named.conf:
dlz "bdbhpt_dynamic" {
database "dlopen ../dlz_bdbhpt_dynamic.so T . test.db";
};
(The name "Dynamically Loadable Zones" is, in retrospect, unfortunate. Now
that it's possible to load DLZ modules at runtime with dlopen(), that means
you can have dynamically loadable Dynamically Loadable Zones zones. Sorry
about that.)
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: non-BDB support for DLZ in Bind9?
On Fri, Mar 25, 2016, at 03:48 PM, Evan Hunt wrote: > To use the runtime-linkable modules, all you need is "configure". > (The "--with-dlopen" part is enabled by default already, and the > others are unnecessary.) > > Then "cd contrib/dlz/modules/bdbhpt" (or whichever one you want to use), > and run "make". The resulting .so file needs to be put somewhere that > named can find it. There's a sample configuration in the "testing" > subdirectory that you can use for guidance. I'm a mite confused about what the summary's telling me then. If I remove the 'unncessary' config items, the summary reports: Dynamically loadable zone (DLZ) drivers: None To my read, that says NO drivers will be dynamically loadable. Or does it mean something else here? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: non-BDB support for DLZ in Bind9?
> Right. I was just referring to the *docs*, which afaict are still the most > complete, conceptually re: DLZ anyway > > IIUC (?), I'm correctly invoking with at > > ./configure ... > --with-dlz-postgres=no \ > --with-dlz-mysql=no \ > --with-dlz-bdb=/usr/local/dlz-bdb \ > --with-dlz-filesystem=yes \ > --with-dlz-ldap=no \ > --with-dlz-odbc=no \ > --with-dlz-stub=yes \ > --with-dlopen=yes To use the runtime-linkable modules, all you need is "configure". (The "--with-dlopen" part is enabled by default already, and the others are unnecessary.) Then "cd contrib/dlz/modules/bdbhpt" (or whichever one you want to use), and run "make". The resulting .so file needs to be put somewhere that named can find it. There's a sample configuration in the "testing" subdirectory that you can use for guidance. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: non-BDB support for DLZ in Bind9?
Thanks for the quick reply. > These still work but are somewhat obsolete now. BIND now has the ability to > dynamically load DLZ modules at run time Right. I was just referring to the *docs*, which afaict are still the most complete, conceptually re: DLZ anyway IIUC (?), I'm correctly invoking with at ./configure ... --with-dlz-postgres=no \ --with-dlz-mysql=no \ --with-dlz-bdb=/usr/local/dlz-bdb \ --with-dlz-filesystem=yes \ --with-dlz-ldap=no \ --with-dlz-odbc=no \ --with-dlz-stub=yes \ --with-dlopen=yes where I do a bit of hoop-jumping-for-convenience due to the distro's system-locations, namely mkdir /usr/local/dlz-bdb cd /usr/local/dlz-bdb ln -sf /usr/include/db4 include ln -sf /usr/local/lib64 lib wherein my config summary tells me Configuration summary: Optional features enabled: ... Dynamically loadable zone (DLZ) drivers: Berkeley DB (--with-dlz-bdb) Filesystem (--with-dlz-filesystem) Stub (--with-dlz-stub) ... and ldd `which named` | egrep -i "libdl|libdb" libdb-4.8.so => /usr/lib64/libdb-4.8.so (0x7efc2dbdd000) libdl.so.2 => /lib64/libdl.so.2 (0x7efc2c6cd000) > Not that I know of, but you can build queryperf (contrib/queryperf) and > measure it. Well, looky that! How long's that been in there? Thx. > > What's Bind's position on BDB dependency & support, and implementation > > any alternative such as LMDB, going forward? > > We have no position on the licensing issue. I can imagine why ... > Technically, the DLZ modules are considered contributed code and are not > formally supported by ISC IMO, It'd be great if that were to change at some point. Understand that resources are needed. > If someone were to build an > LMDB module (which might be pretty straightforward if the API is similar > to BDB) I would be delighted to accept that contribution. I'm starting to poke around myself; hope that a more capable solution appears. Can't help but wonder out loud if an LMDB-based bundled solution might work out ... Fyi+fwiw, @ http://symas.com/mdb/ "Since the LMDB API is similar to BerkeleyDB, porting existing BDB-based code to LMDB is usually quite simple and fast. More projects will be adapted as they come to our attention." ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: non-BDB support for DLZ in Bind9?
On Fri, Mar 25, 2016 at 01:40:29PM -0700, PGNd wrote: > In DLZ, as packaged with bind9, currently a variety of db drivers are > supported, > > grep "AC_ARG_WITH(dlz_" contrib/dlz/config.dlz.in > AC_ARG_WITH(dlz_postgres, > AC_ARG_WITH(dlz_mysql, > AC_ARG_WITH(dlz_bdb, > AC_ARG_WITH(dlz_filesystem, > AC_ARG_WITH(dlz_ldap, > AC_ARG_WITH(dlz_odbc, > AC_ARG_WITH(dlz_stub, > > Of those, as (historically) pointed out @ > > http://bind-dlz.sourceforge.net/driver_docs.html These still work but are somewhat obsolete now. BIND now has the ability to dynamically load DLZ modules at run time, without having to have them compiled in in advance. These loadable modules are in contrib/dlz/modules, and I would expect the ones for bdb, mysql, sqlite3 and ldap to have fairly comparable performance -- it's no longer the case that only the bdb driver supports threads, and the underlying database performance for all of those has improved in recent years -- but you'd better benchmark it yourself to be sure. (Mind you, DLZ performance in general is pretty terrible; none of them is even within an order of magnitude of regular BIND zones when it comes to query performance. Of that much I'm sure, but I can't say which one is the fastest slowpoke.) > (2) are there any available metrics comparing BDB with Filesystem drivers? Not that I know of, but you can build queryperf (contrib/queryperf) and measure it. > With BDB's licensing change from Sleepycat -> AGPL (cref: > https://lwn.net/Articles/557820/, > https://developers.slashdot.org/story/13/07/05/1647215/oracle-quietly-switches-berkeleydb-to-agpl) > distros (e.g. Debian) & other server apps (e.g., Postfix) have added support > for, and/or currently recommend use of, OpenLDAP 'LMDB' (e.g., > http://symas.com/mdb/, > https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Database), database as > a license-friendly, performant alternative. > > TBH, I don't know WTF is going on *currentlY* with libdb vX.X's > licensing; it's all bit fuzzy so far as I've (re)read. My personal > preference is an Oracle-free deployment; opinions & needs vary, of > course. > > What's Bind's position on BDB dependency & support, and implementation > any alternative such as LMDB, going forward? We have no position on the licensing issue. Technically, the DLZ modules are considered contributed code and are not formally supported by ISC, though we do make our best effort to fix bugs. If someone were to build an LMDB module (which might be pretty straightforward if the API is similar to BDB) I would be delighted to accept that contribution. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
