Berkeley NSS DB 2.5 fork (nss_db)

Mark R Bannister mark@proseconsulting.co.uk
Wed Dec 14 15:32:00 GMT 2011


Mark R Bannister wrote:
> That would have been fine until just today (after
> already investing my time and effort) I discovered that nss_db has been
> reintroduced into glibc this year, without Berkeley DB support.

I've been thinking more about this, and it occurs to me that this wasn't perhaps
the best move.

Consider the repercussions of a) bringing nss_db back into glibc and not
providing it as a separate package and b) changing the backend so that it is no
longer Berkeley DB format.

Please see this posting:
http://lists.fedoraproject.org/pipermail/devel/2011-December/160497.html

The Berkeley DB is architecture independent.  I can create a passwd.db and
group.db file, for example, that I can equally use on any Linux host (any
architecture, big endian and little endian), and thanks to my Solaris port at
http://sf.net/projects/nssdb on any Solaris host too.  One database file served
up over NFS.  It can act as a cache, or the requirement I have worked on, a way
of overriding clashing UIDs/GIDs on a per-domain basis.

By removing Berkeley DB support and bringing nss_db back into glibc (as a simple
hash via mmap), you do the following:

   * Stifle any porting efforts to other platforms that don't use glibc.
   * Break backwards compatibility, so those who already have databases have to
re-create them.
   * Break cross-platform and cross-architecture support.  The same database
cannot even be used on the same flavour of Linux on different hardware if the
endianness differs (e.g. x86 will have to have one db file, Macs another).
   * By choosing to continue to name your now incompatible module nss_db, when
users upgrade to a Linux release that uses this latest glibc, things will break
in unexpected ways if they already use nss_db.  It is not backwards compatible. 
I suggest it would therefore have been better to rename it nss_db2, or some other
name, while retaining support for Berkeley DB format under nss_db.

Also, did you do some performance and memory-utilisation comparisons on large
databases?

So, Fedora 16 has since deprecated its nss_db package, assuming that the new
nss_db functionality back in glibc will fit the bill.  That means, come RHEL 7,
the problem will start to hit large enterprises.  This is when, I suspect, the
most pain will be felt.

It's not necessarily an easy problem for the Linux distros to solve themselves. 
They could offer http://sf.net/projects/nssdb as an option, but then if they want
to guarantee backwards compatibility they'll have to offer it up by default.  But
the installation of the latest glibc will overwrite libnss_db with an
incompatible version ....

Do you agree, or am I over exaggerating the problems here?  Do you have any
suggestions?

Best regards,
Mark.



More information about the Libc-help mailing list