a proposal for Samba 3.5
kpfeifle at danka.de
Fri Apr 2 19:26:07 GMT 2004
> 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
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.
More information about the samba-technical