2.0.7pre2, utmp in particular

Giulio Orsero giulioo at pobox.com
Tue Mar 21 19:02:44 GMT 2000


On Sun, 19 Mar 2000 19:09:31 +0000 (GMT), hai scritto:

>On Sat, 18 Mar 2000, Giulio Orsero wrote:

>A patch I submitted on 17 Feb ought to address the w- and u- files being
>in different directories: indeed it also lets them default to their
>natural (and possibly different) directories in the absence of a "utmp
>directory" entry in smb.conf .  Alas, that patch seems to have been missed
Try putting the patch on http://samba.org/samba-patches

I applied that patch to pre2.

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.

This is a log of unpatched pre2
pre2
[2000/04/02 23:15:20, 2] smbd/connection.c:utmp_claim(415)
  utmp_claim: conn NULL
[2000/04/02 23:15:23, 2] smbd/connection.c:utmp_claim(429)
  utmp_claim: dir:/var/run/ conn: user:cdi cnum:2 i:1
[2000/04/02 23:15:23, 2] smbd/connection.c:utmp_claim(431)
  utmp_claim: crec: pid:1466, cnum:2 name:windows addr:10.0.0.179
mach:notebook DNS:pc79

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:
===>closing
[2000/03/21 20:00:41, 2] smbd/connection.c:utmp_yield(454)
  utmp_yield: conn: user:cdi cnum:1 i:1
[2000/03/21 20:00:41, 2] smbd/connection.c:utmp_update(414)
  utmp_update: fname:
[2000/03/21 20:00:41, 2] smbd/connection.c:utmp_update(425)
  utmp_update: fname:


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
===> closing
[2000/03/21 19:58:47, 2] smbd/connection.c:utmp_yield(454)
  utmp_yield: conn: user:go cnum:1 i:1
[2000/03/21 19:58:47, 2] smbd/connection.c:utmp_update(414)
  utmp_update: fname:/var/run/utmpx
[2000/03/21 19:58:47, 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?

There's another issue. With patched pre2 you don't need to use "utmp
dir", however if you don't use it you get this weird behavior:
- if I use the "w" command I see just the active connections, both ttypX
and smb/X.
- if I use the "who" command I see active ttypX connection (like in w),
but also the finished smb/X connections. who shows even two connections
from the same tty, ie.: 2 connections associated with smb/6 (one
finished, one active).
This happens only if using utmp-patched pre2, without specifying "utmp
dir".


A question:
who/w show in "from" the netbios name of the remote machine. On my
system wins updates dns, so there's no problem. But if someone has
netbios names that are not resolvable through dns, would "w" or "who"
trigger a dns lookup/timeout on those names?

I wrote the above question before upgrading "who" (from rh60 to rh61, I
upgraded to rh61 rpm by rpm and I've forgotten this one). Now "who"
never shows the originating host (not related to samba, it does this way
for all connections) so the problem is just in w.

Thanks.

-- 
giulioo at pobox.com


More information about the samba-technical mailing list