management of Samba4

[James Peach]

On Fri, Jun 03, 2005 at 10:51:09PM +1000, Andrew Tridgell wrote:
> James,
> 
>  > So I think this proposal will work well for smbstatus-style apps, and I
>  > can imagine building a really useful samba debugger on top of it. I'm
>  > not sure it is suitable for exporting performance statistics, however.
> 
> I am not proposing that it be used for gathering performance
> statistics. I am proposing it be used to replace the sorts of
> information shown by smbstatus in Samba3, plus a lot more detailed
> information from other subsystems (for example information on the wins
> server, the ldap server etc).

Understood. I interpreted "reporting packets counts" a bit too broadly :)

> For performance monitoring you really do need to use a shared memory
> type of scheme, but what you do is you use a
> START_MONITORING/STOP_MONITORING type of message, so that the (small)
> overhead of doing performance monitoring is not paid when you don't
> need it.
> 
> I also think it is reasonable that the performance monitoring code not
> be as portable as the smbstatus style of monitoring. The 'list of open
> files' information needs to be available for all platforms, whereas
> not being able to do fine grained performance monitoring on systems
> with no way to setup shared memory is OK by me.
> 
> Finally, there are quite different security constraints. With Samba3
> we have the problem that anyone with read access to the various tdb
> databases needed for smbstatus to work can lock those databases (as
> setting read locks in posix relies only on read access to the
> underlying file). That is a potential denial of service attack. Using
> a messaging system we can avoid that problem by building in the
> ability to determine who is sending the message and allowing the
> service function to decide what information to give out depending on
> the user asking for it.
> 
> We will eventually build a performance monitoring system for Samba4,
> but what I proposed earlier today is not it.

This all sounds perfectly reasonable. Thanks for the clarification.

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