l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
November 4: Social gathering
Next Installfest:
TBD
Latest News:
Oct. 24: LUGOD election season has begun!
Page last updated:
2002 Sep 13 20:11

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
[vox-tech] quotas and kernel v2.4
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[vox-tech] quotas and kernel v2.4



keywords: quota, aquota.user, aquota.group, quota.user, quota.group, 2.4,
2.2, quotactl, edquota, quotacheck, setquota 

I recall someone asking about quotas and having a tough time getting them
to work. At the time, I was using kernel v2.2 and had no problems with
it. However, they were using a 2.4 series kernel.

Now that I have setup a v2.4 box yesterday evening with quotas, and wanted
to share this for others...

Here is a brief summary or micro-mini-howto on how to make this work, at
least on my Debian 3.0 system though most, if not all, can be applied to
most any other modern Linux distro. (There is more information that should
be included, and links to other docs too.)

NOTE: I have read users have been able to get quotas to work with ext3,
and Hans Reiser stated that at least one version of his ReiserFS *did*
support quotas too, but the focus in this e-mail is on ext2. (Much may
apply to use on ext3, and reiserfs but YMMV.)




0) Prepare and boot from a quota enabled kernel...
Compile and install a kernel with the "QUOTA" option enabled. You
should have booted from or be using a kernel with quota support before you
continue.
   (Showing how to set this kernel option is beyond scope of this doc)



1) The quota package...
Install the quota tools for your distro. For my Debian 3.0 system, the
package was called, "quota" and was v 3.04.

 You should have this installed before you go on.

 (You are left to figure this step on your own based on your distro and
  packaging system.)

This package includes (or should include) the various tools you will need
for setting up the quota support, manipulating user/group quotas, and for
scaning filesystems at boot for disk use and freshening up the
file(s) with the most up-to-date info on disk space and who is using
it.



2.0) Tell filesystem/mount/kernel about where quotas should be used...
Presently, AFAIK, you can only enable quotas from the root of a mounted
partition in its mountpoint.

This means, if you have one monolithic filesystem for "/" then you can
only enable quotas for the *whole filesystem*.

This means, if you have /var, /tmp, /usr, /home and /usr/local mounted
from different disks and/or different partitions to the local filesystem,
*each and every one* of the mentioned volumes will need to have their
respective "options" in /etc/fstab modified and lead to the user/group to
have disk space computations done on a per-volume basis. (Say, give mike
50MB in /home but 100MB in /var/spool/mail.) If you don't want quotas on
/tmp and /tmp is on its own partition/disk,then dont include the option or
dont edit quotas for that user on that volume if you do enable it.

Tell mount/kernel to support quotas will on the filesystem
Modify /etc/fstab to add one or more of the following args to the
options field:
usrquota
grpquota

At this point, you could probably reboot to make sure the filesystem does
include quota support when mounted, *or* you could try something like:
(assuming /var was the mountpoint for the volume you were enabling)
# mount -o remount /var
 and it should re-read the new options in your fstab to test your options
  or you could try:
# mount -o remount,usrquota,grpquota /var

after chooing one of the above, you can then try:
# mount
to see if the filesystem includes the args you specified above.
(Sample output with just the "/var" volume included:)
/dev/hda3 on /var type ext2 (rw,usrquota,grpquota)

(If you add both (usrquota,grpoquota), you can get support for both. If
you add only one, you will only be able to have support for one.)

Sample entry from /etc/fstab
(assuming I am doing quotas on /dev/hda3 which is for /var):
/dev/hda3   /var   ext2    defaults,usrquota,grpquota 0 2



2.5) (quota.users quota.group) OR (aquota.users aquota.group)

When using a v2.2 series kernel the files "quota.user" and
"quota.group" should be placed at the root level of the mounted volume. In
the above example, "/var" is the directory to place these files, but yours
will likely be different.

When using a v2.4 series kernel the files "aquota.user" and "aquota.group"
should be placed at the root level of the mounted volume. In the above
example, "/var" is the directory to place these files.

It is ok to have both sets of files (files for v2.4 and v2.2) in the same
mounted volume.

Create these files and set ownership with touch and chmod.

(If you have files "there" before you start, and you delete them, you will
lose previous quota information you set for each user (limits) and disk
space used by each user. Certainly, the disk space and user file use can
be recomputed, but the user settings and restrictions are not so easily
rebuilt. A useful tool "setquota" to specify quota settings from a
command line - great for scripting!) 

Sample with "/var" as the arg and a v2.2 kernel:
# touch /var/quota.user /var/quota.group
# chmod 600 /var/quota.user /var/quota.group

Sample with "/var" as the arg and a v2.4 kernel:
# touch /var/aquota.user /var/aquota.group
# chmod 600 /var/aquota.user /var/aquota.group



3.0) "Build" or "grow" the required quota files....

Preparation for build (Choose A or B):

Once you finish with "A" or "B" (below) you can go to step "3.1"
-----------------------------------------------------------------

A) (This first one is not the "easier" of the two, but better for
    production environment and maintaining good uptime.)
   When these file have been created, you can choose one of two routes. If
   the mountpoint for the filesystem contains any files that could be
   open, you will need to make sure processes with access to those files
   close them. (lsof is a *very* useful tool for this.)

   With the above example, I had plenty of things using "/var". I had to
   shut down my mailing services (qmail), logging services (syslog), 
   DNS server (bind), and exit some admin programs. (use of 
   # lsof | grep "var"
   was helpful in identifying processes that still had files open in
   /var so i could shut them down.

B) Reboot your machine in single user mode with no services running.
   (This is easier and limits risk of users opening files in the
    volume you are setting up.)
   (how to boot in single user mode is beyond scope of this doc)



3.1) Build the quota files:
Use the quotacheck tool with appropriate args to build the respective
files.
For either the 2.2 or 2.4 series kernel, you should be able to try this:
(for the 2.2 series kernel, the files that would be changed would be the
quota.user and/or quota.group, while if booted from a 2.4 series kernel,
the files that would be changed would be aquota.user and/or 
aquota.group .)

A sample using the same /var volume as above that has both group and user
quotas enabled: (one or both are critical steps to perform without one or 
both, you will not be able to edit/modify quotas on the included mounted
filesystem.)
# quotacheck -c -d -u /dev/hda3
# quotacheck -c -d -g /dev/hda3
(The -c flag is for creating the index/db in the related file.)
(The -d flag above is optional and is useful for debugging. You may choose
to drop it if you dont like watch stuff scroll by your screen really
fast.;-)
(The -u OR -g flag specifies to build and check for user or group
respectively.)
(The last arg, is of course the devof the filesystem that contains my /var
in the sample.)



4.) Checking your work...
If there is success, then you should note the sizes of the files should
not longer be zero:
(For 2.2 series kernel)
# ls -l /var/quota.user
# ls -l /var/quota.group
(For 2.4 series kernel)
# ls -l /var/aquota.user
# ls -l /var/aquota.group

Also, you can try:
# quota -v SOMEUSERNAME
# quota -v -g SOMEGROUPNAME
depending on you check for a user or group. If they have no quota
restrictions, the soft and hard should be reported as zero (0) while their
disk space in blocks should be reported for the quota enabled volumes.



5.) Return the system to a state ready for use...

If you chose 3.0,A, then you will want to reverse the shutting down of
 services and re-enable them, or you could try to just reboot.

If you chose 3.0,B, then you may wish to call sync:
  # sync         (and then reboot in multiuser mode.)



6.) Set up your user quota or group quotas with your favorite quota
editing tool. (sample: edquota)

simple examples...
(edit quota on user named mike)
# edquota -u mike
(edit quota on group named mike)
# edquota -g mike



7.) Go be a ruthless admin and imposed heavy quota restrictions on your
users and be sure to read plenty of BOFH. (To be very explicit, "I am
joking about the heavy restrictions, but not the reading of the BOFH.")



END)
Hope this helps someone "out there"

I will take the general content, and be placing it on a web page. It
should be located on http://mike.passwall.com/linux.quotas.html when I get
around to it. This way changes to fix my typos and inclusion of other
ideas can be added and make the document "living" as opposed to this
e-mail which is static and dead. (Links to other docs that discuss items
beyond this docs scope for example...)

-ME

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/CM$/IT$/LS$/S/O$ !d--(++) !s !a+++(-----) C++$(++++) U++++$(+$) P+$>+++ 
L+++$(++) E W+++$(+) N+ o K w+$>++>+++ O-@ M+$ V-$>- !PS !PE Y+ PGP++
t@-(++) 5+@ X@ R- tv- b++ DI+++ D+ G--@ e+>++>++++ h(++)>+ r*>? z?
------END GEEK CODE BLOCK------
decode: http://www.ebb.org/ungeek/ about: http://www.geekcode.com/geek.html



_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Sunset Systems
Who graciously hosts our website & mailing lists!