Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
CIP: Disk quota exceeded
Ich wollte gerade noch ein wichtiges Update deployen, aber seit meinem neusten Buildversuch ist mein Speicherplatz im CIP überschritten. Es war vorher auch schon kritisch (~495 MB), jetzt kann ich nichts mehr übersetzen, da gradle mit der Fehlermeldung “Disk quota exceeded” abschmiert.
Kann man das Übersetzen ggf. in tmp auslagern?
Related: räum’ mal [m]~[/m] auf!
Gradle, like Maven, is downloading lots of artifacts. You might want to change the download directory: http://stackoverflow.com/questions/12016681/how-to-change-gradle-download-location
Das hab ich schon als erstes gemacht 
Derzeit 403,1 MiB in .gradle/ und 73,2 MiB in ADAP (nur git-clone des Projekts). Da ist also nicht viel zu machen.
Danke!
Falls noch jemand auf das Problem stößt, es hilft z.B. Folgendes:
(edit:)
echo "export GRADLE_USER_HOME=/proj/ciptmp/$USER/adap/gradle/" >> .bashrcwas ist denn aus dem guten alten ciptmp geworden? Gibt es das nicht mehr?
Stimmt, ciptmp ist wahrscheinlich die bessere Lösung.
Ich kann nur empfehlen den ganzen .gradle ordner ins ciptmp zu symlinken.
Bitte [m]/proj/ciptmp/$USER[/m] verwenden.
Ja, und Leute sollten mal so ein paar Dinge ueber nicht vertrauenswuerdigen Krempel “aus der Cloud” und Symlink-Angriffe und so lernen. /tmp/vorhersagbarername als Ziel ist eine schlechte Idee…
Liegen da nicht eh bloß die Gradle-Files drin? Bei denen wäre es evtl. ja sogar sinnvoll, wenn die jeder nutzen kann und nicht jeder einzeln runterladen muss.
Bitte um Aufklärung.
Stell dir vor du machst wie oben (frueher, vor den paar edits) vorgeschlagen
Wenn du die erste Person auf dem Rechner seit dem letzten Aufraeumen in /tmp (ueblicherweise per reboot) bist, dann wird das Verzeichnis /tmp/gradle angelegt werden. Das gehoert dann dir und alles ist gut.
Wenn aber jemand anderes da zB einen boeswilligen Symlink hinlegt wie
dann sehr wahrscheinlich Gradle Dateien in das Verzeichnis schreiben, auf das der Symlink zeigt (nicht tun wuerde es das nur, wenn der Author explizit wuesste, dass solche Angriffe passieren koennen und aktiv versucht das zu vermeiden. Tut aber niemand.). Dabei schreibt das Gradle mit deinen Benutzerrechten, d.h. ein Angreifer kann dir wirre Dateien in dein .ssh oder sonstwohin in dein Home legen. Im Zweifelsfall erstmal nur aergerlich, ausser, da ist irgendwo mal eine Datei dabei, die so heisst wie irgendwas was ein Angreifer in deinem home ueberschreiben moechte. zB deine authorized_keys.
Ein anderes moegliches Szenario ist, dass ein Angreifer euch boesen Code per Gradle direkt unterschiebt, indem er nach /tmp/gradle ein fuer alle schreibbares Verzeichnis mit seinem boesen Code legt. Je nachdem wie paranoid Gradle Signaturen von dem Zeug prueft was da drinliegt (oder ob das Java oder sonstwas das tut) kann man dann als du beliebig boese Sachen machen. In dem Fall waere auch ein fuer alle nutzbares /proj/ciptmp/grade problematisch, weil der der das zur Verfuegung stellt vertrauenswuerdig sein muesste…
Generell finde ich so Systeme wie Gradle, wo einfach mal von irgendwo irgendwelcher Code gesaugt und ausgefuehrt wird hochproblematisch. Nur selten findet sowas wie Signaturpruefung, Code-Review oder Versionierung auf eine sinnvolle Art und Weise statt, meistens endet sowas in „oh, geil, neueste Version, gleich mal blind $tool update tippen“…
2 Likes