libmsrpc for Samba 3
Gerald (Jerry) Carter
jerry at samba.org
Wed Jul 6 17:08:19 GMT 2005
-----BEGIN PGP SIGNED MESSAGE-----
Let's keep this on the mailing list in case others
want to jump in.
Chris Nicholls wrote:
| Gerald (Jerry) Carter wrote:
|> The first place to start I think is to figure out how
|> libsmbclient and libmsrpc will work together. Obviously,
|> we'll need libsmbclient for the initial connection
|> and named pipe support. What is the division between
|> these two libs?
| Since MS-RPC is essentially above SMB it seems
| like the natural seperation would be for lbmsrpc to
| sit on top of libsmbclient, so libmsrpc would call
| the necessary functions from libsmbclient to get the
| job done, but not vice-versa.
Correct. let's ignore rpc direct over tcp since
we don't have it in Samba 3 anyways.
| I'm still trying to wrap my head around if/how
| this would be possible technically. However, a
| problem with this approach is that it might
| not offer seamless integration with the
| code that is already around. If an application is
| calling a function in libsmbclient expecting it to
| make the right call (RPC or otherwise) then it might
| be wise to have libsmbclient call the necessary
| functions from libmsrpc. I need to study the code more
| to get a better sense of how libsmbclient is used but
| i'm just wondering if you have any thoughts on this?
I think it is best to make a fresh start here. For example,
if an application wanted to enumerate shares on a
server and currently used a RAP call (and thus were limited
to share names <= 12 character in length), the application
would need to be modified to take advantage of the
newer rpc srvsvc calls.
One question that arises in this model though is what
initialized structures does an rpc connection require
and what does the library take care of itself.
Currently in Samba's client tools one layer initializes
the connection (session setup and tcon to IPC$) before
passing the cli_state* to the rpc calls. Is this the
right model for application writers? Probably not
since it requires too much knowledge of the network
What are the other alternatives we have here?
| I took the approach you suggested, and started by
| commenting out #include "includes.h", i then
| created a new header file rpc_includes.h which
| would #include any necessary headers to compile
| the rpc_client code, from the list I found that
| the following header files are necessary for compilation:
| a number of these header files are included to resolve
| dependencies in other headers, but i guess there's not
| much that can be done about that. Also, since I was
| avoiding includes.h I had to copy over some necessary
| definitions from includes.h (I've included rpc_includes.h
| in case you want to take a look at what was needed
| from includes.h), I'm not too sure what the fate
| of the rpc_includes.h file will be, but for the sake
| this exercise I think it's alright that some
| definitions were copied over.
We may need to split these headers up some more.
passdb.h, nt_printing.h, and secrets.h should be
more server stuff and not really something we want
to include for client apps. This is a good start
though. It's actually shorter than I expected.
Redefining a few necessary macros is probably acceptable
if it is at least manageable.
| For the function prototypes, i realized that proto.h
| pretty much needs includes.h in order for it to work,
| so i decided to find the dependencies for linkage by
| creating a new header rpc_proto.h and just
| copying the prototypes from proto.h into it. This file
| was just meant as a hack to avoid including proto.h,
| i don't really intend to use it for anything but now
| that the dependant files are known, a script could pull
| the necessary prototypes out of the files if need be.
We definitely don't want or need proto.h. That's just
an auto generated file of function declarations.
| So from this i found the source files that are necessary
| to compile all of the rpc_client/*.c files, they are as
This is *much shorter than I expected. And very promising.
| In order to test this out, I whipped up a little makefile
| and tried to compile all of these files and statically link
| them into a libmsrpc.o object. I took it so far as to resolve
| all the dependencies needed to link the rpc_client objects,
| the dependencies for all of the other files is a different
| story entirely :).
| So that's what i've found. If you can't get back to me
| right away that's fine, I should spend the meantime studying
| the code and docs and playing with some captures in ethereal.
Looks like a really good start. Go ahead and create a
source/libmsrpc/ directory in the SOC/SAMBA_3_0/ svn branch
so we can start sharing code. I'm not tied to the rpc_client/*.c
interface so if you want to think about a better interface
client for this client lib, that fine. Or if you think the
current interface is ok, then we can start with that as well.
I think we'll probably end up modeling a lot of the corresponding
interfaces in MSDN here.
Alleviating the pain of Windows(tm) ------- http://www.samba.org
GnuPG Key ----- http://www.plainjoe.org/gpg_public.asc
"I never saved anything for the swim back." Ethan Hawk in Gattaca
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the samba-technical