Bug 230705 - net/samba48 conflicts with ldb from port
Summary: net/samba48 conflicts with ldb from port
Status: Closed Feedback Timeout
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Timur I. Bakeyev
Depends on:
Reported: 2018-08-17 13:37 UTC by Stefan Eßer
Modified: 2020-02-16 12:17 UTC (History)
15 users (show)

See Also:
bugzilla: maintainer-feedback? (timur)


Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Eßer freebsd_committer 2018-08-17 13:37:52 UTC
The recent upgrade of samba defines SAMBA4_BUNDLED_LDB and thus causes a conflict with ldb from ports that are required b some 10 packages on my system and thus cannot be de-installed. This problem does probably affect quite a number of people, which cannot upgrade Samba to a version without the security vulnerabilities that are fixed in this version.

The reason to use the bundled ldb appears to be, that the databases/ldb13 port has not been upgraded to version 1.3.5, yet.
Just changing the version number and creating a matching distinfo file was sufficient to get ldb13-1.3.5 compiled and working.

So, I do not see any reason that the samba48 port could not continue to use the ldb13 from a port and thus avoid the conflict!
(I'm CCing to timur@ as the registered maintainer of the ldb13 port.)

The same problem may exist for the other samba4* ports, I did not check ...
Comment 1 Timur I. Bakeyev freebsd_committer 2018-08-17 13:45:12 UTC
(In reply to Stefan Esser from comment #0)

Hi, Stefan!

Can you please, show which other packages are dependent on LDB? Besides (obsoleted) sssd I can't come with any other.

The reasons to switch form external to internal dependency are:

* Samba developers say that interdependence between LDB and Samba is too tight, it's safer to keep them together.

* Upcoming Samba 4.9 depends on, guess, what? LDB 1.4.1.

* There is new LDB 1.5.1 already being released as well.

So, in short time we went from 1.1 -> 1.2 -> 1.3 -> 1.4 -> 1.5 versions, so each Samba upgrade requires de-installing older LDB and installing newer one, which seems to be a hassle.

I'm open to the suggestions how to handle this situation more gracefully, so far removing external LDB dependency looked the best.
Comment 2 Timur I. Bakeyev freebsd_committer 2018-08-17 21:48:51 UTC
Another option could be to make it a CONFIG switch...
Comment 3 Timur I. Bakeyev freebsd_committer 2018-08-17 23:06:48 UTC
# pkg rquery %ro ldb
# pkg rquery %ro ldb12
# pkg rquery %ro ldb13
I don't see any other dependent ports?
Comment 4 Dutchman01 2018-08-23 13:13:44 UTC
i vote for CONFIG switch too
Comment 5 Rick 2018-09-20 19:02:29 UTC
(In reply to Timur I. Bakeyev from comment #1)

Can you clarify the meaning of "Besides (obsoleted) sssd I can't come with any other"? What is meant by "(obseleted)"? Is the message that SSSD is obseleted for some reason?

This behavior is also observed when building SSSD and dependencies w/ a portsnap from today (20180920) in a FreeBSD 11.2 jail. SSSD installs the ldb dependency at v1.1; Samba47 later complains about a conflict because Samba47 requires ldb 1.2 instead.

===>   sssd-1.11.7_14 depends on shared library: libsmbclient.so - not found
===>   Installing existing package /packages/All/samba47-4.7.10.txz
[112R-amd64-v20180920-job-02] Installing samba47-4.7.10...
[112R-amd64-v20180920-job-02] `-- Installing cmocka-1.1.1_1...
[112R-amd64-v20180920-job-02] `-- Extracting cmocka-1.1.1_1: .......... done
[112R-amd64-v20180920-job-02] `-- Installing gamin-0.1.10_9...
[112R-amd64-v20180920-job-02] |   `-- Installing glib-2.50.3_5,1...
[112R-amd64-v20180920-job-02] |   | `-- Installing libiconv-1.14_11...
[112R-amd64-v20180920-job-02] |   | `-- Extracting libiconv-1.14_11: .......... done
[112R-amd64-v20180920-job-02] |   `-- Extracting glib-2.50.3_5,1: .......... done
No schema files found: doing nothing.
[112R-amd64-v20180920-job-02] `-- Extracting gamin-0.1.10_9: .......... done
[112R-amd64-v20180920-job-02] `-- Installing gnutls-3.5.19...
[112R-amd64-v20180920-job-02] |   `-- Installing ca_root_nss-3.39...
[112R-amd64-v20180920-job-02] |   `-- Extracting ca_root_nss-3.39: ........ done
[112R-amd64-v20180920-job-02] |   `-- Installing gmp-6.1.2...
[112R-amd64-v20180920-job-02] |   `-- Extracting gmp-6.1.2: .......... done
[112R-amd64-v20180920-job-02] |   `-- Installing libidn2-2.0.5...
[112R-amd64-v20180920-job-02] |   `-- Extracting libidn2-2.0.5: .......... done
[112R-amd64-v20180920-job-02] |   `-- Installing libtasn1-4.13...
[112R-amd64-v20180920-job-02] |   `-- Extracting libtasn1-4.13: .......... done
[112R-amd64-v20180920-job-02] |   `-- Installing nettle-3.4...
[112R-amd64-v20180920-job-02] |   `-- Extracting nettle-3.4: .......... done
[112R-amd64-v20180920-job-02] |   `-- Installing p11-kit-0.23.14...
[112R-amd64-v20180920-job-02] |   `-- Extracting p11-kit-0.23.14: .......... done
[112R-amd64-v20180920-job-02] |   `-- Installing trousers-0.3.14_2...
[112R-amd64-v20180920-job-02] |   | `-- Installing tpm-emulator-0.7.4_2...
===> Creating groups.
Creating group '_tss' with gid '601'.
===> Creating users
Creating user '_tss' with uid '601'.
[112R-amd64-v20180920-job-02] |   | `-- Extracting tpm-emulator-0.7.4_2: ......... done
===> Creating groups.
Using existing group '_tss'.
===> Creating users
Using existing user '_tss'.
[112R-amd64-v20180920-job-02] |   `-- Extracting trousers-0.3.14_2: .......... done
[112R-amd64-v20180920-job-02] `-- Extracting gnutls-3.5.19: .......... done
[112R-amd64-v20180920-job-02] `-- Installing jansson-2.11...
[112R-amd64-v20180920-job-02] `-- Extracting jansson-2.11: .......... done
[112R-amd64-v20180920-job-02] `-- Installing libarchive-3.3.2_1,1...
[112R-amd64-v20180920-job-02] |   `-- Installing liblz4-1.8.3,1...
[112R-amd64-v20180920-job-02] |   `-- Extracting liblz4-1.8.3,1: .......... done
[112R-amd64-v20180920-job-02] |   `-- Installing lzo2-2.10_1...
[112R-amd64-v20180920-job-02] |   `-- Extracting lzo2-2.10_1: .......... done
[112R-amd64-v20180920-job-02] `-- Extracting libarchive-3.3.2_1,1: .......... done
[112R-amd64-v20180920-job-02] `-- Installing libsunacl-1.0.1...
[112R-amd64-v20180920-job-02] `-- Extracting libsunacl-1.0.1: ....... done
[112R-amd64-v20180920-job-02] `-- Installing py27-dnspython-1.15.0...
[112R-amd64-v20180920-job-02] `-- Extracting py27-dnspython-1.15.0: .......... done
[112R-amd64-v20180920-job-02] `-- Installing py27-iso8601-0.1.11...
[112R-amd64-v20180920-job-02] `-- Extracting py27-iso8601-0.1.11: .......... done
pkg-static: samba47-4.7.10 conflicts with ldb-1.1.29_2 (installs files into the same place).  Problematic file: /usr/local/bin/ldbadd

Failed to install the following 1 package(s): /packages/All/samba47-4.7.10.txz
Comment 6 Timur I. Bakeyev freebsd_committer 2018-09-20 19:44:28 UTC
Well, upstream sssd passed 1.16(or even 1.18) and reached 2.0 version. 1.11 is... Old. As well as it's dependency on ldb 1.1, which, as you correctly stated conflicts even with samba47 dependency on ldb12. Newer versions of Samba require even newer versions of ldb, 1.3 for 4.8, 1.4 for 4.9 and now there is ldb 1.5 already waits for Samba 4.10.

So, there is no clean way to combine those with the external ldb. From other side, I'm pretty sure that sssd uses some Samba libs for it's related module(s) and doesn't explicitly need LDB for itself.

So, if sssd will ever be updated to the latest and greatest, having ldb as a part of Samba (libs) internal dependency actually would help to have both packages on one system.

For now if you need sssd you are bounded to samba46 - or can manually fix the dependency in sssd to ldb12|3, but there is no guaranty that everything would work properly...
Comment 7 amendlik 2018-10-11 14:58:29 UTC
Changing the dependency to another version of LDB does not fix the problem:

pkg-static: samba47-4.7.10_1 conflicts with ldb12-1.2.3 (installs files into the same place).  Problematic file: /usr/local/bin/ldbadd

It is not so much an incompatibility between versions of LDB. The problem is that the ldb* and samba* are both required by sssd when the SMB option is set. The ldb* package and the bundled LDB that comes with samba* place the same files in the same location.

One solution to this could be to eliminate the dependency on LDB when the SMB option is set for sssd. In other words, if Samba is included as a dependency, do not require the ldb* package (use the bundled LDB).

Comment 8 Felix Palmen 2019-04-10 08:06:54 UTC
> One solution to this could be to eliminate the dependency on LDB when the
> SMB option is set for sssd.

This will NOT work, because samba puts the lib in a private library directory and doesn't install any headers ...

FWIW, I have a successful build here with samba48 and sssd -- will see whether it's running stable as well.

First you have to force samba48 to build with the external ldb by putting this in make.conf:

.if ${.CURDIR:M*/net/samba48}

Then, change the dependency in security/sssd/Makefile from databases/ldb to databases/ldb13. If you build samba with a different version of bind, change that dependency as well.
Comment 9 Elias Ohm 2019-05-12 18:09:29 UTC
I see the issue is still unhandled.

I do  not understand the point why not
- eighther the samba4 can make it's ldb at a very specific Version completely private (prefixing the binaries with samba- for example or moving them into a dedicated dir)
- or at the samba4 can make it's ldb public (installing all the headers and libs etc. that ldb package intalls otherwise) [it's a bit less optimal as so no other ldb version can be installed next to samba, but on the other Hand if really nobody use it without samba…]
- or at least the ldb13 port can be kept up-to-date or in sync with the sambas ldb versions for the users that want or hsave to install both (and Building samba with the options for separate installed ldb)

And also I do not understand why it should harm to always use ldb from the separate port but just requiring same version (so making ldb Kind of subpackage of samba4).
Comment 10 Dutchman01 2019-05-12 19:13:02 UTC
(In reply to Elias Ohm from comment #9)

ldb13 port needs a new update too, Timor is aware of CVE for current version.
I don't know when he update the ldb ports to upstream versions.

Right now ldb13 port is incompatible with current version of samba!
Comment 11 John Hein 2019-06-21 16:43:34 UTC
See also sssd update:

This will try to accomodate the various conflicts for tevent/talloc/tdb/ldb consumers.
Comment 12 John Hein 2019-06-21 19:23:40 UTC
(In reply to Timur I. Bakeyev from comment #6)

In bug 238465, I am shooting for updating sssd to 1.13.4 which is currently the long term maintenance release.

It works fine if the SMB option is off (as discussed in this bug), of course.

But no matter the version of sssd, they all build with various flavors of ldb.  It seems to me that sssd needs the ldb lib, but not the tools.

As soon as the sssd SMB option is turned on, we currently hit the conflict problem (unless samba is built with the non-bundled ldb), of course.  It's probably marginally okay to just leave SMB off for sssd in the short term (doesn't help the subset of users who want sssd+samba) and let SMB=on sit broken while we figure out the best way forward.

As far as I can tell, the leading options seem to be:

 - split databases/ldb to ldb-tools & ldb-lib (debian does this).  I believe sssd only needs the lib.

 - make the conflicting pieces installed by samba ports fully private to samba (as suggested in comment 9)

 - modify sssd to bundle ldb itself

 - (or some combination of the above?)

As ldb* & samba* maintainer, do you have a preference?

It's not clear why ldb should be bundled by samba48 by default.  I suspect there's a good reason, but I haven't been able to find it.  If it's bundled just to adhere to upstream recommendations, that's a good enough reason (as you mention in comment 1).  If so, I think we should split out databases/ldb* to databases/ldb*-lib and have sssd depend on that.

Also making the samba bundled versions of the bin/ldb* tools private _seems_ reasonable, but I have not tracked down how/if the bin/ldb* tools are invoked by samba internally (or if they are just for the convenience of the user).  I need more information there to be able to have a more informed opinion.
Comment 13 Timur I. Bakeyev freebsd_committer 2019-06-22 09:03:27 UTC
As I was petting Samba4.9-10 for quite long, I, seems, forgot that I've added the patch which, indeed, rename ldb tools into samba-ldb* ones.

That should decouple Samba from LDB dependency and will let it live it's own life.

Still, need to find how to deal with all those ldb1[2-6] ports, as this is a constantly moving target.

Maybe, turn ldb port into meta-port which will track latest(?) LDB version.
Comment 14 John Hein 2019-07-07 04:36:51 UTC
Latest samba48 commit message (samba48-4.8.12_3) says it won't conflict with talloc/tevent/tdb, but it still has trouble with ldb.  And now whether it's bundled or not, it fails if an ldb is installed.

If SAMBA4_BUNDLED_LDB=yes and an ldb port is already installed, package installation fails:

===>   Registering installation for samba48-4.8.12_3
pkg-static: samba48-4.8.12_3 conflicts with ldb14-1.4.4_1 (installs files into the same place).  Problematic file: /usr/local/lib/python2.7/site-packages/ldb.so

If SAMBA4_BUNDLED_LDB=no, configure fails:

Checking for Python version >= 2.4.2                        : ok 2.7.16
Checking for python headers                                 : using cache
ERROR: Use of system library ldb depends on missing system library/libraries ['talloc', 'tdb', 'tevent', 'pyldb-util']
Compiling with Intel AES instructions
===>  Script "configure" failed unexpectedly.

Is there a combination of bundled and unbundled talloc/tevent/tdb/ldb ports that is supposed to work with the current version of the samba48 port?  I didn't see any combination except SAMBA4_BUNDLED_LDB=yes and no ldb port installed.  And then you can't build other ports that depend on any databases/ldb* port.
Comment 15 Elias Ohm 2019-07-07 17:54:46 UTC
(In reply to Timur I. Bakeyev from comment #13)
I think that is the simplest / best approach if You want to have the bundled version more or less enforces. And if You already have the patch in place to rename the stuff it's not a big deal. (Also the python ldb library needs to be thought about I assume.)
Comment 16 Elias Ohm 2019-07-07 18:02:00 UTC
(In reply to John Hein from comment #14)
Yes there is was "no way" to install samba48 port with a ldb from ports because the recent version of ldb 1.3 matching the requirements of samba48 is not availables (there is a quite strict version check in configure scripts).

I decided to stick with samba47 until there is a proper solution (at least a ldb port with matching version) available or take care for that later.
With samba47 I could finally install along with ldb ldb12-1.2.3_1.

That was the point why I'm looking at this issue..
Comment 17 John Hein 2019-07-08 12:28:27 UTC
(In reply to Elias Ohm from comment #16)
Before the recent changes, it was possible.  You could install databases/ldb13 and then build and install net/samba48 without the bundled ldb (which is nearly identical to unbundled databases/ldb13 except a patch for some code used for testing).  This was useful for other ports that were dependent on a flavor of databases/ldb*.  You could do this with samba-4.8.12_1 if SAMBA4_BUNDLED_LDB=no and all other BUNDLED settings at the then default values.  Now (with PORTREVISION=3) that is failing as described in comment 14.

Even if you install databases/ldb13 and then build net/samba48 with the talloc/tevent/tdb SAMBA4_BUNDLED_* settings to no (as they were in samba-4.8.12_1), it still fails when you build with SAMBA4_BUNDLED_LDB=no now with 4.8.12_3 (this is a new failing combination to add to comment 14).  This seems to be an impasse now which prevents samba48 and any flavor of databases/ldb* from being installed together.  As far as I can see, now you have to revert to 4.8.12_1 or we need to find an update to 4.8.12_3 to resolve this problem and allow building samba with an installed databases/ldb. 

See also the discussion in bug 238465
Comment 18 John Hein 2019-07-08 13:08:57 UTC
(In reply to John Hein from comment #17)
I think this might be the right fix:

--- Makefile    (revision 506209)
+++ Makefile    (working copy)
@@ -418,7 +418,7 @@
 SAMBA4_BUNDLED_LIBS+=          pytdb

-.if !defined(SAMBA4_BUNDLED_LDB)
+.if !defined(SAMBA4_BUNDLED_LDB) || ${SAMBA4_BUNDLED_LDB} == no
 SAMBA4_BUNDLED_LIBS+=          !pyldb !pyldb-util
 SAMBA4_BUNDLED_LIBS+=          pyldb pyldb-util

I am running some builds to check.
Comment 19 Jim Trigg 2019-09-11 01:39:03 UTC
Any news? I'm running into this as well, trying to get a FreeBSD system subscribed to a FreeIPA instance I've set up.
Comment 20 Adam Strohl 2019-10-23 15:06:28 UTC
I second this, it is causing a lot of problems.  The one we've hit is that it prevents the "sudo" and "samba" packages from being installed on the same machine.
Comment 21 Rick 2019-10-23 16:33:09 UTC
security/sssd experiences these problems. bug #238465, comment #23 describes a config that allows sssd to build w/ net/samba410 as opposed to net/samba48. It may also help resolve conflicts in other ports.
Comment 22 Rene Ladan freebsd_committer 2019-12-15 17:23:12 UTC
net/samba48 expired today, is this relevant for net/samba410?
Comment 23 Rene Ladan freebsd_committer 2020-02-16 12:17:06 UTC
databases/{ldb,ldb12,ldb13} expired today and feedback timeout.