The NetBSD Athena Port Greg Hudson Begun August 1, 1995 Introduction This document describes the origins and status of the Student Information Processing Board's NetBSD Athena port. The primary audience of this document is employees of MIT Information Systems Distributed Computing and Network Services, or other people familiar with the Athena environment. NetBSD is a free, portable operating system based on BSD 4.4. NetBSD runs on a variety of platforms, including Intel 386, 486, and Pentium-based machines. The focus of SIPB's NetBSD support has been on the Intel platform. This document will cover the origins and goals of the NetBSD Athena port, how we achieved a high degrees of filesyetem separation between the base NetBSD operating system and the Athena software layered on top of it, the changes we made to the Athena software for NetBSD, the workings of the installation procedure we've development, and how we manage the operating system and Athena software source trees. The last part of this document will discuss future directions of the NetBSD Athena porting effort. Origins and Goals MIT brought network connections to its undergraduate dormitories at the beginning of 1994. In anticipation of this event, SIPB wanted to allow students to make use of their network connections for more than dialup connections and the sparse set of Athena applications available for MS Windows and MacOS. At the time, Linux was the primary full-featured free operating system available for the Intel platforms, and a member of SIPB (Salvatore Valente) had already been doing work on running Athena software under Linux on an old Intel machine in the SIPB office. For most of 1994, SIPB promoted its Linux-Athena port as the best way to use a PC connected to Resnet for Athena tasks. The NetBSD Athena port was developed within SIPB during the summer of 1994. Some SIPB members who previously did work on the Linux-Athena port began to prefer NetBSD due to its developers' more cohesive approach to development. NetBSD's derivation from BSD 4.4 also allowed SIPB to do a port of AFS with much less time and effort than was required for Linux (and the NetBSD AFS port continues to be more reliable than the Linux AFS port). In the fall of 1994, NetBSD 1.0 was released, and SIPB released an installation procedure for NetBSD with or without Athena customizations. SIPB's major goals for the NetBSD Athena port are twofold. First and foremost, we want to provide a stable, supported environment for Athena computation which runs on a popular, inexpensive platform. To achieve this first goal, we want to provide as much support as possible for both the installation of the operating system and the myriad Athena software itself (which includes lockers, courseware, and third-party commercial software as well as the basic Athena tools). Second, we want to promote the use of free operating systems and free software in the Athena environment, and show that despite the lack of commercial software contracts we can produce an environment which is equal to or better than the vendor platforms in many respects. Filesystem Separation One important minor goal of our PC platform support is that we want to allow people to install the operating system itself on a networked PC without installing any Athena software. We also want to be able to update either the operating system software or the Athena software without conflicts. For these reasons, we want to clearly separate Athena software from the operating system software. The NetBSD Athena port design goals for filesystem separation can be stated as follows: * No modification will be made to the operating system which is inappropriate outside of the Athene environment. * All Athena software will reside in /bin/athena, /etc/athena, /usr/vice, and /usr/athena. * All "communication" between the Athena software and the system shall be accomplished through minimal changes to system configuration files. * We further separate MITnet customizations from Athena customizations, and make the latter set optional. Traditionally, the biggest sticking point in filesystem separation in other Athena platforms has been the login procedure. We have overcome this difficulty by placing the Athena login program in /bin/athena/login. The various entry points to an Athena account are handled as follows: * /etc/gettytab is modified to set the login program to /bin/athena/login instead of the default /usr/bin/login, so console logins use the Athena login. * xlogin uses its own login procedures, as on other Athena platforms. * telnetd uses /bin/athena/login for non-preauthenticated logins (when the user does not use Kerberos authentication or telnetd is invoked with "-a off"), so that the user gets tickets and tokens. telnetd uses the Kerberos login.krb for preauthenticated logins, as with other Athena platforms. * The Kerberos klogind and rshd utilities use login.krb, as on other Athena platforms. Another problem in the login procedure is the use of /bin/csh in users' Hesiod information to mean /bin/athena/tcsh. Rather than replace the operating system's /bin/csh with a symlink, we translate /bin/csh to /bin/athena/tcsh in each of the entry points which create system accounts; we will describe this approach more fully in the section on software changes below. While the SGI Athena port ran into considerable difficulty with IRIX's many-featured login procedure, NetBSD's simple approach made it very easy to integrate the Athena login requirements into the system without modifying the system software at all. (The various Athena login utilities still required significant effort in the NetBSD Athena port, as described in the section on software changes below, but this was more due to deficiencies in the Athena software than it was due to NetBSD's differences from other platforms.) Another complicated interaction between the operating system and Athena software arises between the use of imake by both Athena and X11R6 software. In this area, we chose to go in the reverse direction of the other Athena platforms, integrating rather than separating the Imake.tmpl and Imake.rules files so that both X11 and Athena software will configure properly. Although this integrated approach contradicts our principles, it does so in an area of the system we do not generally rebuild or upgrade very often, and it generally makes life much easier on developers than the current approach on other Athena platforms. We decided that the default name server and sendmail configuration were part of MITnet customizations rather than Athena customizations. We will describe what this entails in later sections on the installation procedure and operating system source tree management. Athena software changes The biggest and most irreconcilable difference in the NetBSD Athena port is our use of the Cygnus Network Security package for Kerberos 4 support instead of the Athena Kerberos 4 code base. Unless DCNS plans on using CNS for the main Athena release, we do not anticipate merging these source bases until the Athena environment migrates to Kerberos 5 and discards the Kerberos 4 code base. The area of the Athena software we've done the most work on is the login system. As mentioned above in the section on filesystem separation, the various points of entry to an Athena account are console logins, xlogin, telnetd, rlogind, and rshd. Console logins and make use of the Athena login program /bin/athena/login, rlogind and rshd use of the Kerberos login program /etc/athena/login.krb, telnetd uses either /etc/athena/login.krb or /bin/athena/login depending on whether the login was preauthenticated, and xlogin uses its own login procedure. Console logins, xlogin, and telnetd will all create accounts for the user, while rlogind and rshd assume an account already exists. telnetd uses the "common Athena login library" (libAL) to create accounts (unfortunately, it is the only program in the Athena environment to do so), while /bin/athena/login and xlogin use their own code to create accounts. The main difference in the NetBSD-Athena port requiring changes in the Athena login system has to do with the way BSD 4.4-based systems manage password information: the source file for password information is not /etc/passwd but /etc/master.passwd, from which /etc/passwd is created as well as two databases for fast lookups. This means that code which creates accounts must edit /etc/master.passwd and run the program to recreate the databases (pwd_mkdb) instead of simply modifying /etc/passwd. Fortunately, we can simply make use of a code module from the NetBSD source tree (pw_util.c) which makes it easy to obtain temporary copies of the master.passwd file and rebuild the databse when we're done modifying it. In addition to supporting the master.passwd file, we have corrected several deficiencies in the Athena login system: * The shell listed in users' Hesiod information is not always the correct shell to use; in particular, /bin/csh actually means /bin/athena/tcsh. We added code to /bin/athena/login, xlogin, and libAL to map shells as specified in a file /etc/athena/shellcvt. In addition to mapping /bin/csh to /bin/athena/tcsh, systems can translate other shells which may not have been built for NetBSD. We consider this a cleaner solution than hardcoding shell translations into the login programs. * xlogin will complain loudly when logging people into local accounts which do not have corresponding Hesiod information or Kerberos principals. If a local accout has an empty directory, the stock Athena xlogin will go so far as to remove the home directory and then complain that it can't attach it. We modified xlogin to mark an account as "purely local" if it does not have Hesiod information, and not try to get Kerberos tickets or attach a home directory. * libAL had code to add people to groups, but it was called improperly and wouldn't add people to groups. Thus, when you would do a pre-authenticated login through telnetd, you would not be added to groups. * All three implementations of adding users to groups failed to add users to their primary group in /etc/group (so, for instance, "ls -l" would not be able to recognize the group number of most users' personal files). * All three implementations of adding users to groups limited themselves to adding 13 groups (leaving room for one primary group and two PAG groups), but they failed to count preexisting local groups, so users wound up in too many groups. * Pre-authenticated telnetd logins would create an account for a user, but not attach the user's home directory. (This is perhaps a legitimate design decision, but we felt it appropriate to attach the user's home directory in login.krb, conditionalized on "#ifdef HESIOD".) In correcting these deficiencies, we merged the implementations of adding users to groups in /bin/athena/login and xlogin. The right answer is to use libAL for /bin/athena/login, xlogin, and telnetd instead of just in telnetd, and we may make that change in the near future. Apart from the above-mentioned changes, most of the changes we made to the code base are comparatively minor. Some of the portability issues we had to address in each package were: * Many programs explicitly declare errno and/or sys_errlist, a practice which is not compatible with modern operating systems and causes declaration conflicts under NetBSD. Programs should #include for errno and use strerror() instead of sys_errlist to retrieve error messages. * NetBSD uses a 64-bit off_t types, requiring that all programs using lseek(), read(), etc. include for protoypes or cast their length arguments to off_t explicitly. * NetBSD's regular expression compatibility libraries don't always work as well as the new POSIX routines. In particular, we converted zwgc's regular-expression code to use the new POSIX interface. * NetBSD's stdio and curses internals are different than those of other platforms. This only affected mh. Despite the subtlety of the problems caused for 64-bit offset types, most Athena programs built and ran with very little difficulty. Installation Installations for Athena public workstations focus on the operational requirement that they be automatic after the first few steps. Users of private machines have very different requirements for a filesystem: they don't want to destroy the existing data on their system (in a DOS partition, usually), they do not have a particular standard hardware configuration (imagine DCNS's problems with new models of Sun and SGI hardware occurring for each user's system), they may have special preferences for partition layout, and they are not usually trained in installing operating systems. The NetBSD installation procedure for networked machines works as follows: 1. If users have a DOS partition they need to shrink, they use DOS programs "defrag" and "FIPS". We do not automate this step (supplying a tool to defragment a DOS filesystem isn't easy), but defrag and FIPS are both easy to use. 2. Users boot off of an installation floppy disk, which asks for an IP address, automatically locates the correct ethernet device, and connects to an NFS server (sipb.mit.edu) containing the main body of the installation software. 3. The installation procedure (running off the NFS server at this point) locates or creates a NetBSD partition on the system's disks and asks the user how much space to allocate for the root partition, swap partition, and AFS cache partition (the rest goes to the /u1 partition where /usr and /var are located). 4. The installation procedure copies the operating system software and kernel onto the target disks and creates devices nodes. 5. The installation procedure finds the system's hostname by reverse-resolving its IP address, sets up network configuration files on the target system, and asks a few configuration questions (where to forward root mail to, what the root password should be, whether to use a memory filesystem for /tmp and how much space to allocate if so). 6. The installation procedure asks if the user wants to install Athena software, explaining what this entails. If the user answers affirmatively, the installation procedure modifies the system such that it will load AFS on startup and will rely on the SIPB AFS servers for X11R6 and athena software. 7. The user must reboot and configure X manually, since we cannot easily automate X configuration. (The user can use a program "xf86config" supplied with X11R6.) With a few changes and a standard hardware configuration, this installation procedure could be made completely automatic for cluster machines (one could even avoid the use of a floppy using net-boot hardware). By viewing installation as a simple problem of copying files onto the target system and setting up some configuration files, we are able to avoid the complexities of vendor installation servers which have caused problems for DCNS on the Solaris and SGI platforms. Operating System Source Management Future Directions