smbwall

[Garry J. Garrett]

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.

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

[...]
> 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.



[...]
> 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.


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.

That's why I'm thinking (and this is just my $.02 worth), that you
would want to allocate one pseudo terminal to catch the wall/write
messages (actually, this makes it only useful for wall messages,
though I suppose you could use write to send a message to all of
the smbclients without sending that same message to all of the
logged in users).  I don't see a way to allow a given smb client
to tell smbd that it doesn't want to get the messages (and thus
issue a "mesg" command for it's own pseudo terminal), so it's
not like you are going to need individual pseudo tty devices for
each smb client anyway.  Granted, without individual pseudo
terminals, you can't use "write" to send a windows pop-up message
to a specific smb client (though you can use smbclient to do
so).  This stand-alone daemon would basically sleep, until it
got a wall message, at which time it would wake up, send out
the windows pop-up messages, and promptly go back to sleep.
On a SIGTERM, it could issue a message (I suppose you'd have
to assume that if you stand-alone daemon is getting a SIGTERM
that sending a SIGTERM to smbd is about to follow, though if
the system is shutting down, a wall message probably already
went out, so perhaps there is no need to issue a message if
you get a SIGTERM?).

-- 
-----------------------------------------------------------------------
Garry J. Garrett                                            
CSG Systems, Inc.      ._o             o              __o   
2525 North 117th Ave.    |>           <\            -\<,    
Mailstop 2-A             4    . . .. />   . . .. ...O/ O    
Omaha, NE 68164-3679                                        

CSG Systems  - http://www.csgsystems.com/	
CSG Internal - http://intranet/unixops/		
My Homepage  - http://garrett.no-ip.com:8080/

       ...Professor Plumb, in the DMZ, with the named pipe...

I do not speak in any capacity on behalf of CSG Systems, Inc.
I get into enough trouble speaking for myself.