(Add category and note that it's a draft) |
Mjakubicek (talk | contribs) (added info about BZ#513583) |
||
Line 20: | Line 20: | ||
{{admon/important|Packaging note|When creating RPMs containing module files, be sure to <code>Requires: environment-modules</code> for directory ownership and usability.}} | {{admon/important|Packaging note|When creating RPMs containing module files, be sure to <code>Requires: environment-modules</code> for directory ownership and usability.}} | ||
To create an environment module, place a module file into <code>/etc/modulefiles/</code>. The directory <code>/usr/share/Modules/modulefiles</code> is to be used only for internal modules of environment-modules. | To create an environment module, place a module file into <code>/etc/modulefiles/</code>. The directory <code>/usr/share/Modules/modulefiles</code> is to be used only for internal modules of environment-modules. Besides this, installing a module file into an arbitrary directory currently makes module unloading not working (see [https://bugzilla.redhat.com/show_bug.cgi?id=513583 BZ#513583]) | ||
{{admon/warning|Multilib packages|Suffix the module file name with the architecture to prevent clashes from multilib/multiarch packages.}} | {{admon/warning|Multilib packages|Suffix the module file name with the architecture to prevent clashes from multilib/multiarch packages.}} |
Revision as of 11:48, 24 July 2009
Introduction
When one has multiple programs serving the same purpose (for instance SMTP servers such as sendmail, exim and postfix; or print servers such as lprng and cups), it is usual to wrap these using alternatives. Alternatives provides a clean way to have many types of software serving the same purpose installed at the same time and have the commands such as mail
and lpr
point to the wanted versions.
However, when there are multiple variants that each serve the needs of some user and thus must be available simultaneously by users, the alternatives system simply isn't enough since it is system-wide. This has been reality on supercomputers and clusters for eons, and a solution has been developed: environment modules.
Using environment modules
To see what modules are available, run $ module avail
.
To load a module run e.g. $ module load openmpi-i386
.
To unload a module, run e.g. $module unload openmpi-i386
.
The upstream documentation for the module command is available here.
Creating environment modules
To create an environment module, place a module file into /etc/modulefiles/
. The directory /usr/share/Modules/modulefiles
is to be used only for internal modules of environment-modules. Besides this, installing a module file into an arbitrary directory currently makes module unloading not working (see BZ#513583)
The module files are plain text with a tcl syntax, for instance an environment module for 32-bit OpenMPI openmpi-i386
:
#%Module 1.0 # # OpenMPI module for use with 'environment-modules' package: # prepend-path PATH /usr/lib/openmpi/1.3.3-gcc/bin prepend-path LD_LIBRARY_PATH /usr/lib/openmpi/1.3.3-gcc/lib setenv MPI_BIN /usr/lib/openmpi/1.3.3-gcc/bin setenv MPI_LIB /usr/lib/openmpi/1.3.3-gcc/lib setenv MPI_HOME /usr/lib/openmpi/1.3.3-gcc
The module file begins with the magic cookie #%Module <version>
, where <version>
is the version of the module file used. The current version is 1.0.
The above commands prepends the path with the bindir of the 32-bit OpenMPI 1.3.3 compiled with GCC and adds the relevant library path. Then it sets five environment variables.
It is also possible to set CFLAGS
and LDFLAGS
with the above manner, but in the case of MPI compilers it is not necessary since the compilers are invoked with the mpicc
, mpicxx
, mpif77
and mpif90
wrappers that already contain the necessary include and library paths. Also, in the case of development packages an override of CFLAGS
and/or LDFLAGS
is not sane,
as it may cause trouble in building RPMs as it overrides %{optflags}
.
The upstream documentation for module files is available here.