Below is the list of common account management tasks. At the time of
writing, these have been taken from the original stage1 task document,
and are in various states of dis-repair (but we are working on
this), so if things don't work as expected, speak to someone on the
team to clarify things. The man pages for some of the
commands might give you more info, eg new_passwd accgen
update_user.
Neil 11/7/2003
Most procedures require the use of some Account Management
Tool. These tools currently require you to supply your database and/or
your Kerberos admin principal password at each invocation. A temporary
fix is to run the ampenv (Account Management Prodecures
Environment) script which prompts you for your passwords and then
caches them in environment variables in a new shell. The command
prompt changes to show that you are now in a new shell. If these
variables are set then their contents are used in place of being
prompted for the passwords. Once you have finished using these
scripts, you should exit the ampenv shell.
You need to know your database password, and have arranged for
the database to accept connections from particular DICE machines.
To authorise a connection by yourself from a specific client (the client
should not be a machine that non-computing staff can use) you must do the
following:
- Add the <dice/options/infdb-client.h> header to the machine's
profile and then wait for the profile to be recompiled.
- run om updaterpms run on the client to load the dice-accntmgr
rpm.
- Edit the live/infdb-dbiproxy.h header file and add a _DBIPROXY_ADD macro
to tell the database server to allow access for you from the client, commit the
new version and wait for the profile of the database server (alias infdb) to
recompile.
- Log onto infdb and run om dbiproxy restart.
- Edit the DICE/AccountManager/Infdb/Key.pm file (from the dice-accntmgr rpm) on the client to install the real encryption key.
Local system type pseudo accounts are not covered by these
procedures. Creation of these types of accounts is handled by the LCFG
auth component.
Definitions:
- pseudo account
- is an account that isn't associated with a "real" person. Staff,
students, guests, visitors are "real" people. Accounts used to test
the facilities, or provide some central facility eg inftest
and submit are pseudo accounts. Though these accounts appear
just like a "real" user to the system. They have DB, LDAP and Kerberos
entries.
- system pseudo account
- again an account not associated with a "real" person, and these
accounts are only local to a particular machine(s). They do not need
access to network resources (this would require them needed a Kerberos
principal) eg apache, bindrun and are typically used
by daemon processes to shed their root privileges. They do not have
DB, LDAP or Kerberos entries, and are managed via the LCFG auth
component.
The following procedures do not apply to "system pseudo accounts", but
do to other pseudo accounts.
|
|
Please contact us with any
comments or corrections.
Unless explicitly stated otherwise, all material is
copyright The University of Edinburgh
|
|
