oct2001.tar

E-Class Tools

Keith Clay

In the early 1990s, it became apparent to professors at the college where I work that collecting, tracking, and successfully returning 40 floppies to a class was an untenable task. A Mac server was then put in place, which allowed professors to distribute information to students and for students to turn in assignments. This was later transferred to a Windows NT server to allow both PC and Mac users access to the system. All work was done manually on both systems -- accounts were added, directories created, and permissions set by hand. This is the system I inherited.

Because I'm a UNIX convert, I decided to move the system to our Solaris box. This required software to allow Macs and PCs to use the same filesystem and share these files (i.e., a Mac user could save a file and go to a PC and open it without problems). We chose the Totalnet Access Server (TAS) from Syntax, Inc. This provided file access from both types of machines and allowed access to Solaris for scripting and ACLs.

We are using TAS rather than Samba and Netatalk. TAS allows us to move or copy Mac files on the command line and preserve the resource forks. From the client perspective, there is no additional software that reduces the time to implement and support. The client can create a file on a Mac and then manipulate it on a PC without loss of the resource fork. This allows students and professors to use different types of computers and access the same files. The cost for TAS when we bought it in 1999 was $40/client; we paid $40,000 for 1000 clients.

The current classfolder and dropbox system provides a way for students to turn in assignments, and for faculty to grade and return assignments and to electronically disseminate information to classes.

What Users See

Every night we receive a number of data feeds from the Administrative Computing Department. We use this information to load a MySQL database with user and class tables. When user accounts are created on Solaris, all accounts have the following directory structure:

$HOME -----------------------------------------------
           |            |            |            |
           Home         Classes      Web Files    Shared

Fileservice access is set up on each of these directories. Accessing a Windows share like \\student\home actually mounts $HOME/Home; \\student\classes mounts $HOME/Classes, etc. This prevents access to the $HOME directory in which we store other directories and files.

Faculty members are provided with a Web interface to create classfolders and dropboxes (Figure 1). They can select the classes for which they desire classfolders and dropboxes, and they can crosslink classes so that classes can share the same dropboxes and classfolders (Figure 2). As faculty members choose to create classfolders and dropboxes, a database record is updated with the necessary information. A script that creates these classfolders and dropboxes runs every five minutes.

For example, let's take a class like 011_HIST10001. The 011 indicates the year (01 - 2001) and semester (1 - Spring) under which the class is listed. When the classfolders and dropboxes are created, the directory structure for professors looks like this:

$HOME -----
            |
            Classes
                  |-- 011_HIST10001
                        |---------------------------
                            |        |            |
                            dropbox  returnboxes  classinfo
                                          |
                                          |--- kac97t_Keith_Clay
                                          |--- ejf00a_Elmer_J_Fudd

Three directories are created: dropbox, returnboxes, and classinfo. Classinfo contains information that professors want their students to see (i.e., syllabi, assignments, etc.). Student assignments are placed in the dropbox folder. Returnboxes contains a directory named by userid (Solaris account name) followed by the student's name. Students also see three directories:

$HOME -----
    |
    Classes
          |-- 011_HIST10001
                |---------------------------
                       |        |             |
                       dropbox  returnbox     classinfo

The only difference is the returnbox directory; it is not plural and contains no directories. All returned files are placed in the student's returnbox.

The Workings

Two transporter scripts power this system: one to drop and one to return assignments. The drop transporter script runs every seven minutes. It moves the file from the student's dropbox to the professor's dropbox. In the transporting step, it prepends the userid to filename (e.g., assignment#1 becomes kac97t_assignment#1). This serves two purposes -- it gives each file a unique name, and (because the transporter runs as root) it prevents one student's file from overwriting another's. After the professor grades the assignment, it is then dropped into that student's directory in the returnboxes directory. The return transporter runs every ten minutes and moves files from student's returnbox in the professor's returnboxes directory to the student's returnbox in his or her class directory.

The classinfo directory is linked into each student's class directory. To do this, ACLs are used to protect this area (see Ross Oliver's article "Achieving More Flexible File Permissions Using Solaris ACLs" in Sys Admin magazine, May 2001). A typical getfacl from a classinfo directory looks like this:

# file: classinfo
# owner: mrbrown
# group: usrfiles
user::rwx
user:mrbrown:rwx        #effective:rwx
user:ga1:rwx            #effective:rwx
user:ga2:rwx            #effective:rwx
user:ga3:rwx            #effective:rwx
group::r-x              #effective:r-x
mask:rwx
other:r-x
default:user::rwx
default:user:mrbrown:rwx
default:user:stud1:rwx
default:user:ejf00a:rwx
default:user:kac97t:rwx
default:user:ga1:rwx
default:user:ga2:rwx
default:user:ga3:rwx
default:group::r-x
default:mask:rwx
default:other:r-x

The professor ("mrbrown") has three students in the class. ACLs on classinfo folders are assigned to give write privilege to files and read-only privilege to directories. This was done to overcome the way that Macs deal with file permissions; if the files are also read-only, Macs won't allow dragging and dropping the file into the student's folder. The professor's ACLs are set this way:

setfacl -m u::rwx,u:mrborwn:rwx,g::r-x,o:r-
x,m:rwx,d:m:rwx,d:u::rwx,d:g::r-x,d:o:r-x,d:u:mrbrown:rwx  
~mrbrown/Classes/011_HIST10001/classinfo
setfacl -m u:mrbown:rwx,m:rwx $tmpfile

ACL's for students are set this way:

setfacl -m u:kac97t:rwx,m:rwx $tmpfile
setfacl -m d:u:kac97t:rwx ~mrbrown/Classes/011_HIST10001/classinfo

Default ACLs (d:u:kac97t) are set on the professor's classinfo directory, and regular ACLs are set on a temporary file. Once the entire class is processed, the first command below sets the ACLs on all regular files (non-directories) to the ACLs on the temporary file. The second command below sets the ACLs on all the directories under classinfo. The $fl represent either a file or directory from the output of a find in a for statement in ksh.

getfacl $tmpfile|setfacl -f - $fl
getfacl ~mrbrown/Classes/011_HIST10001/classinfo|setfacl -f - $fl

ACLs on a file in the classinfo directory look like this:

# file: syllabus
# owner: mrbrown
# group: usrfiles
user::rw-
user:mrbrown:rwx        #effective:rwx
user:kac97t:rwx         #effective:rwx
user:ejf00a:rwx         #effective:rwx
user:stud1:rwx          #effective:rwx
user:ga1:rwx            #effective:rwx
user:ga2:rwx            #effective:rwx
user:ga3:rwx            #effective:rwx
group::r--              #effective:r--
mask:rwx
other:r--

A script checks the integrity of these ACLs every five hours. Notice that the user kac97t has write privilege to files in classinfo, but only read privilege to the directories. This satisfies the Macs and prevents files from being overwritten (i.e., the user can't write to the directory). The default ACLs on classinfo give students write privilege on files created in the classinfo directory. There are ACLs set on the professor's dropbox that give faculty write permissions to any file dropped.

Notice the three accounts called ga1, ga2, and ga3. These users have both write privilege to the directories and the files in classinfo; they actually have read and write privileges to the 011_HIST10001 directory. Professors can designate Graduate Assistants (GAs) or even other professors permissions to this class (Figure 3). Permissions can be granted either as read or read/write. These users have the same permissions as professors so that they can grade assignments, return assignments, and place files in the classinfo folder. A link to the class is created in the GAs' shared directory. Again, this is controlled from the Web interface that professors use to create the classfolders and dropboxes. This is part of a larger sharing program that allows users to share files and directories.

This system allows the dissemination of both assignments and information between students and professors using the power of ACLs under Solaris. This system takes advantage of UNIX and is completely automated -- no floppies were used or abused writing this system.

We are currently working to package the system so that others who want to use it can easily implement it at their sites. We hope to have a version available in 2001.

Keith Clay is the lead programmer for the Web Integration and Programming group at Abilene Christian University where he is currently working on a Master of Divinity and Master of Arts in Greek New Testament. He has been using UNIX since 1984 and completed a BS in Applied Science at Miami University, Oxford, Ohio. He spends his spare time trying to manage three cats and one very silly golden retriever puppy. He can be reached at: clayk@acu.edu.