[Fwd: Finger problem on Solaris with 2.2.4 (PR#24659)]

[David Lee]

On 17 Jun 2002, Simo Sorce wrote:

> I think this bug may interest the list and someone can have some ideas
> on why under solaris finger gives problems and under irix not.
> 
> ATM I have neither solaris nor irix boxen here.
> [...]
> We have discovered a bug in Samba 2.2.4 that affects Solaris hosts:
> 
> The 'finger' command (when issued with no arguments) tries to stat the device
> associated with each connection.  Unfortunately, the devices for smb
> connections
> (/dev/smb/n) do not exist.  This causes finger to fail with the following error
> when users have smb connections to the machine:
> 
> 	finger: Can't stat /dev/smb/1
> 
> Samba was compiled with the following flags:
> 	--with-tdbsam --without-winbind --with-utmp
> 	Makefile edited: VARDIR = /var/samba
> 
> Removing --with-utmp fixes the problem, so indicates where the problem lies.
> 
> The 'w', 'who' and 'last' commands function correctly.
> This bug does not affect IRIX.  We have not run samba on any other platforms.

This can be classed as a "known problem" and that it does, indeed, relate
to the utmp support as enabled by "--with-utmp".  (It was I who wrote
Samba's original "utmp" code, using Solaris as a starting point, although
this particular issue only emerged much later.)

There is also a possible workaround we (Samba folk) could do, which can
actually also increase Samba's overall functionality.



Problem analysis:

One could argue that it's a bug in Solaris:  that Solaris shouldn't care
about the (lack of ) reality of the "/dev/smb/n". 

On the other hand, one could argue that we (Samba) shouldn't be using a
non-existent "/dev/smb/n" as though it were real.  (But this fake-device
is a vital component of "utmp" support, and, given that we have to use it,
we ought to ensure that if fits the overall "/dev/..." model.)

But of course, such mutual finger pointing ("it's their fault") won't get
us very far towards resolving the problem.



Towards a solution (and bonus Samba functionality!):

I have proposed an idea which not only solves this problem but also
increases the functionality of Samba.  My idea is for smbd, or something
affiliated, simply to be able to maintain the "/dev/smb/n" tree as
connections come and go.  That solved the problem (I checked by adjusting
a copy of smbd source code accordingly). 

And it also would add further value to Samba.  Because once it exists, it
can then be used as a real device for sys.admins (and users?) to be able
to use the existing "write(1)" and "wall" commands to send WinPopup
messages to smb client users. 

(Our environment is a university campus with sometimes 1000 simultaneous
connections, and occasionally we need to be able to get "alerts" out to
current users about imminent events: naturally we try to keep these rare,
but sometimes they are nececssary!) 

Now, if Andrew Bartlett is reading this...!  Andrew, bear with me...!

And if Gerald (Jerry) Garter is reading: you, too, may recognise this.

So my trial implementation was:
1. "smbd" to create/delete "/dev/smb/n" as a "named pipe";

2. "smbd" then to include this in its "select()";

3. anything appearing on "/dev/smb/n" to be sent to the client PC as a
   WinPopup, using code very similar (and potentially common) to
   "smbclient -M".

As a proof of concept it solved the "who" problem, and added this extra
wall/write functionality.




Technical detail:

Andrew Bartlett and I had a couple of discussions during the last year or
so about this issue, with some initial technical disagreement, but
reaching a resolution.

My original idea, and "proof of concept" demonstration was simply to allow
"smbd" to create/remove "/dev/smb/n" entities.  Conceptually very simple,
and the implementation inside "smbd" is almost trivial.   (The WinPopup
thing was a little harder, but still reasonably straightforward.)

Andrew B. (and, I understand, Tridge) are unhappy about smbd itself
diddling about in "/dev/", even if (as I proposed) that it be a "smb.conf" 
parameter to allow (default disallow) such diddling.  OK, fair enough. 

We agreed on a compromise that a PAM module could be used to do the
"/dev/smb/n" diddling.  Although that doesn't help non-PAM systems
(Solaris, fortuately, is PAM-based).



Summary, including proposal:

1. A known problem.

2. Fix is simple if in smbd, and still relatively simple if in PAM
   (although latter doesn't help non-PAM systems).

3. If "fix" (whether smbd or PAM) uses a named-pipe (or similar) we can
   also gain write/wall added functionality.

I hope that the Samba Team can agree the principle.  If so, then I would
willingly and gladly contribute my "work in progress", and, further,
adjust it to their recommended CVS version (which?  2_2?  3?  HEAD?) for
such developments. 

-- 

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