[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
Hello,
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
from STAGING_DIR to TARGET_DIR.
* If the toolchain is uClibc or musl based, it would install the
built-in getent wrapper script, which has been extracted from uClibc
0.9.33.
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.
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
More information about the buildroot
mailing list