management of Samba4

[Andrew Tridgell]

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).

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.

Cheers, Tridge