smbwall

[David Lee]

On Wed, 30 Jan 2002, Garry J. Garrett wrote:

> David Lee wrote:
> > 
> > On Fri, 25 Jan 2002, Andrew Bartlett wrote:
> > 
> > > David Lee wrote:
> > > > [...]
> [...]
> > > The easiest way to do this is to write a small PAM module that takes the
> > > 'terminal name' that Samba has allocated, creates an appropriate
> > > pipe/socket/fifo and fork()s a small daemon to handle it.  On the
> > > shutdown a 'kill' can be sent to the daemon.  I'll even fix the PAM code
> > > some day to keep the same context open across the open/close.
> > 
> > Do you mean a daemon-per-smbd?  We already have 800+ "smbd"s running...
> > 
> > Or do you mean a single daemon capable of addressing the 800+ fifo-like
> > entities when the corresponding smbds have with a coming/going rate of
> > many per minute?
> 
> 
> PAM module?  Are we knee deep in Linux here?  Some Unicies lack
> PAM altogether - Solaris (my background) as PAM, but it's PAM
> is considerably less functional than (and pretty much incompatible
> with) Linux's PAM.  If you implement something in PAM, Linux's PAM,
> I have my doubts that it will work on anything but Linux.

Our environment is Solaris.  I've also contributed to the "Linux-PAM"
project a little in encouraging openness.  (Someitme, Linux can seem
somewhat closed...!)

But I share your worries about PAM being a pre-requisite.

> As someone pointed out, pseudo terminals come pretty much in
> 2 flavors: BSD & System V.

I suspect we may be using loose terminology.  I think the phrase "pseudo
terminal" was intended to represent a model of doing things, not
necessarily as an real implementation detail. 

> [...]
> > What I'm proposing is that there should be a means of allowing (by opt-in,
> > with health warnings, etc.) ordinary UNIX utilities, such as "shutdown",
> > "wall", "write", etc. would automatically also send messages to PCs on
> > Samba connections (analogous to ordinary terminals). 
> 
> 
> "shutdown" calls "wall", yes?  "wall" and "write" already have a
> method of "opt-ing out": mesg.  I don't, however, see a clean
> way of a Samba client specifying that it wants to run "mesg" to
> ignore such wall/write messages.

My suggest of opt-in was originally loosely intended at a site level
(for site administrator) rather than user.

There may not be a means for an arbitrary Samba client to do a "mesg"-like
yes/no function.  But I'm reasonably sure that various Windows flavours
can enable/disable WinPopups:  we actually rely on WinPopups in other
contexts, and had a phase a few months ago in which they got disabled, and
users didn't get informed of things when they should.

> [...]
> > Andrew, understandably, is not keen that (1) should be done by smbd.
> > Fair enough.  Although we have diffferent emphases here, let's not let
> > that detract from the _real_ purpose which lies in (2) and (3).
> > 
> There is nothing that says that this functionality must be part of
> smbd.  You could have one stand alone daemon that you run in addition
> to smbd (if and only if you want to) that allocates a pseudo terminal
> (to catch the wall/write messages; or it could allocate a pseudo
> terminal per client, though I do not think that is wise [see below]), 
> and when it gets a message, this daemon has code borrowed from smbstatus
> to look up who is connected, and it has code borrowed from smbclient
> to send the Windows Pop-Up message.  The daemon would be self contained.


Agreed.  I proposed something like this at some point, I think, but am
happy to see it re-stated!

And my test implementation did, indeed, borrow code from "smbclient"
(with some modification, which can be back-applied to smbclient, to
maximise code-sharing).


> As for allocating a pseudo terminal per smb client; again, I'm going
> to stick to the flavors of Unix that I know, and pick on Solaris.  Out
> of the box, Solaris builds 48 pseudo terminals.  Because sometimes 
> users use an X-Windows program (such as exceed) to fire of say "xterm" 
> via "rlogin" or "telnet", etc. (thus "soaking up" 2 pseudo terminals 
> for one user login), this ends up supporting about 30 users.  Of
> course, you can bump this up (to 1024) by editing /etc/systems and
> doing a reconfiguration reboot ("boot -r" in Sun lingo).  As someone
> mentioned here, they have 800+ smb clients on their system.  You
> could easily run out of psuedo terminals if you allocated one per smb 
> client.  If you had enough smb clients, you could allocate all of
> your pseudo terminals for your smb clients and then not have any
> left for people to login with.

Ah!  here we get to a misunderstanding.  I wasn't anticipating or
suggesting using real pseudo-ttys (that phrase sounds weird!).  Rather
using some means analogous to pttys, which might be OS-variable.

Indeed my trial implementation used fifos in a dedicated "/dev/smb" 
directory (which, of course, corresponds exactly to the hitherto
fictitious name used in Samba's utmp code).

Very little, if any of this has to be done in "smbd".  But, on the other
side, moving it outside make some of it considerably more "clunky".  For
instance:

1. "smbd" has the actual name "/dev/smb/<n>" and its associated 
   client-name instantly available to itself;

2. The operation only makes sense for the duration of the "smbd"; it
   belongs naturally there;

3. For sites with many concurrent connections (we run 800+ and sometimes
   1000+), the one auxiliary daemon has a lot of fds to handle, which
   are coming and going at rates of 1 per second;

4. The process loop in smbd already handles the required "select(...)"
   on multiple fds.  Staying within "smbd" simply adds two fds (which
   are usually very quiet).  Going outside smbd means inventing a new
   process loop capable of handling 1000+ clients, so probably 2000+
   fds (each client has one for the UN*X-visible "/dev/smb" and one for
   the smb WinPopup channel to the client).


So for those reasons, my preferred solution is to keep the main
functionality within "smbd".  I understand that Andrew's really strong
objection is to "smbd" creating the "/dev/smb" (or whatever) entries on a
UN*X system.  Fair enough.

My aims are to get agreement that the _principle_ of such a WinPopup
mechanism, then to iterate onto an agreed technical implementation which
is clean, as simple as reasonably possible, and useable on systems large
and small.


Does that help?


-- 

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