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 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
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:
| | |
dropbox returnboxes classinfo
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:
| | |
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
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
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
setfacl -m u::rwx,u:mrborwn:rwx,g::r-x,o:r-
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
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: firstname.lastname@example.org.