Quotas Cross Site Meeting Summary
Goal: Initial discussion on quotas in the DICE world
Present: Neil, Roger, John, Bill, Chris, Iain
Actioned: This report was actioned in the meeting of 2002-04-02
- 2002-04-17
- On 11/4/2002 we had an initial meeting to discuss what a quotas system
in the DICE world should do and how we might go about achieving this.
- 2002-04-25
- Updated with the results of some email
exchanges, standing in hall ways discussions. Plus my own radical
proposal.
- 2002-05-03
- Updated with some of the decisions/dicussions
, from the last COS meeting, including the rejection of my radical
proposal :-(.
Decisions
The outcome the meeting are as follows, for more details read on.
- We need a flexible system, similar to dcsquotas.
- All users will be subject to a quota, even if that quota is an
unlimited quota.
- Potentially any partition, whether exported or not, will be
quota'd.
- When talking quota limit, we mean the hard limit in file size.
- We want to store individual quotas with user LDAP objects, it
seems the most logical place, and when a user object is deleted, any
extra quota is also removed.
- We need some warning mechanism so that users are alerted as they
approach their hard limit. Presumably something that will slot into
what the default environment task provide.
Current situation
The 3 existing sites manage user quota's in different ways:
- At AI the default is not to run quotas, though the different classes
of users are told what their notional quota is, and for UG1 and UG2 a
script is run that reports when users are close to or over that
limit. If they do not limit their usage, then a filesystem quota is
applied to their account.
- At CogSci, all users are quota'd. Each account is individually
managed via the 'edquota' command(!) Fortunately almost all home
directories are on a single fileserver.
- At CS only undergrads are quota'd. A home grown system called
'dcsquota' is used to manage this. This consists of a single config
file that can assign quota by netgroup, partition or individual. This
information is then extracted by each fileserver and the 'quotas' file
generated.
What was dicussed
- Quota needs
- It was decided that certainly all undergrads
should be subject to a quota, variable by the course/year they are,
and not depending on where their home directory happens to be
hosted. We should extend the idea of all users having a quota, even if
the quota is "unrestricted" for some classes of users. However, a
blanket decision that staff would have a unrestricted quota would not
work well at BP, where their staff have a very definite quota to stop
disks from filling up. So it was agreed that sites would/should be
able to continue giving specific quota's to staff/PhDs at their
site.
- Hard/Soft quotas
- There was some discussion about hard and soft
quota limits, a final decision was not made, but the various options
are:
- Hard and soft limit set to the same. So when you reach your quota,
that's it. The builtin quota command cannot be used to warn that
you're reaching your limit, but the user will be to have up to their
limit of files permanently on the system.
- Hard limit set to quota and soft limit is less. If we set the hard
limit to the users quota eg 10MB, and the soft limit to say 9MB, then
we can use the quota function to warn the user that they are
approaching their limit as they pass the 9MB limit, but after a
specified time (Check this time can't be an indefinite length of
time) if the user is constanly using 9.5MB, then the soft limit
goes hard and the user must remove some files to bring them below the
9MB limit. So despite having a quota of 10MB, they can only
permanently use 9MB of it.
- Soft limit set to quota and hard limit is something more. If we
set the soft limit to the user's quota, say 10MB and the hard limit to
11MB, then the user can use all 10MB permanently, but if they go over
10MB for a length of time they will then find a hard limit comes into
affect. The danger here is that the user may get used to using the
11MB and get confused when it suddenly goes hard and they have to
reduce their usage to below 10MB. Again we can use the builtin quota
function to warn the user, and really its a user education problem.
I think we were favouring options 1 or 3. Option 1 is perhaps the
easiest for the user to understand, but we would then have to provide
our own warning mechanism to alert users as they approach their quota
limit. Note It is generally assumed that when you reach your
quota, you will have problems logging in, due to the login process
requiring the generation of files in your home directory.
- Roles
- We want to be able to affect mass changes by changing
a value in a single place. Associating a quota with a users
roles/capabilities seems to be the way to do this. We need to pin
Simon down on just what we can expect to be able to with his
roles/capabilites stuff.
- Storing quota with the user
- dcsquota's is nice, but Neil spotted some cases it doesn't cope
with very well eg giving someone just 10MB on a particular partition,
as any group quota is also applied to that 10MB, and it seems more
logical for the quota information to be associated with the user.
Benefits:Removing a user would automatically remove any
quotas associated with that user. Calling up a user's LDAP object
would reveal just how much quota they had on the various partitions.
Drawbacks:Information scattered throughout LDAP, no easy
way to spot users with odd quotas (house keeping), though tools could
be written to extract that info.
- Extraction
- As the actual quota system will be running on
legacy and dice fileservers of differring OSs, we have (sort of)
decided that what runs in the DICE world and extracts the information
from LDAP, will ultimately produce quota data with as much detail as
possible for each partition in the Division. The tool running on the
fileserver then downloads this information (via HTTP, rsync, scp or
whatever) and should need to do as little processing as possible to
create the necessary quotas file for the associated
partition.
Following the original face to face meeting, various emails and
discussions in hallways have occurred. Some of which is summarised
below.
How might it actually?
It look(s/ed) like we were going to store the relavent quota
information with the object that the quota applies to. For flexibility
these objects would be the user, a role, a partition. The
resulting quota that a user has on a partition would be a function of
any individual quota they had assigned, the roles they may have, and
finally any partition specific quota. So for the majority of users,
they would not need a quota associated directly with their LDAP user
object, but rather quota associated with the role(s) object(s) they
had. The syntax has not been decided, but perhaps something like this:
object: partition
objectClass: partitionEntry
objectClass: quotaRecord
cn: u8
partitionServer: bigga
[other regular partition object attributes]
quota: >1MB
object: role
objectClass: roleDescription
objectClass: quotaRecord
cn: ug3
capabilities: login/lab3
[other regular role object attributes]
quota: @HOME 20MB
quota: @WEB 4MB
quota: @MAIL 2MB /* I know we're not having mail for undergrads, */
/* it's just an example */
object: person
objectClass: posixAccount
objectClass: quotaRecord
[other regular person object attributes]
uid: neilb
primaryRole: ug3
homePartition: u8
quota: @WEB +10MB
quota: @HOME 40MB
The @HOME, @WEB would expand in the extract process to be what was
defined as the home directory and web directory for the user. This
would mean that if the user is moved to a new partition, you only have
to update the homePartition attribute, and not any
quota attributes. Likewise if the mail or web partition where
to change location, you only need to update the reference once, not
for all the roles, people, etc.
So in this example:
- The user neilb would have a quota of
40MB on his home partition of u8, 14MB of web space on the
web partition (4+10), and a 2MB mail quota.
- Any other user with the role ug3, and with out individual
quota modifications, would get a 20MB home directory quota, 4MB of web
space, and 2MB of mail.
- Any user that can write to the partition u8 would have a
minium of a 1MB quota.
Again this is just a possible example, the significance of
prefixing quotas with + - = < > is yet to be decided. As is what would
happen with duplicate quota entries. ie if neilb also had the
role tutor, which specified a @HOME 50MB quota, what would be his
resultant home directory quota? Should we add 50MB and 20MB together
to get 70MB, take the max, or leave it as 40MB, as his individual
override wasn't prefixed with > or +, for example?
Possible problems with this
- It's occured to me that most of the quota information is going to be
held in the Role objects, and that we are kind of hijacking their use,
and expanding their original use too far.
- One of Chris's orginal concerns was the spread of information
through out LDAP, and that there's wasn't a simple place to go and
look to get an overall feel for what quotas were applied to who and
where. Though a tool could be written to trawl through all the objects
and extract the necessary quota info, and construct some sort of
summary output.
- Another nice feature of the existing dcsquotas, is that it allows
for comments to be inserted into the config file, so if user neilb is
given a bit extra space, you can comment in the dcsquotas config file
(by the entry that gives neilb the extra space) why he got that space,
who authorised it, and for how long he'd expected to need it for. A
similar provision in the LDAP way of doing things, would be to create
a comments or notes attribute and store aribitary
strings in these.
The last item above, is perhaps the main reason for the U turn I'm
about to suggest. The LDAP database is a public database, and any user
can query it's contents, if we decide we would provide the
comments/notes field above in LDAP, then it would mean that anyone
might see things like 'user X given 10MB to stop his whining!'. Yes,
this could be solved by making sure comments like this aren't left, or
by keeping the comments separate to LDAP, but there is also the
general issue of whether other users should be able to see that a
fellow peer has 10MB more quota than they do. They current 'quota'
command will only let you see your own quota, unless you're root.
Proposal:
Given the above, I suggest that we forget storing
quota information in LDAP, and move to a single config file (under rfe
or the equivalent control) similar to the current dcsquotas
setup. Another benefit of this, is we are taking an existing
technology (though it will need to be modified) and not starting from
scratch.
There was some discussion of quotas at the COS DICE meeting on 30/4/2002.
The issue of private data in LDAP came up, and it was agreed that
it was permissible to have quota information publicly available, as
it is currently at CS as the quotas map is published via NIS. So this
cannot be used as a reason not to use LDAP to store the quota
info. There is still, however, the issue of storing notes/comments
with the quota, which it was felt in appropriate to store publicly.
There are two solutions to the comments/note problem and LDAP.
- Store the comments in a separate, non-public file. This file could
be a source text file that is used to generate the LDAP data, but at
that stage the comments are not transferred into LDAP.
- It is possible to restrict access to certain LDAP attributes to
groups of users, however, these can then not be replicated and so the
master LDAP server has to be queried directly for this information
I think it's a little more complicated than that. We
could replicate it, but you can't guarantee who'll have root access to
the machine, and potentially the restricted attributes. Though in
practice within Inf, it would probably be OK. Check with Simon.
Paul and others were also unhappy about using a single file to
store the quota configuration, rather than LDAP, as this would mean
another mechanism for distributing data. We have LDAP and LCFG, we
should use these, rather than rsync, etc to distribute the quota
config to the file servers.This seems fine in principle, but option 1
above talks about having a source text file for the quota
configuration, which is then parsed and populates LDAP, so that the
client end can then extract the information from LDAP, so that it can
reconstitute the quota config file to generate the quotas! Seems like
idealism gone a bit mad to me [We'll have none of that personal
opinions stuff around here - ed.]
Touched on briefly was the technology to maintain the quota info. I
think the Account Management Technology task got mentioned, and indeed
their report talks about storing quota info with the user, but I don't
think the entire quota system should fall into their lap.
Issue - quotas for multi-homed users post common home directory
Assuming we will be placing hard quotas on users, what happens to
users with more than one site home directory. Say an AI/CS2 undergrad
as a 10MB quota at AI and a 10MB quota at CS for his home directories
at AI and CS. Both of these home dirs are 9MB full. His CS home dir is
becomes his primary home directory, he's told that he should move the
files he wants to keep from /legacy/dai/home/<user> into his
primary home directory. Does he just have to manage with the quota he
has, or will we be increasing his quota so he can blindly copy all 9MB
from AI to CS?
Thoughts?
Neil
(neilb @ dcs)
|
|
Please contact us with any
comments or corrections.
Unless explicitly stated otherwise, all material is
copyright The University of Edinburgh
|
|
