t.d.lee at durham.ac.uk
Fri Feb 1 05:26:02 GMT 2002
On 31 Jan 2002, Scott Gifford wrote:
> David Lee <t.d.lee at durham.ac.uk> writes:
> > So it seems entirely reasonable to migrate. No longer use a fictitious
> > "/dev/smb/<n>", but rather a real "/dev/pts/<n>" (or whatever is the
> > natural name for that particular host OS).
> > Then smbd can grab (or at least allocate) that 'real' pseudo-tty, and use
> > its name in the utmp/connection stuff.
> > Then, if "smb.conf" directs, it can also open it and listen on it for real
> > "wall", "write", etc., and translate these into WinPopup messages.
> > There we are. Mission accomplished, absolutely cleanly. No run-time code
> > anywhere doing "/dev/blah/"-creation. The real UNIX utilities "simply
> > work".
> I think this is absolutely the solution.
Glad you like it. I hope we can all agree _in principle_ on this. Sure,
there are, and will be, some interesting technical issues and discussions,
but can we agree on this general model/concept/idea?
Let me also emphasise again that this can all, if we wish, be opt-in (i.e.
default off): our code only ever gets exercised at all by sites that
specifically choose it. (At a later date, of course, the default might
> > [...]
> > 1. Connection/utmp code to use names consistent with ttys on the OS,
> > and whose name is allocated "live" in co-operation with the OS.
> And I think most of this is in findpty().
Thanks, I'll take a look.
> > 2. If smb.conf option directs to enable wall/write-like support then
> > smbd opens that same tty and adds it to the select list for reading.
> > 3. If input arrives on that tty, it is sent as a WinPopup, using code
> > from libsmb and friends. (Detail: that code needs some adjustment for
> > this use, but this can be retro-fitted cleanly and transparently
> > into the libsmb library.)
> It's a little trickier than that, since there aren't clear message
> delimiters, but it should still be do-able. I wrote a little
> proof-of-concept program that read from a TTY, then packaged up a
> message when it hadn't received anything new for 5 seconds. That
> should work well enough for what we need; it did the write thing for
> "echo message |write samba" and "wall message", which is what's
I, too, had quickly spotted this glitch with lack of delimiters in my
tests within smbd.
Getting theoretical, we then have the possibility of two simultaneous
messages being randomly inter-leaved. But let's keep a sense of
proportion: the use of "write"/"wall" etc. tends to be rare: we're not
building building a chatroom! (Nor an FTP-facility for mult-gigabyte
> Unfortunately, when I tried to port it to use Samba's more portable
> findpty and utmp code, I got into Dependency Hell and couldn't get it
> to build. Somebody with more knowledge of Samba would probably be
> able to throw something together relatively quickly.
Speaking as the author of the "utmp" stuff in Samba: its internals seem
very complex, but that is solely because every flavour of every OS seems
to do something slightly different. That is the "getutmp(...)" family of
functions is distinctly non-standard across the range.
But the external interface onto Samba's "utmp" should be quite clean.
(Since I last saw it, the code has actually been completely relocated, and
cleaned and tidied: a good job by Andrew B. and Tridge.)
My "proof-of-concept" test within smbd used the 2.2.1a source tree,
including the "/dev/smb/<n>" from its utmp/connection/whatever code
unchanged. Reminder, "/dev/smb/<n>" was a fictitious invention for the
purposes of utmp-uniqueness: it can be changed.
If we switch to using real ptys (whatever is "real" on the particular host
OS), I don't foresee any major difficulty in such a switch. (Anyone
else?) Indeed, in the wider perspective, it could be viewed as making
Should a particular host-OS not have any "real" pty, we are no worse off
than at present. For utmp/connection purposes the "/dev/smb/<n>" myth can
continue, and that particular host-OS would just not have this new
WinPopup feature (or an enthusiast for it could find his/her own way of
doing the "findpty"/equivalent functionality).
: 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. :
More information about the samba-technical