More utmp stuff

[David Lee]

On Sat, 25 Mar 2000, David Bonner wrote:

> On Fri, Mar 24, 2000 at 08:47:05PM +1100, David Lee wrote:
> > BUT... this utmp stuff is brand new to Samba 2.0.7 , and it has become
> > very clear that each OS has its own quirks and wrinkles.
> > 
> > So each OS needs an initial volunteer to "champion" the porting of the
> > utmp code.
> 
> Well, I've got easy access to a Slackware 7 machine, and I can
> get access to a RH6.1 box to verify that it does the same thing
> as Slack.  Anyone else got a Debian box?

OK.  Trying to pull together all these varied utmp strings.

Jeremy:  we DEFINITELY need an answer from Jeremy (or an appropriate
member of the main Samba Team) about principles.  Then the rest of us can
get on with the hard work, which will need someone to coordinate it.
(Also see end.)

Some points:

o  The utmp functionality seems to be proving popular.  So we ought to
   continue to improve it and port it.

o  The sheer variety of utmp implementations means that porting is
   becoming increasingly non-trivial.

o  We need to pare down to the absolute minimum the work needed by the
   central Samba team to handle this can'o'worms.  My guess is that
   they want to keep out of the gory details of implementation, but 
   nevertheless keep a managerial eye over the process.

o  Samba 2.0.7pre2 (not pre1) is the base to work from.

o  I would strongly urge that this base be augmented by a patch I sent to
   Jeremy a few weeks ago (since re-sent) which makes a better attempt at
   getting the default pathnames.

o  We should strongly consider moving the code out of "smbd/connection.c"
   into a separate file, because the code will, of necessity, become
   increasingly littered with "#ifdef MY-LITTLE-OS" constructions
   (somewhat akin to "smbd/quotas.c").

o  The basic principle should be that for plug-and-play only "utmp = yes"
   is needed.  That is, that compile-time and run-time should, by default
   arrange that the data appears in the system utmp-type files.

o  Thus "utmp dir" should, ideally, be only needed (1) for over-riding the
   (sensible) system-specfic defaults (2) to get someone started on a new
   port.

o  Despite the above downgrading of "utmp dir" to geek status, there
   should probably be a "wtmp dir" too.

o  Worthy consideration should be given to the idea of consolidating
   multiple connections from the same PC into one single utmp record,
   perhaps by a "utmp consolidate" parameter, and idea suggested and
   already implemented by "Freddie <freddie at ns1.nowait.net>" .

Does that all sound reasonable?


Jeremy:

o  Do you approve the above?

o  Could you consider separating out the code from connection.c in
   whatever way you see best?  Either with or without my patch, I don't
   mind.  There'll be knock-on effects on Makefiles etc. to be done.

o  Those of us who are interested can then use this as a base for 
   development and porting.  This should be entirely self-contained in the
   new "utmp.c" file (with minimum necessary "configure.in", "loadparm.c"
   changes), as outlined above.  OK?

o  Could you nominate someone to coordinate the nitty-gritty work?

Best wishes.

-- 

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