poking/prodding utmp

[David Lee]

On Wed, 5 Apr 2000, Freddie wrote:

> Funny, I just get things working on 2.0.7pre2, and pre3 comes out... *sigh* 
> :) Haven't had a chance to download it yet (read: Nox is too damn 
> addictive), but I'll eventually get around to it.
> 
> Progress...
> 
> utmp consolidation: it's working! It even gets it's own smb.conf option, 
> huzzah. ...

Good.

Since pre3 came out at the weekend, I've been building a patch to include
the bugfixes and changes to utmp handling that we have been discussing. 
It is almost ready for airing.  So your work on "utmp consolidate" should
be most valuable.

The utmp code didn't even exist before 2.0.7, and the various "pre" 
versions have contained rapidly evolving code.  So the patch I am
assembling is against "pre3", and only "pre3".  I'll try to include your
code into that patch.

Could you construct a patch relative to "pre3"?  If that's too tricky,
just send me your version of "connection.c" (and any other relevant ".c"
files).  I'll try to roll that in.

> Normally, with utmp support enabled, it sets the user's "line" to 
> "smb/<connid>". What's wrong with that? Well, you end up with something 
> like this: (or something close to it)
> 
> freddie  smb/1    zugzug           Tue 2am  0.00s 13days   ?     -
> freddie  smb/8    bouncy            6:20am  0.00s 13days   ?     -
> lewi     smb/11   narf             Sun 5pm  0.00s 13days   ?     -
> 
> It varies depending on the number of shares the client machine is 
> accessing. I shudder to think what you'd end up with when a hundred or so 
> people connect.... so I wrote another patch... and now I get:
> 
> freddie  smb/2    zugzug           Tue 2am  0.00s 13days   ?     -
> freddie  smb/3    bouncy            6:20am  0.00s 13days   ?     -
> lewi     smb/4    narf             Sun 5pm  0.00s 13days   ?     -
> [...]
> This involved adding another function, static int utmp_line(void), which 
> returns an int (obviously), which is the next smb/<n> that we can use. Tada.
> 
> The question is, should this be a seperate option, part of utmp 
> consolidate, or just always on? I'd vote for having it always on (well, if 
> utmp = Yes).

Yet another option??  The advantage of the earlier scheme is that it
matches the internal connection number (geek-friendly).  The advantage of
the latter is that it is more obvious to the casual outside observer
(including most sys.admins most of the time, I guess). 

The emerging code has always implemented the former (the "sparse"
numbers) for the brilliant reason that it was trivial to code.  But my
experience suggests that your latter (sequentially ascending, filling in
the gaps) is probably preferable.  (We have several hundred simultaneous
connections, though usually only one share per connection.)

Any strong views, anyone?  My own leaning is towards Freddie's (i.e. the
latter) scheme.  Do we really want another option? 

Very soon I hope to make available this patch, and a set of notes.


-- 

:  David Lee                                I.T. Service          :
:  Systems Programmer                       Computer Centre       :
:                                           University of Durham  :
:  http://www.dur.ac.uk/~dcl0tdl            South Road            :
:                                           Durham                :
:  Phone: +44 191 374 2882                  U.K.                  :