smbwall

[Andrew Bartlett]

David Lee wrote:
> 
> On Thu, 24 Jan 2002, Garry J. Garrett wrote:
> 
> > Attached is a shell script, "smbwall". It basically sends a
> > "wall" (or really more akin to "rwall") message to anyone
> > who has a drive mapped via samba.
> >
> > The shell script uses "smbstatus" to get a list of people
> > who have drives mapped, then it loops through that list,
> > using "smbclient" to send a windows pop-up message to the
> > users.
> >
> > Of course, perhaps it would be cleaner to graft together
> > source code from "smbstatus" and "smbclient" into a binary
> > called "smbwall", but the shell script is functional as
> > it is.  I run the shell script on Sun Solaris, but I so
> > nothing about that is Solaris specific.
> 
> It is good to see that there is someone else who wishes to have this sort
> of functionality associated with Samba.
> 
> 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.
 
> This would assist Garry's "smbwall" command.  Instead of doing "smbstatus"
> and having to post-process its output, then individually calling
> "smbclient" for each process (we routinely have over 800), it would simply
> "write" to all the named pipes (or equivalent) maintained by the smbds
> themselves.
> 
> (Note that running an 800+ simultaneous (nearly 20,000 registered) user
> environment gives different service-support perspectives from that of a
> small lab.)
> 
> To the Samba Team:  There are at least two of us who have spotted the
> usefulness of such functionality, to the extent of actually trying to
> implement it.  Would it be possible, please, for us to discuss with one of
> you this idea some more, to obtain a clean, flexible enhancement to Samba
> for such activity?  (This need not necessarily be on the list, simply to
> reduce list-noise for others.)

Yes, I know this is a pet issue for you :-).  Fortunately its not hard
to do - and you don't even need to convince the samba team of your
solution!

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.

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.

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet at samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net