On Thu, July 23, 2020 15:03, Rowland penny wrote:
> Not having perused the code in depth, I do not know, but I
> doubt if it does, but your problem (as far as I understand it)
> is that Samba will not start.
Samba starts fine, so long as nbt is disabled and the interface is bound to
ipv4 addresses only. That was dealt with long ago and samba_server errors were
reintroduced only when the 'server services = -nbt' and bind interfaces
=yes'
lines were removed from smb.conf trying to debug samba-tool. With those
directives in place samba_server starts without issue.
On the other hand, the original problem with 'samba-tool backup offline'
hanging, was not remedied by having the -nbt line removed from smb.conf.
Likewise, removing the bind interfaces directive had no effect on the
samba-tool problem.
The issue in samba_server is apparently nbtd cannot bind to 137. Ntpd never
gets to 138 so that it and 139 likely suffer from the same problem. What
samba-tool is trying to do with nbt is unknown to me.
> Everything you are trying to do, is different from just about every
> other Samba user. You are using Freebsd and running Samba in
'jails'.
> I am not knocking you over this, I am just pointing out that there is
> little experience on this list about just how you are trying to run Samba.
>
Well, a lot of people before you have noted that I am a little
'different' from
the rest of them. I can live with that.
I do not expect anyone to have these answers. I can hope for answers but I do
not expect it. Nonetheless, in case there is something buried inside Samba
that is only triggered by some environmental issue created by FreeBSD jails
then I believe that is worth the effort to find out what it is.
The choice of FreeBSD as our sole OS (besides the user workstations) was driven
by other considerations and Linux is no longer an option. Nevertheless,
despite not running Samba on Linux, I have tracked down and resolved every
error relating to samba_server. And they were all configuration issues.
With NBT disabled and the interfaces bound solely to IPv4 addresses
samba_server now starts without error and I can administer it using RSAT from a
laptop. I can even replicate using rsync. I have joined another DC running in
a FreeBSD jail and successfully transferred all the FMOS roles to it. I have
destroyed the FMOS DC and successfully seized the FMOS roles back to the
remaining one. I have created yet another DC and joined that to the domain.
So, the core task of creating a robust AD DC installation in FreeBSD jails is
completed successfully.
The issue with samba-tool is a minor annoyance. It arose when I was testing the
backup feature. As it is, with samba installed in jails that are on ZFS file
systems, I get snapshots of the entire running installation every two minutes.
If something did go horrendously wrong with every DC simultaneously then
recovery amounts to rolling back the jails from the last known good snapshot,
which is a trivial task. At regular intervals a transfer snapshot is taken of
each DC jail and each is sent to a different host. So even if the hardware
goes south we can still recover with little effort. ZFS is, in fact, the main
reason we migrated from Linux to FreeBSD. Well, that and systemd.
Our existing domain DC is running on a FreeBSD bhyve VM. We have decided
against using VMs for FreeBSD due to an unresolved, as far as I know, issue
between bhyve and zfs that causes VMs to stop responding. The only remedy is
to destroy the VM and start it again. Now VMs are reserved for alien file
systems like Linux and Windows.
> If you were running Debian in a VM, I would suggest rebooting the VM,
> but can you reboot a 'jail' ??
One can start, restart, and stop a jail. That has the effect of a power down.
I have done this many times to the DC jails. It has absolutely no effect on
the samba-tool problem.
Given that the hang occurs at an os.waitflag() call, I thought initially that
the issue had to do with threading. But, I stole a little Python script from
somewhere that implements a trivial threaded program and that runs on the jail
exactly as expected.
There is something about how that port is attached which is triggering this.
Anyway, whether the jail environment is exposing a defect in Samba or Samba is
exposing a defect in the FreeBSD jail implementation remains to be seen.
Thank you very much for all the help you have previously provided to me. And
thanks to all the other people who provided advice. And to Timur who made
provisioning on FreeBSD work. I would not have succeeded otherwise.
And, no, the questions will not stop now that I have it/them running. I am
certain that I will get the wrong end of the stick with something AD related
and need help from the list.
Sincerely,
--
*** e-Mail is NOT a SECURE channel ***
Do NOT transmit sensitive data via e-Mail
Unencrypted messages have no legal claim to privacy
Do NOT open attachments nor follow links sent by e-Mail
James B. Byrne mailto:ByrneJB at Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3