poking/prodding utmp
Freddie
freddie at ns1.nowait.net
Wed Apr 5 10:34:00 GMT 2000
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 --------------
More information about the samba-technical
mailing list