On Sat, 18 May 2019, Nico Kadel-Garcia wrote:> On Wed, May 15, 2019 at 4:32 PM Tom Diehl via samba > <samba at lists.samba.org> wrote: >> >> Hi, >> >> I have a new Centos 7.6 VM that I self compiled 4.10.3 and joined it to an >> existing samba AD domain that has 2 existing DCs. One of the existing DCs is >> running 4.8.7 and the other is running 4.7.7. Everything looks OK except >> that when I run samba-tool drs showrepl on the new DC (VDC4) I get the >> following output: > > "self-compiled" can include a lot of sins, especially if trying to > place it alongside *or* in place of the provided libraries for tevent, > ldb, tdb, and talloc. Let me point you to my git repo,Well OK maybe I should have said self compiled using the instructions @ https://wiki.samba.org/index.php/Build_Samba_from_Source#configure and the package list from https://wiki.samba.org/index.php/Package_Dependencies_Required_to_Build_Samba#Red_Hat_Enterprise_Linux_7_.2F_CentOS_7_.2F_Scientific_Linux_7 substituting python36-devel for python-devel and adding python32-dns to get the samba-tool dns module to work. None of the distro samba packages are installed. TBH, I am guessng about the package list given the change from python2 to python3 as it does not look like the wiki has been updated for 4.10.x.> https:/github.com/nkadel/samba4repo/, with submodules for samba > itself, talloc, tevent, etc., etc. It's built to use the official > upstream tarballs from www.samba.org, not tarballs from *me*, and that > also will give you a good git repo you can use to manage any > compilation options in the ".spec" file.Is there a way to only build the Centos bits using your git repo? I have no Fedora machines and so far I have not been successful in getting the above to build on a Centos 7 VM using the version of Mock supplied by the Centos project.> >> I see errors similar to below in the logs: >> [2019/05/15 16:19:58.683401, 2] ../../source4/rpc_server/drsuapi/getncchanges.c:1765(getncchanges_collect_objects) >> ../../source4/rpc_server/drsuapi/getncchanges.c:1765: getncchanges on DC=DomainDnsZones,DC=kmg,DC=mydomain,DC=com using filter (uSNChanged>=29465) >> [2019/05/15 16:19:58.695818, 2] ../../source4/rpc_server/drsuapi/getncchanges.c:3619(dcesrv_drsuapi_DsGetNCChanges) >> DsGetNCChanges with uSNChanged >= 29465 flags 0x80000064 on <GUID=e9fe6598-6cfe-40dd-b882-33c6bc031517>;DC=DomainDnsZones,DC=kmg,DC=mydomain,DC=com gave 2 objects (done 2/2) 0 links (done 0/0 (as S-1-5-21-3052942767-4183929206-737583365-1279)) >> [2019/05/15 16:20:01.245656, 2] ../../source4/dsdb/repl/replicated_objects.c:1061(dsdb_replicated_objects_commit) >> Replicated 0 objects (0 linked attributes) for DC=DomainDnsZones,DC=kmg,DC=mydomain,DC=com >> [2019/05/15 16:20:06.260687, 2] ../../source4/dsdb/repl/replicated_objects.c:1061(dsdb_replicated_objects_commit) >> Replicated 2 objects (0 linked attributes) for DC=DomainDnsZones,DC=kmg,DC=mydomain,DC=com >> [2019/05/15 16:20:06.271512, 0] ../../source4/dsdb/repl/drepl_out_helpers.c:1158(dreplsrv_update_refs_done) >> UpdateRefs failed with WERR_DS_DRA_ACCESS_DENIED/NT code 0xc0002105 for a57c74ed-3343-4497-965d-e7e50a1f84ae._msdcs.kmg.mydomain.com DC=DomainDnsZones,DC=kmg,DC=mydomain,DC=com >> [2019/05/15 16:20:08.692911, 2] ../../source4/rpc_server/drsuapi/getncchanges.c:1765(getncchanges_collect_objects) >> ../../source4/rpc_server/drsuapi/getncchanges.c:1765: getncchanges on DC=DomainDnsZones,DC=kmg,DC=mydomain,DC=com using filter (uSNChanged>=29467) >> >> Given the above errors this looks like a permissions problem but so far I have not >> been able to find it. > > Hmm. some classic questions include "is SELinux on", and "which > Kerberos did you use, the supported internal Heimdal Kerberos or the > experimental support for MIT kerberos?SELinux is in permissive and my configure line is simply ./configure so no MIT here. IMO no one in their right mind would try to use MIT in production. Regards, -- Tom me at tdiehl.org
vincent at cojot.name
2019-May-20 21:34 UTC
[Samba] self compiled 4.10.3 replication failure.
On Mon, 20 May 2019, Tom Diehl via samba wrote:> On Sat, 18 May 2019, Nico Kadel-Garcia wrote: > > Well OK maybe I should have said self compiled using the instructions @ > https://wiki.samba.org/index.php/Build_Samba_from_Source#configure and > the package list from > https://wiki.samba.org/index.php/Package_Dependencies_Required_to_Build_Samba#Red_Hat_Enterprise_Linux_7_.2F_CentOS_7_.2F_Scientific_Linux_7 > substituting python36-devel for python-devel and adding python32-dns > to get the samba-tool dns module to work. None of the distro samba packages > are installed.On the other hand, since python3 is a 'foreign' passenger to RHEL7, if you just wanted Samba 4.10.x on el7/centos7, it would be much simplier to just consume the python2 system default. This is what I'm doing on el7 to build without EPEL: http://nova.polymtl.ca/~coyote/dist/samba/samba-4.10.3/RHEL7/SPECS/samba-v410x.spec ----------------------------------------- %if 0%{?fedora} || 0%{?rhel} > 7 %global with_python3 1 %else %global with_python3 0 %endif ----------------------------------------- And 'samba-tool' dns seems to work fine (for me) on python2. To be honnest, the only major change I saw in the compile process for 4.10.x was that one of the required library updates depended on a more recent make of cmake3 (for which I am now providing as SPEC and src.rpm from the above repo as well). But aside from that, the process was mostly a matter of updating tdb,talloc,ldb,tevent and friends. Vincent
On Mon, 20 May 2019, Vincent S. Cojot via samba wrote:> > On Mon, 20 May 2019, Tom Diehl via samba wrote: > >> On Sat, 18 May 2019, Nico Kadel-Garcia wrote: >> >> Well OK maybe I should have said self compiled using the instructions @ >> https://wiki.samba.org/index.php/Build_Samba_from_Source#configure and >> the package list from >> https://wiki.samba.org/index.php/Package_Dependencies_Required_to_Build_Samba#Red_Hat_Enterprise_Linux_7_.2F_CentOS_7_.2F_Scientific_Linux_7 >> substituting python36-devel for python-devel and adding python32-dns >> to get the samba-tool dns module to work. None of the distro samba >> packages are installed. > > On the other hand, since python3 is a 'foreign' passenger to RHEL7, if you > just wanted Samba 4.10.x on el7/centos7, it would be much simplier to just > consume the python2 system default. This is what I'm doing on el7 to build > without EPEL: > http://nova.polymtl.ca/~coyote/dist/samba/samba-4.10.3/RHEL7/SPECS/samba-v410x.spec > ----------------------------------------- > % if 0%{?fedora} || 0%{?rhel} > 7 > % global with_python3 1 > % else > % global with_python3 0 > % endif > -----------------------------------------So what happens when 4.11 is released? The release notes clearly state that 4.11 will not have python2 support. Doing as you suggest only kicks the can down the road. My gut feeling is if I am going to stay with python2 I might as well stay with 4.9. Honestly I would rather get this sorted out sooner than later unless of course someone from the samba team says I am wasting my time. At this point in time, I am not even sure my problem is related to the build. I suspect the build is just fine but there is something else in play. The problem is that there is nothing useful I can find in Google and so far no one has thought of anything else to try troubleshoot the problem. Different strokes for different folks suppose. :-) Given that I have been running self compiled versions of samba in production since 4.7.0 I am inclined to continue down that road. I agree that rpms might be better but ansible does a great job ensuring I build all of my DC's the same way each and every time. Regards, -- Tom me at tdiehl.org
On Mon, May 20, 2019 at 3:33 PM <me at tdiehl.org> wrote:> > On Sat, 18 May 2019, Nico Kadel-Garcia wrote: > > > On Wed, May 15, 2019 at 4:32 PM Tom Diehl via samba > > <samba at lists.samba.org> wrote: > >> > >> Hi, > >> > >> I have a new Centos 7.6 VM that I self compiled 4.10.3 and joined it to an > >> existing samba AD domain that has 2 existing DCs. One of the existing DCs is > >> running 4.8.7 and the other is running 4.7.7. Everything looks OK except > >> that when I run samba-tool drs showrepl on the new DC (VDC4) I get the > >> following output: > > > > "self-compiled" can include a lot of sins, especially if trying to > > place it alongside *or* in place of the provided libraries for tevent, > > ldb, tdb, and talloc. Let me point you to my git repo, > > Well OK maybe I should have said self compiled using the instructions > @ https://wiki.samba.org/index.php/Build_Samba_from_Source#configure and > the package list from https://wiki.samba.org/index.php/Package_Dependencies_Required_to_Build_Samba#Red_Hat_Enterprise_Linux_7_.2F_CentOS_7_.2F_Scientific_Linux_7 > substituting python36-devel for python-devel and adding python32-dns > to get the samba-tool dns module to work. > None of the distro samba packages are installed. > > TBH, I am guessng about the package list given the change from python2 to python3 > as it does not look like the wiki has been updated for 4.10.x. > > > https:/github.com/nkadel/samba4repo/, with submodules for samba > > itself, talloc, tevent, etc., etc. It's built to use the official > > upstream tarballs from www.samba.org, not tarballs from *me*, and that > > also will give you a good git repo you can use to manage any > > compilation options in the ".spec" file. > > Is there a way to only build the Centos bits using your git repo? I have no > Fedora machines and so far I have not been successful in getting the above > to build on a Centos 7 VM using the version of Mock supplied by the Centos > project.Yeah. Comment out the other operating systems in the Makefiles. Install the dependencies, as RPMs, in order. The order in the top level Makefile should get you through the process.> >> I see errors similar to below in the logs: > >> [2019/05/15 16:19:58.683401, 2] ../../source4/rpc_server/drsuapi/getncchanges.c:1765(getncchanges_collect_objects) > >> ../../source4/rpc_server/drsuapi/getncchanges.c:1765: getncchanges on DC=DomainDnsZones,DC=kmg,DC=mydomain,DC=com using filter (uSNChanged>=29465) > >> [2019/05/15 16:19:58.695818, 2] ../../source4/rpc_server/drsuapi/getncchanges.c:3619(dcesrv_drsuapi_DsGetNCChanges) > >> DsGetNCChanges with uSNChanged >= 29465 flags 0x80000064 on <GUID=e9fe6598-6cfe-40dd-b882-33c6bc031517>;DC=DomainDnsZones,DC=kmg,DC=mydomain,DC=com gave 2 objects (done 2/2) 0 links (done 0/0 (as S-1-5-21-3052942767-4183929206-737583365-1279)) > >> [2019/05/15 16:20:01.245656, 2] ../../source4/dsdb/repl/replicated_objects.c:1061(dsdb_replicated_objects_commit) > >> Replicated 0 objects (0 linked attributes) for DC=DomainDnsZones,DC=kmg,DC=mydomain,DC=com > >> [2019/05/15 16:20:06.260687, 2] ../../source4/dsdb/repl/replicated_objects.c:1061(dsdb_replicated_objects_commit) > >> Replicated 2 objects (0 linked attributes) for DC=DomainDnsZones,DC=kmg,DC=mydomain,DC=com > >> [2019/05/15 16:20:06.271512, 0] ../../source4/dsdb/repl/drepl_out_helpers.c:1158(dreplsrv_update_refs_done) > >> UpdateRefs failed with WERR_DS_DRA_ACCESS_DENIED/NT code 0xc0002105 for a57c74ed-3343-4497-965d-e7e50a1f84ae._msdcs.kmg.mydomain.com DC=DomainDnsZones,DC=kmg,DC=mydomain,DC=com > >> [2019/05/15 16:20:08.692911, 2] ../../source4/rpc_server/drsuapi/getncchanges.c:1765(getncchanges_collect_objects) > >> ../../source4/rpc_server/drsuapi/getncchanges.c:1765: getncchanges on DC=DomainDnsZones,DC=kmg,DC=mydomain,DC=com using filter (uSNChanged>=29467) > >> > >> Given the above errors this looks like a permissions problem but so far I have not > >> been able to find it. > > > > Hmm. some classic questions include "is SELinux on", and "which > > Kerberos did you use, the supported internal Heimdal Kerberos or the > > experimental support for MIT kerberos? > > SELinux is in permissive and my configure line is simply ./configure so no MIT > here. IMO no one in their right mind would try to use MIT in production.If you just run "./configure" and then "make install, you can wind up interleaving RPM based components on top of system components. Some of the critical libraries are system libraries, used by other components, and may not have been updated or may show up before your new compiled versions based the system's LD_LIBRARY_PATH and other factors. I can't try to debug that without a good look at what you have in place, and where you put things, deliberately or accidentally. This is precisely why I publish RPM's, and why for someone who doesn't like to play with this stuff I'd actually they spend some money and pay for the Sernet, commercially supported binaries.> Regards, > > -- > Tom me at tdiehl.org
On Mon, 20 May 2019, Nico Kadel-Garcia wrote:> On Mon, May 20, 2019 at 3:33 PM <me at tdiehl.org> wrote: >> >> On Sat, 18 May 2019, Nico Kadel-Garcia wrote: >> >>> On Wed, May 15, 2019 at 4:32 PM Tom Diehl via samba >>> <samba at lists.samba.org> wrote: >>>> >>>> Hi, >>>> >>>> I have a new Centos 7.6 VM that I self compiled 4.10.3 and joined it to an >>>> existing samba AD domain that has 2 existing DCs. One of the existing DCs is >>>> running 4.8.7 and the other is running 4.7.7. Everything looks OK except >>>> that when I run samba-tool drs showrepl on the new DC (VDC4) I get the >>>> following output: >>> >>> "self-compiled" can include a lot of sins, especially if trying to >>> place it alongside *or* in place of the provided libraries for tevent, >>> ldb, tdb, and talloc. Let me point you to my git repo, >> >> Well OK maybe I should have said self compiled using the instructions >> @ https://wiki.samba.org/index.php/Build_Samba_from_Source#configure and >> the package list from https://wiki.samba.org/index.php/Package_Dependencies_Required_to_Build_Samba#Red_Hat_Enterprise_Linux_7_.2F_CentOS_7_.2F_Scientific_Linux_7 >> substituting python36-devel for python-devel and adding python32-dns >> to get the samba-tool dns module to work. >> None of the distro samba packages are installed. >> >> TBH, I am guessng about the package list given the change from python2 to python3 >> as it does not look like the wiki has been updated for 4.10.x. >> >>> https:/github.com/nkadel/samba4repo/, with submodules for samba >>> itself, talloc, tevent, etc., etc. It's built to use the official >>> upstream tarballs from www.samba.org, not tarballs from *me*, and that >>> also will give you a good git repo you can use to manage any >>> compilation options in the ".spec" file. >> >> Is there a way to only build the Centos bits using your git repo? I have no >> Fedora machines and so far I have not been successful in getting the above >> to build on a Centos 7 VM using the version of Mock supplied by the Centos >> project. > > Yeah. Comment out the other operating systems in the Makefiles. > Install the dependencies, as RPMs, in order. The order in the top > level Makefile should get you through the process.OK, I thought about that but I was wondering if there was an easier way. Thanks for confirming that.>>> Hmm. some classic questions include "is SELinux on", and "which >>> Kerberos did you use, the supported internal Heimdal Kerberos or the >>> experimental support for MIT kerberos? >> >> SELinux is in permissive and my configure line is simply ./configure so no MIT >> here. IMO no one in their right mind would try to use MIT in production. > > If you just run "./configure" and then "make install, you can wind up > interleaving RPM based components on top of system components. Some of > the critical libraries are system libraries, used by other components, > and may not have been updated or may show up before your new compiled > versions based the system's LD_LIBRARY_PATH and other factors. I can't > try to debug that without a good look at what you have in place, and > where you put things, deliberately or accidentally. This is precisely > why I publish RPM's, and why for someone who doesn't like to play with > this stuff I'd actually they spend some money and pay for the Sernet, > commercially supported binaries.Here's where I disagree. When you run ./configure, make and make install everything gets put into /usr/local/samba by default. It is not installed over top of any system components. Not that I recommend this as a standard practice but if you totally screw the pooch on a build for whatever reason all you have to do is rm -r /usr/local/samba and you get to start over. I have tested this and know that it works. :-) Obviously if you do that to a DC that is joined to a domain, you have more than that to clean up. Regards, -- Tom me at tdiehl.org