[Pkg-samba-maint] samba ad-dc: mit-krb5, splitting off samba-dc package, more...

Michael Tokarev mjt at tls.msk.ru
Sat Nov 12 10:52:34 GMT 2022


Hello!

After experimenting a bit with building Samba with MIT-Kerberos5 and playing
with the resulting Samba-based AD DC, I've quite a few questions which I'd
love to discuss.  I'm not sure this is a right place to do that though, but
I know no better place anyway.  Also including Andreas who seems to maintain
samba in Ubuntu.

One question is the mit-krb5 vs embedded Heimdal.  It looks like there's no
show-stopper anymore to switch samba from embedded Heimdal to MIT-Kerberos,
everything works quite well, at least from the first look.  Redhat uses this
setup for quite a while too.  The only issue here is the generation of
/var/lib/samba/private/kdc.conf file which has to be done somewhere, and
doing this in a postinst script, while works, seems to be somewhat wrong,
but not entirely wrong.  If we go that route (the mit-kerberos way), it
can be done at an upgrade time if the version we're upgrading from is older
than the switch heimdal -> mit-krb5.  Assuming we'll do the switch once.
Not that a bad thing to do.

Am I right the mit-krb5 way is the way to go these days, or should we still
support embedded heimdal build? It is easy to have 2 build profiles in the
same source, but we should build either one or another, but not both,
obviously, and we can't really switch between the two at will. Or can we?


Another question is about splitting out the domain functionality from main
samba package into a separate samba-domain-controller package.  This way,
we have much more manageable pieces.  The idea is once you install
samba-domain-controller, your system is configured to act as a Domain
Controller, not as a regular server (which are quite different beasts),
and some extra dependencies are installed automatically (eg, a domain
controller needs samba-dsdb-modules and samba-vfs-modules, and it needs
winbind - none of which are *required* for a regular samba server install).
Also, this way it is easy to split out samba-domain-deployment package
with /usr/share/samba/setup/ which is arch-independent.

And since these are a entirely different mode of operations, maybe we can
go even further, having two separate packages, like, samba-domain-controller
and samba-file-server, both depending on a samba-server-common package
with all the required common binaries, with samba-dc and samba-file-server
containing the startup scripts needed for either of the two modes,
but conflicting to each other, and *no* "samba" package at all.
(Or there could be samba-server-common, samba, and samba-domain-controller,
with samba and samba-domain-controller conflicting with each other, and
samba-server-common providing the common binaries - so "samba" package is
still here but it provides the file server part only).

Or maybe this all makes little sense, and it does not worth the trouble
for anyone who's running samba ad-dc currently and will have a manual
upgrade to samba after the split?


Speaking of the samba-dsdb-modules and samba-vfs-modules, I don't really
understand why these are separate packages. Why not move them into the
main samba package (or into samba-server-common if samba is split into
-server and -dc)?

What do you think?

/mjt



More information about the Pkg-samba-maint mailing list