«

»

ACL deploy

1. Task of the function

With “Deploy ACL”, the directory structure is written under the target path and the list- and authorization groups created before are entitled to it. Sub-directories without explicit authorizations are not created.

You need write rights to the deploy directory, for example as administrator.

Deploy ACL

2. Paths

Here three paths are displayed:

Source path
The authorization structure was read on the source path. This path is available only in case of the “Migration per Scan”.
You have specified the name while starting the project.

Target path
This is the name, which our migrated share should finally get.
This name can correspond with the source path – this is then the most common instance. It can also get another name, if the final share name does not correspond with the source path.

Why is this name important?

  • In the names of the authorization groups, the directory name, also the release name is entered, if you selected it in the group configuration. In this way you can easily recognize the domains of the authorization group. For this the “defined target” is needed.
  • 8MAN works with the group-description field. In the description field for each authorization group, the complete path is available with server, release and directories. In case of adapted configuration, migRaven creates 8MAN-compatible groups. Therefore indispensable.

Also you have already specified this name while starting the project.

Deploy path  (Target location, Green Meadow)
In this path, the new authorization structure is now written. This deploy path is first offered and reserved with the value of the “Target path”. You can change the provided value. Which name should you specify is indifferent; it must only deviate from the source path.

[Warning] If the provided deploy path corresponds with the source path in case of migration per scan, then you should implicitly rename it. Otherwise write the migration in the source directory. [/warning]

[Important] You must create this path, set the release and give yourself the required rights before the Deploy ACL, in order to be able to write the authorization structure. [/important]

3. Possible variants

– “Source path” and “Target path” are same

migRaven enters the content of the “target path” in case of the “deploy path”. Thus you would migrate directly into the source path without detour! This is possible but not sensible. The new authorization structures are written, the old structures remain. Also the old inheritance-interruptions are preserved. Rework is needed but inadvisable.

[Warning]! In this case, it is important to specify a deploy path deviating from the source path. ! [/warning]

 

– “Source path” and “Target path” are same, “Deploy path” was changed (for example in “Green Meadow”)
It is migrated into an alternative directory (deploy path). At the end (after migration and data transfer), you must rename the source- and deploy-share in such a way that the deploy path receives the share name of the source directory.
This is the recommended and distributed procedure.

 

– While starting the project, various shares were specified in case of “Source path” and “Target path”
migRaven enters the “target path” in case of the “deploy path”. It is migrated into the deploy path.

The share name is changed in this way.

4. Following is generated

Here statistical data on directories and authorization are generated.

5. Action

Deploy is started with a checkmark in case of “I confirm this action” and by pressing the button “Start action”.

6. Report

Displays the current work step during deploy, up to the final message: “The folders of your project and the authorizations assigned to it were written in the file system.”

7. Status

If this work step is successful, then the project gets the status 3 in the project administration