WhereAmI

Summary

During bootup, a whereami-like application will gather information about the machine's environment. According to a user-defined configuration, it will choose what network interfaces to bring up and how, what xorg config file to use, what remote shares to attempt to mount, what proxy server to use, what services to start, etc.

Rationale

Many laptop users use their machines in various locations with different environments. Remote shares, proxy servers and other network resources will differ in availability among these locations. A laptop may be docked in one location and not another, and so have multiple monitors available or not. A machine used both at home and on the job may need certain services running at one location and not another. Authentication may be local at one location or use LDAP at another.

Use cases

Trent has a laptop he uses both at work and at home. He also frequents a coffee shop with an available wifi network.

At work, he is usually docked and physically connected to the network and does not need to use his wifi card, but he occasionally attends meetings where only the company's wireless connection is available. When docked, he has an additional monitor available and wants to use an xorg.conf file that reflects that. When at the office, whether docked or mobile, there are SMB and NFS shares he wants auto-mounted, and he must authenticate against an LDAP server. He must connect to the Internet through an HTTP proxy.

At home, he only uses his home wireless network, all of whose connection information differs from the one at the office. He wants to authenticate locally. He has a different set of SMB and NFS shares to mount. There is no proxy server.

Scope

Create an application to gather the information necessary to determine the location. Create a repository for configuration files, such as xorg.conf, to which the application will create symlinks as appropriate before the configuration file's application starts. Select network interfaces to bring up, remote shares to mount, environment variables to set, and so on.

Design

The application will organize the configured locations into 'profiles'. Information used to identify the appropriate profile will be configured by the user. For example, "If wireless network X is available, I'm at the office. If I'm docked, I'm at my desk and have an extra monitor and a physical network connection. If not, I have neither. If wireless network Y is available, I'm at home, and if there's a DHCP response on eth0, I'm connected to the physical network." Based on the results, a user-configured list of services will be started or stopped, environment variables set, remote filesystems mounted, configuration files linked to, etc.

Implementation

A Ruby (if I write it) or Python script will load the user's configuration, gather the required information, and make a determination about the current location, and implement the appropriate user-configured changes. This script will be sufficiently decoupled from the QT/GTK configuration front-ends as to allow new front-ends to be easily developed.

Data preservation and migration

Files (especially configuration files) altered by the migration will be stored in their original forms with a dpkg-assigned suffix. When the application is installed, no changes are made outside the scope of the application itself until the user configures it to do so, and in the event of a problem, the original configuration can be restored.

Outstanding issues

An application called 'whereami' exists and has a similar purpose, but does not appear to be designed in such a way as to accommodate this specification.

CategorySpec

WhereAmI (last edited 2008-08-06 16:14:27 by localhost)