abartlet at pcug.org.au
Fri Jan 25 05:04:03 GMT 2002
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
> 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
> (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
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 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
More information about the samba-technical