mirror of https://github.com/tLDP/LDP
998 lines
31 KiB
Plaintext
998 lines
31 KiB
Plaintext
<CHAPTER ID="Distributions">
|
|
<TITLE>Distribution specific installations (2.4) </TITLE>
|
|
<SECT1><TITLE>Installing openMosix</TITLE>
|
|
<para><emphasis>This Chapter deals with openMosix 2.4</emphasis></para>
|
|
<PARA> This chapter deals with installing openMosix on different
|
|
distributions. It won't be an exhaustive list of all the possible
|
|
combinations. However throughout the chapter you should find enough
|
|
information on installing openMosix in your environment.
|
|
</PARA>
|
|
|
|
<PARA> Techniques for installing multiple machines with openMosix will
|
|
be discussed in one of the next chapters.
|
|
</PARA>
|
|
|
|
</SECT1>
|
|
<SECT1><TITLE>Before getting openMosix</TITLE>
|
|
|
|
<PARA> First of all, you must understand that openMosix is made up of
|
|
a kernel patch and some user-space tools. The kernel patch is needed
|
|
to make the kernel capable of talking to other openMosix-enabled
|
|
machines on the network. If you download openMosix as a binary package
|
|
(such as an rpm file), you don't even need to take care about the
|
|
kernel patch because the kernel has been patched and compiled with the
|
|
most common default options and modules for you. </PARA>
|
|
|
|
<PARA> The user-space tools are needed in order to make an effective
|
|
use of an openMosix-enabled kernel. They are needed to start/stop the
|
|
migration daemon, the openMosix File System, to migrate jobs to
|
|
certain nodes and other tasks which are usually
|
|
accomplished with the help our good old friend: the command line
|
|
interface. About binary packages: the same as in the kernel patch goes
|
|
for the user-space tools: if you install an rpm you don't need to
|
|
care about compiling them or configuring anything; just let them install
|
|
and run. That's all. Really :) </PARA>
|
|
|
|
<PARA> Once you get to the download page (which we'll talk about in a
|
|
second), you'll need to get two distinct parts: the kernel and the
|
|
user-space tools. You can either download two binary packages or get
|
|
the kernel patch plus the user-space tools' sources. The kernel patch
|
|
is usually named after this scheme: openMosix-x.y.z-w where x.y.z is
|
|
the version of the vanilla Linux Kernel against which the patch should
|
|
be applied and w is the patch revision for that particular kernel
|
|
release. For the precompiled kernel binaries, please refer to the
|
|
README-openMosix-kernel.txt file you'll find in the download
|
|
page. This file also contains updated info about manually compiling a
|
|
kernel. </PARA>
|
|
|
|
<PARA> About the user-space tools: you'll find those in a package
|
|
named openmosix-tools. We use the terms user-space tools,
|
|
userspace-tools and openmosix-tools interchangeably.
|
|
Updated info about precompiled binaries and
|
|
manually compiling the tools are also provided in the
|
|
README-openmosix-tools.txt file. Please note that since version 0.3 of
|
|
the openmosix-tools, the openmosix.map file is deprecated and the use
|
|
of the autodiscovery daemon is highly encouraged since it tends to
|
|
make your life easier. </PARA>
|
|
|
|
</SECT1>
|
|
|
|
<SECT1><TITLE>Getting openMosix</TITLE>
|
|
|
|
<PARA>
|
|
You can download the latest versions of openMosix from <ulink
|
|
url="http://sourceforge.net/project/showfiles.php?group_id=46729">
|
|
<citetitle>http://sourceforge.net/project/showfiles.php?group_id=46729</citetitle></ulink>.
|
|
|
|
You can either choose the binary (even in rpm) compiled for UP or SMP
|
|
or download the source code. You will need both the kernel patch or
|
|
binaries and the userland tools.
|
|
|
|
Alternatively you can get the CVS version:
|
|
|
|
<PROGRAMLISTING>
|
|
|
|
cvs -d:pserver:anonymous@cvs.openmosix.sourceforge.net:/cvsroot/openmosix login
|
|
cvs -z3 -d:pserver:anonymous@cvs.openmosix.sourceforge.net:/cvsroot/openmosix co linux-openmosix
|
|
cvs -z3 -d:pserver:anonymous@cvs.openmosix.sourceforge.net:/cvsroot/openmosix co userspace-tools
|
|
|
|
</PROGRAMLISTING>
|
|
|
|
At the password prompt, just type enter since you're doing an
|
|
anonymous login. Please take care that CVS trees DO BREAK now and
|
|
then and that it might not be the easiest way to install openMosix ;-)
|
|
|
|
</PARA>
|
|
</SECT1>
|
|
|
|
<!--
|
|
<SECT1><TITLE>Getting Mosix (obsolete)</TITLE>
|
|
<PARA>
|
|
|
|
You can download Mosix from the www.mosix.org
|
|
<ulink url="http://www.mosix.org/txt_distribution.html"><citetitle>http://www.mosix.org/txt_distribution.html</citetitle></ulink>
|
|
|
|
for the Kernel Patches, and after you accepted the License agreement
|
|
<ulink url="http://www.mosix.org/txt_download.html"><citetitle>http://www.mosix.org/txt_download.html</citetitle></ulink>
|
|
|
|
for the Userland tools.
|
|
|
|
</PARA>
|
|
</SECT1>
|
|
-->
|
|
|
|
<SECT1><TITLE>openMosix General Instructions</TITLE>
|
|
<SECT2><TITLE>Kernel Compilation</TITLE>
|
|
<PARA>
|
|
|
|
Always use pure vanilla kernel-sources from <ulink
|
|
url="http://www.kernel.org/">
|
|
<citetitle>http://www.kernel.org/</citetitle></ulink> to compile an
|
|
openMosix kernel! Please be kind enough to download the kernel using a
|
|
mirror near to you and always try and download patches to the latest
|
|
kernel sources you do have instead of downloading the whole
|
|
thing. This is going to be much appreciated by the Linux community and
|
|
will greatly increase your geeky Karma ;-)
|
|
|
|
Be sure to use the right openMosix patch depending on the
|
|
kernel-version. At the moment I write this, the latest 2.4 kernel is
|
|
2.4.20 so you should download the openMosix-2.4.20-x.gz patch, where
|
|
the "x" stands for the patch revision (ie: the greater the revision
|
|
number, the most recent it is).
|
|
|
|
Do not use the kernel that comes with any Linux-distribution: it won't
|
|
work. These kernel sources get heavily patched by the
|
|
distribution-makers so, applying the openMosix patch to such a kernel
|
|
is going to fail for sure! Been there, done that: trust me ;-)
|
|
</PARA>
|
|
|
|
<PARA>
|
|
Download the actual version of the openMosix patch and move it in your
|
|
kernel-source directory (e.g. /usr/src/linux-2.4.20). If your
|
|
kernel-source directory is other than
|
|
"/usr/src/linux-[version_number]" at least the creation of a symbolic
|
|
link to "/usr/src/linux-[version_number]" is required.
|
|
|
|
Supposing you're the root user and you've downloaded the gzipped patch
|
|
file in your home directory, apply the patch using (guess what?) the
|
|
patch utility:
|
|
<PROGRAMLISTING>
|
|
mv /root/openMosix-2.4.20-2.gz /usr/src/linux-2.4.20
|
|
cd /usr/src/linux-2.4.20
|
|
zcat openMosix-2.4.20-2.gz | patch -Np1
|
|
</PROGRAMLISTING>
|
|
|
|
In the rare case you don't have "zcat" on your system, do:
|
|
<PROGRAMLISTING>
|
|
mv /root/openMosix-2.4.20-2.gz /usr/src/linux-2.4.20
|
|
cd /usr/src/linux-2.4.20
|
|
gunzip openMosix-2.4.20-2.gz
|
|
cat openMosix-2.4.20-2 | patch -Np1
|
|
</PROGRAMLISTING>
|
|
|
|
If the even more weird case you don't have a "cat" on your system (!),
|
|
do:
|
|
<PROGRAMLISTING>
|
|
mv /root/openMosix-2.4.20-2.gz /usr/src/linux-2.4.20
|
|
cd /usr/src/linux-2.4.20
|
|
gunzip openMosix-2.4.20-2.gz
|
|
patch -Np1 < openMosix-2.4.20-2
|
|
</PROGRAMLISTING>
|
|
|
|
|
|
The "patch" command should now display a list of patched files from
|
|
the kernel-sources.
|
|
|
|
If you feel adventurous enough, enable the openMosix related options
|
|
in the kernel-configuration file, e.g.
|
|
<PROGRAMLISTING>
|
|
...
|
|
CONFIG_MOSIX=y
|
|
# CONFIG_MOSIX_TOPOLOGY is not set
|
|
CONFIG_MOSIX_UDB=y
|
|
# CONFIG_MOSIX_DEBUG is not set
|
|
# CONFIG_MOSIX_CHEAT_MIGSELF is not set
|
|
CONFIG_MOSIX_WEEEEEEEEE=y
|
|
CONFIG_MOSIX_DIAG=y
|
|
CONFIG_MOSIX_SECUREPORTS=y
|
|
CONFIG_MOSIX_DISCLOSURE=3
|
|
CONFIG_QKERNEL_EXT=y
|
|
CONFIG_MOSIX_DFSA=y
|
|
CONFIG_MOSIX_FS=y
|
|
CONFIG_MOSIX_PIPE_EXCEPTIONS=y
|
|
CONFIG_QOS_JID=y
|
|
...
|
|
</PROGRAMLISTING>
|
|
|
|
However, it's going to be pretty much easier if you configure the
|
|
above options using one of the Linux-kernel configuration tools:
|
|
|
|
<PROGRAMLISTING>
|
|
make config | menuconfig | xconfig
|
|
</PROGRAMLISTING>
|
|
|
|
The above means you have to choose one of "config", "menuconfig", and
|
|
"xconfig". It's a matter of taste. By the way, "config" is going to
|
|
work on any system; "menuconfig" needs the curses libraries installed
|
|
while "xconfig" needs an installed X-window environment plus the
|
|
TCL/TK libraries and interpreters.
|
|
</para>
|
|
<para>
|
|
Now compile it with:
|
|
|
|
<PROGRAMLISTING>
|
|
make dep bzImage modules modules_install
|
|
</PROGRAMLISTING>
|
|
|
|
After compilation install the new kernel with the openMosix options
|
|
within you boot-loader; e.g. insert an entry for the new kernel in
|
|
/etc/lilo.conf and run lilo after that.
|
|
</PARA>
|
|
|
|
<PARA>
|
|
Reboot and your openMosix-cluster-node is up!
|
|
</PARA>
|
|
|
|
</SECT2>
|
|
<SECT2><TITLE>Syntax of the /etc/openmosix.map file</TITLE>
|
|
|
|
<PARA>
|
|
Before starting openMosix, there has to be an /etc/openmosix.map
|
|
configuration file which must be the same on each node.
|
|
</para>
|
|
<para>
|
|
The standard is now /etc/openmosix.map, /etc/mosix.map and /etc/hpc.map are old
|
|
standards, but the CVS-version of the
|
|
tools is backwards compatible and looks for /etc/openmosix.map,
|
|
/etc/mosix.map and /etc/hpc.map (in that order).
|
|
</para>
|
|
<para>
|
|
The
|
|
openmosix.map file contains three space separated fields:
|
|
<PROGRAMLISTING>
|
|
openMosix-Node_ID IP-Address(or hostname) Range-size
|
|
</PROGRAMLISTING>
|
|
|
|
An example openmosix.map file could look like this:
|
|
<PROGRAMLISTING>
|
|
1 node1 1
|
|
2 node2 1
|
|
3 node3 1
|
|
4 node4 1
|
|
</PROGRAMLISTING>
|
|
|
|
or
|
|
|
|
<PROGRAMLISTING>
|
|
1 192.168.1.1 1
|
|
2 192.168.1.2 1
|
|
3 192.168.1.3 1
|
|
4 192.168.1.4 1
|
|
</PROGRAMLISTING>
|
|
|
|
or with the help of the range-size both of the above examples equal to:
|
|
|
|
<PROGRAMLISTING>
|
|
1 192.168.1.1 4
|
|
</PROGRAMLISTING>
|
|
|
|
openMosix "counts-up" the last byte of the ip-address of the node
|
|
according to its openMosix-Node_ID. Of course, if you use a
|
|
range-size greater than 1 you have to use ip-addresses instead of
|
|
hostnames.
|
|
</PARA>
|
|
|
|
<PARA>
|
|
If a node has more than one network-interface it can be configured
|
|
with the ALIAS option in the range-size field (which equals to setting
|
|
the range-size to 0) e.g.
|
|
|
|
<PROGRAMLISTING>
|
|
1 192.168.1.1 1
|
|
2 192.168.1.2 1
|
|
3 192.168.1.3 1
|
|
4 192.168.1.4 1
|
|
4 192.168.10.10 ALIAS
|
|
</PROGRAMLISTING>
|
|
Here the node with the openMosix-Node_ID 4 has two network-interfaces
|
|
(192.168.1.4 + 192.168.10.10) which are both visible to openMosix.
|
|
</PARA>
|
|
|
|
<PARA>
|
|
<emphasis>
|
|
Always be sure to run the same openMosix version AND configuration on each
|
|
of your Cluster's nodes!</emphasis>
|
|
</PARA>
|
|
|
|
<PARA>
|
|
Start openMosix with the "setpe" utility on each node :
|
|
|
|
<PROGRAMLISTING>
|
|
setpe -w -f /etc/openmosix.map
|
|
</PROGRAMLISTING>
|
|
|
|
Execute this command (which will be described later on in this HOWTO)
|
|
on every node in your openMosix cluster.
|
|
</PARA>
|
|
|
|
<PARA>
|
|
Alternatively, you can grab the "openmosix" script which can be found
|
|
in the scripts directory of the userspace-tools, copy it to the
|
|
/etc/init.d directory, chmod 0755 it, then use the following commands
|
|
as root:
|
|
<PROGRAMLISTING>
|
|
/etc/init.d/openmosix stop
|
|
/etc/init.d/openmosix start
|
|
/etc/init.d/openmosix restart
|
|
</PROGRAMLISTING>
|
|
</PARA>
|
|
|
|
<PARA>
|
|
Installation is finished now: the cluster is up and running :)
|
|
</PARA>
|
|
|
|
</SECT2><SECT2><TITLE>oMFS</TITLE>
|
|
|
|
<para><emphasis>Note that oMFS has been removed from openMosix as of the 2.4.26-om1 release.
|
|
</emphasis>
|
|
</para>
|
|
<PARA>
|
|
First of all, the CONFIG_MOSIX_FS option in the kernel configuration
|
|
has to be enabled. If the current kernel was compiled without this
|
|
option, then recompilation with this option enabled is required.
|
|
</para>
|
|
<para> Also
|
|
the UIDs (User IDs) and GIDs (Group IDs) on each of the clusters'
|
|
nodes file-systems must be the same. You might want to accomplish this using
|
|
openldap. The CONFIG_MOSIX_DFSA option in
|
|
the kernel is optional but of course required if DFSA should be used.
|
|
To mount oMFS on the cluster there has to be an additional fstab-entry
|
|
on each node's /etc/fstab.
|
|
</PARA>
|
|
|
|
<PARA>
|
|
in order to have DFSA enabled:
|
|
<PROGRAMLISTING>
|
|
mfs_mnt /mfs mfs dfsa=1 0 0
|
|
</PROGRAMLISTING>
|
|
|
|
in order to have DFSA disabled:
|
|
<PROGRAMLISTING>
|
|
mfs_mnt /mfs mfs dfsa=0 0 0
|
|
</PROGRAMLISTING>
|
|
|
|
the syntax of this fstab-entry is:
|
|
<PROGRAMLISTING>
|
|
[device_name] [mount_point] mfs defaults 0 0
|
|
</PROGRAMLISTING>
|
|
|
|
After mounting the /mfs mount-point on each node, each node's
|
|
file-system is going to be accessible through the
|
|
/mfs/[openMosix-Node_ID]/ directories.
|
|
</PARA>
|
|
|
|
<PARA>
|
|
With the help of some symbolic links all cluster-nodes can access the same
|
|
data e.g. /work on node1
|
|
<PROGRAMLISTING>
|
|
on node2 : ln -s /mfs/1/work /work
|
|
on node3 : ln -s /mfs/1/work /work
|
|
on node3 : ln -s /mfs/1/work /work
|
|
...
|
|
</PROGRAMLISTING>
|
|
Now every node can read+write from and to /work !
|
|
</PARA><PARA>
|
|
|
|
The following special files are excluded from the oMFS:
|
|
|
|
<itemizedlist mark='opencircle'>
|
|
|
|
<listitem><para>the /proc directory</para></listitem>
|
|
|
|
<listitem><para>special files which are not regular-files,
|
|
directories or symbolic links (e.g. /dev/hda1) </para></listitem>
|
|
|
|
</itemizedlist>
|
|
</PARA>
|
|
|
|
<PARA>
|
|
Creating links like:
|
|
|
|
<PROGRAMLISTING>
|
|
ln -s /mfs/1/mfs/1/usr
|
|
</PROGRAMLISTING>
|
|
|
|
or
|
|
|
|
<PROGRAMLISTING>
|
|
ln -s /mfs/1/mfs/3/usr
|
|
</PROGRAMLISTING>
|
|
|
|
is invalid.
|
|
</PARA>
|
|
|
|
<PARA>
|
|
The following system calls are supported without sending the migrated
|
|
process (which executes this call on its home (remote) node) going
|
|
back to its home node:
|
|
</PARA>
|
|
|
|
<PARA>
|
|
read, readv, write, writev, readahead, lseek, llseek, open, creat,
|
|
close, dup, dup2, fcntl/fcntl64, getdents, getdents64, old_readdir,
|
|
fsync, fdatasync, chdir, fchdir, getcwd, stat, stat64, newstat, lstat,
|
|
lstat64, newlstat, fstat, fstat64, newfstat, access, truncate,
|
|
truncate64, ftruncate, ftruncate64, chmod, chown, chown16, lchown,
|
|
lchown16, fchmod, fchown, fchown16, utime, utimes, symlink, readlink,
|
|
mkdir, rmdir, link, unlink, rename
|
|
</PARA>
|
|
|
|
<PARA>
|
|
Here are situations when system calls on DFSA mounted file-systems may not
|
|
work:
|
|
|
|
<itemizedlist mark='opencircle'>
|
|
|
|
<listitem><para>different mfs/dfsa configuration on the
|
|
cluster-nodes</para></listitem>
|
|
<listitem><para>dup2 if the second file-pointer is
|
|
non-DFSA</para></listitem>
|
|
|
|
<listitem><para>chdir/fchdir if the parent dir is
|
|
non-DFSA</para></listitem>
|
|
|
|
<listitem><para>pathnames that leave the
|
|
DFSA-filesystem</para></listitem>
|
|
|
|
<listitem><para>when the process which executes the system-call is
|
|
being traced</para></listitem>
|
|
|
|
<listitem><para>if there are pending requests for the process which
|
|
executes the system-call</para></listitem>
|
|
|
|
</itemizedlist>
|
|
</PARA>
|
|
|
|
<PARA>
|
|
Next to the /mfs/1/ /mfs/2/ and so on files you will find some other
|
|
directories as well.
|
|
</para>
|
|
|
|
<table frame=all><title>Other Directories</title>
|
|
<tgroup cols=2 align=left>
|
|
<tbody>
|
|
|
|
<row>
|
|
<entry>/mfs/here</entry>
|
|
<entry>The current node where your process runs</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>/mfs/home</entry>
|
|
<entry>Your home node</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>/mfs/magic</entry>
|
|
<entry>The current node when used by the "creat" system call (or
|
|
an "open" with the "O_CREAT" option) - otherwise, the last node on
|
|
which an oMFS magical file was successfully created (this is very
|
|
useful for creating temporary-files, then immediately unlinking
|
|
them)
|
|
</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>/mfs/lastexec</entry>
|
|
<entry>The node on which the process last issued a successful
|
|
"execve" system-call.
|
|
</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>/mfs/selected</entry>
|
|
<entry>The node you selected by either your process itself or one
|
|
of its ancestor's (before forking this process), writing a number
|
|
into "/proc/self/selected".
|
|
</entry>
|
|
</row>
|
|
|
|
</tbody></tgroup></table>
|
|
<para>
|
|
|
|
Note that these magic files are all ``per process''. That is their
|
|
content is dependent upon which process opens them.
|
|
</PARA>
|
|
<para>
|
|
A last not about openMFS is that there are versions around that return
|
|
faultive results when you run <quote>df</quote> on those filesystems.
|
|
Don't be surpised if you suddenlty have about 1.3 TB available on those
|
|
systems.
|
|
</para>
|
|
</SECT2>
|
|
|
|
</SECT1>
|
|
|
|
<SECT1><TITLE>Red Hat and openMosix</TITLE>
|
|
<PARA>
|
|
If you are running a RedHat 7.2, 7.3 or 8.0 version, this is probably
|
|
the easiest *Mosix install you have ever done. Choose the appropriate
|
|
openMosix RPMs from sourceforge. They have precompiled kernels (as I
|
|
write this 2.4.20) that work seamlessly: I have tested them on several
|
|
machines including Laptops with PCMCIA cards and Servers with SCSI
|
|
disks. If you are a grub user, the kernel rpm even modifies your
|
|
grub.conf. So all you have to do is install 2 RPMs:
|
|
|
|
<programlisting>
|
|
rpm -Uvh openmosix-kernel-2.4.20-openmosix2.i686.rpm openmosix-tools-0.2.4-1.i386.rpm
|
|
</programlisting>
|
|
|
|
and edit your /etc/openmosix.map if you don't wish to use the
|
|
autodiscovery daemon (omdiscd).
|
|
|
|
Since this seems to be a problem for lots of people, let's go with
|
|
another example. Say you have 3 machines: 192.168.10.220,
|
|
192.168.10.78 and 192.168.10.84.
|
|
|
|
Your openmosix.map will look like this.
|
|
<programlisting>
|
|
[root@oscar0 root]# more /etc/openmosix.map
|
|
# openMosix CONFIGURATION
|
|
# ===================
|
|
#
|
|
# Each line should contain 3 fields, mapping IP addresses to openMosix node-numbers:
|
|
# 1) first openMosix node-number in range.
|
|
# 2) IP address of the above node (or node-name from /etc/hosts).
|
|
# 3) number of nodes in this range.
|
|
#
|
|
# Example: 10 machines with IP 192.168.1.50 - 192.168.1.59
|
|
# 1 192.168.1.50 10
|
|
#
|
|
# openMosix-# IP number-of-nodes
|
|
# ============================
|
|
1 192.168.10.220 1
|
|
2 192.168.10.78 1
|
|
3 192.168.10.84 1
|
|
</programlisting>
|
|
|
|
|
|
Now by rebooting the different machines with the newly installed
|
|
kernel you will get one step closer to having a working cluster.
|
|
</para>
|
|
|
|
<para>
|
|
Most RedHat installations have one extra thing to fix. You often get
|
|
the following error:
|
|
<programlisting>
|
|
[root@inspon root]# /etc/init.d/openmosix start
|
|
Initializing openMosix...
|
|
setpe: the supplied table is well-formatted,
|
|
but my IP address (127.0.0.1) is not there!
|
|
</programlisting>
|
|
|
|
This means that your hostname is not listed in /etc/hosts with the
|
|
same ip as in your openmosix.map. You might have a machine called
|
|
omosix1.localhost.org in your hostfile listed as
|
|
<programlisting>
|
|
127.0.0.1 omosix1.localhost.org localhost
|
|
</programlisting>
|
|
|
|
If you modify your /etc/hosts to look like below, openMosix will have
|
|
less troubles starting up.
|
|
|
|
<programlisting>
|
|
192.168.10.78 omosix1.localhost.org
|
|
127.0.0.1 localhost
|
|
</programlisting>
|
|
|
|
<programlisting>
|
|
[root@inspon root]# /etc/init.d/openmosix start
|
|
Initializing openMosix...
|
|
[root@inspon root]# /etc/init.d/openmosix status
|
|
This is openMosix node #2
|
|
Network protocol: 2 (AF_INET)
|
|
openMosix range 1-1 begins at 192.168.10.220
|
|
openMosix range 2-2 begins at inspon.localhost.be
|
|
openMosix range 3-3 begins at 192.168.10.84
|
|
Total configured: 3
|
|
</programlisting>
|
|
</PARA>
|
|
<para>If you would like to use more bleeding edge patches, you can always
|
|
opt for the src rpm and run rpmbuild --rebuild on it.
|
|
This will install the source for you and create an initial config file.
|
|
From there you can go further applying patches to openMosix
|
|
</para>
|
|
<para>A tutorial on how to build your own openMosix RPM's can be found in the Appendixes.
|
|
|
|
|
|
</para>
|
|
<para>As new RedHat versions come out, they might be supported out of
|
|
the box so, feel free to drop the author a note and help him keeping
|
|
this information updated.
|
|
</para>
|
|
</SECT1>
|
|
|
|
<SECT1><TITLE>Suse and openMosix</TITLE>
|
|
|
|
<PARA>Although the RPMs are being built on a RedHat based environment,
|
|
you can use most of them on other RPM based systems.
|
|
</para>
|
|
|
|
<para>
|
|
Suse however has /sbin/mk_initrd as a link to /sbin/mkinitrd, which
|
|
makes rpms before release 20-2 fail. Newer version should have a fix
|
|
for this.
|
|
</para>
|
|
|
|
</SECT1>
|
|
<!--
|
|
<SECT1><TITLE>Suse 7.1 and Mosix (obsolete)</TITLE>
|
|
<SECT2><TITLE>Versions Required</TITLE>
|
|
<PARA>
|
|
|
|
The following is based on using SuSE 7.1 (German Version), Linux
|
|
Kernel 2.2.19, and Mosix 0.98.0.
|
|
|
|
</PARA><PARA>
|
|
|
|
The Linux Kernel 2.2.18 sources are part of the SuSE distribution. Do
|
|
not use the default SuSE 2.2.18 kernel, as it is heavily patched with
|
|
SuSE stuff. Get the patch for 2.2.19 from your favorite mirror such as
|
|
. If there are further patches for the 2.2.* kernel
|
|
RROR URL HERE by the time you read this text, get those, too.
|
|
|
|
</PARA><PARA>
|
|
|
|
If one of your machines is a laptop with a network connection via
|
|
PCMCIA, you will need the PCMCIA sources, too. They are included in
|
|
the SuSE distribution as MISSING: RPM HERE.
|
|
|
|
</PARA><PARA>
|
|
|
|
Mosix 0.98.0 for the 2.2.19 kernel can be found on
|
|
<ulink url="http://www.mosix.org"><citetitle>http://www.mosix.org/</citetitle></ulink> as MOSIX-0.98.0.tar.gz . While you are there, you
|
|
might want to get some of the contributed software like qps or mtop.
|
|
Again, if there is a version more current than 0.98.0 by the time you
|
|
read this, get it instead.
|
|
|
|
</PARA><PARA>
|
|
|
|
SuSE 7.1 ships with a Mosix-package as a rpm MISSING: RPM HERE
|
|
Ignore this package. It is based on Kernel 2.2.18 and seems to have
|
|
been modified by SuSE (see /usr/share/doc/packages/mosix/README.SUSE).
|
|
You are better off installing the Mosix sources and installing from
|
|
scratch.
|
|
|
|
</PARA>
|
|
</SECT2>
|
|
|
|
<SECT2><TITLE>Installation</TITLE>
|
|
<PARA>
|
|
|
|
We're assuming your hardware and basic Linux system are all set up
|
|
correctly and that you can at least telnet (or ssh) between the different
|
|
machines. The procedure is described for one machine. Log in as root.
|
|
Install the sources for the 2.2.18 Kernel in /usr/src. SuSE will place them
|
|
there automatically as /usr/src/linux-2.2.18 if you install the RPM RPM
|
|
NAME. Rename the directory to /usr/src/linux-2.2.19. Remove the existing
|
|
link /usr/src/linux and create a new one to this directory with
|
|
|
|
|
|
<PROGRAMLISTING>
|
|
ln -s /usr/src/linux-2.2.19 linux
|
|
</PROGRAMLISTING>
|
|
|
|
(assuming you are in /usr/src). Patch the kernel to 2.2.19 (or whatever
|
|
the current version is). If you do not know to do this, check the Linux
|
|
Kernel HOWTO. Make a directory /usr/src/linux-2.2.19-mosix and copy the
|
|
contents of the vanilla kernel /usr/src/linux-2.2.19 there with the command
|
|
|
|
<PROGRAMLISTING>
|
|
cp -rp linux-2.2.19/* linux-2.2.19-mosix/
|
|
</PROGRAMLISTING>
|
|
|
|
|
|
|
|
This gives you a clean backup kernel to fall back on if something goes
|
|
wrong. Remove the /usr/src/linux link (again). Create a link /usr/src/linux
|
|
to /usr/src/linux-2.2.19-mosix with
|
|
|
|
|
|
<PROGRAMLISTING>
|
|
ln -s /usr/src/linux-2.2.19-mosix linux
|
|
</PROGRAMLISTING>
|
|
|
|
to make life easier. Change to /tmp, copy the Mosix sources there and
|
|
unpack them with the command
|
|
|
|
|
|
<PROGRAMLISTING>
|
|
tar xfz MOSIX-0.98.0.tar.gz
|
|
</PROGRAMLISTING>
|
|
|
|
Do not unpack the resulting tar archives such as /tmp/user.tar that appear.
|
|
|
|
</PARA>
|
|
</SECT2>
|
|
<SECT2>
|
|
<TITLE>Setup</TITLE>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
|
|
Run the install script /tmp/mosix.install and follow instructions.
|
|
|
|
</para><para>
|
|
|
|
|
|
Mosix should be enabled for run level 3 (full multiuser with network, no
|
|
xdm) and 5 (full multiuser with network and xdm). There is no run level 4
|
|
in SuSE 7.1.
|
|
|
|
</para><para>
|
|
|
|
The Mosix install script does not give you the option of creating a boot
|
|
floppy instead of an image. If you want a boot floppy, you will have to run
|
|
"make bzdisk" after the install script is through.
|
|
|
|
</para><para>
|
|
|
|
Do not repeat /not/ reboot.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
The install script in Mosix 0.98.0 is made for Red Hat distributions
|
|
and therefore fails to set up some SuSE files correctly. It tries
|
|
to put stuff in /sbin/init.d/, which in fact is /etc/init.d/ (or
|
|
/etc/rc.d/) with SuSE. Also, there is no /etc/rc.d/init.d/ in SuSE.
|
|
|
|
So:
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
|
|
Copy /tmp/mosix.init to /etc/init.d/mosix and make it executable
|
|
with the command
|
|
|
|
|
|
<PROGRAMLISTING>
|
|
chmod 754 /etc/init.d/mosix
|
|
</PROGRAMLISTING>
|
|
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem><para>
|
|
MISSING - MODIFY ATD stuff "/etc/rc.d/init.d/ATD" BY
|
|
HAND
|
|
</para></listitem>
|
|
|
|
<listitem><para>
|
|
MISSING - MODIFY THE "/etc/cron.daily/slocate.cron" FILE
|
|
</para></listitem>
|
|
<listitem><para>
|
|
|
|
The other files - /etc/inittab, /etc/inetd.conf, /etc/lilo.conf -
|
|
are modified correctly.
|
|
</para></listitem>
|
|
</itemizedlist>
|
|
</para></listitem>
|
|
<listitem><para>
|
|
Edit the file /etc/inittab to prevent some processes from migrating
|
|
to other nodes by inserting the command "/bin/mosrun -h" in the
|
|
following lines:
|
|
</para>
|
|
<para>
|
|
Run levels:
|
|
|
|
<PROGRAMLISTING>
|
|
l0:0:wait:/bin/mosrun -h /etc/init.d/rc 0
|
|
l1:1:wait:/bin/mosrun -h /etc/init.d/rc 1
|
|
l2:2:wait:/bin/mosrun -h /etc/init.d/rc 2
|
|
l3:3:wait:/bin/mosrun -h /etc/init.d/rc 3
|
|
l5:5:wait:/bin/mosrun -h /etc/init.d/rc 5
|
|
l6:6:wait:/bin/mosrun -h /etc/init.d/rc 6
|
|
</PROGRAMLISTING>
|
|
|
|
(Remember, there is no run level 4 in SuSE 7.1)
|
|
</para>
|
|
<para>
|
|
Shutdown and sulogin:
|
|
</para>
|
|
<PROGRAMLISTING>
|
|
~~:S:respawn:/bin/mosrun -h /sbin/sulogin
|
|
ca::ctrlaltdel:/bin/mosrun -h /sbin/shutdown -r -t 4 now
|
|
sh:12345:powerfail:/bin/mosrun -h /sbin/shutdown -h now THE \
|
|
POWER IS FAILING
|
|
</PROGRAMLISTING>
|
|
<para>
|
|
|
|
It is not necessary to prevent the /sbin/mingetty processes from
|
|
migrating - in fact, if you do, all of the child processes started
|
|
from your login shell will be locked, too [Note to German readers:
|
|
This is mistake in the article "Zwischen Multiprocessing und
|
|
Cluster-Computing" on Mosix in "Linux-Magazin" 6/2000].
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
To enable the processes started by your window manager to migrate,
|
|
edit the files ~/.xinitrc and ~/.xsession by going to the end of the
|
|
file and changing the line "exec $WINDOWMANAGER" to
|
|
|
|
|
|
<PROGRAMLISTING>
|
|
exec /bin/mosrun -l $WINDOWMANAGER
|
|
</PROGRAMLISTING>
|
|
|
|
|
|
You should be able to enable migration for all users' window
|
|
mangers by modifying the equivalent line in /etc/X11/xdm/Xsession
|
|
MISSING: NOT TESTED YET. However, see section 8 "Notes" for
|
|
reasons why you might not want to do this by default.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
The command to start and stop Mosix (do not repeat /not/ do this
|
|
now) is
|
|
|
|
|
|
<PROGRAMLISTING>
|
|
/etc/init.d/mosix {start|stop|status|restart|reload}
|
|
</PROGRAMLISTING>
|
|
|
|
|
|
To have Mosix start automatically at boot time, go to /etc/init.d/ .
|
|
In the subdirectories ./rc3.d and ./rc5.d, create the following
|
|
links:
|
|
|
|
|
|
<PROGRAMLISTING>
|
|
ln -s ../mosix S30mosix
|
|
ln -s ../mosix K01mosix
|
|
</PROGRAMLISTING>
|
|
|
|
|
|
The first line causes Mosix to be called as the last part of the
|
|
install procedure for the given run level, the second line closes it
|
|
down as one of the first services.
|
|
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
|
|
Create a file /etc/mosix.map following the instructions in the
|
|
Mosix documentation. In the most simple case, you will have n
|
|
computers which have their IP-addresses in sequence so that the map
|
|
file will simply look like
|
|
|
|
|
|
<PROGRAMLISTING>
|
|
1 IP-address of first node n
|
|
</PROGRAMLISTING>
|
|
|
|
This is where a lot of errors occur, let me clarify this with an example.
|
|
Suppose you have 5 machines, 10.0.0.1, 10.0.0.2 , 10.0.0.100 , 10.0.0.101
|
|
and 10.0.0.150 your mosix.map would look like
|
|
|
|
<PROGRAMLISTING>
|
|
1 10.0.0.1 2
|
|
3 10.0.0.100 2
|
|
5 10.0.0.150 1
|
|
</PROGRAMLISTING>
|
|
|
|
PLEASE VERIFY THIS !!!!!!!
|
|
</para>
|
|
</listitem>
|
|
<listitem><para>
|
|
Run "/etc/versionate", which will most probably tell you that the
|
|
Mosix module already has a version. Do it anyway.
|
|
</para></listitem>
|
|
<listitem><para>
|
|
|
|
Now, finally, reboot. The computer should come up running Mosix.
|
|
|
|
</PARA></listitem></itemizedlist>
|
|
</SECT2>
|
|
</SECT1>
|
|
-->
|
|
<SECT1><TITLE>Debian and openMosix</TITLE>
|
|
<PARA>
|
|
Installing openMosix ``the Debian way'' can be easily done as
|
|
described below.
|
|
</para>
|
|
<para>
|
|
The first step consists in downloading the packages from the net. I
|
|
had to use a 2.4.19 kernel since the openMosix patches package is not
|
|
yet available for 2.4.20 at the moment I write this. Since we are
|
|
using a Debian setup we needed:
|
|
|
|
<ulink
|
|
url="http://packages.debian.org/unstable/net/openmosix.html"><citetitle>http://packages.debian.org/unstable/net/openmosix.html
|
|
</citetitle></ulink>,
|
|
|
|
<ulink
|
|
url="http://packages.debian.org/unstable/net/kernel-patch-openmosix.html"><citetitle>http://packages.debian.org/unstable/net/kernel-patch-openmosix.html
|
|
</citetitle></ulink>,
|
|
|
|
<ulink
|
|
url="http://packages.debian.org/unstable/misc/kernel-package.html"><citetitle>http://packages.debian.org/unstable/misc/kernel-package.html
|
|
</citetitle></ulink>,
|
|
|
|
<ulink
|
|
url="http://packages.debian.org/unstable/devel/kernel-source-2.4.19.html"><citetitle>http://packages.debian.org/unstable/devel/kernel-source-2.4.19.html
|
|
</citetitle></ulink>.
|
|
|
|
You can also apt-get install them ;).
|
|
</para><para>
|
|
|
|
The next part is making the kernel openMosix capable.
|
|
</para><para>
|
|
Basically, the procedure to follow is:
|
|
|
|
<PROGRAMLISTING>
|
|
cd /usr/src
|
|
apt-get install kernel-source-2.4.19 kernel-package \
|
|
openmosix kernel-patch-openmosix
|
|
tar vxjf kernel-source-2.4.19.tar.bz2
|
|
ln -s /usr/src/kernel-source-2.4.19 /usr/src/linux
|
|
cd /usr/src/linux
|
|
../kernel-patches/i386/apply/openmosix
|
|
make menuconfig
|
|
make-kpkg kernel_image modules_image
|
|
cd ..
|
|
dpkg -i kernel-image-*-openmosix-*.deb
|
|
</PROGRAMLISTING>
|
|
|
|
You now will need to edit your /etc/openmosix.map. Please follow the
|
|
instructions given in the ``Syntax of /etc/openmosix.map'' part of
|
|
this HOWTO.
|
|
</para>
|
|
<para>
|
|
After rebooting with this kernel and a configured /etc/openmosix.map,
|
|
you should then have a cluster of openMosix machines that talk to
|
|
each-other and that do migration of processes.
|
|
</para><para>
|
|
|
|
You can test that by running the following small script:
|
|
<PROGRAMLISTING>
|
|
awk 'BEGIN {for(i=0;i<10000;i++)for(j=0;j<10000;j++);}'
|
|
</PROGRAMLISTING>
|
|
a couple of times, and monitor its behaviour with "mosmon" where you
|
|
will see that it spreads the load between the different nodes.
|
|
</para><para>
|
|
We also setup openMosixView on the Debian machine:
|
|
<PROGRAMLISTING>
|
|
apt-get install openmosixview
|
|
</PROGRAMLISTING>
|
|
|
|
In order to be able to actually use openMosixView you will need to run
|
|
it from a user who can log in to the different nodes as root. We
|
|
suggest you set this up using ssh. Please note that there is a
|
|
difference between the ssh and ssh2 implementations. If you do have an
|
|
identity.pub file, ssh will check authorized_keys, while if you do have
|
|
an id_dsa.pub you will need authorized_keys2!
|
|
</para><para>
|
|
|
|
openMosixView gives you a nice interface that shows the load of
|
|
different machines and gives you the possibility to migrate processes
|
|
manually.
|
|
</para><para>
|
|
A detailed discussion of openMosixView can be found elsewhere in this
|
|
document.
|
|
</PARA>
|
|
</SECT1>
|
|
<sect1><title>openMosix and Gentoo</title>
|
|
<para>
|
|
First Install Gentoo Linux
|
|
</para>
|
|
<para>
|
|
Then, install openMosix: type "emerge sys-apps/openmosix-user", which will
|
|
install an openMosix kernel source tree in /usr/src/linux along with the
|
|
openMosix userland tools.
|
|
</para>
|
|
<para>
|
|
Michael Imhof, aka tantive, keeps Gentoo current for the latest openMosix
|
|
version.
|
|
</para>
|
|
<para>
|
|
Daniel Robbins, the President/CEO of Gentoo Technologies, Inc. and the creator
|
|
of Gentoo Linux, wrote the artitles we use as our Introduction to
|
|
openMosix Clusters.
|
|
</para>
|
|
</sect1>
|
|
|
|
<SECT1><TITLE>Other distributions</TITLE>
|
|
<PARA>
|
|
Based on the explanations above you should be able to install openMosix on
|
|
most other Linux platforms.
|
|
</PARA>
|
|
</SECT1>
|
|
|
|
|
|
</CHAPTER>
|
|
|