Linux computers on the FI network use a system of modules to manage the installed software. Thanks to him
- the same software can be used across faculty Linux machines,
- different versions of the same software can be run side by side,
- students and teachers can install and make available to others any software (of course only if its license allows it).
A module is a set of software that logically belongs together. For example, a module
ghc contains in addition to the compiler
ghc also an interpreter
ghci , documentation generator
haddock and a packaging tool
Most of the work with modules is mediated by the command
module which has several commands. The most important thing is
connecting modules - programs in the module are not easily accessible until we connect the module.
$ module add ‹name›
Listing of available modules:
$ module avail -------- /packages/run/modules-3.1.6/modulefiles -------- binhex gnuplot modules tcl-tk devel info-services plan texlive eclipse maple snns viewers
List of currently connected modules:
$ module list Currently Loaded Modulefiles: 1) modules
modulesmust always be present; if not, you need to add it in the standard way:
module add modules.
I want to add a module
Great! Proceed as follows:
Isn't there an older version?
If you want to create a new version of an existing module, it is a good idea to contact the administrator of the current version first. He is the owner of the file
Create the module with application in the Faculty Administration .
Enter the name and version of the software package. We will label them below
When created, an empty module skeleton is created:
/packages/run.64/‹pkg›-‹version›/(will be installed here)
(In fact, there is more; interested parties are referred to the advanced section below.)
Install the software in
This varies by software; typically it consists of setting a prefix when configuring, building and / or installing to this directory. Look for a choice
Install on one of the following computers:
aisa , anxur , aura , nymfe01 ,
where you plan to use the module (otherwise you may encounter problems with versions of system libraries, for example).
Set the module with a file
You will need to find out exactly where the executable files were installed and add this path to the environment variable in the configuration file
PATH. It is also polite to make manual pages accessible.
Here is a short example from the module
#%Module1.0 #! #! Title: ghc #! Version: 8.10.2 #! Description: The Glasgow Haskell Compiler prepend-path PATH /packages/run.64/ghc-8.10.2/bin prepend-path MANPATH /packages/run.64/ghc-8.10.2/share/man
Similarly, you may need to set up
LD_LIBRARY_PATHor other environment variables. Here you can also set module dependencies on other modules or conflicts with other modules. Details can be found in a separate section below and in
man 4 modulefile.
Test the functionality.
$ module add ‹pkg›-‹version›
and verify that everything works as it should.
Contact us about the default version.
All modules must have a version number. A package name without a version is just an abbreviation for some default version. If you want your module to be connected with a shorter command
$ module add ‹pkg›
you need to mark your version of the module as default. You can't do this yourself, but you can write to us at
Advanced module configuration
prepend-path VARIABLE VALUE the module can change environment variables in other ways:
prepend-path VARIABLE VALUE- add a value and a colon to the beginning
append-path VARIABLE VALUE- adding a colon and a value to the end
setenv VARIABLE VALUE- overwriting a variable with a value
unsetenv VARIABLE VALUE- cancellation of a variable
It is also possible to set dependencies and conflicting modules. If your module needs to use other modules, always state this explicitly in the configuration. Otherwise, we can eventually evaluate any necessary module as unused and delete it.
conflict MODULE [MODULE ...] prereq MODULE [MODULE ...]
Finally, modules can be connected directly or other command operations can be performed
module COMMAND [ARGUMENT]
If you need to write a short help for the module, you can write it to a file
/packages/run/modules/helpfiles/‹pkg›-‹version› . It will then be viewable by the command
modulehelp ‹pkg›-‹version› .
See the man pages for more information
How does it all work?
The modules are available in the directory on all Linux computers
/packages . Except for the subdirectory
run.64 is here
run with old 32-bit modules. There may still be an interesting subdirectory
share , in which platform - independent files are placed (that is, what is usually in
/usr/share ). The idea is that the directory
/packages/run.64 is shared between computers with the same platform and
/packages/share among all computers.
As it is currently the only module endowed with an FI platform
Linux-amd64 , not necessary
share use and you can place the whole installation in
run.64 (which in a multiplatform design would include only binaries, libraries, etc.).
From the description of the installation, it is probably clear that the whole magic of adding modules is actually just adding paths to
PATH (or other variables).
There must be a command for this to work
shell functions , not an executable program. (This function does not appear in the shell by itself; it is loaded by the file
/etc/profile.d/modules.sh .) As a result, you can command
module use in shell scripts (typically eg in
~/.bashrc ), but not in other programs. On the other hand, nothing prevents you from accessing binaries directly in an absolute way
However, this carries a risk with long-term use. Unlike
module add we can detect this method of use only on servers (Aisa, Anxur, Aura), not on Nymfe stations. Modules used only on Nymphs should therefore always be added via
module add so that we do not evaluate them as unused over time and do not remove them. The same applies to modules with libraries, etc. - so far we only detect the start of the binary.
The existence of the module is "caused" by the existence of a properly formatted configuration file in
/packages/run.64/modules/modulefiles/ . The default version of the module (the one without an explicit version number) is in the directory
modulefiles also its configuration file - but in reality it is only a symbolic link to a specific version file. The default versions of the modules can be found by the command
readlink (or perhaps by listing the directory
ls -l ).