Usability of 'samba-tool domain provision'

Andrew Bartlett abartlet at samba.org
Thu Jun 2 13:02:41 UTC 2016


On Thu, 2016-06-02 at 12:28 +0100, Rowland Penny wrote:
> On 02/06/16 09:17, Andrew Bartlett wrote:
> > On Thu, 2016-06-02 at 08:56 +0100, Rowland Penny wrote:
> > 
> > > The whole thing that started this was that the NetBIOS domain
> > > name
> > > didn't have enough 'help', the same went for the realm name, and
> > > this
> > > cannot really be fixed without a total re-write of 'samba-tool'.
> > > This
> > > is
> > > because it comes from 'sambaopts'
> > > 
> > > Why can't we change the syntax? just because external scripts use
> > > samba-tool as it is now, isn't really a good enough reason, do we
> > > totally guarantee that samba-tool will never change?
> > Pretty much.
> 
> Well, in my opinion, that is just wrong, if things cannot change, how
> do 
> we progress ??
> 
> > For this reason we have to be pretty careful about our
> > choices here, as we end up stuck with them.  See for example
> > 'smbpasswd' which has a totally non-standard (for Samba) syntax.
> 
> Your reference to 'smbpasswd' is a bit different, this is, as far as
> I 
> am aware, written in 'C' and then compiled, unlike samba-tool which
> can 
> be examined easily because it is written in 'Python'.

The language used makes no difference to those running the command line
tool.

> > 
> > I'm not saying we have never changed a syntax, but like smb.conf
> > options changes, it should be a last resort for known to be rarely
> > used
> > options, and even then because of Samba's wide use, we will always
> > find
> > someone who depended on it.
> 
> Ah, but you can hardly call 'realm' & 'domain' rarely used options,
> in 
> fact you cannot provision a domain without them, which is where the 
> problem started from :-)

Exactly.  Therefore they can't be changed without breaking it for
folks.

> >    
> > 
> > > I seem to remember a similar argument about the 'debug' library
> > > and
> > > this
> > > was changed.
> > Command line tools are an external ABI, and we go to great lengths
> > not
> > to change their behaviour.
> 
> These patches don't actually change their behaviour, they just
> enforce 
> that 'realm' & 'domain' are given

The fact that the selftest scripts had to change indicates that they
changed in behaviour.

> > debug is an internal ABI we shared with two
> > other projects (ctdb and openchange).  To deal with that (and for
> > many
> > other reasons) we brought ctdb in house, and are still trying to
> > smooth
> > things over with the openchange effort.
> > 
> > There will be other ways to fix the help, we just can't change the
> > syntax in this case.
> > 
> > Sorry,
> > 
> > Andrew Bartlett
> > 
> 
> Ok, before I alter my patches, can you confirm, it is just the change
> of 
> 'realm' & 'domain' from options to args, you are against, or is there
> anything else ?

The user should not be prompted about use_xattrs.  In fact, just to
demonstrate that Samba development is always an art both of knowing the
rules and of knowing when not to apply them, I would argue we should
actually drop the --use-xattrs option, or at least hide it.

https://git.samba.org/?p=asn/samba.git;a=commitdiff;h=4ee1d4b209a1e11f2
b62087e09d9f221d85bd137

For the password check, I would prefer if we re-used the same
complexity check as the DB will use, perhaps by adding a python binding
to the C function in use.  Otherwise I fear the two will diverge, and
just cause further confusion.

https://git.samba.org/?p=asn/samba.git;a=commitdiff;h=f56bb2c2edbc7c0ad
406d642f2de2f09a25b85b2

-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba






More information about the samba-technical mailing list