Session info needs more real info

Some thoughts:

Getting the hardware address will only work if the client is on the same subnet as the terminal server. I think this is usually the case, but can we actually rely on this?
Is the hardware address really useful to somebody who does not know how to obtain it without tcm?

Getting the hostname could end up being very slow, because we might have to perform a reverse DNS lookup, and in the worst case, wait until it times out. I don't think we can use the utmp file, because we have no way to determine which entry in it is an LTSP session. A user might spawn a multitude of login sessions, all of which will show up in utmp.
The same problem arises for for "last login" and "length of current session". For these two, letting the user-side helper record the information and then querying it would probably work.

I am changing the status of this bug to "incomplete", since it needs further discussion before it can be fixed.

I guess it's not necessary for HW address, though for future implementations of Wake-on-LAN (WoL) we'll need the MAC address anyway. The other stuff is useful, though I guess not totally necessary.

Having a user-side helper could be beneficial for future ideas to implement as well as these little bits of info we could display... what is the reasoning behind removing it again?

#2: We do have a user-side helper right now, and there are no conrete plans to remove it. We can probably use it to implement some of the stuff mentioned above.

Anything we could do with a thin client side daemon, or a session side helper we could do with only an ssh key...

If we have the thin clients ip and ssh authentication then it's the same as having a shell on the thin client. If we're root we have total control over any session on the system as long as we know the display.

Hi,

syn66:
> Anything we could do with a thin client side daemon, or a session
> side helper we could do with only an ssh key...
>
> If we have the thin clients ip and ssh authentication then it's the
> same as having a shell on the thin client. If we're root we have
> total control over any session on the system as long as we know
> the display.

I agree. And I think these methods (accessing the display for local
stuff, sshing into the thin client for stuff that needs access to the
thin client hardware) are preferable. The current "tcm-client" helper
is basically just a workaround because I could not access the user's
display so far. But I must admit that I did not really look into the X
display stuff yet. I am sure there is a clean way to do this. The
current tcm-client package will not be needed anymore as soon as we
have figured this out.