On Sun, 19 Feb 2017, Jeff Sadowski via samba wrote:> I was never able to build it in a way I feel comfortable on Fedora. I would > want to build it using an RPM build process. I think I want an MIT build > but I don't know what all I would need to build either way. I thought itWhat do you hope to gain from an MIT build? The MIT kerberos user tools (kinit, etc) operate just fine with keytabs generated by the Heimdal Samba KDC. I understand that the distro wants to ship a unified set of packages, but for end users doing their own builds, I don't think it really matters much. FWIW, I rebuilt the CentOS 7.2 Samba packages (samba-4.2.10-7) with DC support. It required building without MIT and with DC support, and also adding a the samba.service file that RH didn't include. I also increased the epoch so system updates with a newer version would never override my local build. I also had to add export LDB_MODULES_PATH=/usr/lib64/samba/ldb/ to my bash profile for the ldb tools to work. However, when I rebuilt the CentOS 7.3 packages (4.4.4-12.el7_3), I am unable to replicate with any of my older DCs (4.1 or 4.2 sernet, or my rebuilt CentOS 4.2.10 DCs). This happened even when I built straight from source, so I think either 4.4 requires some dependency that 7.3 doesn't meet, or there may be some issue with some dependency on 7.3 that wasn't an issue on 7.2. In case it's useful, this is the extent of my changes to the spec file: --- samba.spec 2017-01-17 11:21:48.000000000 -0600 +++ samba-dc.spec 2017-01-27 13:58:55.736213036 -0600 @@ -56,8 +56,8 @@ %global libwbc_alternatives_suffix -64 %endif -%global with_mitkrb5 1 -%global with_dc 0 +%global with_mitkrb5 0 +%global with_dc 1 %if %{with testsuite} # The testsuite only works with a full build right now. @@ -78,9 +78,9 @@ Release: %{samba_release} %if 0%{?rhel} -Epoch: 0 +Epoch: 4 %else -Epoch: 2 +Epoch: 4 %endif %if 0%{?epoch} > 0 @@ -879,7 +879,7 @@ %endif install -d -m 0755 %{buildroot}%{_unitdir} -for i in nmb smb winbind ; do +for i in nmb smb winbind samba ; do cat packaging/systemd/$i.service | sed -e 's@\[Service\]@[Service]\nEnvironment=KRB5CCNAME=FILE:/run/samba/krb5cc_samba at g' >tmp$i.service install -m 0644 tmp$i.service %{buildroot}%{_unitdir}/$i.service done @@ -1515,6 +1515,7 @@ %{_datadir}/samba/setup %{_mandir}/man8/samba.8* %{_mandir}/man8/samba-tool.8* +%{_unitdir}/samba.service %else # with_dc %doc packaging/README.dc %endif # with_dc
On Tue, Feb 21, 2017 at 7:43 AM, Sketch <smblist at rednsx.org> wrote:> On Sun, 19 Feb 2017, Jeff Sadowski via samba wrote: > > I was never able to build it in a way I feel comfortable on Fedora. I would >> want to build it using an RPM build process. I think I want an MIT build >> but I don't know what all I would need to build either way. I thought it >> > > What do you hope to gain from an MIT build? The MIT kerberos user tools > (kinit, etc) operate just fine with keytabs generated by the Heimdal Samba > KDC. I understand that the distro wants to ship a unified set of packages, > but for end users doing their own builds, I don't think it really matters > much. >Nothing really, I think I'll do it how Dario Lesca showed me with building the packages. I'm was just hoping the MIT build with AD DC support would just start showing up in at least in Fedora Rawhide so I don't have to build it myself at all. If I can script build it similar to how Dario Lesca built it I can live with that for now I guess. Or maybe I'll install a centos and use Nico Kadel-Garcia's repo that he shared. Although I'm not sure what version he is on. I just want a reliable AD DC and as much as I complain about my Ubuntu implementation I really haven't had a problem with it. I would like to create a second DC and replicate but I don't know how well that will work. I think I need to rebuild bind as well because I want to use it how I did in ubuntu. I seem to recall it needing something built in to work with samba.> FWIW, I rebuilt the CentOS 7.2 Samba packages (samba-4.2.10-7) with DC > support. It required building without MIT and with DC support, and also > adding a the samba.service file that RH didn't include. I also increased > the epoch so system updates with a newer version would never override my > local build. >Ouch, changing epoch wouldn't that cause all sorts of havoc with keeping client times and server times synced? Maybe there is a better way to distinguish the package name so it doesn't think it is an upgrade? Maybe build it as ADDC-samba-4.X.X so fedora won't try to update it?> I also had to add > > export LDB_MODULES_PATH=/usr/lib64/samba/ldb/ > > to my bash profile for the ldb tools to work. > > However, when I rebuilt the CentOS 7.3 packages (4.4.4-12.el7_3), I am > unable to replicate with any of my older DCs (4.1 or 4.2 sernet, or my > rebuilt CentOS 4.2.10 DCs). This happened even when I built straight from > source, so I think either 4.4 requires some dependency that 7.3 doesn't > meet, or there may be some issue with some dependency on 7.3 that wasn't an > issue on 7.2. >I think Fedora will be OK with building later versions as it keeps packages a little better up to date. Yeah replication is my fear. I'm hoping if I get to a version that supports replication better. I thought samba 4.6 is suppose to have replication correct? or 4.7rcX? or is replication still something I need to do manually with an rsync? I'm hoping all I need to do to replicate is to join the domain and promote it to a DC. Will that work? (My current DC is 4.3.11-Ubuntu)> In case it's useful, this is the extent of my changes to the spec file: > > --- samba.spec 2017-01-17 11:21:48.000000000 -0600 > +++ samba-dc.spec 2017-01-27 13:58:55.736213036 -0600 > @@ -56,8 +56,8 @@ > %global libwbc_alternatives_suffix -64 > %endif > > -%global with_mitkrb5 1 > -%global with_dc 0 > +%global with_mitkrb5 0 > +%global with_dc 1 > > %if %{with testsuite} > # The testsuite only works with a full build right now. > @@ -78,9 +78,9 @@ > Release: %{samba_release} > > %if 0%{?rhel} > -Epoch: 0 > +Epoch: 4 > %else > -Epoch: 2 > +Epoch: 4 > %endif > > %if 0%{?epoch} > 0 > @@ -879,7 +879,7 @@ > %endif > > install -d -m 0755 %{buildroot}%{_unitdir} > -for i in nmb smb winbind ; do > +for i in nmb smb winbind samba ; do > cat packaging/systemd/$i.service | sed -e 's@ > \[Service\]@[Service]\nEnvironment=KRB5CCNAME=FILE:/run/ > samba/krb5cc_samba at g' >tmp$i.service > install -m 0644 tmp$i.service %{buildroot}%{_unitdir}/$i.service > done > @@ -1515,6 +1515,7 @@ > %{_datadir}/samba/setup > %{_mandir}/man8/samba.8* > %{_mandir}/man8/samba-tool.8* > +%{_unitdir}/samba.service > %else # with_dc > %doc packaging/README.dc > %endif # with_dc > >
On Tue, 21 Feb 2017, Jeff Sadowski via samba wrote:> On Tue, Feb 21, 2017 at 7:43 AM, Sketch <smblist at rednsx.org> wrote: > >> I also increased the epoch so system updates with a newer version >> would never override my local build. > > Ouch, changing epoch wouldn't that cause all sorts of havoc with keeping > client times and server times synced? > Maybe there is a better way to distinguish the package name so it doesn't > think it is an upgrade? > Maybe build it as ADDC-samba-4.X.X so fedora won't try to update it?In thise case, epoch is just an extra RPM tag used to enforce versioning, nothing to do with time. You could also rename the package instead, but the samba package already uses the epoch tag anyway (set differently for RHEL and Fedora, for some reason). https://ask.fedoraproject.org/en/question/6987/whats-the-meaning-of-the-number-which-appears-sometimes-when-i-use-yum-to-install-a-fedora-package-before-a-colon-at-the-beginning-of-the-name-of-the/> I think Fedora will be OK with building later versions as it keeps packages > a little better up to date. > Yeah replication is my fear. I'm hoping if I get to a version that supports > replication better. > I thought samba 4.6 is suppose to have replication correct? > or 4.7rcX? or is replication still something I need to do manually with an > rsync? > > I'm hoping all I need to do to replicate is to join the domain and promote > it to a DC. Will that work?That should work. Replication generally works fine, but they have made fixes and improvements over time, so the newer (stable) version you run, the better. The only times I have really had any issues in production was with 4.1, and that was mostly only with manual deletion of objects with ldbedit not getting replicated. I'm not really sure what's going on with 4.4 or newer on CentOS 7.3. As far as I know, there should be no replication issues with older versions.