USENIX Association Proceedings of LISA 2002: 16th Systems Administration Conference Philadelphia, Pennsylvania, USA November 3–8, 2002 © 2002 by The USENIX Association All Rights Reserved For more information about the USENIX Association: Phone: 1 510 528 8649 FAX: 1 510 548 5738 Email: [email protected] WWW: http://www.usenix.org Rights to individual papers remain with the author or the author's employer. Permission is granted for noncommercial reproduction of the work for educational or research purposes. This copyright notice must be included in the reproduced paper. USENIX acknowledges all trademarks herein. Pp. 1-12 of the Proceedings of LISA ’02: Sixteenth Systems Administration Conference (Berkeley, CA: USENIX Association, 2002). Work-Augmented Laziness with the Los Task Request System Thomas Stepleton – Swarthmore College Computer Society ABSTRACT Quotidian system administration is often characterized by the fulfillment of common user requests, especially on sites that serve a variety of needs. User creation, group management, and mail alias maintenance are just three examples of the many repetitive tasks that can crowd the sysadmin’s day. Matters worsen when users neglect to provide necessary information for the job. They can grow bleakest, however, at volunteer-run or otherwise loosely-coordinated sites, where sysadmins often collectively hope for someone else to attend to the task. The Los Task Request System addresses all three problems. It mitigates user vagueness with web forms generated from XML parameter specification files. It skirts sysadmin sloth by requiring one simple review and approval step to set changes into motion. It then saves time by automatically executing commands tailored from user input. Amidst this convenience, cryptographic signatures on Los directives ensure that only administrators can alter the system. Overall, Los aims to make life easier for users and sysadmins by standardizing and streamlining the submission, review, and execution of requests for common system tasks. Introduction system configuration information to the user in order to be user-friendly (e.g., no rote memo- For over a decade, the volunteer student system rization of group names). administrators of the Swarthmore College Computer 4. It would have to be secure by design. Only Society (SCCS) have provided shell, mail, and web sysadmins should be able to make changes to services to hundreds of College-affiliated users. How- the system, and integrating new tasks into Los ever, a problem arose during the 2001-2002 school should never compromise its security. year: nobody was volunteering to take care of com- mon system administration requests. The sysadmins Happily, after months of programming, Los had an excuse: most were seniors that year and were appears to fulfill all of these requirements. Points 1 confronted with the double whammy of the formidable and 3 were handled by diligent coding of no particular Swarthmore workload and figuring out what to do novelty; the approach to points 2 and 4, on the other after college. Still, the requests kept piling up. hand, is Los’s most compelling feature. Immediately, the SCCS chose to hire new sysad- Los can be characterized as a ‘‘semi-automatic’’ mins from the freshman and sophomore classes. At the system administration tool. Some system administration same time, however, an idea began to take form. tools directly empower the user to make important Instead of having users mail the admins with only changes to the system. These ‘‘fully automatic’’ tools are vague ideas of what they need to say to get things carefully written to resist malicious behavior on behalf of done, what if a web form could guide them in supply- the user; however, since they must have elevated privi- ing the necessary information? Then, what if the leges, there’s always a slight risk of an exploit. Los is sysadmins could just direct the data to some handy designed so that only the sysadmins can activate the scripts and have everything taken care of automati- privileged part of the system. A review of the user’s cally? The notion of turning the e-mail client into a input, or ‘‘task request,’’ by a responsible human, while system administration tool was compelling, and relatively brief and unchallenging, is mandatory. through an impossible feat of time management, The best way to understand how the Los system development of the Los Task Request System began. works is to follow it as it handles a single task request. From the onset, it became clear that Los would This ‘‘bird’s eye view’’ will reveal that there are many have to satisfy some challenging requirements: steps involved in the process. However, it is important 1. It would have to be general enough to handle to remember that users and sysadmins themselves only many different types of system administration see a small and manageable fraction of them for any tasks. given request. 2. It would have to reduce the time required for The process starts on the Web, where the user common system administration tasks beneath makes a selection from a catalog of available auto- the threshold of the harried student volunteer. mated tasks (Figure 1). This catalog is generated from 3. It would have to collect and present necessary a collection of task description files, which are XML 2002 LISA XVI – November 3-8, 2002 – Philadelphia, PA 1 Work-Augmented Laziness with the Los Task Request System Stepleton files that contain all the information Los needs to verification message. The user visits a web address solicit and apply task information from a user. from the message, and Los sends their input on to the Using information from the description file for sysadmins. The user is finished and now waits for the the user’s chosen task, the Los web interface retrieves task request to be fulfilled. information from the user with a ‘‘wizard’’-style series A few moments later, a sysadmin sees the task of input forms (Figure 2). The description file can request as an XML document attached to an e-mail. invoke sophisticated filters that check the validity of Surveying the user’s input, the admin decides it is input and solicit corrections (Figure 3). valid and uses a small utility to forward the data to the When the user finishes entering data, Los checks Los task execution module. The utility cryptographi- the e-mail address they specified by sending them a cally signs the request with the admin’s GNU Privacy Figure 1: The Los task list. The user begins here. 2 2002 LISA XVI – November 3-8, 2002 – Philadelphia, PA Stepleton Work-Augmented Laziness with the Los Task Request System Guard (GPG) [1] key before sending it. (In the future, commands from the task request data, and each com- the utility will be unnecessary; the sysadmin will sim- mand is executed. Finally, Los mails the commands’ ply forward a signed copy of the task request e-mail to output to the sysadmins for review. the execution module directly.) The sysadmin is fin- By now, the SCCS has successfully adapted a ished and waits for an e-mail confirming the execution number of system administration tasks to this auto- of the task. mated paradigm. Users are able to request new The Los task execution module, having validated accounts, create and manage mail aliases and mailing the signature on the task request, loads the appropriate lists, and allocate and control access to shared student task description file and determines what commands it organization webspace through six custom-made Los needs to run. It gleans arguments to the specified tasks. Figure 2: Using a ‘‘wizard’’-style interface, the user enters data for the task. 2002 LISA XVI – November 3-8, 2002 – Philadelphia, PA 3 Work-Augmented Laziness with the Los Task Request System Stepleton Related work are owners of particular websites or other Internet resources and the administrator must oversee the The goals of Los are not especially novel. Sev- servers that host them. Because site owners want to eral systems that automate or at least accelerate com- provide the same services on their sites that organiza- mon system administration tasks already exist. These tions with dedicated servers can provide, it is often seem to fall into two categories: the fully automatic necessary for system administrators to directly config- user-centric systems that require no sysadmin inter- ure mail transport agents, FTP daemons, and other vention, and systems which are intended to be seen systems to their needs. Some solutions to this problem only by the administrators. A few seem to cater to streamline the sysadmin’s job: one example software both, depending on their configuration. package is ispbs [2], which provides a convenient web A good first place to look for both kinds of soft- interface for administration of many such sites. There ware is the Internet hosting business, where the users are several systems that also have user-centric Figure 3: Task description files can invoke filters that check the validity of user input. 4 2002 LISA XVI – November 3-8, 2002 – Philadelphia, PA Stepleton Work-Augmented Laziness with the Los Task Request System capabilities, however, including Account Systems employs a separate mechanism for each stage. While Manager [3] (ASM), and ISPMan [4] which provide the mechanism for task request review is actually the web-based configuration interfaces to the user as well. judgment of a discriminating system administrator, the To make system changes, all three eventually require other two steps are automated by two Perl programs of some sort of automated privileged mechanism: ispbs considerable complexity: the web interface and task uses a script that is automatically executed as root by execution module mentioned previously. The web cron, ASM executes changes immediately by always interface is a CGI program that resides in any web running as root, and ISPMan places user requests into accessible directory that permits execution of CGI an LDAP database which is queried periodically by an scripts.