[OpenIndiana-discuss] Vnc to mimic SunRay behaviour, how??

[Jim Klimov]

On 2013-02-28 20:47, DormitionSkete at hotmail.com wrote:
> There is no thin client software to deal with, per se.  The thin clients don't need an embedded OS.  I know some thin client units that you see sold today have a Windows CE or Linux embedded OS.  You don't need that at all with LTSP.  I wouldn't know how you'd use it if you had it!


In a sense, this is semantics, but not completely. Most other
thin clients do use an OS, and for many use-cases it is a good
thing (i.e. running multimedia codecs locally, not on the server).

AFAIK, LTSP was originally based on a small Linux image with X11,
rdesktop, samba client, CUPS and so on, which could be booted onto
a diskless machine via PXE - or installed onto its local disk (or
usb/cf/sd flash). It is an operating system, perhaps constrained,
but expandable by malicious and/or advanced users, etc.

I do know it is mature, free and good (so they say, I haven't used
it so far); it is just a different implementation of the concept.

SunRays have a firmware - much like a harddisk or RAID controller
does, or a BIOS in your PC (and nowadays the BIOS image is about
three times the size of a SunRay firmware image). Also the ability
to boot a particular image is constrained by that it must be signed
by the same vendor who made the box (and holds the root CA which is
trusted by bootloader/updater firmware of the box, in terms of modern
cryptography). This is a strict limitation on ability to reuse or
expand the device, you can't install or configure software on the
box (not even preconfigure an image as a site admin), and for secure
environments it is also a big bonus.

For example, I could come to a PC repurposed as an LTSP client and
force it to boot my OS (from USB, or by faking a PXE server) - and
until you find and reset it, it would be my sniffer or a remotely
controlled script-bot to intrude on your network, or just a ticking
bomb ready to do a DoS by floodpinging a target with broken packets.

> If the SunRay clients won't PXE or Etherboot, you could probably put the boot image on a smart card, and boot it with that.  I don't see why that wouldn't work.

With a SunRay you can't do that, at all, by design. You can only
use it with a Sun-issued firmware, to connect to a Sun Ray Software
server. What you can do from there on - is defined on the server.

Which for their use-case and marketing is a good thing (i.e. desktops
in banks, military, universities, corporations, etc.) For example,
there were solutions to have different smartcards and trust levels
for people from varied affiliations (i.e. officers of domestic army
and those of other countries during joint trainings), or cards to
either allow LAN access or internet access - so the two nets don't
see each other (when a very private LAN is forbidden to connect to
public networks, but personnel needs to have both and only use a
little space on the working desk - not two computers).

Original SunRays are also useless and helpless until they connect
to a SunRay Server. Other vendors' devices, such as laptop-form
models, usually had alternate firmware or OSes, to do browsing or
email even if you don't have a session with your SunRay server.

All in all, I believe this is a bit of deviation from OI discussion,
the Sun Rays have their own list (somewhat active).

Info about SunRays *here* is only good to see which major points of
that solution might be desired in something you build with other
technologies (as, for example, an LTSP on OI). I guess, a key feature
for those who want to migrate, would be hot-desking to their Unix
session from different desktops - along with rerouting of audio,
(performant) video, desktop-attached printers and whatnot. How you'd
do that - by retyping login+password or plugging a smartcard - is an
implementation detail (SunRays do have both).

Possibly, the solution would be to have per-user VNC sessions or
something more featured (with sound, usb, etc), started on demand
with a login, closed on explicit logoff, disconnected and running
while the user walks away. And a broker to connect to these sessions.
Somewhat a poor man's VDI. Might grow into a useful product to
broker VM desktops as well ;)

HTH,
//Jim