[Pkg-ltsp-devel] next upload

[Vagrant Cascadian]

On Mon, Sep 04, 2006 at 10:41:06AM -0300, Gustavo Franco wrote:
> On 9/4/06, Vagrant Cascadian <vagrant at freegeek.org> wrote:
> >so, i'd like to push some things into pkg-ltsp main branch in
> >preparation for another upload...
...snip... 
> >(in addition to the other things already in pkg-ltsp main)
> >
> >i tested the localdev support today. it seems to at least partially
> >work, but it requires ltspfs/ltspfsd packages. i pulled the ubuntu
> >sources and built them on sid, and they seem to basically work.
> 
> Cold you give me more details about these tests? Can we upload ltspfs soon?

well, i've built packages for it on sid without any real modifications
from ubuntu sources:

http://llama.freegeek.org/~vagrant/debian/unstable/

ltspfs is the server-side component, and ltspfsd is the client-side
component.

add user to "fuse" group. add LOCALDEV=True in
/opt/ltsp/i386/etc/lts.conf. boot and login via ldm :)

i tried it on one machine, and it only appeared to work for an usb cdrom
drive, not for a usb stick or internal cdrom drive. i didn't
test if icons are automagically created on a desktop, but the mount was
happening.

the really cool thing is that communication between the terminal and
server is happening through the ssh tunnel.
 
> >i think we could upload new packages with just the above + pkg-ltsp
> >main, but consider these, too:
> >
> >http://llama.freegeek.org/~vagrant/bzr/ltsp/features/vagrant-ltsp-plugins
> >
> >this splits the load_plugins function out of ltsp-server into a file
> >that can be sourced, and moves the plugins into
> >/usr/share/ltsp/plugins/ltsp-build-client, to make it possible for other
> >scripts to start using the same plugins system.
> 
> If it works, why not ?

it's one of those seemingly major changes that's really pretty minor.
works for me :)
 
> >http://llama.freegeek.org/~vagrant/bzr/ltsp/features/vagrant-ltsp-swap
> >
> >includes support for encrypted swap with cryptsetup, NBD or local.
> >the one thing i don't like about this is that the nbd-client's init
> >script is ran after ours, so i manually called nbd-client from
> >ltsp-client's init script. we could possibly move ltsp-client's init
> >script to later in the process to implement it more properly.
> 
> Are we sure that move ltsp-client's later in the process won't break 
> anything?

it worked fine on my test runs with a default setup, but S20 is the default,
so it might break things in more complicated setups(i.e. diskless
workstations).
 
> >http://llama.freegeek.org/~vagrant/bzr/ltsp/features/vagrant-ltsp-locale
> >
> >plugin to set up the chroot with locales installed on the server. that
> >was pretty easy. still need to remove some of the hard-coded calls that
> >set LC_ALL before doing things in the chroot, as any that run after the
> >plugins stuff should be able to run with proper localization :)
> 
> I like that. Btw, have you tried without some LC_ALL sets too?

haven't yet. others more experienced with localization issues should try
it out :)
 
> >also, currently our support for architectures other than i386, amd64,
> >powerpc, alpha and sparc is pretty poor. no kernels get installed, and
> >there's nothing that helps with creating network bootable images
> >installed. would this be the sort of thing to document in README.Debian?
> >(i also have theoretical patches for ia64 and hppa, based on:
> >http://bugs.debian.org/302638)
> 
> Are we sure that we're ok with i386, amd64, ppc, alpha and sparc? I
> can do tests with i386, and soon with amd64 and ppc too.

some rewriting of the code has happened since i've tested it on sparc
and alpha, but it worked at one time. testing on more architectures
would definitely be good :)

> I think the README.Debian can cointain 'per arch' instructions yes,
> and we can group the architecures that have the same instructions,
> eg.:
> 
> LTSP on your hardware
> ==================
> 
> Debian supports multiple hardware architectures, LTSP too. Some
> hardware require special configuration that is documented here.
> 
> FIXME: I think we can add a note about mixed environments (server
> running one arch and clients other) too. If Ubuntu has the same
> special needs, we can share the same documentation and replace
> "Debian" with "Debian and Ubuntu" above.

mixed environments still requires the ltsp-build-client to happen on
another machine, though of course the NFS export can host any
architecture.

> i386, amd64, ppc, alpha, sparc
> ========================
> 
> [ Instructions to build the chroot and post-chroot setup hints ]
> 
> arm
> ===
> 
> You need to do something before build the chroot..

sounds good to me. i'll write something up.

live well,
  vagrant