[prev in list] [next in list] [prev in thread] [next in thread] 

List:       klik-devel
Subject:    Re: [klik-devel] klik-devel Digest, Vol 15, Issue 1
From:       "Lionel Tricon \(perso\)" <lionel.tricon () free ! fr>
Date:       2007-05-24 8:02:09
Message-ID: 46554681.7060706 () free ! fr
[Download RAW message or body]

Thomas Leonard a écrit :
> Sounds good... but can we separate this from the installation system?
>   
Not sure i understand what you mean by "separate this from the
installation system". In fact there are several virtualization solution
for klik2 available and my solution (fuse based only) is one of them
(maybe not the best one but the only workable for the moment). In
details, i patched fuseiso and fusecramfs to merge to real filesystem
with the filesystem located into an iso or cramfs file. When i mount
such a filesystem on a directory (for example /tmp/app/1/mnt), i use a
fake chroot (based on the LD_PRELOAD feature) to put the merged
filesystem into a jail. The application run into the virtual namespace
whereas the application files are not really installed on disk.

The example below show you quickly how it works to execute an
application located into a cmg file :

# mkdir -p /tmp/app/1/mnt
# ln -s ~path/fichier.cmg /tmp/app/1/image
# /opt/klikutils/bin/fuse[iso|cram] -n -u /opt/klikutils
/tmp/app/1/image /tmp/app/1/mnt
# export KLIK_BASENAME=/opt/klikutils
# export FAKECHROOT_EXCLUDE_PATHS=/tmp:/proc:/dev:/var/run
# export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${KLIK_BASENAME}/lib/fakechroot
# export LD_PRELOAD=$LD_PRELOAD:libfakechroot.so
# ${KLIK_BASENAME}/bin/chroot /tmp/app/1/mnt
<run the application>
# exit
# /opt/klikutils/bin/fusermount -u /tmp/app/1/mnt
# rm -f /tmp/app/1/image
# rmdir /tmp/app/1/mnt/
# rmdir /tmp/app/1

And remember that in the klik model, 1 app == 1 file. A cmg package
cannot depends of an another cmg package. Each one run in its own namespace.

With all of that, you do not need to relocate the application al all.
> Again, that sounds useful, but possibly for other programs too (e.g.
> programs installed using apt-get). Will you be supporting multiple
> 'profiles' per program? e.g.
>   
When you run fuseiso or fusecram, you can redirect the modification into
a directory. It works for the application located into the cmg file as
well for all applications available on disk (there are no difference
between both, you run what you want, real application or virtualized
application ; you can fuse mount an empty cmg file and launch a real
application without any troubles). To be accurate, only the $HOME of the
user is concerne (it's by design and can be changed easily). I consider
that a normal user will only modify it's private directory, not other
part of the root filesystem.

So, you can put modifications into an usb key or into a file mounted in
loopback (we can use mountlo which is fuse-based for that).

Again, i don't know exactly what you mean by "multiples profiles" but i
guess that yes since you can redirect each time data in a new location.
For the moment, the backend is ready but nothing is done to integrate it
for the end user ; the engine is ready but not the frontend !

Just an example. The following make a union between the root directory
and the filesystem present into the test.cmg file (the new directory
will be available into the /tmp/app/1/mnt filesystem). The -b option
redirect writes from the $HOME user into the /tmp/test directory.

You have just to put the /tmp/app/1/mnt directory into a jail from the
application point of view and you can run it (since fuse do not support
by design special files and suid bits, we exclude from the jail some
directories like /tmp, /proc, /dev and /var/run to allow direct access
on them).

# /opt/klikutils/bin/fuseiso -n -u /opt/klikutils -b /tmp/test
/home/lionel/Desktop/test.cmg /tmp/app/1/mnt

That's how it works,
Lionel
_______________________________________________
klik-devel mailing list
klik-devel@kde.org
https://mail.kde.org/mailman/listinfo/klik-devel

[prev in list] [next in list] [prev in thread] [next in thread]