smbwall

[David Lee]

On Sat, 2 Feb 2002, Andrew Bartlett wrote:

> [...]
> Also, I feel that the /dev/smb/? namespace is a good one - it mirrors
> FTPs utmp semantics and allows the admin to quickly distinguish between
> SSH/telnet logins and Samba connections.  If 'write' and 'wall'
> functionality is desired, I think that some kind of daemon listening on
> these 'terminals' (actually pipes in a dir) is the desirable solution.  

I agree that the "/dev/smb" namespace is good (as was illustrated by
Toomas's example).  No disagreement there, Andrew! 

The only reason that I personally started aligning myself with using
pre-existing pty/pts as the mechanism was simply, and solely, that those
devices already exist in typical systems, so it would forestall the
debates about how these things get created in the first place. 

Andrew says "If 'write' and 'wall' functionality is desired ...".  If that
were the entire picture, the remainder would be OK-ish, at least for
further exploration.  But the picture is bigger: I can also envisage
things within smbd itself being able profitably to use a message mechanism
by a clean subroutine interface.

> It should be noted that none of this actually requires modification to
> Samba - even now!.  If you want to make this happen - simply write a
> daemon that listens on /dev/smb/0 - /dev/smb/x (where x is the maximum
> number of connections you expect to receive).  It can include its own
> code to read sessionid.tdb and the message sending code to bug the
> client with it.

Don't several systems have a limit around 1024 for the number of open fds? 

A daemon with its own code to read sessionid.tdb?  But the information
needed is already implicitly within smbd itself.  Complexity-creep...

The point is that the lifetime and resources of this messaging function is
very closely tied to (identical with?) the particular smbd process, both
for the client/PC, including smbd-generated messages, and the
"/dev/whatever" for externally generated messages for that client. 

Inside smbd is absolutely the natural place to do it, and it drops in
cleanly and easily without having to invent "auxiliary" things (such as
"own code to read sessionid.tdb", and own process loop and own debug code
and possible own param-reading and ...)

Sotware bloat?  Most of the libsmb stuff (e.g. "cli_message_start(...)") 
is already in smbd anyway (according to "nm smbd | grep cli_")  The extra
code is small, and is one copy shared across all the smbds.  (OK, we'd
have to watch per-smbd data space, but I'd be pretty confident that there
would be worse areas already in smbd!) 

Inside smbd seems to have all the virtues of elegance, full flexibility
and simplicity.  The external daemon seems to lose functionality (possibly
restorable by some relatively clumsy call-out mechanism) and introduce
unnecessary complexity.

Personally I really would like to see this, as far as possible, within
smbd itself.  (I think I'm not alone here...) 

And we all seem to have reached a consensus that _ending up with_ the
"/dev/smb" namespace, precisely because it is neatly self-contained, is
fine as a solution.

The major sticking point is managing the namespace.  Understandably, the
Samba Team doesn't want smbd actively diddling generally in "/dev".  Fair
enough.  Does this extend to a private, self-contained, "/dev/smb"
namespace?

Now (off the top of my head) what about the following?

Suppose the Samba site-administator does a one-off creation of a symlink
called "/dev/smb" pointing to something like "/var/<blah>/smb".  Then the
smbd code does its pseudo-device management (fifo, named pipe, etc.) on
names of the latter form "/var/<blah>/smb/XXX"?  As a model (principle,
idea etc.) does that seem OK (or at least reasonable)? 

Summary:

1. Plea (pretty, pretty, please) for code within smbd (elegance,
   flexibility, simplicity);

2. Agreement on self-contained "/dev/smb" namespace;

3. Possible admin/manual symlink /dev/smb->/var/<blah>/smb, with device
   manipulation code done in terms of "/var/<blah>/smb".


And, to re-iterate again, this whole thing could be "opt-in":  no site
would suddenly find nasty surprises in its "/dev" (i.e. "/dev/smb")
because the default would be off.  Indeed, if a "--with-XXX" approach is
taken, the default could be no compilation. 


-- 

:  David Lee                                I.T. Service          :
:  Systems Programmer                       Computer Centre       :
:                                           University of Durham  :
:  http://www.dur.ac.uk/t.d.lee/            South Road            :
:                                           Durham                :
:  Phone: +44 191 374 2882                  U.K.                  :