[SAMBA4][PATCH] dd client for samba 4

Andrew Bartlett abartlet at samba.org
Tue Jan 17 23:44:09 GMT 2006


On Wed, 2006-01-18 at 10:12 +1100, James Peach wrote:
> On Tue, 17 Jan 2006 09:26 pm, Andrew Bartlett wrote:
> > On Tue, 2006-01-17 at 16:18 +1100, James Peach wrote:
> > > On Tue, 17 Jan 2006 03:16 pm, James Peach wrote:
> > > > On Tue, 17 Jan 2006 03:06 pm, tridge at samba.org wrote:
> > >
> > > [snip]
> > >
> > > > > Having code like sdd.c in Samba that re-invents popt, and avoids
> > > > > using all the existing command line handling code for options
> > > > > (especially auth options) is something that I'm very reluctant to do,
> > > > > so it would require some very strong justifications!
> > > >
> > > > I guess I don't feel as strongly about this. I expect to use this for
> > > > generating client load. Strictly speaking I don't need _any_
> > > > authentication.
> > > >
> > > > Maybe I could add the popt handling prior to looking at any dd
> > > > arguments? sdd [common samba options] [dd-style options]
> > >
> > > The attached patch implements this ...
> >
> > You still don't use cmdline_credentials.  This global variable is what
> > the POPT_COMMON_CREDENTIALS creates.
> 
> Ok, I didn't understand that this was what you meant. IIRC, the reason I
> wanted to use the SMB URL for the "if" and "of" options is the case where
> you have 2 connections do different servers and you need to have different
> authentication information for each. This will probably be a rare case,
> however, so I can certainly use cmdline_credentials until it's needed.

If or when a change away from cmdline_credentials is made, it should be
fixed for both this tool and for some of the smbtorture commands, which
would also like multiple sets of authentication credentials.  

However, I would warn you that this is actually quite hard to do right
(and easy to do wrong) at the command line level.  Once we are in C code
it is of course easy, now we have those structures.

> On the issue raised on IRC of there already being a dd clone called
> "sdd", I'm more than happy to change the name. cifsdd?
> 
> > I think tridge has a point about making this an smbclient command.  Once
> > this is all done, what will be the difference between the operation of
> > the modified sdd and smbclient -c 'dd .....'?
> 
> First, the actual syntax of smbclient is smbclient -c 'foo' //host/share. This
> creates ambiguity in the dd syntax.
> 
> Where does the data go in this case?
>     smbclient -c 'dd if=/dir/file1 of=/dev/null" //server/share
> 
> What about this case?
>     smbclient -c 'dd if=//server1/share/dir/file1 
> of=/dir/file1" //server/share
> 
> The dd subcommand certainly wouldn't operate like any of the other smbclient
> subcommands.

Perhaps we need to change the syntax a bit more (then do any munging in
a shell wrapper, to better match what you want in for your test harness)

smbclient -c 'blockwrite <local> <remote> <options>'
smbclient -c 'blockread <remote> <local> <options>'

The wrapper script can then pull apart which has the //server/share/
prefix, and call the appropriate subcommand.

> Second, the smbclient syntax is incompatible with existing test harnesses that
> drive dd. The usage I'm planning for this is something like:
>     DD=/usr/samba/bin/sdd SRC=//server/share/foo DST=/dev/null ./test.sh
> 
> Third, the sdd command is carefully constructed to do exactly the IO
> you tell it to as far as possible. If you specify a 32KiB block size,
> then you get a 32KiB read on the wire. To move this code into smbclient
> would require moving its IO path. smbclient would then contain 2 parallell
> IO paths. I don't see how making smbclient more complicated in this way
> is helpful.

smbcacls was a tool created to handle a particular task in Samba, and no
doubt did that task quite well, without disrupting other tools.  It also
broke very often, and was unmaintained and untested for long periods of
time.  

The situation is better these days, particularly thanks to the popt,
better documentation (magic includes of common options) and other
tricks, but there is still a cost.

I'm sorry to be so discouraging.

> > Why the change to popt.h?
> 
> There was a gcc warning; when returning const char * const, the second const
> has no effect.

I would prefer to leave it intact.  That code is meant to be simply the
imported popt project.  We should update it sometime.

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20060118/01cd94cc/attachment.bin


More information about the samba-technical mailing list