translated by Google

Machine-translated page for increased accessibility for English questioners.


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


Most of the work with modules is mediated by the command module which has several commands. The most important thing is add for connecting modules - programs in the module are not easily accessible until we connect the module.

  • Module connection:

    $ 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

    Module modules must 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:

  1. 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 /packages/run.64/modules/modulefiles/‹pkg›-‹current version› .

  2. Create the module with application in the Faculty Administration .

    Enter the name and version of the software package. We will label them below ‹pkg› and ‹version› .

    When created, an empty module skeleton is created:

    • /packages/run.64/‹pkg›-‹version›/ (will be installed here)
    • /packages/run.64/modules/modulefiles/‹pkg›-version› (module configuration)

    (In fact, there is more; if you are interested, please refer to the advanced section below.)

  3. Install the software in /packages/run.64/‹pkg›-‹version›/ .

    This varies by software; typically it consists of setting a prefix when configuring, building and / or installing to this directory. Look for a choice --prefix , CMAKE_INSTALL_PREFIX apod.

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

  4. Set the module with a file /packages/run.64/modules/modulefiles/‹pkg›-‹version› .

    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 ghc-8.10.2 :

    #! 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_PATH or 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 .

  5. Test the functionality.

    $ module add ‹pkg›-‹version›

    and verify that everything works as it should.

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

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

conflict MODULE [MODULE ...]
prereq   MODULE [MODULE ...]

Finally, modules can be connected directly or other command operations can be performed module .


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 module(1) and modulefile(4) .

How does it all work?

The modules are available in the directory on all Linux computers /packages . Except for the subdirectory run.64 there may 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 would only include binaries, libraries, etc. in the multiplatform design).

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 module 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/ .) 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 /packages/run.64/‹pkg›-‹version›/... . However, this carries a risk with long-term use. Unlike module add we cannot detect this method of use yet, so over time we can evaluate the module as unused and remove it. It is therefore advisable to add the module via module add .

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 modulefiles help ls -l ).