| 2012-02-20 08:44:43 |
Alkis Georgopoulos |
bug |
|
|
added bug |
| 2012-02-20 08:45:01 |
Alkis Georgopoulos |
ltsp (Ubuntu): status |
New |
In Progress |
|
| 2012-02-20 08:45:34 |
Alkis Georgopoulos |
ltsp (Ubuntu): importance |
Undecided |
Wishlist |
|
| 2012-02-20 08:45:48 |
Alkis Georgopoulos |
bug task added |
|
ltsp |
|
| 2012-02-20 08:47:07 |
Alkis Georgopoulos |
ltsp: importance |
Undecided |
Wishlist |
|
| 2012-02-20 08:47:07 |
Alkis Georgopoulos |
ltsp: status |
New |
In Progress |
|
| 2012-02-23 21:02:02 |
Alkis Georgopoulos |
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@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). |
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:
[DONE] ltsp-client-core.preinst checks if /etc/ltsp_chroot exists, while it shouldn't (fixed in Ubuntu's LTSP 5.3.2).
[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":
[DONE] The SERVER variable gets the wrong value (fixed in r2101).
[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@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). |
|
| 2012-03-07 08:20:02 |
Alkis Georgopoulos |
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:
[DONE] ltsp-client-core.preinst checks if /etc/ltsp_chroot exists, while it shouldn't (fixed in Ubuntu's LTSP 5.3.2).
[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":
[DONE] The SERVER variable gets the wrong value (fixed in r2101).
[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@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). |
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:
[DONE] ltsp-client-core.preinst checks if /etc/ltsp_chroot exists, while it shouldn't (fixed in Ubuntu's LTSP 5.3.2).
[DONE] ltsp-client-core should only start if init=/sbin/init-ltsp is passed in the kernel command line (fixed in r2080).
[DONE] 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 (fixed in r156).
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":
[DONE] The SERVER variable gets the wrong value (fixed in r2101).
[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@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). |
|
| 2012-03-07 08:21:16 |
Alkis Georgopoulos |
ltsp (Ubuntu): status |
In Progress |
Fix Released |
|
| 2012-03-07 08:21:44 |
Alkis Georgopoulos |
ltsp: status |
In Progress |
Fix Released |
|
