management of Samba4

[James Peach]

On Fri, Jun 03, 2005 at 01:10:43PM +1000, Andrew Tridgell wrote:
> After our discussions in the web server thread, I've been thinking a
> bit more about the low level details of management and monitoring
> interfaces in Samba4. 
> 
> To try to crystalise things a bit, the specific bits of information I
> have been trying to work out how to report are:
> 
>   - lists connected users
>   - lists of open files in the ntvfs backends
>   - counts of packet types in the nbt server
> 
> This is only a tiny subset of what we want to be able to report, but
> its acts as a good basis for thinking about the types of solutions we
> could use. Each of the 3 bits of information above illustrates a type
> of problem we need to solve.
> 
> The goals I want to meet are:
> 
>   - should be easy to add new sources of information in the server
>     code
>   - should be accessible from js scripts
>   - should not reduce performance when not being used
>   - should work on all our supported platforms

[snip]

> So, how can we put together a framework for gathering this type of
> information while meeting the above goals? I'd like to propose the
> following:
> 
>  - using our smbd messaging layer (the one based on unix domain
>    datagram messages) as the basic transport. 
> 
>  - add a NDR encoded layer on top of this transport
> 
>  - use IDL to write the structures that will be accessible, allowing
>    pidl to generate the marshalling/unmarshalling code for these
>    structures.

I like this idea. It will add some latency to a monitoring application,
but that's probably ok because normal sampling frequencies would be in
order of seconds.

A monitoring app would need to link Samba libraries to do the NDR
encoding, right? What would the license on this be?

>  - use the pidl ejs backend that jelmer has started on to provide
>    interfaces to these functions from ejs
> 
>  - add the ability to broadcast a message to a class of smbd tasks
>    (for example, to all smb_server tasks).

So a monitoring app could get a count of all the smb packets by
broadcasting a request to all smb_server tasks and then summing them?
That sounds good.

> I know this sounds a bit like reinventing the ncalrpc transport, but
> it isn't quite. For a start, ncalrpc is over connected stream sockets,
> whereas I want to use unix domain datagrams as otherwise we will run
> out of file descriptors when getting results from 1000 smbd
> processes. Plus, I don't want to have to setup a full rpc server in
> each smbd task, instead I want code to be able to do something like:
> 
>   smsg_register_handler(SMSG_LIST_OPEN_FILES, my_function);
> 
> in source/ntvfs/posix/vfs_posix.c and have my_function() be called
> with the unmarshalled structures all setup, and be able to send reply
> data by filling in the .out sections of the passed structure.

So the performance monitoring messages can be extensible and
{en,dis}abled at runtime. Great!

> It will really be more like a ncadg_ interface, but without any of the
> bind stuff and with awareness of smbd sub-tasks and how to talk to
> them.
> 
> As an initial goal, I'd like to write the equivalent of the Samba3
> smbstatus command as an ejs script. That should allow the framework to
> be tested quite well, and will naturally slot into an element of the
> web management interface once done (as the same ejs functions will be
> used).
> 
> The low level messaging code in lib/messaging/ will need a bit of
> work to support all this stuff. In particular it currently uses a
> connected unix datagram socket, which means it creates a full file
> descriptor for each message. That is no good when you want to send off
> thousands of these messages, so I'm going to see if I can make it work
> with socket_sendto() (which means adding that to
> lib/socket/socket_unix.c). That should also make it faster.
> 
> For platforms without unix domain datagram sockets, they would need to
> write an alternative messaging system with the same api as
> lib/messaging/ and abstract the code to allow the transport to be
> selected (at either compile time or runtime).
> 
> At the end of all this we should have a really good system for
> allowing any internal data structure in any part of smbd to be easily
> exposed to our management interfaces, while still scaling well, and
> not incurring any overhead when management calls are not being
> used. It should then be an easy task to write the individual pages of
> the web management interface, and (if desired) write command line
> versions in ejs.
> 
> Cheers, Tridge

-- 
James Peach | jpeach at sgi.com | SGI Australian Software Group
I don't speak for SGI.