Installing Software for Consultants
The Computer Science department has specific regulations for installed software that are site-specific. Even if you are experienced at installing software on UNIX systems, please read this guide as there are a few points to group administered systems and Turing in particular that you must know before you can install software.
- First, ensure the software you plan to install is not already loaded on the system. There are several search tools available to find binaries on the system. Read manual pages for whereis(1B), slocate(1), find(1) (which should generally not be used for global system searches), and which(1) for a few methods if you are unsure how to search on the system. Most applications on Turing are installed under /usr/local/bin to prevent data loss if the system is rebuilt. Some applications installed in special directories may not start when you type their name at the system prompt; check your PATH environment variable or use the full pathname to the binary.
- Once you are satisfied that the software is definitely not on Turing, create a request. Make sure to search request before you create a new request; the application you want may have been requested in the past, and is either currently being installed or was rejected for various reasons. Request is documented in a qref, and minimal help available by running %request -h. Search the requests using the -f and -F options as documented elsewhere. If you find any relevant requests, use those. Make sure you update it with your intentions so that everyone knows what you are doing.
If there aren't any relevant requests in the database, create one. All work on Turing must be documented in the request database. Coordination between a large staff, faculty, and consultants is impossible if request is not used.
- Now that the general administration is done, you need to download the source for the package. The source code is generally available from the main program web site. If you don't know where that is, use your favorite search engine. Make sure to download an up-to-date and stable release of the software. If there is an earlier version of the program on Turing
- Extract the package into /proj/{your user name}/{source package name}. This can usually be done with %tar -xvzf {source package name}. Some packages might come compressed differently; experiment to find the correct method.
- Create a README.MUDD document in the newly extracted package directory. This will be a repository for all of the necessary steps required to build the package and is the recipe that other people will use in the future if they need to construct a modern version. A template is available in /staff/MUDD_README_template.txt. Make sure to enter all information as you experiment with the package. Note that any non standard configuration necessary or patches should be mentioned in the "Additional Notes" section and accompanying patch files should be provided (with a .MUDD suffix).
- Read the documentation that came with the software. The main installation information can usually be found in the INSTALL and README files in the package directory. Make sure to read them completely, as there might be important notes at the bottom of the file.
- Create a test environment. Because you are not running as root and we do not want untested software available for general consumption, the software must be installed into a special directory in your proj directory where it can be tested before it is installed in the system. Create a directory off of your project directory just for this specific purpose; make sure to note the name so that staff can run the program before installing it system-wide.
- Compile the software. The correct method should be explained in the documentation; if it is not mentioned, the standard way to compile software on UNIX is the %./configure, %make, %make install sequence. Make sure that when you configure the software the prefix is set up to install the software into the test environment; the actual mechanics will depend on how the configuration is handled. Make sure to read the documentation for their recommendations.
- Test the software. Run the program, try to break them. Try and figure out what environment variables are needed to have the programs execute, and be sure to mention them in the additional notes section of the README.MUDD document. You can remove write privileges from the environment by changing to the test directory and running $chmod -R a-w.
- Adjust the software to install into /usr/local. This can be done by rebuilding the package with the --prefix=/usr/local option or by editing Makefile in the package source directory so that when the install script is run the files are copied into the /usr/local directory tree. Check to make sure that the installation works correctly by running $make -n install. The -n command line switch prints the installation commands but does not copy any files. The installation should only copy files into the /usr/local tree or those extra files will be lost if turing is rebuilt. Make sure that the installation obeys the prefix completely.
- Make the software world readable. Staff will not install software if you do not make the files world readable, or at least accessible to the operator group. To ensure that all of the files in a directory are world-accessible, change to the directory and execute %chmod -R o+r,o-w followed by %chmod o+x `find . -perm -100 -print`. Similar commands can restrict access to the operator group; see chown(1).
- Update the request. Make sure to specify where the example is built and where staff can find the README.MUDD with your specific changes. Check once more that all of the files relevant to the package (not just the test environment) are readable. Although staff has access to root, they will not use it to bypass your choice of permissions.
Staff will eventually get around to testing the software and installing it system-wide. If the request is not updated by a staff member after a decent amount of time (remember, everybody has lots of work to do), try bumping the request and a friendly staff might explain why no action will be taken, or will install the application.
Last Modified Thursday, 14-Oct-2004 16:07:22 PDT
|
