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, the module ghc contains in addition to the compiler ghc also an interpreter ghci , documentation generator haddock and a packaging tool cabal .


The command mediates most of the work with modules 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! Follow these steps:

  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 a 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; we refer you 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. See the separate section below and in for details man 4 modulefile .

  5. Test the functionality.

     $ module add ‹pkg›-‹version›

    and make sure 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 module version as default. You can't do that 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 - adding 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 may 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 .


If you need to write some 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 . In addition to the subdirectory run.64 is here run with old 32-bit modules. It 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 on the same platform and /packages/share among all computers.

As it is currently the only module endowed with a platform on FI Linux-amd64 , not necessary share use and you can place the whole installation in run.64 (where only binaries, libraries, etc. would fall 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 can detect this method of use only on servers (Aisa, Anxur, Aura), not on Nymph 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 modulefiles help ls -l ).

Local modules on Nymph stations

At Nymph stations you can also find modules ending in -loc . These are the same modules as their non-versions -loc , are only located on the local disk of Nymph stations. Local modules only create unix @ fi for large modules, both to speed them up and to limit network traffic.