[PATCH] samba-tool: make 'samba-tool user create' work like ADUC

Rowland Penny repenny241155 at gmail.com
Thu Jun 25 04:29:45 MDT 2015

On 25/06/15 11:04, Alexander Bokovoy wrote:
> On Thu, Jun 25, 2015 at 10:45:49AM +0100, Rowland Penny wrote:
>>>>> knowledge about edge cases for trust-related operations that is not
>>>>> really documented other than as a code.
>>>>> Adding samba-tool support for ADUC-like functionality isn't going to
>>>>> solve it. It would create a heritage we would need to deal with later.
>>>> And that last statement says it all, you *are* going to have deal with the
>>>> heritage domains, or are you proposing that Samba does what Microsoft did
>>>> with NT-4 and declare every version of Samba that works as it does now
>>>> obsolete and tell everybody they will have to use a new version.
>>> I think you misunderstood and I never said anything like that.
>> Unless you deal with what is out there at the moment, in my opinion, in a
>> round about way that is what you are saying.
> No, I'm not and do not put that in my mouth. :)

OK, I withdraw my comments :-)

>>>> Adding ADUC-like functionality to samba-tool isn't going to do anything but
>>>> make it easier to create users and groups, it isn't adding *any*
>>>> functionality above what is available on ADUC or what samba-tool already has
>>>> (provided you have a pen & paper to keep track of last ID number used).
>>> Unfortunately, your patch isn't forcing manual allocation with
>>> pen&paper. Instead, it does go full way to auto-increment the IDs which
>>> is what prompted the reaction -- it is incorrect way of doing it and it
>>> would be better to have a way to request ID allocation from winbindd
>>> using whatever configured idmap plugin.
>> OK, your average Samba sysadmin is sat at their terminal and needs to create
>> a new AD Unix user with samba-tool. They start typing 'samba-tool user
>> create User passw2rd --given-name=John --surname=Doe --nis-domain=samdom
>> --unix-home=/home/User --login-shell=/bin/false --uid-number=???
>> Hmm. what was the last uidNumber used, sysadmin then consults their records,
>> post-it note stuck on terminal, file on computer, notepad -- you get the
>> idea and comes up with a number '10005' , they add 1 to this number and type
>> that in. Finally they need to add a gidnumber, back to records, what group
>> to use, what is its gidNumber and they finally type  ' --gid-number=10000'
>> on the end. They then press 'Enter' and create the user, they then go back
>> and update their records with the uidNumber they just used.
>> Would you like to explain how this is different from the way my patch works
>> ?
> You patch ignores ID allocation schemas that are configured on Samba AD
> DC with Winbindd, completely. We need to have a single place where logic
> to allocate IDs is done and that is winbindd. Do not add other logic,
> please, use the one that is there already.

Taking a member server as an example, windbind can be setup to work in 
at least two ways, the 'ad' and 'rid' back ends. The 'rid' backend maps 
the users AD RID to a number, this number should be the same on all 
member servers, but not on a DC (at the moment). The 'ad' backend has 
nothing to do with winbind apart from the fact winbind extracts the info 
from AD.
I am *not* adding logic, I am just using what is already there, but in a 
different way. If you come right down to it, the two main ways of using 
windbind do not allocate IDs, they are either mapped or extracted.

>>> This is what I meant by a heritage that we would need to deal with
>>> later.
>>> Also, I don't like the mess that is created by combining formatting
>>> changes with functional ones. It is going to beat us in future when any
>>> specific bug arises and we'll be doing searches for the offending
>>> commit. The way we deal with it is that formatting commits are separate
>> >from functional changes.
>> Could you explain what you mean by 'formatting' and 'functional' , I think I
>> understand the later, but do not have a clue about the former.
> More than half of your patch is reformatting existing code rather than
> adding new feature. Split that into a separate patch, rather than
> combining them together.

OK, I will try and split the patch up, but quite a lot of what I altered 
was because it wouldn't work unless I did alter it i.e one depends on 
the other.

What I could do is to remove most of the patch and just leave the nisadd 
part and then go from there.


More information about the samba-technical mailing list