JackNeely

jjneely@pams.ncsu.edu

January 23, 2002 This document is aimed at explaining the user management tools that have been developed here at NCSU to manage the PAMS Beowulf running Scyld's Beowulf software with the NCSU modifications. The reason for this software was a desire for an automated method of creating accounts for people that wanted to use the Beowulf and met the proper qualifications. The software is also required to send out proper notification to the user granted an account and to the PAMS system administrators. If you have questions, concerns, additions, corrections, or what have you to this document or to the software in question please feel free to contact the author. The Account Request Page is the place to go to get an account on the PAMS Beowulf Cluster. By accessing this page you make known to the PAMS system administrators that you are asking for an account. If certain qualifications are met you will be granted a provisional account within the next hour. (The scripts run every hour.) At which time you and the PAMS system administrators will be notified by a call being placed in Remedy. The system administrators can then approve or deny the account. As of this writing, the only difference between a provisional account and a approved account is a substantial increase in quota. There are several restrictions on the use of this cluster. This cluster was purchased with PAMS ETF money and therefore must be for student use. The Account Request Page will automatically grant an account to a graduate or undergraduate in a PAMS major. Faculty and staff can use the cluster but must first arrange an agreement with Pete Evans in PAMS Computing Operations. The Account Request Page is a web form implemented in PHP. WRAP is used for authentication. Your user ID is then passed to the PHP script via an environment variable. Three checks are don against the user ID. The first attempts to find the user ID in a list of all PAMS majors which is contained in AFS. The second checks to see if the user has already been added to the system. The third checks to see if the user's ID is less than 65,535. This is due to the version of the Linux kernel and glibc in the Scyld Beowulf software not supporting user IDs that are greater than 65,535. If all these checks succeed, the user ID is added to the "access_list" table in the database, the user's preferred email is added to the "email" table, and the user's supplied reason is added to the "reason" table. Otherwise, account activation fails and the user is given a message describing the problem and an email address of the PAM system administrators. Currently, I am not aware of any bugs or feature enhancements that need to go into this particular part of the Beowulf management scripts. The purpose of the page is so that systems administrators can approve the provisional users on the system. Each provisional user is list with three possible actions. These actions are "approve," "defer," and "remove." Respectively, the three actions upgrade the user to a real user, no action, and remove the user from the system completely. In the final case any data the user has in his home directory will be preserved. Once again, this script is a WRAP authenticated PHP script. Users in /etc/users.local have permission to access this script and therefore approve and deny users on the Beowulf. If a users is "approved" the respective user ID is dropped into the "upgrade_list" table in the database. If the user is "removed" the the user ID is dropped into the "remove_list" table. All updates actually happen the next run of the back end scripts. This script is pretty new and feature less at the present moment. It definitely needs to look a little better and friendlier. Also, the "defer" action should probably be the default rather than the "approve" action. Not implemented. Not implemented. Not implemented. This documentation is part of an RPM package that contains all the web scripts and back end scripts fot the Beowulf User Management stuff. Currently, there is no defined point of distribution for this software but if you are interested in looking at the source please contact the author of this document. Source RPMS can be made available. The back end script is written in Python and runs once an hour via cron. Its purpose is to update the database and carry out those actions, when necessary, on the head node of the Beowulf cluster. The reason this functionality is separated out from the web scripts is that the backend script requires root access to the Beowulf. Hopefully, this separation will help keep possible exploits to a minimum. The script has three main peaces of functionality. In order of execution they are addusers to the Beowulf, upgrade users on the Beowulf, and remove users from the Beowulf. Adding users removes the ID of the person to add from the "access_list" table, adds the user on the Beowulf, sends email to the user and Remedy, and drops that ID into the "users.provis" table. Upgrading users takes the IDs from "upgrade_list" and increases their quota and adds the upgraded users to the "users.real" table. Proper checks and removals are also done to the "users.provis" table. Remove users attempts to remove all users found in the "remove_list" table from the cluster and their user IDs from either "users.real" or "users.provis." The back end script started out rather messy but got decently clean when more functionality was added. (Lots of refactoring.) Currently, it supports all the features found in the web pages but will surely grow in the future. Very soon it will most likely be broken into multiple files. The database for the whole operation is currently a collection of text files and directories located in /home/cluster_db. There is a growing number of tables in this database and a distinction between tables that the web scripts can touch and tables that the back end script manages. The two tables that the web scripts are not to touch are the "user.provis" and "user.real" tables. The other tables are "reason", "email", "access_list", "upgrade_list", and "remove_list". Some time real soon now I will make all this use DBM, shelves, or something of the like. My gosh, file I/O is horrid!