[Pkg-ltsp-devel] features i'd like to work on

[Vagrant Cascadian]

On Tue, Jul 04, 2006 at 09:16:57AM -0300, Otavio Salvador wrote:
> Vagrant Cascadian <vagrant at freegeek.org> writes:
> 
> > the first one is a wrapper around chroot that does special things like
...snip... 
> I like the idea but I found some problems with current code:
> 
>  - arch detection is debian dependent. There's already made code to be
>    generic in set-arch and you might do a look at it;

yeah, it was just a quick and dirty implementation. if you read the
TODO comments, you'll notice i was aware of this :P

>  - impossibility to set ROOT to something different of /opt/ltsp while
>    in ltsp-build-client it's possible;
 
> The way the I see to workaround this issues is to use a ltsp common
> plugin repository to set the architecture and root running same code
> that will be run by ltsp-build-client. 

yeah, i was thinking some of this stuff could be moved into some common
functions.

> The most complicated problem
> is, when the user use --base it won't be passed to ltsp-chroot and
> then we'll need to pass the commandline option. That won't make too
> much difference of current way to do it.

which could be handled by setting the ROOT environment variable, or
putting a configuration file in /etc, or adding a commandline argument
to ltsp-chroot (all of this was possible with the lessdisks version).

i'd kind of like to improve support for non-standard install locations
anyways, but that's another issue :)

the lessdisks script i largely based ltsp-chroot on is:

http://dev.lessdisks.net/projects/lessdisks/browser/trunk/install/usr-sbin/lessdisks-chroot

> > i'd also like to split some of the functionality found in
> > ltsp-update-kernels get split into the ltsp-client package, and have it
> > run chrooted(or in the case of a different architecture, on a privledged
> > client with write access of some sort). then the ltsp-update-kernels
> > package would mostly just copy files into place(and maybe run chrooted
> > scripts if the architecture is supported), rather than the special
> > network-bootable preparations(mknbi, yaboot, netabootwrap, etc). this
> > way we could get support for multiple architectures.
> 
> I didn't understand this last one. If we remove mknbi and like we
> loose support to anything but pxe. No?

what i was suggesting was to move that code (mknbi, yaboot,
netabootwrap, etc) into a script within the chroot that gets run
chrooted (or on a priveledged client if the arch is incompatible).

so ltsp-update-kernels would do something like this:

* look for chroots with supported architecture
  * run chrooted script (for mknbi, yaboot, netabootwrap, etc)
* copy images and/or kernels into the tftp directory
* other tweaks (such as pxe configuration)

live well,
  vagrant