«

»

Deploy ACL

1. Aufgabe der Funktion

Mit „Deploy ACL“ wird unter dem Deploy-Pfad die Verzeichnisstruktur geschrieben und es werden die zuvor angelegten List- und Berechtigungsgruppen darauf berechtigt. Unterverzeichnisse ohne explizite Berechtigungen werden nicht angelegt.

Sie benötigen Schreibrechte auf den Deploy-Pfad, z.B. als Administrator.

Deploy ACL

2. Pfade

Hier werden drei Pfade angezeigt:

Quellpfad
Aus dem Quellpfad wurde die Berechtigungsstruktur gelesen. Diesen Pfad gibt es nur bei der Projektart „Ressource scannen“.
Den Namen haben Sie beim Projekt-Start angegeben.

Ziel-Pfad:
Dieses ist der Name, den unser migrierter Share endgültig erhalten soll.
Dieser Name kann dem Quellpfad entsprechen – das ist wohl der häufigste Fall. Er kann auch einen anderen Namen erhalten, wenn der endgültige Share-Name nicht dem Quellpfad entsprechen soll.
Warum ist dieser Name wichtig?

  • In die Namen der Berechtigungsgruppen fließt der Verzeichnisname ein, auch der Freigabename, wenn Sie ihn in der Gruppenkonfiguration ausgewählt haben. So können Sie leicht die Wirkungsstätte der Berechtigungsgruppe erkennen. Dafür wird der „Ziel-Pfad“ benötigt.
  • 8MAN arbeitet mit dem Gruppen-Beschreibungsfeld. Im Beschreibungsfeld zu jeder Berechtigungsgruppe steht der komplette Pfad mit Server, Freigabe und Verzeichnissen. Bei angepasster Konfiguration erstellt migRaven 8MAN-kompatible Gruppen. Dafür also unverzichtbar.

Auch diesen Namen haben Sie schon beim Projekt-Start angegeben.

Der Deploy-Pfad

Sind Quell- und Ziel-Pfad gleich, würden wir die neue Berechtigungsstruktur in die Quelle schreiben. Dann wären die ursprüngliche als auch die neue Berechtigungsstruktur im Quellverzeichnis. Und das ist garnicht zu gebrauchen. Wir benötigen also einen Pfad, in den wir das Ergebnis der Migration schreiben. Wie wir ihn nennen ist gleichgültig, z.B. „Grüne Wiese“ oder „temporärer Pfad“,  der Name muss nur vom Quellpfad-Namen abweichen. Eingegeben wird er beim Deploy-Pfad.

Der Deploy-Pfad ist der Pfad in den wir jetzt die neue Berechtigungsstruktur schreiben werden. Er muss vorhanden und leer sein. Er muss, wie die beiden anderen, ein Share oder Unterverzeichnis eines Shares sein. Dieser Deploy-Pfad kann hier noch geändert werden. Den vorgegebenen Wert können Sie ändern, entspricht er dem Quellpfad, sollten Sie ihn unbedingt ändern. Welchen Namen Sie angeben ist  gleichgültig, er muss nur vom Quellpfad abweichen und er muss vorhanden sein..

Wenn bei der Migration per Scan der vorgegebene Deploy-Pfad dem Quellpfad entspricht, sollten Sie ihn unbedingt umbenennen. Ansonsten schreiben Sie die Migration ins Quellverzeichnis.

Sie müssen diesen Deploy-Pfad vor dem Deploy ACL anlegen, die Freigabe einrichten und sich selber die erforderlichen Rechte geben, um die Berechtigungsstruktur schreiben zu können.

Vergabe von Berechtigungen auf den Deploy-Pfad selbst und bei Vererbungsunterbrechung

Der Deploy-Pfad selbst

Der Quell- als auch der Deploy-Pfad können Share als auch Unterverzeichnis eines Shares sein. Folgende Feststellungen betreffen beide Varianten.

  1. Es werden von dem Pfad, der als Quellpfad angegeben wurde, keine Rechte auf den Deploy-Pfad übertragen. Die Migration betrifft ausschließlich die Unterverzeichnisse des Quellpfades.
  2. migRaven schreibt auf den Deploy-Pfad selbst weder List- noch Berechtigungsgruppen. Sie müssen Ihre Berechtigungen auf dem Deploy-Pfad selber vornehmen. migRaven schreibt ausschließlich unter den Deploy-Pfad.

Vererbungsunterbrechung

Die Vererbungsunterbrechung spielt beim Deploy-Pfad eine besondere Rolle.

  1. Bei einer Vererbungsunterbrechung auf einem Verzeichnis werden die auf diesem Verzeichnis befindlichen expliziten Rechte nach unten vererbt.
  2. Rechte, die unter dem Deploy-Pfad und bis über die Vererbungsunterbrechung explizit vergeben wurden, enden bei der Vererbungsunterbrechung – das ist der Zweck der Vererbungsunterbrechung.
  3. Aber es werden auch alle Berechtigtigungen des Deploy-Pfads über die Vererbungsunterbrechung hinaus nach unten vererbt. Das betrifft sowohl die Berechtigungen des Shares als auch die Berechtigungen der Share-Unterverzeichnisse, sofern sie Teil des Deploy-Pfades sind.  Dadurch wird gewährleistet, dass Administratoren auch nach unten hin ihre Rechte behalten. Aber auch alle anderen Rechte des Deploy-Pfades, wie read and execute, write, modify, modify plus, werden vererbt. Diese Berechtigten werden aber nicht in die vorhandenen Berechtigungsgruppen aufgenommen, da diese Berechtigungen erst nach der Erstellung des Sollzustandes beim Schreiben der ACLs hinzukommen.

Wichtig: Wenn Sie Vererbungsunterbrechungen verwenden, sollten Sie vor dem „Deploy ACL“ den Deploy-Pfad komplett berechtigen. Nur so werden die Berechtigungen vom Deploy-Pfad durch migRaven über die Vererbungsunterbrechung hinaus berechtigt. Nachträglich erfolgt das nicht mehr automatisch.

Auch Listrechte werden durch migRaven über die Vererbungsunterbrechung nach unten generiert. Da diese immer nur für „dieses Verzeichnis“ gelten, kann man hier nicht von Vererbung sprechen.

 

3. Mögliche Varianten:

– „Quellpfad“ und „Ziel-Pfad“ sind gleich

migRaven trägt beim „Deploy-Pfad“ den Inhalt des „Ziel-Pfades“ ein. So würden Sie direkt ohne Umweg in den Quellpfad migrieren! Das ist möglich, aber nicht sinnvoll. Die neuen Berechtigungsstrukturen werden hineingeschrieben, die alten bleiben erhalten. Auch die alten Vererbungs-Unterbrechungen bleiben erhalten. Es ist Nacharbeit erforderlich. Also nicht zu empfehlen.

[warning]! In diesem Fall ist es wichtig, hier einen vom Quellpfad abweichenden Deploy-Pfad anzugeben. ![/warning]

 

– „Quellpfad“ und „Ziel-Pfad“ sind gleich, „Deploy-Pfad“ wurde geändert (z.B. in „Grüne Wiese“)
Es wird in ein alternatives Verzeichnis (Deploy-Pfad) migriert. Zum Schluss (nach Migration und Datenübertragung) müssen Sie Quell- und Deploy-Share so umbenennen, dass der Deploy-Pfad den Share-Namen des Quellverzeichnisses erhält.
Das ist die empfohlene und verbreitetste Vorgehensweise.

 

– Beim Projektstart wurden bei „Quellpfad“ und „Ziel-Pfad“ unterschiedliche Shares angegeben
migRaven trägt beim „Deploy-Pfad“ den „Ziel-Pfad“ ein. Es wird in den Deploy-Pfad migriert.

Der Share-Name wird auf diese Weise geändert.

4. Erzeugt werden

Hier werden statistische Angaben zu den Verzeichnissen und den Berechtigungen gemacht.

5. Aktion

Mit einem Häkchen bei „Ich bestätige diese Aktion“ und dem Betätigen des Buttons „Aktion starten“ wird das Schreiben der ACLs gestartet.

6. Report

Zeigt während des Deploys die aktuellen Arbeitsschritte an, bis zur Abschlussmeldung: “Die Ordner Ihres Projekts und die darauf vergebenen Berechtigungen wurden ins Dateisystem geschrieben.”

7. Testlizenz

Bei einer Testlizenz werden max. 19 explizite Berechtigungen geschrieben.

8. Status

Ist dieser Arbeitsschritt erfolgreich verlaufen, erhält das Projekt in der Projektverwaltung den Status 3.