2.0.7pre2, utmp in particular

[David Lee]

On Tue, 21 Mar 2000, Giulio Orsero wrote:

> I applied that patch to pre2.

I believe Jeremy is now examining this patch (to try to use better default
values for "utmp dir").

Any news, Jeremy?

Also, I suspect we should probably supplement "utmp dir" with a "wtmp dir"
parameter.  See below.  This should be very easy to do. 

> My tests are with 2.0.7pre2 installed, with smbd overwritten with the
> one recompiled with the connection.c patch of 17 feb.
> 
> I use rh61.
> pre2+patch works without need of "utmp dir", however "last" does not
> work yet.

One thing that has become increasingly clear is how many flavours of utmp
exist.  Every OS seems to have its own quirks.  Therefore every new OS
for which utmp is tried will probably need a keen enthusiast to check, and
if necessary adjust, Samba's new utmp code.  That is, access to a C
compiler, and time to edit, compile and test the source code.

> This is a log of patched pre2 without "utmp dir" set:
> ===>opening
> [2000/03/21 20:00:29, 2] smbd/connection.c:utmp_claim(471)
>   utmp_claim: conn NULL
> [2000/03/21 20:00:29, 2] smbd/connection.c:utmp_claim(481)
>   utmp_claim: conn: user:cdi cnum:1 i:1
> [2000/03/21 20:00:29, 2] smbd/connection.c:utmp_claim(483)
>   utmp_claim: crec: pid:12357, cnum:1 name:golden addr:10.0.0.179
> mach:notebook  DNS:pc79
> [2000/03/21 20:00:29, 2] smbd/connection.c:utmp_update(414)
>   utmp_update: fname:
> [2000/03/21 20:00:29, 2] smbd/connection.c:utmp_update(425)
>   utmp_update: fname:

"fname" is empty.  Strongly implies that on your OS (rh61) the Samba
code (compilation time) has been unable to determine a default directory.

Needs a volunteer with rh61 to investigate and tweak the code!

> This is a log of patched pre2 with "utmp dir" set:
> ===> opening
> [2000/03/21 19:51:15, 2] smbd/connection.c:utmp_claim(471)
>   utmp_claim: conn NULL
> [2000/03/21 19:51:15, 2] smbd/connection.c:utmp_claim(481)
>   utmp_claim: conn: user:go cnum:1 i:1
> [2000/03/21 19:51:15, 2] smbd/connection.c:utmp_claim(483)
>   utmp_claim: crec: pid:12245, cnum:1 name:share addr:10.0.0.179
> mach:notebook DNS:pc79
> [2000/03/21 19:51:15, 2] smbd/connection.c:utmp_update(414)
>   utmp_update: fname:/var/run/utmpx
> [2000/03/21 19:51:15, 2] smbd/connection.c:utmp_update(425)
>   utmp_update: fname:/var/run/wtmpx

> [...]
> I don't understand the names. Shouldn't they be /var/run/utmp and
> /var/log/wtmp?

Ah!  Your OS uses different directories as default utmp and wtmp
locations.

First problem:  ideally compilation should determine the default path
names of the files (things like "UTMPX_FILE").  That should completely
solve it, where such determinination is possible.  This requires the code
to be checked and ported to each OS.

Second problem: either such compile-time determination for the OS is
impossible, or the sys.admin. specifically wishes to override the
directions for u- and w- files independently.  Perhaps a "wtmp dir" 
parameter might be worth having?  So in determining the path of w- files,
try, in order, explicit "wtmp dir", explicit "utmp dir", system default
(after someone has properly ported to the OS question).

The "first problem" above is the one we should concentrate on.



Another consideration: there is an increasingly strong argument for
putting the utmp code into a separate source file.  It was originally
bundled into "connection.c", because it is very closely allied to that. 
But "connection.c" is clean, whereas the utmp code is having to become
littered with all sorts of OS dependencies ("#ifdef ...").   (I have no
strong feelings on this:  let the Samba code maintainers decide.)

Hope that helps.

-- 

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