poking/prodding utmp

[Freddie]

At 18:13 5/04/2000, David Lee wrote:
>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?

For the moment, it's not another option, it's part of the "utmp 
consolidate" option. If you turn that on, you get the sequential ut_line's 
to go with it :)

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

Attached is a patch against 2.0.7pre2, the 2nd and 3rd hunks fail for 
smbd/connection.c in 2.0.7pre3.


>--
>
>:  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.                  :
-------------- next part --------------
A non-text attachment was scrubbed...
Name: utmp-2.0.7pre2.patch3
Type: application/octet-stream
Size: 8269 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20000405/f5a306f5/utmp-2.0.7pre2.obj
-------------- next part --------------