Fw: samba-tool command structure
lauria at us.ibm.com
Fri Aug 26 11:39:44 MDT 2011
I am sorry it took so long to get back to you. Please keep in mind that I
am a new samba team member, so I feel that your input is very important.
Here are my answers to your questions:
1) For the delegation command, I first would like to say that it has been
a top-level command even before I started looking at this regrouping work.
While I still think it should be a top-level command due to the fact that
it has many subcommands, we should have its authors answer your specific
>From the command, I see:
# Copyright Matthieu Patou mat at samba.org 2010
# Copyright Stefan Metzmacher metze at samba.org 2011
# Copyright Bjoern Baumbach bb at sernet.de 2011
Hopefully one of those gentlemen may give us a feedback.
2) In general, I think it is easier to find things that are grouped by
category. It would also be nice to have a single object (diag in our case)
as a single entry for the administrator to validate different
I think testparm belongs to a diag-like command.
After looking at the "testparm" code in more details, I noticed that it
does nothing more than validating the values for each keyword in the
config file. The fact that it allows the user to specify a section or a
keyword, is just to simply dump that section or keyword after validating
all the keyword values anyway. Unless I am missing something, I am not
sure how useful the keyword value(s) dump can be or whether it is a bug in
I am not crazy about the diag naming myself but could not come up with
anything better for the time being. Please feel free to suggest a better
3) While keytab is a concept that exists outside of Samba, my
understanding is that the exportkeytab in Samba4 is strictly referring to
a keytab from an AD domain. I've referenced to this link:
Regarding the vampire command, here is a comment from Andrew Bartlett:
"'samba-tool domain vampire' is just a special case of 'samba-tool domain
join', using a different codebase. it should be an option for
developers (--old-vampire-code or such) not a top level command), as it
is no longer the preferred code."
Being only a special case of "join", then maybe it is a domain subcommand.
Otherwise, we would have to move the "join" command as well.
Thank you very much for your comments,
On 09/08/11 19:57, Giampaolo Lauria wrote:
> I am working on redesigning the samba-tool command to follow the
> samba-tool<object> <action> <parameters> <options>
Thanks for looking at fixing the hierarchy for samba-tool. I agree it's
a bit of a mess at the moment :)
I think it makes sense to use the structure you suggest for some of the
subcommands of samba-tool. I don't think it's a good idea for all of
them, and would make samba-tool harder to use if we are strict about this.
> With that in mind, I've come up with the following structure for the
> top-level objects and their actions. Please keep in mind that some of
> current action names need to be changed to reflect an action.
> Also, we are thinking of integrating the "provision" command into
> samba-tool under domain as: samba-tool domain provision
> Your comments are greatly appreciated.
What sort of services/protocols would these be, the srvsvc kind?
These are much more discoverable as top-level commands, hiding them
under "diag" just makes them harder to use I think. "diagnosis" doesn't
really cover some of the uses of testparm, such as retrieving the value
of a single current smb.conf option.
Perhaps the general management of smb.conf options could be moved into a
separate subcommand, and we can just have a simple "samba-tool check"
that covers both the "check" part of testparm as well as e.g. things
like checking the consistency of the database.
Wouldn't exportkeytab and vampire be machine-specific rather than domain
More information about the samba-technical