|Deletions are marked like this.||Additions are marked like this.|
|Line 14:||Line 14:|
'''Note:''' Due to blockers in authentication, it has been recommended that this spec is defered to Edgy+1
|Line 70:||Line 72:|
|== Outstanding issues ==||== Blockers ==|
|Line 72:||Line 74:|
|* In earlier tests (breezy), GDM would crash if you start more than 10 clients simultaniously, I think this might be due to GDM trying to to write to the same file/socket at the same time (this will be properly logged upon further tests with Dapper and Edgy)||* Authentication needs to happen in 'Ubuntu' (SoC project)|
Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/ltsp-fat-clients
Created: 2006-06-21 by JonathanCarter
Packages affected: ltsp-server, ltsp-server-standalone, dhcp3-server
Ubuntu LTSP should provide a quick and effective method to install a diskless workstation that runs all applications locally from within the NFS or otherwise exported chroot.
Note: Due to blockers in authentication, it has been recommended that this spec is defered to Edgy+1
LTSP cuts down on administration overhead, and has proven to be popular in education, and is becoming more popular in the commercial sector. LTSP does have limitations and complexities, for example, local devices (storage, peripherals, etc) are often complicated, and multimedia saturates network bandwidth quickly and becomes unusable.
Diskless Fat Clients would allow an administrator to use powerful workstations as diskless machines, maintaining the benefits of easy administration, while eliminating the current limitations that exists with current thin client implementations.
- A school uses new computers as diskless machines. Using P4 machines with 256MB RAM is wasteful as pure thin clients, and adds limitations on performance and multimedia.
- A scenario where you would want to easily migrate a Windows lab to dual boot to Ubuntu. Ubuntu could then be provided via LTSP, users could then simply boot locally for the legacy operating system.
- A company wants to implement PoS systems that would communicate via serial ports to petrol pumps, credit card machines, etc that would not be supported under traditional LTSP.
- A graphics studio using diskless machines for graphical intensive purposes.
- A university which runs CPU intensive tasks on workstations.
- A home user who wishes to do less admin on all his/her machines, and would like to have one central computer stored in a safe place and using the rest of the computers as workstations.
A successful implementation will provide a quick and easy method for administrators to deploy an Ubuntu fat client terminal server. This applies to all derivatives and Ubuntu based distributions.
Additional packages need to be installed in the current default Ubuntu LTSP chroot, which includes, but are not limited to: gdm, ubuntu-desktop
- User data should be stored on the server disk space, not in the LTSP chroot. This requires authentication with home directory mounting off the server, using an appropriate method of authentication.
Ideally, a user should be able to choose whether a client should boot as a thin, or fat client by specifying a tag in the lts.conf file. A thin client and a fat client could share the same chroot, a thin client would just start up LDM (or a potentially new GDM with ssh tunnelling capability), while the fat client would start GDM and allow the user to log in to the LTSP chroot.
Implementation requires some changes to the preseeds used for the chroot installation, as well as an automated authentication setup. Some changes will be required to the LTSP configuration scripts, in order to allow 'dual booting' between thin and fat clients.
Methods that could be used:
Rsyncing/copying passwd, shadow, group
- NIS - Probably not the best choice
- LDAP - looks promising (information available from the LTSP wiki)
Needs some scripting love, but easy. Cleaning up of some config file stuff, and a nice gui/debconf/whatever front end to get the server, etc. Refer to NetworkAuthentication spec.
- Kerberos (doesn't give you a filesystem, just authentication)
Filesystems could be exported via:
- LTSP NBD swap will be used for swap
- LTSP NBD swap needs to be implemented for Ubuntu LTSP
- Additional scripts and code needed should be possible to integrate and be built on top of current LTSP initialisation scripts, re-using as much code as possible.
Some postinst scripts might have to be written to allow the automatic setup of authentication.
- Authentication needs to happen in 'Ubuntu' (SoC project)
BoF Agenda and discussion
JonathanCarter - Quick introduction to specification
[https://launchpad.net/distros/ubuntu/+spec/ltsp-fat-clients Spec Subscribers] - discuss roadblocks, suggestions and improvements.
- We will be available on the Ubuntu Teamspeak server, from 15:00 - 16:00 UTC. Discussion items will be added below.
RodrigoNovo: We should have an option in LTSP manager to set certain clients as thin clients of fat clients on boot.
- Blocker points: Authentication and home directories
RodrigoNovo: Suggests that this is defered to Edgy+1
JimMcQuillan: What about printing, what happens to /var/spool/print? (Needs further discussion)
- We could export this directory from the server, this will create more network traffic though.
JimMcQuillan: What about tmp files? This goes all into RAM.
JonathanCarter: We could store tmp files in home directory, avoiding keeping true tmp files in RAM.