Fw: samba-tool command structure

Giampaolo Lauria lauria at us.ibm.com
Fri Aug 26 11:39:44 MDT 2011

Hi Jelmer,

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 
configuration settings.

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 
the command. 
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,

Hi Giampaolo,

On 09/08/11 19:57, Giampaolo Lauria wrote:
> Hi,
> I am working on redesigning the samba-tool command to follow the 
> format:
> 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.
> delegation
>          add-service
>          del-service
>          for-any-protocol
>          for-any-service
>          show
What sort of services/protocols would these be, the srvsvc kind?
> diag
>          dbcheck
>          ldapcmp
>          testparm
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.

>   domain
>          exportkeytab
>          join
>          level
>          passwordsettings
>          vampire
Wouldn't exportkeytab and vampire be machine-specific rather than domain 



More information about the samba-technical mailing list