<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>

