[Fwd: Finger problem on Solaris with 2.2.4 (PR#24659)]
Andrew Bartlett
abartlet at samba.org
Mon Jun 17 07:08:01 GMT 2002
David Lee wrote:
>
> 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!):
There is another solution:
simple touch /dev/smbd/{1 - 3000} with empty files or symlinks to
/dev/null.
But I know you want more than this :-)
> 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!)
Certainly it could be useful in that the system will also broadcast some
of this stuff - like shutdown messages. Then again, some of the other
system broadcasts might not be desirable...
> Now, if Andrew Bartlett is reading this...! Andrew, bear with me...!
I'll try :-)
> 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.
If we create smb.conf options, people use them. Then we get the blame.
And they don't read the manpage either - see recent discussion on
'delete user script' and people loosing thier 'root' account...
> 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).
Or also simple if we add a 'sesion exec'. I never got time to put such
a patch into practice, but if sombody else wants to put it togeahter...
> 3. If "fix" (whether smbd or PAM) uses a named-pipe (or similar) we can
> also gain write/wall added functionality.
Which could indeed be quite useful. But outside smbd :-)
> 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.
The principal is fine 'hooks for such things should be provided' :-)
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
More information about the samba-technical
mailing list