libmsrpc comments

[Chris Nicholls]

>Why use a cli_state* in struct _CACSERVERHANDLE instead
>a libsmbclient connection structure ?  the cli_state* stuff
>is pretty messy.  This is probably the biggest question.
>The remaining items are all minor.
>  
>
I was debating with myself about this one and I ended up a bit unsure. I 
kinda didnt want to store a reference to the SMBCCTX becuase of all the 
function pointers in it.  But it does provide a lot of useful 
functionality for handling the underlying connection (even the 
connection function that i have mimics the smbc_server function).  Using 
one also makes for better compatibility with libsmbclient. I'll switch 
it over to a SMBCCTX structure.

>When tracking the _srv_level, I would recommend tracking
>by a numerated type for os.  For example, instead of _srv_level = 1,
>I would use something like server_type = SRV_WIN_NT4.
>  
>
Will do.

>Use True and False instead of 0 and 1 when you mean BOOL.
>(i.e. uint32 _pipes[] should probably be declared as BOOL _pipes[])
>  
>
Not too sure what I was thinking here.  When i first typed it I thought 
I might be storing something else in there, but a BOOL is the best way 
to go.

>I'd rather not have a function an structure by the same name.
>That get pretty confusing and in fact I think tridge had a technical
>reason for not doing so in Samba 4.  For example,
>int cac_LsaOpenPolicy(CacServerHandle *hnd, struct cac_LsaOpenPolicy *op);
>  
>
I'll fix this.

>If you have any test code you are working with to exercise
>the new rpc functions, pleas check that in as well.  Just so
>we can all play with it.
>  
>
It was going to be my next step. I was going to add a couple more lsa 
functions and then get some test code written up.

>It is probably easier to clean up the "implicit declaration of
>function XX" warnings along the way than wait until the end.
>If you compile with --enable-developer, you will see what I mean
>(in case you aren't already).
>  
>
oops :)

>Beware of using a TALLOC_CTX* in the server handle for client
>calls since the server handle is supposedly long lived.  You'll
>end up with memory bloat here.
>  
>
hadnt (but should have) considered that.   I wanted to  give a developer 
the option of managing their own talloc context or letting the library 
handle it.   But there are other ways of doing that  and I don't think 
it's a huge deal either way.  I'll take it out.

>Finally, we probably need a good solution to deal with the
>security bits when opening handles.  I doubt that redeclaring them
>in libmsrpc.h is a good idea.
>  
>
I was stuck on this one.   I'd like to be able to provide a generic set 
of access masks that can be used for any pipe and also make them easy to 
find in documentation.  My idea here was to redefine them, so they could 
be passed through directly for some pipes (like LSA) and then translate 
them for pipes that use different access masks (like the registry).  
It's probably not the ideal solution since there isnt really direct 
mapping between the different sets. other options are to force the 
developer to use the standard security bits, or to come up with a new 
set of masks.  Any thoughts?

>Overall, things look like they are going really well.  Given the 4
>and 1/2 weeks left in google's summer, how many rpc pipes do you
>want to try to complete?  And how do you want to demo the library?
>At one point you had mentioned a command line user manager, or
>registry editor.
>
>
>  
>
I think at a minimum i'd like to get through lsarpc, winreg, samr, 
spoolss and netlogon (given the current client code). srvcsvc is quite 
important as well and it might be possible to complete it in time.  Does 
this sound reasonable?  Ultimately, i'd like to see this through to 
completion and get all of the pipes and perhaps make some useful apps to 
work with is.

As for a demo, I'd like to develop something that shows use of all the 
supported pipes but also demonstrates multiple operations on a pipe 
during the course of execution.

A user manager or registry editor would demonstrate a number of 
operations but don't show off many pipes.  I'm not sure if i could do 
justice to a command line registry editor in the short time I will have, 
but it would be a very usefull program IMHO.

I believe you suggested something similar to net rpc at one point. There 
are only a few operations that are done each execution, but it provides 
access to a number of pipes.  This might be a good way to go, it could 
be quite useful in testing, and I could develop it as I go along and 
tidy it up for a proper demo.  Maybe i can make it do batch commands or 
something to demonstrate having active connections to a number of pipes 
at a time, etc. Any preferences here?


Also, did you take a look at Makefile.in by any chance? I'm not sure if 
i've set things up the proper way.

Chris