utmp update for bsd systems (try 2)

[Michael Shalayeff]

Making, drinking tea and reading an opus magnum from 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".)

ang login.c logout.c from any bsd's libutil...

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

they use ttyslot() -- not acceptable.
use the source luke!

> 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?!)

i fail to see any reason in this beakering...

nobody reads any sources and makes hypothetical
demands w/o any kind of ground underneath.

configure detects available interfaces. if there is none than
this pity function is called to do it's dirty deed.
it cannot be any "higher" level by definition!

cu

-- 
    paranoic mickey       (my employers have changed but, the name has remained)