Contents
- Introduction
- Goals
- Release Deliverables
- Development Infrastructure
- Milestones
- Release Features List
- Design Plans For Release Features
- Desupported and Changed Features
Introduction
The Athena 10 release is planned for summer 2008. It is intended to renew the Athena software, improve security, bring the base operating system into closer alignment with the MIT community, and reduce the ongoing maintenance burden of the Athena environment.
The Athena 10 project will be a collaboration with the Debathena developers from SIPB and will also act as a follow-on to the current Debathena release. From IS&T, the primary developers will be Greg
Hudson (the release engineer and lead developer), Robert Basch, and Andrew Boardman, with Alex Prengel taking on the role of ensuring compatibility with third-party software lockers. From the SIPB, the contributors will be Tim Abbott and Anders Kaseorg.
Goals
- The supported base operating system will be Ubuntu 8.04 (Hardy Heron), which is due out in April 2008 and is tagged by Canonical as a long-term support release. Development will mostly take place on Ubuntu 7.10 (Gutsy Gibbon).
- The build infrastructure and package repository will also support versions of Debian and other versions of Ubuntu. These operating system versions will be supported by SIPB rather than IS&T.
- When a software package exists in the Ubuntu package archive, we will not build it ourselves from the upstream source. In cases where a change is necessary, we will use a script to rebuild the relevant Ubuntu and Debian source packages with a patch applied.
- We will plug into system features such as PAM and NSS to avoid having to replace core parts of the base platform.
- We will use autofs on /mit to remove the need for users to manually attach lockers (though the attach command will remain for compatibility and system notifications).
- We will make our configuration packages as modular as possible, rather than bundling them all up into an athena-ws package.
- We will use the standard /usr path prefix for Athena software rather than using a separate tree in /usr/athena. There will be a big package of compatibility symlinks to ensure that most old path references keep working.
- The update system will no longer be organized around specific patch releases. This change will allow us to better leverage the native update system and will also enable machines to take native package updates as soon as they become available, which will improve security.
Release Deliverables
The deliverables for the Athena 10 release are:
- A set of packages containing Athena original software (e.g. Larvnet, attach, etc.) with names like debathena-discuss.
- A set of packages controlling configuration of other packages (e.g. sshd) with names like debathena-hesiod-config.
- A set of packages to perform self-maintenance (e.g. to clean up temporary directories).
- Source repositories for software which has Ubuntu packages, but for which we are the upstream maintainer (e.g. Zephyr).
- An automated update from Athena 9.4.
- An installation system.
- Release notes and documentation, particularly for aspects of Athena 9.4 which become desupported or supported in different ways.
Development Infrastructure
The Athena CVS repository will be converted to Subversion and copied to svn.mit.edu. This will become the development trunk; the CVS repository in AFS will remain as a branch for Athena 9.4 development.
The source tree will be reorganized to reflect the new architecture. The tentative new organization is:
- athena - Athena local software. New debian subdirectories will be added to each software directory to turn these into Debian packages.
- third - Third-party software imported from orginal source provider. Ideally, this would go away completely; in practice, a few packages may remain and have debian subdirectories added.
- doc - Source tree documentation.
- debathena/scripts - Build scripts and other supporting
materials. - debathena/config - Sources for debathena-config-* packages.
- debathena/debathena - Sources for debathena-specific software
packages such as debathena-libnss-afspag. - debathena/meta - Sources for metapackages.
- debathena/third - Scripts and supporting materials for building modified versions of native Debian and Ubuntu packages.
Conspicuously absent is the packs directory; the entire contents will be replaced with Debathena-specific packages.
Milestones
(This section needs to be reconsidered in light of the Debathena collaboration. The milestones will look very different as a result of fully incoporating the Debathena work.)
These milestone due dates assume the project starts immediately and has the focused attention of Greg, Andrew, and Bob (Andrew and Bob after two weeks) until completion of the Feature Complete milestone. The due dates will likely need to be adjusted for other realities. I am assuming that minimal work gets done between Dec 15 and Dec 31.
A "big scheduling monster" is a task which dwarfs the other milestone's tasks in size. A developer who is assigned to a big scheduling monster should not receive many other tasks.
- Infrastructure - Development infrastructure in place including source tree and build scripts. Ubuntu machines in the hands of Andrew and Bob so that they may begin work. Due date: November 15.
- Core - The fundamental building blocks of the Athena environment are in place (AFS, login, incremental updates, etc). Due date: December 15.
- Basic - The high-profile Athena applications are in place (Firefox, email, etc.). Due date: January 31. Big scheduling monster: email clients.
- Cluster - Self-maintenance features and GNOME modifications necessary for cluster machine deployments are in place. Alpha testing can begin once this milestone is complete. The updater is complete. Due date: February 28. Big scheduling monster: The updater.
- Feature Complete - Remaining release features are completed except for rearchitected printing. The installer is complete. System release notes are complete. The compatibility symlinks package is complete. Due date: April 15. Big scheduling monster: The installer.
- Beta Testing Complete - Acceptance testing is complete and Athena 10 is ready for "early release" deployment. User release notes are complete. Rearchitected printing is either complete or deferred indefinitely. Due date: May 30.
- Full Deployment - Early release is complete and Athena 10 is released to all cluster machines. Due date: June 30.
Release Features List
Applications
- Users can connect to the mainframe with the x3270 terminal emulator.
- Users can send and receive Zephyr messages.
- Users can browse the web with Firefox, which is preconfigured with the MIT CA, a local filesystem path for its disk cache, and the Java and Flash plugins.
- Users can easily connect to the MIT Chat service with Gaim, and in addition can use the gaim-encryption plugin for end-to-end message encryption.
- Users can easily read MIT mail using Evolution or Pine.
- Users can read archives in Discuss.
- Users have access to a rich C development environment as well as basic installations of Perl, Python, and Java.
- Users have access to a variety of non-standard utilities (jot, lam, saferm, etc.).
- Users can print to Athena network printers with the lpr command and from applications which support printing.
- Users have access to the enscript command to format text documents into postscript for printing.
- Users can run emacs with Athena site customizations.
- Users can conduct single sign-on logins to other Athena machines (provided they have a keytab and are configured for remote access) or compatible non-Athena machines via kerberized ssh, telnet, rlogin, or ftp.
- Users can query and manipulate IMAP mail stores with the mailquota, mailusage, from, and mitmail* commands.
- Users can access and run software from AFS lockers through /mit paths via "attach", "add", "setup", and related commands. Home directories are also treated as lockers.
- Users can use a network-enabled replacement for "write" between machines.
- Users can query Athena hesiod information with the hesinfo command.
- Users can spell-check documents using the ispell command.
- Users can pull down MIT mail with the emacs movemail command (currently uses kpop).
- Athena machines have a selection of international fonts installed.
- Users can talk to serial devices using kermit.
- Users can process TeX and LaTeX documents.
- Athena machines can access Windows file shares using a Kerberos-enabled smbclient which is pre-configured for the win.mit.edu realm.
- Athena machines have attach-and-run scripts in the default path for various bits of locker software such as the Moira tools.
Legacy Features
- Athena users can run an old desktop interface based on dash and mwm instead of GNOME if they have opted to do so.
- Athena users can elect to run Sawfish (an outdated GNOME window manager) instead of Metacity.
- Users can read mail with the nmh command suite (currently uses kpop).
- Users can browse the web with Mozilla instead of Firefox. Mozilla can also be used to read mail and edit HTML files.
Serial Reusability
- Any MIT user can log into cluster machines using their Kerberos passwords and their AFS home directories.
- Root logins on cluster machines are not permitted, but users can su to root once they log in as themselves.
- Users can change their Kerberos passwords with the passwd command.
- Private machine admins can configure who can log into machines remotely and locally with the /etc/athena/access file. They can also tag accounts as "local" and not part of the Hesiod/AFS namespace.
- Athena machines tagged as quickstations display a timer and nagging warnings to log out after a set period of time.
- Users can temporarily enable and disable remote access daemons on Athena machines with the access_on and access_off commands, if the machine is configured to allow this.
Changes For Shared Network Home Directories
- GNOME Bonobo components from one login session will not be reused in another login session because they may not have access to the same tickets and tokens. There is similar isolation for gconfd-2 for the same reason.
- Users can log in simultaneously from multiple machines without running afoul of GNOME software locks in the home directory.
- If a user's home directory is unavailable upon login, a temporary homedir will be created on local disk and used instead.
- Users can log in with "ignore customizations" or in terminal mode to repair severely broken dotfiles.
- User processes generated by Athena software components do not stick around after the user logs out. On cluster machines, user processes are forcibly killed after the user logs out.
- Athena machines have a screensaver which accepts a Kerberos password to unlock and which allows the user to be logged out after a set time.
- GNOME won't display a dialog about changes in X keyboard settings from one login to another, since the same account is used on multiple machines.
- Basic GNOME functions will work when the user's home directory is inaccessible (such as when the user's AFS tokens have expired) or is over quota.
- GNOME's trash handling has fixes for Athena home directories.
Monitoring
- Athena machines can be queried via athinfo for various bits of information.
- Athena machines record a history of their patch release numbers and dates of each update.
- Athena machines forward some syslog notices to a central host for monitoring purposes.
- Athena machines send information about whether they are in use to a "larvnetd" daemon on a central host which can be queried using the cview and xcluster commands.
- Athena machines report centrally about their existence, machine type, and version so that they can be counted.
- Athena machines respond to requests on the "time" and "daytime" ports with their idea of the current time.
Self-maintenance
- Athena machines have filesystem-level access to AFS.
- Athena machines periodically clean up files in temporary areas to avoid slowly filling the disk.
- Athena machines automatically take updates when we put out new releases.
- Athena machines have a consistent set of native platform packages installed, which is a superset of the default package set.
- Athena machines can be flagged as "public", which implies that they have no persistent data or customizations and can engage in more aggressive cleanup activities.
- The default GNOME panel setup contains a menu of important Athena locker software (currently unmaintained). For performance reasons, the files representing this menu must be stored on local disk.
- Some lockers containing frequently-used software are stored on local disk for performance reasons.
- Cluster machines perform some self-integrity checking to repair accidental and casual changes to their configurations.
- Athena machines may be part of a Hesiod "cluster" which can determine whether they take beta updates, whether they are cluster/quickstation machines, and what their default printers are.
- Particular aspects of Athena machines can be configured by editing /etc/athena/rc.conf.
- Cluster machines use static IP addresses and have an easy procedure for changing IP addresses when they are moved to different subnets.
- Cluster machines run a local name server and are configured to use it to cache name lookup results.
- Admins can enable various nework services with the "mkserv" command; the most popular of these is "mkserv remote" to permanently enable remote access daemons.
- Athena machines almost always have the correct time as determined by time.mit.edu.
- Athena machines automatically synchronize the hardware clock following Daylight Savings Time changes.
- Athena users receive messages of the day prior to logging in (the gmotd) and upon logging in (the motd) and can also be sent personalized system messages upon logging in about things like impending account cancellations (lert).
- Users can submit bug reports to the appropriate channel using the sendbug command.
Miscellaneous
- /usr/sbin/sendmail is configured to inject mail through outgoing.mit.edu and to use Kerberos authentication if the user has valid tickets. The sendmail queue is flushed once an hour in case mail has to be queued locally.
- Users can see system messages in the "console".
- GNOME is configured to use applications available on Athena to open certain document types.
- Athena machines can have either a krb5 keytab or a krb4 srvtab and Kerberos daemons will use either one, preferring the keytab.
- Athena login sessions follow a complicated set of rules regarding user dotfiles.
- Users can query basic machine characteristics with the machtype command.
Design Plans For Release Features
(This section needs to be reconsidered in light of the Debathena collaboration. Package naming is off since we will be naming our packages debathena-* instead of athena-*, milestones are off since much of this stuff is already implemented in Debathena, and in some cases the plan may need to be adjusted to conform to what Debathena has done.)
In total, these design plans account for about 24 weeks of work, or about two months per developer. Additional work will be required for the installer, the updater, integration testing, and documentation.
Feature: Users can connect to the mainframe with the x3270 terminal emulator.
Current solution: The athena-x3270 package provides this software. It does not appear to be modified except for portability. There is an xlogin option to run x3270 to mitvma.mit.edu in an xterm.
Planned solution: Ensure that the native x3270 package is installed. The xlogin option will no longer be supported.
Milestone: Feature Complete (one hour)
Feature: Users can send and receive Zephyr messages.
Current solution: The athena-zephyr package provides this software, including Athena configuration and a boot script for zhm.
Planned solution: We will use the native zephyr package; however, we must continue maintaining the Zephyr source code (if only minimally) since Ubuntu treats MIT as the upstream maintainer. A new debathena-zephyr-config package will provide Athena configuration files.
Milestone: Basic (one day).
Feature: Users can browse the web with Firefox, which is preconfigured with the MIT CA, a local filesystem path for its disk cache, and the Java and Flash plugins.
Current solution: We use the native Red Hat Firefox package. The athena-firefox-extension package installs a Firefox extension making the MIT-local customizations, and the athena-firefox-wrapper package installs a front-end script in /usr/athena/bin/firefox which performs some customizations and setup.
Planned solution: Same general plan. However, debathena-firefox-extension's packaging materials will likely need to be adjusted for Ubuntu, and debathena-firefox-wrapper will need to use a dpkg diversion on /usr/bin/firefox since we don't have a /usr/athena/bin in the path to play with. Alternatively, we could overwrite /etc/firefox/firefoxrc which is sourced by the native /usr/bin/firefox.
Ubuntu makes the Java plugin available (after the sun-java packages are installed) without the user having to manually set the plugin path. We should determine how this is done; it should make some of our wrapper script logic unnecessary.
Milestone: Basic (one week).
Feature: Users can easily connect to the MIT Chat service with Gaim, and in addition can use the gaim-encryption plugin for end-to-end message encryption.
Current solution: The athena-gaim package provides a Gaim 1.5 built with GSSAPI support and some bugfixes. The athena-gaim-encryption package includes the encryption plugin.
Planned solution: Ensure that the native pidgin, pidgin-encryption, and libsasl2-modules-gssapi-mit packages are installed. If necessary, modify the native pidgin package to work around an Openfire authentication bug if that has not been resolved on the server side.
Milestone: Basic (one day).
Feature: Users can easily read MIT mail using Evolution or Pine.
Current solution: The athena-evolution and athena-evolution-data-server packages provide Evolution, and the athena-pine package provides Pine. (Unfinished.)
Planned solution: (Unfinished.)
Milestone: Basic (three weeks).
Feature: Users can read archives in Discuss.
Current solution: The athena-discuss and athena-xdsc packages provide the Discuss software and an X front end.
Planned solution: No change.
Milestone: Basic (none).
Feature: Users have access to a rich C development environment as well as basic installations of Perl, Python, and Java.
Current solution: We install the RHEL 4 C development environment and a selection of development packages. We install our own builds of Perl 5.8.3 and Python 2.3.3. We install a JDK RPM from Sun. The athena-ws package ensures that /usr/java/jdk is a symlink to the most recent JDK directory. Our Firefox wrapper script includes the Java plugin directory in the plugin path.
Planned solution: Ensure that build-essential and native GNOME development packages are installed. Perl and Python are installed by default. Ensure that the sun-java6 packages are installed. Ubuntu sets up /usr/lib/jvm/java-6-sun along the same lines as our /usr/java/jdk so we won't have to do that ourselves.
Milestone: Core (one day).
Feature: Users have access to a variety of non-standard utilities (jot, lam, saferm, etc.).
Current solution: We build each of these from small independent source trees: cxref, dent, hostinfo, just, saferm, syncupdate, jot, lam, and rs. jot, lam, and rs are imports from NetBSD (they live in third/) while the others are treated as original source code.
Planned solution: We can use the athena-jot package (which is an upstream Ubuntu package despite the name), but other than that, no change. These utilities do not have Ubuntu equivalents. Some of them are probably never used, but it's too hard to measure which ones and too easy to just keep building them.
Milestone: Feature Complete (one hour).
Feature: Users can print to Athena network printers with the lpr command and from applications which support printing.
Current solution: athena-lprng-misc, athena-ifhp, and athena-lprng provide this functionality. lprng has been extensively modified for Kerberos authentication and Hesiod support. (Unfinished.)
Planned solution: Cluster printers no longer require Kerberos authentication, though other Athena printers do. Authentication is also required in order to be able to remove print jobs from a different location than they were submitted. (Unfinished.)
Milestone: Feature Complete (three weeks). If time is short, we can defer rearchitecting printing and deploy the existing code base with a work estimate of three days.
Feature: Users have access to the enscript command to format text documents into postscript for printing.
Current solution: The athena-enscript command provides this functionality, which we used to get from Transcript (a commercial tool from Adobe). athena-glue installs attach-and-run scripts for the other Transcript utilites which are installed in the psutils locker: afmdit, pscat, pscatmap, psdit, psdraft, pslpr, psnup, psplot, psrev, and psroff.
Planned solution: Ensure that the native enscript and psutils packages are installed; that gets us enscript and psnup, the most commonly used utilities. A new package debathena-transcript-glue will install attach-and-run scripts for the remaining commands.
Milestone: Feature Complete (one day).
Feature: Users can run emacs with Athena site customizations.
Current solution: athena-emacs provides this functionality, including the Athena site-start file. Although we have some source-level customizations to emacs, none of them appear important any more.
Planned solution: Ensure that the native emacs package is installed. A new package debathena-emacs-config will install our site-start file into /etc/emacs/site-start.d.
Milestone: Basic (one day).
Feature: Users can conduct single sign-on logins to other Athena machines (provided they have a keytab and are configured for remote access) or compatible non-Athena machines via kerberized ssh, telnet, rlogin, or ftp.
Current solution: The athena-ssh package provides ssh and sshd. The upstream openssh.org source code has been customized with GSSAPI key exchange support, libal support, krb524 conversion of delegated credentials, access_on/access_off support, AFS PAG creation support, denial of GSSAPI-authenticated logins without delegated credentials, a change to make sshd work when invoked simply as "sshd" without an absolute path, syslogging of root logins, and creation of a directory in /tmp to put Xauthority files to prevent them from living in AFS.
The athena-krb5 package provides kerberized telnet, rlogin, rsh, and ftp daemons. Each are customized with libal support. The athena-inetd package is configured to allow access to these daemons.
Planned solution: Kerberized telnet, rlogin, rsh, and possibly ftp should be deprecated in favor of ssh. The Athena 10 release will include clients but not servers for those functions. (Unfinished.)
Milestone: Feature Complete (one week).
Feature: Users can query and manipulate IMAP mail stores with the mailquota, mailusage, from, and mitmail* commands.
Current solution: The athena-from, athena-mailquota, athena-mailusage, and athena-mitmail* packages provide these programs. They are based on the athena-cyrus-imapd package, which is a build of Cyrus IMAPD 2.2.3 with some bug fixes.
Planned solution: Use the native Cyrus packages; otherwise no change. Testing will be required to ensure that the native Cyrus packages have all the required bug fixes.
Milestone: Feature Complete (two days).
Feature: Users can access and run software from AFS lockers through /mit paths via "attach", "add", "setup", and related commands. Home directories are also treated as lockers.
Current solution: The athena-locker, athena-libathdir, athena-attach, athena-quota, athena-attachandrun, athena-athdir, athena-athrun, and athena-gathrun packages provide most of this functionality. The standard dotfiles define the "add" and "setup" commands. The athena-zephyr package is configured to invoke zinit at zwgc startup time, causing users to get zephyr messages about outages of filesystems they have attached lockers on.
Planned solution: All of the above packages will continue to be in the release, but the liblocker logic to actually mount filesystems will be removed. A new package athena-autofs-config will configure autofs to mount hesiod filesystems in /mit. Ensure that autofs and autofs-hesiod are installed.
Milestone: Core (one week).
Feature: Users can use a network-enabled replacement for "write" between machines.
Current solution: The athena-write and athena-writed packages provide the client and server. The athena-inetd package is configured to allow access to the daemon.
Planned solution: Desupport this feature.
Milestone: None.
Feature: Users can query Athena hesiod information with the hesinfo command.
Current solution: The athena-hesinfo package provides this command.
Planned solution: Ensure that the native hesiod package is installed.
Milestone: Basic (one hour).
Feature: Users can spell-check documents using the ispell command.
Current solution: The athena-ispell package provides this command. The Linux works has mostly moved over to aspell, but some of our documentation refers to ispell and our Emacs site-start file also refers to it.
Planned solution: Ensure that the native ispell and ispell-dictionary packages are installed. aspell is installed by default, but ensure that aspell-dictionary is installed for more languages.
Milestone: Feature Complete (one hour).
Feature: Users can pull down MIT mail with the emacs movemail command (currently uses kpop).
Current solution: The athena-emacs package is built with Hesiod and KPOP support in its movemail command, which is used by emacs rmail. It has also been locally modified to install a symlink from /usr/athena/bin/movemail to the internal location of the movemail program; however, the need for this symlink is no longer present (it was used by Pine and Netscape ten years ago, but no longer).
Planned solution: The Ubuntu emacs package is not built with Hesiod and KPOP support in movemail. Some users still use emacs rmail, so we either need to locally modify the Debian package to build movemail differently, or install the native mailutils package, configure it to work with the PO servers, and point emacs at it in our site-start file. Alternatively, we could desupport this way of reading mail, though we know a few people still use it.
Milestone: Feature Complete (one week, maybe less).
Feature: Athena machines have a selection of international fonts installed.
Current solution: The athena-intlfonts package provides these fonts.
Planned solution: Ensure that the native emacs-intl-fonts package is installed.
Milestone: Feature Complete (one hour).
Feature: Users can talk to serial devices using kermit.
Current solution: The athena-kermit package provides a build of kermit 8.0.
Planned solution: Ensure that the native ckermit package is installed.
Milestone: Feature Complete (one hour).
Feature: Users can process TeX and LaTeX documents.
Current solution: The athena-tetex package contains a build of teTeX 2.0.2. The package installs a few extra control files to support printing duplex, tumble, or in the bottom tray, and also installs a "listing" style. The Athena stock answers refer to the duplex and tumble printing options.
Planned solution: Ensure that the native tetex and tetex-extra packages are installed. A new package debathena-tetex-extras will install the nonstandard extensions.
Milestone: Feature Complete (one hour).
Feature: Athena machines can access Windows file shares using a Kerberos-enabled smbclient which is pre-configured for the win.mit.edu realm.
Current solution: The athena-samba package contains a build of Samba 3.0.2a built with Kerberos, along with a boot script and some configuration files.
Planned solution: Ensure that the native smbclient package is installed. A new package debathena-smbclient-config will point it at the win.mit.edu domain.
Milestone: Feature Complete (one day).
Feature: Athena machines have attach-and-run scripts in the default path for various bits of locker software such as the Moira tools.
Current solution: The athena-glue package installs attach-and-run scripts as well as man page symlinks (in some cases) for the Moira utilities, the Transcript utilities, acroread, Ghostscript, Ghostview, lastlog (a consult locker tool), OpenOffice, MIME utilities, realplay, ivview, freewrl, and tellme. The MIME utilities are custom-written scripts and are referred to by our nmh configuration.
Planned solution: Ensure that the native gv package is installed. OpenOffice and Ghostscript should be installed by default. New packages debathena-transcript-glue, debathena-mimeutils-glue, debathena-moira-glue, and debathena-misc-glue will install the remaining attach-and-run scripts and man page symlinks.
Milestone: Feature Complete (one day).
Feature: Athena users can run an old desktop interface based on dash and mwm instead of GNOME if they have opted to do so.
Current solution: The athena-dash package provides the dash software, as well as a set of fallback software menus in /usr/athena/lib/Dash.fallback and a symlink to the (theoretically but not actually) maintained-in-AFS menus in /usr/athena/lib/Dash.menus. We use the native RHEL 4 mwm from the openmotif package, but the athena-ws package installs a /usr/lib/X11/system.mwmrc.athena file and overwrites the standard configuration file with it. xlogin has an option to log in with the dash interface. The athena-revert-to-dash package provides a dialog which will create ~/.athena_dash_interface, and the standard Athena GNOME system menu has an entry to run this program. The xsession in the athena-dotfiles package has conditional logic to honor these indications and invoke mwm and dash instead of GNOME software.
Planned solution: Continue to provide debathena-dash since it's cheap to do so. Provide an debathena-mwm-config to overwrite the system mwm configuration. Continue to honor ~/.athena_dash_interface. Eliminate revert-to-dash and the dash login option.
Milestone: Feature Complete (one day).
Feature: Athena users can elect to run Sawfish (an outdated GNOME window manager) instead of Metacity.
Current solution: The athena-sawfish package provides a build of Sawfish 1.2-gtk2, customized with a number of bugfixes, an Athena site-init file, and the Eazel theme. The xsession in the athena-dotfiles package uses sawfish if ~/.athena-sawfish exists. The athena-dotfiles package installs a script to display a dialog about reverting to sawfish, and the standard Athena GNOME system menu has an entry to run this script. At present count there are 126 publically listable AFS home directories with the .athena-sawfish file in them; the usage levels of thouse accounts are unknown.
Planned solution: Desupport this option. If we receive pushback, we can support it by ensuring that the native sawfish package is supporting and installing a site-init file via a new package debathena-sawfish-config.
Milestone: None.
Feature: Users can read mail with the nmh command suite (currently uses kpop).
Current solution: The athena-nmh package provides a build of nmh 1.0. (Unfinished.)
Planned solution: (Unfinished.)
Milestone: Feature Complete (two weeks, maybe less).
Feature: Users can browse the web with Mozilla instead of Firefox. Mozilla can also be used to read mail and edit HTML files.
Current solution: The athena-mozilla package provides this software. We have never officially supported Mozilla as a mail client, though we do know that some people use it.
Planned solution: Desupport this. Ensure that the native mozilla-thunderbird package is installed for people who want to use a Mozilla mail client.
Milestone: Feature Complete (one hour).
Feature: Any MIT user can log into cluster machines using their Kerberos passwords and their AFS home directories.
Current solution: The athena-libal package provides a library which contains code to create passwd and group entries for users as they log in and attach user home directories. The athena-xlogin, athena-openssh, and athena-krb5 packages contain modified versions of the various login programs (graphical, text console, and remote daemons) which are customized to use krb5 authentication, to get krb4 tickets, to invoke libal session creation, and to create an AFS PAG for the login session. Non-transient passwd and group entries are stored in /etc/passwd.local, /etc/shadow.local, and /etc/group.local. In the athena-ws package, the athena-ws boot script overwrites the current passwd/group files with those files at boot time, the reactivate script overwrites them between graphical logins if no one else is logged in. The public workstation verification script also references those files.
Planned solution: athena-libal will go away. A new package debathena-pam-config will set up the PAM configuration to use krb5 authentication, create krb4 tickets, and create an AFS PAG for each login session. A new package debathena-nsswitch-config will set up the nsswitch configuration to use Hesiod for users and groups, making use of Debathena's libnss_nonlocal for improved security. Since the login system will no longer be modifying the passwd and group files, the .local versions of those files will no longer be part of the model and will be removed during the update process.
Milestone: Core (one week, due to previous prototyping effort).
Feature: Root logins on cluster machines are not permitted, but users can su to root once they log in as themselves.
Current solution: On cluster machines, the root password is set to a value which can be discovered by the tellme command (a symlink into AFS installed by athena-glue). To prohibit root logins, the athena-ws boot script in the athena-ws package creates /etc/noroot on machines which are part of the "cluster" Hesiod cluster. The athena-libal package denies root login access if this file exists.
Planned solution: The debathena-pam-config package will handle this by creating an /etc/pam.d/deny-root file which is included by the main system login configuration. A boot script in the debathena-pam-config package will populate this file with a PAM directive to deny root logins if the machine is part of the "cluster" cluster.
Milestone: Cluster (one day).
Feature: Users can change their Kerberos passwords with the passwd command.
Current solution: The athena-passwd package provides a /usr/athena/bin/passwd command which uses libal to determine whether the current user is a local account and runs kpasswd (from athena-krb5) or /usr/bin/passwd as appropriate.
Planned solution: The debathena-pam-config package will configure password changing to use krb5 for non-system uids. The passwd program will change both the local and Kerberos passwords.
Milestone: Core (one day).
Feature: Private machine admins can configure who can log into machines remotely and locally with the /etc/athena/access file. They can also tag accounts as "local" and not part of the Hesiod/AFS namespace.
Current solution: The login library in the athena-libal package parses /etc/athena/access and will deny access to accounts when appropriate. It also tells the calling application if the account is tagged as local; if so, the login program will suppress all Athena login activities (getting Kerberos tickets, creating a session entry, attaching the homedir).
Planned solution: The debathena-pam-config package will configure pam_access as part of the login sequence. The update from 9.4 will rewrite /etc/athena/access to /etc/security/access.conf. Local account tagging will be desupported unless we think of a clever way to do it. Users who wish to use Athena software with a privately-owned machine will generally not install the debathena-pam-config package. Also, it shouldn't be as necessary with the new login architecture; all it would really do is suppress the attempt to get Kerberos tickets.
Milestone: Core (two days).
Feature: Athena machines tagged as quickstations display a timer and nagging warnings to log out after a set period of time.
Current solution: The athena-bugme package displays the timer and the nagging warnings for quickstations. The Xsession script in the athena-dotfiles package invokes bugme.
Planned solution: No change, except that the Xsession script should move to debathena-gdm-config. The bugme program will need to be tested for interference with gnome-session; there is already a bug report filed against it for interference with the screensaver in bugs 27097.
Milestone: Cluster (one day).
Feature: Users can temporarily enable and disable remote access daemons on Athena machines with the access_on and access_off commands, if the machine is configured to allow this.
Current solution: The athena-inetd package contains a modified version of inetd which will respond to SIGUSR1 by turning on access to daemons marked as "switched" and to SIGUSR2 by turning off access. The boot script in that package invokes inetd with the -n option if /etc/athena/rc.conf has ACCESSON set to true, instructing inetd to turn those services on initially. The athena-openssh package has the sshd daemon customized to honor SIGUSR1 and SIGUSR2 if sshd is invoked with the -s or -S options. The boot script in that package invokes sshd with one of those options if /etc/athena/rc.conf has SSHD set to "switched". (Which option is sent depends on the value of ACCESSON and determines whether sshd is active or inactive initially.) The athena-access package contains a setuid program which sends SIGUSR1 or SIGUSR2 to inetd and sshd depending on whether it is invoked as access_on or access_off.
Planned solution: Desupport this feature.
Milestone: None.
Feature: GNOME Bonobo components from one login session will not be reused in another login session because they may not have access to the same tickets and tokens. There is similar isolation for gconfd-2 for the same reason.
Current solution: The athena-ORBit2 and athena-ORBit packages are locally modified to honor the ATHENA_SESSION_TMPDIR variable and use that instead of /tmp/orbit- for ORBit communication files. The Xsession script in athena-dotfiles creates a temporary directory (using a shell script named mksessiondir included in the same package) and sets ATHENA_SESSION_TMPDIR to point to it. This serves to create a separate universe of ORBit-enabled applications (including Bonobo components) for each login session. A similar local modification exists for athena-GConf2 and athena-GConf.
Planned solution: Bonobo components or gconfd daemons can most easily be reused if they erroneously persist beyond logout, but they can also be reused in other cases. For example, someone could have logged in remotely to an Athena machine from elsewhere, run a GNOME program sch as Evolution, and left the login session around (with expired tickets and tokens) before attempting to log in locally. Although the corner cases may be rare enough to warrant moving this to the low-priority list, nothing appears to have removed the need for this feature, and there does not appear to be any upstream equivalent to the ATHENA_SESSION_TMPDIR features we have added to ORBit and GConf. We will have to use the framework for modifying Debian packages to enable this, although we can ignore the GNOME 1 libraries. We should probably submit enhancement requests with patches to the upstream GConf2 and ORBit2 maintainers in order to get away from requiring source modifications of those components, although the enhancements may or may not be accepted.
Milestone: Cluster (three days).
Feature: Users can log in simultaneously from multiple machines without running afoul of GNOME software locks in the home directory.
Current solution: (Unfinished.)
Planned solution: (Unfinished.)
Milestone: Cluster (three days).
Feature: If a user's home directory is unavailable upon login, a temporary homedir will be created on local disk and used instead.
Current solution: The login library in the athena-libal package checks if "attach" succeeds and that the resulting home directory is readable. If not, it synthesizes a local home directory and rewrites the local passwd entry to point to it. The passwd entry will be reverted on a future login attempt if attach succeeds.
Planned solution: Desupport this feature. It's a good feature but we want to get away from customizing the login system code, and there's no way to make it work without doing that. Instead, the Xsession script in debathena-gdm-config should check for an inaccessible home directory and present a fallback UI such as an xterm which will let the user input commands.
Milestone: Feature Complete (one day).
Feature: Users can log in with "ignore customizations" or in terminal mode to repair severely broken dotfiles.
Current solution: The athena-xlogin package includes an "ignore customizations" login option, which causes the Xsession script in the athena-dotfiles package to be invoked with the argument "2". Xsession responds to this argument by ignoring $HOME/.xsession files and invoking the central xsession script (also in athena-dotfiles) with the -nocalls flag. The xsession script responds to this flag by setting the NOCALLS environment variable and forcing SHELL to /bin/athena/tcsh. Athena dotfiles will typically do their best to ignore user dotfiles when NOCALLS is set. The athena-GConf and athena-GConf2 packages are modified to honor NOCALLS by substituting a temporary directory when evaluating $(HOME) in the configuration source paths. The athena-gnome-libs package (a GNOME 1 library package) also contains a change to honor NOCALLS, but that change does not appear to have propagated into the corresponding GNOME 2 package--which makes some sense since most GNOME 2 software uses GConf2 rather than the outdated gnome_config API.
Planned solution: If we are making source-level modifications to GConf2 anyway, then this is a relatively easy feature to support. debathena-gdm-config will include an "ignore" desktop (we've prototyped this in prior 9.9 work) and the dotfiles will continue to respect NOCALLS in the same manner. If this ever becomes the last source-level modification we are making to GConf2, we should desupport that side of the feature.
Milestone: Cluster (one day).
Feature: User processes generated by Athena software components do not stick around after the user logs out. On cluster machines, user processes are forcibly killed after the user logs out.
Current solution: The athena-dustbuster package provides a program which runs a command in a child process and terminates the process when it detects that the current login session has ended. The athena-esound, aathena-GConf, athena-GConf2, athena-oaf, and athena-bonobo-activation packages are locally modified to invoke subprocesses under dustbuster so that they don't survive a logout.
Planned solution: Using the GNOME session manager should fix most of our issues with components surviving a logout. Our biggest problem in the past was that gconfd-2 was surviving a logout due to a race condition in the shutdown process (gnome-panel was managing to cause a restart of gconfd-2 after the manual shutdown in the Xsession script); that goes away with a properly ordered shutdown. So we should be able to discard all of this machinery.
Milestone: None.
Feature: Athena machines have a screensaver which accepts a Kerberos password to unlock and which allows the user to be logged out after a set time.
Current solution: The athena-xscreensaver package contains a build of xscreensaver 4.14, heavily customized. For historical reasons, symlinks to the xscreensaver commands from xss, xss-command, and xss-demo are added. We have added a new command xscreensaver-button (with a symlink xss-button) to present a simple UI for locking the screen. We have added an option to let people log the user out after the screen has been locked for a specified amount of time; forcible logouts also send syslogs in an effort to detect cluster abuse. We have trimmed the number of screen hacks to a bare minimum because man of them were triggering X server bugs on Solaris. We have added an option to let people specify an encrypted screensaver password to use in preference to the account password. We have added a -start-locked option to make the screensaver start out locked and exit when the screen is unlocked, like the old xlock command works. We have added options to specify commands to run when the screen is locked or unlocked. We have removed support for unlocking the screen using the root password. We have added a feature to allow Kerberos ticket renewal using the password entered to unlock the screen.
In addition, the athena-glue package provides an xlock script which will successfully lock the screen whether or not the xscreensaver daemon is running. It was originally written to prevent people from running the native "xlock" command which behaved in inappropriate ways on cluster machines.
Planned solution: Remove the athena-xscreensaver package. A new debathena-xlock package will provide the xlock script, which will just be an alias for "gnome-screensaver-command -l". The debathena-pam-config package will configure the screensaver to unlock the screen with the user's Kerberos password. A new debathena-screensaver-config package will set up system GConf defaults to configure gnome-screensaver to disable user switching and to allow the user to be logged out after the screen has been saved for a set length of time. All other special features of the Athena screensaver will be desupported as they would require local code modifications.
Milestone: Cluster (one day).
Feature: GNOME won't display a dialog about changes in X keyboard settings from one login to another, since the same account is used on multiple machines.
Current solution: The athena-control-center package is customized to disable this dialog.
Planned solution: The dialog still exists in current GNOME code; however, it will come up much less often with only one platform, and it now contains an option to suppress itself, so it should only bother users once if it happens at all. So we should not need to propagate this change.
Milestone: None.
Feature: Basic GNOME functions will work when the user's home directory is inaccessible (such as when the user's AFS tokens have expired) or is over quota.
Current solution: The athena-gnome-desktop package is customized to make launchers work when the home directory is inaccessible. The athena-libgnome package is customized to make gnome_init() work when the home directory cannot be written to.
Planned solution: These problems still exist in current code. However, if the system Xsession detects an inaccessible homedir and throws up an xterm for repair, we can probably get away without making the code modifications.
Milestone: (Accounted for in temporary home directory feature).
Feature: GNOME's trash handling has fixes for Athena home directories.
Current solution: The athena-gnome-vfs2 package is locally modified with a change to make trash handling work when the homedir is a symlink to a directory on another device and to support moving files between devices in the gnome_vfs_xfer function.
Planned solution: It looks like we will be forced to make a similar change to the native libgnomevfs2 package, since this still appears to be a problem in upstream code. We should try to get a fix into GNOME to resolve this problem upstream.
Milestone: Feature Complete (one day for local fix, another for upstream patch submission).
Feature: Athena machines can be queried via athinfo for various bits of information.
Current solution: The athena-athinfo package provides the client software. The athena-athinfod package provides the daemon and default configuration files (athinfo.access, athinfo.defs). The athena-inetd package contains configuration to make the Athena inetd answer on the athinfod port.
Planned solution: The debathena-athinfod package will install stub configuration files, which will be kept in athena/etc/athinfod rather than packs/config. A new Ubuntu-specific package debathena-athinfod-config will install the actual Athena athinfo.defs and will take care of making athinfod network-accessible (unfinished). The athinfo.defs file may need to be updated for Ubuntu.
Milestone: Cluster (one day).
Feature: Athena machines record a history of their patch release numbers and dates of each update.
Current solution: The athena-base package inaugurates the /etc/athena/version file. The update and mkserv scripts write entries to the file.
Planned solution: The version feature will only be used for full release updates (e.g. 9.4 to 10.0) since we will no longer be using a patch release model for individual package updates.
Milestone: (Accounted for in installer and updater tasks).
Feature: Athena machines forward some syslog notices to a central host for monitoring purposes.
Current solution: The athena-ws package installs a syslog.conf file which (via a scriptlet) overwrites the stock syslog.conf file.
Planned solution: A new debathena-syslog-config package will overwrite the stock syslog.conf file.
Milestone: Cluster (one day).
Feature: Athena machines send information about whether they are in use to a "larvnetd" daemon on a central host which can be queried using the cview and xcluster commands.
Current solution: The athena-xlogin package contains calls to liblarv (in the athena-larv package) which creates or removes a flag file (/var/athena/busy) and sends a UDP status packet to a machine determined by the larvnet Hesiod sloc record. The athena-busyd package provides a UDP daemon which responds to poll requests based on the presence of the flag file, and the athena-inetd package makes the busyd daemon available. On the server end, the athena-larvnetd package contains a program to receive status packets, do periodic polling of cluster machines and printers, and write out reports. The athena-cviewd, athena-cview, and athena-xcluster packages provide server and client programs for retrieving and displaying those reports.
Planned solution: The Xsession script in the debathena-gdm-config package will take care of setting the flag file and sending the status packet, probably using nc. The debathena-busyd-config package will take care of making the busyd daemon available. (Unfinished.)
Milestone: Cluster (one day).
Feature: Athena machines report centrally about their existence, machine type, and version so that they can be counted.
Current solution: The athena-ws package installs a script /etc/athena/counterlog to do the actual logging, a cron job to run it every hour (desynchronized), and a line in the athena-ws.rc script to run it at boot time.
Planned solution: A new package debathena-counterlog will install the script, the cron job, and a boot script to run it.
Milestone: Cluster (one day).
Feature: Athena machines respond to requests on the "time" and "daytime" ports with their idea of the current time.
Current solution: The athena-inetd package is configured to answer on the time and daytime ports. The daemon code is built into inetd.
Planned solution: Desupport this feature.
Milestone: None.
Feature: Athena machines have filesystem-level access to AFS.
Current solution: The installer creates a separate disk partition for the AFS cache. The athena-openafs package contains a build of OpenAFS 1.4.4. It also contains a script /etc/athena/config_afs to set up cell locations, setuid cells, and cell aliases using files in /afs/athena.mit.edu/service and a customized init script which recreates the cache partition if it won't fsck cleanly and then mounts it. We rebuild the athena-openafs package each time the kernel changes so that the kernel module matches the kernel version. The athena-afs-krb5 package contains an aklog program which can get tokens using a Kerberos credentials cache.
Planned solution: (Unfinished.)
Milestone: Core (one week).
Feature: Athena machines periodically clean up files in temporary areas to avoid slowly filling the disk.
Current solution: The athena-ws package installs a script in /etc/athena/clean_tmp_areas which removes old files in temporary areas if they are not owned by logged-in users. It also installs a cron job to run the script once a day. It also contains code in the boot and reactivate scripts to clean specific kinds of files which only pertain to logged in users, such as /tmp/session-* directories used by our GConf modifications.
Planned solution: A new package debathena-tmp-cleaner will install the script and cron job.
Milestone: Cluster (one day).
Feature: Athena machines automatically take updates when we put out new releases.
Current solution: The athena-ws package installs a script /etc/athena/update_ws which is invoked by the boot and reactivate scripts. update_ws runs a script out of the sysprefix area (determined by the machine's Hesiod cluster information) which checks for a new numbered patch release and invokes rpmupdate from the athena-rpmupdate package to update the machine's RPM set to a new version.
Planned solution: (Unfinished.)
Milestone: Core (one week).
Feature: Athena machines have a consistent set of native platform packages installed, which is a superset of the default package set.
Current solution: In the release area in AFS, the list-9.4.X files contain a list of pathnames of RHEL 4 packages. When we want to add or remove a native package in a patch release, we simply include it or omit it from the list file for that patch, and rpmupdate adds or removes the RPM during the update. Non-included RHEL 4 packages are listed in the upgrade-9.4.X file; rpmupdate will upgrade these packages if they are locally installed on a private machine, but will not install them.
Planned solution: A new package debathena-packages-native will act as a metapackage to ensure the local installation of operating system packages we want installed. (Unfinished.)
Milestone: Core (one day).
Feature: Athena machines can be flagged as "public", which implies that they have no persistent data or customizations and can engage in more aggressive cleanup activities.
Current solution: The athena-ws package inaugurates the PUBLIC variable into /etc/athena/rc.conf. The package value defaults to false, but our installer will set it to true if the user does not customize the rc.conf values. The specific changes enabled by setting PUBLIC are:
- athinfod allows remote viewing of the update.log file.
- The athena-ws boot script performs hardware-specific configuration maintenance when appropriate, such as adjusting the X configuration. (Specific examples at the current time are probably irrelevant due to the change in base operating system.)
- The athena-ws boot script removes any installed ssh host keys.
- The athena-ws boot script removes any files named *.local in /etc, /etc/athena, or /etc/athena/login.
- The athena-ws boot script removes Mozilla cache directories in /var/tmp.
- The athena-ws boot script removes configuration files and other files which shouldn't exist, and adjusts the mode of /etc/shadow.
- The athena-ws boot script does not preserve the contents of /etc/motd (normally it rewrites the original line but keeps the remaining contents.
- The public workstation verification script will operate (normally it will refuse to run) and runs at boot time.
- The reactivate script does not check for running screen processes before performing cleanup.
- The reactivate script performs a "full" reactivation (additional, slower cleanup) between each login instead of just when it runs from the cron job.
- The reactivate script erases all files in /tmp as well as all temporary home directories.
- The reactivate script copies the local passwd, athinfo.access, and local-lockers.conf file from a directory in AFS.
- The reactivate script removes any installed ssh host keys.
- The update script (run out of AFS) passes the -p option to rpmupdate, causing it not to honor local changes to the installed RPM set.
Planned solution: Since rc.conf is going away, we will use the file /etc/default/athena-public to control whether the machine is considered public. The particular actions listed above will be cleaned up a bit but will mostly remain as part of the debathena-verification package.
Milestone: Cluster (two days).
Feature: The default GNOME panel setup contains a menu of important Athena locker software (currently unmaintained). For performance reasons, the files representing this menu must be stored on local disk.
Current solution: The athena-dotfiles package installs gnome-panel default schemas which include a menu object pointing to /var/athena/menus. It also installs a symlink /usr/athena/share/gnome/athena/menus pointing into AFS. The athena-ws package includes a script /etc/athena/local-menus which is invoked from the reactivate and boot scripts. The local-menus script copies a tar file out of AFS if a new one exists, and then untars it locally into /var/athena/menus. If the process fails, /var/athena/menus is directly symlinked into an untarred menu directory in AFS, which will yield poor performance but is correct.
Planned solution: (Unfinished.)
Milestone: Basic (two days).
Feature: Some lockers containing frequently-used software are stored on local disk for performance reasons.
Current solution: The athena-athlsync package contains a program which can efficiently synchronize a locker to local disk while translating AFS-specific path features. The athena-ws package includes a script /etc/athena/local-lockers and a cron job to invoke it every day between 3:30am and 7:30am. The local-lockers script uses athlsync to synchronize lockers to /var/athena/local and sets up a symlink in /var/athena/local-validated for those lockers which were successfully synchronized. The athena-liblocker package contains logic to look for a directory in /var/athena/local-validated when attaching a locker and to use that in preference to the network copy.
Planned solution: Desupport this feature. It would be difficult, though possible, to make it work with autofs. Right now we are only using it for OpenOffice and Acrobat. We can use the native OpenOffice installation for document processing and natively provided PDF tools for casual PDF browsing.
Milestone: None.
Feature: Cluster machines perform some self-integrity checking to repair accidental and casual changes to their configurations.
Current solution: The athena-ws package includes a script /etc/athena/verify which is invoked from the boot script. The verify script uses rpmupdate to synchronize the locally installed RPM set with the current release list, and then checks for files which differ from their RPM checksums and reinstalls any affected RPMs. A specific set of configuration files is also copied in from an area in AFS in case they have been changed.
Planned solution: (Unfinished.)
Milestone: Cluster (three days).
Feature: Athena machines may be part of a Hesiod "cluster" which can determine whether they take beta updates, whether they are cluster/quickstation machines, and what their default printers are.
Current solution: The athena-getcluster package contains a program which queries Hesiod for cluster information and writes out C shell or Bourne shell commands to set environment variables. The athena-ws package installs a script in /etc/athena/save_cluster_info which invokes getcluster to update files in /var/athena containing the environment variable settings. save_cluster_info is invoked by the boot athena reactivate scripts, and is also invoked by update_ws just to make sure. The resulting files are used by the boot script, the update script, the verification script, and the Athena dotfiles.
Planned solution: A new package debathena-clusterinfo will contain the save_cluster_info script and a boot script to invoke it. The debathena-getcluster package will remain.
Milestone: Core (one day).
Feature: Particular aspects of Athena machines can be configured by editing /etc/athena/rc.conf.
Current solution: The athena-base package (required by all other packages) contains the initial rc.conf file, which contains no variables. Each package which respects a variable will "inaugurate" that variable value into rc.conf with its default value at installation time, and will honor the variable value by sourcing /etc/athena/rc.conf in (usually) the package's included boot script. The list of packages using this mechanism is: athstatusd, glue, ined, lprng, ntp, olc, openafs, openssh, samba, sendmail, ws, and zephyr.
Planned solution: Desupport this feature. Since we will no longer be a multi-platform environment, we should not be layering our own configuration mechanism on top of the native IP address configuration, and we should be using standard mechanisms (files in /etc/default) for configuring when our own software runs at boot time or determining whether a workstation is considered public.
Milestone: Cluster (one day).
Feature: Cluster machines use static IP addresses and have an easy procedure for changing IP addresses when they are moved to different subnets.
Current solution: The athena-ws package inaugurates HOST, ADDR, and NETDEV variables into /etc/athena/rc.conf. Their values are initially determined at install time. The syncconf boot script runs /etc/athena/syncconf (both are from the athena-ws package) which rewrites the appropriate network configuration scripts when those variable values change. An ADDR value of dhcp indicates the use of a dynamic address.
Planned solution: Desupport this mechanism and use standard native mechanisms for reconfiguring machines' IP addresses. This will require a certain amount of retraining of ACIS personnel.
Milestone: (Accounted for in installer and updater tasks).
Feature: Cluster machines run a local name server and are configured to use it to cache name lookup results.
Current solution: The athena-bind package provides a build of BIND 9.3.1 and a script to run the daemon at boot time. It also includes an /etc/resolv.conf file (which, oddly, is not owned by any system RPM) pointing libc name resolution requests at the local named and setting a search domain of MIT.EDU.
Planned solution: Desupport this feature. Use the MIT name servers directly from resolv.conf instead.
Milestone: (Accounted for in installer and updater tasks).
Feature: Admins can enable various nework services with the "mkserv" command; the most popular of these is "mkserv remote" to permanently enable remote access daemons.
Current solution: The athena-glue package installs an attach-and-run script for mkserv and man page symlinks. The update script invokes "mkserv updatetest" before an update to check if all services are available for the new version, and "mkserv update" afterwards. The mkserv locker software contains code to bring parts of /usr/athena onto local disk (no longer used since /usr/athena is already local), to change values in rc.conf, and to run service-specific action scripts when services are added and removed. Scripts to add services are re-run at each update.
Planned solution: Desupport this feature.
Milestone: None.
Feature: Athena machines almost always have the correct time as determined by time.mit.edu.
Current solution: The athena-gettime package contains a locally written utility to get the time from a remote host and optionally reset the current machine's time from a remote host. The athena-ntp package contains a build of ntp 4.1.1, along with configuration files to sync time passively from network broadcasts and a boot script to reset the time and start up ntpd. The athena-ws package sets up a cron job to reset the time twice a day using gettime if it has drifted. AFS will also attempt to keep the time synchronized to within two seconds.
Planned solution: Ensure that the native ntp and ntpdate packages are installed. A new package debathena-ntp-config will configure ntp to synchronize the time actively against time.mit.edu. AFS will continue to resync the time if NTP somehow fails. We will continue providing the debathena-gettime package for compatibility but will not use it in any of our own scripts.
Milestone: Basic (two hours).
Feature: Athena machines automatically synchronize the hardware clock following Daylight Savings Time changes.
Current solution: The athena-ws package installs a script in /etc/athena/syncclock which synchronizes the hardware clock to local time, and a cron job to run it after daylight savings transitions.
Planned solution: This mechanism exists because most of our existing time synchronization methods can fail if a machine comes up without network and with a time which is off by an hour. Configuring the native package to actively sync time against time.mit.edu should not be vulnerable to this issue, so this mechanism should not be needed. Therefore, desupport this feature unless it is found to be necessary. If it is necessary, add the script and cron job to debathena-ntp-config.
Milestone: None.
Feature: Athena users receive messages of the day prior to logging in (the gmotd) and upon logging in (the motd) and can also be sent personalized system messages upon logging in about things like impending account cancellations (lert).
Current solution: The xlogin program is configured to display the contents of /afs/athena.mit.edu/system/config/motd/login.94 prior to login. The athena-get-message, athena-gms, and athena-messaged packages contain client, library, and server software for retrieving the motd. The athena-lert package contains client and server software for retrieving the user-specific lert messages. get-message and lert are invoked from the xsession and login dotfiles in the athena-dotfiles package; the messages are displayed via Zephyr in graphical logins and to standard out in text logins.
Planned solution: The xlogin gmotd will be desupported since we are moving to gdm; Ops has indicated that they don't care about it. No change to the other messages.
Milestone: None.
Feature: Users can submit bug reports to the appropriate channel using the sendbug command.
Current solution: The athena-sendbug package contains the sendbug script. The message is composed in emacs and submitted using nmh commands.
Planned solution: No change. The script badly needs to be rewritten to use modern tools, but that is neither trivial nor relevant to the Athena 10 goals.
Milestone: None.
Feature: /usr/sbin/sendmail is configured to inject mail through outgoing.mit.edu and to use Kerberos authentication if the user has valid tickets. The sendmail queue is flushed once an hour in case mail has to be queued locally.
Current solution: (Unfinished.)
Planned solution: (Unfinished.)
Milestone: Basic (three days).
Feature: Users can see system messages in the "console".
Current solution: The athena-console package contains a console display program, and the athena-dm package invokes it and sends xlogin's stdout and stderr to it. The athena-config_console package contains a setuid utility which can send signals to the console to show or hide itself or reload configuration from X resources. The xsession script in the athena-dotfiles package redirects the output of GNOME programs to /dev/null to reduce console spam.
Planned solution: Desupport this feature. xsession output messages will be written to .xsession-errors in the user's home directory as is standard on Ubuntu.
Milestone: None.
Feature: GNOME is configured to use applications available on Athena to open certain document types.
Current solution: The athena-gnome-mime-data package contains a customized applications file which will run acroread, applix, gimp, gv, lynx, office, realplay, soffice, and xanim from lockers instead of locally, and also knows about htmlview, mswordview, xess, and xv. It also contains a customized keys file adjusting which applications are pointed to by certain MIME types.
Planned solution: Desupport this feature. The base OS will do a good job of viewing documents without our help at this point.
Milestone: None.
Feature: Athena machines can have either a krb5 keytab or a krb4 srvtab and Kerberos daemons will use either one, preferring the keytab.
Current solution: The athena-krb5 package is customized with support to read krb4 srvtab files and support for trying two different kinds of keytabs. The krb5.conf installed by the athena-krb5 package is configured to look in /etc/krb5.keytab first and /etc/athena/srvtab second.
Planned solution: Desupport this feature. As part of the Athena 9 to Athena 10 update, translate srvtab files to keytab files automatically if a srvtab exists and a keytab does not.
Milestone: (Accounted for in installer and updater tasks.)
Feature: Athena login sessions follow a complicated set of rules regarding user dotfiles.
Current solution: The athena-dotfiles package package installs central dotfiles in /usr/athena/lib/init, prototype user dotfiles in /usr/prototype_user, and replacement root dotfiles in /root.
Planned solution: The debathena-dotfiles package will need to be adjusted for the new development infrastructure, and will contain only the central and prototype dotfiles. A new package debathena-root-dotfiles will contain the root dotfile replacements, since those are not necessarily desirable for privately operated machines.
Milestone: Core (two days).
Feature: Users can query basic machine characteristics with the machtype command.
Current solution: The athena-machtype package installs a script in /bin/athena/machtype to answer the questions.
Planned solution: No change.
Milestone: None.
Desupported and Changed Features
This section will collate features which are desupported or changed in user-visible ways, and can serve as a basis for a similar section in the release notes.
- The login option to run x3270 to mitvma.mit.edu is no longer supported; users will have to log in and run x3270 by hand.
- The login option to use the dash interface is no longer supported, nor is the script to revert to dash. ~/.athena_dash_interface is still honored.
- The Kerberized rlogin, rsh, and telnet daemons are no longer supported. The clients are still provided.
- The network write command is no longer supported.
- The Sawfish window manager is no longer supported.
- The -k and -l options to the passwd command (to select between changing the Kerberos and local password) are no longer supported. The passwd command will always try to change both.
- The /etc/athena/access file has been replaced with the /etc/security/access.conf file. The update from Athena 9.4 will automatically rewrite /etc/athena/access to /etc/security/access.conf. The ability to tag accounts as "local" (suppressing Kerberos authentication) is no longer supported.
- The access_on and access_off commands are no longer supported.
Athena machines will no longer create temporary home directories for users whose home directories are unavailable.
- The customized Athena xscreensaver has been replaced with the default GNOME screensaver. It is still possible to log out users after 20 minutes by default. It is no longer possible to specify a separate password for the screensaver. It is possible to run commands when the screen locks or unlocks but it is substantially more complicated; google for "gnome-screensaver dbus" for more information. The xscreensaver-button command is no longer supported.
- Athena machines will no longer answer time requests on the "time" and "daytime" ports unless manually configured to do so.
- Bringing lockers local with the /etc/athena/local-lockers.conf file is no longer supported.
- The /etc/athena/version file will no longer list patch release updates since we are no longer using a patch release model. It will continue to list full release updates such as the one from 9.4 to 10.0.
- The /etc/athena/rc.conf file is no longer used to control workstation configuration. (Unfinished.)
Athena machines no longer run a local caching name server.
- The mkserv command is no longer supported.
- The xlogin global motd (displayed on the login screen before the user logs in) is no longer supported.
- Athena machines will no longer read /etc/athena/srvtab files. The update from Athena 9.4 will automatically translate /etc/athena/srvtab to /etc/krb5.keytab files if the former exists and the latter does not.