Umgebungsmodule

Wenn mehrere Programme denselben Zweck erfüllen (zum Beispiel SMTP-Server wie sendmail, exim und postfix oder Druckserver wie lprng und cups), werden diese üblicherweise mit Alternativen gekapselt. Alternativen ermöglichen es, viele Softwaretypen mit demselben Zweck gleichzeitig zu installieren und Befehle wie mail und lpr auf die gewünschten Versionen verweisen zu lassen.

Wenn jedoch mehrere Varianten existieren, die jeweils den Bedürfnissen eines Benutzers dienen und daher gleichzeitig verfügbar sein müssen, reicht das Alternativen-System aufgrund seiner systemweiten Ausrichtung nicht aus. Dies ist auf Supercomputern und Clustern seit Langem Realität, und es wurden mehrere Lösungsansätze entwickelt: Umgebungsmodule und Lmod. Fedora nutzt dies aktuell hauptsächlich für den Wechsel zwischen verschiedenen MPI-Implementierungen.

Umgebungsmodule sind auch dann nützlich, wenn ein Paket Binärdateien installieren möchte, die häufig verwendete Namen haben und möglicherweise mit Dateien in /usr/bin in Konflikt geraten oder diese anderweitig beeinträchtigen. Der Benutzer muss dann ein Umgebungsmodul laden, bevor er diese Programme verwenden kann.

Um die verfügbaren Module anzuzeigen, führen Sie $ module avail aus. Um ein Modul zu laden, führen Sie beispielsweise $ module load mpi/openmpi-x86_64 aus. Um ein Modul zu entladen, führen Sie beispielsweise $ module unload mpi/openmpi-x86_64 aus.

Die Upstream-Dokumentation für den Befehl „module“ ist hier oder mit man module verfügbar.

Um ein Umgebungsmodul zu installieren, legen Sie eine Moduldatei in %{_modulesdir} an, was zu /usr/share/modulefiles aufgelöst werden sollte. Dieses Makro ist in Fedora und EPEL 7+ verfügbar. Das Verzeichnis /usr/share/Modules/modulefiles ist ausschließlich für interne Module von Umgebungsmodulen vorgesehen. /etc/modulefiles steht lokalen Systemadministratoren zur Verfügung.

Die Moduldateien sind Klartext mit optionaler Tcl-Syntax, zum Beispiel ein Umgebungsmodul für 64-Bit OpenMPI mpi/openmpi-x86_64:

Die Moduldatei beginnt mit dem magischen Cookie +#%Module +, was die Version der verwendeten Moduldatei angibt. Die aktuelle Version ist 1.0.

Die obigen Befehle stellen dem Pfad das Binärdateiverzeichnis des 64-Bit-OpenMPI (kompiliert mit GCC) voran und ergänzen den Pfad zur entsprechenden Bibliothek. Anschließend werden verschiedene Umgebungsvariablen gesetzt.

Es ist zwar auch möglich, CFLAGS und LDFLAGS auf die oben beschriebene Weise zu setzen, aber bei MPI-Compilern ist dies nicht notwendig, da diese mit den Wrappern mpicc, mpicxx, mpif77 und mpif90 aufgerufen werden, die bereits die erforderlichen Include- und Bibliothekspfade enthalten. Auch bei Entwicklungspaketen ist das Außerkraftsetzen von CFLAGS und/oder LDFLAGS nicht sinnvoll, da dies zu Problemen beim Erstellen von RPMs führen kann, da dadurch %{optflags} außer Kraft gesetzt wird.

Die Upstream-Dokumentation für Moduldateien ist hier oder mit man modulefile verfügbar.

Der Wechsel zwischen den Implementierungen von Umgebungsmodulen und Lmod erfolgt über Alternativen. Die Shell-Init-Skripte /etc/profile.d/modules.\{csh,sh} sind Verknüpfungen zu /etc/alternatives/modules.\{csh.sh} und können mit dem „alternatives“-Befehl manipuliert werden.

Lmod ist eine in Lua geschriebene Implementierung von Umgebungsmodulen und kann sowohl in Lua als auch in Tcl geschriebene Moduldateien verwenden. Diese Dateien haben die Dateiendung „.lua“. Sie dürfen jedoch nicht in /usr/share/modulefiles installiert werden, um Probleme bei der Verwendung des Pakets environment-modules zu vermeiden. Installieren Sie sie stattdessen in %{_datadir}/lmod/lmod/modulefiles/Core.