Fw: samba-tool command structure

Andrew Bartlett abartlet at samba.org
Wed Sep 7 22:19:05 MDT 2011


On Thu, 2011-09-01 at 18:31 +0200, Jelmer Vernooij wrote:
> Hi Giampaolo,
> 
> On 26/08/11 19:39, Giampaolo Lauria wrote:

> > 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.
> Vampire originally was a way to suck everything out of a remote machine 
> in order to be able to replace it. While that is in some ways pretty 
> similar to joining a domain, I think it is quite different (you can't 
> "join" a standalone machine). I'm not at all familiar with the current 
> code though, so perhaps it's not (any longer?) as generic as I was hoping.

The primary domain join (as a DC, or member server) has been under
'samba-tool join' and now 'samba-tool domain join' for quite some time.
It has never been a way to clone a member server, and once you have the
concept of an RODC and a subdomain, the 'vampire' idea of one simple
copy doesn't really apply, even for a DC.  This is particularly because
we now support bidirectional replication with Windows.

Giampaolo,

I've been reviewing your recent patches via Amitay, and I note that you
propose to move vampire, but not into --old-vampire-code.  Please don't
move it until it is either removed, or an option to 'samba-tool domain
join'. 

Metze,

Do you have any particular reason to keep the untested python wrapper of
the vampire code in the user interface?  The libnet_vampire code still
underlies the 'samba-tool domain join' code, and remains tested in the
torture test.  I would like to remove it from the samba-tool UI however,
so we have less code-paths to cover.

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org



More information about the samba-technical mailing list