Age | Commit message (Collapse) | Author | Files | Lines |
|
- Work on server side and local COM support (should work, just no
example classes yet)
- Use vtables so that local and remote calls can be used transparently
- Generate 'proxies and stubs' rather then heavily modified code in client.pm and server.pm. proxies (client side code) are generated in proxy.pm, stubs (server side dispatchers) are generated in stubs.pm
- Support registering classes and interfaces
- DCOM interfaces no longer have to be in the same IDL file as their
base interface, which will allow us to split up dcom.idl
(This used to be commit 7466947a23985f9bb15209b67880f7b94dc515c8)
|
|
Both subsystems and modules can now have init functions, which can be
specified in .mk files (INIT_FUNCTION = ...)
The build system will define :
- SUBSYSTEM_init_static_modules that calls the init functions of all statically compiled modules. Failing to load will generate an error which is not fatal
- BINARY_init_subsystems that calls the init functions (if defined) for the subsystems the binary depends on
This removes the hack with the "static bool Initialised = " and the
"lazy_init" functions
(This used to be commit 7a8244761bfdfdfb48f8264d76951ebdfbf7bd8a)
|
|
when it gets NT_STATUS_NET_WRITE_FAULT
metze
(This used to be commit 084845c1ab5e8acdb91f1d93b87d3f58e5de1bfd)
|
|
metze
(This used to be commit 0cf0c3646038574e73c77a0b7adbdf6d04fe7207)
|
|
structures in the generated rpc server code
(This used to be commit 60838a0f94ef2b2f27a6f1b3c413481e94c69602)
|
|
- added server side support for schannel type 23. This allows WinXP to establish a schannel connection
to Samba4 as an ADS DC
- added client side support for schannel type 23, but disabled it as currently the client
code has now way of getting the fully qualified domain name (which is needed)
- report dcerpc faults in the server code in the log
(This used to be commit 55e0b014fe14ca8811b55887208a1c3147ddb0d2)
|
|
(This used to be commit ee65e43d4dd0bf78a877b918991aa60f44f435b5)
|
|
servers. Previously the server pipe code needed to return the RPC
level status (nearly always "OK") and separately set the function call
return using r->out.result. All the programmers writing servers
(metze, jelmer and me) were often getting this wrong, by doing things
like "return NT_STATUS_NO_MEMORY" which was really quite meaningless
as there is no code like that at the dcerpc level.
I have now modified pidl to generate the necessary boilerplate so that
just returning the status you want from the function will work. So for
a NTSTATUS function you return NT_STATUS_XXX and from a WERROR
function you return WERR_XXX. If you really want to generate a DCERPC
level fault rather than just a return value in your function then you
should use the DCESRV_FAULT() macro which will correctly generate a
fault for you.
As a side effect, this also adds automatic type checking of all of our
server side rpc functions, which was impossible with the old API. When
I changed the API I found and fixed quite a few functions with the
wrong type information, so this is definately useful.
I have also changed the server side template generation to generate a
DCERPC "operation range error" by default when you have not yet filled
in a server side function. This allows us to correctly implement
functions in any order in our rpc pipe servers and give the client the
right information about the fault.
(This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
|
|
a dcesrv module and also use the autogenerated boilerplate
you can just use:
#define DCESRV_INTERFACE_<UPPERCASE_INTERFACE_NAME>_BIND <interface_name>_bind
#define DCESRV_INTERFACE_<UPPERCASE_INTERFACE_NAME>_UNBIND <interface_name>_unbind
the prototype for the functions are the same as in
struct dcesrv_interface {
...
/* this function is called when the client binds to this interface */
NTSTATUS (*bind)(struct dcesrv_call_state *, const struct dcesrv_interface *);
/* this function is called when the client disconnects the endpoint */
void (*unbind)(struct dcesrv_connection *, const struct dcesrv_interface *);
...
};
e.g.
#define DCESRV_INTERFACE_WINREG_BIND winreg_bind
#define DCESRV_INTERFACE_WINREG_UNBIND winreg_unbind
metze
(This used to be commit ae97f5f50b0d00889f29e1903513cee88891545d)
|
|
metze
(This used to be commit 5ac4f878687eb0fa95a2e5830a8372168a27d3b3)
|
|
- implement the interface_by_name() and interface_by_uuid() hooks
for the autogenerated dcerpc server boilerplates.
metze
(This used to be commit 0b6a291eb4b353259ad5b72f8731a5504d9dc8c7)
|
|
metze
(This used to be commit 61ec710518469876ccc48d57b5fee5d6ead3d482)
|
|
1.) We now register endpoint servers add startup via register_backend()
and later use the smb.conf 'dcerpc endpoint servers' parameter to setup the dcesrv_context
2.) each endpoint server can register at context creation time as much interfaces as it wants
(multiple interfaces on one endpoint are supported!)
(NOTE: there's a difference between 'endpoint server' and 'endpoint'!
for details look at rpc_server/dcesrv_server.h)
3.) one endpoint can have a security descriptor registered to it self
this will be checked in the future when a client wants to connect
to an smb pipe endpoint.
4.) we now have a 'remote' endpoint server, which works like the ntvfs_cifs module
it takes this options in the [globals] section:
dcerpc remote:interfaces = srvsvc, winreg, w32time, epmapper
dcerpc remote:binding = ...
dcerpc remote:user = ...
dcerpc remote:password = ...
5.) we currently have tree endpoint servers: epmapper, rpcecho and remote
the default for the 'dcerpc endpiont servers = epmapper, rpcecho'
for testing you can also do
dcerpc endpoint servers = rpcecho, remote, epmapper
dcerpc remote:interfaces = srvsvc, samr, netlogon
6,) please notice the the epmapper now only returns NO_ENTRIES
(but I think we'll find a solution for this too:-)
7.) also there're some other stuff left, but step by step :-)
This patch also includes updates for the
register_subsystem() , ntvfs_init(), and some other funtions
to check for duplicate subsystem registration
metze
(hmmm, my first large commit...I hope it works as supposed :-)
(This used to be commit 917e45dafd5be4c2cd90ff425b8d6f8403122349)
|
|
when starting a pipe. Thanks to metze for a script that gave the idea.
do something like this to use it:
pidl.pl --parse --template librpc/idl/XXX.idl > rpc_server/XXX/rpc_XXX.c
then fill in the functions in rpc_XXX.c
(This used to be commit 68e71d7497ddc7b8239fc4bd7cb3e780a1f53a39)
|
|
for the server rpc boilerplate to correctly generate for multiple
interfaces on an endpoint
(This used to be commit 56143689ecf623e8a6ef5c453e6ad1ca9404411c)
|
|
on some systems
(This used to be commit a4aa9168c0f80cf6e758c380d41335db50d06869)
|
|
pipe.
The server side code gets generated as librpc/gen_ndr/ndr_NAME_s.c and
gets included in the pipe module
(This used to be commit bd3dcfe5820489a838e19b244266bd9126af5eb4)
|