After realizing that people don't realize (heh) samba DC is not a regular fileserver, 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? 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? /mjt
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
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
It certainly would be nice to have distinct 'smb.conf' and 'samba.conf' files. Each one would have its own manual page containing only the parameters that apply to each case, AD DC and regular file server. The current situation, mixing parameters that apply and don't apply to a DC is somewhat confusing to many users.
> It certainly would be nice to have distinct 'smb.conf' and 'samba.conf' files. > Each one would have its own manual page containing only the parameters that apply to each case, AD DC and regular file server. > The current situation, mixing parameters that apply and don't apply to a DC is somewhat confusing to many users.A transition period could be implemented, during which the 'samba' daemon would read its configuration from both 'samba.conf' and 'smb.con', in this order of preference, until at a certain point the use of 'smb.conf' by the AD DC would be discontinued.