samba - Feb 2023 - Using separate packages for a DC

On 30/01/2023 13:44, Michael Tokarev via samba wrote:
> After realizing that people don't realize (heh) samba DC is
> not a regular fileserver,
Sorry, but it is a regular fileserver (sysvol), it just works 
differently to a Unix domain member.
> an idea come to me.
> 
> How about building two different samba packages (on a distribution
> such as debian), one being a regular file server and another is
> just for an AD DC, and make them *co-installable*, so each has
> its own set of config/library/cache/runtime files?
I think you just described running a DC on the bare metal and a Unix 
domain member in a VM.
> 
> When installed together, it will be two separate instances, built
> in a way so that they don't share anything. One only have to specify
> different IP addresses for the two (and different names),
> and that's about it.
> 
> I'm not yet sure about all the details, - for example, there can
> only be one libnss_winbind, but in this case it looks like the
> regular instance don't need winbinidd, single winbind can be used.
> There's a question about DNS too.? That all needs to be thought
> about for *sure*.
> 
> If that works, the two might be built with different kerberos
> implementations as well: the regular fileserver (and client)
> is built with MIT kerberos which is more featureful, and the
> AD-DC one is built with heimdal (using their own set of libraries
> and helper executables).
> 
> What do you think?
It sounds like far too much work for too little gain.

Rowland

30.01.2023 17:34, Rowland Penny via samba ?????:
[]
> I think you just described running a DC on the bare metal and a Unix domain
member in a VM.
I would use it the other way 'round: DC in a VM (or better yet, a
container),
and domain member on bare metal (or both in containers). A DC is very well
suited for a container, - it is a small thing with its own
"ecosystem", used
basically for authentication and "finding things". While a regular
member
server is the one which serves files, often many of them, and this is where
most work is being done.  This way, when the DC is in a container, it is
easier to install several DCs too (even two DCs on a single physical machine,
to be able to bring one of them down for maintenance and stuff like that).
Also, a DC install is easy to script/automate, since the configuration is
usually quite simple and self-contained.

The prob which I thought about is different though: somehow many people
don't
realize the differences between a DC and a regular file server, and at first
try to set up both on the same samba instance.  Setting up containers or VMs
is too much work for some who aren't familiar with the concept (and while
regular tools always available on a typical linux distribution, - like
systemd-nspawn for example - can be used to run just a single application,
like samba, in a separate container without the need to install a whole
new system, - it turned out these aren't easy at all, - perhaps I should
write a how-to about running samba ad dc off the regular system in a
systemd-nspawn container).

It is like, huh, samba needs two machines now instead of one? that's
ridiculous, let's ignore this, I don't have another machine anyway.
And face issues later.

If the DC were easily available and can co-installable with a regular
member server (with single addition necessary, - an extra dedicated IP
address from private IP space), things would be easier for many.

But it wont work anyway, as noted in my other email in this thread.
Just too confusing.

/mjt