[Samba] domain-free multi-user use cases

[Eric Levy]

On Mon, 2021-10-25 at 15:45 -0500, Patrick Goetz via samba wrote:
> 
> On 10/24/21 14:34, Gregory Sloop via samba wrote:
> > 
> > > I think you mean 'nuts' :-D
> > > If you do, then I must be a double nut, I run two rpi4's with a
> > > DC on
> > > each (less electric). I wouldn't use them for a large business,
> > > but
> > > they are ideal for my small home test domain.
> > 
> > I mean it's for the dogs!
> > 
> > (Yeah, I meant nuts. Perhaps I should have said "glutton for
> > punishment" instead.)
> > 
> > I've been more enamored with Pi's in the past. But I've been bit in
> > the backside too many time by abrupt SD card failures.
> > The $30/year (or so) I pay to run a XCP hypervisor vs a Pi is
> > totally worth it for me, because it saves me time, and frustration.
> > (And it has a ton of additional utility that the Pi doesn't.)
> > 
> > I think you can run regular SSD's on Pi's now - and perhaps that
> > would alleviate my biggest peeve about Pi's - but it wouldn't make
> > up for a ton of other utility having a real VM setup with all the
> > advantages for testing; snapshots, spinning up test environments,
> > etc. (I even run pihole on a XCP based VM - instead of a Pi.)
> > 
> > But IMO, if running a Pi was the only way to run the DC, I'd still
> > recommend that over not, to the OP.
> > 
> > 
> 
> For what it's worth, I'm doing a Samba deployment right now where
> they 
> only have one server available for Samba (previously, a PDC).  So
> I'm 
> running Samba-AD-DC in an LXD container on this server, connected to
> a 
> public facing bridge.  Works great.
> 
> If you only have linux machines, Samba is absolutely not the tool
> you 
> want.  As already mentioned, NFS does exactly what you want already.


I will investigate whether a solution of this kind, or any other given
earlier, might be viable workaround for me at this time. Running Samba
on an inexpensive NAS appliance, I wish to preserve the benefits of the
device being self contained, small scale, low cost, and minimal
configuration. 

The current discussion is the latter of two on which I have engaged
this group so far. In the prior, I sought a practical solution for
managing my current deployment, though few solutions were suggested at
that time. Ironically, this conversation, initiated after I considered
the implications of the prior, was intended to target the broader
design choices of Samba, but rather has diverged largely into a
discussion of current practice, most especially my current practice.

As I indicated, I welcome practical solutions for their value, but also
hope not to lose the chance for a sound review of the broader context.

Currently, the orthodox position is that multiuser mounts and domain
controllers have a relationship of dependence, if not by absolute
necessity, then at least by history and practice. Multiuser mounts are
considered mostly to occur in larger deployments that include domain
controllers. Due to this association, the design choices of the
software make as a prerequisite of multiuser mounts the utilization of
a domain controller. Even admitting the value of any earlier
assumptions at the time of their adoption, ongoing technological
evolution continues to wear upon the usefulness of orthodoxy.

History and practice inevitably informing perception, the prevailing
perception is now that a separation between support of multiuser mounts
from the use of a domain controller is not a useful direction to
consider for future development, because of the design and
implementation costs, because of lack of broad relevance, or because of
a belief that deployments would introduce difficult problems. 

Whereas anyone sensible would recognize that administrators creating
multiuser mounts often will be doing so in deployments currently
benefiting from a domain controller, I hoped to draw attention to a
separate and distinct scenario. Suppose someone not using a domain
controller is completely happy in every way with the layout of the
system, and the function of the software, except for the impossibility
of simply creating a multiuser mount. Resolving this impossibility
would not limit anyone else currently using a domain controller, nor
require a commitment of never adding a domain controller to the same
deployment in the future. The plain observation is that at the current
moment, the constraints in the software design impose the only
limitation against someone adding to the simple deployment a multiuser
mount.

Seen in such a light, as I originally attempted to cast on the subject,
and also as immediate to my present experience, some of the ideas given
earlier, about a fixation on avoiding a domain controller, a stinginess
over cash expenditures, or features being redundant with NFS, all
appear to me as red herrings, as not bearing on the essential merits of
the ideas I have expressed.

It has been suggested that utilization of domain controller achieves
the same result as the proposed support for multiuser mounts without a
domain controller, but such suggestions overlook the central premise
that inclusion of a domain controller in the deployment is part of the
result. Introducing a domain controller broadly determines how the
network operates, and not including one is a defensible choice. Domain
controllers not only impose administrative and operational overhead,
including for the lost time of normal workflow stopping when they fail
or malfunction, but they also require changing the operational mode of
the other nodes to be members of the domain, with operation then
becoming dependent on the function of the domain controller.
Utilization of a domain controller must be considered as a different
paradigm, a more complicated and in some ways more fragile network
configuration, which is surely suitable for many deployments, but may
not be suitable for all. 

Ideally, a choice not to include a domain controller in a network would
not prevent benefiting from features that in principle have no
necessary dependence on one.

Such observations may be, I hope, useful toward putting aside orthodox
perception, and framing the matter through broader clarity, I hope to
show that a wish to create a multiuser mount without a domain
controller is in principle rather sensible, and not, in the most
general case, diminished by many of the common objections.

To close on a more concrete remark, NFS currently has limitations, as
stated previously, of its own, including the insistence on matching
numeric user identifiers, and lack of support for password
authentication. Features useful for Samba might be considered
separately from those available in NFS.