Last updated: 3 Oct 2003

Sun Servers

Two SunFire V480 computers are available for graduate research and projects. Currently, both are identical in hardware and software. They are named:

• rigel.insttech.washington.edu
• vega.insttech.washington.edu

Accessing the Sun Servers

There are no consoles attached to the Sun servers. Another computer can be connected as a console to the server via a serial cable and special adapter, or, if so configured, by an Ethernet connection. However, if you are not interested in restarting a Sun server or specially configuring it, there is little need for console access.

Normally, you connect to a Sun server via an ssh client or an X client. Both provide secure connections.

Access to the Sun servers is restricted to those explicitly authorized by faculty or staff. The reason for the restriction is due to some students using computers for computations not related to their academic work.

As with other connections to remote servers, all you need to know is the name of the remove server (see above), your INSTTECH login name and its password. Windows login authentication is always used for Linux and for Solaris systems -- this reduces time spent on your password management and drastically reduces the time spent on management of the user accounts on these systems.

Unfortunately, sometimes there will be problems with logging in. There are some common cases:

1. password was never set or has expired

   If you have never logged onto your Windows account on a lab workstation, your password needs to be changed from its initial value. This situation will prevent you from logging into any remote server because Windows authentication isn't in the correct state to allow logins. The solution is to be login to a lab workstation, set your new password, and thereafter you can remotely login.

   Your account enters into a similar state as a first-time-use when your password has expired, and the solution is the same.

2. account is locked out

   Your Windows login account is automatically locked out if there are more than three failed attempts to login. It will unlock automatically after a preset time (about 15-20 minutes). Lab staff can unlock it sooner than that.

   Sometimes, it is not you who has caused the account to lock, but some external hacker who is trying to break into your account. Generally, the attack will stop after the account gets locked out, so just by waiting the preset time noted in the preceding paragraph, the account will automatically unlock.

3. Server connection is lost

   If you receive this message after entering a correct password, that login name is denied access to the server. This could be legitimate, or it could be due to slow recognition of group membership, which controls access to the servers. If someone you know has root privileges, stopping then starting the Name Service Caching Daemon (nscd) can help:

     /etc/init.d/nscd stop
     /etc/init.d/nscd start
   

   Then try logging in again.

   Another possibile resolution for a root user is to change the file controlling access, which is /etc/security/pam_script.allow.

You must login at least once to create local home directory file space for your account.

File Spaces

Currently, each server has its own file space -- nothing is shared between the computers. If you have accounts on both servers and have logged into both, you can share files via secure ftp or copy commands. Secure ftp is available from within an SSH client window; secure copy (scp or scp2) is issued from the command-line.

To access your Windows home directory, you can use the smbclient tool, which provides an ftp-like (command-line) tool to transfer files. Your Windows home directory is available as a network share, which is named the following (substitute your login name for "uwnetid"):

  //itfiles/uwnetid$

Backups

Ultimately, you are responsible for backing up any files you deem necessary for your work.

Currently, there is no backup device attached to the Suns. Instead, daily backups of home directories and some configuration files are performed over the network to another computer.

Backups are retained for seven days. Lab staff may be able to restore your files from those backups, but any changes made within one day are not recoverable... unless you back up your own files more frequently.

Software

Currently, there is a minimal amount of non-Solaris software installed. Here is a list of what was explicitly installed by lab staff; Sun support technicians may have installed other software (e.g., Java 2 VM 1.4.1):

• gcc
• samba 2.2.7a
• pvm and xpvm

Installing Software

Generally, you need to be running as root to install software. Due to the use of Windows authentication via samba and winbind, as well as Sun's restrictions on their name-switching service, you cannot directly login as root or any other account in the file /etc/passwd. Instead, you must use the "ssu" script, which will use "su" to login to root -- if you know the root password.

So that others may know the changes made to the system, you must record your changes (such as installed software) by sending email to the appropriate tracking system below. Please include a descriptive subject line, and put specific information about what was installed and how it was installed in the body of the email.

• rigel
• vega

Sun has its own package management system. Once a package is saved to disk or on a CD/DVD, you can run the "pkgadd" command to install it. Enter:

  man pkgadd

Other software comes in what are sometimes called "compressed tarballs". These are compressed archives of directories and files, very similar to ".zip" files in the Windows environment. Often, "gzip" will have been used to compress an archive, which is nearly always an archive created via the "tar" command -- a "tarball". If someone knowledgeable created the tarball, it will create the appropriate subdirectories for you when you extract the files; otherwise, it will just dump files in the current directory, which can be messy to clean up. So it is usually a good idea to peek at the structure of the compressed tarball first (presuming a gzipped tarball called "thispkg.tar.gz" in /tmp/mypkgs):

  tar -ztvf /tmp/mypkgs/thispkg.tar.gz

  cd extractdir
  tar -zxvf /tmp/mypkgs/thispkg.tar.gz

Change Log