Hi Holger,
ich hatte die aus dem data Verzeichnis genommen, da ich es wohl geschafft hatte, dort Leichen zu vergraben. Aber du kannst ja erstmal die 700 so löschen und gucken, ob in data was übrig bleibt…
Viel Erfolg, Max
Hi. Ich schiebe dieses Thema nochmal nach oben, da es bei uns in Sachen „NextCloud für alle“ demnächst auch damit losgehen wird, dass alte Accounts, die es im LDAP/AD gar nicht mehr gibt, auch unter NextCloud gelöscht werden müssen. Hat das jemand unter NC 18 ausprobiert und funktioniert das weiterhin so wie hier gezeigt?
Problematisch scheinen ja weiterhin die Files zu sein, die von Leuten geteilt wurden, die dann gelöscht werden sollen – oder?
Hallo Michael,
wie das mit Dateien ist, die geteilt wurden, weiß ich nicht, das müsste man mal ausprobieren.
Ich lösche meine Schüler jedenfalls immer noch so (war im Sommer aber noch NC15).
Eigentlich sollte es ja eine eingebaute LDAP-cleanup-funktion geben, in der config.php die Zeile
'ldapUserCleanupInterval' => 5,
aber das hat bei mir keine Auswirkung. Ich habe allerdings auch von Version 6 ab hochgedatet, vielleicht ist da auch etwas einer älteren Version hängengeblieben…
Was jedoch mittlerweile geht, ist
'activity_expire_days' => 14,
welches die Datenbankgröße der Aktivitäten schön klein hält, bis Version 14 oder so hatte ich noch ALLE jemals gespeicherten Aktivitäten drinnen.
Hallo Max.
OK, gut zu wissen.
Die Option zum Aufräumen der Aktivitäten habe ich zufällig gestern auch gesetzt. Es fiel auf, dass das bei Kalendereinträgen durchaus sinnvoll sein kann, da nicht alles zu loggen…
Die andere Option hatte ich auch schon gesehen - weiß aber auch nicht, ob es funktioniert. Wir denken über eine Cloud für Schüler nach… Da müssen solche Aufräumarbeiten jedenfalls regelmäßig laufen, damit das nicht unnötig voll läuft…
Schönen Gruß
Michael
Wenn man aber sein Portfolio in der Cloud liegen hat und nach zwei Jahren feststellen will, wer die Datei XY zum letzten Mal editiert hat, ist expiry in 14 Tagen auch nicht gut.
Ich hab eine riesige activity-Datenbank.
VG, Tobias
Hallo Tobias. Ja, mag sein … aber muss man das unbedingt wissen? Da gelten doch sicher auch irgendwelche Zeiten, die man in Sachen Datenschutz einhalten muss ?
Wenn ein User eine Datei bearbeitet hat, die in einem shared-ordner liegt, kann man doch davon ausgehen, dass sein Editieren nicht ein schützenswertes Datum ist, oder?
Datenschutz hin oder her: wenn die Datei verändert wurde, würde ich gerne die Historie sehen: zumindest wer hat sie wann bearbeitet…
wer sein portfolio im OSP pflegt hat das auch - über Jahre, oder?
Ein Kollege hatte zu Testzwecken in einen öffentlichen Kalender seine (Privat-)Termine per .ics importiert und wieder gelöscht. Das war kein Problem. Aber in den Aktivitäten stand dann sehr detailliert, um welche Termine es sich handelte – und das zurück bis ins Jahr 2014. Das waren schon schützenswerte Daten, so dass wir die Aktivitätenliste einfach gelöscht haben…
Erläuterung: Der Pfad zur cloud muss angepasst werden. Bei mir ist es das Verzeichnis ‚owncloud‘, obwohl dort eine nextcloud werkelt. Auch das script liegt in diesem Verzeichnis und muss ausführbar sein. Einmal gestartet gibt es für jeden gelöschten user eine Bestätigung. Da ganz oben in der Datei deluser ‚Nextcloud name‘ steht, startet die Ausgabe mit user ‚does not exist‘. Danach kann man gemütlich beim Löschen zuschauen. Das dauerte bei mir ein Weilchen und zwischendurch bekam ich es mit der Angst zu tun, dass alle user sterben
Push – auch diesen Beitrag schiebe ich nochmal nach oben. Nutzt das von Euch noch jemand auf diese Art und Weise mit einer aktuellen Nextcloud?
Wir haben nun die Situation, dass viele Schüler die Nextcloud für ihre Backups nutzen und der Speicher dort langsam aber sicher voll laufen wird. Da ist ein jährliches Aufräumen und Löschen alter Accounts mitsamt belegtem Speicher auf jeden Fall notwendig.
Ja, am jahresende.
Ich habe mir folgendes Skript gebastelt, s.u.
seit diesem Jahr habe ich die Nextcloud in docker, d.h. ich muss schauen, wie ich den Befehl abändere, z.B. occcmd="docker exec -it -u 33 nextcloud-devel-fpm /var/www/html/occ"
und der phpcmd entfällt dann wohl…
Das Skript kopiert sich zuerst auf den Cloudserver (scp), dort führt es sich dann aus (ssh $0 $1).
#!/bin/bash
# Copyright 2019-2023 Tobias Küchel <devel@zukuul.de>
# This piece of software is licensed under:
# SPDX-License-Identifier: GPL-3.0-or-later
# ideas and pieces of this script from Max Führinger from the wiki
## your cloudserver should be configured here:
cloudserver="cloud-ext"
## path to the occ command on the cloudserver
occcmd="/opt/nextcloud/occ"
phpcmd="sudo -u www-data php --define apc.enable_cli=1"
## path to the data directory on the cloud server
data="/srv/nextcloud/data"
## list of directories on $data/ which should not be considered for deletion
excludelist="(appdata|files_external|rainloop|__groupfolders|updater-|vplan|plan)"
## kopiere dieses Script auf den Cloudserver
if [ `hostname -s` = "server" ]; then
echo "Kopiere dieses Script $0 auf den Cloudserver: $cloudserver und führe es dort wieder aus"
scp $0 $cloudserver:$0
ssh -t $cloudserver $0 $1
exit 0
fi
##############################################################################################
homelist=`mktemp`
pv --version > /dev/null
if [ $? -ne 0 ] ; then
apt install pv bc
fi
simulate=""
if [ "$1" = "--simulate" -o "$1" = "-s" ]; then
echo "Simulation! Es wird nichts gelöscht!"
simulate="echo Kommando wäre: "
fi
### Zeige, frage und lösche alle User, die nicht mehr im LDAP sind:
echo -n "Users scheinbar nicht mehr im LDAP: "
$phpcmd $occcmd ldap:show-remnants | awk '{print $2}' | sed "2d;/^\s*$/d" > /tmp/zuloeschendeuser
if [ -s /tmp/zuloeschendeuser ]; then
cat /tmp/zuloeschendeuser | paste -s -d " "
lines=$(cat /tmp/zuloeschendeuser | wc -l)
lines=$(echo "$lines * 2" | bc -l)
for i in `cat /tmp/zuloeschendeuser`; do
$phpcmd $occcmd ldap:check-user "$i";
done | pv -l -s $lines > /dev/null
$phpcmd $occcmd ldap:show-remnants | awk '{print $2}' | sed "2d;/^\s*$/d" > /tmp/zuloeschendeuser2
if ! diff /tmp/zuloeschendeuser2 /tmp/zuloeschendeuser ; then
echo "HUCH. Bitte starte das Programm nochmal. Es schienen beim ersten Durchlauf LDAP-User nicht zu existieren, die nach einen Check doch existieren!"
exit 0
fi
[[ -n $simulate ]] && echo "SIMULATION: würde in keinem Fall etwas löschen!"
echo -n "Sollen diese User gelöscht werden? yes/NO "
read
if [ "x$REPLY" = "xyes" ] ; then
for i in `cat /tmp/zuloeschendeuser`; do
echo -n "$i: "
$simulate $phpcmd $occcmd user:delete "$i";
done
fi
else
echo "keine"
fi
### Erstelle eine Liste an Usern mit Dateien in der Cloud
echo -n "Erstelle Liste aller User mit Dateien in der Cloud: "
ls $data | grep -v "\." | grep -vE $excludelist > /tmp/userlist
echo `cat /tmp/userlist | wc -l` "user"
### Erstelle die Liste aller User mit Dateien, die nicht mehr im LDAP sind
echo "Checke, ob User noch in LDAP sind:"
for i in `cat /tmp/userlist` ; do
## not an LDAP user?
if $phpcmd $occcmd ldap:check-user "$i" | grep "not" 2>/dev/null >/dev/null ; then
# not a local user?
if ! $phpcmd $occcmd user:info "$i" 2>/dev/null >/dev/null ; then
## then add him to the list
echo "$i" >> $homelist
fi
## echo one byte
echo -n "x"
else
## echo one byte
echo -n "."
fi
done | pv -s `cat /tmp/userlist | wc -l` > /dev/null
### Zeige, frage und lösche alle User, die scheinbar noch Dateien in der Nextcloud haben
echo -n "Users in $homelist, deren Home gelöscht werden könnte $data: "
if [ -s $homelist ]; then
cat $homelist | paste -s -d " "
[[ -n $simulate ]] && echo "SIMULATION: würde in keinem Fall etwas löschen!"
echo "Sollen diese User per rm -rf $data/<user> gelöscht werden? yes/NO"
read
if [ "x$REPLY" = "xyes" ] ; then
for i in `cat $homelist`; do
$simulate rm -rf $data/$i
done
fi
else
echo "keine"
fi
exit 0
rm /tmp/zuloeschendeuser
rm /tmp/userlist
rm $homelist
[… etwas später…]
Ich habe die Zahlen nochmal geprüft: bei uns sind > 600 User im attic und könnten nun auch von der Nextcloud gelöscht werden. Vom v7-Server wurden sie bereits entfernt. Es ist offenbar so, dass der Prozess ldap:check-user in dem Script etwas länger dauert und es in der Summe bei so vielen Usern daher schon mal etwas dauern kann.
Es ist aber noch eine andere Frage aufgetaucht:
Wenn man nur den Befehl occ ldap:show-remnants verwendet, erhält man ja eine sehr detaillierte Tabelle, von der die letzte Spalte Sharer lautet.
Bei den meisten Usern steht da ein N (No) aber wie geht ihr vor, wenn da ein Y (Yes) auftaucht? Es könnte ja sein, dass der Login dann z.B. einem Kollegen gehörte, der in den Ruhestand gegangen ist, doch der kurz vorher noch ein paar Dateien mit den Kollegen geteilt hat. Ich weiß nicht, was in diesen Fällen mit den geteilten Ordnern/Dateien geschieht und erst recht nicht, wie das bei den Usern aussieht, mit denen die Dateien/Ordner geteilt wurden?
Habt ihr diesen Fall einmal durchgespielt?
Ich zögere aus diesem Grund noch, das Script einfach laufen zu lassen…
Ja, das haben wir immer vorher bedacht - und die Daten umgezogen - oder hinnehmen, dass sie weg sind.
Ordner, der „Old Surehand“ gehört und mit Winnetou und Hatschi geteilt wurde, verschwindet halt aus der Sicht und Greifbarkeit von Winnetou und Hatschi, wenn Old Surehand in Rente geht und rausgekickt wird.
Ist halt so. Es ging bisher immer insofern gut, als dass die Kollegen wussten, dass es relevante Daten von Kollege X gibt, der demnächst nicht mehr da ist.
...
: The specified user was deleted
: The specified user was deleted
...
Ok – sehr gut, wenn es so einfach ist … es hätte ja auch in einem dead-Link enden können.
[… und noch etwas später …]
Ok – es ist sauber durchgelaufen. Die Dateileichen sind jetzt entfernt und es ist kein User mehr da, den es nicht auch im LDAP gibt. Super!
Dazu noch ein sudo -u www-data php occ trashbin:cleanup --all-users
und die Mülleimer aller User sind auch gleich entleert.
Hat Platz gebracht
?
