| |
CHOS - FAQ
- What is CHOS?
CHOS is a framework for concurrently running multiple Linux environements (distributions)
on single node. This is accomplished through a combination of the chroot system call,
a Linux kernel module, and some additional utilities. It can be configured so that users
are transparently presented with their selected distribution on login.
- Why would I want to use CHOS?
CHOS is most useful on a shared resource where different users require different Distributions
or releases of Linux. For example, if user Bob needs RedHat 7.3 and user Sara needs RedHat 9,
then CHOS can simplify supporting these users.
- What is the license for CHOS?
CHOS is distributed under a modified BSD license.
- How do I install CHOS?
You can use the rpm or install from a source tar file. See the included INSTALL
file for details.
- What is a base OS? What is a CHOS OS?
These terms are used to distinguish the different Linux OS distributions and versions
that can be involved in a CHOS installation. The base OS or boot OS refers to the
distribution that is initially booted by the kernel. So the distribution that
includes the init executed by the kernel on boot would be considered the base OS.
A CHOS OS is any of the potentially many distributions that the users are allowed to switch
to. It can be created by copying an installed distribution from another system
or by unpacking packages into an alternate directory. You could even have two
complete trees of the same distribution that only differ by some start up
files. These would be considered different CHOS OSs or OS trees.
The terminology is still evolving. As it converges, the documentation will be updated.
- What are the different pieces in CHOS?
CHOS is composed of several pieces. The primary pieces are...
- Loadable Linux Kernel Module
- Command line utility (currently set uid for the chroot call)
- PAM module
The system admistrator must also install the additional OS distributions in
area that CHOS can access.
- Why is a kernel module needed?
Technically its not. One could simply chroot to the different trees. However,
for a chrooted environment to fully function, other pieces need to be available.
For example, /proc and other virtual file systems need to be mounted underneath
the chroot tree. Also, if an automounter is used or other NFS mounts are needed, then
those also must be accessible inside the chroot tree. Doing this for more than one
or two OS trees would become messy. The kernel module allows the same framework
(and mounts) to be reused for multiple OS trees. The kernel module accomplishes this
by providing a special symbolic link whose target is dependent on the process that
asks. For example, proc 100 could see the link pointing to one directoy, while process
101 points to another. The link also has the important characteristic that children processes
automatically inherit the value of their parent (unless they override it). Using this link, the following would
occur when accessing /bin in an CHOS tree.
/chos/bin -> /proc/chos/link/bin -> /process dependent path/bin
All users using CHOS are chrooted to /chos, but each can see a different set of links.
This means one user could get /nfsserver/redhat73/bin/ and another may get
/nfsserver/redhat9/bin/. In fact, the same user could use one OS tree in
one login and another OS tree in a seperate login.
The real benefit though is only one set of additional
mounts or automounters are need to support an array of OS tres.
- How do I integrate CHOS into my batch system?
There is a sample job starter than does this. You must configure your batch system
to pass the CHOS environment variable to the execuation host. The job starter can then
see this and automatically run the chos utility when executing the job.
- What's broken? What are the known problems?
Here are the few we are aware of...
- Cronjobs and atjobs don't automatically run in the CHOS environement. A pam enabled version
of vixie-cron is available. This would solve it for CRON, but AT would still be broken.
- parallel jobs may not automatically switch to the CHOS environment. This is definitely
a problem under SGE. We hope to provide a patched rshd to fix this.
- Are there other uses for CHOS?
We think so. Here are some that we have thought of.
- Use a very light weight base OS. This could be heavily stripped down. For example, you could
use a framework like warewulf to boot nodes,
and then users could use standard linux distributions under CHOS.
- Strip down the base OS to limit the usefulness of a root compromise. Imagine a base OS so
stripped down that it acts like a chroot jail. This would require some changes to CHOS to make
it more effective. For example, you would need to prohibit root from perforning a CHOS.
- Deploy grid application with a full CHOS tree. This would simplify using new grid resources. You
essentially extend the envelope of what is the application. The application would include the
OS components used by the application.
- Testing new releases and OS distributions. Upgrading with CHOS could be done by first copying
a working tree and doing the upgrades. Users could test the new release by selecting the test tree.
If things are broken, they simply switch back.
- What has CHOS been tested with?
CHOS has been tested with a varity of base (or boot) distributions and CHOS OS distributions.
Here are some...
CHOS has been built on both 2.4 and 2.6 kernels and on both i386 and x86_64 architectures.
- Why can't I get CHOS to build with my RedHat 9 kernel?
The RedHat 9 kernels have several 2.6 back ports. Here is a patch to fix CHOS for
those kernels. In the future we should have the logic integrated into the standard source.
RedHat 9 patch
- What is planned for the next release?
The next version (0.4) has a couple of siginificant changes. The main one is that the chroot
is performed in the kernel module. This removes the need for a set uid root program. It
also means the pam module can function from a non-root daemon (such as a job starter). Valid
OS trees are specified by echoing them into a proc file which must be done as root, so it should
be just as secure as before. Currently
the startup script looks at /etc/chos and echos in the valid installs. There were two reasons
for this change. One, I had concerns about requiring a set uid root program. While I wrote the
utility with security in mind, I would prefer to remove the risk. To a certain degree I simply shifted
the risk to the kernel module, but this risk was already present. Second, allowing non-root
programs to issue a chos session has some interesting benefits. My plan is to right a PAM enabled
job starter. With this job starter, enabling chos would just require modifying a pam configuration
file.
Back to top
|
