Bonjour ($echo "hello world!"),
I'm François, a physicist in France.
i apologize for this long message but
i think it's necessary to explain my problems !
thank you in advance for your time !
I have 2+ questions Q1 and Q2 (see below) !
Here at Caen (University and Physics lab) we tried ltsp (2.09pre3.0)
for a computing classroom for students. More, we're testing
ltsp for a professionnal use with physicists.
It works fine in a very simple configuration between
a PII 233MHz server with 96Mo RAM running Redhat 7.1.
The only connected client is a Celeron 700MHz 128Mo RAM.
I have 13 others clients more of the same familly to add to this
"cluster" ! After this first step, we consider now
to use all the local CPU and HD on clients (powerful machines are cheap)
That means:
1 - using the ltsp system to initiate the configuration of the clients
(we like this unique lts.conf and a few other standard+homemade
scripts on the server side)
2 - loading a full linux distro on the client box:
* some parts can be mounted via NFS
* others parts are used only as templates to populate a rw ramdisk
* "merging" some config file from ltsp with this loaded distro
* we don't like when a client use the same /usr
than the server ! we really prefer to use an independant
partition with a dedicated linux installation for clients
that make possible to have more than one distro, to have
experimental client template distro...
3 - mounting a local swap partition
4 - mounting a local scratch partition /tmp what about var/ ?
5 - using the floppy and cdrom without tricks
Briefly speaking,
we want the advantages of the central administration from dhcp/ltsp
and the advantadges when using the local CPU on the client side.
We think this kind of approach can be an interesting alternative
to the standard ltsp approach with the LOCAL_APPS option
that seemed to us quite limited (unless we missunderstood
something!)
It should not prevent to use the ltsp basics with some
very light clients.
Q1 : do you think our approach is valuable
and that ltsp can be a good base for it ?
Now the technical stuff !
we use the 2.09pre4.0 (there was a problem at boot time
with the kernel version
and the modules, so we copied the 2.09pre3/lib/modules in the
/opt/ltsp/i386/lib/modules and it worked again... may be we should not
do this !)
We looked at the ltsp scripts and found that this call to pivot_root
was a good idea.
We export from the serevr a full redhat install on a dedicated
disk:
server:/opt/ltsp/i386 (ltsp standard)
server:/some-path/rh7.1-clients/bin
server:/some-path/rh7.1-clients/sbin
server:/some-path/rh7.1-clients/lib
server:/some-path/rh7.1-clients/usr
server:/some-path/rh7.1-clients/etc
server:/some-other-path/n-home
note that we could use an other NFS server for
exporting the template rh distro.
After the first ltsp step (linux.rc form the ltsp_initrd package):
we use a modifed /etc/rc.local script:
- we build a new ramdisk (4096 ko) on /tmp ok,
- we create 2 dirs:
/tmp/wsroot
and
/tmp/wstemplate
- we mount ro via NFS:
server:/som~clients/bin on /tmp/wsroot/bin
server:/som~clients/sbin on /tmp/wsroot/sbin
server:/som~clients/lib on /tmp/wsroot/lib
server:/som~clients/usr on /tmp/wsroot/usr
server:/som~clients/lib on /tmp/wsroot/lib
- we mount rw via NFS:
server:/som~er-path/n-home on /tmp/wsroot/home
- we mount ro via NFS:
server:/som~clients/etc on /tmp/wstemplate/etc
should we do the same for the .../var/ ?
- we copy this /tmp/wstemplate/etc in the ramdisk
cp -a /tmp/wstemplate/etc /tmp/wsroot/
now this /tmp/template/etc is writable
- then at the end of the script we try a new pivot_root:
cd /tmp/wsroot
mkdir oldroot
/sbin/pivot_root . oldroot
and it does not work with this sad message:
pivot_root: pivot_root: invalid argument
Q2 : what is the problem ?
- what about the uClibc.so , is it used by busybox ?
- we used:
chroot .
bash
- it works but does it do the same than pivot_root ?
- what to do with the /var , /mnt and /dev directories ?
- do you forsee other problems with this approach ?
that's all
----
ltsp is a very, very good project
thank you to the ones who develop it and to the other ones
who contribute to its improvement!
frc
--
François Mauger
Laboratoire de Physique Corpusculaire de Caen et Université de Caen
ISMRA - 6, Boulevard du Marechal Juin, 14050 CAEN Cedex, FRANCE
e-mail: [EMAIL PROTECTED] -- fax: (0/33) 2 31 45 25 12
web-page: http://www.physique-eea.unicaen.fr/~fmauger/
_____________________________________________________________________
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.openprojects.net
