Gli esperimenti li ho fatti su Scientific Linux 6. Di default quota è già installato, per controllare basta un:
# rpm -qa | grep quota quota-3.17-10.el6.x86_64
Il kernel dispone già del supporto, quindi non ci sarà da fare nulla di particolare.
Per usare il quota, è necessario abilitarlo mountando la partizione con le opzioni relative: usrquota per il supporto a livello di utente e grpquota per quello dei gruppi. E' anche necessario richiamare il comando quotaon per attivare le impostazioni, ma lo vedremo più avanti.
Ipotizziamo di avere una partizione /dev/vdb1 formattata in ext4, mountiamola in /mnt/testquota, attiviamo il quota ed inizializziamo il db
# mount -t ext4 /dev/vdb1 /mnt/testquota -ousrquota,grpquota # quotaon /mnt/testquota # quotacheck -bvug /mnt/testquota
Le opzioni che abbiamo usato per quotacheck sono:
- -b: fai un backup del quotafile, prima di scrivere quello nuovo
- -v: verbose
- -u: abilita il quota per gli utenti
- -g: abilita il quota per i gruppi
Per quanto riguarda quotaon, se salviamo la riga di mount nell'fstab, verrà richiamato automaticamente all'avvio. A proposito di fstab, la riga di configurazione per mountare automaticamente la nostra partizione di prova sarebbe:
# partizione mountpoint fs opzioni dump/prio /dev/vdb1 /mnt/testquota ext4 defaults,usrquota,grpquota 1 2
Torniamo a noi. Abbiamo lanciato quotacheck per creare il db e ci ritroveremo con due file nella nuova partizione:
# ls -lh /mnt/testquota/ totale 40K -rw-------. 1 root root 6,0K 13 mag 05:20 aquota.group -rw-------. 1 root root 7,0K 13 mag 05:23 aquota.user [...]
Questi sono i database che contengono le impostazioni per i gruppi e gli utenti. Non vanno editati direttamente, ma invocando edquota:
# edquota velenux [si apre vi per modificare il file] Disk quotas for user velenux (uid 500): Filesystem blocks soft hard inodes soft hard /dev/vdb1 0 50000 60000 0 20 50
Come vedete, è possibile modificare sia il numero di blocchi (di 1024byte) che il numero di inode (cioè di file e directory che è possibile creare).
Abbiamo impostato un "soft" quota di circa 50Mb ed un hard quota di 60. Il "soft" può essere superato per brevi periodi di tempo, detto grace time, mentre l'"hard" quota è un limite invalicabile. Facciamo una semplice prova:
# mkdir /mnt/testquota/velenux
# chown velenux:users -R /mnt/testquota/velenux
# su - velenux
$ cd /mnt/testquota/velenux
$ for num in $(seq 5); do dd if=/dev/urandom of=prova${num} bs=10M count=2; sync; done
2+0 records in
2+0 records out
20971520 bytes (21 MB) copied, 2,88992 s, 7,3 MB/s
2+0 records in
2+0 records out
20971520 bytes (21 MB) copied, 2,88969 s, 7,3 MB/s
dd: scrittura di `prova3': Superata la quota di disco
2+0 records in
1+0 records out
19496960 bytes (19 MB) copied, 2,85899 s, 6,8 MB/s
dd: scrittura di `prova4': Superata la quota di disco
1+0 records in
0+0 records out
0 bytes (0 B) copied, 1,43602 s, 0,0 kB/s
dd: scrittura di `prova5': Superata la quota di disco
1+0 records in
0+0 records out
0 bytes (0 B) copied, 1,42407 s, 0,0 kB/s
Cos'è successo? Abbiamo provato a scrivere 5 file di 20Mb l'uno, ma la scrittura si è interrotta durante il terzo file e gli ultimi due sono vuoti, come ci conferma un ls:
$ ls -lb totale 60000 -rw-rw-r--. 1 velenux velenux 20971520 18 mag 03:08 prova1 -rw-rw-r--. 1 velenux velenux 20971520 18 mag 03:08 prova2 -rw-rw-r--. 1 velenux velenux 19496960 18 mag 03:08 prova3 -rw-rw-r--. 1 velenux velenux 0 18 mag 03:08 prova4 -rw-rw-r--. 1 velenux velenux 0 18 mag 03:08 prova5
Il totale è praticamente il nostro hard limit:
$ du -sb 61444096 . $ echo 61444096/1024 | bc 60004
Se controlliamo le statistiche, vedremo che ci confermano che abbiamo sforato il "soft" limit e siamo stati bloccati dall'"hard":
# repquota -uv /mnt/testquota/
*** Report for user quotas on device /dev/vdb1
Block grace time: 7days; Inode grace time: 7days
Block limits File limits
User used soft hard grace used soft hard grace
----------------------------------------------------------------------
root -- 20 0 0 2 0 0
velenux +- 60000 50000 60000 6days 5 20 50
Statistics:
Total blocks: 7
Data blocks: 1
Entries: 2
Used average: 2,000000
Nel report vediamo anche che abbiamo 6 giorni di "grace" prima che i file/blocchi over quota vengano cancellati.
Per modificare il grace period si usa edquota con l'opzione -t:
# edquota -t [viene avviato vim] Grace period before enforcing soft limits for users: Time units may be: days, hours, minutes, or seconds Filesystem Block grace period Inode grace period /dev/vdb1 7days 7days
Il default può andar bene, ma possiamo allungarlo se sappiamo che i nostri utenti si connettono raramente, oppure ridurlo se sappiamo che si connettono spesso (e che tendono a sforare spesso il quota!).
Nessun commento:
Posta un commento