On Sat, 1 Dec 2018 22:17:58 +0000 Simon Hobson <li...@thehobsons.co.uk> wrote:
> Rowland Penny <rpe...@samba.org> wrote: > > >> I think what Roland was getting at here is the number of users and > >> how they are dealt with makes a huge difference. > >> > >> At one extreme, you have 28 seats, each one of them has a user such > >> as "user1", and you can simply use /etc/passwd & /etc/shadow to > >> manage that single user one each seat. You could probably build one > >> software image and simply image all 28 machines with that one > >> image. > > > > This would entail running Samba as a workgroup and, once you get > > past about 10 machines, it get unwieldy, you have to create the > > exact same users on every machine you want them to connect to and > > keep their passwords in sync. This can rapidly become a nightmare, > > this applies if you decide to go with NFS instead. > > Indeed, but this scenario is for a fixed setup where the users (28 of > them) are setup once and then there is no further user maintenance > going forward. In such a scenario, there's little point in going for > the complexity of setting up AD - as you say, a one-off setup of the > users in Samba. The clients could potentially be configured to > auto-login to the desktop (or training system) on boot so the users > don't even need to know about users. Easy for users, no security. Been there, done that, but with that many computers it becomes a struggle, the users want to use different computers and cannot because they are not set up on that computer, believe me, if you are setting something up of this size, a domain is the way to go. It also helps if a computer decides to turn its toes up and die, you just wheel a spare machine out and use that instead. > > >> At the other extreme, every person has their own login and can use > >> any seat at any time (and there are hundreds or even thousands of > >> them) so that progress/results can be logged for each person. In > >> this case, you will really need a centralised user management such > >> as Roland described using Samba & AD. You could still image each > >> machine from one common image - but you'll need to do some > >> post-imaging setup to give each machine a unique set of > >> identifiers etc for the AD to work properly. > > > > If you run Samba as an AD DC and join the clients to this, you only > > have to create the users & groups once and the password is only > > stored in one place, the DC. > > Exactly - for many users, and especially if the users are dynamic, > then it's the only sane way to do it. > > And it also means that each user has their own personal login & home > directory so (if it isn't stored in a database that's part of the > training system) there is somewhere for the system to store each > users progress etc. > > Which leads to another question ... Does the training system itself > have a user directory etc ? This also has an impact on the solution > chosen. > > If the training system has a logon for each user and stores (eg) > progress information in it's own database, then it makes little sense > to also configure each user separately to the OS (eg using Samba & > AD). Just setup the machines as above with a single user and manage > users via the training system. On the other hand, if the database > (the schema, not just the DB engine) is "open" enough then it may be > possible to use that as an authentication source - giving each user > their own OS level login which is the same as the traingin system > login, but using just the one database. > It was my understanding this was to be on a separate network. > Many possibilities - the "best" for any setup depends on answers to > these sorts of questions. > Personally, (and I repeat, I am biased), I would run 2 Samba AD DC's and at least one Samba Unix domain member as fileserver. Rowland _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
