samba - Feb 2023 - Using separate packages for a DC

On Mon, 2023-01-30 at 16:44 +0300, Michael Tokarev via samba
wrote:
> After realizing that people don't realize (heh) samba DC isnot a
> regular fileserver, an idea come to me.
> How about building two different samba packages (on a
> distributionsuch as debian), one being a regular file server and
> another isjust for an AD DC, and make them *co-installable*, so each
> hasits own set of config/library/cache/runtime files?
I think that would be a pile of pain, and cause to many
conflicts.
> When installed together, it will be two separate instances, builtin a
> way so that they don't share anything. One only have to
> specifydifferent IP addresses for the two (and different names),and
> that's about it.
I would really not do that.
> I'm not yet sure about all the details, - for example, there canonly
> be one libnss_winbind, but in this case it looks like theregular
> instance don't need winbinidd, single winbind can be used.There's a
> question about DNS too.  That all needs to be thoughtabout for
> *sure*.
> If that works, the two might be built with different
> kerberosimplementations as well: the regular fileserver (and
> client)is built with MIT kerberos which is more featureful, and
> theAD-DC one is built with heimdal (using their own set of
> librariesand helper executables).
Alternative packages would be a reasonable outcome, but not co-
installable. 
Andrew Bartlett

-- 
Andrew Bartlett (he/him)       https://samba.org/~abartlet/Samba Team Member
(since 2001) https://samba.orgSamba Team Lead, Catalyst IT  
https://catalyst.net.nz/services/samba
Samba Development and Support, Catalyst.Net Limited
Catalyst.Net Ltd - a Catalyst IT group company - Expert Open SourceSolutions

31.01.2023 22:32, Andrew Bartlett via samba wrote:
> On Mon, 2023-01-30 at 16:44 +0300, Michael Tokarev via samba wrote:
>> After realizing that people don't realize (heh) samba DC isnot a
>> regular fileserver, an idea come to me.
>> How about building two different samba packages (on a
>> distributionsuch as debian), one being a regular file server and
>> another isjust for an AD DC, and make them *co-installable*, so each
>> hasits own set of config/library/cache/runtime files?
> 
> I think that would be a pile of pain, and cause to many conflicts.
I don't (yet) see any conflicts in there besides the already mentioned
one: where things like nsswitch should point to (and it looks like it
should point to the DC). Other than that, things look quite smooth.

However, the more I think about that, the less I like the whole thing.
Not because of the conflicts, but because of the unusual/non-standard/
confusing two sets of binaries and control tools. For example, there
will be two samba-tools and smbstatus, - either named differently,
like samba-tool and samba-tool.dc (and all other tools need to be able
to find the right one), or put into different dirs to adjust PATH
(with the same problem finding the right one). It will be too clumsy
as a whole.

..
> Alternative packages would be a reasonable outcome, but not co-
> installable.
I think you're right here.

Or maybe it's better to spend efforts in building whole thing with MIT,
fixing the issues and removing the -experimental- tag from this DC.

I'm being asked for mit-krb5 build of samba on a regular basis, and
I know why, - when you actually use kerberos, you understand that
heimdal is really lacking in some areas. For one, I haven't found a
way to use smartcards/tokens with heimdal, while with mit-krb5 it
just works out of the box.

Thank you for the answer!

/mjt