skel at samba.org
Wed Jul 27 04:22:41 GMT 2005
>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.
>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
>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).
>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
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.
More information about the samba-technical