| Message ID | 1407176057-13180-2-git-send-email-benoit.thebaudeau@advansee.com |
|---|---|
| State | Superseded |
| Headers | show |
Dear Benoît Thébaudeau, On Mon, 4 Aug 2014 20:14:17 +0200, Benoît Thébaudeau wrote: > +config BR2_PACKAGE_SAMBA_LIBNSS_WINS > + bool "libnss_wins" > + default y if BR2_TOOLCHAIN_USES_GLIBC > + help > + libnss_wins is a library that permits the Name Service Switch > + to resolve NetBIOS names. > + > +config BR2_PACKAGE_SAMBA_LIBNSS_WINBIND > + bool "libnss_winbind" > + default y if BR2_TOOLCHAIN_USES_GLIBC > + help > + libnss_winbind is a library that permits the Name Service > + Switch to resolve user and group information from a Windows > + NT server. Since libnss loadable modules only work with glibc, shouldn't those options simply be "depends on BR2_TOOLCHAIN_USES_GLIBC" ? Also, do we really want two separate options here? Thanks! Thomas
Dear Thomas Petazzoni, On Monday, August 4, 2014 8:28:14 PM, Thomas Petazzoni wrote: > Dear Benoît Thébaudeau, > > On Mon, 4 Aug 2014 20:14:17 +0200, Benoît Thébaudeau wrote: > > > +config BR2_PACKAGE_SAMBA_LIBNSS_WINS > > + bool "libnss_wins" > > + default y if BR2_TOOLCHAIN_USES_GLIBC > > + help > > + libnss_wins is a library that permits the Name Service Switch > > + to resolve NetBIOS names. > > + > > +config BR2_PACKAGE_SAMBA_LIBNSS_WINBIND > > + bool "libnss_winbind" > > + default y if BR2_TOOLCHAIN_USES_GLIBC > > + help > > + libnss_winbind is a library that permits the Name Service > > + Switch to resolve user and group information from a Windows > > + NT server. > > Since libnss loadable modules only work with glibc, shouldn't those > options simply be "depends on BR2_TOOLCHAIN_USES_GLIBC" ? This is explained in the commit message. The libnss modules are indeed designed for glibc, but there is nothing preventing from using them directly without glibc (for testing or whatever), just as a normal library. This is probably not very useful, but there is no reason to prohibit this usage. > Also, do we really want two separate options here? I don't know. They are independent, so keeping them separate allows to save some space (1066244 bytes for libnss_wins.so and 38676 bytes for libnss_winbind.so on Raspberry Pi), but this is not a strong requirement if people prefer to see them merged. Best regards, Benoît
Hello Gustavo, Could you have a look at the below patch? It would be useful to have some review from a person knowing Samba better than I do. I must say I'm a bit skeptical about two things (about which probably Benoît can give some details) : * The usefulness of enabling the NSS libraries in non-glibc environments. Even though I agree that technically, nothing prevents some program from using them, in practice, the NSS libraries are basically only used by the glibc name resolution logic. So I would personally prefer to make those NSS libraries visible only in glibc configurations. * The fact that the winbindd daemon is not actually needed on the target to get libnss_wins/libnss_winbind working. My understanding is that winbindd is a daemon that will answer to the name resolution requests of libnss_wins/libnss_winbind, so I don't see how they can work without the daemon running. Also, Benoît, some minor comment below. On Mon, 4 Aug 2014 20:14:17 +0200, Benoît Thébaudeau wrote: > The libnss_wins and libnss_winbind libraries are required in order to add > support for the wins and winbind sources to the Name Service Switch (NSS), so > make it possible to install them. This is useful in order to resolve NetBIOS > names or user and group information from a Windows NT server. > > These libraries are installed to /lib/ like the standard libnss_* libraries from > (E)GLIBC. > > These libraries require the --with-winbind configuration option, but not the > files installed by BR2_PACKAGE_SAMBA_WINBINDD. That's why > BR2_PACKAGE_SAMBA_LIBNSS_* are not made to depend on BR2_PACKAGE_SAMBA_WINBINDD. > > These libraries are designed to be used by the NSS provided by (E)GLIBC, but > nothing forbids to use them directly without (E)GLIBC. That's why > BR2_PACKAGE_SAMBA_LIBNSS_* are not made to depend on BR2_TOOLCHAIN_USES_GLIBC. > BR2_PACKAGE_SAMBA_WINBINDD is enabled by default, so enable > BR2_PACKAGE_SAMBA_LIBNSS_* by default, but only if BR2_TOOLCHAIN_USES_GLIBC is > enabled since using these libraries without (E)GLIBC is unusual. > > Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com> > --- > package/samba/Config.in | 15 +++++++++++++++ > package/samba/samba.mk | 22 +++++++++++++++++++++- > 2 files changed, 36 insertions(+), 1 deletion(-) > > diff --git a/package/samba/Config.in b/package/samba/Config.in > index 8dd0bf2..8448784 100644 > --- a/package/samba/Config.in > +++ b/package/samba/Config.in > @@ -240,6 +240,21 @@ config BR2_PACKAGE_SAMBA_LIBSMBCLIENT > standards POSIX functions available for manipulating local > files. > > +config BR2_PACKAGE_SAMBA_LIBNSS_WINS > + bool "libnss_wins" > + default y if BR2_TOOLCHAIN_USES_GLIBC > + help > + libnss_wins is a library that permits the Name Service Switch > + to resolve NetBIOS names. > + > +config BR2_PACKAGE_SAMBA_LIBNSS_WINBIND > + bool "libnss_winbind" > + default y if BR2_TOOLCHAIN_USES_GLIBC > + help > + libnss_winbind is a library that permits the Name Service > + Switch to resolve user and group information from a Windows > + NT server. > + > endmenu > > > diff --git a/package/samba/samba.mk b/package/samba/samba.mk > index 84e525f..20cccbc 100644 > --- a/package/samba/samba.mk > +++ b/package/samba/samba.mk > @@ -58,7 +58,7 @@ SAMBA_CONF_OPT = \ > \ > $(if $(BR2_PACKAGE_SAMBA_RPCCLIENT),--with-readline=$(STAGING_DIR)) \ > $(if $(BR2_PACKAGE_SAMBA_SMBCLIENT),--with-readline=$(STAGING_DIR)) \ > - $(if $(BR2_PACKAGE_SAMBA_WINBINDD),--with-winbind,--without-winbind) > + $(if $(BR2_PACKAGE_SAMBA_WINBINDD)$(BR2_PACKAGE_SAMBA_LIBNSS_WINS)$(BR2_PACKAGE_SAMBA_LIBNSS_WINBIND),--with-winbind,--without-winbind) > > SAMBA_INSTALL_TARGET_OPT = \ > DESTDIR=$(TARGET_DIR) -C $(SAMBA_DIR)/$(SAMBA_SUBDIR) \ > @@ -135,6 +135,26 @@ endef > > SAMBA_POST_INSTALL_TARGET_HOOKS += SAMBA_REMOVE_UNNEEDED_BINARIES > > +define SAMBA_INSTALL_LIBNSS_WINS > + # install libnss_wins > + $(INSTALL) -m 0755 -D $(@D)/nsswitch/libnss_wins.so $(TARGET_DIR)/lib/ With -D, you should specify the full destination path. > + ln -snf libnss_wins.so $(TARGET_DIR)/lib/libnss_wins.so.2 > +endef > + > +ifeq ($(BR2_PACKAGE_SAMBA_LIBNSS_WINS),y) > +SAMBA_POST_INSTALL_TARGET_HOOKS += SAMBA_INSTALL_LIBNSS_WINS > +endif It would be better to have the definition of the hook function inside the conditional. > + > +define SAMBA_INSTALL_LIBNSS_WINBIND > + # install libnss_winbind > + $(INSTALL) -m 0755 -D $(@D)/nsswitch/libnss_winbind.so $(TARGET_DIR)/lib/ > + ln -snf libnss_winbind.so $(TARGET_DIR)/lib/libnss_winbind.so.2 > +endef > + > +ifeq ($(BR2_PACKAGE_SAMBA_LIBNSS_WINBIND),y) > +SAMBA_POST_INSTALL_TARGET_HOOKS += SAMBA_INSTALL_LIBNSS_WINBIND > +endif Same comments here. Thanks, Thomas
On 11/22/2014 05:33 PM, Thomas Petazzoni wrote: > Hello Gustavo, > > Could you have a look at the below patch? It would be useful to have > some review from a person knowing Samba better than I do. Hi, let's see. > I must say I'm a bit skeptical about two things (about which probably > Benoît can give some details) : > > * The usefulness of enabling the NSS libraries in non-glibc > environments. Even though I agree that technically, nothing prevents > some program from using them, in practice, the NSS libraries are > basically only used by the glibc name resolution logic. So I would > personally prefer to make those NSS libraries visible only in glibc > configurations. Even if they can be built they really are intended for (e)glibc so we agree. If you need to access/use wbclient functionality you could just use the wbclient (winbind) api by enabling samba install to staging, that's the public way of accessing it. > * The fact that the winbindd daemon is not actually needed on the > target to get libnss_wins/libnss_winbind working. My understanding > is that winbindd is a daemon that will answer to the name resolution > requests of libnss_wins/libnss_winbind, so I don't see how they can > work without the daemon running. AFAIK you need winbind running in order to use libwbclient and/or libnss_winbind/wins. I think libnss_wins has a fallback to DNS-only mode but it's probably not very useful. Also please note that Samba 3 is very likely going EOL as soon as Samba 4.2.x is released which even though delayed a bit in the RC phase is coming along pretty soon, so adding feature to the samba3 package isn't very wise IMHO (it's in security-only fixes now). See: https://wiki.samba.org/index.php/Samba_Release_Planning Regards.
Dear Gustavo Zacarias, On Mon, 24 Nov 2014 07:24:19 -0300, Gustavo Zacarias wrote: > > I must say I'm a bit skeptical about two things (about which probably > > Benoît can give some details) : > > > > * The usefulness of enabling the NSS libraries in non-glibc > > environments. Even though I agree that technically, nothing prevents > > some program from using them, in practice, the NSS libraries are > > basically only used by the glibc name resolution logic. So I would > > personally prefer to make those NSS libraries visible only in glibc > > configurations. > > Even if they can be built they really are intended for (e)glibc so we agree. > If you need to access/use wbclient functionality you could just use the > wbclient (winbind) api by enabling samba install to staging, that's the > public way of accessing it. Agreed. > > * The fact that the winbindd daemon is not actually needed on the > > target to get libnss_wins/libnss_winbind working. My understanding > > is that winbindd is a daemon that will answer to the name resolution > > requests of libnss_wins/libnss_winbind, so I don't see how they can > > work without the daemon running. > > AFAIK you need winbind running in order to use libwbclient and/or > libnss_winbind/wins. I think libnss_wins has a fallback to DNS-only mode > but it's probably not very useful. Ok. Benoît, can you rework your patches to take into account those comments? > Also please note that Samba 3 is very likely going EOL as soon as Samba > 4.2.x is released which even though delayed a bit in the RC phase is > coming along pretty soon, so adding feature to the samba3 package isn't > very wise IMHO (it's in security-only fixes now). > See: https://wiki.samba.org/index.php/Samba_Release_Planning Ok. Still there's some chance that we will keep Samba 3 around for a bit of time, just like we still have libgtk2 available. Thomas
Dear Thomas Petazzoni, On Mon, Nov 24, 2014 at 8:34 PM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > Dear Gustavo Zacarias, > > On Mon, 24 Nov 2014 07:24:19 -0300, Gustavo Zacarias wrote: > >> > I must say I'm a bit skeptical about two things (about which probably >> > Benoît can give some details) : >> > >> > * The usefulness of enabling the NSS libraries in non-glibc >> > environments. Even though I agree that technically, nothing prevents >> > some program from using them, in practice, the NSS libraries are >> > basically only used by the glibc name resolution logic. So I would >> > personally prefer to make those NSS libraries visible only in glibc >> > configurations. >> >> Even if they can be built they really are intended for (e)glibc so we agree. >> If you need to access/use wbclient functionality you could just use the >> wbclient (winbind) api by enabling samba install to staging, that's the >> public way of accessing it. > > Agreed. OK, I will change that. >> > * The fact that the winbindd daemon is not actually needed on the >> > target to get libnss_wins/libnss_winbind working. My understanding >> > is that winbindd is a daemon that will answer to the name resolution >> > requests of libnss_wins/libnss_winbind, so I don't see how they can >> > work without the daemon running. >> >> AFAIK you need winbind running in order to use libwbclient and/or >> libnss_winbind/wins. I think libnss_wins has a fallback to DNS-only mode >> but it's probably not very useful. > > Ok. From: https://www.samba.org/samba/docs/man/manpages/winbindd.8.html https://git.samba.org/?p=samba.git;a=blob;f=docs-xml/manpages-3/winbindd.8.xml;h=71829fb124950d901eb0516f77b5b9b4e41035ca;hb=refs/heads/v3-6-stable "Even if winbind is not used for nsswitch, it still provides a service to smbd, ntlm_auth and the pam_winbind.so PAM module, by managing connections to domain controllers." So libnss_wins / winbind do not directly require the winbindd daemon to be running in order to resolve names. I had tested this case, and it works fine. But winbindd is still closely related to this change, and maybe things do not work correctly without it in some network environments, so I will do this change anyway. > Benoît, can you rework your patches to take into account those comments? Sure, will do. >> Also please note that Samba 3 is very likely going EOL as soon as Samba >> 4.2.x is released which even though delayed a bit in the RC phase is >> coming along pretty soon, so adding feature to the samba3 package isn't >> very wise IMHO (it's in security-only fixes now). >> See: https://wiki.samba.org/index.php/Samba_Release_Planning > > Ok. Still there's some chance that we will keep Samba 3 around for a > bit of time, just like we still have libgtk2 available. That would be great. samba4 is currently monolithic and huge for embedded targets. Best regards, Benoît
On 11/24/2014 06:05 PM, Benoît Thébaudeau wrote: >>> Also please note that Samba 3 is very likely going EOL as soon as Samba >>> 4.2.x is released which even though delayed a bit in the RC phase is >>> coming along pretty soon, so adding feature to the samba3 package isn't >>> very wise IMHO (it's in security-only fixes now). >>> See: https://wiki.samba.org/index.php/Samba_Release_Planning >> >> Ok. Still there's some chance that we will keep Samba 3 around for a >> bit of time, just like we still have libgtk2 available. > > That would be great. samba4 is currently monolithic and huge for > embedded targets. I agree it'd be great since samba4 is huge in comparison (mostly because of the added dependencies, otherwise it's more logically put together in the target in the form of more shared libraries with common code instead of the "really big" binaries samba 3.x has). But i'm afraid upstream will throw the glove off on the 3.x series, there's been talk about it in the mailing list and it's on security-fixes only mode at the moment. Regards.
diff --git a/package/samba/Config.in b/package/samba/Config.in index 8dd0bf2..8448784 100644 --- a/package/samba/Config.in +++ b/package/samba/Config.in @@ -240,6 +240,21 @@ config BR2_PACKAGE_SAMBA_LIBSMBCLIENT standards POSIX functions available for manipulating local files. +config BR2_PACKAGE_SAMBA_LIBNSS_WINS + bool "libnss_wins" + default y if BR2_TOOLCHAIN_USES_GLIBC + help + libnss_wins is a library that permits the Name Service Switch + to resolve NetBIOS names. + +config BR2_PACKAGE_SAMBA_LIBNSS_WINBIND + bool "libnss_winbind" + default y if BR2_TOOLCHAIN_USES_GLIBC + help + libnss_winbind is a library that permits the Name Service + Switch to resolve user and group information from a Windows + NT server. + endmenu diff --git a/package/samba/samba.mk b/package/samba/samba.mk index 84e525f..20cccbc 100644 --- a/package/samba/samba.mk +++ b/package/samba/samba.mk @@ -58,7 +58,7 @@ SAMBA_CONF_OPT = \ \ $(if $(BR2_PACKAGE_SAMBA_RPCCLIENT),--with-readline=$(STAGING_DIR)) \ $(if $(BR2_PACKAGE_SAMBA_SMBCLIENT),--with-readline=$(STAGING_DIR)) \ - $(if $(BR2_PACKAGE_SAMBA_WINBINDD),--with-winbind,--without-winbind) + $(if $(BR2_PACKAGE_SAMBA_WINBINDD)$(BR2_PACKAGE_SAMBA_LIBNSS_WINS)$(BR2_PACKAGE_SAMBA_LIBNSS_WINBIND),--with-winbind,--without-winbind) SAMBA_INSTALL_TARGET_OPT = \ DESTDIR=$(TARGET_DIR) -C $(SAMBA_DIR)/$(SAMBA_SUBDIR) \ @@ -135,6 +135,26 @@ endef SAMBA_POST_INSTALL_TARGET_HOOKS += SAMBA_REMOVE_UNNEEDED_BINARIES +define SAMBA_INSTALL_LIBNSS_WINS + # install libnss_wins + $(INSTALL) -m 0755 -D $(@D)/nsswitch/libnss_wins.so $(TARGET_DIR)/lib/ + ln -snf libnss_wins.so $(TARGET_DIR)/lib/libnss_wins.so.2 +endef + +ifeq ($(BR2_PACKAGE_SAMBA_LIBNSS_WINS),y) +SAMBA_POST_INSTALL_TARGET_HOOKS += SAMBA_INSTALL_LIBNSS_WINS +endif + +define SAMBA_INSTALL_LIBNSS_WINBIND + # install libnss_winbind + $(INSTALL) -m 0755 -D $(@D)/nsswitch/libnss_winbind.so $(TARGET_DIR)/lib/ + ln -snf libnss_winbind.so $(TARGET_DIR)/lib/libnss_winbind.so.2 +endef + +ifeq ($(BR2_PACKAGE_SAMBA_LIBNSS_WINBIND),y) +SAMBA_POST_INSTALL_TARGET_HOOKS += SAMBA_INSTALL_LIBNSS_WINBIND +endif + define SAMBA_REMOVE_SWAT_DOCUMENTATION # Remove the documentation rm -rf $(TARGET_DIR)/usr/swat/help/manpages
The libnss_wins and libnss_winbind libraries are required in order to add support for the wins and winbind sources to the Name Service Switch (NSS), so make it possible to install them. This is useful in order to resolve NetBIOS names or user and group information from a Windows NT server. These libraries are installed to /lib/ like the standard libnss_* libraries from (E)GLIBC. These libraries require the --with-winbind configuration option, but not the files installed by BR2_PACKAGE_SAMBA_WINBINDD. That's why BR2_PACKAGE_SAMBA_LIBNSS_* are not made to depend on BR2_PACKAGE_SAMBA_WINBINDD. These libraries are designed to be used by the NSS provided by (E)GLIBC, but nothing forbids to use them directly without (E)GLIBC. That's why BR2_PACKAGE_SAMBA_LIBNSS_* are not made to depend on BR2_TOOLCHAIN_USES_GLIBC. BR2_PACKAGE_SAMBA_WINBINDD is enabled by default, so enable BR2_PACKAGE_SAMBA_LIBNSS_* by default, but only if BR2_TOOLCHAIN_USES_GLIBC is enabled since using these libraries without (E)GLIBC is unusual. Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com> --- package/samba/Config.in | 15 +++++++++++++++ package/samba/samba.mk | 22 +++++++++++++++++++++- 2 files changed, 36 insertions(+), 1 deletion(-)