Samba 2.0.7 : utmp patch

[David Lee]

On Tue, 2 May 2000, Giulio Orsero wrote:

> I tested the above patch on linux rh61/2.2.14/glibc2.1.2.
> 
> The patch solves 2 problems:
> 1) wtmp logging works automatically. With plain 2.0.7 you needed "wtmp
> dir = /var/log" in smb.conf.
> 2) "utmp consolidate" now works. With plain 2.0.7 it had an inconsistent
> behavior.

Good.  Thanks.  (The consolidate idea was an afterthought.  With the
benefit of hindsight, we see that it had not had long enough for all its
issues to be thought through.)

> There is a behavior I'm not able to reproduce, it happened to me just
> once:
> $ w|grep pc79
> user1       smb/1    pc79              5:19pm  0.00s 37.37s   ?     -
> user1       ttyp4    pc79             11:24am  0.00s  0.32s  0.02s  w
> $ who -l|grep pc79
> user1       smb/1    May  1 17:19 (pc79)
> user1       smb/3    May  1 17:14 (pc79)
> user2      smb/2    May  1 16:56 (pc79)
> user1       ttyp4    May  1 11:24 (pc79)
> 
> Basically "w" is correct, "who" (and "last") shows connections that are
> already closed (I turned samba off and on, and they are of before
> turning samba off).
> I think I'll have to truncate utmp to blank those entries.

Let me know if you manage to pin this down.

(1) Might it be related to a "force user" interaction, as you mention
below? 

(2) It's not clear to me in Samba generally (and utmp in particular) what
happens when a parameter changes value through a session.  Is such a thing
possible (e.g. change a boolean in smb.conf, HUP the process, ...)?  What
should done in the many corners of Samba where this might have an effect? 
Where else in Samba can I find examples which cope with this?

> A note on utmp consolidate:
> If I understand it well, it's supposed to consolidate smb entries in
> utmp/wtmp "by machine", and this is what it does.

Imagining "utmp consolidate" as per-machine isn't quite right, but is
probably 99% close enough.  The current behaviour is "per-[smbd-]process". 
If the clients are simple PCs then this is the same thing, I think.  But
in earlier correspondence someone mentioned terminal-server-like devices.
I don't know about these, so cannot comment. 

> I'm wondering if it would be more correct to consolidate "by machine"
> and "by user_id". What do you think? 
> 
> This is without consolidate
> user2      smb/1    pc79              6:56am  0.00s  4.84s   ?     -
> user1       smb/2    pc79              6:56am  0.00s  4.84s   ?     -
> user2      smb/3    pc79              6:56am  0.00s  4.84s   ?     -
> This is the same situation with consolidate
> user2      smb/1    pc79              6:54am  0.00s  4.80s   ?     -
> Wouldn't it be better as
> user2      smb/1    pc79              6:56am  0.00s  4.84s   ?     -
> user1      smb/2    pc79              6:56am  0.00s  4.84s   ?     -
> 
> The user "user1" is because of user-level auth; the user "user2" is
> user1 that appears as user2 because the use of "force user = user2" on a
> share.

The idea of "utmp" support was to let UNIX commands such as "who", "last" 
etc. indicate who uses the system, and from where.  That is, to deliver a
UNIX-like view of Samba usage.

Then the idea of "utmp consolidate" is to reduce the quantity of this
UNIX-oriented "who" (etc.) data. 

Note that, in their UNIX context, these UNIX commands don't reflect any
"su" done by UNIX users.  Assuming that Samba's "force user" is more or
less analogous to UNIX "su", then utmp wouldn't necesarily reflect such
subtleties at the top of its priority list.

Samba's "utmp" functionality was never intended to replace the SMB-like
view, which can be seen through Samba's "smbstatus" command. 

So I see your point.  My initial reaction is conservative and cautious,
but I am open to further persuasion.  Would it need to allow both options? 
What would the parameters be called?  Assuming other folk agreed, it would
need a volunteer, familiar with "force user..." (which I am not) to
implement it... .  

I think the overriding priority at present is to get the current patch
tested, stable and rolled into the 2.0.8 development tree.  (Indeed,
though unlikely, if, for some reason, there had to be a 2.0.7a, it would
be good to get this in there.) 

Thanks again, Giulio.  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.                  :