At the beginning of February 1995, Information Systems released an updated ("patch") version of the Athena System to all workstations in the Athena public clusters.
As a "patch" release, this revision does not constitute a full new release of the Athena system (the release number remains 7.7, for example), and the release mostly focuses on minor changes such as bug fixes, security enhancements, and vendor-supplied updates. However, unlike a typical "behind-the-scenes" patch release, this Athena revision does include a number of user-visible changes and system enhancements.
This document describes most of the user-visible changes in the release, including the following:
Program Developers Take Note! For developers (and, indirectly, many end users), the most significant change in the Athena 7.7 Patch release involves the introduction of a new set of conventions and tools for organizing "executables" (programs) and related development files in lockers. The scheme defining how development directories should be organized has been completely revised to be much more flexible. To support the new scheme, old tools have been revised (e.g., see add below), and new tools have been added (e.g., see athdir, which supersedes the functionality of the $bindir shell variable). All program developers are advised to pay special attention to these changes! (The new scheme is described in detail in the document Organizing Athena Development Lockers.)
For More Information About the Patch Release. For a terse -- but technical -- list of all the changes in the Athena 7.7 Patch release, including changes primarily of interest to programmers or system maintainers, see the document January 7.7 Patch Release Information.
When you log into a workstation in an Athena public cluster, the environment variable PRINTER is now created and its value is set to the name of that cluster's default printer. (This is the printer to which output from the lpr command would be sent if you did not explicitly specify a printer; not unexpectedly, the default printer is most often a printer in the cluster itself.)
This change is for the benefit of software programs (such as enscript) that do not know how to access the default printer information directly from the Athena Hesiod server, but do check the PRINTER variable. (A few programs, such as lpr, are able to communicate directly with the Hesiod server to determine what default printer to use; rather than revise the other programs, the release team decided to initialize the PRINTER variable, which in previous releases was not created by default).
One result of this change is that now, in a public cluster, a command such as
enscript filenamewill queue its output to an appropriate default printer -- without you having to explicitly specify the printer (e.g., using the -Pprinter option).
To see the current value of this environment variable (i.e., what printer it is set to), enter the following command at your athena% prompt:
echo $PRINTER
As with any environment variable set by the system during startup, you can override the default value. Simply include a command of the following form in your ~/.environment file (or at the athena% prompt, if you want to change the value for the current session only):
setenv PRINTER printer-name
The add command (actually an alias established in the system dotfiles) has been completely rewritten to include many new features, and to support the new locker directory conventions. (See the Organizing Athena Development Lockers document for details of the new directory scheme.)
The most visible changes for end-users is that add can now accept multiple locker names in a single command, and that add with no arguments prints out a path-like listing that highlights added lockers in a special way.
Adding Multiple Lockers. Formerly, you had to issue a separate add command for each locker you wanted to attach. For example:
athena% add sipb athena% add outland athena% add graphics
Now you can perform the equivalent function in a single command:
athena% add sipb outland graphics
[Be careful: each locker is processed in turn by add, so if you choose to use add -f (a new option) to add lockers at the front of your path rather than at the end (the end is the default, as before, if you don't specify -f), then the last locker specified in the add command will be the first entry in your resulting PATH, because that locker's path was added to the beginning of the PATH setting last by add.]
Showing a "Path" Listing. Another new feature is that add -p (or just add with no arguments) will now print out a "path"-like listing. For example:
athena% add sipb
athena% add -p
/srvd/patch /usr/athena/bin /bin/athena /usr/bin/X11 /usr/new
/usr/ucb /bin /usr/bin /usr/ibm /usr/andrew/bin {add sipb} .
For readability, add -p shows locker paths that conform to the new locker directory scheme in the simplified form {add lockername}. For instance, in the example above, the sipb locker is listed as {add sipb}; the actual path would be /mit/sipb/arch/platform/bin (or /mit/sipb/bindir on older machine types).
Be aware that the output of add -p is intended only as a convenient report of your path, not as a string to be used for other programming purposes. In other words, you should not try to use the add -p output in shell scripts or for such purposes as setting your path -- it is not designed for this.
Other New Features. A variety of other new features have been incorporated into add. For example, you can now pass arguments directly to the underlying attach command which actually does some of add's work. And you can tailor add via several new shell and environment variables.
For details of all the new options, features, and behaviors of the add command, see the add manual page.
The telnet command has been revised such that, by default, it will now try to establish a secure (i.e., authenticated and encrypted) connection, and will only use an unsafe version of telnet (i.e., the old /usr/ucb/telnet) if it can't establish a secure connection. (Previously, the unsafe version of telnet was used by default and you had to explicitly include the -safe option to have the command try to establish a secure connection.)
In addition, the -safe option has itself been revised such that it will not only try to establish a secure connection, but it will also not establish any connection if it cannot establish an secure one. (In other words, telnet -safe will now not "fall back" to an unsafe connection under any conditions). This is more consistent with its definition as a truly "safe" connection.
These changes help make sessions involving access to remote machines on Athena more secure.
Background. Currently, in almost all cases when you remotely access other machines over the network (e.g., using telnet, ftp, rlogin, etc.), your password and all your data is sent across the network "in the clear". This means all your information -- including the key to your account -- is actually visible to anyone who wants to look at it. "Packet sniffers" (people who purposefully eavesdrop on information sent across the network) can sieze your password and your account and misuse your data and the system at will.
One obvious workaround to the password problem is to change your password often (perhaps even after every remote session). But even this good practice is not failsafe, and it doesn't address the fact that any other information you pass over the network is also vulnerable.
Solutions. Two technical solutions have arisen to address these problems:
Because these solutions involve encoding and decoding at both ends of the network connection, your remote-access client (i.e., the connecting program, such as telnet) and the remote server (the remote machine to which you are connecting, such as an Athena dialup machine) must both have Kerberos and encryption capabilities if this scheme is to work.
Changes on Athena. In the previous Athena release, the telnet client program was updated to let you request a Kerberized and/or encrypted session, and the corresponding program on the server end (telnetd on the Athena dialup machines) was updated to be able to recognize requests for a Kerberos/encrypted connection.
With both ends in place on Athena, users could safely connect remotely to other machines in the Athena environment by using the -safe switch when they called the telnet command. However, when users tried to connect to machines that did not support the Kerberos/encryption schemes (e.g., non-Athena machines), telnet -safe did not terminate the connection. Instead, it connected them to the remote machine without a safe (Kerberized/encrypted) connection. Thus users would sometimes have connections they presumed were safe but in fact were not.
In order to assure that the -safe option really creates a safe connection, the telnet command has been revised in the Athena 7.7 Patch release such that telnet -safe will not establish a connection to a remote machine unless it can establish a Kerberized/encrypted session. (And telnet without any options will also try to establish a safe connection -- but, unlike telnet -safe, it will fall back to an unsafe connection if it can't establish a safe one).
Other changes of interest in the Athena 7.7 Patch Release include the following: