a proposal for Samba 3.5

[Kurt Pfeifle]

> Andrew Bartlett abartlet at samba.org
> Thu Apr 1 21:41:03 GMT 2004
> 
> On Fri, 2004-04-02 at 04:54, Michael Sweet wrote:
>> tridge at samba.org wrote:
>>  > ...
>>  > It should be relatively easy to replace most uses of RPC in Samba3.5
>>  > with the Samba4 RPC library, except perhaps for the rpcclient tool. I
>>  > would suggest removing the rpcclient tool in Samba3.5, and instead
>>  > work towards writing a new tool with equivalent functionality
>>  > (possibly even basing the new tool on Tim's python or perl interfaces
>>  > to the library).
>>  > ...
>> 
>> I would argue strongly against providing a scripted replacement,
>> as few commercial platforms come with a recent version of Perl or
>> any version of Python.  A C-based tool shouldn't be that much
>> harder to write and would be as portable as Samba itself.
> 
> We need to create and maintain scripting interfaces to the things
> rpcclient calls.  We also need rpcclient - which is only a thin shim
> over these calls.  By maintaining it as a working example of the
> scripting interface, not only do we make it's development easier, we
> ensure that both parts are actively maintained.
> 
> If this were 'smbclient' we were talking about, I would be more
> sympathetic, but rpcclient is considered a developers testing tool at
> best 

This was never made clear. This is the first time I hear this.
Why is rpcclient then compiled by default? Why is it documented in
a man page?

It is different with "tdbtool" and some other utilities. They don't
compile by default and they don't have a man page. That's why simple
souls like myself considered *these* developer tools, not rpcclient.

> and I think it (and smbtorture for that matter) could benefit from
> what scripting brings us.  Is it really that hard to install python or
> perl, for a developer?  (Any more-so than installing samba4 itself?)
> 
> We already have a python dependency in any case, for the (optional) self
> test framework.
> 
>> Also, rpcclient is used by CUPS (among other projects) to install
>> printer drivers for Windows clients; this is very big deal and
>> if rpcclient disappears then we will have to come up with an
>> alternate means of doing this that will also work with Samba
>> 3.0 and earlier.
> 
> CUPS should never have used rpcclient like that,

It is using this for a long time, and never has anyone issued a word
of warning about that.

> nor assumed that our
> internal testing tool 

That "internal testing tool" has received a lot of airtime in the
"Samba-3 HOWTO Collection" and never did a core Samba developer object
to that fact.

That "internal testing tool" was playing a major role in some large
NT --> CUPS/Samba print server migrations.

Maybe we can talk next week about this.

> would have an interface sufficiently consistent
> for use in the way that cupsaddsmb does.
> 
> The tool which we provide for that purpose is 'net' - 

I'll have a look. But currently I am sceptical if I can do with "net"
what I can do with "rpcclient"....

> and I think that
> the tasks CUPS needs to perform should be done via a new incarnation of
> that interface.
> 

Even if "net" was/became a full replacement of rpcclient, the removal
of rpcclient would break a lot of existing (CUPS) installations, if
Samba was upgraded.

Cheers,
Kurt