On 03/04/15 10:19, buhorojo wrote:> On 03/04/15 11:09, Rowland Penny wrote: >> 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. > > So why have you reported it a bug in Samba Bugzilla and labelled its > priority as 'P5 major'? >Because when I reported that bug I thought it *was* a bug, I have since been advised that it isn't and HAVE ACCEPTED THIS!!! Rowland
On 03/04/15 12:19, Rowland Penny wrote:> On 03/04/15 10:19, buhorojo wrote: >> On 03/04/15 11:09, Rowland Penny wrote: >>> 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. >> >> So why have you reported it a bug in Samba Bugzilla and labelled its >> priority as 'P5 major'? >> > > Because when I reported that bug I thought it *was* a bug, I have > since been advised that it isn't and HAVE ACCEPTED THIS!!! > > Rowland >If you have changed your mind, then maybe you should consider either withdrawing the bug report or at the very least updating the same to include reference to this post. Thanks, B.
On 03/04/15 11:27, buhorojo wrote:> On 03/04/15 12:19, Rowland Penny wrote: >> On 03/04/15 10:19, buhorojo wrote: >>> On 03/04/15 11:09, Rowland Penny wrote: >>>> 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. >>> >>> So why have you reported it a bug in Samba Bugzilla and labelled its >>> priority as 'P5 major'? >>> >> >> Because when I reported that bug I thought it *was* a bug, I have >> since been advised that it isn't and HAVE ACCEPTED THIS!!! >> >> Rowland >> > If you have changed your mind, then maybe you should consider either > withdrawing the bug report or at the very least updating the same to > include reference to this post. > Thanks, > B. > >I will not be referencing this thread and I will not be withdrawing the bug report, whilst it turned out not be a bug, it is a lack of an expected feature and whilst the bug report is open it will serve as a reminder to the devs. You can, if you so wish, add to the bug report, explaining that this problem affects you, I would think that the more people it affects, the more chance there will be of getting the feature added. I also think that this thread has run its course and will not be posting on it again. Rowland
Greetings, Rowland Penny!>>>>>> 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. >> >> So why have you reported it a bug in Samba Bugzilla and labelled its >> priority as 'P5 major'? >>> Because when I reported that bug I thought it *was* a bug, I have since > been advised that it isn't and HAVE ACCEPTED THIS!!!You know, if I can't justify the need for additional installation to myself, there's no way I could possibly explain it to my superiors to arrange the acquisition of such installation? And so far, this doesn't make any sense to me at all. Though, it seems we're going in circles. Sorry. -- With best regards, Andrey Repin Friday, April 3, 2015 17:05:43 Sorry for my terrible english...