The net/samba48 (from both head and quarterly) now fails with: # samba-tool Traceback (most recent call last): File "/usr/local/bin/samba-tool", line 33, in <module> from samba.netcmd.main import cmd_sambatool File "/usr/local/lib/python2.7/site-packages/samba/__init__.py", line 28, in <module> import ldb ImportError: /usr/local/lib/python2.7/site-packages/ldb.so: Undefined symbol "ldb_handler_copy" The seems to be because ldb has become a "builtin" library in this port. The port from rev. 504590 works just fine.
I've made an attempt to debug/fix the problem. I failed to fix it, but here's what I've found (if that matters). Both pyldb and pyldb-util targets depend on ldb. But since pyldb also depends on pyldb-util (which in turn depends on ldb) WAF eventually removes the ldb dependency from the pyldb target. So ldb does not get builtin into pyldb (i.e. python/..../ldb.so). And pyldb-util (i.e. libpyldb-util.so) has a restricted set of exported symbols, and so even though the ldb lib gets builtin into the pyldb-util, all it's symbols are private, and thus "Undefined symbol" at runtime. A similar problem exists with talloc/pytallog/pytalloc-util. I tried removing abi_directory and abi_match parameters from the definitions of pyldb-util and pytalloc-util targets. With these changes, it becomes possible to run samba-tool without parameters. However if I attempt to, say, provision a new domain, it fails anyways, this time with some talloc related error.
I think I have a related problem. samba-tool without commands gives the help screen, buth with commands it fails: # samba-tool user list ldb: Unable to find backend for '/var/db/samba4/private/secrets.ldb' - do you need to set LDB_MODULES_PATH? Bad talloc magic value - unknown value Abort (core dumped) # samba-tool dbcheck Bad talloc magic value - unknown value Abort (core dumped) And my /var/log/messages is flooded with: Jul 28 11:00:26 defiant samba[25796]: [2019/07/28 11:00:26.890259, 0] ../lib/util/util_runcmd.c:327(samba_runcmd_io_handler) Jul 28 11:00:26 defiant samba[25796]: /usr/local/sbin/samba_spnupdate: Bad talloc magic value - unknown value Jul 28 11:00:26 defiant samba[25796]: [2019/07/28 11:00:26.923522, 0] ../source4/dsdb/dns/dns_update.c:353(dnsupdate_spnupdate_done) Jul 28 11:00:26 defiant kernel: pid 26018 (python2.7), jid 0, uid 0: exited on signal 6 (core dumped) Jul 28 11:00:26 defiant samba[25796]: ../source4/dsdb/dns/dns_update.c:352: Failed SPN update - with error code 6 Jul 28 11:00:26 defiant samba[25796]: [2019/07/28 11:00:26.935055, 0] ../lib/util/util_runcmd.c:327(samba_runcmd_io_handler) Jul 28 11:00:26 defiant samba[25796]: /usr/local/sbin/samba_dnsupdate: Bad talloc magic value - unknown value Jul 28 11:00:26 defiant samba[25796]: [2019/07/28 11:00:26.972835, 0] ../source4/dsdb/dns/dns_update.c:330(dnsupdate_nameupdate_done) Jul 28 11:00:26 defiant kernel: pid 26016 (python2.7), jid 0, uid 0: exited on signal 6 (core dumped) Jul 28 11:00:26 defiant samba[25796]: ../source4/dsdb/dns/dns_update.c:329: Failed DNS update - with error code 6 Jul 28 11:00:42 defiant samba[25794]: [2019/07/28 11:00:42.374380, 0] ../lib/util/util_runcmd.c:327(samba_runcmd_io_handler) Jul 28 11:00:42 defiant samba[25794]: /usr/local/sbin/samba_kcc: ldb: Unable to find backend for '/var/db/samba4/private/secrets.ldb' - do you need to set LDB_MODULES_PATH? Jul 28 11:00:42 defiant samba[25794]: [2019/07/28 11:00:42.381391, 0] ../lib/util/util_runcmd.c:327(samba_runcmd_io_handler) Jul 28 11:00:42 defiant samba[25794]: /usr/local/sbin/samba_kcc: Bad talloc magic value - unknown value Jul 28 11:00:42 defiant samba[25794]: [2019/07/28 11:00:42.418399, 0] ../source4/dsdb/kcc/kcc_periodic.c:693(samba_kcc_done) Jul 28 11:00:42 defiant kernel: pid 26020 (python2.7), jid 0, uid 0: exited on signal 6 (core dumped) Jul 28 11:00:42 defiant samba[25794]: ../source4/dsdb/kcc/kcc_periodic.c:692: Failed samba_kcc - NT_STATUS_UNSUCCESSFUL
Created attachment 206226 [details] Stop building in the libraries and install shared objects instead It's not clear the advantage of building in the bundled libraries- if we don't build them in but bundle the '.so's instead, this problem disappears. Timur, mind if I commit this? Would you prefer to remove the ldb and talloc manpages to avoid conflicts?
I'm going to commit this in a couple of days under timeout unless Timur has any objection.
I see you don't like the patch, which is your prerogative. What do you propose to do about these errors? At the moment Samba is unusable for me because of them.
(In reply to Chris Rees from comment #3) Chris, if you go through the developers archives you'll see that I've been asked by portmgr to make the port this way, as the way of building it with the legacy external libs was breaking some other ports... If you still want to built samba48 with external libs you need to set in the /etc/make.conf: SAMBA4_BUNDLED_TALLOC= no SAMBA4_BUNDLED_TEVENT= no SAMBA4_BUNDLED_TDB= no SAMBA4_BUNDLED_LDB= no I'm not happy with this solution, believe me, but taking into account that Samba 4.8 will be discontinued around September I prefer to drop the whole shebang with conflicts and just move on. It's a pity, as Samba 4.8 seems to be the only one ATM version that has working AD/DC, but I really hope that 4.10 will be fixed in this regards soon and will become default version for a while.
(In reply to Timur I. Bakeyev from comment #6) It has half-working AD/DC, to be precise. The samba-tool utility is broken, which mean you cannot even provision a new domain, nor fully manage the existing one.
(In reply to andriys from comment #7) I know, and working with iXsystems on the fix(please note, that ZFS provisioning patch is provided by them). Also, it seems that provisioning doesn't work properly with the bundled LDB, so it have to be set to external dependency. This I'm discussing with Samba team now... Sorry, all that migration to Python3 and new WAF with the attempt to co-exist with the existing legacy libs and ports created such a mess :(
(In reply to Timur I. Bakeyev from comment #8) So, if I understand this conversation correctly, there currently is no working AD/DC Samba version in ports? I tried the 4.10 but this gave problems so I had to revert to 4.8. I guess I have to be patient then.
(In reply to devries.arno from comment #9) I'm currently running 4.8.12_4 manually built from head rev.504590 on my DCs. My understanding is I'm stuck with this version until all the issues related to Python3 migration are resolved. You can do the same.
ports-mgmt/portdowngrade can help you with that :) Timur, I can't find the referenced conversation but I'm happy to believe that this wasn't your choice! I eagerly await a fixed 4.10, and thanks for all your work on it.
I installed the latest samba410 and all seems to be ok now. I think you can close this issue. Thanks for all the work.
net/samba48 expired today, is this relevant for net/samba410?
(In reply to Rene Ladan from comment #13) No, it is not (or, at least, not anymore). And I personally do not care about net/samba48 anymore either, so feel free to close this.