Bug 230705
| Summary: | net/samba48 conflicts with ldb from port | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Stefan Eßer <se> |
| Component: | Individual Port(s) | Assignee: | Timur I. Bakeyev <timur> |
| Status: | Closed Feedback Timeout | ||
| Severity: | Affects Some People | CC: | adam.strohl-fbsd, amendlik, carson, dutchman01, grahamperrin, info, jcfyecrayz, jtrigg, ml, rene, se, swills, timur, vrwmiller, zirias |
| Priority: | --- | Flags: | bugzilla:
maintainer-feedback?
(timur) |
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Stefan Eßer
2018-08-17 13:37:52 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. Another option could be to make it a CONFIG switch... # pkg rquery %ro ldb net/samba46 security/sssd # pkg rquery %ro ldb12 net/samba47 # pkg rquery %ro ldb13 net/samba48 I don't see any other dependent ports? i vote for CONFIG switch too (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 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... 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). Thoughts? > 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}
SAMBA4_BUNDLED_LDB= no
.endif
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.
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). (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! See also sssd update: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238465 This will try to accomodate the various conflicts for tevent/talloc/tdb/ldb consumers. (In reply to Timur I. Bakeyev from comment #6) Timur, 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. 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. 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. (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.) (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.. (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 (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 .endif -.if !defined(SAMBA4_BUNDLED_LDB) +.if !defined(SAMBA4_BUNDLED_LDB) || ${SAMBA4_BUNDLED_LDB} == no SAMBA4_BUNDLED_LIBS+= !pyldb !pyldb-util .else SAMBA4_BUNDLED_LIBS+= pyldb pyldb-util I am running some builds to check. Any news? I'm running into this as well, trying to get a FreeBSD system subscribed to a FreeIPA instance I've set up. 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. 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. net/samba48 expired today, is this relevant for net/samba410? databases/{ldb,ldb12,ldb13} expired today and feedback timeout.
|