Self Service Quota Increase (DRAFT)

Document Version: 0.9 - 02/12/2003
http://www.andrew.cmu.edu/~wcw/work/ss-quota.html
Bboard: https://bboard.andrew.cmu.edu/archive/mailbox.php?mailbox=org.acs.asg.project.ssq
Test site: http://halcyon.andrew.cmu.edu/kweb-cgi/ssq.cgi

1.0 Overview

Quota increases for AFS and Cyrus have traditionally been done by administratively increasing the amount. AFS user quotas have been fixed and no quota increases are allowed. Cyrus quotas have been set at an initial value but a request to the Help Center may result in the quota being increased.

The Help Center reports that quota increases take up a significant amount of time and would like to see this be something a user can automatically request.

At this point in time, we have the capacity to increase quotas significantly for both AFS and Cyrus. However, rather than increasing everyone's quota across the board and then prohibiting quota increases, we would prefer to have the user go to a web page to request more space.

In this manner, we have a better idea on how many people actually want more space. Also, in the case of email, if people do not use their account, spam and other junk mail will only accumulate up to the point of the default quota when the account is created instead of increasing to the maximum quota that all users are allowed. This way, we should have less junk sitting around.

2.0 Implementation Notes

2.1 General

• The quota increaser CGI will be linked off of MyAndrew.

• The MacOS X AFS quota checker should include a link to the quota increaser CGI when it notifies the user they are reaching the end of their AFS quota.

• It would be good to use the "webmail" webiso so we don't have to create another all powerful user.

• The web page should display how much of their quota they are currently using and what the hard limit is.

• Users may only increase their personal AFS or Cyrus quota. Increasing quotas for project volumes, web publishing workspaces, and other items is not covered in this project.

• The user will be given an option to increase the quota by a certain amount (default) or choose to go with the maximum with one click.
  This will let us see if there are users that feel they don't need all that quota but also not inconvenience those that want the maximum.

2.2 ADM

• The actual quota increase will be done via ADM. The functions should already exist. Only a "wrapper" to allow users to raise their own quota will be needed.

• ADM will read the file /afs/andrew.cmu.edu/data/db/ssq/user/<service-name>.

  The service names currently are: afs for AFS; cyrus for Cyrus.

• ADM will enforce the maximum quota and not rely on the web page to do so.

  The file will just contain the maximum quota a user can increase to. The file will be in 1K blocks, e.g. 200000 will be 200MB.

2.3 InelIgble Users

There will be a set of users that are not allowed to increase their quota. These users will be referred to as ineligble. Ineligble users are are defined as those without an eduPersonPrimaryAffiliation or an eduPersonPrimaryAffiliation that is sponsored.

At this point in time the string sponsored may be of mixed case so any comparison must ignore the case of the string.

ADM will fork a program to do the check. As such, the check is likely going to be done twice -- once as when the UI loads and another time when ADM runs. This is likely to be slow but the frequency of execution should be low enough that it won't matter.

2.4 Maximums

As a first pass, the maximums will be:

• AFS home directory: 100MB
• Cyrus INBOX: 100MB
• AFS Project Volume: 200MB

3.0 Open Issues

3.1 Ineligible Users

Answered in section 2.3.

3.2 MacOS X Preferences

Addressed in 4.3

3.3 Command line

If we provide a command line utility to perform the same functionaltiy, it probably would be good to make sure it can't be run from the .login (or at least not without some negative consequences). The reason for this is that there may be load issues (and the resulting slow down may just be the consequence) that we just don't want to incur on every user login.

4.0 Other/Related Issues

4.1 XQ space

Anyone can purchase additional disk space at this time. Details are at http://yendi.cc.cmu.edu/work/xq/.

This system is not scalable and so the costs are very high. It would be good to be able to provide cost recovery storage services so that anyone could purchase more storage at a better price point. For example, students may be able to buy more central space from the computer store or online.

4.2 Mac OS X preferences

Currently, our MacOS X cluster implementation uses the user's AFS home directory to store preference information. This preference information is not automatically garbage collected and so will not shrink unless the user takes explicit action.

The preferences are stored as discrete files so deletion should be fairly straightforward by the end user. A program like clean could tag the file for deletion but we generally do not want to automatically clean up since we do not know whether or not the user will actually care if their preferences gets nuked.

This project will not directly address this issue. It will only indirectly help by giving users a larger AFS quota.

5.0 Deferred Items

5.1 DAMS integration

At this point, DAMS integration/representation will be deferred until the future.

We have been discussing a couple of methods for DAMS integration.

• Trigger updating - When ADM updates the quota, it also updates the appropriate fields in the account object. The problem with this approach is that the quota data still can't be trusted as any manual change in the quota would not be reflected. It is also unclear how easy it would be to get ADM to update LDAP.

• Direct LDAP - Have a direct LDAP interface to the quota information. This can be done by either putting an LDAP interface onto Cyrus and AFS or by possibly having an LDAP "shell" backend where the LDAP server runs a shell command to get the value of an attribute instead of looking it up in Berkeley DB or some other back-end.

5.2 Project Volumes

Increasing the quota on project volumes is being deferred until such a time we can revisit the management of project volume in general.

5.3 Decreasing Quota

6.0 Timeline

6.1 Immediate Actions

• Laura will revise the draft pages based on feedback from the meeting.
• Barbara will stub the ADM stuff so we can see the draft pages in action.
• Walter will assist with some of the ADM stuff.

6.2 Big Picture

• beta 1 month before mid-semester break
• release on midsemster break
• DAMS integration should be done after we investigate the new LDAP back-end. Project volume work likely depends on this as well.

6.3 Completed

01/20/03

• Next meeting: 01/27/03
• Laura will draft some pages
• Barbara will look into adm more and stub adm calls
• Walter will decide on max quotas.

01/13/03

• Gretchen will obtain resources for the Web UI
• blk will investigate the basic adm work for the back end.

ChangeLog

0.9  - 02/12/2003 - minor updates to paths and such.
0.8  - 01/21/2003 - revised based on meeting yesterday. Updated MacOS
		    X foo after talking with Joe.
0.7  - 01/13/2003 - revised based on meeting today. 
0.6  - 01/06/2003 - add open issue about MacOS X prefs; command line
0.5  - 01/06/2003 - revised based on meeting today
0.4  - 01/05/2003 - add DAMS management; add xq; cleanup
0.3  - 12/11/2002 - Add grm comments
0.2  - 08/29/2002 - Add MacOS X thing per Joe.
0.1  - 08/28/2002 - Initial revision.