Univention Bugzilla – Bug 26025
Samba3/Samba4/NFS Listener Module für Univention Shares sollen Verzeichnisse verschieben können
Last modified: 2013-06-26 14:43:58 CEST
Die Listener für univentionShares (samba3, samba4, nfs) sollen optional das Verschieben des SharePath unterstützen, falls dieser geändert wird.
*** Bug 26032 has been marked as a duplicate of this bug. ***
Anpassungen * die Listener Module aus univention-samba4, univention-samba und univention-nfs verwenden zum Anlegen bzw. Verschieben des Freigabe- verzeichnis nun univention.lib.listenerSharePath aus python-univention-lib (>= 1.0.43). Entsprechender control Eintrag wurde in den Paketen ergänzt * Die Listener sollten nun mit modrdn umgehen können * Der Teil für das Anlegen des Pfades und das Setzen der Berechtigungen wurde aus allen Listener Modulen entfernt und nach univention.lib.listenerSharePath verschoben Verschieben: * Das Verschieben von Freigabeverzeichnissen ist nicht Standard, es muss erst aktiviert werden (listener/shares/rename=yes) * Verschoben wird nur, wenn: * univentionShareHost gleich bleibt und sich univentionSharePath ändert * Die Quelle existiert und das Ziel nicht * Quelle oder Ziel nicht diese Verzeichnisse (bzw. Unterverzeichnisse von diesen) sind: /boot, /sys, /proc, /etc,/dev,/tmp,/root * Quelle oder Ziel keine Mountpoints sind (bzw. unterhalb eines liegen) * Das Ziel darf nicht in / liegen * Quelle und Ziel müssen auf einem "bekannten" FS liegen ( listener/shares/rename/fstypes, default ext2/ext3:ext2:ext3:ext4:xfs:btrfs) Anlegen/Berechtigungen: * Der Pfad wird immer angelegt * Die Berechtigungen werden immer gesetzt (solange des Pfad nicht mit /boot, /sys, /proc, /etc, /dev, /tmp oder /root beginnt) QA, mindestens folgendes: * Testen mit univention-nfs, univention-samba und univention-samba4 * funktioniert alles noch wie früher * werden die Verzeichnisse verschoben/angelegt, stimmen die Berechtigungen * Funktioniert es, wenn gleichzeitig der Name der Freigabe und der Pfad geändert wird (modrdn) * Fehlen wichtige Tests vor dem Verschieben?
Verified: * Die drei Listener-Module verwenden jetzt die gleiche univention-lib Funktion zum Anlegen und Umbenennen von Verzeichnissen. * Der ModRDN-Code ist ebenfalls identisch kopiert in den drei Modulen und funktioniert. * Verzeichnis-Umbenennung funktioniert bis auf die unten aufgeführten Spezialfälle. * Changelog OK Zwei kleinere Bugs, die vermutlich daran liegen, dass os.path.dirname(newPath) leicht durch anhängen eines slashes zu verwirren ist: * share mit Pfad "/test1D/" angelegt. Dann am share-Objekt Pfad geändert auf "/test2D/". Dadurch liegt dann im Dateisystem "/test2D/test1D/" * share mit Pfad "/share/test1D/" angelegt. Dann am share-Objekt Pfad geändert auf "/test1D/". Dadurch liegt dann im Dateisystem "/test1D/test1D/" Beobachtungen/Verbesserungsvorschläge, ggf. als separate Bugs auszugliedern: * dirIsMountPoint verhindert das Umbenennen von /mountpoint/share1 wenn /mountpoint der Mountpoint z.B. für ein lokale ext3 Partition ist. * Wegen möglicher Unterschiede in den Mount-Optionen (z.B. "acl") ist es gut, das nicht von einem Mountpoint auf einen anderen verschoben werden kann. * dirIsMountPoint verhindert das Umbenennen von /mountpoint/share1 aber nur wenn der mountpoint in die fstab eingetragen ist (IMHO OK). * listenerSharePath.py könnte besser univention.lib.fstab verwenden * createOrRename konvertiert Symlinks in Realpfade, allerdings nicht wenn eines der übergeordneten Verzeichnisse ein Symlink ist, der letzte Pfadteil aber nicht. Hier hat sich das Verhalten aber nicht geändert. * mit "ln -s / /shares/redirect" und sharePath='/shares/redirect/' wird der Pfad nicht als Blacklisted erkannt (das liegt ggf. an os.path.islink('/shares/redirect/') == False), nur das Anlegen des Pfads scheitert. Das lässt sich aber vermutlich nicht ausnutzen, da die UMC z.B. /shares/redirect/root ablehnt. * Generell führen Fehler dazu, dass am share-Objekt der neue Pfad steht, aber im Dateisystem das Umbenennen verweigert bzw. das Verzeichnis nicht angelegt wird.
> Zwei kleinere Bugs, die vermutlich daran liegen, dass os.path.dirname(newPath) > leicht durch anhängen eines slashes zu verwirren ist: > > * share mit Pfad "/test1D/" angelegt. Dann am share-Objekt Pfad geändert auf > "/test2D/". Dadurch liegt dann im Dateisystem "/test2D/test1D/" > > * share mit Pfad "/share/test1D/" angelegt. Dann am share-Objekt Pfad geändert > auf "/test1D/". Dadurch liegt dann im Dateisystem "/test1D/test1D/" Der abschließende "/" am (neuen und alten) Pfad wird nun immer entfernt (.rstrip("/"). > > Beobachtungen/Verbesserungsvorschläge, ggf. als separate Bugs auszugliedern: > > * dirIsMountPoint verhindert das Umbenennen von /mountpoint/share1 wenn > /mountpoint der Mountpoint z.B. für ein lokale ext3 Partition ist. Quelle und Ziel dürfen jetzt nicht mehr exakt ein MountPoint sein (bisher startswith()). > > * Wegen möglicher Unterschiede in den Mount-Optionen (z.B. "acl") ist es gut, > das nicht von einem Mountpoint auf einen anderen verschoben werden kann. Verschoben wird nur, wenn Quelle und Ziel auf dem gleichen Device liegen (os.stat().st_dev). > > * dirIsMountPoint verhindert das Umbenennen von /mountpoint/share1 aber nur > wenn der mountpoint in die fstab eingetragen ist (IMHO OK). nun fstab und mtab > > * listenerSharePath.py könnte besser univention.lib.fstab verwenden nein, hab ich nicht gemacht. > > * createOrRename konvertiert Symlinks in Realpfade, allerdings nicht wenn > eines der übergeordneten Verzeichnisse ein Symlink ist, der letzte Pfadteil > aber nicht. Hier hat sich das Verhalten aber nicht geändert. OK, wann ist das kritisch? > > * mit "ln -s / /shares/redirect" und sharePath='/shares/redirect/' wird der > Pfad nicht als Blacklisted erkannt (das liegt ggf. an > os.path.islink('/shares/redirect/') == False), nur das Anlegen des Pfads > scheitert. Das lässt sich aber vermutlich nicht ausnutzen, da die UMC z.B. > /shares/redirect/root ablehnt. Auch dies lag am abschließenden "/". Dieser wird nun entfernt bevor auf einen Link getestet wird. >>> os.path.islink('/shares/link') True >>> os.path.islink('/shares/link/') False > > * Generell führen Fehler dazu, dass am share-Objekt der neue Pfad steht, > aber im Dateisystem das Umbenennen verweigert bzw. das Verzeichnis nicht > angelegt wird. Ja univention-lib angepasst, Abhängigkeit in univention-nfs, univention-samba und univention-samba4 ebenso.
Verified: * Funktionsanpassung OK * Pakete sind mit aktualisierter Abhängigkeit auch python-univention-lib gebaut * Changelog nennt jetzt auch die neuen UCR-Variablen
UCS 3.0-1 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte dieser Bug dupliziert werden: "Clone This Bug"