Installation of getent, solving bug #7142
v2 cover Installation of getent, solving bug #7142
Hello,
Here is a second version of the patches to fix bug #7142. As I proposed, this new version takes a simplified approach: it creates an autonomous getent package, which simply installs the toolchain's getent program when the toolchain is glibc based, and otherwise installed the wrapper script borrowed from uclibc sources. This new solution avoids doing complicated stuff in the toolchain support, and completely isolates all the logic in the getent package.
It is functionally identical to the previously proposed solution, except for internal uClibc toolchains: in the previous solution, the getent script from the uClibc sources was used, while with this solution, it's a fixed version inside the getent package that is being used. However, considering the very simple nature of the script, it's unlikely to be changed frequently in uClibc sources, so this difference shouldn't cause much troubles.
Thanks,
Thomas
Thomas Petazzoni (2):
getent: new package
ecryptfs-utils: add runtime dependency on getent
package/Config.in | 1 + package/ecryptfs-utils/Config.in | 2 ++ package/getent/Config.in | 10 +++++++++ package/getent/getent | 45 ++++++++++++++++++++++++++++++++++++++++ package/getent/getent.mk | 26 +++++++++++++++++++++++ 5 files changed, 84 insertions(+) create mode 100644 package/getent/Config.in create mode 100644 package/getent/getent create mode 100644 package/getent/getent.mk
Signature · 1 line
2.0.0
PATCH v2 1/2 getent: new package
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 getent package, which has the following behavior:
- When the toolchain is glibc based (either internal or external), it installs the getent program that was built and installed in the staging directory. This covers cases 1/ a/ and 2/ a/ above.
- When the toolchain is uclibc or musl based, it installs a version of uclibc's getent wrapper script that is built into the getent package. This script is unlikely to change over time, so having it directly built into the package should not cause much issues moving forward. This covers all other cases above.
This solution allows to install a NSS-capable getent when glibc/eglibc is used, and otherwise to rely on uClibc's wrapper script.
--- package/Config.in | 1 + package/getent/Config.in | 10 ++++++++++ package/getent/getent | 45 +++++++++++++++++++++++++++++++++++++++++++++ package/getent/getent.mk | 26 ++++++++++++++++++++++++++ 4 files changed, 82 insertions(+) create mode 100644 package/getent/Config.in create mode 100644 package/getent/getent create mode 100644 package/getent/getent.mk
package/Config.in +1 -0
@@ -1159,6 +1159,7 @@ if BR2_PACKAGE_BUSYBOX_SHOW_OTHERS endif source "package/dsp-tools/Config.in" source "package/ftop/Config.in" + source "package/getent/Config.in" source "package/htop/Config.in" source "package/iprutils/Config.in" source "package/keyutils/Config.in"
package/getent/Config.in new file +10 -0
@@ -0,0 +1,10 @@ +config BR2_PACKAGE_GETENT + bool "getent" + help + This package installs the 'getent' utility, which allows to + get entries from Name Service Switch libraries. For glibc + toolchains, it's the real getent program from the C library + that gets installed, which is NSS-capable. For uclibc and + musl toolchains, it's a simple wrapper script that emulates + getent's behavior, since there is no NSS support in uclibc + and musl.
package/getent/getent new file +45 -0
45 lines not on this page · raw message
package/getent/getent.mk new file +26 -0
@@ -0,0 +1,26 @@ +################################################################################ +# +# getent +# +################################################################################ + +# source included in Buildroot +GETENT_SOURCE = + +GETENT_VERSION = buildroot-$(BR2_VERSION) +GETENT_LICENSE = LGPLv2.1+ + +# For glibc toolchains, we use the getent program built/installed by +# the C library. For other toolchains, we use the wrapper script +# included in this package. +ifeq ($(BR2_TOOLCHAIN_USES_GLIBC),y) +GETENT_LOCATION = $(STAGING_DIR)/usr/bin/getent +else +GETENT_LOCATION = package/getent/getent +endif + +define GETENT_INSTALL_TARGET_CMDS + $(INSTALL) -D -m 0755 $(GETENT_LOCATION) $(TARGET_DIR)/usr/bin/getent +endef + +$(eval $(generic-package))
Signature · 1 line
2.0.0
PATCH v2 1/2 getent: new package
Hi Thomas,
On Mon, Aug 18, 2014 at 11:54 AM, Thomas Petazzoni <[email protected]> wrote:
[..]
Quoted 7 lines
package/getent/getent.mk new file +1
-0@@ -0,0 +1,26 @@ +################################################################################
package/getent/getent.mk line 11
Quoted 10 lines
package/getent/getent.mk new file +10
-0+# +# getent +# +################################################################################ + +# source included in Buildroot +GETENT_SOURCE = + +GETENT_VERSION = buildroot-$(BR2_VERSION) +GETENT_LICENSE = LGPLv2.1+
How do you conclude this license?
Isn't this dependent on the case glibc versus uclibc/musl ? Or do each of these use the same license?
Also, shouldn't we specify GETENT_LICENSE_FILES and make sure the appropriate license text is present?
Best regards,
Thomas
PATCH v2 1/2 getent: new package
Dear Thomas De Schampheleire,
Quoted 1 line · Thomas De Schampheleire
How do you conclude this license?
uclibc: there is no license specific in the script itself, so by default it's the same license as the entire project, i.e LGPLv2.1+
glibc: the header comment in nss/getent.c is clear: it's under LGPLv2.1+.
Quoted 2 lines
Isn't this dependent on the case glibc versus uclibc/musl ? Or do each of these use the same license?
See above :)
Quoted 2 lines
Also, shouldn't we specify
GETENT_LICENSE_FILESand make sure the appropriate license text is present?
Which license text file should be used? In neither of the uclibc/musl or glibc cases we have access to the license text. I can include a COPYING file in package/getent/, but that's going to be 100x times larger than the getent script :)
Thanks,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH v2 1/2 getent: new package
Quoted 9 lines · Thomas Petazzoni
Dear Thomas De Schampheleire,
Quoted 1 line · Thomas De Schampheleire
How do you conclude this license?
uclibc: there is no license specific in the script itself, so by default it's the same license as the entire project, i.e LGPLv2.1+
Quoted 7 lines
glibc: the header comment in
nss/getent.cis clear: it's under LGPLv2.1+.Quoted 2 lines
Isn't this dependent on the case glibc versus uclibc/musl ? Or do each of these use the same license?
See above :)
OK
Quoted 8 lines
Quoted 3 lines
Also, shouldn't we specify
GETENT_LICENSE_FILESand make sure the appropriate license text is present?Which license text file should be used? In neither of the uclibc/musl or glibc cases we have access to the license text. I can include a COPYING file in package/getent/, but that's going to be 100x times larger than the getent script :)
Hmm, not sure what to do here.
If we don't specify anything, the developer wanting to distribute an image will have to manually add a LGPL2.1 license text.
Is there a big problem that the license text would be so much bigger than the script itself? If we'd have multiple packages with source included in buildroot, we could move the licenses to one directory to avoid duplication.
But I have no strong opinion here...
Best regards,
Thomas
PATCH v2 1/2 getent: new package
Dear Thomas De Schampheleire,
Quoted 10 lines · Thomas De Schampheleire
Quoted 4 lines
Which license text file should be used? In neither of the uclibc/musl or glibc cases we have access to the license text. I can include a COPYING file in package/getent/, but that's going to be 100x times larger than the getent script :)
Hmm, not sure what to do here.
If we don't specify anything, the developer wanting to distribute an image will have to manually add a LGPL2.1 license text.
Quoted 6 lines
Is there a big problem that the license text would be so much bigger than the script itself? If we'd have multiple packages with source included in buildroot, we could move the licenses to one directory to avoid duplication.
But I have no strong opinion here...
Note that we have a lot of packages that have a value for <pkg>_LICENSE, and no value defined for <pkg>_LICENSE_FILES.
According to http://autobuild.buildroot.org/stats/, we have 76 packages without <pkg>_LICENSE, and 152 without <pkg>_LICENSE_FILES. Therefore, I think that's a more global problem, not limited to just this package. At least, I don't think it should be a blocking issue, especially considering the fact that this set of patches is meant to fix a bug before the release.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH v2 1/2 getent: new package
Thomas Petazzoni <[email protected]> schreef:
Quoted 24 lines
Dear Thomas De Schampheleire,
Quoted 10 lines · Thomas De Schampheleire
Quoted 4 lines
Which license text file should be used? In neither of the uclibc/musl or glibc cases we have access to the license text. I can include a COPYING file in package/getent/, but that's going to be 100x times larger than the getent script :)
Hmm, not sure what to do here.
If we don't specify anything, the developer wanting to distribute an image will have to manually add a LGPL2.1 license text.
Quoted 6 lines
Is there a big problem that the license text would be so much bigger than the script itself? If we'd have multiple packages with source included in buildroot, we could move the licenses to one directory to avoid duplication.
But I have no strong opinion here...
Note that we have a lot of packages that have a value for <pkg>_LICENSE, and no value defined for <pkg>_LICENSE_FILES.
Quoted 6 lines
According to http://autobuild.buildroot.org/stats/, we have 76 packages without <pkg>_LICENSE, and 152 without <pkg>_LICENSE_FILES. Therefore, I think that's a more global problem, not limited to just this package. At least, I don't think it should be a blocking issue, especially considering the fact that this set of patches is meant to fix a bug before the release.
No, agreed, let's proceed with this version of the patch...
Best regards,
Thomas
PATCH v2 1/2 getent: new package
In reply to Thomas PetazzoniQuoted 48 lines · Thomas Petazzoni
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 getent package, which has the following behavior:
- When the toolchain is glibc based (either internal or external), it installs the getent program that was built and installed in the staging directory. This covers cases 1/ a/ and 2/ a/ above.
- When the toolchain is uclibc or musl based, it installs a version of uclibc's getent wrapper script that is built into the getent package. This script is unlikely to change over time, so having it directly built into the package should not cause much issues moving forward. This covers all other cases above.
Quoted 4 lines
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 <[email protected]>
Fixes a (run-time) bug, so please apply.
Regards,
Arnout
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
PATCH v2 1/2 getent: new package
Quoted 8 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Arnout" == Arnout Vandecappelle <[email protected]> writes:
Quoted 5 lines · Thomas Petazzoni
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.
Quoted 8 lines
Quoted 4 lines
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 <[email protected]>Fixes a (run-time) bug, so please apply.
Committed, thanks.
Signature · 1 line
Bye, Peter Korsgaard
PATCH v2 1/2 getent: new package
In reply to Arnout VandecappelleQuoted 12 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Arnout" == Arnout Vandecappelle <[email protected]> writes:
Quoted 9 lines · Thomas Petazzoni
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.
Quoted 8 lines
Quoted 4 lines
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 <[email protected]>Fixes a (run-time) bug, so please apply.
We have some autobuild issues, like:
http://autobuild.buildroot.net/results/820/8207527e3e42a226649c5f5fbf62fa8a77b89467/
(codesourcery mips 2013.05)
Should we perhaps fallback to the uClibc emulation version if the toolchain doesn't provide it?
Signature · 1 line
Bye, Peter Korsgaard
PATCH v2 1/2 getent: new package
Quoted 21 lines · Peter Korsgaard
Quoted 12 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Arnout" == Arnout Vandecappelle <[email protected]> writes:
Quoted 9 lines · Thomas Petazzoni
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.Quoted 8 lines
Quoted 4 lines
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 <[email protected]>Fixes a (run-time) bug, so please apply.
Quoted 9 lines
We have some autobuild issues, like:
http://autobuild.buildroot.net/results/820/8207527e3e42a226649c5f5fbf62fa8a77b89467/
(codesourcery mips 2013.05)
Should we perhaps fallback to the uClibc emulation version if the toolchain doesn't provide it?
The toolchain does provide it, but it's in a different path
(libc/usr/lib/bin/getent).
Thomas, did you test this at all with a CodeSourcery toolchain because it looks
like it's never in sysroot/usr/bin...
I guess the external toolchain infrastructure should copy it like it does for
the libraries.
Regards,
Arnout
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
PATCH v2 2/2 ecryptfs-utils: add runtime dependency on getent
In reply to Thomas PetazzoniFixes bug #7142.
--- package/ecryptfs-utils/Config.in | 2 ++ 1 file changed, 2 insertions(+)
package/ecryptfs-utils/Config.in +2 -0
@@ -5,6 +5,8 @@ config BR2_PACKAGE_ECRYPTFS_UTILS # runtime dependency only, some scripts are using the # 'gettext' program to get translations select BR2_PACKAGE_GETTEXT + # runtime dependency only + select BR2_PACKAGE_GETENT depends on BR2_USE_WCHAR # gettext depends on BR2_USE_MMU # keyutils depends on !BR2_avr32 && !BR2_microblaze # keyutils
Signature · 1 line
2.0.0
PATCH v2 2/2 ecryptfs-utils: add runtime dependency on getent
Quoted 3 lines · Thomas Petazzoni
Fixes bug #7142.
Signed-off-by Thomas Petazzoni <[email protected]>
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
PATCH v2 2/2 ecryptfs-utils: add runtime dependency on getent
Quoted 8 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Arnout" == Arnout Vandecappelle <[email protected]> writes:
Quoted 3 lines · Thomas Petazzoni
Fixes bug #7142.
Signed-off-by Thomas Petazzoni <[email protected]>
Committed, thanks.
Signature · 1 line
Bye, Peter Korsgaard