Overview of PIRL systems

Where do I find out how to do what?

Both new and experienced users' best bets to finding answers are the PIRL sys mailing list, these Web pages, and by visiting the PIRL user's room, located in Space Sciences room 429D.

In the PIRL users room you will usually find a few of a small army of PIRL graduate students that are quite knowledgeable about the workings of the system. If one of them can't help you, they can usually point you towards someone that can. In addition a fair percentage of the LPL community are also PIRL users. If you need to know something, ask!

Below are a few "action" items of new procedures that are of general interest to all users.

Changing your password

The command "yppasswd" is obsolete. You need to use the command passwd.

Note for old users

You may also get prompted for your network password, which depending on when your account was created, will either be "PIRL" or "nisplus". Note: This will not apply to any new (post year 2000) PIRL users.

Please use "secure" passwords - i.e. mix case, letters, numbers, funny shift characters. Please do not use the name of your spouse, dog, name spelled backwards, or any character names from the "Lord of the Rings", etc.

This is what you should see when you change your password:

% passwd
passwd:  Changing password for user
Enter login(NIS+) password: 
New password: 
Re-enter new password: 
NIS+ password information changed for user
NIS+ credential information changed for user

PIRL general use and affiliated user systems

deimos.lpl.arizona.edu
enceladus.lpl.arizona.edu
jupiter.lpl.arizona.edu
luna.lpl.arizona.edu
phobos.lpl.arizona.edu
tethys.lpl.arizona.edu

All other PIRL and affiliated systems are not for general access. Contact the owners of those systems for permission to use them.

Remote Access

Please do NOT use "rlogin", "telnet" or "ftp" to remotely log in to the system. Use the secure shell (SSH) clients instead. If you need a SSH client, we have information on obtaining one. Please start here.

Description of PIRL global login scripts

We presently support global login scripts for csh and tcsh users. If you are still using csh, well, you don't need to, you are subjecting yourself to unnecessary pain. There is no reason why you shouldn't be using tcsh instead. Please ask PIRL sys to change your login shell to tcsh. If you don't know why you should be running tcsh, ask! If you are unsure of what shell you are using, type "echo $SHELL" at your command line. If you want to use bash, we're happy to set you up with it, but bash is still unsupported on the Sun boxes.

The global login scripts "localize" your environment to make sure that you have command-line access to all applications loaded on to the PIRL systems. You'll see references to the global logins in your .cshrc and .login. Don't remove those references. When modifying your .cshrc, make your local mods AFTER the global reference, and in your .login, before. Remember that the .login is run only once, when you first log in, and your .cshrc is run for every new shell. Please put any setenv's in your .login, set's and aliases in your .cshrc.

Description of operation of remote mounts

Remote mounts are done using the "/net/systemname" automounting mechanism. "Convenience" links are placed under / and /home to point to popular filesystems. Basic system commands are aliased to hide this complexity from the user, the alias is called "fix_path". The point is, "/net/systemname" and "/opt/pirl" are not "real" paths as far as the PIRL applications software is concerned. Ignore those paths. They don't really exist.

Description of PIRL applications software structure

The PIRL applications disk (/opt/pirl) contains most of the public and locally maintained software packages. For the most part, applications are grouped under /opt/pirl/package_name/package_revision. For example the IDL 5.4 installation can be found in the following place:

/opt/pirl/rsi/idl_5.4 (really /opt/rsi/idl_5.4)

There are various indirections that take place so that users can easily run various software packages. the first indirection is that "/opt/pirl" doesn't actually exist as far as users and the system are concerned. ALL applications in /opt/pirl are mapped directly from /opt. So, in the case of IDL, /opt/pirl/rsi is REALLY /opt/rsi. To unconfuse things a little, a small alias called "fix_path" is run on some basic system commands to hide the /opt/pirl path.

Applications that do not exist in a package format are grouped into two types - "local", meaning locally developed or paid-for software, and "pub", or publicly available software packages, such as software from the GNU project or other freeware packages. These packages exist under /opt/local and /opt/pub, respectively. Generally, users can maintain their own packages in the /opt/pub tree. Packages under /opt/local are maintained by the PIRL staff. All users are automatically given paths to all software that exists under the /opt/pirl applications disk, and these paths are updated nightly.

In general, most applications have a startup script that is placed in one of two places: /opt/pub/sh or /opt/local/sh (see above for the explanation of why there are two paths). The startup scripts take care of application version control and environment setup. In some cases the environment setup is quite complicated (such as for the ISIS image processing package). These scripts obviate the need for complicated user initialization files.

Description of PIRL Multi-Architecture system support.

Multiple architecture support is a tricky problem. In our case, the decision was once again made to obfuscate the structure of the applications disk in order to make builds, installs and operation of software packages in a multi-architecture environment as easy as possible. I've already mentioned the "/opt/local/sh" and "/opt/pub/sh" paths. These paths are available on all systems and they contain scripts that should at least RUN on any architecture system. In the case of architecture specific files, such as in bin, sbin, lib, and libexec, these are links that point to a architecture and OS specific location on the applications disk via a "shadow" directory that is created when each system is built. The script that does the architecture/OS magic is "osarch". All of this complexity should be hidden from the user. The user should simply notice that not all applications are available on all systems.

Architectures/OS's presently supported

Linux.X86
Solaris.SPARC

There is no reason why we could not support more system architectures. We are looking specifically at FreeBSD X86 boxes as strong contenders for replacing the Sun desktops.

The University of Arizona Lunar & Planetary Lab
PIRL Webmaster
11 Jul 2002