Forked from
emulab / emulab-devel
Source project has a limited visibility.
-
Mike Hibler authored
Two-day boondoggle to support "/scratch", an optional large, shared filesystem for users. To do this, I needed to find all the instances where /proj is used and behave accordingly. The boondoggle part was the decision to gather up all the hardwired instances of shared directory names ("/proj", "/users", etc.) so that they are set in a common place (via unexposed configure variables). This is a boondoggle because: 1. I didn't change the client-side scripts. They need a different mechanism (e.g., tmcd) to get the info, configure is the wrong way. 2. Even if I had done #1 it is likely--no, certain--that something would fail if you tried to rename "/proj" to be "/mike". These names are just too ingrained. 3. We may not even use "/scratch" as it turns out. Note, I also didn't fix any of the .html documentation. Anyway, it is done. To maintain my illusion in the future you should: 1. Have perl scripts include "use libtestbed" and use the defined PROJROOT(), et.al. functions where possible. If not possible, make sure they run through configure and use @PROJROOT_DIR@, etc. 2. Use the configure method for python, C, php and other languages. 3. There are perl (TBValidUserDir) and php (VALIDUSERPATH) functions which you should call to determine if an NS, template parameter, tarball or other file are in "an acceptable location." Use these functions where possible. They know about the optional "scratch" filesystem. Note that the perl function is over-engineered to handles cases that don't occur in nature.
Mike Hibler authoredTwo-day boondoggle to support "/scratch", an optional large, shared filesystem for users. To do this, I needed to find all the instances where /proj is used and behave accordingly. The boondoggle part was the decision to gather up all the hardwired instances of shared directory names ("/proj", "/users", etc.) so that they are set in a common place (via unexposed configure variables). This is a boondoggle because: 1. I didn't change the client-side scripts. They need a different mechanism (e.g., tmcd) to get the info, configure is the wrong way. 2. Even if I had done #1 it is likely--no, certain--that something would fail if you tried to rename "/proj" to be "/mike". These names are just too ingrained. 3. We may not even use "/scratch" as it turns out. Note, I also didn't fix any of the .html documentation. Anyway, it is done. To maintain my illusion in the future you should: 1. Have perl scripts include "use libtestbed" and use the defined PROJROOT(), et.al. functions where possible. If not possible, make sure they run through configure and use @PROJROOT_DIR@, etc. 2. Use the configure method for python, C, php and other languages. 3. There are perl (TBValidUserDir) and php (VALIDUSERPATH) functions which you should call to determine if an NS, template parameter, tarball or other file are in "an acceptable location." Use these functions where possible. They know about the optional "scratch" filesystem. Note that the perl function is over-engineered to handles cases that don't occur in nature.