Re: Berkeley NSS DB 2.5 fork (nss_db)

[Mark R Bannister <mark at proseconsulting dot co dot uk>]

Mark R Bannister wrote on libc-help:
> 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.

http://sourceware.org/ml/libc-help/2011-12/
.. copying to libc-alpha:

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.