smbwall

[David Lee]

On Fri, 25 Jan 2002, Andrew Bartlett wrote:

> David Lee wrote:
> > [...]
> > A couple of months ago, I implemented and tested something similar, but
> > coded into Samba itself.  My "philosophical" starting point was similar,
> > though not identical, to yours.  I identified three things (there may well
> > be more) where the _easy_ ability to issue such popup message might be
> > useful:
> > 
> > 1. the real "wall" command:  e.g. when system "shutdown" alerts
> >    terminal users it also automatically alerts samba users;
> > 
> > 2. the ability simply to "write" to a Samba user as one would write to
> >    a terminal user;
> > 
> > 3. for future internal use by other parts of "smbd" (e.g. "vfs" routines,
> >    quota warnings, ...).
> 
> I think this is a separate issue - probably best solved by simple shell
> interface to smbclient.  A 'quota exceed script' is perfectly capable of
> doing whatever is required - including calling smbclient -M etc.

Hmmm...  One can pick off these issues one-by-one as divide-and-rule.  But
I'm trying to view the overall picture of allowing the PC to be viewed as
"just another tty".  Allowing this to happen seems to be an option worth
having for a site that so wishes.

Andrew B.:  I realise you are concerned about one possibility of a
particular detail in my original draft and implementation.  But I think it
can be worked so we can co-exist.  See later. 

> 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?

> However, any attempt to make smbd create /dev/ entries is, in my
> opinion, highly misguided. The consequences in case of error and the
> cross-platform issues are a major concern to me.  As such, I greatly
> favor handling this outside smbd where the admin can configure such an
> arrangement to his/her liking.

I understand this, and even sympathise with it.  (Note to others: a few
months ago, off-list, Andrew B. and I had a lively little discussion about
this!) 

So let's back off the detail of whether smbd itself should create and
maintain the /dev/ entries.

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).  Also, "smbd" itself
might then be able to take advantage of such a mechanism to produce
warning messages.

As I see it, this requires:

1. something (not necessarily smbd) able to maintain entries in "/dev"; 

2. something, possibly different, which can:

   (a) listen to ("select()"?) those entries, including their possible
       comings/goings or attaching/detaching, etc.; 

   (b) determine the client name associated with a particular "/dev";

   (c) translate stuff written to that "/dev/blah" into a WinPopup message
       for that client.

3. some means by which things within "smbd" can conveninetly and 
   consistently get WinPopups to the client PC (I used a quota vfs module 
   as an example), but there are also authetication warning/error 
   conditions which would be useful at our site).

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

I'm suggesting, initially at least, that (2) should be inside "smbd",
simply because it very conveniently has all the infomation immediately to
hand to associate client name with the potential "/dev" name (in the
"utmp" cuntionality, to which I'm biased!).

And my doing (2) within "smbd", it automatically allows the generalised
mechanism for implmenting (3).


Andrew B.:  Could you explain your proposed PAM mechanism a little more,
please?  

Off the top my head, I see here a possibility for the "utmp" code itself
to be migrated out of "smbd" into such general "utmp" module, no longer
specific to samba, but of more general and wider usefulness to other
things.

Also, the PAM module itself would not need to fork the daemon (and I think
it would be cleaner to avoid this anyway).  Rather the daemon could be
started up independently, analogous to "nmbd" (and the master "smbd" for
sites that operate smbd that way).

This is sounding promising!

All that I ask that we bear in mind the overall aim (should a site policy
so be) of enabling: 

1. the UN*X server to view a PC (smb client) as "just another tty", so
   that UNI*X utilities such as "wall", "write" etc. automatically work.

2. entities within "smbd" (e.g quota, passwd, vfs modules) to output
   a simple text message to the PC to appear as a WinPopup.

Hope that helps.

-- 

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