On 19:54:24 wrote Andrey Repin:> Greetings, Rowland Penny! > > >>> nss/winbind does work, yes, there is 1 missing file, just created > >>> it. ( and this is not needed on a DC ! ) > >> > >> So you are telling us that something that returns: > >> /bin/false > >> > >> when: > >> /bin/bash > >> is specified in the database is a piece of software that is > >> working? > > > > You only need a shell if you are logging into the DC and you > > shouldn't be, the samba wiki couldn't be much plainer, it is not > > recommended to use the DC as a fileserver! > > You can recommend whatever you like, the reality is that there's no > spare hardware is coming my way alongside your recommendations. > And I've been bitten by virtualization one time too many already to > feel reluctant to implement it in production. > Just check the last thread I started. > > > However, if you must use the DC as a fileserver, investigate the > > 'template' lines for smb.conf > > I can't see, how it can make a difference, if I'm setting winbind on > DC or a member server.OK. You dont understand it. winbind exists in two incarnations. winbind on samba dc, version 4.0.x and 4.1.x, winbindd (with two d) on all other samba versions.> The information is coming from same place - > from AD.Simply false. Read the docs. Information may be stored in AD, passwd db, nis, idmap.ldb or computed on the fly. Sometimes you have two stores at the same time.> What makes it behave differently, if set on different > server?Different approaches for the same thing!! Mapping M$ identities to posix identities could be quite complex. -- Regards Harry Jede
On 02/04/15 20:14, Harry Jede wrote:> On 19:54:24 wrote Andrey Repin: >> Greetings, Rowland Penny! >> >>>>> nss/winbind does work, yes, there is 1 missing file, just created >>>>> it. ( and this is not needed on a DC ! ) >>>> So you are telling us that something that returns: >>>> /bin/false >>>> >>>> when: >>>> /bin/bash >>>> is specified in the database is a piece of software that is >>>> working? >>> You only need a shell if you are logging into the DC and you >>> shouldn't be, the samba wiki couldn't be much plainer, it is not >>> recommended to use the DC as a fileserver! >> You can recommend whatever you like, the reality is that there's no >> spare hardware is coming my way alongside your recommendations. >> And I've been bitten by virtualization one time too many already to >> feel reluctant to implement it in production. >> Just check the last thread I started. >> >>> However, if you must use the DC as a fileserver, investigate the >>> 'template' lines for smb.conf >> I can't see, how it can make a difference, if I'm setting winbind on >> DC or a member server. > OK. You dont understand it. winbind exists in two incarnations. winbind > on samba dc, version 4.0.x and 4.1.x, winbindd (with two d) on all other > samba versions. > >> The information is coming from same place - >> from AD. > Simply false. Read the docs. > Information may be stored in AD, passwd db, nis, idmap.ldb or computed > on the fly. Sometimes you have two stores at the same time. > >> What makes it behave differently, if set on different >> server? > Different approaches for the same thing!! Mapping M$ identities to posix > identities could be quite complex. >Andrey There is a good choice. Put all your data in the same database. All data in AD, serving files from the DC. Forget winbind. Use sssd instead. It does exactly what you want. A server just like windows intended. One box for everything. No nis, no separate idmap database, nothing on the fly. Just a server.
On 20:55:10 wrote buhorojo:> On 02/04/15 20:14, Harry Jede wrote: > > On 19:54:24 wrote Andrey Repin: > >> Greetings, Rowland Penny! > >> > >>>>> nss/winbind does work, yes, there is 1 missing file, just > >>>>> created it. ( and this is not needed on a DC ! ) > >>>> > >>>> So you are telling us that something that returns: > >>>> /bin/false > >>>> > >>>> when: > >>>> /bin/bash > >>>> is specified in the database is a piece of software that is > >>>> working? > >>> > >>> You only need a shell if you are logging into the DC and you > >>> shouldn't be, the samba wiki couldn't be much plainer, it is not > >>> recommended to use the DC as a fileserver! > >> > >> You can recommend whatever you like, the reality is that there's > >> no spare hardware is coming my way alongside your > >> recommendations. And I've been bitten by virtualization one time > >> too many already to feel reluctant to implement it in production. > >> Just check the last thread I started. > >> > >>> However, if you must use the DC as a fileserver, investigate the > >>> 'template' lines for smb.conf > >> > >> I can't see, how it can make a difference, if I'm setting winbind > >> on DC or a member server. > > > > OK. You dont understand it. winbind exists in two incarnations. > > winbind on samba dc, version 4.0.x and 4.1.x, winbindd (with two > > d) on all other samba versions. > > > >> The information is coming from same place - > >> from AD. > > > > Simply false. Read the docs. > > Information may be stored in AD, passwd db, nis, idmap.ldb or > > computed on the fly. Sometimes you have two stores at the same > > time. > > > >> What makes it behave differently, if set on different > >> server? > > > > Different approaches for the same thing!! Mapping M$ identities to > > posix identities could be quite complex. > > Andrey > There is a good choice. Put all your data in the same database.Best approach, if it is possible.> All data in AD, serving files from the DC.small server approach, often unwanted.> Forget winbind. Use sssd instead.winbind, nslcd and sssd could do id mapping. Which of them is the best one? The one which fits your needs. Yes, here is no holy gral.> It does exactly what you want. A server just like windows > intended.No, just your opinion.> One box for everything.Once again, a small server fan. Others have other needs.> No nis, no separate idmap > database, nothing on the fly. Just a server.-- Regards Harry Jede
Greetings, Harry Jede!>> You can recommend whatever you like, the reality is that there's no >> spare hardware is coming my way alongside your recommendations. >> And I've been bitten by virtualization one time too many already to >> feel reluctant to implement it in production. >> Just check the last thread I started. >> >> > However, if you must use the DC as a fileserver, investigate the >> > 'template' lines for smb.conf >> >> I can't see, how it can make a difference, if I'm setting winbind on >> DC or a member server. > > OK. You dont understand it. winbind exists in two incarnations. winbind on > samba dc, version 4.0.x and 4.1.x, winbindd (with two d) on all other samba versions.I have same Samba version on both, so, doesn't apply.>> The information is coming from same place - >> from AD. > > Simply false. Read the docs.> Information may be stored in AD, passwd db, nis, idmap.ldb or computed on > the fly. Sometimes you have two stores at the same time.Where information MAY come from is irrelevant. I told you, where it is coming from in my case.>> What makes it behave differently, if set on different >> server?> Different approaches for the same thing!! > Mapping M$ identities to posix identities could be quite complex.I set the same program in the same fashion on two OS installations of the same version - and suddenly it behave differently, depends on the server it runs on, the phase of the moon and the height of snow cover on Alaska? See above, I can compress this phrase into one word, starting with "b". And that would not be a "bug". -- With best regards, Andrey Repin Friday, April 3, 2015 00:46:16 Sorry for my terrible english...
On 02/04/15 22:54, Andrey Repin wrote:> Greetings, Harry Jede! > >>> You can recommend whatever you like, the reality is that there's no >>> spare hardware is coming my way alongside your recommendations. >>> And I've been bitten by virtualization one time too many already to >>> feel reluctant to implement it in production. >>> Just check the last thread I started. >>> >>>> However, if you must use the DC as a fileserver, investigate the >>>> 'template' lines for smb.conf >>> I can't see, how it can make a difference, if I'm setting winbind on >>> DC or a member server. >> >> OK. You dont understand it. winbind exists in two incarnations. winbind on >> samba dc, version 4.0.x and 4.1.x, winbindd (with two d) on all other samba versions. > I have same Samba version on both, so, doesn't apply. > >>> The information is coming from same place - >>> from AD. >> >> Simply false. Read the docs. >> Information may be stored in AD, passwd db, nis, idmap.ldb or computed on >> the fly. Sometimes you have two stores at the same time. > Where information MAY come from is irrelevant. > I told you, where it is coming from in my case. > >>> What makes it behave differently, if set on different >>> server? >> Different approaches for the same thing!! >> Mapping M$ identities to posix identities could be quite complex. > I set the same program in the same fashion on two OS installations of the same > version - and suddenly it behave differently, depends on the server it runs > on, the phase of the moon and the height of snow cover on Alaska? > See above, I can compress this phrase into one word, starting with "b". And > that would not be a "bug". > >OK, from what you have posted, I am surmising that you are using samba 4.2.0, in which case you will be using winbindd on all samba servers. Now, whilst winbindd is in use on all servers, it is used differently depending on what the server is. If it is a DC, the samba daemon is started and then this starts the smbd & winbindd daemons, unfortunately, it would appear that not all the links are there to use all that winbindd could provide. This means whilst you get the uidNumber & the primarygroupid, you do not get anything else, this is not a bug, it is a lack of a feature. On a member server, you do not use the samba daemon, you start the smbd, nmbd & winbindd daemons, with this setup, you get all possible rfc2307 attributes. By default, winbindd does not enumerate users & groups, so whilst 'getent passwd' will only show local users, 'getent passwd <a domain user>' should show the info for the user. However, before this will work, a couple of things have to be done, you need 'winbind' in the passwd & group lines in /etc/nsswitch.conf, you also need to have 'libnss_winbind.so.2' in the correct place for your distro. Rowland