libmsrpc for Samba 3
skel at samba.org
Thu Jul 7 02:01:03 GMT 2005
Gerald (Jerry) Carter wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 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?
At first glance, I thought a structure like SMBCCTX might be a good
idea. However, I think libmsrpc will have groups of functions that are
not closely related to each other (ie. winreg vs. srvsvc vs. eventlog
etc. ) so it doesnt make much sense to keep references to all of them in
one structure. Really only a small amount of data will have to be
stored in a structure in the application itself. Basically client
Netbios name, workgroup/domain, username, and perhaps some space for any
variable data that needs to be stored and maybe some server information,
but it seems like the server information isn't required. I believe all
of the authentication and state information can be stored in struct
rpc_pipe_client (unless i've misinterpreted it's use) and cli_state.
I agree that the application should store as little information as
possible and let the library handle dealing with the cli_state stuff,
much like libsmbclient does, using a server cache to keep track of the
cli_state structure. As you said, the library will be much easier to
work with as developers won't need to worry about the network protocol
> | 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:
> | xfile.h
> | nt_status.h
> | pstring.h
> | talloc.h
> | privileges.h
> | ntioctl.h
> | local.h
> | nterr.h
> | byteorder.h
> | smb.h
> | ntlmssp.h
> | rpc_creds.h
> | rpc_misc.h
> | rpc_dce.h
> | client.h
> | safe_string.h
> | rpc_client.h
> | secrets.h
> | mapping.h
> | passdb.h
> | nt_printing.h
> | 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.
I'll look into this and see how much needs to be redefined to make it
work. I should be able to get that done tonight.
> 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.
I'll add the the rpc_includes.h and rpc_proto.h, along with the quick
and dirty makefile to the source/libmsrpc/ directory for the moment and
get that commited to svn tonight once I widdle down the headers a bit.
As for the interface I'll have to put a bit more thought into it. I
think the current interface is ok for the moment but I figure once I get
a little deeper into it i'll have some good ideas.
> cheers, jerry
> 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