[Samba] domain-free multi-user use cases

[Eric Levy]

On Sun, 2021-10-24 at 12:07 -0700, Gregory Sloop via samba wrote:
> > On Sun, 2021-10-24 at 09:03 +0100, Rowland Penny via samba wrote:
> > > On Sun, 2021-10-24 at 03:37 -0400, Eric Levy via samba wrote:
> > > > On Sun, 2021-10-24 at 20:35 +1300, Andrew Bartlett wrote:
> > > > > On Sun, 2021-10-24 at 03:23 -0400, Eric Levy via samba wrote:
> > > > > > Right, so coming full circle to my opening comments, we
> > > > > > have a
> > > > > > case
> > > > > > that is not supported internally by Samba, and I wish to
> > > > > > inquire
> > > > > > about
> > > > > > enthusiasm for keeping open any possibility for considering
> > > > > > such
> > > > > > support in future development.
> > > > > I don't have any enthusiasm for host-based (rather than user
> > > > > based)
> > > > > authentication, if that is what you mean, but do suggest a
> > > > > way,
> > > > > without
> > > > > changing Samba, that you could achive your goal.
> > > > > Other remote file systems may offer host-based
> > > > > authentication.
> > > > > Andrew,
> > > > I am not sure what you mean.
> > > I think Andrew is saying that Samba has no real interest in
> > > creating
> > > the set up that you seem to require, but you may find another
> > > tool
> > > that
> > > does, but I will not hold my breath whilst you search for it.
> > > Rowland
> > I did not understand the reference to host-based authentication.
> 
> Eric.
>  
> My two cents, after reading some of the thread...
>  
> I've not carefully read this thread, but I think in general I
> understand the issues - and while I'm at a different place in life
> (where money isn't as scarce as it once was - yet I'm far from rich)
> I think you're really complaining about a trivial cost.
>  
> Almost any C2D or i3/i5 machine can act as a DC.
> Even better is a machine with a bit more oomph and run something like
> Xen/XCP and run your DC in a VM. (You can test with other VM's or run
> additional stuff without buying yet more hardware.)
>  
> But all that said - you're avoiding running a DC because you'd have
> to buy more hardware. And you kind of take the stance that someone
> else should spend a substantial amount of time finding you an easy
> way to do this.
>  
> Yet, a used Dell/HP/Compaq machine is probably easily less than $200.
> (At least here in the US, I've gotten Optiplex 7010's for <$100. I
> assume you're not in some 3rd world country with terribly limited
> access to decent hardware. Outside of that, I think used hardware
> should be pretty trivially available. Heck, you could run a DC on a
> RaspPi - though I think that's muts.)
>  
> So, for <$200, you're asking others to spend a lot of time walking
> you through an "alternate" solution. (An alternate that ALREADY has a
> very good solution in a DC.)
> I don't know exactly how much time has been expended in just this
> thread so far, but at any professional rate of pay, I'd nearly
> guarantee that $200 in time has already been expended.)
>  
> To say it kind of bluntly; You're effectively expending other
> people's $200 (in time), so you can avoid it yourself. (Whether the
> cost, the hassle, or whatever...)
> And to me, that doesn't feel very equitable or reasonable.
>  
> There are probably other ways to do what you want, but, by far, the
> best way already exists - and it's a DC. You'll spend a ton of time
> trying to re-create the wheel, and why do that? (Likely smarter
> people than you and I have spent a ton of time considering the
> problem, and the DC is the solution that's the best so far. You're
> not likely to come up with something better. And it certainly will
> cost more than the cost of the hardware you want to avoid buying - so
> it will be more costly and likely a worse solution too!)
>  
> If I were to recommend something - a Dell Precision T3610 (Xeon QC) -
> ECC RAM is super cheap. Toss a regular 500G SSD in it. Run XCP-NG on
> it and you'll have an awesome test-bed where you co do all sorts of
> tinkering. You can make snapshots so if you screw things up, you can
> roll back in seconds etc. I'd guess you'd find a lot of utility in
> it. It will probably cost more than $200, but probably not a lot, if
> you're careful and patient.
>  
> Cheers!


My discussion has been constrained to the completeness of features of
the software, particularly with respect to consideration of the range
of use cases.

I would not agree that any large part of my planning is based on
avoiding the financial cost of purchasing the cheapest hardware that
might be used solely for running one additional software component. 

While I may not be swimming in cash, money is not a driving force for
me in this conversation. (Having said as much, buying a tower
workstation to sit next to a SOHO NAS half the size tends to defeat the
purpose of the earlier purchase.)

I am also not asking anyone to walk me through steps to do something.

Configuring and maintaining a domain server has a cost independent of
hardware purchases, and it might be valuable to consider how a future
feature of the software might allow users to create a multiuser mount
without one.

The purpose of a domain server above all else is to manage user
accounts centrally across nodes on a network, and it is, I think, a
sound observation that multiuser mounts need not in principle be tied
to this additional infrastructure.

As an aside, on a very narrow point, if we were to consider the
difference between my obtaining more hardware versus the feature set of
the software growing, the former benefits only me, whereas the latter
benefits everyone. Turning the previous suggestion on its head, I might
say that you are suggesting that an entire cohort of users augment
their hardware assets just so the software may avoid evolving toward
greater flexibility.

I am not minimizing the costs of development for new features, nor
expressing a judgment that the benefits exceed those costs. I am only
suggesting considering the idea for the future.

There is a wide range of possible use cases, and a slightly less-wide
gap between the two clusters of use cases supported on either side of
the single- versus multiuser divide. The confusion in this discussion
reveals that the full range of these cases are not being
comprehensively evaluated by the community, and my drawing attention to
this topic hopefully has some value, whatever decisions might be
reached.