| Task: | Account management procedures |
| Group: | neilb,johnb,roger,cc |
| Stage: | 1 |
Description
This task covers the procedural aspects of account management;
eg how people are grouped, how accounts are reviewed etc.
Report changes
- 2002-02-18
- Biggest change is the list of data now in the Final Decisions section.
Firmed up some decisions that have now been made.
Some rewording and grammatical changes.
Added changes and action section.
No changes to the text of the procedures.
- 2002-03-01
- Updated progress of actions ie not much :-(
- 2002-03-15
- Moved actions and timescales information out of this report and
into the new stage1progress.hml document.
Added a new issue regarding user-centric file system information
- 2002-03-21
- Updated user-centric file system
issue. It should no nolonger be an issue.
- 2002-03-26
- Added issue of staff doing a PhD/MSc.
- 2002-04-05
- Added issue of associate accounts and
sponsorship of those accounts
- 2002-05-11
- Added details about pseudo user accounts.
- 2002-06-09
- Started the update of the procedures with the real commands.
Text rendered like this, are just thoughts for
my benefit.
Initial Report
This task covers the procedural aspects of account management:
- How accounts are classed (staff, student, guest, visitor, pseudo)?
- How accounts are created
- Management of their role information. What roles do we need?
- User web space. Which users have web space. Where is it kept?
- Disk quotas. How much do they get?
- Printing quota/permissions. Controlled via role information?
- Forgotten passwords
- How accounts are reviewed. Should it still exist? Does it need modified?
- The lifetime of accounts
- Disabling
- Archiving. Though backups, /yesterday are presumably part of the backup
task.
It is not concerned with:
Though not actively involved in the following, we may provide guidance
on what we think will be required to the tasks that are
solving these problems.
Issues
The type of DICE world we will be living in, will be a DICE/legacy
hybrid, Jeremy's World C. The fileservers containing home directories
of users will remain in the legacy world for the time being.
Access Control
Mechanisms to restrict certain management procedures to certain
classes of user. EG full access for computing staff, limited access,
say to change forgotten passwords, for lab supervisors. We can't rely
on a general purpose (rfe style) wrapper mechanism. Kerberos
will restrict what we can and can't do. Certain things, like changing
a user's principals and passwords, can only be done by users with an
"admin" principal, which allows them complete administrative
access. Without tweaking, the current KDC access controls aren't
sophisicated enough for the sort of fine grained access control that
we desire. We have to rely on Kerberos Task so see if a solution can
be implemented. Apparently there can be, but perhaps not in time for
stage 1.
Consistency of Data
We'll be interfacing with the DB for certain information. If that
information is changed in the DB by some other mechanism. eg ITO staff
correcting spelling of a users real name, could/should that change be
automatically propagated into derived data, eg GECOS field in passwd
file? It seems likely that there will automatic feed back from the
Database to LDAP to update certain data. Other deletion/creation type
operations would require some form of human mediation. We need to
decided what changes/updates will propagate automatically and which
need mediation.
Recently (10/3/2002) there's been some dicussions about the correct
place to store automounter map information for certain file
systems. Namely the /yesterday, /public and /risky (note these are the
current legacy names any new DICE equivalents will probably have
different names) plus the existing /home. We already store
homePartiton and homeSubdir with the User
information in LDAP, and there is a proposal that we do the same for
the other user-centric filesystems. Is this the right thing to do for
all of these filesystems?
Update 21/3/2002 Following this weeks COs meeting, it was
decided that (for stage1 at least) that /yesterday, /public and
/volatile (the DICE name for /risky) will not require extra
information to be stored the the Person LDAP object. /yesterday will
become /yesterday/home/<user>, and the automounter map will be
generated from the user's existing homePartition and
homeSubdir attributes plus extra mirror information held
with the Partiton object. /public/<user>/[web|cgi] will be held
on a single (possibly virtual) partition on the homepages web server,
so this map will be trivial to generate. /volatile will not be
user-centric, it will be of the form /volatile/<area>/ where
area will be some shared writeable partition/directory. These
facts meant that the AMT/AMP interface does not need to change, and we
can be a bit more specific about management of user web space.
Tim has pointed out that some current staff, and presumably some
future staff, may be staff first and then choose to do a PhD or MSc at
the University. What impact does this have for their account? Do they
get two UUNs from the EUCS, an s1234567 style UUN plus their
existing jsmith one? If they get both, what do we do at
Informatics? The EUCS will allocate two UUNs, and the user will then
have a SMS email account as well as a Staffmail one. From our point of
view, I think we would just ignore their s1234567 style UUN,
and always use their staff style one.
It was brought up at the last meeting that associate and visitor
accounts should have some concept of a sponsor for that account. This
sponsor would be a current member of staff that will take
responsibility for the users actions, and should be able to contact
them (other than emailing their Inf account). Ideally this information
will be tracked in the database, and we need to consider how that
information is entered. We could take the easy way out and say that if
the associate/visitor is in the database, then someone else will have
already filled in the sponsor details. Though perhaps we should at
least double check that before creating an account for an
associate/visitor, that a suitable sponsor has been named.
There are generally two types of pseudo user account. One is a system
type user, eg 'wwwrun' or 'bindrun', used when a process wants to shed
its root privileges. The other is just like a real user
account but it is either used by computing staff to test the
enviroment, eg 'bashtest', or 'inftest'; or it is used for the
purposes of group file sharing, eg 'cs1', 'support', 'submit'.
The first type of system account is not generally covered by these
account management procedures. It will be the LCFG auth
component that creates the local passwd entries on the local
machine. However, these system pseudo users should still have their
name registered with the UUN system, so that no "real" user would ever
end up with the username 'bindrun'. These accounts would not usually
need to access any files, and any that they do would be local to the
machine running that process. The Divisional Database does not need to
know about these accounts.
The second type of pseudo user, the one almost equivalent to a
"real" user account, would be largely managed by the procedures
produced by this task. This is because the account will need: a UUN,
read/write access to shared network resources (usually just
/home/<pseudoUser>), a network wide UID, and (depending on use)
a Kerberos principal. As these procedure will be used to manage these
accounts, the Divisional Database needs to have a record for these
"users".
Currently the 3 sites AI, CS, BP have their own, different, ways of
managing accounts. The only common feature is the use of the accgen
script, which given an input list of users, will generate suitable
usernames and other information for feeding into the sites' existing
account generation scripts.
The use of accgen should ensure that new users are given unique
usernames and uids throughout the division. Accgen relies on
the database already being populated with basic information about the
user, and then updates further fields marking the username/uid
allocated to them.
The main goal is to have a consistent policy through the Division, so that
no matter where a users home directory physically resides, they can expect
consistent management of their account.
The computing staff benefit by having a consistent line to tell users. So
no more ``CS2 students get web space, why can't I as a AI2 student?'' type
queries from students.
Provided documented procedures on various account management tasks, eg
creating new accounts, disabling accounts, moving home directories.
Before we can decide what the procedures are, we need to know which
world we will be developing procedures for. For previous discussion of
the worlds, you'll have to look at the previous
1.6 version of this document. Though the details of common home
directories and file system maps haven't been totally finalised, it
has been agreed that home directories will continue to live in the
legacy world, and that they will be served to both DICE and legacy
clients. Given this our options are:
- Do nothing. All 3 sites maintain their own
procedures/policies regarding account management. DICE bends for
us. Unlikely.
- Common management procedures are agreed and
implemented separately at the 3 sites. Possibly their existing
technology may mean not all "procedures" are available at
each site (quotas, /yesterday). The likely option.
The most important part of this task is getting the user account
information into the new LDAP and Kerberos services. Without this
information users will not be able to log in and use the
system. This means that we can't go for option 1. We must have some
new procedures detailing how to populate the LDAP and Kerberos
services with user account data.
The user account data in LDAP and Kerberos will be accessed and
manipluated by tools that only work in the DICE environment. As this
is the bulk of account procedure task, with only the low level home
directory creation/manipulation activities existing in the legacy
world, the common management procedures (option 2 above) is the option
we are developing for.
This still leaves lots for us to do. Now that common procedures
have been decided, how are these "procedures" implemented?
For example, the "How to create a new account" procedure could be
different at each site, in that it details the steps to take using the
existing sites' technology to physically create the account on the
legacy fileserver plus whatever extra is needed to interface with
LDAP/Database/etc. Or, the "How to create a new account" procedure
would detail the use of new, common to all sites, scripts that
actually do the work.
Possibly, the 3 sites would implement common scripts to carry out
routine account management tasks (adduser, moveuser, disableuser,
rmuser, newpasswd). The underlying code at the 3 sites may be
different to achieve the desired result, but their interfaces would be
common. So when file servers in the inf domain start appearing, these
tools would also be implemented on them, and hence learning of yet
more new procedures would be unnecessary. It would also have the
benefit of a C(S)O suddenly seconded to another site, could be
confident that the command adduser would add a new user, and
do the necessary magic behind the scenes.
Given the constraints enforced by the new technology, and the time
to get things done for stage 1, the account management procedures will
be common across Informatics, with site specific details where
appropriate.
It has been decided (elsewhere) that home directory file servers will
still exist in the legacy world for the time being. This means the
procedures have to contain site specific instructions where
appropriate. As much as possible they (will) contain details of
new tools used to manipluate DB, LDAP and Kerberos data.
The Data
After discussion with the AMT task, the following list of user account
data is that this procedures task will want to query and/or modify via
the tools provided by the AMT task.
| Attribute | Access | Description
|
|---|
| username | RO | Unified UserName
|
| firstname | RO | First Name
|
| lastname | RO | Last/surname
|
| uid | RW | Numeric user id
|
| gid | RW | Numeric group id
|
| email | RO | Official contact email address
|
| homeDir | RW | Home directory, eg /home/neilb
|
| homePartition | RW | Home directory partition, eg twain9
|
| homeSubdir | RW | Home directory sub-directory, eg staff/neilb
|
| shell | RW | Shell, usually /bin/bash
|
| passwd | WO | Plain text password
|
| primaryRoles | RO | Primary roles
|
| secondaryRoles | RW | Secondary "system" roles
|
| enabled | RW | Is the account enabled?
|
Key: RO = Read Only, RW = Read Write, WO = Write Only.
There is still an open issue on whether disk/print quota's will be
delt with via the "roles" mechanism, or wether they need listed
explicitly in the list above.
We have not finalised those procedures, but the current list at the
end of this report is probably pretty close.
- an overview of what subsequent changes could be made if, for
- example, anticipated technologies emerge.
The possible change is the time when file servers do start to exist in
the DICE world (@inf domain). Then all new accounts will be created on
those machines, and existing accounts migrated to them. As this is the
desired goal, then unifying any procedures/work now will benefit us
when these new servers start to appear.
Web Interface
It has been suggested that a web interface may be desireable to allow
prospective users to specify their account details before arriving at
Informatics. It could have links to the Computing Regulations for
their perusal, and they'd be able to specify things like their: full
name, prefered name, email address and an initial password. When they
physically turn up, they sign the computing regulations and the
account is then created with the details supplied on the web. No need
to generate/print off sheets of paper with a password on it.
This may be more useful for the occasional visitor, new member of
staff, but for hundreds of new students in October, doesn't sound like
the right way to do it. Though perhaps some other web form would allow
users to change/specify a password if they had forgotten it, by
requesting some shared secret, such as mother's maiden name, postcode,
etc.
Though it strikes me that there would be a chicken
and egg situation here. "Q: I've forgotten my password. A: Log in and
change it on the web page blah. Q: Err, but I've forgotten ...". OK
perhaps the user can borrow someone else's browser.
An anonymous account has also been suggested. New users and people
who've forgotten their password would log into this account (with
no/or a public password), a restricted shell would then start which
would confirm various shared secrets (like above), and then allow the
user to specify/change the passwd of their real login account.
The absolute must, is the interfacing to the AMT provided tools. These
tools must exist and provide the flexibility we need. The finer
details about account classification and review, and some of the
procedures eg account archiving, removal are not so urgent.
Actions and Timescales
The actions and timescales sections have moved and renamed into the Stage 1 progress document.
Dependencies
The report ends here. The following are the fruits of our
labour so far.
The following are now obsolete, and are only provided for
historical reasons. The official procedures
are now linked to from the DICE documentation pages.
The procedures that we need:
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. See
Ken to set this up.
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.
This procedure currently under going a rewrite, and is incompleted
Account creation is carried out in two ways:
- En-masse for possibly hundreds of users (eg new students at the
beginning of term), and
- In an ad-hoc manner for single users (eg new staff)
Either method relies on two things, the user(s) must exist in the
database, and the database must contain the Universal Username (UUN)
for that user.
Must be in the Database
No Database entry == No acount. To create an account, the "person"
must have a person record in the Informatics database. For staff and
students, someone from the ITO, School Office or Institute that they
are affiliated with should have added them to the Database. Only in
exceptional circumstances computing staff could create the initial
database entry for staff and students.
When admin staff are creating DB entries for staff/visitors, etc
they are unlikely to be filling in the "Unix Username" (UUN)
field. This can be done by computing staff (see later).
Only pseudo user accounts will be routinely created in the database
by computing staff. Remember is does not include system pseudo accounts.
If you do need to create a database entry for a user, then double
check the user really isn't in the database before you proceed. If you
need to ask how to create a database entry for a user, then you
probably shouldn't be doing it. Either ask a member of the computing
staff that does have the power, or a member of the admin staff.
You must know the UUN
Before an account can be created, you must know the UUN for the
user. No UUN == no account. This UUN must also be stored with the
person record in the Informatics Database, if it is not, the user does
not get an account. (This is not strictly true for students who have
their matric number in the database, as their UUN can be deduced)
The Universal UserName (UUN) for students is their matric number
with an 's' prepended (no matric number == no account). For all other
types of users you must currently email mft@ed.ac.uk, with the
staff number of the member of staff, or other relavent details if it
is a visitor/pseudo user. Only when you have their UUN can you proceed.
At somepoint in the future there will be some
automated way to query/request UUNs. It isn't here yet. The EUCS were
hoping for Easter 2002 - oh dear
Those with the necessary database access can update the users UUN
database field by using the itodb command on AI machine Suns,
and filling out the "Unix Username" field on the "Person" form. You
don't need to do this with students who have their matric number
recorded in the database.
Once the database has a UUN for each account you wish to create,
you can continue below.
To create student accounts en-masse
Use the command create_users, this takes as input a colon
delimited text file, not unlike a passwd file. The format is as
follows, empty line and ones beginning with a # are ignored:
# UUN:uid:gid:homeDir:homePartition:homeSubdir:shell:secndryRoles:enabled
s0123456::::u8
s0123457::::u8
Most of the fields can be left empty and will default to appropriate
values.
- UID will be obtained from uid_lookup
- gid defaults to 10000 (people)
- homeDir defaults to /home/<user>
- homeSubdir you should specify, as this is the name of the
partition that will contain the user's home directory.
- homeSubdir default to the UUN. You may want to change this to
'student/<user>'.
- shell defaults to /bin/bash
- there are no default secondaryRoles, you may choose to specify
some here.
- the account will be enabled by default.
Once you have populated the input file, run the command on a DICE
machine:
create_users <inputfile>
This will initialised any necessary LDAP, Database and Kerberos
datasources. If you do not want it to print out memo sheets with the
passwords, use the -n flag.
Create the Home directory
At this point a new user will exist in the Database, LDAP and
Kerberos, but they need a home directory. To do this, follow
these steps.
- Determine the UID for the user:
- If the user is already in LDAP, then
id or
get_users will return the uid. Failing that,
use uid_lookup for a student.
- Otherwise allocate one from our local reserved list of
UIDs. Currently use the existing legacy site procedure for this.
- Create the directory by logging on to the legacy file server that
will host the home directory, as specified above and do:
mkdir /path/to/home/dir
chown UID /path/to/home/dir
chmod 700 /path/to/home/dir
Need create_user to flag if a home directory already
exists, so that another CO doesn't try and create another home dir.
- If the update_user isn't going to automatically
trigger rebuilding of auto-mounter homedir maps (DICE and Legacy) then
it should be done here.
Some of my statements above gloss over details, eg the
allocation of UIDs, update_user script that doesn't yet
exist. Others probably go into more detail than necessary, eg the
mkdir stuff. Somewhere the work does need to get done, so uid stuff
and mkdir stuff may well get wrapped up into some detail hiding
script.
Need to mention something about ensuring email
facilities are available for the user. For students this is making
sure that their sms.ed.ac.uk has been setup. For staff, the issue
hasn't been resolved yet. We will be handling staff mail locally for
the short term at least, so we need to find out if any intervention is
required (eg creating a spool directory on the mail server), or will
it "just work"?
Roles for the user
Give the user their appropriate roles. See the Role procedure for detail
on how to do this.
Will some/any/all roles be generated from the DB?
Will printing restrictions be defined by the roles a user has?
Allocating Web Space
Depending on the user, create personal web space for the user. See
Personal Web Space procedure for details.
Disk quota
Depending on the user, apply the appropriate quota to their home
directory, and possible web space. The Quotas procedure.
New Password
Generate and print off a new password for the user. See the Change
Password procedure.
That's it
Your user should now be ready to go.
Disabling an account means that the account still exists, but the user
is no longer able to log in and use any of our services. Reasons for
this would be: disabling of account before finally being archived and
removed; Someone has been a naughty boy and we need to stop them in
their tracks. Generally users would be emailed at least a couple of
days prior to the disabling. This is just the mechanics of the
process, we should have some guidelines for timescales and grace
periods for students who leave the Division.
There are possibly a few ways of achieving this:
- Change their authentication so that their password no longer
works, in old world speak "star out their passwd". Presumably the only
sure fire way, but not very informative for the user.
- Change their shell to some sort of "no login" or "disabled"
shell. This could allow the user to be informed as to why they are
unable to log on, but also means that services that don't use the
shell may still work, eg FTP, possibly allow a back door in.
- Is there some way of Kerberos authenticating the user, but giving
them null privileges? This would require all services to kerberised to
be sure there wasn't some back door in. Apparently what we do is stop
the user from being granted any tickets (the KRB5_KDB_DISALLOW_ALL_TIX
flag), but this wouldn't affect non-kerberised services.
How will this 'disabling' be achieved. We'll need to wait for the AMT
task to tell us. Presumably a command line tool, perhaps some file
under rfe control.
Before an account is removed from the system it should be archived
to some offline storage for posterity. This frees up live resources
for other users, but allows us to reinstate the account later should
it be necessary.
Prior to an account being archived, it should have been first
disabled for a period of time, usually 3 months (CHECK
THIS) to make sure the account is indeed inactive. After archiving,
the account is usually removed from the system.
All the personal files held on the Informatics system for the user
should be archived, this includes their home directory, mailbox,
personal web/ftp space. Not all users will have mail/web/ftp files.
Outline of Steps
- Identify a suitable large/empty archive partition (preferably on a
machine with a tape drive), to copy the data to.
- Copy the contents users home directory onto this partition.
- Create sub-directories in this copy for any mail/web/ftp files
that they have, and copy those files into those directories eg create
a sub-dir called WEB_ARCHIVE and copy the contents of
/public/<user>/web into this directory.
- Copy this copy of all their data onto tape.
In the real world archiving of accounts will be done in large
blocks. Say a whole year of undergrads done at once. When this is the
case all the accounts would be copied to the archive partition and
then all copied to tape in one go. The tape would then be suitably
labelled, and a hardcopy of the contents kept with the tape.
Needs more thought as to the actual process of
copying to tape. Should Amanda be used? Just tar it to the tape? Use an
AI do-archive script? How should the tape be labelled,
stored?
The steps above, bar the copy to tape, can be scripted. What will
happen with kerberised file systems? Will 'root' still be able to read
other peoples files, and copy them across networked machines?
What steps need to be carried out to remove a user from the
system. This includes things like deletion of files, removal of user
from groups/netgroups/roles/mailing lists/LDAP/Kerberos, but probably
not the database.
It's assumed the user has been sufficiently warned that their account
is about to be removed, and has been disabled for an appropriate length
of time. Students who are leaving should also be asked to make sure
they have unsubscribed themselves from any external mailing
lists. Though it will be the SMS service that will suffer if they don't.
A lot of the lists that a user will appear on will be automatically
generated from database information. So as long as the database is
updated with the fact that a user has left, this should remove them
automatically.
That should be it, again possibly some of this could be
scripted.
Fairly straight forward, we just want to be able to generate new
password for someone who's forgotten it.
This only changes the regular principal password, other
prinicipals, eg admin, eed to use KDC tools directly. See Tim, Simon.
new_passwd -P <printer> <username>
Without the -P it will send the passwd info to your default printer.
A user may have several roles eg user, staff, cs3, sysadmin,
beowulf, cs1pass. Some of these roles will come automatically from
information in the database, and some will be managed by hand. These
roles replace the old group and netgroup mechanisms for deciding what
services/resources a user has/can access.
User roles will come from the database eg user, staff,
cs3. System roles are ones that are managed by this procedure
and include things like: beowulf (the user can log into the beowulf),
cs1pass (the user can change cs1passwords).
Need to decided what are user and system roles. Is
sysadmin a user or system role? I'd say "system".
What it means to have a "sysadmin" or "beowulf" role is also managed
in this procedure.
Managing Roles
Users have roles, rather than users belonging to a role. So the data
should be considered as:
neilb:user,staff,sysadmin
rather than
staff: grd, bundy, neilb, ajs
sysadmin: neilb, ajs, cc, cms
However, tools will be provided to say "list all the users who have
the 'sysadmin' role". eg roles -list sysadmin
To alter the system roles that a user has I see two possible
interfaces, either a straight command line, or some file under 'rfe'
style control. A command line work something like:
roles -add sysadmin neilb
roles -delete beowulf neilb
roles -set sysadmin:beowulf neilb
or via rfe rfe user/roles and you'd then edit a text file in
the same format as described above ie:
neilb: sysadmin, beowulf
ajs: sysadmin, inventory
s123456: cs1pass
Again note that you can only assign system roles via these
tools. user roles would need changes to the data held in the
database.
Defining Roles
Defining what it means to have, for example, a cs1 role. If having
cs1 as one of your roles means that you get a 10MB quota, 100 printing
quota and can login to a certain group of machines, but we feel
generous and up the disk quota to 12MB, where do we make this
change. This part of the Roles Procedure will describe that.
Unfortunately I've no idea how this will work, I think
Simon is the only one that does. We need to get more info from him, or
wait for his "Architecture Overview" document.
Web Space
For the stage 1 role out, it doesn't look like we'll be providing user
web space on an @inf machine, ie there will be no
www.inf.ed.ac.uk/home/<username>. Users will still be given personal
web space on legacy web servers. ie:
www.dai.ed.ac.uk/homes/neilb/
www.dcs.ed.ac.uk/home/neilb/
www.cogsci.ed.ac.uk/~neilb/
For AI and CogSci this means the user would create a
public_html directory in their home directory. For CS, an
area called /public/<user>/web/ is created for them and
their web pages are served from here. At Cogsci anyone can have web
space, at AI and CS it requires computing staff to enable it for
particular users. CS and CogSci allow user CGI scripts, at AI they do
not.
All in all, not a very satisfactory situation, and ...
STOP PRESS: CEG are reconsidering the no
www.inf/~user/ statement and it may be reversed. More details when
we have it. Then we can make this procedure a bit more concrete. It
looks like there will be www.inf/~user space of some sort.
Hoping that there is a single user web server, then presumably the
work require to enable it will either be:
- Create the necessary /public/<user>/web/ directory
and change the ownership to the user. As it is at CS.
- or tell the user to create a public_html directory in
their home dir and create the required symbolic link to make it
"live", as they do at AI
FTP space
Currently we have no plans for user FTP space, the legacy system
should survive for those that already use it. New users should be told
of alternative methods, HTTP can be used to serve anonymous files, and
scp (ssh) used to transfer user files.
Again how quotas are to work hasn't been finalised in the AMT
task. I'll describe the three possibilities that I see.
- Run the command 'admin_user' with the appropriate quota for the
user, and then trigger the update on the fileservers as appropriate
eg:
admin_user -quota 12MB neilb
- Quotas may be a function of roles. So assigning the appropriate
role will give them the correct quota. So perhaps if a user has a
system role of CS1, that would give them a 10MB quota. If they needed
extra for some reason then perhaps we'd do:
roles -add 10MBextra
We'd need a role for each extra amount we may
add. Sounds unwieldy.
- Quota information grouped into one big file under rfe
style control. The file may contain lines like:
#user : soft limit : hard limit
neilb:1GB:2GB
s1234567:10MB:12MB
After doing any of the above, it may then be necessary to log in to
every home directory fileserver and run some command like DCS's
dcsquota. This will depend on whether this is automatically
triggered by the above steps. The reason all fileservers need to be
updated is so that if a user has a 10MB quota on partition, they need
to have a 0MB quota on all other partitions, or enterprising students
can allow others write access to their home partition with unlimited
quota.
How disk quotas for other other services like web space
and ftp space will presumably be similar.
It might be possible to execute this with a single top-level command
(script) although this would involve several smaller tasks - some
trivial, some not.
The work involved can be described in the following sequence:
- Check current status
Making sure that current location is not in use (no open
files or processes with current working directory - but do we
abort if the current directory is in use?), and
preventing updates whilst move is in progress (write-locking
or other disabling procedure). Optionally, check number of
(local) links to track down any aliases or pointers. This
requirement could be replaced by the Account Disabling
procedure above, or share common elements.
There's only so much checking we can do. In the past,
contacting the affected user(s) and agreeing a time when they
would not be logged in, or have processes running that are
outputing to their home directory, should be enough. If they
chose to ignore this or forget, then tough. If disabling
accounts is as effective and simple to carry out as we hope,
then this should certainly be done prior to the move.
- Relocation (and renaming if required).
The move of
the disk data (move old-home-location new-home-location),
should check new partition has enough room, and that the move
does not put the new partition over a certain usage
threshhold. Once assured that these constraints are
satisfied, shift the data (via simple mv, or via
tar or dump|restore pipeline?). This will
need to be done on the appropriate legacy (NFS server)
machine. Ideally, rename the old home dir as appropriate eg
neilb.todelete and only remove once a backup has
been taken of the home dir in its new location.
tarcopy script at AI. When it comes to
moving data between servers/sites, are there going to be root
authorisation issues on the legacy (eventually Inf) file
servers. I think there will be. If they can't be solved, then
the computing staff would have to transfer the data as
themselves and then restore it at the destination as root.
- Update directory services
Changing the home directory location in all accessible
records, LDAP for DICE (passwd entry or equivalent, automount
map for home directories), and feedback for legacy machines
(where the data will actually live in the short term). If
there is an additional partition/sub-directory to home
directory mapping elsewhere, change that too.
This should be no different from the step 3 of the Create
Home Directory part of the Account Creation procedure. So
possibly some command line tool like:
update_user <username> -homedir partition:path/to/home/dir
All the other magic should be triggered from this.
- Notify user of completion
And re-enable account.
This is a fairly major task, and shouldn't be called upon too
frequently. Requirements here are to:
- Disable account
(notify user - optional, as user may already have been
notified). Write-locking or similar protection is advised,
although unsharing/unmounting is probably not necessary.
- Update directory services
LDAP and the DB store the UID, so these need to be updated
eg:
update_user <username> -uid newuid
If the user has passwd entries on legacy systems, the they
will have to be updated.
Need to flag this to legacy tasks
- Change ownership
Update UID of home directory and (possible) mail file (recursive
find & chmod?).
- Identify and change ownership of external files
Make sure any files outside the home directory and mail
delivery area are also modified (via find??). This should
include any files in web and ftp areas.
- Re-enable account
and notify user.
Remember, the procedures above are now obsolete, and are only
provided for historical reasons. The official procedures
are now linked to from the DICE documentation pages.
|
|
Please contact us with any
comments or corrections.
Unless explicitly stated otherwise, all material is
copyright The University of Edinburgh
|
|
