Not so insane,
Back in LTSP2.0 days the client mounted the LTSP servers /usr directory.
My server was a Sun Solaris box with a copy of a Redhat 7.2 linux
directory structure (with compiler etc) that was mounted by the clients.
I had several old production Linux boxes (Redhat 7) that did not have
compilers. If I required to compile something for them I would log onto
an LTSP client and compile the package and copy it across to the other
box for the make install.
I did this up until early this year when I finally turned off the last
LTSP2.0 client and upgraded the RH7 boxes.
Which reminds me, the directory structure is still on the Solaris box,
better go and delete it.
Why not use a decent client to compile the client code on the server
with a RW filesystem. Of course, the client must not compile for its own
architecture but a more generic one.
Regards
Darryl
jm wrote:
On 29/06/2005, at 7:10 AM, Pål Arne Hoff wrote:
I think your into something here. I built binary drivers for NVidia
using NVidia's installer program in the LBE, and I had to do some
symlinking to make it run at all, and when it was finished, a lot of the
files had ended up in wrong places and had to be moved to work. If the
LBE had been organized the way you're sugesting, I don't think I would
have had a problem at all.
When that's said, I really don't have a clue to where to begin
reorganizing the thing...
I started blindly reorganising things. Starting with the crosscomp-src
(super)package/bundle. Modified things to install under lbe/tools and
let the build script run until it fell over. Then went home. While
think about this overnight it occurred to me that there are going to
be a couple of problems with this method. As things are cross compiled
anything that executes a config program will break as it wont run
unless it's being compiled on a compatible architecture. For example,
say your on an i686, if ltsp is being built not for an i386, but say
it was to be built for a mips processor then the execution of a config
program would segfault. I don't know if ltsp can be built for anything
other than i386, but as a cross-compile is being done I assume it's
theoretically possible. The other problem is that this is really only
applicable to what I'll call mid-weight clients - to fat to be thin,
but to thin to be fat. Those clients that may have a lot of processing
power, but may be missing hard drives, etc for easy of management. So
why burden the whole process.
This train of thought lead me to a fifth possibility. Add into the
ltsp-src tree a package management system for installed ltsp. This
would mean adding gcc and associated tools within /opt/ltsp/i386 which
may or may not have drawbacks depending on what you are trying to do.
This would mean compiling somethings for what would be the fourth
copy. Again, I would think that placing the tools in a tools directory
for easy removal later would be the way to go. You would then have to
mount this image on a machine which is the intended target and install
the last few trouble some packages. Not ideal either.
jm.
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.freenode.net
DISCLAIMER
The contents of this electronic message and any attachments are intended only
for the addressee and may contain legally privileged, personal, sensitive or
confidential information. If you are not the intended addressee, and have
received this email, any transmission, distribution, downloading, printing or
photocopying of the contents of this message or attachments is strictly
prohibited. Any legal privilege or confidentiality attached to this message and
attachments is not waived, lost or destroyed by reason of delivery to any
person other than intended addressee. If you have received this message and
are not the intended addressee you should notify the sender by return email and
destroy all copies of the message and any attachments. Unless expressly
attributed, the views expressed in this email do not necessarily represent the
views of the company.
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.freenode.net
