Rutgers, The State University of New Jersey
OFFICE OF INFORMATION TECHNOLOGY | TECHNICAL DIRECTOR'S WEB PAGE
 

Solaris System Configuration

Who is this page for?

This web page is intended to give advice to system administrators at Rutgers about configuring Solaris systems. This page should be all you need if you are managing a simple workstation. However for servers and more complex systems, you are likely to need additional information.

This document was carefully checked for Solaris 2.6. A number of changes have been made for Solaris 8, but it is possible that I've missed something. I does not cover Solaris 7. In general Solaris 7 should be covered by either the comments for 2.6 or 8, but I am currently not in a position to state which. (I don't have an unmodified Solaris 7 system I can check.)

There is a support infrastructure for system administrators, based around TINT (an automatic software distribution system), the ru.comp.dev newsgroup, and monthly Unix support staff meetings (at 1:30 the first Tuesday of each month. Exact times and locations are given on the System Administrators' Web Page. HOWEVER, this all assumes that you have some background in Unix administration, and plan to do administration as a significant part of your job. There are a number of people at Rutgers who have Suns, but who do not have system administrators, and who do not want to spend their own time keeping up with the amount of information needed to manage a system in the traditional Rutgers fashion. This page is intended for you. This page is also worth reading for professional staff who are new to the Rutgers environment.

Beware that if you are running a machine used by more than one person, e.g. a departmental server, you are by definition going to become a professional system administrator. I think you can get away with running a private desktop system just by following the guidelines in this document. But if you're running a departmental server you're kidding yourself if you don't think you're a professional system administrator. In that case this document is still a place to start, but you're going to have to learn more. Start by coming to the monthly meetings, and by looking carefully at the section in this document on security. Go to a bookstore with a good computer section (e.g. Borders) and pick up the O'Reilly books on several of the basic topics involved in system administration.

If you want to use Track, and run your system in the traditional Rutgers fashion, I suggest looking at the Network Services web page. See particularly the section on System Administration Services. This is the approach I recommend for professional system administrators, and anyone maintaining systems for use by a large number of people.

Overall Approach

For people who are going to do their own system administration, we recommend that you use Solaris as it comes from Sun, with a minimum of modifications.

In the old days, Unix required lots of experience to set up, and what you got from the vendor was missing lots of things that people at universities wanted. So system administrators did a lot of customization, and Unix had the reputation of needing a guru to administer. Modern Unix systems (in particular, Solaris 2 and Digital Unix 4.0 or later) have GUI-based installation and system administration tools. They are as easy to set up as Windows NT (which is easier to set up in a networked environment than Windows 3.1). Some editing of text files is probably still going to be needed, but it doesn't need a wizard anymore.

However you should be aware that many Solaris systems at Rutgers are still run the "old way": they are set up by people who have experience with the larger systems at Rutgers, and they are customized significantly. This page assumes that you do not, and that you don't want a customized system.

If you are going to be responsible for your own system, you must know everything that has been done to it. The worst thing you can do is to hire a student or consultant to install it, and then take responsibility for it yourself. You need to make a decision at the beginning as to whether you want a customized system or not. If you do, you either need to learn enough about system administration to understand the customizations yourself, or you need to have the services of a system administrator on a continuing basis. This can be a student: there are many students capable of installing and maintaining a system for you. But once the system has been customized, you're going to find it nearly impossible to do system administration for yourself, because you're not going to know exactly what was done. If you ever need to reinstall the system (e.g. which is sometimes a good idea when there's a major new release), you'll find it very hard to redo the customizations.

Thus this page assumes that your system has not been customized in any way.

Configuring your disks (Partitioning)

The one item you'll need to think about in advance is configuring your disks. If you have a single disk, this can be fairly easy. If you have more than one, you have to think about what things you put on each disk. As with most other operating systems, Solaris breaks disks up into pieces, called "partitions". (Under DOS, these correspond to different drive letters: C:, D:, etc.) In theory you can have 7 partitions on each disk, but you probably don't want to do that.

Why partition?

About now, you're probably asking why we'd want to partition a disk. Why not just use the whole disk as one big file system? There are several answers for that, but some of them apply more to large timesharing systems. For the systems you're likely to be dealing with, there's one good reason for partitioning: When you install Solaris, the install procedure completely recreates the partitions it uses. That is, anything you had there is wiped out. Thus you want at least two partitions: one with Solaris, created by the install procedure, and one with everything else (your own files and any software you install). In practice, you'll probably end up with 4 partitions: Note that Solaris will create a partition 2 on each disk, called "overlap". Ignore that partition. It's the full size of the disk, but it isn't used for anything.

One disk

If you have one disk, I recommend four partitions: root, /usr, swap, and one partition for everything else. You can let the Solaris install program lay out the disk for you. Choose Auto-Layout, and tell it to create root, /usr, and swap. Solaris will calculate the sizes of root, /usr, and swap for you. It will assign the rest of the disk to /export/home.

When I tried it under Solaris 7, Solaris created a root that I think is too large. It chose to use over 120 MB for root. For a typical single-user machine, 64 MB is large enough for root, although I'm now using 96 MB. I'd be inclined to go into the Customize window and decrease the size of root. That will leave more for /export/home, where you'll probably need it. There are two possible exceptions: (1) If you are going to have a number of people on the machine, all with large mail files, you might need as much space as the install program assigned. (In this case you should consider letting the install program create a separate /var.) (2) If the only additional software you're going to install fits in about 64 MB, you could leave /opt in root. Then 120 MB for root would be fine. But additional software tends to grow, and most of it is bigger than 64 MB.

If you have enough disk space, you may want to add space to /usr. The size of Solaris grows from release to release. You'll save yourself future hassles if you make /usr larger than it needs to be.

Once you've finished the installation, you'll want to move /opt. The problem is that in this pattern of usage, Sun will put /opt in the root partition. Solaris doesn't put much on /opt: /opt is used primarily for additional software. But you almost certainly want it in /export/home, not root. So once the system is up, I recommend moving /opt to /export/home/opt. The following commands will do it:

Make sure the files are properly copied to /export/home/opt before removing the original copy ("rm -rf /opt"). If something goes wrong, you'll want to remove the copies and try again, i.e. do "rm -rf /export/home/opt/*" if you're going to have to do the "cp" command again.

If you are going to install software from elsewhere at Rutgers or from the net, you will probably also need /usr/local. With this pattern of partitions, I recommend putting it on /export/home. E.g.

An example

Below are the sizes on my desktop, with Solaris 8. I have the complete Solaris distribution. However I haven't followed the advice above. If I were doing it again, I wouldn't create separate /local and /opt partitions, as mentioned above.

On /local I have a number of packages, some of which you might not need. This includes a couple of versions of Netscape, teTeX (a complete distribution of TeX/LaTeX, which is 108 MB of this), a reasonable amount of Gnu software, etc.

On /opt I have commercial versions of Acrobat 3 and 4, samba, and various other random software. However I don't have anything really big. I put that on /export. If I were doing it again, I would probably combine /export, /local and /opt as one partition.

Here's the output of "df -k" on my desktop system: 

/dev/dsk/c0t0d0s0      96019   47835   38583    56%    /
/dev/dsk/c0t0d0s5     865221  741436   63220    93%    /usr
/proc                      0       0       0     0%    /proc
fd                         0       0       0     0%    /dev/fd
mnttab                     0       0       0     0%    /etc/mnttab
/dev/dsk/c0t0d0s3      96019   58599   27819    68%    /var
swap                  127616       0  127616     0%    /var/run
swap                  131800    4184  127616     4%    /tmp
/dev/dsk/c0t0d0s7    2150859 2030520   77322    97%    /export
/dev/dsk/c0t0d0s6     384120  359611       0   100%    /local
/dev/dsk/c0t0d0s4     192056  151094   21757    88%    /opt

Two disks

If you have two disks, the exact setup depends upon size. If possible, you should try to split things so that disk I/O is split evenly between the disks. In practice it turns out that a lot more I/O happens to partitions that store software than to your own home files. Also, it's traditional to create swap partitions on every disk, thus splitting swap activity. Thus I'd do the following: /opt is where additional software goes, so this does the best job of splitting I/O between the disks. If the two disks are the same size, this makes /opt larger than /export/home. Assuming you put your own home directory on /export/home, that's probably right, since most people use more space for software than their actual files.

Solaris will calculate the sizes of root, /usr, and swap for you. It will assign the rest of disk 1 to /export/home, which is OK. When I tried a two-disk system, it assigned all of disk 2 to /export/home0. I needed to go into the Customize dialog to add a swap partition and rename /export/home0 to /opt. Here's the easiest way to do it:

When I tried it, Solaris created a root that I think is too large. It chose to use over 120 MB for root, at least for Solaris 7. For a typical single-user machine, 64 MB is large enough for root. I'd be inclined to go into the Customize window and decrease the size of root to something between 64 MB and 100 MB. That will leave more for /export/home, where you'll probably need it. There are two possible exceptions: (1) If you are going to have a number of people on the machine, all with large mail files, you might need as much space as the install program assigned. (In this case you should consider letting the install program create a separate /var.) (2) If the only additional software you're going to install fits in about 64 MB, you could leave /opt in root. Then 120 MB for root would be fine. But additional software tends to grow, and most of it is bigger than 64 MB.

If you have enough disk space, you may want to add space to /usr. The size of Solaris grows from release to release. You'll save yourself future hassles if you make /usr larger than it needs to be.

If you are going to install software from elsewhere at Rutgers or from the net, you will probably also need /usr/local. With this pattern of partitions, it could go in either /opt or /export/home, depending upon how much space you think you're likely to use in those two areas. Other things being equal, I'd put it in /opt. E.g.

More about partitions

While I recommend using only root, swap, and /usr, Sun's partitioning program will ofter to create a number of different partitions. You don't really need to know any of this, but in case you're curious, here's what the options are, at least in release 2.5.1:

Advice on setting up or upgrading Solaris

This section is going to run you through the process of setting up or upgrading Solaris, giving advice where it's likely that you'll need it.

Before you start the install, make sure you read the previous section: Configuring your disks (Partitioning). Also, if you are modifying an existing system, make sure you have the output of the "df" command on paper. You may need it to see how your system is currently set up.

Upgrading

This section applies if you are already running Solaris, and you need to move to a new version. If you are doing a new installation, you can skip to the next section, The Installation Process. Note that you use essentially the same process to install Solaris from scratch or to upgrade to a new release. If you're upgrading to a new release, and you like the way your system is currently set up, you can take the "upgrade" option. This will replace your system software with the new release, and leave the rest of your system untouched. If you have changed files, you may have some cleanup to do after the upgrade, but the upgrade procedure should identify the files you need to look at, and automatically save any old files that you need.

Unfortunately, Solaris doesn't always offer to upgrade, even when you might think it should. At least under 2.5.1 it offers to upgrade right after you've set the date and time (and after pausing for several minutes to assess your system). If you get the "System Type" dialog (which asks you to specify Standalone, Server or Dataless client) without seeing it offer to upgrade your system, then an upgrade is not possible. In this case, you'll have to install the new release from scratch. You may also chose to do a reinstallation even when it would be possible to upgrade. Do this if your current setup is incomplete, corrupted, or you simply want to start from scratch.

If you are going to do a reinstallation, spend some time thinking about what information you might need to save. The installation process will completely recreate the root and /usr partitions. If you have put any files on root and /usr, they will be lost. This is why we advise you to put all your own files somewhere else, such as /home or /opt. Even if you've followed this advice, you will probably find that you've changed some files in /etc. For example, /etc/passwd, /etc/shadow and /etc/group will contain information about any users you have added. If you have added any file systems that weren't generated by the Solaris installation, that will be in /etc/vfstab. If you're using PAM (i.e. Rutgers Enigma or Kerberos support), you'll need /etc/pam.conf. I suggest doing 

  ls -lt /etc | more
This will show you a directory of /etc, with the most recent files first. Some of these files (e.g. mnttab, utmppipe, and initpipe) are created by the system. You don't have to worry about them. However others will be files you have created or changed, or subdirectories in which you have made changes.

Once you've identified files that you have changed, I suggest that you save copies of them in a directory somewhere outside of root and /usr. Then you can put them back after the reinstallation.

You may also have added symbolic links. For example, it is likely that /usr/local will be a symbolic link to some other file system (e.g. /opt). Make sure that you recreate those symbolic links after you've reinstalled the system. (Use the command "ls -s".)

The Installation Process

The Solaris install tool is rather friendly. You can go back to previous screens if you make a mistake, and it doesn't actually do anything to your system until the very end, where you tell it to go ahead. Help is available.

We generally advise people to install from the network. It's faster, and it doesn't require you to find a CD copy of Solaris. However it requires a second machine on the same subnet, which you have to configure as a server. If you're the kind of person this page was written for, you probably don't have a second machine. So you'll have to borrow a CD. Rutgers gets 10 copies of Solaris. Several of them are available to be borrowed from Joe Miklojcik. The Newark and Camden OIT groups should each have a copy of the CD. Users on those campuses will probably find it more convenient to get the CD from their campus OIT group.

I'm not going to comment on things that I think will be obvious, such as setting the timezone and time. Note that the system may take a long time in certain places (e.g. after confirming the time). Normally it is loading software from the CD, which is very slow. However there is one very long pause where the CD light isn't going.

Identification

The first section is common to upgrading and full installations. It identifies the system. The exact dialog will not be the same in all cases, because Solaris sometimes figures out information from servers on the network. (This can be a problem if you you want to change your hostname or IP address. You may need to disconnect your network in order to keep the system from getting the old information.) Here are the questions it asked (other than those where I think the answer is obvious):

Finishing an Upgrade

If your system already has Solaris on it, the installation program may offer to upgrade it to the current release. The upgrade option was discussed above. If Solaris thinks your system is upgradable, you'll get a dialog box labelled "Upgrade system?", with choices "Upgrade" and "Initial". Choose upgrade to upgrade your existing software, or "Initial" to install from scratch. If you choose "Initial", your root and /usr partitions will be recreated, so you'll lose everything that was on them before.

If you chose to upgrade, you may be asked to choose a disk to use for upgrading. (In theory you could have two copies of Solaris, residing on different partitions. The installation program needs to know which one you want to upgrade.) It will then ask if you want to customize software. The normal thing is to choose "Continue". This will cause it to do a simple upgrade, i.e. to leave you with the same set of software you had before, but a newer release.

If you choose "Customize", you'll get the same software selection system that you'd get in a full install. This lets you change the set of software you have installed. New releases tend to be larger than old ones. You may sometimes run into a situation where the new version won't fit. In that case, you may need to use "Customize", and deselect enough options so that the new release will fit.

Once you've gone through the software selection, or bypassed it by choosing "Continue", you'll be presented with a summary of what Install is going to do, and asked to choose "Begin Upgrade". If you want to make any changes, "Change" will let you move back into previous screens. Once you're convinced you've got things right, hit "Begin Upgrade". At that point everything will happen automatically.

Once the upgrade is finished, there are some log files you'll want to look at. They indicate places where Solaris isn't sure it did the right thing, and you need to check something. Typically this is where you have modified a file, and it isn't sure how to put your changes into the new version. This doesn't mean you modified the file yourself. You may have installed a software package, and its installation script changed something. If you have installed patches, you may also see some indication in the log. It warns you if the old version of any file wasn't what it expected. If you installed a patch, any files changed by the patch may be flagged.

If the upgrade fails, the log file is /a/var/sadm/install_data/upgrade_log. If it succeeds, the log file is /var/sadm/install_data/upgrade_log.

Finishing a full install

If your system is not upgradable, or if you choose "Initial", you'll now see the "System Type" dialog box. You should choose "Standalone". The other two options can be used in larger installations where several systems get /usr from a central server, but we're never tried it and don't really recommend it. You may see the question "Do you want to allocate space for diskless clients and/or AutoClient systems". Normally you do not. Thus you should simply choose "Continue". You'll now be asked to choose the software you want. Sun has defined certain sets of software that they think make sense. The most likely ones are "End user", "Developer", and "Entire Distribution". You can pick one of these, and choose "Continue". That will be it for software choice. Or you can choose "Customize" to select the individual pieces of software you want. The only reason I can think of for doing customize is if you have to get a certain set of software into a limited amount of disk space. (With the costs of disks today, I'd recommend getting a larger disk, rather than monkeying around with obscure combinations of software.) We normally use "Entire Distribution" on servers and "Developer" on workstations. "End user" is intended to be the minimum usable system. It has the basic commands and windowing system, but no online man pages, and it's missing things needed to compile programs. "Developer" is intended to be a system that's usable for serious work. It's missing only some of the more specialized features. It has man pages but not AnswerBook (the online copy of the full documentation). You'll probably prefer to get Answerbook over the network from our server.

Once you've chosen your software, you'll need to choose disk partitions. Before you started the install, you should have read the section above: Configuring your disks (Partitioning). If you haven't, do so now.

First, Solaris will ask if you want to preserve data on any of your partitions. If you're upgrading or reinstalling Solaris on an existing system, you'll probably want to do this. If you've followed my advice, you'll keep Solaris and your own files on separate partitions. An installation always recreates root and /usr. But if you've put your own files and programs elsewhere (e.g. /export/home, and if you've got two disks, /opt), you can tell Solaris to leave them alone. BUT YOU MUST TELL SOLARIS TO PRESERVE DATA.

First, you'll come to the "Disks" dialog box, where you tell the system what disks you want to install Solaris on. If you have only one disk, this is obvious. If you have more than one, you want to choose the disks on which you want Solaris to be installed. If you have lots of disk space, you can keep multiple copies of Solaris. But that's very unusual. Normally you'll have one root and /usr, and when you install a new version of Solaris, you'll use the same root and /usr that the old verison did.

Unless you're doing something odd, I'd choose all the disks. In theory you only need to choose the disks on which parts of Solaris are resident. However unless you have a huge number of disks, you'll probably need to do something to each of them (even if it's only putting swap on it).

Next you'll get "Preserve Data?". If you're upgrading or modifying an existing installation, choose "Preserve". In general you want to mark any partition as preserved if it has your data or programs. If you've followed my recommendations, this will be all partitions EXCEPT root, /usr, swap, and overlap. (Root and /usr are recreated by Solaris. Data on swap isn't saved over reboots anyway, so preserving it doesn't do anything. Overlap isn't real, so preserving it doesn't do anything either.)

If you have a separate /opt, it's a special case, because it has both your own data (programs you may have installed) and things from Solaris. You should preserve it. Once Solaris has been installed, verify that Solaris didn't create a new /opt in root. If so, you'll need to follow the instructions for moving /opt.

Now you'll get a screen that lets you choose how to lay out the disks. I recommend choosing Auto-layout. That will let Sun lay out the disks for you. I've already given advice on how to do partitioning. In general, there are three steps:

When you choose Continue from the File System and Disk Layout screen, you'll be asked if you want to mount remote systems. This depends upon your environment, but for the simplest cases, you don't. Simply choose "Continue".

You'll now get a screen summarizing the installation. If you want to make any changes, "Change" will let you move back into previous screens. Once you're convinced you've got things right, hit "Begin Installation". At that point everything will happen automatically.

You may be asked whether you want to do an "Auto Reboot" or "Manual Reboot". Once the software is installed, the system must be rebooted. Auto reboot will do this for you. Manual reboot will not reboot the system. You'll have to do it for yourself. Unless for some reason you need to make adjustments in the system before reboot, choose "auto". (Here's a case where you'd want to do manual reboot: If you are upgrading an existing system, and all privileged accounts use Enigma or Kerberized logins, the Rutgers PAM support must be working before you reboot. Otherwise you may be unable to login after the reboot. In that case you would want to verify that the upgrade hasn't changed any of the critical files before rebooting. If you don't understand any of this, don't worry -- we're talking about systems that have been modified by the system administrator.)

Configuring the system after installation

When the system reboots after installation, a few additional steps happen. One of them allows you to choose a root password. Please make sure that you do this, and make sure that the root password is not easy to guess. Otherwise it will be easy to break into your system.

Newer operating systems may offer to enable features that power down your monitor and/or system after they have been idle for a while. If you do this, you will probably want to go into the CDE configuration screens and increase the waiting time. The default value is annoyingly short. Many users find this whole feature annoying.

Once your system is installed, there are a few things you'll want to do in order to make it function well at Rutgers.

Check /etc/hosts and /etc/hostname.le0

This should not be necessary. However we've seen cases where the Solaris install procedure leaves you with invalid data, and your system either can't come up at all or can't use the network. Do 
    ls /etc/hostname.*
You will have a file with a name like /etc/hostname.le0. The le0 is actually the name of your first Ethernet interface. It's le0 for most of our systems, though some very old ones may is ie0 and some newer ones hme0. This file is used during startup to tell the system what IP address to assign to your machine. It can contain either the IP address itself or your hostname. If it contains your hostname, the system will look up the hostname in /etc/hosts to get the address. We recommend putting the IP address in this file, rather than the hostname. To do that, replace the file with a one-line file containing just the address followed by an end of line. An easy way to do that is with echo, e.g. if your IP address is 128.6.4.1, type 
    echo 128.6.4.1 >/etc/hostname.le0
Make sure you use the IP address assigned to your machine instead of 128.6.4.1, and use the correct filename (/etc/hostname.le0, /etc/hostname.ie0, or /etc/hostname.hme0).

Set up IP routing

If you want to be able to access computers outside your own subnet, your system needs to know the address of a "router". The router is a special-purpose computer run by the Network Operations Group. There's usually one per building or department. It connects your building or department to the rest of the Rutgers network.

By default, Solaris will use a daemon (the "router discovery daemon") that attempts to find the router automatically. This should do the right thing. However if the router is not up when your machine comes up (that can happen after a power failure), you may end up with the wrong daemon running, and thus be unable to access the rest of the network. Furthermore, not all the routers are running the service that lets the daemon find them. In departments whose router is not running the router discovery service, the default Solaris approach will not work.

To see whether Solaris has managed to find a router, use the command 

    netstat -n -r
If one of the lines has "default" in the first column, your system has found a router. If it has, you can skip the rest of this section.

If you are not seeing a default route

If you are not seeing a default route, several problems are possible: When you first install Solaris, it is configured reasonably. However if someone else has been "helping" you, they may have done something to modify the routing. Since there are many things they could have done, it's very hard to comment on this. There's one easy test to make: See what daemon is running: 
    /bin/ps -ef | grep rdisc
You should see something like this: 
     root   304   302  1 14:55:29 ?        0:00 grep rdisc
     root    96     1  0 14:08:46 ?        0:00 /usr/sbin/in.rdisc -s
The first line comes from your command itself, and doesn't mean anything. This second line comes from the router discovery daemon. If you don't see it, something is wrong. The next check to make is 
    /bin/ps -ef | grep routed
The output should look similar to the two lines above, but with routed instead of rdist. Again, the line showing "grep routed" simply comes from your command, and doesn't mean anything. If you see a second line, actually showing routed running, this probably indicates that your system was unable to find a router. Normally Solaris starts in.rdisc. If that fails to find a router, it exits, and Solaris starts in.routed. In many locations, in.routed is the right way to find a router. At Rutgers, it will never work. So if you find in.routed running, it probably means that when you brought your system up, it was unable to find a router. Perhaps the router was down at the time, or you were temporarily disconnected from the network. If so, you may be able to fix things by rebooting. This will cause Solaris to try in.rdisc again. If the router is now accessible, things will work.

If neither in.rdisc nor in.routed is running, then something is probably wrong with your configuration.

If in.routed is running, then you should investigate your network. Can you connect to other machines on your network? (Try /usr/sbin/ping 1.2.3.4, replacing 1.2.3.4 with the actual IP address of another machine on your network. Hostnames may not work at this stage, so you'll need the IP address.) If not, there is probably a problem with cabling or the network.

If you can connect to other machines on your network, then you will probably suspect a problem with your router. Can other machines on your network get to hosts elsewhere at Rutgers? If not, then the router is probably down. In that case, your departmental liaison should contact the Network Operations Group, using network-problems@tdmx.rutgers.edu.

If other hosts on your network can get out, and you can get to other hosts on your network, then there's a good chance that your router isn't running the service on which router discovery is needed. The Network Operations Group normally does not turn on this service unless they know there is a Sun on your network. Contact them, via email to network-problems@tdmx.rutgers.edu, and ask them whether IRDP is enabled for the router in your department. Make sure to include the IP address for your machine in the message.

Using /etc/defaultrouter

You can also specify the address of your router manually. You do this by creating a file /etc/defaultrouter, with the IP address of the router in it. You'll need to reboot after creating this file. An easy way to create is is with echo: 
    echo 128.6.1.1 >/etc/defaultrouter
Replace 128.6.1.1 with the actual address of your router. You'll need to get this from your departmental liaison or the Network Operations Group.

Once you create this file and reboot, "netstat -n -r" should show a default route. If it doesn't, then there is a configuration error on your system. Probably someone has changed something they shouldn't have. When /etc/defaultrouter exists, in.rdisc and in.routed are not run, because the default route is taken directly from that file.

The advantage of creating this file is that you know you'll always have a default route, even if something was wrong when your machine is booted. However there are disadvantages:

First, it requires you to find the address of the router. The Network Operation Group would prefer not to answer question from every individual who is setting up a workstation.

Second, sometimes router address changes. This won't happen on a routine basis. However, when a major change or upgrade is made to the network, the Network Operations Group may change or replace your router. The new one may have a different IP address than the old one. If you have created /etc/defaultrouter, you'll have to update it to have the new address. If you let Solaris run the router discovery daemon, it will find the new router automatically.

Thus Network Operations recommends that you not create /etc/defaultrouter, but depend upon the router discovery daemon.

Test network connectivity

At this point you may wish to reboot your machine and verify that you can reach other portions of the network. (Some of the changes above do not take effect until the next reboot.) I suggest the following test: 
    /usr/sbin/ping 128.6.4.4
You should see 
    mysun# /usr/sbin/ping 128.6.4.4
    128.6.4.4 is alive
If you see "no answer from 128.6.4.4", then you have a problem. It is possible that the machine 128.6.4.4 is down. (This particular machine should be one of the most reliable.) Other machines to try are 128.6.21.6 and 128.6.7.5. If you can't get to any of them, either you've got a problem or there are major problems with the campus network.

If you see the message 

    ICMP Host Unreachable from gateway geneva.rutgers.edu (128.6.26.11)
where the "gateway" is your own computer, you probably do not have a default route. Try "netstat -n -r" and verify that one of the lines has "default" in the first column. If not, see the previous section on setting up /etc/defaultrouter.

If you see a similar message, where the "gateway" is some other machine (probably with -gw at the end of its hostname), either the campus network is confused, or the hosts I've suggested no longer exist. (This is *very* unlikely. We have long-term commitments to the address 128.6.4.4.)

If you see "no answer" with no other error messages, it is possible that your have specified the wrong address in /etc/defaultrouter, that the campus network is confused, or that your system is somehow misconfigured in some other way.

Create /etc/resolv.conf and fix /etc/nsswitch.conf

This step is needed so that you can use hostnames to refer to other computers. Until you have done this, you will be able to connect using IP addresses but not names.

The first step is to create a file /etc/resolv.conf. It must contain at least two lines. A minimal file might look like this: 

    domain rutgers.edu
    nameserver 128.6.4.4
You can create it with a text editor, or simply using cat: 
    cat >/etc/resolv.conf
    domain rutgers.edu
    nameserver 128.6.4.4
    ^D
This file does two things: Note that it is possible to list more than one nameserver, one per line. This can provide backup in case one fails. The system will try them in the order listed.

Once you have set up /etc/resolv.conf, you must tell the system to use it. This is done by editing the file /etc/nsswitch.conf. You'll need to use a text editor for this. Look for the line starting with "hosts:". It will probably look like this: 

    hosts:      files
However if you're using NIS it might be 
    hosts:      nis [NOTFOUND=return] files
I recommend changing this line to read 
    hosts:      files dns
This tells the system to look up hostnames in /etc/hosts first, and ask the nameserver if it's not there. I do not recommend leaving "nis" in the list. If your nsswitch.conf already has "dns" listed, you may not need to make any changes to this file.

In case you prefer not to edit files, I've made a copy available in a public area called /sos/oss-dist/ru-dist. There are three subdirectories, ru-config.2.5.1, ru-config.2.6, and ru-config.8. These contain files referred to in this document, for Solaris 2.5.1, 2.6, and 8 respectively. For Solaris 7, I believe the 2.6 versions would work, but they haven't been checked.

If you haven't set up the automounter yet, you'll probably want to refer to the directory above as /net/alfred/sos/oss-dist/ru-dist. If name service isn't working you should be able to use /net/165.230.4.68/sos/oss-dist/ru-dist.

If you can get to the directory mentioned above, you'll find two files: nsswitch.files and nsswitch.nis. If you're using NIS, copy nsswitch.nis from this directory to /etc/nsswitch.conf. If you're not, copy nsswitch.files from this directory to /etc/nsswitch.conf. If you're using NIS+, you'll have to edit the file for yourself.

Testing the resolver setup

Once you've created /etc/resolv.conf and added dns to /etc/nsswitch.conf, you may wish to reboot your machine and make sure that these changes worked. (In general, changes to nsswitch.conf do not take effect until you reboot your machine. Experts know ways to avoid the reboot, but they vary from release to release, and do not always work.)

The easiest test to make is ping something using the name instead of the IP address. E.g. 

    /usr/sbin/ping ns1
You should get 
    ns1.rutgers.edu is alive
If the changes to resolv.conf or nsswitch.conf didn't work, you'll get something like 
    ping: unknown host ns1
possibly after a very long pause.

Set up printing.

At this point your system should be largely usable. The rest of these steps refer to particular services that need setting up. They should not affect operation of other things on your system.

Printing is probably the most complex thing to deal with under Solaris, and one of the most problem-prone. If you simply want to access printers on other machines, it's easy. But hanging printers off your own machine can be more complex.

Access to remote printers

Let's start with the easiest case. Suppose you want to use a printer that is attached to another Unix machine (or any other kind of machine that supports Unix "lpd" printing). Run Sun's admintool. This is a GUI system administration tool intended to simplify some common system administration tasks. Pull down the "browse" menu and select "printers". Pull down the "edit" menu, and select "add" and then "access to printer". You'll now get a little box that lets you enter the information about the printer. You'll probably have to get that information from someone who is responsible for running the printer: Once you've given the necessary information, click on "OK". After a pause (which may be quite noticable), you should return to the main admintool. It should now list this printer.

Access to printers on serial/parallel ports

This works fine if you're trying to access someone else's printer, but suppose you want to add a printer of your own. There are two ways to do this: add it as a local printer, or add it as a network printer. Under Solaris, a local printer is a printer attached to a serial or parallel port on the back of your machine. A network printer is one that you get to over the network.

First, attach the printer to the port on your machine. All Suns have two serial ports. Getting to them may not be easy: sometimes they require a special cable. But they're there. On some newer systems these same ports can also support parallel operation. We've used them in serial, but not parallel. If you want to try a parallel printer, make sure you don't commit to buying the printer until you see if it will work. On newer systems, e.g. the Ultra 10, parallel printers definitely work, because I'm using one. Once the printer is attached, go into admintool. Use the "browse" menu to select "printers". Pull down the "edit" menu, and select "Add" and then "Local printer". You'll now get a box that has a number of attributes about your printer. Most of them will be straightforward:

When you've entered all the information, click "OK". After a pause (which may be significant), the printer should show up on the printer list.

Access to printers with an Ethernet interface

We generally recommend getting your printer with an Ethernet interface. Unfortunately Sun does not support all of them. Printer makers have done their network support in two different ways:

The older way used a network connection just like a serial cable. You connect to the printer and send it the same commands you'd send if the printer is directly attached. Sun supports this mode, but not through admintool. If you have this kind of printer, see the Solaris 8 System Administration Guide, Volume 2 at http://docs.sun.com. The relevant chapter is "Setting up Printers (Tasks), in the section "Adding a Network Printer."

Commonly printers of this kind come with their own software. If you're using printers from HP, you can get printer software from HP's web site that will work with Sun's printing software to support their printers in this mode.

The newer approach puts enough smarts into the printer that it pretends to be a Unix host. We've seen printers from both Apple and HP that do this. With HP's JetDirect cards, you may need a firmware update to get this capability. (They're still shipping cards with firmware that is several years old.) If this is the approach you want to take, I'd verify before buying it that the vendor will take responsibility for making sure that the printer will implement the Unix lpd protocol.

If your printer implements lpd, you simply configure it as a remote printer. In admintool, select Browse and the Printers. Then select Edit, Add, and Access to Printer. In the resulting box, for "Print Server", use the hostname of the printer itself. The only problem I've seen with this is that some of the printers don't seem to know how to convert ASCII into Postscript. They treat all input as Postscript. If your printer has this problem, you *may* be able to fix this by using the following command: 

    lpadmin -d PRINTER -I postscript
where PRINTER is the name of your printer. However I've never tried it.

For more information on setting up printers, see the Solaris 8 System Administration Guide, Volume 2 at http://docs.sun.com. The relevant chapter is "Setting up Printers (Tasks).

Set up mail.

The big problem with mail is that there are a number of different ways to set it up. Some of them involve a lot of expertise. Also, the daemon used to receive mail has proven a source of security problems. Thus in the section on security, we are going to recommend that you not receive mail on your workstation. Instead, you can login to rci (or some other centrally run machine) and receive mail there. If you accept this recommendation, then mail setup on your own machine is easy. You'll probably still want to set your machine so you can send mail, since there's no security problem with sending, and some software will generate mail automatically. However in this section, I'll document a few common mail setups.

Note that all of this assumes you have configured your machine with is full name. That is, in the installation dialog, when you were asked for a hostname, we assume you used foo.rutgers.edu, and not just foo. Otherwise, you may get odd effects in mail. To verify this, use the command "hostname". It should print a name ending in .rutgers.edu.

Mail setup for Solaris 8

This section is for Solaris 8. If you are not using Solaris 8, please go to the next section, Installing sendmail 8.8.8.

Solaris 8 comes with a reasonable version of sendmail, the mail delivery daemon. However you'll need to make two changes, and you may want to make a third one

1) You'll want to go to /etc/mail, and edit the file sendmail.cf. Look for the following lines: 

# "Smart" relay host (may be null)
DSmailhost.$m
Comment out the second line by adding a # at the beginning. The result is 
# "Smart" relay host (may be null)
# DSmailhost.$m
If you don't do this, mail to anyplace outside of Rutgers will fail.

If you prefer not to edit files, an appropriate copy of sendmail.cf is available in /sos/oss-dist/ru-dist/ru-config.8. As usual, if that isn't set up, try /net/alfred/sos/oss-dist/ru-dist/ru-config.8

2) To prevent outsiders from using your system to create spam, you must create the file /etc/mail/relay-domains. It must contain one line: 

.rutgers.edu
A copy of /etc/mail/relay-domains is available in /sos/oss-dist/ru-dist/ru-config.8.

3) If your system isn't being used as a mail server, we recommend configuring sendmail so that it can't receive mail. It will still be able to send mail. But we will expect you to receive mail from a OIT or departmental server. To do this, create the file /etc/default/sendmail. It should contain the line 

MODE=""
For your convenience a copy of /etc/default/sendmail is available in /sos/oss-dist/ru-dist/ru-config.8. This change will not take effect until you reboot your system or type 
/etc/init.d/sendmail stop
/etc/init.d/sendmail start

Installing sendmail 8.8.8

This section is intended for Solaris 2.5.1 and 2.6. (This document does not cover Solaris 7. It's probably the same as either 2.6 or 8, but I'm not sure which.) If you are using Solaris 8, please go to the next section, Adding root to aliases.

Unfortunately the mail delivery program (sendmail) that comes with Solaris 2.5.1 and 2.6 is seriously deficient. It has many security holes, and it does not have critical features needed to protect your system against forwarding "spam". (See Dealing with Spam being forwarded by your system for why this is a problem.)

This means that you're going to have to install a new version of sendmail. Sun supplies an appropriate one as a patch. It is available in / rutgers/ref/sun-patches.

To apply a patch, cd to an area where you have free space, and then do something like this: 

     uncompress < .../105395-03.tar.Z |tar xf -
This will create a directory 105395-03. Cd into it and do 
     patchadd .
For 2.5.1, use the command "./installpatch ." (Yes, that's a dot at the end of the command.)

Once you have installed the new sendmail, you will need to fix the main configuration file, /etc/mail/sendmail.cf. This file is an arcane monster, but what you need to do is fairly simple. You need to make 3 changes. You may want to do this someplace where you can cut and paste from this document. You need to get all the punctuation and capitalization right.

In case you don't want to do this editing, I've put a copy of the fixed sendmail.cf on /sos/oss-dist/ru-dist/ru-config.2.6 and ru-config.2.5.1 as sendmail.cf.888. (sendmail.cf is for the original version of sendmail. You really don't want to use it.) Of course make sure you copy sendmail.cf.888 as /etc/mail/sendmail.cf.

This file can also be retrieved via the web: sendmail.cf.888. (It is the same for 2.5.1 and 2.6.)

In case you need to make the changes for yourself, here they are:

(1) Fairly near the beginning of /etc/mail/sendmail.cf you'll see a section "Local Information". Somewhere in that section add the following: 

     # relay for any Rutgers host
     CR .Rutgers.EDU
This is part of the code to prevent your system from being used as a relay for SPAM.

(2) In the same section, you'll see a line like this: 

    DSmailhost.$m
Remove it or comment it out, e.g. change it to 
    # DSmailhost.$m
This is necessary for you to send mail outside Rutgers.

(3) Somewhere in the rules section (I did it right before the major heading MAILER DEFINITIONS) add the following: 

    Scheck_rcpt
    # anything terminating locally is ok
    R$*                   $: $>Parse0 $>3 $1
    R$+ < @ $* . > $*     $: $1 < @ $2 >
    R$+ < @ $=w >         $@ OK
    R$+ < @ $* $=R >      $@ OK

    # anything originating locally is ok
    R$*                   $: $(dequote "" $&{client_name} $)
    R$=w                  $@ OK
    R$* $=R                       $@ OK
    R$@                   $@ OK

    # anything else is bogus
    R$*                   $#error $: "550 Relaying Denied"
The lines beginning with R must use tabs to separate the two columns. Since that's likely to be hard to get right, here's a file containing these lines.

This is code to prevent your system from being used as a relay for SPAM.

If your system is a simple, standalone machine, these instructions should be enough. However if it other systems have DNS entries that point to it (specifically "MX records"), you'll need to do one more thing:

Create a file /etc/mail/sendmail.cw containing a list of all systems for which you receive mail. It should contain one hostname per line.

Adding root to aliases

You will also want to edit /etc/mail/aliases. This file lets you create mail "alias". An alias is a name that people can mail to that isn't an actual user. Instead mail sent to it goes to one or more other users. The Internet standards require that you have an alias called "postmaster" on each machine that receives mail. This should be a person who can handle problems relating to mail. Most Unix systems also make "root" an alias for someone who can deal with problems on the system. For desktop systems or small departmental systems root and postmaster will probably be the same person (probably you). Sun gives you an alias file that defines postmaster as root. If you want postmaster and root to be the same person, you just need to add a line for root. E.g. to make root be mutt and jeff, you'd add a line 
    root: mutt, jeff
Whenever you change /etc/mail/aliases, you must run the program "newaliases" afterwards. This builds a binary database from the text file. The mail software actually uses the binary database.

Checking the version of sendmail

This section is not necessary for Solaris 8. If you are using Solaris 8, please skip to next section, Ways to use Mail.

Finally, make sure you've got the right version of sendmail. In older releases of Solaris, Sun includes two different versions of sendmail (the program that delivers mail), /usr/lib/sendmail and /usr/lib/sendmail.mx. If /usr/lib/sendmail/mx exists on your system, rename /usr/lib/sendmail.mx it to be /usr/lib/sendmail. Sendmail.mx is a version designed to use with the Internet. In 2.5.1 (and possibly 2.5), Sun has decided that everyone will want to be able to use the Internet, so the normal /usr/lib/sendmail has the necessary features. Thus in that release there is no separate /usr/lib/sendmail.mx.

Once you've edited sendmail.cf and put up the right /usr/lib/sendmail, you'll need to do something for it to take effect. If you're going to reboot at the end of this process, don't worry. If not, do the following: 

    /etc/init.d/sendmail stop
    /etc/init.d/sendmail start

Ways to use mail

OK, now for the various ways to set up mail.

First, the default. When Solaris is first installed, it assumes that you've got a typical small departmental setup, where mail is received on a single departmental server, and all the desktop systems mount /var/mail from there. Sendmail looks to see if /var/mail is mounted via NFS. If so, it sends all mail to the system from which /var/mail is mounted. That system is then responsible for maintaining the mail queue and managing the mail configuration. This is actually a reasonable configuration if there is a system in your department that is set up to receive mail for you. To use this configuration, for each client you must do two things: (1) Add a line like this to /etc/vfstab: 

     heidelberg:/var/mail   - /var/mail     nfs - yes intr,bg
Instead of heidelberg, use the name of your departmental mail server. Once you've added a line to /etc/vfstab, you'll need to reboot, or simply use the command "mount /var/mail".

(2) Send a request to hostmaster@nsmx, giving them a list of all of the machines that are going to mount /var/mail from that server. Ask them to create MX records so that mail sent to the clients is delivered to the server. Because all mail is sent to the mail server, you don't need to bother creating aliases for postmaster (or anything else) on the client systems. Note however that every user who is going to receive mail must have an account on the mail server (or you'll need to do some additional setup to let them receive mail without having an account).

The mail server needs no special setup.

If you don't want to have a departmental mail system like this, simply make sure that /var/mail is not in an area that is mounted from another machine via NFS. No other special setup is needed. (That is, the configuration changes I've listed above are sufficient for this case.)

Set up the automounter.

The automounter provides an easy way for you to NFS mount file systems on other machines. You can of course list all of the mount in /etc/vfstab. However if you do that, the files will be mounted all the time. This can slow down booting (because the system will wait to mount all of them before it comes up). Also, if some of the other machines are down, processes on your system can hang. With the automounter, the file systems aren't mounted until someone actually starts to use them. They're dismounted after a few minutes when there's no activity.

To use the automounter, you need to edit /etc/auto_master. In most cases the lines you add to /etc/auto_master refer to additional files in /etc, which must also be present. Generally you'll want to create a separate file for each group of directories you mount. That makes the system easier to maintain, and also lets you steal configuration files from us. I'm not going to give you instructions on how to edit the file, because there's good online documentation, which includes examples. Use the command "man automount" for details.

I'm providing some example files in /sos/oss-dist/ru-dist/ru-config.*. The files are auto_rutgers, auto_rutgerssrc, and auto_sos. These would go in /etc. If you don't have the automounter configured yet, you'll probably want to refer to this directory as /net/alfred/sos/oss-dist/ru-dist or /net/165.230.4.68/sos/oss-dist/ru-dist.

auto_rutgers is necessary for you access to /rutgers/ref and /rutgers/fonts. /rutgers/ref contains older Sun and Digital Unix software for which we have site licenses, including online documentation. You may not want to use the disk space to have a full copy of the online documentation. You can simply access it from /rutgers/ref.

auto_sos defines /sos/oss-media and /sos/oss-dist. This will eventually be a replacement for /rutgers/ref. It has the Solaris 8 distribution, the current Sun compilers, and all current Sun patches. Additional information will be added over time.

auto_rutgerssrc is necessay for you access to /rutgers/src/public, a repository of source code for various Unix software.

In addition to copying auto_rutgers, auto_rutgerssrc, and auto_sos to /etc, you'll need to edit /etc/auto_master to point to those files. You'll want to add the following lines: 

    /-              auto_rutgerssrc -intr
    /-              auto_rutgers    -intr
    /-              auto_sos	    -intr
There's a copy of auto_master with these edits in /sos/oss-dist/ru-dist/ru-config.*

Whenever you've changed auto_master or any of the files it points to, you'll want to tell the automount daemon to reread the files, by usin the command /usr/sbin/automount. (No arguments are needed.)

Set up users.

This is not a complete book on Unix system administration. So I'm not going to explain all about /etc/passwd and /etc/group. The easiest way to create a user is with Sun's admintool. Pull down the "Browse" menu and select "Users". You can then pull down "Edit" and select "Add" to add a new user. If your system is self-contained, that should be all you need to do. If you're part of a departmental system that uses NIS, you'll want to do this on the NIS master. When you add a user on the NIS master, it is automatically available on all the other systems in that NIS domain.

When creating a user, I recommend using the default settings for the "account security" section. This will set things up so the user has no password, but the first time he logs in, he'll be forced to pick a password. You'll need to specify a home directory. If you've used the default partitioning, home directories will go in /export/home. So the user smith's home directory would be /export/home/smith. However you may well have adopted a different placement. Type the path into the box provided, and click on Create Home Dir. The default settings for User Identity are probably OK, though obviously you have to decide on what user name to use. You may find it convenient to keep your usernames in sync with the names on RCI. So you might ask your users to create an account on rci, and then use the same username.

Think about what shell you assign. You'll probably want to use the same shell for everyone, though if a user already knows one, there's no reason not to let them pick a different one. The Rutgers public machines use tcsh. That comes with Solaris 8. With earlier release, the closest is csh (which Admintool calls C). If you are going to use RCI or ICI, you'll probably want to use tcsh or csh, just to keep things as close as possible. To see tcsh in Admintool, you'll need to choose "Other" and then specify /bin/tcsh.

You can let admintool allocate the userid and groups. However if you're going to be mounting disks from a departmental server, you'll need to make sure that you coordinate userids and groups. One approach is to use NIS. In that case, all accounts are created and managed on the server. If you don't do that, I suggest creating them first on the server, and then using the same userid on your machine. Security over NFS is by userid, so userid 1001 on your machine will have access to files owned by userid 1001 on the server, no matter who that userid is attached to. That's the reason you need to keep userid's in sync.

Be aware that Sun's software does not do as thorough a job of screening passwords. The usual Rutgers password program goes to great lengths to make sure your password can't be guessed. This is important, because one of the major ways of hacking systems is guessing passwords.

If you care about the security of your system, you need to be very careful indeed about choosing your passwords. The safest thing to do is to choose a password that passes the tests on RCI or ICI. (However you probably want to use a different password than your RCI or ICI one. One approach is to try changing your password on RCI or ICI. The first time you type the new password, it will check the rules. If your password is OK, it will ask you to type it a second time. If you abort at that point, it won't make the change. That lets you try out a new password to see if it passes the rules. Just in case anyone is watching, you may wish to change a character or two from the one you typed on RCI/ICI.)

You can also use Admintool to manage usergroups. Again, if you're going to mount disks from a server, you'll want to use NIS, or keep your groups in sync with those on the server manually.

Think about logs.

One thing to beware about on a Unix system is that the system itself creates log files of various kinds. These files take up space. If you're not careful, over time you can run out of disk space just from log files. Sun's install provides default cron jobs that run nightly. These take care of processing most of the log files. If you're just using Sun's software, this processing is probably enough. However if you install any of your own applications, read the documentation carefully to see if they create log files. If so, you may need to do something to keep them in check.

If something goes wrong with your system, it's possible for something to start writing continuous error messages to a log file. If that happens, you might run out of disk space before the midnight job has a chance to clean up. If you ever find yourself mysteriously short on disk space, try doing "du /var/adm". That will show you how much space is being used in /var/adm. That's where log files are normally kept. You might want to do that periodically, just so you have a feel for how much is normally in /var/adm. The file that tends to fill up due to errors is /var/adm/messages. You might also want to look through /var/adm/messages periodically just to see if something odd is going on with your system.

If you do "ls -l" in /var/adm/messages, the file lastlog may look like it's very big. However it's normally not worth doing anything about this file. It isn't as big as it looks (do "ls -ls" to see the actual file sizes), and it will come back very quickly if you remove it.

Adding Additional Software

Once you have Solaris up and running, you may want to add additional software. Solaris comes with a good basic collection of utilities. However there are a number of additional utilities and tools that Sun doesn't supply, but which are commonly used. For example, most systems in OIT use tcsh as their default shell and emacs as their default editor. Neither of these comes with Solaris.

Before bringing in new software, you need to think about where you're going to put it. Sun's software is mostly in /usr/bin, with X-related things in /usr/openwin/bin or /usr/dt/bin. You don't want to put your software the same place. When you upgrade or reinstall Solaris, you will often end up replacing those directories (or all of /usr) completely. Thus you want a separate place for your own software that Sun's installation procedures won't touch. Historically, we've used /usr/local for that. A lot of software from the net is intended to be installed in /usr/local. Normally the actual executable goes in /usr/local/bin. Support files go in /usr/local/lib or other directories under /usr/local.

On large OIT servers, /usr/local is often its own partition. However for the people who are likely to be using this document, we recommend putting /usr/local in either /opt or /export/home. The instructions on partitioning included setting up this link.

For Solaris, Sun has established /opt as the place to put extra software. Sun's languages and other "unbundled" software installs in /opt. While much of the software you get from the net installs by default in /usr/local, a growing number of packages now go into /opt. Often packages intended for /opt go into a directory that's specific to the package. For example, Sun's languages go into /opt/SUNWspro. This makes it convenient to manage the individual packages. But it can complicate running the software. The executables that a user will want to run are in /opt/SUNWspro/bin. Sun assumes that every user will put /opt/SUNWspro/bin into their path. That's fine as long as there is only one package. But if every piece of software has its own subdirectory in /opt, with its own bin directory, paths become unreasonable. Thus some software installs the actual executable in a common directory, /opt/bin. If you have a number of packages that go into private /bin directories, you may find it convenient to make symbolic links from /opt/bin to the actual exectuables for each package. For example, the Fortran 77 compiler is /opt/SUNWspro/bin/f77. I would recommend making it easy for users to find it, by doing 

   ln -s /opt/SUNWspro/bin/f77 /opt/bin/f77
You may find that you get both software that expects to be put in /usr/local and software that expects to be put in /opt. It's up to you how to handle that. My inclination would be to use only /opt. If possible, I'd build the software to go in /opt. Rather than using /usr/local/bin and /usr/local/lib, I'd use /opt/bin and /opt/lib. Normally the installation instructions will tell you how to specify the directories in which the software should go. If you get software that should go into /usr/local/bin, and you can't easily modify it, an obvious alternative would be to make /usr/local a symbolic link to /opt: 
   ln -s /opt /usr/local
Don't forget that you'll have to put that symbolic link back anytime you reinstall Solaris (since that will completely recreate /usr).

Whereever you decide to put new software, make sure that users' paths are set up correctly. For example, if you put all new executables in /opt/bin, you'll need to add /opt/bin to all users' paths. You can ask all users to put an appropriate "set path" statement in their .cshrc file (if they use csh or tcsh) or "PATH=" in .profile (if they use sh, bash, or ksh). There are also system-wide files you can tailor, but they do not work in all cases.

With older releases, the first new software you put up should be Netscape. That's an essential tool to get to other software on the network. However Netscape comes with Solaris 8, so you can skip the next paragraph for Solaris 8.

The most convenient way to get Netscape is using Netscape, by connecting to Netscape's web site. If you don't already have a copy of Netscape, you can also get it using ftp. (An ftp program comes with Solaris.) Here's an example. What you type is emphasized. Unfortunately you probably won't be able to use this example exactly. I'll explain why afterwards.

>mkdir netscape
>cd netscape
>ftp ftp.netscape.com
Name (ftp.netscape.com:hedrick): anonymous
331 Guest login ok, send your complete email-address as password.
Password: user@host
ftp> cd /pub/navigator/2.02/unix
ftp> binary
ftp> get netscape-v202-export.sparc-sun-solaris2.4.tar.Z
ftp> quit
>uncompress netscape-v202-export.sparc-sun-solaris2.4.tar.Z
>tar xf netscape-v202-export.sparc-sun-solaris2.4.tar
In the example, you do the following: Unfortunately, the exact file name at netscape is likely to change. /pub/navigator/2.02 is where release 2.02 of Netscape Navigator is stored. By the time you read this document, the current version may be 3.1. In that case, the name is likely to be /pub/navigator/3.1. You'll probably need to use the "cd" and "ls" commands inside FTP to look around. E.g. after connecting, you can do
ftp>cd /pub
ftp>ls
If there's still a navigator directory, "cd" to it and do "ls" again. You may find releases 3.0 and 3.1 rather than 2.02 and 3.0. Decide which one you want, and cd to it, etc.

Once you've found the right file and brought it in, you'll uncompress it and extract the files, following the example above. This will leave you with a bunch of files. One of them should be called README. Look at it. That should contain the actual instructions for installing Netscape. In the current release, I find the instructions fairly confusing. At a minimum, you need to put the file called "netscape" whereever you want your executables to be. That's probably /usr/local/bin or /opt/bin. As explained in the README, you may need to put XKeysymDB in /usr/openwin/lib/X11, if you get a lot of errors about undefined keysyms. If you want to be able to use Java (which you probably do), you need to move moz2_02.zip to one of a list of directories given in README. I recommend /usr/local/lib/netscape. If you don't have such a directory, you'll have to create it.

Once you have netscape working, you can start looking around for other software. This software is generally available to the Rutgers community via the TINT software distribution. I recommend looking at TINT. Unlike our previous software system (Track), TINT can be used to install single packages in which you are interested. You don't have to make major changes to your system to use TINT.

TINT is documented at the TINT web site. See "getting started." Note that by the end of 2000 we will move to RPM to distribute software. RPM is a standard software distribution system, used with Linux and other Unix-based operating systems. However I recommend using TINT in the meantime.

Another good source of Solaris software is at Sunsite, a software repository maintained by the University of North Carolina with support from Sun. Specifically, we suggest that you look at the section Free Software ported to Solaris. Software in this collection is in Solaris package format. Thus you can install it using "pkgadd", the same tool that is used to install Sun's software and most other commercial software for Solaris.

Security

Unix security is an incredibly messy topic. If you're running a system like Eden, where 30,000 students login, security can be impossible. However on a typical faculty desktop system, it should be fairly easy to get a reasonable level of security. You need to operate under the following assumptions: So to secure your machine, you need to do the following: Before I go through these things, I'd like to suggest one overriding rule:

You should look at /var/adm/messages, and all other log files. You should now and then do "ps -ef" and "who". You should have a feeling for how much free disk space there should be and how busy the processor should be. If you start seeing unexpected messages, or unexplained usage, investigate. If you have other users, know what they're doing and when. If you see them doing things you wouldn't expect or working at times you wouldn't expect, investigate.

The Rutgers Open Systems Support group (OSS) has a good section on Solaris security in the OSS web page. I'd start there before reading the other resources recommended in this section.

As another general piece of advice: Considering reading the newsgroup comp.security.unix on a regular basis. They have FAQ listings with lots of good information about security, and you'll see notices of security-related bugs there. If you find it too verbose, at least look at comp.security.announce. That contains important announcements about security problems.

Also read ru.comp.dev. That's a Rutgers newsgroup for system administrators. We'll announce security fixes we know about (though we may be a bit vague about the problem). At least look in ru.comp.dev for the weekly "Patch Club" announcements from Sun. This will list fixes for the operating system, including security fixes.

Periodically, you should take a look at the list of recommended patches from Sun. These are in /sos/oss-dist/sun/patches, SolarisNNN.PatchReport, where NNN is the version of Solaris you are running. Those files contain a list of all patches available for that release. Near the beginning, you'll find a list of Recommended Patches, and a separate list of Security-related Patches. We recommend installing all Recommended Patches. You should at least install the Security-related patches. (The recommended patches will also show up in the weekly Patch Club bulletin. However the PatchReport files contain a summary of all recommended patches, while the weekly Patch Club contains only new patches. Thus the PatchReport will let you catch up in case you missed something in Patch Club.)

You need to be more careful about security if you have more users and run more services. If you're running a machine that only you use, and use some of the more careful options described below, you may get away with paying less attention. As a minimum, you should periodically check the PatchReport file, and you should upgrade to new releases of Solaris within a year after they are released.

If you are running a multi-user machine, you're going to have to put some time into learning about Unix security. A good place to go for general information on security is CERT, the Computer Emergency Response Team. Their web site is http://www.cert.org/. On their top level web page, you'll see a pointer to their FTP archives. In those archives, start by looking in the tech_tips directory. You should read carefully at least UNIX_configuration_guidelines, intruder_detection_checklist, root_compromise, and security_tools.

For multi-user machines, I recommend using the TCP Wrappers (which are described in the security_tools directory at CERT). Set up all the entries in /etc/inetd.conf to call the daemons through tcpd. Set up syslog.conf to forward the resulting log entries to another machine where security is better. (Most likely this would be the desktop system used by the system administrator. Such systems should be run as paranoid single user systems.) To do this, add a line like 

     auth.info            @foo.rutgers.edu
where use your own host rather than foo.

TCP wrappers do two things for you:

Both of these can be useful. For small departmental machines, you may be able to find out in advance exactly what services your users need. If for example you find that your users only need to be able to connect to your server from their own desktop machines, and from the dialups, you can configure the TCP wrappers to only allow those connections. If the desktop systems are run properly, this could significantly reduce your exposure. Logging becomes useful if any problems occur. The first thing most hackers do is remove all evidence of what they've done. If you are logging all connections to another machine, you'll have some idea of where they came from and how they got in. Of course they may start by disabling the TCP wrappers. But you should at least see the first connection they made. And the fact that you suddenly stop getting logging information will make the fact of the breakin immediately obvious.

Now for some details:

Accounts

Historically, the biggest security holes in any system are due to people. Left to themselves, people choose bad passwords. You explain the issue very carefully, and they still choose their girlfriend's first name, their license plate number, or their hobby. All of these are things an attacker can easily find out. They are also things that tend to be common. On most machines, you can try a common female first name, and just go down the list of users. At Rutgers, the easiest way to avoid this is to insist that people try out passwords using the ICI or RCI passwd program. (You may want to copy it to your machine, though I wouldn't call it "passwd". The problem is that if you run it on ICI or RCI, you've got to assume that someone is watching what you type.)

Another common people-related problem is people giving out passwords. One of the major techniques for cracking a system is "social engineering". Hackers get very good at calling people on the phone and getting them to give out their password. They will often do a lot of advance preparation, so they know a lot about the institution and department. Their stories can sound very convincing. Note however that actual authorized staff will not ever ask you what your password is. If someone asks you your password, you know they are a hacker, no matter how plausible their story. The only exception I can think of is that sometimes when you are having a problem logging in, staff may need to know your password in order to duplicate the problem. But we normally go to great lengths to avoid that. Even in the case where you are having trouble logging in, you should only give your password to someone in person, when you can verify who they are. And even then, it's probably a hacker.

Because there are so many security holes in Unix, you've got to assume that if someone can log in, they can eventually find a way to become root. (This isn't unique to Unix. Similar holes exist on other systems. Unix just gets more publicity.) This makes system administration of a public machine very challenging. For typical faculty machines, the answer is simpler: don't give anyone else an account. Of course you may need to give accounts to your colleagues or staff. But if you do, realize that every account you give is a potentional security hole. You have to make sure they don't give their password to a friend, a student, or their children. The latter is an easy to way have the entire student body of a local high school using your machine.

At Rutgers, faculty often hire students to act as system administrators. If you need knowledgeable help, this can be a great idea. We have lots of talented students, many of whom know about as much as our professional staff. However you should be aware that we know of cases where student system administrators are also hackers. I'm not sure how you can tell whether a student is trustworthy or not. One possibility is to ask the eden support staff. They keep records of hacking incidents. However I'm not sure whether they can legitimately give you that information.

Disable all daemons that you don't absolutely have to use.

Assuming that everyone on your machine is trustworthy, attacks are going to come from outside. Most outside attacks are based on security bugs in network daemons. Systems have been attacked through bugs in the daemons for mail, finger, and printing. The ideal approach for running a security machine would be to disable all incoming network connections. There's not much security risk to running programs like telnet or ftp from your machine. The risk is running the daemons that let people telnet or ftp to you. Historically the most serious problems have been in sendmail, the daemon that receives mail.

One obvious strategy at Rutgers is to do activities that require incoming connections on OIT machines. E.g. if you want to make files available for others to FTP, make them available on RCI. Have people send you mail on RCI. If you want to clamp down on daemons, I know of five major things to look at:

inetd.conf

Most daemons in Unix run from a central dispatcher called inetd. The file /etc/inetd.conf tells it what to do. My suggestion would be to go through that file and comment out all of the entries that you don't actually need. In some cases you might comment out every entry except the ones labelled "echo". (If you comment out echo, it could cause the Network Operations Group problems.) Assume that an entry is guilty until proven innocent.

Here are some entries you may want to leave in:

Telnet: If you want to use your machine from home, you'll probably use telnet to get to it. Telnet is fairly safe. It hasn't been a source of problems historically. The main danger here is that people can see your password when you type it. See the discussion below on network snooping. A good way to deal with that is to use a one-time password at home. See below.

Ftp: If you work at home, you may want to use ftp to get files to your computer at work. This may make you want to run the ftp daemon. While I have to admit that I do this, I need to warn you that the ftp daemon has been a continuing source of security holes. I know of no holes in the current program, but where there's been one bug I normally suspect there are probably others. A way to avoid this would be to use your account at RCI as a drop off.

Finger: This is controversial. A lot of people like to have the finger daemon running, so people can find out whether they're around. However security experts recommend against it. When someone wants to break into your machine, the first thing they need to do is to find out about the machine and users. Finger is a great way to do that. I'd be inclined to recommend against running it. A bug in finger was one of the major holes used in the famous Internet worm a few years ago. (That bug is fixed now, of course. But where there was one bug...)

sendmail

Now for sendmail. Historically, sendmail has been the biggest source of security problems on Unix. However in all honesty I have to say that it has been getting better. I'm no longer sure that it's appropriate to be paranoid about sendmai.

Sendmail is used for both sending and receiving mail. Sending mail is not a problem. However receiving it is. The only safe approach is not to receive mail on your machine. The section above on setting up mail tells you how to do this. Under Solaris 8, you create a file /etc/defaults/sendmail containing MODE=""

For older systems, you could do the following: Type "/etc/init.d/sendmail stop" and remove the file /etc/rc2.d/S88sendmail. (If this file doesn't exist, try "ls /etc/rc*.d/S*sendmail")

In this scenario you would read your mail on RCI or some other large system on which you have an account. There are other reasons to want to do this anyway: managing a reliable mail system requires some time and expertise. If for some reason you still want to run sendmail on your system, make sure you look at /var/adm/messages regularly for odd events, and make sure you read the newsgroups comp.security.unix and ru.comp.dev, and stay alert for signs of problems with sendmail.

lp

The following comments apply to Solaris versions before 8. I'm not as suspicous of the version 8 print system.

Lp is the Solaris print system. It runs a daemon, lpsched. This daemon sends and receives printouts. When you use Admintool to set up a printer, it sets things up so that lpsched can receive printouts from the network. I know of no specific security problems in lpsched. However the program is not well written, and it's reasonable to believe that security problems will be discovered in it. If you not need to act as a print server, you might want to turn off listening to print requests from the outside. This is appropriate if you use printers on other machines, but no one else uses a printer on your machine. The following two commands will turn off listening: 

     pmadm -r -p tcp -s lpd
     pmadm -r -p tcp -s lp
This is a good reason to buy printers that have their own Ethernet interface: it means that a whole department can access them without needing to make anybody's computer a print server.

NFS

NFS is the network file system. This is the way you mount file systems on other computers. There are various issues with NFS. Unless you become knowledgeable about it, I'd avoid acting as an NFS server. There is no problem mounting disks from other systems. The problem is in making your own disks available. Solaris startup will only start the NFS daemons if you have actually defined disks to share (in /etc/dfs/dfstab). If you want to share data among several machines in your department, I would be inclined to keep all shared data on one server. That server will have the security risks of NFS, but desktop systems that mount it will not. (However see the section below on making sure that the security of your system isn't undermined by another one.)

X

X is the window system used by Unix. It's a network-based system. The software that runs on your desktop is actually a server: X-based application program connect to your X server in order to put things on your screen and get input from your keyboard and mouse. Unfortunately, X has some serious security risks. Anyone who can connect to your X server can take over your machine. They can type anything into any of your windows (among other things).

There's two ways to control who can connect to your X server. In the more secure way, you use a script called xrsh to initiate X connections. That script logs you in on another machine and starts an X application. It puts information on that machine that is essentially a password. The less secure way is to use "xhost" to allow access from that machine. (There's an even less secure approach: "xhost +". That allows any system in the Internet to hack you. Unfortunately some documents and manuals tell you to use "xhost +". Don't.)

Both xrsh and xhost have similar risks: they allow other people on the machine you're connecting to access to your X server. xhost does this overtly: "xhost foo.rutgers.edu" allows any user on foo.rutgers.edu to get to your X server. xrsh is more careful. It puts a file in your home directory on the other machine, and protects it so only you can read it. Unfortunately, security on many of our machines isn't very good. You've got to assume that there are people on the other machine who have managed to become root. (This is definitely true on any machine with large-scale student use, such as eden.) They can look at the file.

There are three approaches to X security problems:

The third approach is probably the easiest. If you want to connect to rci, open a local window by running xterm, and then telnet to rci from that window. To help you keep windows straight, you might want to put a label on it, e.g. "xterm -n rci". If you're using csh or tcsh, you might want to create a simple alias to make this easier, e.g. 
    alias connect "xterm -n \!:1 -e telnet \!:1"
You can put that definition in your .cshrc file. Now if you say "connect rci" it will open a new window and telnet to rci.

The only problem with this approach is what to do if you run a command on the other system that needs X. Unless you've done something special, it won't be able to get to your X server. (The error message will say that it can't open your X display.) This will depend upon what software you use. If you don't use any X-based software, put "unsetenv DISPLAY" in your .cshrc file on the other machine. This will disable X. If you need to use some X-based software, you'll have to briefly enable access from that machine as you start it (using xhost +machine and then xhost -machine). You may wish to set emacs so it doesn't try to use X. The simplest approach is to add 

     alias emacs emacs -nw
to your .cshrc file on the other machine.

Look carefully at your pattern of network use.

One major security issue is the fact that networks are not always secure. However the details depend upon how your network is set up. The following paragraph DOES NOT APPLY if your network is set up using switches. Most new networks, including all networks funded by RUnet 2000, are being done this way.

When you make a connection to another system, anyone with a PC on your departmental network, or on the network that the machine is attached to, can watch what you're typing. So can anyone who can become root on Unix machines on those networks. The most serious threat is that they will see your password as you type it. However there are more obscure dangers. In theory it is possible to "hi-jack" a network connection. That is, once you've logged in, in theory someone else can take over your network connection.

There a couple of reasonable approaches to this. You'll probably have to look at it separately on both ends. In your department, make sure you put machines with different user communities on different networks. Don't put a public or student-oriented lab on the same network as your faculty's workstations. Anyone in the lab could watch what your faculty type on the network. Even if you don't have a lab on the same network, you are still at the mercy of other faculty on the same network. If they aren't as careful as you are, someone can break into their machine and then watch your traffic. (In one case, a faculty machine was taken over completely by hackers. They even started running their own system backups, over a trans-Atlantic Internet connection.)

Many of these problems can be avoided by using switches for your network. These prevent other systems on the network from seeing your network traffic.

It is more difficult for you to protect the other end. It may also be less important. If you're connecting to a large public machine such as RCI or ICI, you've got to assume that their security is completely compromised. It doesn't matter whether hackers can watch the network, since the hackers are on the machines themselves. You can watch network traffic involving a machine from the machine itself, as well as from the network it's connected to.

OIT does do a good job in protecting network security for modems. So if you can secure your departmental network, you can safely log into your machine over a modem. However when it comes to accessing a central machine such as RCI or ICI from your system, you've got to assume anything you type is compromised. That means that you should use a different password on your own machine from your RCI or ICI password (since that one will be known), and you should make sure you never type your own password in any connection to the central machine. You should make telnet connections, and not X connections, to the central machine. If you absolutely must use X, do xhost +machine, start the application, and then immediately do xhost -machine, or do xrsh and then immediately remove the .Xauthority file that it creates.

If you're getting to Rutgers through an Internet Service Provider rather than through OIT modems, be aware that their security isn't always very good. Their public machines will be no more secure than those run by OIT, and they may well be worse. If you log into a machine at an ISP, you should assume that anything you type can be spied on. If you only use their modems, you may be OK, but someone would need to make an assessment of their networking setup to be sure.

See if your system depends upon another machine

It doesn't do any good to be paranoid in how you set up your own machine, and then let it be compromised by what someone else has done. It's surprisingly easy for this to happen. All I can do here is list some of the more common problems. Note that these dangers typically come up for departmental clusters of machines. If you have a single workstation, and you've followed the guidance in the proceeding sections, you shouldn't have these issues. For those systems, I've recommended not using NIS, not exporting file systems via NFS, not running any daemons other than telnet, etc.

If you use NIS, the security of your machine becomes dependent upon the security of the NIS server, and to some extent the security of the network itself. If the person running the NIS server doesn't know what they're doing, it can act as a point of entry for remote attacks. The main danger is that usernames and passwords now come from NIS rather than /etc/passwd. So if someone can compromise the NIS master, they can log into your machine. In some configurations they may also be able to compromise you by changing netgroup or other maps. In some environments NIS is hard to avoid, e.g. in a lab situation where there are a large number of machines with the same set of users. However if you are administering your own desktop machine, and you have only a few users, I'd be inclined not to use NIS.

If you mount files from another system via NFS, you need to think about the security issues. Suppose you have a departmental file server that that stores all your files. Your home directory is there. You mount it via NFS. Now suppose someone breaks into the departmental server. They can then change your files. They can do things like change your .login, so the next time you login, you'll execute their commands on your own machine. A clever person can do this in a way that you won't see, and delete all evidence that it happened. (Lots of hackers are clever people.) To protect against this, I suggest the following two rules:

There are a set of utilities that let you do things on other machines without typing a password. Examples are rlogin and rsh. These can present security problems. In order to use them, you must configure one machine to believe the other about who you are. This is done with the file .rhosts in the user's home directory (and if you're really brave, hosts.equiv). If you have a set of machines with the same system administrator, who depend upon a common NIS database, you may not lose much security by allowing the r-commands among them. This is particularly true if home directories are all on the server. These systems are so dependent upon each other from a security point of view that it makes no sense to try to protect them from each other. However in other situations I wouldn't allow the r-commands. The easiest way to disable them is in /etc/inetd.conf, by disabling the daemons.

The problem is, if you're in a situation where you want to allow them among a cluster of machines, it's difficult to avoid accepting a wider risk. Once you allow the r daemons to be run, a user can set up his .rhosts file to allow people anywhere on the Internet to connect without a password. This can happen by accident, or because a user didn't quite understand what they were doing. If you are going to use this, you'll want to use tcpd, a utility that allows you to control what hosts a daemon can be accessed from. This is not a standard Sun program, but it's widely used at Rutgers.

There are other issues with these daemons: They depend upon verifying the address of the machine the user is coming from. Typically .rhosts files are written in terms of hostnames. In principle it is possible to compromise the DNS system used to map IP addresses to hostnames. This can allow someone to pretend to be a host that's listed in .rhosts. Using tcpd to limit the hosts you'll accept access from will help this problem. (It uses a somewhat more paranoid method than usual to validate hostnames.)

If any of your security measures depend upon validating hostnames, you'll need to worry about the security of your name service. The most common cases where this comes up is with the r-daemons, and with NFS. The r daemons use .rhosts and hosts.equiv. Normally those contain lists of hostnames that you'll allow connections from. When a user tries to connect, it's necessary to turn the IP address he's coming from into a hostname. This is normally done by asking the nameserver listed in /etc/resolv.conf. If you are an NFS server, there is a similar issue: NFS servers normally list the hosts they'll allow to mount a given file system.

So if you are using these services, you need to think about the security of your nameserver. The primary OIT nameservers are run on dedicated machines with careful system administration. But if you use another machine (e.g. because it's nearer) it may not be as secure. Some system administrators prefer to make entries in /etc/hosts for all machines on which their security depends. That way, the system uses /etc/hosts rather than the name server to evaluate those names.

There are more abstruse dangers as well, such as someone on the same network you're on masquerading as the nameserver and giving you bad information. (It is harder to do such a masquerade through a router, because of the way Rutgers configures our routers.) In general as soon as you start down a path involving NFS, NIS, and the r-commands, you need to have a single person administering all of the systems on your network, and make sure that security is competent on all of them.

The last danger I'm going to talk about in this category is netscape (and other web browsers). Current versions of netscape support Java. With Java, it's possible for the author of a web page to include a program with his page. That program is loaded into your copy of netscape and run. There's an obvious danger here: what's to prevent someone from written a Java program that deletes all your files? In principle, Java contains a special program-checker that keeps programs from accessing files outside a specially defined set. However bugs have been found in Java's security. It's not clear how serious a problem this is. I only use netscape to look at information supplied by vendors, and INFO. I seriously doubt that IBM or Sun are going to delete my files. However if you do more widespread net surfing, this can become an issue. If you look in the options section of netscape, you'll find a Java security section. It is possible to disable the use of Java. You might want to do that, at least until Java has had a chance to mature.

Incidentally, the same issue is present with other web technologies that involve loading programs. I'm even more worried about Microsoft's activeX than about Java. Java checks all programs before they run, to make sure they don't do anything to your system. While bugs have been found in it, Sun has been very good about fixing them, and it's been a while since I've seen such a bug. activeX does not do this sort of checking. An activeX program can do anything it wants to your system. The same thing is true of the various "plugins" and helper programs that you load over the network. Make sure you trust the people you get any of these things from. Java is by far the safest technology of this sort.

Rutgers authentication

Rutgers has an authentication architecture, intended to support services such as Kerberos and Enigma one-time cards. Support is done via a library, /usr/local/lib/libru.so. The same code is also available as a PAM module.

Under releases before 2.6, Rutgers had to replace every program that processed passwords, e.g. login, ftpd, etc. We used BSD source, and built the programs with libru to do authentication.

Under 2.6, Sun is consistently using PAM for password processing. This allows us to supply a PAM implementation of the Rutgers authentication, and then use normal Sun software. Libru is still present, because it's easier to use. Thus when we take normal Internet programs, e.g. the IMAP daemon, it's a lot easier to convert it to use libru than PAM. However we are no longer replacing telnetd, login, etc., with versions that use libru. We're using Sun's code, with PAM.

libru and PAM also do some additional things involving setting up the environment and checking for valid groups.

For details, see /sos/oss-dist/ru-dist/README.

BACK TO TOP

For more information, contact hedrick@rutgers.edu.
Last updated: Tuesday, 31-May-2005 12:25:03 EDT
© 2005 Rutgers, The State University of New Jersey. All rights reserved.