utmp update for bsd systems (try 2)

[David Lee]

On Sat, 16 Apr 2005, Michael Shalayeff wrote:

> Making, drinking tea and reading an opus magnum from Andrew Bartlett:
> -- Start of PGP signed section.
>> On Sat, 2005-04-16 at 07:18 -0400, Michael Shalayeff wrote:
>>
>>> what is so "wrong" in it for you?
>>> maybe we can "fix" it...
>>
>> I don't like such low-level messing with the utmp file.  How does ftpd
>> on the BSDs handle utmp?  This is the modal David Lee used originally, I
>> think.
>>
>> If the login() and logout() apis are not useful (has this been tested?),
>> can they be improved by the BSD crew to honour the contents of the
>> struct utmp?
>>
>> Basically, I want anything that avoids doing a write() to those files
>> directly.
>
> i think i've figured out the difficult part for you.
> if you open the source and read it you would see that
> there are whole bunch of functions that use all kinds
> of so called high-leel apis to write into utmp that do
> exist on many operating systems. this particular function
> that is losely aimed for bsd support exists for the whole
> purpose for systems that lack such functions.
> that is it -- IT MUST BE LOW-LEVEL as you call it.

(By "open the source", I assume the source in questions is Samba's 
"smbd/utmp.c".)

I admit that I did insert hooks for direct file-writing if necessary. 
But that was really only for last-resort, absence-of-anything-else, 
purposes.  And I admit that I made an association between these hooks and 
possible need for their use on BSD, but based on a no-direct-experience 
reading of the "utmp" man page, and over five years ago.

However, almost my first comment in the file, the first "Hints for 
porting", strongly urges programmatic (perhaps a poorly chosen word) use 
rather than direct file access.  I stand by this strong preference, not 
least because it should avoid (bugs notwithstanding) locking problems
with simultaneous update.

A reading of the BSD man pages (at "www.freebsd.org") for "login(3)" and 
"logout(3)", suggests that this login/logout avenue looks reasonable for 
further investigation.  There seems nothing in the man page which says 
that it has to be associated with a "tty".  Of course, such investigation 
might reveal a fundamental show-stopper along these (or other) lines for 
such a login/logout implementation.

We're all agreed that a Samba/utmp interface on BSD is desirable.  What it 
now needs is someone with a test rig (BSD, Samba 3.0.x) to try to do the 
best implementation.  I would suggest that the login/logout route is 
investigated first.  If some reasons then emerge that can prove this to be 
unworkable, then a fall-back direct file access method would seem to be 
unavoidable.

Michael: I've been, and, indeed, still am, where you are!  A relative 
"outsider" trying to get patches accepted by the Samba Team.  It can seem 
tedious.  They do sometimes need reminding.  But they are open to 
well-reasoned suggestions. Samba is phenomenally impressive, not least in 
its technical rigour and its high portability across a range of diverse OS 
features and interfaces.  To us, as outsiders, it can sometimes seem 
annoying and frustating.  But I can see, and understand, why they need to 
do this to preserve the integrity, protability and functionality of Samba. 
(Andrew and I have had our differences, haven't we?!)

Hope that helps.



-- 

:  David Lee                                I.T. Service          :
:  Senior Systems Programmer                Computer Centre       :
:                                           University of Durham  :
:  http://www.dur.ac.uk/t.d.lee/            South Road            :
:                                           Durham                :
:  Phone: +44 191 334 2752                  U.K.                  :