[SSSD-users] Slow convergence between sssd and windows 2008 r2 ad server

Paul Liljenberg liljenberg.paul at gmail.com
Wed May 14 08:55:08 UTC 2014

Replacing the binaries and libs was no issues in itself, The issue is that
it could not find the libs and even if i specifically pointed to the libdir
while configureing ie  ./configure --without-samba
--libdir=/usr/lib/x86_64-linux-gnu/sssd it still resulted in the following

root at client:~# dpkg -i test.deb
(Reading database ... 72929 files and directories currently installed.)
Preparing to replace sssd 1.8.4-2 (using test.deb) ...
Unpacking replacement sssd ...
Setting up sssd (1.8.4-2) ...
/usr/sbin/sssd: error while loading shared libraries: libsss_util.so:
cannot open shared object file: No such file or directory
[FAIL] Starting System Security Services Daemon: sssd failed!
Processing triggers for man-db ...

root at client:~/sssd- ldd /usr/sbin/sssd
        linux-vdso.so.1 =>  (0x00007fff9a1ff000)
        libtevent.so.0 => /usr/lib/x86_64-linux-gnu/libtevent.so.0
        libtalloc.so.2 => /usr/lib/x86_64-linux-gnu/libtalloc.so.2
        libpopt.so.0 => /lib/x86_64-linux-gnu/libpopt.so.0
        libldb.so.1 => /usr/lib/x86_64-linux-gnu/libldb.so.1
        libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3
        libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3
        libini_config.so.2 => /usr/lib/x86_64-linux-gnu/libini_config.so.2
        libcollection.so.2 => /usr/lib/x86_64-linux-gnu/libcollection.so.2
        libdhash.so.1 => /usr/lib/x86_64-linux-gnu/libdhash.so.1
        libnss3.so => /usr/lib/x86_64-linux-gnu/libnss3.so
        libnssutil3.so => /usr/lib/x86_64-linux-gnu/libnssutil3.so
        libsmime3.so => /usr/lib/x86_64-linux-gnu/libsmime3.so
        libssl3.so => /usr/lib/x86_64-linux-gnu/libssl3.so
        libplds4.so => /usr/lib/x86_64-linux-gnu/libplds4.so
        libplc4.so => /usr/lib/x86_64-linux-gnu/libplc4.so
        libnspr4.so => /usr/lib/x86_64-linux-gnu/libnspr4.so
        liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2
        libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
        libtdb.so.1 => /usr/lib/x86_64-linux-gnu/libtdb.so.1
        libsss_util.so => not found
        libsss_crypt.so => not found
        libsss_debug.so => not found
        libsss_child.so => not found
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fa5d22a3000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa5d1f18000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fa5d1af3000)
        libpath_utils.so.1 => /usr/lib/x86_64-linux-gnu/libpath_utils.so.1
        libref_array.so.1 => /usr/lib/x86_64-linux-gnu/libref_array.so.1
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fa5d14d4000)
        libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2
        libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2
        libgnutls.so.26 => /usr/lib/x86_64-linux-gnu/libgnutls.so.26
        libgcrypt.so.11 => /lib/x86_64-linux-gnu/libgcrypt.so.11
        libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1
        /lib64/ld-linux-x86-64.so.2 (0x00007fa5d4e46000)
        libtasn1.so.3 => /usr/lib/x86_64-linux-gnu/libtasn1.so.3
        libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0
        libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0

Note that the modules was located in the following folder.

root at client:~# ls /usr/lib/x86_64-linux-gnu/sssd/
libsss_ipa.so  libsss_krb5.so  libsss_ldap.so  libsss_proxy.so
 libsss_simple.so  libsss_util.so  modules

On Wed, May 14, 2014 at 8:57 AM, Lukas Slebodnik <lslebodn at redhat.com>wrote:

> On (14/05/14 08:20), Paul Liljenberg wrote:
> >The patch from Lukas did succeed very well on . You need to have
> >autotools installed to properly regenerate ./configure file. This is done
> >by "autoreconf -if"
> >before running configure. I have tested the compiled binary and that
> works.
> >What needs to be done now is to build a proper debian package for this.I
> >would try to use the
> >package from testing and replace the libs and binaries.
> It is very likely that  you will not be able to use the sssd package from
> debian testing. There will be strict dependency on newer version of
> libraries.
> It is not related to packaging but how linking of binaries works. You will
> need
> to install libraries from testing as well. As a result of this you will
> upgrade
> half of your system to debian testing.
>    e.g. libkrb5 ...
> I think you have two options:
>     * use your own sssd built from tarball + extra patch
>     * wait for official sssd-1.11 in wheezy-backports
> >If theres a more
> >Debian way please tell. Timo, do you have time for building this? I also
> >want to thank Lucas for
> >taking his time building a patch som it would be possible to have
> >in Debian stable without samba4-devel. Hopefully this would solve any
> >issues related to
> >active directory that i mentioned previous.
> >
> LS
> _______________________________________________
> sssd-users mailing list
> sssd-users at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Vänliga Hälsningar / Best Regards
Paul Liljenberg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/sssd-users/attachments/20140514/d676f7ce/attachment-0001.html>

More information about the sssd-users mailing list