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