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.
Am 26.10.21 um 13:00 schrieb Eric Levy via samba:> 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.As I mentioned earlier most people in your situation and setup would opt for NFS with its limitations. Also as I said pam_mount would in the end result do what you want. So I think it very unlikely that this would be implemented in Samba.> > 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.Most people would use NFS in similar situations. They would restrict the NFS to be only mounted (or even only accessible) by clients that honour the requirement for Password auth. NFS can also support ACLs to make this more fine grained. I don't speak for the samba team. I just think your use case is just to small to really relevant. Or do others think different here? Regards Christian -- Dr. Christian Naumer Vice President Unit Head Bioprocess Development BRAIN Biotech AG Darmstaedter Str. 34-36, D-64673 Zwingenberg e-mail cn at brain-biotech.com, homepage www.brain-biotech.com phone +49-6251-9331-30 / fax +49-6251-9331-11 Sitz der Gesellschaft: Zwingenberg/Bergstrasse Registergericht AG Darmstadt, HRB 24758 Vorstand: Adriaan Moelker (Vorstandsvorsitzender), Lukas Linnig Aufsichtsratsvorsitzender: Dr. Georg Kellinghusen
I removed some part. ...> 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.QSNAP and Synoligy provide Samba AD on NAS.>....> > 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.I have that with cloud.. But i think people will get that in some time.> > 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. > >You made your text it such a way, i lost track what your exactly trying to say/asking here. (sorry) All i can say is, im a System admin for over (damn..) 28years now.. Everyone has different ideas on how to setup and what to run. Which is totaly fine, for me, only what matters is. Standarized setups. Easy to maintain. Making users happen and reducing there actions to save time. Thats all what i do and thats my only goal. How i do that, that totaly depends on "need" and who maintains it, can they maintain it. I worked with, Windows (all versions expect latest windows server as from 2016+ ), novell (2x-6x), bayens, AS400, Linu,x OS/2. And there is only one thing thats bad for all system, and thats us, the sys admins. (yes, including myself).. What you do want exactly. 1 server and multiple mounts to other server and no domain controller. Use LDAP, ... Ow wait, thats included in a domain controller. Mutiple user mount, NFS/CIFS. So, now try to explain in a simple way what you want. Non-native english people might not get it all what you exactly want. Greetz, Louis
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. > > > > > >