|
From: Xavier D. <xav...@gm...> - 2022-06-02 18:40:52
|
Hi All, For the environment initialization, I would like to also suggest to look at module collections [1] as an alternative to the init* commands. New version of the default initrc configuration file highlights a way to restore default collection of user when their session initializes [2]. Combined with the collection_target [3] configuration option, it is possible to have different set of collections for each defined target. And it is up to you to define this target, based on how the environment you provide has to be split (by os id name and version, by dns domain, etc). Regards, Xavier [1] https://modules.readthedocs.io/en/latest/module.html#collections-1 [2] https://modules.readthedocs.io/en/latest/INSTALL.html#configuration [3] https://modules.readthedocs.io/en/latest/module.html#mconfig-collection_target Le jeu. 2 juin 2022 à 19:52, Jason Edgecombe <jwe...@un...> a écrit : > Hi Erik, > > Thanks to everyone for the excellent suggestions! I'm going to look at > using your and Pierre's suggestion of handling the $DISTRO in the module > files. I plan to keep the modules as close as possible between each distro. > > Thanks, > Jason > > --------------------------------------------------------------------------- > Jason Edgecombe | Linux Administrator > UNC Charlotte | Office of OneIT > 9201 University City Blvd. | Charlotte, NC 28223-0001 > Phone: 704-687-1943 > jwe...@un... | oneit.charlotte.edu > > --------------------------------------------------------------------------- > If you are not the intended recipient of this transmission or a person > responsible for delivering it to the intended recipient, any disclosure, > copying, distribution, or other use of any of the information in this > transmission is strictly prohibited. If you have received this transmission > in error, please notify me immediately by reply e-mail or by telephone at > 704-687-1943. Thank you. > > > On Thu, Jun 2, 2022 at 1:36 PM Erik Parawell <eri...@si...> > wrote: > >> Hi, >> >> I had the same issue. This is how we resolved it: >> We have a file called os_detect.tcl in the root of our modules folder. >> >> https://gist.github.com/ErikParawell-SiFive/fac611a6fa8acb4868f9da420c3c43a5 >> And this is what our module file looks like: >> >> https://gist.github.com/ErikParawell-SiFive/020b0d8774d49b5d2164ec141234bbe5 >> >> >> >> >> On Jun 2, 2022, at 11:47 AM, Paul Markfort <pau...@gm...> wrote: >> >> Note. >> >> The module initadd script modifies the module load command in the user's >> shell initialization scripts. >> So, different locations for those files is what you need (hence the >> suggestion of different home directories). >> >> Alternatively, users can learn to modify their own init scripts >> (including adding in code to make decisions based on OS). >> >> From the man module page: >> >> initadd modulefile... >> Add modulefile to the shell's initialization file in the >> user's >> home directory. The startup files checked (in order) are: >> >> C Shell >> .modules, .cshrc, .csh_variables and .login >> >> TENEX C Shell >> .modules, .tcshrc, .cshrc, .csh_variables and .login >> >> Bourne and Korn Shells >> .modules, .profile >> >> GNU Bourne Again Shell >> .modules, .bash_profile, .bash_login, .profile and .bashrc >> >> Z Shell >> .modules, .zshrc, .zshenv and .zlogin >> >> Friendly Interactive Shell >> .modules, .config/fish/config.fish >> >> If a module load line is found in any of these files, the >> mod- >> ulefiles are appended to any existing list of modulefiles. >> The >> module load line must be located in at least one of the >> files >> listed above for any of the init sub-commands to work >> properly. >> If the module load line is found in multiple shell >> initializa- >> tion files, all of the lines are changed. >> >> >> Note, the man page does not specify how the .modules file is used (I >> suspect it is specifically used by the module command - not by the shell, >> but when I am not sure). >> The libexec/modulecmd.tcl file doesn't seem to directly use it (only >> modifies it, if there). >> >> >> On 2022-06-02 10:09 AM, Pierre Girard wrote: >> >> De : Jason Edgecombe <jwe...@un...> >> I just realized that I didn't explain my problem very well. I'm looking >> for how to split each user's automatically-loaded modules for each OS. In >> other words, if I run "module initadd foo" on Ubuntu then the foo module >> will be automatically loaded on Ubuntu, but not RHEL. >> So if I understand correctly, you have 2 sets of modules that differ >> depending on the OS. So having module load foo in the configuration file >> would work on ubuntu and an error on RHEL or something along those lines. >> Maybe write the module itself so it adjusts to the platform you’re on? >> Something like this: >> switch $env(DISTRO) { >> ubuntu { >> # do something >> } >> rhel { >> # do something else >> } >> default { >> # unknown system >> } >> } >> On Thu, Jun 2, 2022 at 10:18 AM Pierre Girard <pie...@ge...< >> mailto:pie...@ge... <pie...@ge...>>> wrote: >> [Caution: Email from External Sender. Do not click or open links or >> attachments unless you know this sender.] >> De : Jason Edgecombe <jwe...@un...<mailto:jwe...@un... >> <jwe...@un...>>> >> Envoyé : 2 juin 2022 09:34 >> À : mod...@li...< >> mailto:mod...@li... >> <mod...@li...>> >> Objet : [Modules] modules on different Linux distros with shared NFS home >> directories >> I want to start using modules in our Linux environment. I support both >> RHEL and Ubuntu machines that use the same shared NFS path for each user's >> home directory. Is there a way for me to override the ~/.modules path to >> make it something like ~/.modules-$DISTRO ? I would prefer to not modify >> the core modulecmd.tcl file. I tried using trace commands in my site >> config, but I can't seem to trace the cmdModuleInit procedure to override >> things. >> You should be able to change MODULEPATH environment variable. >> export MODULEPATH=~/modulefiles:/home/modules/modulefiles-$DISTRO >> _______________________________________________ >> Modules-interest mailing list >> Mod...@li...< >> mailto:Mod...@li... >> <Mod...@li...>> >> https://lists.sourceforge.net/lists/listinfo/modules-interest >> _______________________________________________ >> Modules-interest mailing list >> Mod...@li... >> https://lists.sourceforge.net/lists/listinfo/modules-interest >> >> >> -- >> -------------------------------------------------------- >> The views and opinions expressed above are strictly >> those of the author(s). The content of this message has >> not been reviewed nor approved by any entity whatsoever. >> -------------------------------------------------------- >> Paul FM Info: http://paulfm.com/~paulfm/ >> -------------------------------------------------------- >> >> >> _______________________________________________ >> Modules-interest mailing list >> Mod...@li... >> https://lists.sourceforge.net/lists/listinfo/modules-interest >> >> >> _______________________________________________ >> Modules-interest mailing list >> Mod...@li... >> https://lists.sourceforge.net/lists/listinfo/modules-interest >> > _______________________________________________ > Modules-interest mailing list > Mod...@li... > https://lists.sourceforge.net/lists/listinfo/modules-interest > |
