On this page you will find ideas and suggestions for some student projects. If you cannot find a suitable project here, you are welcome to tell us your own suggestions.
1. Modular Bootmanager
Possible mentors:
Stephen Soltesz
Marc Fiuczynski
Background:
Every machine in the PlanetLab network boots from a read-only boot image (CD-ROM or read-only USB stick). The first step of the BootImage is to configure the machine's network and download a second-stage script called the BootManager (BM) which is responsible for configuring the other parts of the hardware, verifying that the machine has minimal resources (amount of RAM, size of disk, speed of CPU), and installing a bootstrap file system onto the disk to prepare our production environment.
Problem:
This process does not always work. It is very time consuming for admins to visit the node and manually diagnose the problem. As well, there is no means of applying solutions learned in one location to all future sites. There is currently no framework for installing extra components into BM without modifying the code directly.
Insight:
The BM run-level is a controlled environment, with complete access to the machine. If the BootImage can download BM, then BM should be able to fetch and run other modules also.
Proposal:
Extend BM to support modules. These extension would enhance BM's functionality without changing BM itself. Adding such a module would be simpler than modifying BM.
Useful modules:
* Runlevel agent
* OpenVPN client
* Additional hardware and environment diagnostics to detect bad disks, mis-configured networks (DNS, time servers, firewalls, etc.)
* Other monitoring agents like snmpd or zabbix.
* Help with the recovery of common problems (corrupted installation, out-of-date installations)
You would take an active role in defining how BM would be modularized and thinking through the operations aspects of keeping the modules easy to manage over time; i.e. how to distinguish a core set (default), a set that are installed only for certain machines (special groups), and those meant only for certain times (errors). The current implementation is in python and we would prefer that it remain so.
2. CFengine for ConfFiles
Possible mentors:
Faiyaz Ahmed
Stephen Soltesz
Background:
Every machine in PlanetLab needs to remain up-to-date with the latest rpm packages and fixes. However, some of the files that we update are at a finer-granularity than RPM. Today, we use a mechanism that periodically requests a list of configuration files via our API.
Problem:
Our experience is that this mechanism is clumsy and difficult to administer for the kind of quick, persistent, and find-grained changes that we would like to make.
Proposal:
Find a way of leveraging CFengine, or other configuration management tool, to replace our API calls for this operations and management need. A successful proposal would reassure us that the solution would be easy to administer (quick or intuitive), easily persistent (changes will not be lost), and flexible enough to apply to individual hosts, sets of hosts, or all hosts.
3. Develop the world's first automated memory-leak detector
Possible mentor:
Sapan Bhatia
Background: Managing memory in large, complex programs is a formidable task. This is why over the years, critical systems such as the Linux kernel, the Apache web browser, and many more, have been riddled with memory-management errors. The most common instance of such errors is the memory leak. Memory leaks are caused when a program fails to free memory that it will not use any more. Even environments such as Java that make use of automated garbage collection are susceptible to memory leaks caused as a result of dangling object references. These errors cause program crashes in the best case, and system crashes in the worst case.
Proposal: The goal of this project is to develop an automated memory-leak detector that would monitor live systems to not only identify programs with memory leaks, but also inform the developer of the program of the circumstances in which it happened, pointing out the associated lines of code, stack traces etc. We envisage the end product to be a daemon that would gather such information and send an email to the developer of the offending program asking him to fix the error. If successfully implemented, we will deploy the solution on PlanetLab - a planetary-scale testbed consisting of over 800 machines distributed worldwide.
The foundation of this project, which is to collect data that would aid in identifying and diagnosing memory leaks has already been built (http://www.usenix.org/events/osdi08/tech/full_papers/bhatia/bhatia_html/index.html). Analysing this data is challenging for two reasons: 1. Allocations and deallocations in the data are decoupled - i.e., the data is unable to match 'mallocs' with their corresponding 'frees'. 2. The amounts of memory reported are associated with a small probability of error (e.g. malloc (500) may be reported as malloc(250) once out of every 1000 times). A good analysis tool will amortize these shortcomings over the long periods for which data is collected. The conceptual tools involved in this project may include the following: parsing, machine learning, system programming and programming in a functional programming language. Our main interest is to develop a solution that works. We are flexible about the means to get there.
4. Work on a new privilege-allocation scheme for virtual environments
Possible mentor:
Sapan Bhatia
Background: Traditionally, privilege assignment on Operating Systems is based on ACLs and capability systems. While this approach has worked well in the past, it is too coarse-grained to cater to the complexity of virtual environments. Specifically, ACLs and capability systems assume a 2-tier definition of the OS in which the two tiers; user space and kernel space, are separated by a system-call boundary. Virtual environments on the other hand are based on a 3-tier definition of the OS in which there is an additional separation between the 'host' and 'guest' access domains. Unlike the well-defined system-call interface, the interface between these domains is dynamic and highly system-specific.
On PlanetLab, we use a privilege allocation tool called Vsys, which can define privileges at an arbitrary granularity through executable scripts that filter data between the host and guest domains. Unfortunately, specifying privileges using Vsys is tedious and error-prone. Also, it does not have access to any well-defined abstractions (such as ACLs and capability sets), which prevents code reusability.
Proposal: The goal of this project is to design and implement a new specification language for Vsys. Using this specification language, an administrator would be able to express traditional ACLs and capabilities. For example, that user X has read-only access to /dev/sda1, or that user Y has the capability to mount new partitions. Additionally, it would allow administrators to execute complex privileges that current ACLs and capability systems do not support. For instance, that "user X has the privilege to mount /dev/sda1 in read-only mode as long as /dev/sda1 is not currently mounted". Or that users associated with a site 'princeton' be given access to entries in the /etc/password file that have the prefix, "princeton_".
An essential qualification to apply for this work is strong intuition for UNIX development. We believe that if designed well, this new approach will be a strong candidate as a replacement for tools such as sudo. For more information on vsys, please see www.cs.princeton.edu/~sapanb/vsys, or get in touch with us.
