RATS: The Other Big Picture
RATS is a system for creating and maintaining accounts. It consists
of four major pieces:The first two we run:
- the People DataBase (PDB) and related databases. These are located
in Administrative Computing Services. They contain information on
everyone who gets an account using RATS, as well as certain information
such as usernames and herds.- the RATS server. This is located on a machine run by NBCS. It
contains no data, except a small set of administrative data such as
your encryption keys. Its purpose is to communicate with the PDB
and the Kerberos servers on your behalf. There are both security and
data integrity problems with allowing tools to talk directly to
the PDB. So they all talk to the RATS server.The second two you run:
- the client daemons. In the simplest case there is one of these,
probably on your NIS master. The client daemons do the actual work of
creating accounts, such as editing the password file. For complex
clusters you may need more than one of these, because work may have to
be done several places. E.g. quotas generally need to be set on the
NFS server. So many systems will have a client daemon on the NIS
master and each NFS server. All of these client daemons run the same
program (ratsd). If you have more than one daemon, your RATS
configuration file specifies where each thing is done. One of the
client daemons is designated as the master. This coordinates
communication among the parts of RATS on your system. The master
can be on a separate system, or it can be one of the daemons that
you need anyway for other reasons.- the tools. These are programs that talk to users. They include
command-line tools, such as ratsut and ratsadmin, intended primarily
for the sysadmin, and the RATS web client, rats.cgi, which
implements the web interface.These pieces talk to each other using secure communications. In
order to maintain security, you need to assign encryption keys.
Typically each machine or cluster will have its own encryption
key. The RATS administrator has to know the encryption key for
your machine or cluster, so that it can verify where requests are
actually coming from. Thus one of the first steps in setting up RATS
is to contact the RATS administrator to agree on encryption
keys.The client daemons and tools are controlled by a single configuration
file. This file- contains your encryption keys.
- defines where each RATS function is performed. E.g. it may say
that the password file is on your NIS master, and quotas for a certain
list of file systems must be updated on your NFS server.
- defines what types of accounts are allowed to create accounts on
your system. E.g. it may describe two categories of accounts: a
faculty account type which can be used by any faculty member and a
student account type which can be used by any registered student in
Camden.Each account type has two main categories of information:
- who can create an account. Normally this is information contained
in the PDB, e.g. the fact that someone is a registered student and
what campus they are on. This is only needed if you allow users to
create accounts for themselves. On many systems, the sysadmin will
create all accounts. In that case you don't need to define who can
use each category of accounts, though you may still wish to do so.- information needed to create the account, e.g. where you want the
home directories, what disk quota should be used, what .login file you
want installed.Here is a quick summary of how to set up RATS:
- figure out what systems you are going to need rats on. For many
systems, you'll install just one copy, on your NIS master. If you use
quotas, you'll also need a copy on every NFS server. You'll need a
copy on the system where you run your web server (assuming you are
going to use the web features -- basically this means that users are
going to create accounts for themselves).- install the software on all the systems that need it. It is
available through TINT, our software distribution system. (TINT
doesn't do anything magical - it just has a tar file with the software
and possibly some scripts to run.) See <URL> for details on the TINT
packages and how to install TINT.- agree on an encryption key with the rats admin. (send two 56 character or shorter strings to rats_support@email, and let them know if it is the master cleint server)
- edit the rats configuration file. The first thing you do should be
to put the encryption keys in the file. The DES_KEYS specification
lists all the computers where parts of RATS will run.- Next, look at general things needed to create accounts. Major ones
that most people will have to change are FS - which specifies the
system that should operate on each file system where you are going to
be creating home directories (normally this should be the NFS server
where that file system is located), ACCT_FILES_MASTER - which
specifies the system where RATS should edit passwd, group, etc,
(normally the NIS master), LOG_HOST - where the RATS logs will be
located, EMAIL_HOST - used in creating email addresses for new users
(e.g. computer science uses mail addresses that look like
user@cs.rutgers.edu; enter cs.rutgers.edu), MASTER_HOST - the system
that will coordinate communications (This can be any host running
ratsd)- Now create one or two types of accounts. Look at the documentation
and examples to see what information is needed. The information falls
into two general categories (1) who is allowed to create an account of
this type (2) information needed by RATS to set up the accounts.- Test
I suggest testing in two ways:
- verify that you can create users of each type. Use ratsadmin to do
this manually. You want to make sure that it puts the home directory
the right place, that any files you have requested are put into the
home directory, that the passwd file entries look right, etc. For
this test you can use existing users as test cases if you don't have
any people who need to be added. Simply rename their home directory
to something else and remove them from the password and group files.
Now use rats to create an account for them and make sure it's OK.- if you are going to allow users to create accounts for themselves,
use ratscheck to make sure you've got the tests right. Since
ratscheck doesn't change anything, you can use it to test a bunch of
examples. For example, if you are allowing students in Newark, try a
couple of students currently registered in Newark, a couple of
students on other campuses, a couple of alumni, and a couple of
faculty or staff.- once you've done this, things should work. However you're probably
going to want to find some real new users to try out the web interface
for you. We do have a few test users for you to try out. Contact the
RATS administrator to find the right test users for your situation.HERDS
Not everyone needs herds, but probably most systems will use them
eventually. A herd is simply a list of people. We chose the name
"herd" because other obvious words (e.g. "group") already have special
meanings. A herd represents a list of people who are allowed to
create accounts on your system. Some departments may ahve a single
herd which lists everyone that is allowed to have an account on
their system. However you will often want more than one herd (e.g.
faculty, administrative staff, TA's, GA's), since some people get
accounts on different systems, have different quotas, etc. Or
using multiple herds may simply help you keep track of your users.You need to use a herd whenever you can't define the set of people by
using information from the People Database. RATS treats herds
just like PDB roles. That is, if you have a herd nb_math_tas for
TA's in the NB math dept, you'd use it just like "student" in
the configuration file.If you're willing to create accounts manually, you don't need
herds. You can use ratsadmin to create an account for anyone
you want. But you may well want to use a herd to describe
who is allowed to create accounts. There are two advantages to
this: (1) it lets the user create his own username and password,
(2) it helps you keep track of why people have accounts. A couple
of years from now, you may not remember who all these people are.
If you use herds, you can see that one user got an account because
he was a faculty member, a TA, or whatever.You create herds by sending email to the RATS administrator (or
whatever is actually true). advice on choosing herd names.If you're using herds, then creating an account for a new user
has the following steps:1) Verify that they are already in the PDB. This should be true
for faculty, staff, and students. However if they are new, they
may not be there yet. The add person tool can be used to add
faculty and students who will be in the payroll or student
database but aren't yet, and to add other types of people as guest.
If they don't have a real SSN (or in the case of guests, won't tell it
to you) this process will assign a fake SSN for them.2) Add them to the appropriate herd. See URL for documentation
on the herd tools.3) Tell them to create an account for themselves. If your machine
has more than one type of account, make sure you tell them the
account type they should use. If a fake SSN was generated, make
sure to them them their fake SSN, since they'll need that to
generate their account.