Modules

Linux computers on the FI network use a system of modules based on Environment Modules and, more recently, also on Lmod to manage installed software. Thanks to this,

it is possible to use the same software across the faculty’s Linux machines,
different versions of the same software can be run side by side,
and students and lecturers can install and make any software available to others (provided, of course, that the licence permits this).

A module is a set of software that logically belongs together. For example, the moduleghc contains, in addition to the compilerghc, the interpreterghci, the documentation generator haddock and the packaging toolcabal.

Usage

Most work with modules is carried out using the command `module`, which has several options. The most important is `add ` for loading modules – programmes within a module are not easily accessible until the module is loaded.

Loading a module:
```
  $ module add ‹name›
```

Listing 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 loaded modules:
```
  $ module list
  Currently Loaded Modulefiles:
          1) modules
```
Themodules module must always be present; if it is not, it must be added in the standard way:module add modules.

I want to add a module

Great! Please proceed as follows:

Is there no older version? Is there no distribution package?

If you wish to create a new version of an existing module, it is a good idea to first contact the maintainer of the current version. This is the owner of the file /packages/run.64/modules/modulefiles/‹pkg›-‹current version›.

It is also a good idea to check whether the software in question (in a version that suits your needs) is available in a distribution package. If so, simply write to unixJliEPq0HO@fivLbKmOyL2.munic7IRbGg1m.cz , and if there are no issues, we will install it.
Set up the module using the application in the Faculty Administration system.

Enter the name and version of the software package. We will refer to them hereafter as‹pkg› and‹version›.

When the module is created, an empty module framework will be generated:
- /packages/run.64/‹pkg›-‹version›/ (this is where it will be installed)
- /packages/run.64/modules/modulefiles/‹pkg›-version› (module configuration)
(In reality, there is more to it; those interested should refer to the advanced section below.)
Install the software into/packages/run.64/‹pkg›-‹version›/.

This varies depending on the software; typically, it involves setting a prefix during configuration, compilation and/or installation to this directory. Look for options such as--prefix,CMAKE_INSTALL_PREFIX, etc.

Carry out the installation on one of the following computers:

aisa, anxur, aura, arachne, nymfe001,

specifically on the machine where you plan to use the module (otherwise you may encounter problems such as issues with system library versions). If the programme does not have a graphical user interface, it is safer to install it on Aisa or Aura – the programme will then usually be able to run on graphical workstations as well. In particular, if you are compiling using thegcc orllvm modules, binaries built on Aisa will probably run on Nymfe machines, but certainly not the other way round.
Configure the module using the file/packages/run.64/modules/modulefiles/‹pkg›-‹version›.

You will need to find out exactly where the executables have been installed and add this path to thePATH environment variable in the configuration file. It is also good practice to make the manual pages available.

Here is a brief example from the `ghc-8.10.2` 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 variables such as `LD_LIBRARY_PATH ` or other environment variables. Here you can also configure the module’s dependencies on other modules or resolve conflicts with other modules. Details can be found in a separate section below and atman 4 modulefile.
Test that it works.
```
 $ module add ‹pkg›-‹version›
```
and check that everything is working as it should.
Please contact us regarding the default version.

All modules must have a version number specified. A package name without a version is simply a shorthand for a default version. If you want your module to be loaded using a shorter command
```
 $ module add ‹pkg›
```
you need to mark your module version as the default. Whilst you cannot do this yourself, you can write to us at or.

More advanced module configuration

Apart fromprepend-path VARIABLE VALUE, a module can modify environment variables in other ways:

prepend-path VARIABLE VALUE – adding a value and a colon at the start
append-path VARIABLE VALUE – adding a colon and a value at the end
setenv VARIABLE VALUE – overwriting the variable with a value
unsetenv VARIABLE VALUE – removing a variable

It is also possible to set dependencies and conflict modules. If your module needs to utilise other modules, always state this explicitly in the configuration. Otherwise, we may eventually classify a required module as unused and delete it.

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

Finally, it is possible to link modules directly or perform other operations using the `module` command.

module   COMMAND [ARGUMENT]

If you need to write a short help message for a module, you can enter it in the `/packages/run/modules/helpfiles/‹pkg›-‹version›` file. It will then be displayed using the command `modulehelp ‹pkg›-‹version›`.

Further information can be found in the man pages for `module(1) ` and `modulefile(4)`.

How does it all work?

The modules are available on all Linux computers in the directory/packages. In addition to the subdirectoryrun.64, there is alsorun containing the old 32-bit modules. You may also find the subdirectoryshare of interest; this is where platform-independent files are stored (i.e. what is usually found in/usr/share). The idea is that the directory/packages/run.64 is shared amongst computers with the same platform, whilst/packages/share is shared amongst all computers.

AsLinux-amd64 is currently the only platform at FI that supports modules, there is no need to useshare, and you can place the entire installation inrun.64 (where, in a multi-platform design, only binaries, libraries, etc. would be located).

It is probably clear from the installation description that the whole trick to adding modules is actually simply adding paths toPATH (or other variables).

For this to work, the command `module ` must be a shell function, not an executable programme. (This function does not appear in the shell by itself; it is defined by the file /etc/profile.d/modules.sh.) Consequently, whilst you can use the commandmodule in shell scripts (typically, for example, in~/.bashrc), you cannot use it in other programmes. On the other hand, there is nothing to stop you from accessing binaries directly via the absolute path/packages/run.64/‹pkg›-‹version›/.... However, this carries a risk with long-term use. Unlikemodule add, we can only detect this method of use on servers (Aisa, Anxur, Aura), not on . It is therefore advisable to always add modules used solely on stations via module add, so that we do not eventually classify them as unused and remove them. The same applies to modules with libraries, etc. – for the time being, we only detect the execution of binaries.

The existence of a module is ‘triggered’ by the existence of a correctly formatted configuration file in/packages/run.64/modules/modulefiles/. The default version of the module (the one without an explicit version number) therefore also has its own configuration file in the directorymodulefiles – but in reality, it is merely a symbolic link to the file for a specific version. The default versions of modules can thus be determined using the command `readlink ` (or, for example, by listing the directory `modulefiles ` using `ls -l`).

Local modules on student workstations

On Nymfe workstations, you may also come across modules ending in-loc. These are the same modules as their versions without-loc, but they are located on the local disk of the Nymfe workstations. Local modules are created only by unix@fi for large modules, both to speed them up and to limit network traffic.