On Mon, 2016-09-12 at 14:54 +0200, Joakim Tjernlund wrote:
> On Mon, 2016-09-12 at 14:42 +0200, Joakim Tjernlund wrote:
> >
> > On Mon, 2016-09-12 at 14:06 +0200, Lukas Slebodnik wrote:
> > >
> > >
> > > On (12/09/16 11:37), Joakim Tjernlund wrote:
> > > >
> > > >
> > > >
> > > > On Mon, 2016-09-12 at 11:30 +0200, Sumit Bose wrote:
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Sep 12, 2016 at 09:01:23AM +0000, Joakim Tjernlund
wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Mon, 2016-09-12 at 10:27 +0200, Lukas Slebodnik wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On (12/09/16 08:08), Joakim Tjernlund wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Mon, 2016-09-12 at 09:41 +0200, Sumit Bose
wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Fri, Sep 09, 2016 at 07:07:58PM +0000,
Joakim Tjernlund wrote:
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Fri, 2016-09-09 at 20:53 +0200, Lukas
Slebodnik wrote:
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On (09/09/16 18:35), Joakim
Tjernlund wrote:
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, 2016-09-09 at 19:40
+0200, Lukas Slebodnik wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On (09/09/16 16:25),
Sumit Bose wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Fri, Sep 09, 2016
at 02:00:53PM +0000, Joakim Tjernlund wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Fri,
2016-09-09 at 14:48 +0200, Sumit Bose wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Fri,
Sep 09, 2016 at 11:46:27AM +0000, Joakim Tjernlund wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
Trying to bring up samba with sssd-13.4 and for some reason samba fails
> > > > > > > > > > > > > > > > > to
lookup users: From smb.log I have:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On
older systems I have samba 3.6.25 and sssd 1.12.5 and there samba works
> > > > > > > > > > > > > > > > >
fine.
> > > > > > > > > > > > > > > > > Is
there som change I have missed when upgrading to newer samba sssd?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Are you
using SSSD's version of libwbclient to help samba to map SID to
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > hmm, I got both
(/usr/lib64/libwbclient.so.0 and
> > > > > > > > > > > > > > >
/usr/lib64/sssd/modules/libwbclient.so)
> > > > > > > > > > > > > > > and wbinfo -n
'TRAN_01\jocke' reports:
> > > > > > > > > > > > > > > wbinfo -n
'TRAN_01\jocke'
> > > > > > > > > > > > > > > could not
obtain winbind interface details: WBC_ERR_WINBIND_NOT_AVAILABLE
> > > > > > > > > > > > > > > could not
obtain winbind separator!
> > > > > > > > > > > > > > > failed to call
wbcLookupName: WBC_ERR_WINBIND_NOT_AVAILABLE
> > > > > > > > > > > > > > > Could not
lookup name TRAN_01\jocke
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I guess the
problem is that samba uses its own libwbclient.so and winbind
> > > > > > > > > > > > > > > is not
configured?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > iirc you are using
gentoo. In Fedora/RHEL is is possible to switch
> > > > > > > > > > > > > > those two libraries
with the alternatives command.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To make at least
wbinfo try to use SSSD's version you can try calling it
> > > > > > > > > > > > > > as:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
LD_LIBRARY_PATH=/usr/lib64/sssd/modules wbinfo -n 'TRAN_01\jocke'
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > as long as wbinfo is
not complied with rpath or similar it should pick
> > > > > > > > > > > > > >
/usr/lib64/sssd/modules/libwbclient.so.0 instead of
> > > > > > > > > > > > > >
/usr/lib64/libwbclient.so.0. If there is no
> > > > > > > > > > > > > >
/usr/lib64/sssd/modules/libwbclient.so.0 you should add it as a softlink
> > > > > > > > > > > > > > to
/usr/lib64/sssd/modules/libwbclient.so. I would also expect that
> > > > > > > > > > > > > > there are link with
ends with a version number like 11 or 12.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > and samba 4.5 has
libwbclient.so.0.13
> > > > > > > > > > > > >
> > > > > > > > > > > > > [root@host ~]# rpm -qf
/usr/lib64/samba/wbclient/libwbclient.so.0.13
> > > > > > > > > > > > >
libwbclient-4.5.0-0.0.rc1.fc26.x86_64
> > > > > > > > > > > > and lives in its own package.
Is this new from samba >= 4.5 ?
> > > > > > > > > > > >
> > > > > > > > > > > Yes,
> > > > > > > > > > > I cannot see it in official
announcement (2 days old :-)
> > > > > > > > > > >
https://lists.samba.org/archive/samba-technical/2016-September/116033.html
> > > > > > > > > > > but samba 4.4.5 has just a
libwbclient.so.0.12
> > > > > > > > > > >
> > > > > > > > > > > But if you asked about packaging
then
> > > > > > > > > > > the libwbclient (from samba) and
sssd-libwbclient are separate packages
> > > > > > > > > > > on fedora since I remember :-)
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I see, now the 1000 $ question, is sssd
able to use libwbclient from samba too?
> > > > > > > > >
> > > > > > > > > It does not have to. libwbclient is an
interface for Samba components to
> > > > > > > > > get data from winbind. The SSSD version of
libwbclient implements some
> > > > > > > > > parts to the interface to allow the Samba
components to get SID, name,
> > > > > > > > > POSIX ID mapping data from SSSD instead of
winbind. So SSSD provides the
> > > > > > > > > interface but does not use it.
> > > > > > > > >
> > > > > > > >
> > > > > > > > I guess that would be somewhat unusual case and
not really needed.
> > > > > > > > To summarize, in Fedora, the libwbclient libs from
samba resp. sssd are installed
> > > > > > > > under non standard search paths, are separate pkgs
and there is a "script"(alternatives)
> > > > > > > > that selects between the two by creating a symlink
in /usr/lib{,64,32} to either
> > > > > > > > samba's libwbclient or sssd's libwbclient.
Is that correct?
> > > > > > > >
> > > > > > > > Have you considered a more direct way? That is, if
sssd's libwbclient is built/installed
> > > > > > > > it always takes over(eliminaiting the need for an
alternatives script? Or just require
> > > > > > > > that only one of libwbclient pkgs can be installed
at the same time?
> > > > > > > >
> > > > > > > sssd-libwbclient does not implement all functions.
That's reason why it is not
> > > > > > > a default; and just an alternative.
> > > > > >
> > > > > > hmm, then I wonder why my samba stopped working just from
moving from samba 3.6.25 to 4.2.11/14
> > > > > > Maybe some bug in samba/my smb.conf ?
> > > > >
> > > > > The newer versions of Samba removed some fallback code e.g. to
fix the
> > > > > Badlock (
http://badlock.org/) issue. The means newer versions of
Samba
> > > > > require that winbind is running in more and more use cases. In
some
> > > > > cases SSSD's version of libwbclient might be sufficient in
some cases
> > > > > (see below) it is not.
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Not impl. all functions makes it hard to know when to use
sssd's libwbclient,
> > > > > > how to figure out when sssd's libwbclient is good
enough?
> > > > >
> > > > > Yes and to make is worse as mentioned above there are more and
more use
> > > > > cases where Samba requires that winbind is running. If you have
to run
> > > > > winbind, e.g. if you needed to proxy NTLM authentication to a AD
DC, you
> > > > > of course have to use Samba's version of libwbclient. To make
sure the
> > > > > SID to POSIX ID mapping is consistent on the system SSSD 1.14
also
> > > > > provides an idmapping plugin for winbind (see man idmap_sss for
> > > > > details). With this plugin winbind will ask SSSD to do the
mapping.
> > > > >
> > > >
> > > > I see, thanks for this info. it might not be worth to add sssd
libwbclient support to Gentoo just yet.
> > > > I will see if I can get samba running with native libwbclient first.
> > > >
> > > BTW SSSD 1.13.4 has sssd-libwbclient as well
> > >
> > > >
> > > >
> > > >
> > > > Speaking of sssd-1.14, I cannot build 1.14 with the same dependencies
as 1.13, for instance:
> > > > configure:21738: error: libhttp_parser missing http_parser_init
> > > I will take a look
> > >
> > > >
> > > >
> > > >
> > > > Gentoo has:
> > > > net-libs/http-parser-2.6.2
> > > >
> > > Did you use special USE flags?
> >
> > No, it only has static-libs which I have off.
> >
> > >
> > >
> > >
> > > >
> > > >
> > > >
> > > > Maybe the deps has been updated? Is here a list with minimum deps for
sssd 1.14?
> > > >
> > > Meanwhile you can disable secrets responder and thus dependency on
> > > libhttp_parser + libjansson
> >
> > libjansson? I don't have that installed(installing now and retrying 1.14
..., nope:
> > checking for fakeroot... yes
> > checking for py.test... no
> > checking for HTTP_PARSER... no
> > checking http_parser.h usability... yes
> > checking http_parser.h presence... yes
> > checking for http_parser.h... yes
> > checking for http_parser_init in -lhttp_parser_strict... no
> > checking for http_parser_init in -lhttp_parser... no
> > configure: error: libhttp_parser missing http_parser_init
> >
> > Jocke
> >
> > >
> > >
> > >
> > > --without-secrets
> > >
> >
> > Will try this next ...
>
> I figured out the http-parser, it was when building 32 bits and http-parser was only
built for 64 bits.
> Moving --without-secrets to 32 bits only gets me further:
>
32 bit version is required only for client files
(equivalent of the package sssd-client in fedora)
secret responder would not be built/installed there in case of multilib
Even though you woudl have installed 32 bit version of HTTP_PARSER
and libjansson.
> libtool: link: x86_64-pc-linux-gnu-gcc -Wall -Wshadow
-Wstrict-prototypes -Wpointer-arith -Wcast-qual
> -Wcast-align -Wwrite-strings -Wundef -Werror-implicit-function-declaration
-Winit-self -Wmissing-include-
> dirs -fno-strict-aliasing -std=gnu99 -O2 -pipe -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE
> -D_LARGEFILE64_SOURCE -Wl,-O1 -o .libs/sss_ssh_knownhostsproxy
src/sss_client/sss_ssh_knownhostsproxy-
> common.o src/sss_client/ssh/sss_ssh_knownhostsproxy-sss_ssh_client.o
> src/sss_client/ssh/sss_ssh_knownhostsproxy-sss_ssh_knownhostsproxy.o -Wl,-rpath
-Wl,/usr/lib64 -Wl,--as-
> needed ./.libs/libsss_util.so -L/usr/lib64 -lldb -ldbus-1 -lpcre
/usr/lib64/libini_config.so
> /usr/lib64/libpath_utils.so /usr/lib64/libbasicobjects.so /usr/lib64/libref_array.so
> /usr/lib64/libcollection.so /usr/lib64/libldap.so /usr/lib64/liblber.so -lresolv
-lsasl2 -lgnutls
> /usr/lib64/libgcrypt.so -lgpg-error -ltdb -lglib-2.0
/var/tmp/portage/sys-auth/sssd-1.14.1/work/sssd-1.14.1-
> abi_x86_64.amd64/.libs/libsss_child.so
/var/tmp/portage/sys-auth/sssd-1.14.1/work/sssd-1.14.1-
> abi_x86_64.amd64/.libs/libsss_cert.so
/var/tmp/portage/sys-auth/sssd-1.14.1/work/sssd-1.14.1-
> abi_x86_64.amd64/.libs/libsss_crypt.so ./.libs/libsss_crypt.so -lcrypto
./.libs/libsss_debug.so
> ./.libs/libsss_child.so -ltevent /usr/lib64/libdhash.so
/var/tmp/portage/sys-auth/sssd-1.14.1/work/sssd-
> 1.14.1-abi_x86_64.amd64/.libs/libsss_debug.so -lpthread -ltalloc -lpopt -Wl,-rpath
-Wl,/usr/lib64/sssd
> libtool: link: x86_64-pc-linux-gnu-gcc -Wall -Wshadow -Wstrict-prototypes
-Wpointer-arith -Wcast-qual
> -Wcast-align -Wwrite-strings -Wundef -Werror-implicit-function-declaration
-Winit-self -Wmissing-include-
> dirs -fno-strict-aliasing -std=gnu99 -O2 -pipe -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE
> -D_LARGEFILE64_SOURCE -Wl,-O1 -o .libs/sss_ssh_authorizedkeys
src/sss_client/sss_ssh_authorizedkeys-common.o
> src/sss_client/ssh/sss_ssh_authorizedkeys-sss_ssh_client.o
src/sss_client/ssh/sss_ssh_authorizedkeys-
> sss_ssh_authorizedkeys.o -Wl,-rpath -Wl,/usr/lib64 -Wl,--as-needed
./.libs/libsss_util.so -L/usr/lib64
> -lldb -ldbus-1 -lpcre /usr/lib64/libini_config.so /usr/lib64/libpath_utils.so
/usr/lib64/libbasicobjects.so
> /usr/lib64/libref_array.so /usr/lib64/libcollection.so /usr/lib64/libldap.so
/usr/lib64/liblber.so -lresolv
> -lsasl2 -lgnutls /usr/lib64/libgcrypt.so -lgpg-error -ltdb -lglib-2.0
/var/tmp/portage/sys-auth/sssd-
> 1.14.1/work/sssd-1.14.1-abi_x86_64.amd64/.libs/libsss_child.so
/var/tmp/portage/sys-auth/sssd-
> 1.14.1/work/sssd-1.14.1-abi_x86_64.amd64/.libs/libsss_cert.so
/var/tmp/portage/sys-auth/sssd-
> 1.14.1/work/sssd-1.14.1-abi_x86_64.amd64/.libs/libsss_crypt.so
./.libs/libsss_crypt.so -lcrypto
> ./.libs/libsss_debug.so ./.libs/libsss_child.so -ltevent /usr/lib64/libdhash.so
/var/tmp/portage/sys-
> auth/sssd-1.14.1/work/sssd-1.14.1-abi_x86_64.amd64/.libs/libsss_debug.so -lpthread
-ltalloc -lpopt -Wl,-
> rpath -Wl,/usr/lib64/sssd
> ./.libs/libsss_util.so: undefined reference to `timer_settime'
> ./.libs/libsss_util.so: undefined reference to `timer_delete'
> ./.libs/libsss_util.so: undefined reference to `timer_create'
> collect2: error: ld returned 1 exit status
>
>
And passing LIBS="-lrt" fixes the last error:
LIBS="-lrt" ebuild sssd-1.14.1.ebuild clean compile --skip-manifest
I hit this bug last week when I was testing different combinations
of linkers. Man timer_settime is clear that it need to be linked with -lrt
e.g.
TIMER_SETTIME(2) Linux Programmer's Manual TIMER_SETTIME(2)
NAME
timer_settime, timer_gettime - arm/disarm and fetch state of POSIX per-process
timer
SYNOPSIS
#include <time.h>
int timer_settime(timer_t timerid, int flags,
const struct itimerspec *new_value,
struct itimerspec *old_value);
int timer_gettime(timer_t timerid, struct itimerspec *curr_value);
Link with -lrt.
I just need to find portable way how to detect it.
LS