[Buildroot] [PATCH 1/2] toolchain: add mechanism to install the getent program

Thomas Petazzoni thomas.petazzoni at free-electrons.com
Sun Aug 17 08:27:44 UTC 2014


On Sat, 16 Aug 2014 16:39:51 +0200, Thomas Petazzoni wrote:
> The ecryptfs-utils scripts require the 'getent' program to be
> installed to find the home directory of users. However, Buildroot
> currently never installs this program, and therefore bug #7142 was
> reported, explaining that ecryptfs-utils is not working properly.
> In normal Linux systems, the getent program is provided by glibc, and
> allows to query not only /etc/passwd, but also other NSS databases
> such as LDAP and others.
> In the context of Buildroot, this gives us several cases:
>  1/ Internal toolchain
>     a/ glibc/eglibc. In this case, the getent program is already built
>        and installed by Buildroot in the staging directory, so the
>        only thing missing is installing it in the target directory.
>     b/ uclibc. uClibc provides a simple shell script that emulates the
>        behavior of getent. It is located in extra/scripts/getent in
>        the uClibc sources, but is currently never installed.
>     c/ musl. There seems to be no getent implementation, and musl does
>        not support NSS.
>  2/ External toolchain
>     a/ glibc/eglibc. In several external toolchains that we tested,
>        there is a pre-built getent binary available in the sysroot,
>        but Buildroot is not installing it to the target.
>     b/ uclibc. The getent wrapper script is typically not part of any
>        external uClibc toolchain.
>     c/ musl. There is no getent implementation.
> This patch proposes to solve this problem by introducing a hidden
> BR2_TOOLCHAIN_INSTALL_GETENT Config.in option, which packages needing
> 'getent' should select, and that toolchain packages should use to know
> whether getent should be installed or not.
> On the toolchain side of things, the behavior is as follows:
>  - For 1/ a/ above, the glibc package is modified to install the
>    getent program that was built.
>  - For 1/ b/ above, the uclibc package is modified to install the
>    getent wrapper script available as part of the uClibc sources.
>  - For 1/ c/ above, the musl package is modified to depend on the new
>    'getent' package, which simply bundles the 'getent' wrapper script
>    of uClibc 0.9.33.
>  - For 2/ a/ above, the toolchain-external package installs the
>    'getent' program that is available as part of the external
>    toolchain sysroot.
>  - For 2/ b/ and 2/ c/ above, the toolchain-external package depends
>    on the new 'getent' package.
> This solution allows to install a NSS-capable getent when glibc/eglibc
> is used, and otherwise to rely on uClibc's wrapper script.
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

In fact, I think I have a simpler solution to propose, with just a
getent package, and no need for a BR2_TOOLCHAIN_INSTALL_GETENT stuff.
The getent package would:

 * If the toolchain is glibc/eglibc based (regardless of whether it's
   internal of external), the package would install the getent program

 * If the toolchain is uClibc or musl based, it would install the
   built-in getent wrapper script, which has been extracted from uClibc

This solution has the same result as the previously proposed solution,
except for case 1/ b/ (internal uClibc toolchain): with the previous
solution, the getent program of the current uClibc version being used
was installed, while with the new solution, a fixed version of the
getent program will be installed. However, since I don't think the
getent wrapper script is going to change often in uClibc, I don't think
this difference really matters.

This makes the entire patch must simpler. I'll respin with this idea
unless some of you disagree.


Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering

More information about the buildroot mailing list