More utmp stuff

[David Lee]

On Fri, 24 Mar 2000, Freddie wrote:

> A question, why is there a utmp directory parameter? This from the 
> GETUTENT(3) man page:

It *ought*, ideally to be either "last resort" (for OSes for which the
Samba/utmp port is not yet done) or explicit, wilful override.

It would appear that the Samba/utmp code has not yet been ported to your
system.  But before you rush in...

A further patch, currently being examined by Jeremy, tries harder to
determine sensible defaults at compile time, for both u- and w- files,
so that "plug and play" should, ideally, use the system's defaults
without needing "utmp dir".

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.

I could send you the patch I've sent to Jeremy, so that you could try it
on your system.  (My slight hesitation is that Jeremy might wish to adjust
my patch, and then we'd all be working from different bases!)

Perhaps Jeremy could "approve" my patch or a modification of it, which we
could then all use as a base.

> 
> DESCRIPTION
>         utmpname() sets the name of the utmp-format file  for  the
>         other utmp functions to access.  If utmpname() is not used
>         to set the filename before the other functions  are  used,
>         they assume _PATH_UTMP, as defined in <paths.h>.
> 
> If there's already a valid OS default path (at least, there is on 
> Linux/glibc 2.0.x/2.1.x), why force the user to specify it? Perhaps it 
> should be an optional parameter, only needed if _PATH_UTMP isn't defined?

See above.

> I think the problem with utmp showing up multiple times for the same pid is 
> the way that pututline() searches for the right entry to use.

But this "problem" is not a "problem".  The aim of utmp is to show
connections, not pids.  in the Samba case, we have multiple connections
between a PC and a UNIX host.  So utmp, just like smbstatus, shows
multiple connections.  All to the same pid, but I think that is
irrelevant, isn't it? 

Forget technical details for the moment.  As a matter of principle, in
coding up the utmp stuff, I assumed that it should reflect connections
(just like smbstatus).  Was this a wrong principle to assume?


>         pututline()  writes  the  utmp  structure ut into the utmp
>         file.  It uses getutid() to search for the proper place in
>         the  file  to  insert the new entry.  If it cannot find an
>         appropriate slot for ut, pututline() will append  the  new
> 
>         getutid()  searches forward from the current file position
>         in the  utmp  file  based  upon  ut.   If  ut->ut_type  is
>         RUN_LVL,  BOOT_TIME, NEW_TIME, or OLD_TIME, getutid() will
>         find  the  first  entry  whose   ut_type   field   matches
>         ut->ut_type.   If  ut->ut_type  is  one  of  INIT_PROCESS,
>         LOGIN_PROCESS, USER_PROCESS,  or  DEAD_PROCESS,  getutid()
>         will  find  the  first  entry  whose  ut_id  field matches
>         ut->ut_id.
> 
> ut->ut_id is set to the "int i" parameter that utmp_claim gets called with, 
> which ends up being...
> 
> #ifdef WITH_UTMP
> 	utmp_claim(&crec, conn, foundi);
> #endif
> 
> in claim_connection. foundi is... umm... a free spot? (don't understand 
> this code)
> 
> 	/* find a free spot */
> 	for (i=0;i<max_connections;i++) {
> 		if (i>=total_recs ||
> 		    sys_lseek(fd,i*sizeof(crec),SEEK_SET) != i*sizeof(crec) ||
> 		    read(fd,&crec,sizeof(crec)) != sizeof(crec)) {
> 			if (foundi < 0) foundi = i;
> 			break;
> 		}
> 
> If foundi changes for each connection (to a new share etc), then obviously 
> you'll end up with a different ut->ut_id, and therefore, a new utmp entry.
> 
> freddie  smb/1    zugzug            1:13am  0.00s 34:52m   ?     -
> freddie  smb/2    zugzug            1:13am  0.00s 34:52m   ?     -
> freddie  smb/3    zugzug            1:13am  0.00s 34:52m   ?     -
> 
> Service      uid      gid      pid     machine
> ----------------------------------------------
> freddie      freddie  users     9493   zugzug   (192.168.0.201) Fri Mar 24 
> 01:13:49 2000
> software     freddie  users     9493   zugzug   (192.168.0.201) Fri Mar 24 
> 01:13:51 2000
> public       freddie  users     9493   zugzug   (192.168.0.201) Fri Mar 24 
> 01:13:52 2000
> 
> These are _all the same pid_, and there should be _a single utmp entry_ for 
> the whole lot of them. Phew.

Er... *why* should there be just a single entry?  There are three
connections.  Yes, they are all to the sam pid, but that is irrelevant
isn't it?

> Anyone feel like commenting/coming up with another way to do ut->ut_id? 
> I'll work on it while I wait :)

Why, conceptually, do you think it needs changing?  Your example has three
connections, giving three utmp entries.  What, conceptually is wrong with
that?

By analogy, if there are three connections between an X-terminal and a
timesharing machine, that, rightly, gives three utmp entries.  You seem to
be arguing that Samba should use a fundamentally different model.  Could
you persuade us why?

Best wishes.  Thanks for your concern and willingness to investigate this
area.

-- 

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