# Anzeige Disk Quota [ISP3]



## Quest (9. Nov. 2011)

Hallo zusammen, 
ich hab gerade mal in den Menüpunkt der Disk Quotas der Webseiten geschaut. War der vor dem Update auf 3.0.4 schon da? Hab ich bisher gar nicht wahrgenommen.

Jedenfalls zeigt die Übersicht für jede Webseite nur "KB" an, ohne irgendwelche Zahlenwerte.
Handelt es sich hier um einen bekannten Bug?
Oder kann es ein Problem mit der Konfiguration der VZ-Container geben, dass das Disk Quota momentan überhaupt nicht funktioniert?
ISP läuft bei mir in verschiedenen OpenVZ Containern.


----------



## Till (9. Nov. 2011)

Das kann mit OpenVZ zu tun haben. Was gibt denn der Befehl:

rpquota -avug

aus?


----------



## Quest (9. Nov. 2011)

Auf dem Host wie auch in den Containern ein bescheidenes Ergebnis:
# rpquota -avug
-bash: rpquota: command not found

Muss ich noch etwas nachistallieren? Auf dem Host oder in den VZs?


----------



## Till (9. Nov. 2011)

Quota wired bei Openvz auf dem Host für die VM verwaltet, es kann daher seinn dass das Quota zwar funktioniert, es sich aber nicht abfragen lösst. Installier mal die quotatools in der VM.


----------



## Quest (9. Nov. 2011)

Die VMs sind alle nach Perfect Server Lenny installiert, 
das Paket quotatool ist installiert.

Heißt der Befehl evtl. 
"repquota -avug"?
Den Befehl hab ich auf dem System, die Ausgabe ist allerdings leer.


----------



## Till (9. Nov. 2011)

> Heißt der Befehl evtl.
> "repquota -avug"?


Ja, war ein Typo bei mir 



> Den Befehl hab ich auf dem System, die Ausgabe ist allerdings leer.


Dann lässt sich Quota scheinbar nicht aus der VM heraus abfragen.


----------



## Quest (9. Nov. 2011)

Hab das ganze gerade mal auf dem Host probiert, da ist die Ausgabe ebenfalls leer.
Ich vermute mal dann können meine Kunden momentan ihren Webspace über die gesetzten Limits hinaus befüllen?

Es scheint ja auch einige Installationen mit openVZ zu geben wo das mit der Quota sauber funktioniert.
Wo könnte ich mit der Fehlersuche anfangen?


----------



## Till (9. Nov. 2011)

Welches Dateisystem setzt Du auf dem Server ein (schau mal in die /etc/fstab)?


----------



## Till (9. Nov. 2011)

Schau mal hier:

User Guide/Managing Resources - OpenVZ Linux Containers Wiki

zum Thema "Turning On and Off Second-Level Quotas for Container" und speziell "QUOTAUGIDLIMIT".


----------



## Quest (9. Nov. 2011)

Ich hab jetzt per 
# vzctl set 1002 --quotaugidlimit 200 --save
ein Limit gesetzt und Quota für den Container aktiviert.

Im Container bekomme ich folgende Ausgabe:
# edquota root
No filesystems with quota detected.

Hier kommen die fstab und mtab von Host und Container

Host

```
# cat /etc/fstab
proc /proc proc defaults 0 0
none /dev/pts devpts gid=5,mode=620 0 0
/dev/md0 none swap sw 0 0
/dev/md1 /boot ext3 defaults 0 0
/dev/md2 / ext3 defaults 0 0
cat /etc/mtab
/dev/md2 / ext3 rw 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,mode=0755 0 0
proc /proc proc rw,noexec,nosuid,nodev 0 0
sysfs /sys sysfs rw,noexec,nosuid,nodev 0 0
procbususb /proc/bus/usb usbfs rw 0 0
udev /dev tmpfs rw,mode=0755 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,noexec,nosuid,gid=5,mode=620 0 0
/dev/md1 /boot ext3 rw 0 0
```
Container

```
#cat /etc/fstab
# UNCONFIGURED FSTAB FOR BASE SYSTEM
# cat /etc/mtab
simfs / simfs rw 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,mode=755 0 0
proc /proc proc rw,nosuid,nodev,noexec 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,nosuid,noexec,gid=5,mode=620 0 0
```


----------



## Quest (9. Nov. 2011)

Ach ja, per vzquota bekomm ich für diesen Container eine ellenlange Ausgabe, hier die ersten Zeilen davon, geht genaus für weitere userids weiter:



> # vzquota stat 1002 -t
> resource          usage       softlimit      hardlimit    grace
> 1k-blocks       13143340        31895097       35084607
> inodes         185209         8190045        9009051
> ...


----------



## Till (9. Nov. 2011)

Hast Du denn quota wie im perfect setup beschrieben innerhalb des Containers mal aktiviert, so dass die Quota Dateien engelegt worden sind und repquota darauf zugreifen kann? Und für die / Partition ist ja im Container auch kein Quota aktiviert.


----------



## Quest (9. Nov. 2011)

Habe gerade versucht die Schritte zu Quota aus dem Tutorial durchzuführen.
Wie du in meinem letzten Post sehen kannst hat die fstab des Containers keinerlei Einträge, bei denen ich die Quota-Optionen setzen könnte.
Trotz gesetztem Quota-Limit für diesen Container mit anschließendem vzctl restart wird das Dateisystem des Containers scheinbar weiterhin nicht mit Quota eingehängt.


```
# quotacheck -avugm
quotacheck: Cannot find filesystem to check or filesystem not mounted with quota option.
```


----------



## Quest (10. Nov. 2011)

Könnte es ein Problem sein, dass das Dateisystem des Hosts nicht mit Quota eingehängt ist? 
Siehe FSTAB des Hosts weiter oben


----------



## Till (10. Nov. 2011)

Das Quota wird von openvz verwaltet, also ohne ein gesondertes Quotamodul. Du kannst das Quota Paket auch garnicht nicht auf dem Host installieren da das Kernelmodul nicht zusammen mit einem openvz Kernel installiert wedren kann.


----------



## Till (10. Nov. 2011)

Hats Du denn mal nach "openvz repquota" bei Google gesucht? Da ist doch einiges zu finden, inkl einem Bugreport.

OpenVZ Forum: Support » Second level quotas mystery


----------



## Quest (10. Nov. 2011)

Hmm, der Patch im OpenVZ-Bugtracker ist schon ein paar Monate alt, aber scheinbar noch nicht in den Kernel gewandert.
Hab gerade mal ein Update gemacht und die Maschine neu gestartet, hat sich leider überhaupt nichts geändert. 
Zumindest weiß ich jetzt schon mal, dass ein Blick in die /etc/fstab gar nichts bringt, weil diese Infos innerhalb des Containers mittlerweile in /proc/mounts gewandert sind.

Muss ich wohl warten, bis endlich ein stabiler Kernel da ist, der für dieses Problem gepatcht wurde ...
Danke trotzdem für die Hilfe.


----------



## Quest (10. Nov. 2011)

Ein interessantes neues Problem ist hinzugekommen.
Seit ich den OpenVZ Kernel aus dem Debian Repository auf 2.6.26-2-openvz-amd64 upgedatet habe sind die ausgehenden Verbindungen der Container gekappt.
Von außen sind sie weiter normal erreichbar.


```
# sysctl -p
net.ipv4.conf.all.rp_filter = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.default.forwarding = 1
net.ipv4.conf.default.proxy_arp = 0
net.ipv4.ip_forward = 1
kernel.sysrq = 1
net.ipv4.conf.default.send_redirects = 1
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.proxy_arp = 1
net.ipv6.conf.all.proxy_ndp = 1
net.ipv4.conf.eth0.proxy_arp = 1
```


----------



## Till (10. Nov. 2011)

Hast Du per IP oder Domain getestet? Vielleicht ist es ja nur der dns? Und hast Du schon bei google gesucht?


----------



## Quest (10. Nov. 2011)

Ja, ich habe gegoogelt.
Den Ping hab ich erst mit Domain getestet.
Jetzt gerade noch mal mit IP, da geht der Ping wunderbar durch.

Dann der Test per nslookup mit dem bisher verwendeten Nameserver 145.253.2.75 auf google.de:

```
> google.de
;; connection timed out; no servers could be reached
> server 8.8.8.8
Default server: 8.8.8.8
Address: 8.8.8.8#53
> google.de
;; connection timed out; no servers could be reached
```


----------



## Till (10. Nov. 2011)

Dann schau mal nach, welche DNS Server in der openvz Config der VM stehen. Ändere sie ggf mal auf:

8.8.8.8 8.8.4.4

(das sind die freien google dns server) und starte die VM neu.


----------



## Quest (10. Nov. 2011)

Vielen Dank für die Hilfe, mit den Google-DNS funktioniert alles wunderprächtig.
Mich wundert nur, dass das in meinem Versuch mit nslookup nicht funktioniert hat.
Da habe ich ja zwischendrin mal auf den Server 8.8.8.8 umgestellt, das hat nicht funktioniert.
Egal, jetzt passt wieder alles.
Bleibt mir nur zu hoffen, dass OpenVZ den Patch aus ihrem Bugtracker bald implementiert.


----------



## Quest (22. Apr. 2012)

Für den Fall, dass hier sonst noch jemand das Quota-Problem mit Debian Squeeze hat:

Bei mir ist das Problem jetzt erledigt.
Problematisch ist, dass es von OpenVZ kein offizielles Repository für Squeeze gibt. Ok, ein Verzeichnis auf dem Repositoryserver gibt es, aber das ist leer ...
In den Kernel im orginal Debian-Repo ist der Patch stand heute soweit ich weiß noch nicht eingeflossen. Er wurde lediglich in den RHEL-Kernel übernommen, der unter Debian ja nur mühsam einsetzbar ist.

Deshalb habe ich jetzt bei mir auf den Proxmox-Kernel umgestellt.
Dieser basiert auf dem aktuellen RHEL-Kernel, wurde aber für Debian portiert.
Seitdem kann auch unter Debian Squeeze Gästen das Quota ausgelesen werden.

Führt nach dieser Wikiseite die Schritte 
'Adapt your sources.list' und 'Install Proxmox VE Kernel' aus und alles ist wunderbar.

Install Proxmox VE on Debian Squeeze - Proxmox VE

ACHTUNG:
Wenn ihr schon VEs konfiguriert hattet:
Proxmox verschiebt das Verzeichnis /etc/vz/conf nach /etc/vz/conf.org und erstellt unter /etc/vz/conf einen Symlink nach /etc/pve/openvz.
Nach Installation von Proxmox VE sind also scheinbar erst mal alle VEs 'weg'.
Kopiert die Config Files aus conf.org wieder nach conf und startet openvz neu
# /etc/init.d/vz restart
Danach ist alles super.


----------



## Till (22. Apr. 2012)

Danke für Deine recherchen und die anleitung!


----------

