Summary: | security/sssd: Update to 1.13.4 | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Ports & Packages | Reporter: | Rick <vrwmiller> | ||||||||||||||||||
Component: | Individual Port(s) | Assignee: | Steve Wills <swills> | ||||||||||||||||||
Status: | Closed Overcome By Events | ||||||||||||||||||||
Severity: | Affects Some People | CC: | Richard, beppo, carson, jcfyecrayz, joris.dedieu, jtrigg, karli.sjoberg, koobs, lukas.slebodnik, martymac, swills, timur | ||||||||||||||||||
Priority: | --- | Keywords: | needs-patch, needs-qa | ||||||||||||||||||
Version: | Latest | Flags: | lukas.slebodnik:
maintainer-feedback-
|
||||||||||||||||||
Hardware: | Any | ||||||||||||||||||||
OS: | Any | ||||||||||||||||||||
See Also: |
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239022 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241347 |
||||||||||||||||||||
Bug Depends on: | |||||||||||||||||||||
Bug Blocks: | 240708 | ||||||||||||||||||||
Attachments: |
|
Description
Rick
2019-06-10 18:56:05 UTC
See also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230705 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231846 Created attachment 205266 [details] [patch] update to 1.12.5 Here' a patch to update to 1.12.5 This takes sssd from the old 1.11.7 up one major to the latest 1.12 release. Next will be to update to 1.13.4 which is the latest in the long term maintenance (LTM) release series. I think the LTM series (now 1.13.*) should be the target for the security/sssd port for now. From the release info page: https://docs.pagure.org/SSSD.sssd/users/releases.html "Releases designated as LTM are long-term maintenance releases and will see bugfixes and security patches for a longer time than other releases." There is also a so-called "stable" release series. Search for "stable" on the home page: https://pagure.io/SSSD/sssd That might be a good candidate for a security/sssd-stable port. Alternately, security/sssd could be the "stable" flavor and there could be a security/sssd-ltm or security/sssd13. For now, let's good up to the LTM release at least. Then we can decide where to go from there. QA: - poudriere testport (11/amd64): ok - stage-qa & check-plist: ok - portlint (no new errors or warnings) ** To be helpful, please do some run testing. Just quick testing is fine since I will submit an update to 1.13.4 here soon. Change summary: - update 1.11.7 to 1.12.5 - use non-legacy tdb/ldb/talloc/tevent ports - pet portlint: move USES - put all /var/db paths in /var/db/sss/ (new: /var/db/sss/gpo_cache; move db/sss_mc -> db/sss/mc) - use --without-nfsv4-idmapd-plugin (NFSv4 idmapd function is different in freebsd - see nfsuserd). Future change can investigate integration with nfsuserd. For now, avoid build issues if it tries to include support for idmapd. - update startup script with new /var dirs. Add them to @dir cleanup list in pkg-plist. Remove the ${RMDIR} for them from Makefile (not needed). - update some of the patches to fix build errors (need LTLIBINTL for some build products, remove more cases of non-portable "timezone" global, catch up existing patches due to upstream code motion, etc.) - pkg-plist refresh to reflect changes (mostly man pages & docs; a couple new .so modules and two new .pc files) (In reply to John Hein from comment #2) The build testing above was done with default options (DOCS on, SMB off). I will also test with DOCS on, SMB on. To make that work, it will probably be better to point to the same default deps for tevent/tdb/talloc/ldb as the default samba port (samba48), so there will probably be a patch update for that. Created attachment 205271 [details] [patch] update to 1.12.5 [v2] (In reply to John Hein from comment #3) Tested with DOCS on & SMB on. Same QA results (all okay), but see [1]. Please do run testing. Updated patch to use the same default talloc/tdb/tevent/ldb ports as default samba port (samba48). [1] Note: For now (until bug 230705 is resolved), this ONLY works if you build samba without bundled ldb. You can do this as described in comment 8 of bug 230705. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230705#c8. Created attachment 205276 [details]
[patch] update to 1.12.5 [v3]
v2 of the 1.12.5 update patch was the wrong version (missed some plist entries for SMB on).
Created attachment 205304 [details] [patch] update to 1.13.4 Here's the update to 1.13.4 - on the current long term maintenance series of sssd. I didn't obsolete the 1.12.5 patch since that can still be applied for testing if you want to incrementally update from 1.11.7. But I think it's reasonable to commit the change from 1.11.7 to 1.13.4 and skip over 1.12.5. See previous comments regarding other versions (2.x). If you are an sssd user, please do run-time testing with this patch. Changes from the 1.12.5 patch include: - Set an option for python2 or python3. If both are installed and detected, it would require a more complicated plist. Instead add a radio option for either python2 or python3 (or neither), which defaults to python3 (matching the current ports default). - Disable PAC responder if SMB is off. It is part if Microsoft Active Directory [1] and needs samba. If you happen to have samba installed, but the SMB option off, sssd's configure will detect samba and try to build the PAC responder which will trigger stage-qa warnings. - Handle build errors for pysss.c (when building with python support [2]): In file included from src/python/pysss.c:27: In file included from ./src/util/util.h:51: ./src/util/util_errors.h:130:26: error: unknown type name 'errno_t' - plist updates. [1] For more info on PAC (Privilege Attribute Certificate): https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-pac/166d8064-c863-41e1-9c23-edaaa5f36962 https://jhrozek.wordpress.com/category/sssd/ [2] patch from bug filed upstream - https://pagure.io/SSSD/sssd/issue/4027 As with the 1.12.5 patch, if you want to build with SMB on, this still needs samba to be built without the bundled ldb, as in: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230705#c8 (In reply to John Hein from comment #6) QA for 1.13.4 patch: ... with various opt combinations: DOCS=on, SMB=on & off, PYTHON2=on, PYTHON3=on, PYTHON2/3=off - poudriere testport (11/amd64): ok - stage-qa & check-plist: ok - portlint (no new errors or warnings) (In reply to John Hein from comment #6) Thanks for this patch! Poudriere bulk builds security/sssd with this patch applied, SMB=on, and SAMBA4_BUNDLED_LDB=no via FreeBSD 11.2-RELEASE-p10. The package was tested by configuring the new repo on a SSSD-enabled system, removing packages that will conflict (samba46, tevent, talloc, tdb, ldb), and pkg upgrade -fy followed by a reboot. The system permitted console and ssh login authenticated through updated SSSD. sudo also functioned as expected w/ SSSD enabled. After samba48 was recently updated (to 4.8.12_3) in the past week or so, the workaround to build samba48 with SAMBA4_BUNDLED_LDB=no no longer works. See bug 230705, comment 14 and bug 230705, comment 17 (and bug 230705, comment 8). To support building sssd with SMB=on now, you need to revert samba48 to back 4.8.12_1 or we need to find a new fix to allow samba to coexist with an unbundled ldb. Currently build with SMB=on is broken even with this patch. pkg-static: samba48-4.8.12_3 conflicts with tdb1-1.3.16,1 (installs files into the same place). Problematic file: /usr/local/lib/python2.7/site-packages/tdb.so (In reply to Joris Dedieu from comment #10) Yep, samba48 broke this with ports r505764 and ports r505798 which were trying to reduce problems with conflicts. But they make the ldb conflict harder to work around. See bug 230705, comment 18 (which hints at a needed fix, but that might not be enough). (In reply to Joris Dedieu from comment #10) Mostly just a +1 here, wanting to upgrade samba from 4.6 since it's about to croak any day now. Please let me know if there's anything you want help testing or something, I'm all for it! Best Regards /K Hey again! No responses on testing anything yet but I can at least say that I'm doing alright now with samba410 after applying patch to sssd from 239022. My FreeBSD systems, both virtual and physical, including two AD DC are happy again. /K Patch needs updating (see comment 11). @John Re Python 2/3 support, port options for choosing this is not the standard/accepted method for Python version selection. Did you try to set/use USES=python (declaring that is supports "any" (2/3)version), and test with make.conf overrides: DEFAULT_VERSIONS=python=2.7|3.5 ? Just a +1 here. I am successfully running sssd 1.13.4 and samba410 in a small production environment. sssd 1.13.4 based on modified patch above with files/patch-src__monitor.c fix and using ldb15. samba410 was compiled with the following in make.conf: .if ${.CURDIR:M*/net/samba410} SAMBA4_BUNDLED_LDB= no .endif Only using LDAP, but no known problems so far. (In reply to Richard Frewin from comment #15) Comment #15 guided me to identify security/sssd builds [ from HEAD ] and functions as desired w/ Samba support given the configuration below, which upgrades Samba from 4.[678] to 4.10. This mitigates SSSD build failures w/ SMB=on, but fails to update the port to a more recent version. The attached patch should be ported to ports -HEAD. Updates to make.conf: DEFAULT_VERSIONS=samba=4.10 .if ${.CURDIR:M*/security/sssd} OPTIONS_FILE_SET+=SMB .endif .if ${.CURDIR:M*/net/samba410} OPTIONS_FILE_UNSET+=AD_DC SAMBA4_BUNDLED_LDB=no SAMBA4_BUNDLED_TALLOC=no SAMBA4_BUNDLED_TEVENT=no SAMBA4_BUNDLED_TDB=no .endif Updates to security/sssd/Makefile: diff --git a/security/sssd/Makefile b/security/sssd/Makefile index dddb1f6c2..265d9b818 100644 --- a/security/sssd/Makefile +++ b/security/sssd/Makefile @@ -17,7 +17,7 @@ LIB_DEPENDS= libpopt.so:devel/popt \ libtalloc.so:devel/talloc \ libtevent.so:devel/tevent \ libtdb.so:databases/tdb \ - libldb.so:databases/ldb14 \ + libldb.so:databases/ldb15 \ libcares.so:dns/c-ares \ libdbus-1.so:devel/dbus \ libdhash.so:devel/ding-libs \ Updates to security/sssd/files/patch-src__monitor__monitor.c: --- src/monitor/monitor.c.org 2019-07-14 23:45:13.760141000 +0200 +++ src/monitor/monitor.c 2019-07-14 23:58:50.715935000 +0200 @@ -2832,6 +2832,20 @@ ret = server_setup(MONITOR_NAME, flags, monitor->conf_path, &main_ctx); if (ret != EOK) return 2; + /* Use confd initialized in server_setup. ldb_tdb module (1.4.0) check PID + * of process which initialized db for locking purposes. + * Failed to unlock db: ../ldb_tdb/ldb_tdb.c:147: + * Reusing ldb opened by pid 28889 in process 28893 + */ + talloc_zfree(monitor->cdb); + monitor->cdb = main_ctx->confdb_ctx; + + ret = confdb_get_domains(monitor->cdb, &monitor->domains); + if (ret != EOK) { + DEBUG(SSSDBG_FATAL_FAILURE, "No domains configured.\n"); + return 4; + } + monitor->is_daemon = !opt_interactive; monitor->parent_pid = main_ctx->parent_pid; monitor->ev = main_ctx->event_ctx; Created attachment 208037 [details]
update to 1.13.4 with backported N_ELEMENTS
You can fix the N_ELEMENTS error by cherry picking upstream commits e32920a9c7 and e1ff063ffa. I've done that in the attached patch and it builds OK for me with Samba 4.10 with SAMBA4_BUNDLED_LDB=no. It does not build with Samba 4.8. I will try to fix that.
Created attachment 208044 [details]
Further updated patch
Not sure if this is sufficient, but this changes sssd to rely on samba 4.10 directly, rather than vary which samba is used based on the default version in Mk/bsd.default-versions.mk. This still relies on setting SAMBA4_BUNDLED_LDB to no when the SMB option is on in sssd. It also means that you can't use the current default samba, samba 4.8, at the same time as sssd. Again, not sure if this is OK, but wanted to propose it.
Thanks for the patch. It also requires the patch in bug #239022 to start sssd in daemon mode. I tested both patches, which apply cleanly, and sssd 1.13.4 w/ SMB=on builds with ldb15 and samba410 and functions as desired. Samba is installed here as a consequence of sssd. As long as it builds and functions as desired, Samba version is negligible. Samba 4.8 was EOLed on 2019-09-17, so you don't need to worry about it. From other side, Samba 4.11 will depend, guess what, on ldb 1.6, which will flip the board again. I'd rather stick the port to the original ldb package and let Samba and SSSD to coexist independently. That's the main reason, why ldb is now a bundled lib in Samba. (In reply to Timur I. Bakeyev from comment #20) > I'd rather stick the port to the original ldb package and let Samba and SSSD to coexist independently. That's the main reason, why ldb is now a bundled lib in Samba. Sorry, can you explain? I don't understand that this means. Why do you prefer bundling ldb? (In reply to Timur I. Bakeyev from comment #20) If I understand correctly, you suggest SAMBA4_BUNDLED_LDB=yes and DEFAULT_VERSIONS=samba=4.10 maintaining sssd's ldb14 dependency. I tried to build samba410 and sssd with this patch applied minus the ldb15 dependency instead using the original ldb14. The monitor.c patch was also applied. samba410 fails in package phase citing the error below. sssd is subsequently skipped. =========================================================================== =======================<phase: package >============================ ===> Building package for samba410-4.10.8 pkg-static: Unable to access file /wrkdirs/usr/ports/net/samba410/work/stage/usr/local/lib/samba4/private/libtalloc.so.2:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/net/samba410/work/stage/usr/local/man/man3/talloc.3.gz:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/net/samba410/work/stage/usr/local/lib/samba4/private/libtdb.so.1:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/net/samba410/work/stage/usr/local/lib/samba4/private/libtevent.so.0:No such file or directory *** Error code 1 Stop. make: stopped in /usr/ports/net/samba410 =>> Cleaning up wrkdir With this make.conf: DEFAULT_VERSION=samba=4.10 .if ${.CURDIR:M*/security/sssd} OPTIONS_FILE_SET+=SMB .endif .if ${.CURDIR:M*/net/samba4*} OPTIONS_FILE_UNSET+=AD_DC SAMBA4_BUNDLED_LDB=yes SAMBA4_BUNDLED_TALLOC=yes SAMBA4_BUNDLED_TEVENT=yes SAMBA4_BUNDLED_TDB=yes .endif security/sssd in its current form w/ SMB=on builds only with Samba 4.10 with SAMBA4_BUNDLED_LDB=yes. net/samba410 must be explicitly built prior to security/sssd as opposed to allowing LIB_DEPENDS to pull it in (via Poudriere bulk). Config below. This is a reasonable config for me which updates Samba from 4.[678] to 4.10. Now if sssd can get to a LTS version or better... :) The idea behind bundling ldb w/ Samba is -- since a) it's tightly coupled and b) it installs in a private lib dir -- sssd comes along and installs its own non-conflicting system ldb dependency, whatever version it may be (in this case ldb14). Might it be appropriate to propose security/sssd's ldb dependency default to the version depended upon by current default Samba into the future? This config produced the build: bulk_build.in: ... net/samba410 security/sssd ... make.conf: DEFAULT_VERSION=samba=4.10 .if ${.CURDIR:M*/net/samba4*} OPTIONS_FILE_UNSET+=AD_DC SAMBA4_BUNDLED_LDB=yes .endif .if ${.CURDIR:M*/security/sssd} OPTIONS_FILE_SET+=SMB .endif Created attachment 208374 [details]
patch to 1.13.4
This new patch reverts the LIB_DEPENDS ldb and Samba 4.10 changes in swills' patch and leaves the remainder in tact, which patches sssd to 1.13.4. Coupling this patch with the config described in comment #23 as well as the patch from bug #239022 has proven to build sssd w/ SMB=on and the appropriate dependencies particularly Samba 4.10 and was successfully tested. In other words, enabling security/sssd's SMB requires default samba=410 w/ SAMBA4_BUNDLED_LDB=yes and net/samba4* explicitly listed _above_ security/sssd in the Poudriere bulk file. sssd-1.13 branch should have been LTM in upstream but latest version 1.13.4 is 2.5 years old. I created another BZ241347 Closing, I think PR 241347 supersedes this. Hi, Well, just in case (as version 1.16.4 from PR #241347 does not seem to be ready), I've attached a patch that updates the port from current ports' version (1.11.7_20). That patch *includes* the patch from PR #239022 and allowed us to log-in using and OpenLDAP backend (it may need further testing though). Maybe it would be worth re-opening that PR and push that update before a more up-to-date version is ready ? Best regards, Ganael. Created attachment 216461 [details]
Patch against 1.11.7_20
|