Re: [gdm-list] gdm username history

[Bob Doolittle <Robert Doolittle Sun COM>]

Bob Doolittle wrote:
> Hi Jon,
>
> William Jon McCann wrote:
> > On Wed, Sep 24, 2008 at 1:22 PM, Bob Doolittle 
> > <Robert Doolittle sun com> wrote:
> > > Please do file a bug in any case. You're not the only person 
> > > affected by
> > > this. This will be a big issue when GDM is used for multi-user 
> > > systems such
> > > as thin client servers which may have hundreds of users and on which 
> > > display
> > > numbers may be assigned non-deterministically. There needs to be a 
> > > way to
> > > turn off login history within gdm.
> > Have you tried this or are you just speculating?
>
> I'm speculating at this point, since ConsoleKit hasn't yet been 
> adapted to our thin client model (I think - I haven't been involved 
> with that aspect).
>
> > Done correctly, this
> > system should be split into different seats. ConsoleKit history is
> > per seat. So, it should not be a big issue.
>
> How do you define a "seat"?
>
> There's nothing fixed in a typical thin client model. A given thin 
> client can be used to host any number of sessions over time, for any 
> number of users. Each session will get a display number assigned on 
> the fly based on whatever is free at the time. At my company, we have 
> "flex offices" which are assigned on demand to whomever needs a space, 
> so people are highly mobile wrt where they physically may create or 
> access their session. Multiple people may have sessions which were 
> originally created on a particular thin client, and are later accessed 
> on different thin clients. At any given point in time, a session can 
> be connected to any client, or can disconnected and waiting to be 
> connected to a thin client somewhere. Any sort of login history here 
> is meaningless, except from an accounting/auditing perspective, so 
> ideally it could be turned off.

Two more points worth mentioning:

There can also exist soft client applications that can run anywhere to 
create or access sessions.

The servers hosting the sessions may be remote to the thin client. We 
have tens of thousands of employees globally, who could be connecting to 
sessions anywhere in the world without any local server state reflecting 
that, so again it's not clear to me how a "seat" has bearing and where 
state for it could be usefully stored.

-Bob