[Megoldva] Linux Disk Quota - kérdések

Linux-haladó

Debian 6 alatt két kötet esetén quota van beállítva.
Azt szeretném, hogy ha valaki túllépte a rendelkezésre álló tárterületet, akkor arról emailt kapjak (lehetőség szerint csak én, az érintett felhasználó nem).

Jelenleg alapértelmezett beállítások vannak:

$ cat /etc/default/quota
# Set to "true" if warnquota should be run in cron.daily
run_warnquota=

# Add options to rpc.rquotad here
RPCRQUOTADOPTS=

$ cat /etc/warnquota.conf
; ; and # type comments are allowed
# and even blank lines

# values can be quoted:
MAIL_CMD = "/usr/sbin/sendmail -t"
FROM = "root@localhost"
# but they don't have to be:
SUBJECT = Over quota
CC_TO = "root@localhost"
SUPPORT = "root@localhost"
PHONE = ""
#
CHARSET = UTF-8

$ cat /etc/quotagrpadmins
#
# This is a sample groupadmins file (/etc/quotagrpadmins)
#
# Comments begin with hash in the beginning of the line

# In this file you specify users responsible for space used by the group
users: root
mygroup: chief

Kérdések:

  1. Elég csak a /etc/default/quota fájban run_warnquota=true módosítás elvégézése?
  2. Pontosan mire szolgál a /etc/quotagrpadmins fájl? Jól értelmezem, hogy itt adhatok meg egy felhasználót, aki qroup quota túllépése esetén megkapja a mailt? Mire szolgál a "myqroup: chief" opció?
  3. Az megoldható valahogy, hogy csak a root és én kapjak értesítést, az érintett felhasználó nem? A felhasználók adatai (helyi mail címe is) LDAP-ban vannak tárolva.

A repquota -avs parancs hatására olyan falhasználók uid-ja is megjelenik a listában, akik korábban már törölve lettek a rendszerből:

#1059 -- 0K 5120M 6144M 0 20000 25000
#2407 -- 0K 51200K 61444K 0 5000 6000

Normális működés ez? Vagy valahogy ki lehet tisztítani a nyilvántartásból az ilyen bejegyzéseket?

  • 3476 megtekintés

( stra | 2012. 12. 02., v – 23:14 )

1.)
"Elég csak a /etc/default/quota fájban run_warnquota=true módosítás elvégézése?"
Ahhoz, hogy a /etc/cron.daily/quota az abban foglaltak szerint elvégezze a feladatát (lefuttassa a warnquotat), ahhoz igen. De ahogy láthatod, a csoportkvótát nem ellenőrzi ez a script, vagy módosítsd, vagy pedig másolással gyárts újat, és abba vedd fel a -g opciót.

2.)
"Pontosan mire szolgál a /etc/quotagrpadmins fájl? Jól értelmezem, hogy itt adhatok meg egy felhasználót, aki qroup quota túllépése esetén megkapja a mailt?"
man warnquota (-g, --group): "check whether groups are not exceeding quotas. If group is exceeding quota a mail is sent to the user specified in /etc/quotagrpadmins."
Tehát igen.

"Mire szolgál a "myqroup: chief" opció?"
A /etc/quotagrpadmins elején ott van kommentben a leírás: "In this file you specify users responsible for space used by the group".
Illetve az előbbi man warnquota idézet is erről szól. A mygroup csoport csoportkvótájának túllépéséről a chief nevű felhasználó fog értesítést kapni. Ez egy példasor, a Debian alaptelepítésben nincs ilyen felhasználó vagy csoport.

3.)
"csak a root és én kapjak értesítést, az érintett felhasználó nem"
/etc/warnquota.conf: 

  MAIL_CMD        = "/usr/sbin/sendmail -t"

Ez az alapértelmezett konfig. Módosítod, leveszed a végéről a "-t" opciót, ami a man sendmail (postfix) szerint "Extract recipients from message headers. These are added to any recipients specified on the command line." (tartalmilag az Eximé is ugyanígy szól), majd a végére odateszed a címzetteket.

"A felhasználók adatai (helyi mail címe is) LDAP-ban vannak tárolva."
Lásd a dokumentációt: /usr/share/doc/quota/README.ldap-support

"olyan falhasználók uid-ja is megjelenik a listában, akik korábban már törölve lettek a rendszerből" "Normális működés ez? Vagy valahogy ki lehet tisztítani a nyilvántartásból az ilyen bejegyzéseket?"
Igen. A user törlése nem jelenti a user tulajdonában lévő file-ok törlését. Keresd meg ezeket a file-okat, és töröld. A find jó választás rá, tud UID-ra keresni.

Köszönöm a részletes választ.

Beállítottam a run_warnquota=true értéket, és ma reggel már jött is a mail. Viszont az érintett felhasználót is megpróbálta e-mailben értesíteni, de mivel betelt a kvótája, és már a türelmi idő is lejárt, ezért a kézbesíthetetlen levélről is kaptam egy értesítést.

1.)
Csoportkvóta nincs beállítva, ezért jó lesz az eredeti /etc/cron.daily/quota fájl.

2.)
Na ezt jól félreértettem. Én úgy értelmeztem, hogy a "users: root" határozza meg, hogy bármely csoport esetén a csoportkvóta elérése esetén az itt megadott felhasználó (jelen esetben a root) értesül e-mailben, és nem értettem, hogy mire való a "mygroup: chief" beállítás. Most már világos. De mivel nem használok csoportkvótát, nálam ez a beállítás nem játszik.

3.)
Módosítottam a /etc/warnquota.conf fájlt (MAIL_CMD = "/usr/sbin/sendmail root", kommenteztem a CC_TO = "root@localhost", stb), futtattam a /etc/cron.daily/quota szkriptet, és most már elvileg csak én kapom meg a levelet. Viszont érdekes, hogy a levél forrásában továbbra is szerepel az érintett felhasználó (To: felhasznalo kukac akarmi.hu) és a (Cc: root kukac akarmi.hu), de csak a root-nak postázza a levelet.

Minden egyes törölt felhasználó esetén a "repquota -avs" kimenetében a felhasznált terület 0K, és az inodok száma is 0, és csak akkor jelennek meg ezek a bejegyzések, ha a repquota parancsot a -v opcióval együtt használom. És érdekes, hogy a bejegyzés "#"-el kezdődik.
A felhasználókat egy szkripttel törlöm a fájljaival együtt. És a find parancsot is használom a törölt felhasználók esetén, esetlegesen megmaradt fájlokat keresve.

Még egyszer köszönöm a segítséget.

"Viszont az érintett felhasználót is megpróbálta e-mailben értesíteni, de mivel betelt a kvótája, [...]"
A 3. pontban lévő MAIL_CMD módosítása már előtte megtörtént, vagy csak utána?

3.)
Természetesen, hiszen a warnquota programnak az érintett felhasználók értesítése a feladata, amit te szeretnél tőle, - hogy pont ők ne kapjanak belőle -, arra nincs felkészítve. Ez egy kerülőmegoldás. Persze ha csak te akarsz értesítést kapni, és a felhasználónkénti levélhez sem ragaszkodsz, akkor egyszerűbbnek tűnne egy egyszerű repquota kimenetet grepelni. Így egy levélben megkaphatnád az összes, kvótáját túllépő felhasználó adatait.

Tehát mégis van file a rendszeren, ami az övé. A kvóta a legtöbb esetben filerendszerre vonatkozik, így ne csak a /home-ban, hanem az egész filerendszeren keress. Filerendszert tudsz mondani? Ext4 alatt biztosan eltűnik a repquota kimenetéből az utolsó általa tulajdonolt file törlésekor. Ha pedig mégsem, mert tényleg nincs file-ja, akkor lehet, hogy a kvóta adatbázisát kellene újragenerálni. Ilyen akkor fordulhat elő, ha kvóta nélkül mountolva történik az adott felhasználó nevében írás.

"A 3. pontban lévő MAIL_CMD módosítása már előtte megtörtént, vagy csak utána?"
Az érintett felhasználót ma reggel 6.25-kor próbálta értesíteni, amikor a cron futtatta a /etc/cron.daily/quota szkriptet, az eredeti beállításokkal.
Aztán ma 9 óra után módosítottam a MAIL_CMD-t és újra futtattam a /etc/cron.daily/quota szkriptet. Most már nem küldte az értesítést az érintett felhasználónak, de a levél forrásában szerepel az érintett felhasználó e-mail címe a To: sorban, de ennek ellenére most már nem kapja meg. Ez így nekem jó.

3.)
Igen, értem én. De a levelek Maildir formátumban vannak tárolva a /home köteten /home/user/Maildir. És a kvóta is a /home kötetre van beállítva. Igaz 7 nap a grace time, tehát elvileg megkaphatja az emailt, de fölösleges mert a (iskolai környezet) tanulók / tanárok (egy-két kivétellel) nem olvassák az iskolai e-mailjüket. Ezért fölösleges, hogy megkapják az értesítést. (A tanulók lényegében csak akkor használják, amikor megtanulják, hogyan kell postafiókot beállítani.)
Ha van egy kész megoldás, ami megfelel, vagy testre szabható, akkor nem írok újat.

"Tehát mégis van file a rendszeren, ami az övé."
Elvileg nincs.

Csak a /home és a /pub kötetek esetén van quota

# /home was on /dev/sda7 during installation
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /home ext4 defaults,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0 0 2
# /pub was on /dev/sda10 during installation
UUID=yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy /pub ext4 defaults,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0 0 2

És mindkét kötetet ellenőriztem az alábbi parancsokkal:
find /pub/ -nouser -print
find /pub/ -nogroup -print
find /home/ -nouser -print
find /home/ -noggroup -print

A felhasználóknak nincs shell hozzáférésük, tehát máshova elvileg nem tudnak írogatni.

"Ilyen akkor fordulhat elő, ha kvóta nélkül mountolva történik az adott felhasználó nevében írás."
Ez kizárnám, mivel a quota volt a legelső dolog amit beállítottam telepítés után (még tavaly) és csak utána hoztam létre a felhasználókat. A quota adatbázis újragenerálása jó ötlet majd kipróbálom.

De amint azt már írtam is nem jelez diszkhasználatot a törölt felhasználóknál, ez látszik alább is, csak azon lepődtem meg, hogy nyilvántartja azokat az uid-okat is, akik már törölve lettek.

#2400 -- 0 51200 61444 0 5000 6000
#2433 -- 0 51200 61444 0 5000 6000
#2416 -- 0 51200 61444 0 5000 6000

( sirenter | 2012. 12. 03., h – 09:31 )

man find:
...
-nogroup
No group corresponds to file's numeric group ID.

-nouser
No user corresponds to file's numeric user ID.
...

Welcome Back, My Friends, to the FLAME That Never Ends...tisztelet a kivételnek