[an error occurred while processing this directive] MFCF Resource Sponsorship [an error occurred while processing this directive]

MFCF Resource Sponsorship

Preface

MFCF's automated resource management software works on many systems, including UNIX (Solaris, IRIX, Linux), Mac, and Active Directory. Not all machines are administered this way, but wherever possible, it will be best if they are.

Introduction

The essential purpose of account managment (or any general resource allocation system) isn't so much to allow one to create accounts as it is to keep track of why the accounts exist. In particular the most valuable information it provides is letting one know when it is safe to delete an account.

Unless there is a security issue, when Professor Smith asks you to delete John Doe's account on general.math, that's really not what he means, and it is definitely not what you should do. Instead, what he means is that he no longer wants to be responsible for that account, and what you should do is remove his sponsorship of that account.

The accounts management software keeps track of all resource sponsorships. John's account may very well be sponsored by several professors for different purposes; but that's something you don't need to know. If your removing Smith's sponsorship happens to leave the account without any sponsors, the accounts software will automatically arrange for the account to be deleted; but if the account still has at least one sponsor, it will remain, possibly with disk quotas automatically adjusted. Either way, you don't need to worry about or even know about it.

To enable this to work, all user accounts must be maintained using this same sponsorship mechanism. If even a few are created by hand (for convenience), it won't take long until there are dozens or hundreds of such accounts, and getting rid of them, even when you know they should be gone, will be almost impossible.

All computing resources must be allocated using MFCF's sponsorship database. (One obvious exception is the accounts that were created by the vendor and come with the basic operating system. Another exception is those accounts needed for xhiered packages. But in either case, the accounts management system knows about these special accounts and prevents the sponsorship software from affecting them.)

Resources

The sponsorship database can control resources such as printer quotas, mail aliases, dialin-modems, software licences, and computer accounts on Unix, Linux, Macs, and Active Directory.

After information is entered into the sponsorship database it is compiled using the sponsor_resources command.

The accounts-master command runs sponsor_resources, and the actual resources (other than computer accounts) are updated. It also updates a few web pages and prepares student information from the Registrar's data for computer account updates.

The accounts_client program is used to update computer accounts on a specific machine or on all sponsored machines.

Generally, all resources are updated by software that compares what is sponsored against what is actually there and then adjusts reality to match the sponsorship information.

Updates

For most resources and attributes, the software updates happen right away. Computer accounts however are not immediately deleted.

Instead, unsponsored accounts are put into a state of grace for typically 3 weeks. During this time the accounts are still usable, but with restricted disk quota and no special group memberships. Mail is sent each week to remind the user to copy files and mail elsewhere.

After the grace period, the account is given a shell that displays an appropriate message and prevents logins.

At the end of the month, the account is actually deleted. (Active Directory accounts are disabled and marked as expired, but not deleted.)

Sponsorship Database

All sponsorship information in the database is maintained in a hierarchical structure as described below, with a sponsor as the root of each tree.

Sponsors

Each sponsor has various attributes, mostly for billing purposes.

Sponsor
The sponsor's name.
Department
The sponsor's department.
Address
Further mailing information if name and department aren't sufficient.
Email
The sponsor's e-mail address.
Billing
This says what happens to bills at the end of each term. It can be omitted, but will have the values Automatic if the sponsor's financial accounts are automatically charged (e.g. research grants) or NoCharge if no charges are actually made (e.g. the Dean's sponsorship of classroom equipment).
Statements
This says what happens to the sponsor's monthly statements. It is normally omitted, but can have either or both of the values NoWeb to prevent publishing them or NoPaper to prevent sending paper statements.
Subsidy
This lists any subsidies the sponsor is eligible for. Currently the only possible value is FirstConnection, indicating that the Dean will pay the cost of the sponsor's first internet connection. (Actually the first four as of this writing.)

Bill-Codes

Each sponsor will have one or more bill-codes for charging purposes. These are normally UW Financial Services account numbers, but in some cases (e.g. internal sponsorship with no real billing) other codes may be used (check with the accountING people for what is appropriate).

Classes

Each bill-code will have one or more classes associated with it. Classes are a generalization of (and in fact include) the student classes assigned by the Registrar. They allow the grouping of multiple users requiring the same resources.

Other information may be associated with each class, most of which applies only to the Registrar's classes and is used for automatically updating various web pages.

Class
This is the name of the class. Names that contain no upper-case characters are reserved for those automatically generated from the Registrar's data (e.g. co350). Other class names typically consist of a keyword and a number (e.g. Admin100).
Description
This is a short description of the class, which should be sufficient to distinguish it from other similar classes and to allow one to decide whether someone should be in it or not.
Usage
This defines the primary use of the class. It must be one of Research, Administration, Maintenance, or Teaching. Since it can affect the charges billed to other users, the most financially significant value is Maintenance, which should be reserved for staff who are assigned resources only for the purpose of maintaining that machine. So for instance, an account for maintaining web pages on a web server would not count as Maintenance, since those web pages are part of the normal purpose of the machine. But an account for making sure the web server is running correctly would count as Maintenance. A general guide-line would be whether or not the account would be needed in a world where things never go wrong.
Subsidy
This indicates whether resources sponsored in this class are eligible for the Dean's subsidy. By default, they are, and this is normally used only to prevent incorrectly applying a subsidy (e.g. a Math professor might be sponsoring an account for a colleague from a different faculty).
Instructors
This lists the name of the professor, class instructor(s), et al. for Registrar-sponsored classes.
Enrollment
This is the estimated number of students in a Registrar-sponsored class.
Load
This is the estimated CPU usage for a Registrar-sponsored class. It may be low, moderate, high, or heavy.
Requirements
This is a short list of extra requirements for the Registrar-sponsored class (e.g. specific software packages).
Fee
This specifies any lab-fee required for the class.

Resources

Each class may contain a number of different resources.

Computing
Resources for computer accounts, including hostname(s), group membership(s), and disk quota.
Printing
Resources for printers, including page quotas. A sponsoring account name may also be given, overriding the class name that would have been used by default (for the lpr -Raccount parameter).
MailAlias
Requests for automatic mail redirection (e.g. jdoe@math —> JohnDoe@Rogers.com).
PPP
Dial-in phone access.
Licences
Software licences.

Each of the above resources may have other attributes.

Starts
This sponsorship is ignored before this date.
Expires
This sponsorship is ignored after this date.
AssignTo
A list of userids (hosts for Licences) to which the current resource is to be assigned. Note that this is ultimately the most important part of the data; without it, none of the other information in the database ever gets used for anything.

Short-cuts

A few additional attributes exist in the current implementation of the database for the convenience in entering the data.

External files
Any list may have the form <filename. The contents of that file will be decommented and processed as if they had been entered in the data at this point. Typically this is used in an AssignTo list, where the list of userids comes from an externally maintained file.
Sponsors: Userids
Normally all userids must be entered into the sponsorship database with an accompanying identifier (e.g. student ID) to provide redundancy to eliminate most mistakes from typos. Any userids that will appear many times for this sponsor can be entered in their full form in this list, and then any further references to them for this sponsor are allowed without the identifier.
Class: MembershipStarts
Any following membership lists will be ignored before this date.
Class: MembershipExpires
Any following membership lists will be ignored after this date. If start date was given, the expiry date may be expressed relatively (e.g. +42Days, +2Terms).
Class: Members
This attribute lists userids belonging to the class. They will not be automatically assigned any resources; that must still be done by specifying *MEMBERS* as a userid in an AssignTo trigger. The main use of this mechanism is when the same userid list is needed several times, especially when it comes from an external file.

Other References

Overview of MFCF accounting philosophy.
Overview of MFCF resource allocation.
[an error occurred while processing this directive]