On 10/26/21 06:00, Eric Levy via samba wrote:> 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.
With all due respect, I think you're confused about how these things
must work, based on practical considerations. I urge you to go back and
re-read my first post in this thread carefully. The issue is explained
there.
To reiterate an example I provided there (bitcoin), you either have a
central authority which is the final arbiter of deciding if someone
requesting a resource is actually the user they say they are, or you
don't. If you don't have a central authority, then there must be some
other mechanism for determining this and those quickly become onerous or
complicated. If you don't care about security, then problem solved:
just set file permissions to 777 and share the filesystem to anyone who
asks for it. This would generally not be acceptable in a business
context, but I know some smaller organizations who essentially have
their filesystem share configured this way: everyone is a fully trusted
user.
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.
>
>
>
>
>
>