From 5ca6ccb09fe3a0ff17fbdcd7ecc30f34e7cc0170 Mon Sep 17 00:00:00 2001 From: Kent Mein Date: Sat, 19 Oct 2013 10:30:36 -0500 Subject: [PATCH] Some small tweaks to example setup documentation. --- doc/example.txt | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/doc/example.txt b/doc/example.txt index ba87cd9b..2ff288d8 100644 --- a/doc/example.txt +++ b/doc/example.txt @@ -5,7 +5,7 @@ This document will explain how we have things setup at the University of Minnesota's Computer Science Department, where we have 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 interdependant. How +environment. Note many of these things are interdependent. How you setup your template user (Section 1) will depend on your Layout (Section 05). @@ -37,7 +37,7 @@ 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 starting point. In modules/contrib/scripts/ +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. @@ -63,10 +63,10 @@ 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 +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 absolutly needed. If your setting it +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. @@ -79,11 +79,11 @@ 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 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 have. After -thats done you can copy the new module over to the systemwide modulefiles -directory. +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 @@ -96,16 +96,16 @@ 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. +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. +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 seperate install of modules that I can use to +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. @@ -118,11 +118,11 @@ 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 initalize your modules environment. +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 compaire the results. I usually leave my account on the PERSONAL +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.