linerva.mit.edu is a SIPB project aimed at filling the need for a Linux-Athena dialup server. The official Athena dialups (athena.dialup.mit.edu) run Solaris Athena for “security reasons”. Unfortunately, this meant that Athena users did not have a public dialup server which they could use to run software that is only available on Linux, and it also means that compiling software for Linux-Athena can require travelling to a cluster.
Because we believe that modifying Athena Linux based on RHEL 4 to have improved security might be difficult, linerva.mit.edu runs Debathena, a collection of Debian packages that provide nearly complete compatibility with Athena for accessing the Athena services. With athmode, linerva also provides a public dialup capable of compiling software for Linux-Athena. We have made a number of security-related changes to the base Debian system to address the security concerns regarding a public Linux dialup. You can log in to linerva.mit.edu via SSH using Kerberos ticket forwarding (ssh -K) or password. Currently, you are able to log in by presenting your ticket but not forwarding it (ssh -k), which some users find confusing, since in that case your tickets will obviously not be forwarded.
You can contact the linerva maintainers at linerva@mit.edu.
The rest of this brief webpage documents features of linerva, along with some of the differences between linerva and Athena.
linerva.mit.edu is not Linux-Athena, and thus it is not optimal for compiling software to run on Linux-Athena. However, linerva features an Athena Linux build chroot accessed via the athmode command, which will place you inside the chroot and execute your normal Athena shell. You should thus be able to conveniently build software for Linux-Athena inside this chroot. athmode can also be useful for running software from AFS that does not yet work on linerva itself, though you should be aware that some Athena services such as sendmail will not be running from inside the chroot, and the setuid root binaries inside the chroot have lost their permissions.
/mit is automounted, which should make accessing files in lockers generally less painful. We have a fully compatable version of attach installed, which is necessary for some complex locker software, but you don’t have to actually attach a locker in order to access it via a /mit path.
/usr/athena is symlinked to /usr (and /bin/athena to /bin). This allows locker software that runs things like /usr/athena/bin/perl to work correctly. Thus, scripts that use pathnames for binaries on Athena should work without having to translate the pathnames on linerva (let us know if you find a case where this is not true). If you’re curious whether a program is the stock Debian version or a modified version, run dpkg -S /path/to/file. If the program comes from a package with a name starting with “debathena-”, then it is one that we modified.
We believe linerva.mit.edu to have some library compatibility with Athena, in the sense that all the libraries installed locally on an Athena workstation are installed locally on linerva, though of course we cannot guarantee the same versions are installed. Most software in AFS will run on linerva without changes. Let us know if you find any cases where this does not work.
We have a large amount of Debian development software installed for our own convenience, but which is generally useful for making Debian packages. We do not recommend building software intended for Red Hat Linux-Athena on linerva without using the athmode chroot.
On linerva, your Athena dotfiles will be executed as on any normal Athena machine, except for a few changes: the athena% prompt is replaced with a debathena% prompt by default, and the default ZEPHYR_CLIENT variable is to print a message, rather than by running zwgc on the dialup (since that behaviour is almost always annoying).
Some users may find it useful to have different dotfiles on linerva than on a standard Athena workstation. You can implement this by testing for the output of the program /etc/athena/dialuptype (which only exists on dialup machines). Some working example code for tcsh and bash are provided below. Note that your dotfiles should never print any text to standard output if you want programs like scp to work.
For tcsh (~/.cshrc.mine):
if (-e /etc/athena/dialuptype) then
if (("`/etc/athena/dialuptype`" == "linerva" )) then
# Put your linerva-specific customizations here
endif
endif
For bash (~/.bashrc.mine):
if test -e /etc/athena/dialuptype; then
if test "`/etc/athena/dialuptype`" = "linerva"; then
# Put your linerva-specific customizations here
fi
fi
Announcements of outages and service changes will be sent to the linerva-announce Moira/Mailman list. Outages not related to security problems will be announced at least 3 days in advance, and will be accompanied with changes to the motd and messages sent via wall. Outages that result from security problems in the Linux kernel may occur on arbitrarily short notice, depending on the nature of the vulnerability.
In order to prevent users from causing a denial of service to the system, we have some resource limits in place on linerva. You will probably not see them unless you attempt to run a computationally intensive job, fork-bomb the machine, or do other stuff you shouldn’t do on a dialup. If you believe our resource limits are too restrictive, please let us know (you can check the current settings using limit in tcsh or ulimit -a in bash).
If you do not have the GSSAPIDelegateCredentials option enabled in your ssh, you will not receive Kerberos tickets or AFS tokens and thus will not be able to run your dotfiles when you log in. GSSAPIDelegateCredentials is disabled in most ssh configurations by default. You can configure your machine to delegate credentials to linerva by adding the following to your ~/.ssh/config.
Host linerva linerva.mit.edu linux linux.mit.edu
GSSAPIDelegateCredentials yes
SecureCRT does not try keyboard-interactive authentication by default. linerva does not support the older password authentication mechanism (which SecureCRT does try by default), so you need to configure SecureCRT to use the keyboard-interactive authentication method in order to log in to linerva with a password using SecureCRT, as follows.
In the Connection options, or in the Quick Connect window, look at the “Authentication” section. Choose “GSSAPI” as the Primary authentication method and “Keyboard Interactive” as the Secondary authentication method. The default authentication method of “Password” does not work with linerva.
Linerva’s sshd is also listening on port 8080.
In order to get Kerberos 4 tickets on Linerva and other Debathena machines, you should use the renew command, or pass the arguments kinit -54.