|
Server : Apache System : Linux srv.rainic.com 4.18.0-553.47.1.el8_10.x86_64 #1 SMP Wed Apr 2 05:45:37 EDT 2025 x86_64 User : rainic ( 1014) PHP Version : 7.4.33 Disable Function : exec,passthru,shell_exec,system Directory : /usr/share/doc/environment-modules/ |
Upload File : |
Creating a user environment using Modules ========================================= There are lots of extra things to think about and setup when creating a successful environment using modules, besides just installing the software. This document will explain how we have things setup at the University of Minnesota's Computer Science Department, where we have been using modules for over 20 years. It may not be the best setup but it will give you an idea of what you need to think about when creating your environment. Note many of these things are interdependent. How you setup your template user (Section 1) will depend on your Layout (Section 05). Topics covered in this document: 01. Template User 02. Resetenv 03. Sample modulefiles (our default modules) 04. Creating and testing new modules 05. Layout: Distributing Modules/Revision control 06. Testing new version of modules command 07. Retiring old modules 01. Template User ----------------- We have a default user "template" that has all of the current defaults for new users. So if people need a copy of the defaults they can just look at ~template to get a copy of them. A slightly simplified version of our template user is in modules/contrib/template When we create a new user on our systems they get ~template copied over to their home directory, so they have the standard configuration files. Part of creating ~template is deciding what modules to load by default for the average user. You want to only load the modules that everyone is going to use, but at the same time, if you can please 80-90% of your users with the defaults, then they will not need to make many changes to their account. It's a balancing act that you will have to learn over time. 02. Resetenv ------------ Users will eventually mess up their environment. It's good to have a way to get back to a known good starting point. In modules/contrib/scripts/ we have a script we use "resetenv" which will allow users to backup their current '.*' files and then copy over the defaults from ~template. So that they can hopefully get back to a known working state. We also have provided another script resetgnome which will clear out a users config files for gnome and reset them to our default new user. 03. Sample modulefiles (our default modules) -------------------------------------------- The modules provided in modules/modulefiles are very bare bones and just show you the basics. You can find all of our default modules that are loaded by our template user in modules/contrib/modulefiles 04. Creating and testing new modules ------------------------------------ In general your modules should be as simple as possible. In theory all modules should just be adding a path to your environment and maybe a couple of other things. A great example is modules/contrib/modulefiles/perl/5.14.1 Lots of times you need more complicated logic. Something like: modules/contrib/modulefiles/soft/gcc/4.7.2 If you need to do something like this, its important that you various platforms into groups. In general we break things down first by OS, then by arch, and then sysname if needed. When adding a path to an environment variable use append-path only use prepend-path when absolutely needed. If all of your modules work the same way it will be much easier for users to figure things out. On our Linux systems we use prepend-path for the gcc module so that we can override the system default version of gcc, otherwise we would use append-path. Avoid setting LD_LIBRARY_PATH unless absolutely needed. If your setting it you'll probably wind up with problems in the future. First setup a user modules directory, mkdir ~/.modules for example. In your .cshrc or .bashrc file after your source your modules init file add the following line to start using your local directory: module use ~/.modules It's a good idea to make a subdirectory for your module and use a .version file, just like we did for the above two. In general as time moves on you will have different versions of the software and if you name them you will be able to retire old versions without bothering the users. The best way to create a new module, is to use one of your existing modules and modify it to work for your new needs. Once you have your module created it's important to test it on all of the distinct types of platforms you want the module to function on. After thats done, you can copy the new module over to the system wide modulefiles directory. 05. Distributing Modules/Revision control ----------------------------------------- We use the following setup: GLOBALMODULESINSTALL /soft/rko-modules/tcl GLOBALMODULEFILES /soft/rko-modules/modulefiles PERSONALMODULEFILES ~/.modules PERSONALMODULESINSTALL ~/modules REPOSOFMODULEFILES /project/rdist/conf/opt/modules/modulefiles GLOBALMODULESINSTALL is where we have modules installed. This is the live site for all of our users so we are very careful about making changes to this directory. This directory is NFS shared to all of our client machines. GLOBALMODULEFILES is where we have our live modules that the users use. Again we are very careful about applying changes to this directory, and it is NFS shared to all of our clients. PERSONALMODULEFILES is where I store modules I am working on or testing. That way I can play with them and know that I'm not affecting users. PERSONALMODULESINSTALL is a separate install of modules that I can use to test the latest version of modules and make sure things are working before upgrading our GLOBALMODULESINSTALL. REPOSOFMODULEFILES is a git controlled directory that contains all of our modulefiles. When we are done testing a new module we check it in to the repository and update it here. Then it gets pushed to all of our clients through rsync. 06. Testing a new version of modules command -------------------------------------------- If you use a scheme similar to the above testing a new version of modules is really easy. All you need to do is edit your .cshrc or .bashrc or whatever other file your using to initialize your modules environment. and point it at PERSONALMODULESINSTALL instead of GLOBALMODULESINSTALL. In general what I do is do a "make test" with the global setup and then switch things to my PERSONALMODULESINSTALL and rerun the "make test" and compare the results. I usually leave my account on the PERSONAL version for a week or to to make sure there aren't any hidden bugs. Once the week is up, if there are no problems, I update the GLOBAL version. 07. Retiring old modules ------------------------ After you have been using modules for awhile your going to get some modules that are no longer valid. An example would be we have installed a new version of perl and we are getting rid of one of the really old versions. For this example, I'm going to pretend we are getting rid of the "perl/5.8" module. At this point in time perl/5.8 is no longer the default version of the perl module and very few users are hopefully using it. The way that we retire an old module file is we add lines that print a warning to all users still using the module: puts stderr "The perl/5.8 module is outdated and will be going away" puts stderr "please update your . files to use the perl module instead. " We push this out to all of the systems after we have tested it. Then we wait a month to see if any of our users complain or have an issue with the problem. If there are no complaints then we remove the module and make sure it's removed on all of the systems.