[Bug 936810] Re: Make ltsp-client package installable on regular machines

[Alkis Georgopoulos]

I've subscribed LTSP upstream because some of the TODO tasks need to be
done there.

** Changed in: ltsp
   Importance: Undecided => Wishlist

** Changed in: ltsp
       Status: New => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to ltsp in Ubuntu.
https://bugs.launchpad.net/bugs/936810

Title:
  Make ltsp-client package installable on regular machines

Status in Linux Terminal Server Project:
  In Progress
Status in “ltsp” package in Ubuntu:
  In Progress

Bug description:
  In the past, trying to install the ltsp-client package in regular
  machines resulted in the following error:

  > Installation aborted
  > 
  > ltsp-client cannot be installed in a regular machine.
  > This package provides the basic structure for a LTSP terminal.
  > 
  > Please read the package description to understand what it means
  > 
  > [OK]

  That's because it required special changes to the operating system
  done by ltsp-build-client.

  In LTSP 5.3, most of those changes were moved from the chroot build phase to the client boot phase (/sbin/init-ltsp), and it makes sense now for the ltsp-client package to be installable, because of the following expected benefits:
   * Users that need chroots with different architectures than the server (e.g. amd64 server, powerpc clients) will be able to install the OS normally on one client, then install ltsp-client on top of it, and transfer the result to the server.
   * The same for users that need proprietary drivers that can't be installed if they don't detect the hardware attached at the installation phase (e.g. smartboards, graphics card drivers etc).
   * It will be possible to manage virtual disks (not "chroots" anymore) by booting them with a virtualization technology, e.g. KVM or VirtualBox. Some programs have problems when ran in chroots.
   * It will be possible to manage fat clients graphically, without requiring the use of command line. 
   * It will be possible to boot LTSP "chroots" from local hard disks on the clients. While this sounds silly, LTSP offers very easy centralized user account, home and settings management. So regular computer labs with slow 100 MBps networks could get the benefits of LTSP fat clients by just installing ltsp-client locally. Or a sysadmin could prepare an "instant LTSP fat client DVD/usb stick" for his roaming users.
   
  Current problems with local boot when ltsp-client is installed:
   [TODO] ltsp-client-core.preinst checks if /etc/ltsp_chroot exists, while it shouldn't.
   [DONE] ltsp-client-core should only start if init=/sbin/init-ltsp is passed in the kernel command line (fixed in r2080).
   [TODO] The ltspfsd package udev rules should be put somewhere in /usr/share/ltspfsd and should be linked to /lib/udev/rules.d by an init-ltsp.d/ script.

  After the user is done preparing his local image, he's expected to transfer it to the server somehow (e.g. for the VirtualBox case, with a vdi2squashfs script, yet to be developed), and the clients will then boot with that image.
  Current problems with remote boot when ltsp-build-client wasn't used to build the "chroot":
   [TODO] The SERVER variable gets the wrong value.
   [TODO] The local user accounts need to be temporarily deleted by an init-ltsp.d/ script.
   [DOCS] The server ssh keys are't tranferred. The user is expected to run `sudo ssh user at server` from his local installation to fetch the keys, or if he transfers the image to the server, to run ltsp-update-sshkeys there.
   [TODO] The Debian LDM theme was selected instead of the Ubuntu one.

  Finally, for the case where we want to boot LTSP from the local disk:
   [TODO] It'd be nice if a grub entry was automatically inserted (like /etc/grub.d/20_linux_xen does for Xen).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ltsp/+bug/936810/+subscriptions