nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Reverse deployment permissions problem

brizrobbo

Hi Folks,

I am reverse deploying some content from our Intranet server (node=Intranet). However, I want to preserve the same permissions, and when the deployment runs, the permissions are changed for some of the files.

For example:

In source host (OD Rcvr):

drwxr-xr-x   2 beswica  www         1536 Jun  2  2005 bin/
-rwxr-xr-x   1 beswica  www         4551 Feb 21  2005 cgi-lib.pl*
-rwxr-xr-x   1 beswica  www         8063 Aug  1 09:01 confirmedEmailToSlicca.cgi*
-rw-rw-r--   1 beswica  www         8429 Oct  3  2006 confirmedEmailToSlicca.cgi.118

In target host (OD base):

dr-xr-xr-x   2 tsadmin  webdev       512 Dec  6 11:51 bin/
-r-xr-xr-x   1 tsadmin  webdev      4551 Feb 21  2005 cgi-lib.pl*
-r-xr-xr-x   1 tsadmin  webdev      8063 Aug  1 09:01 confirmedEmailToSlicca.cgi*
-r--r--r--   1 tsadmin  webdev      8429 Oct  3  2006 confirmedEmailToSlicca.cgi.118

In my deployment config file, I specifically left out any

file="0664"

directory="0775"

attributes in the

element, which is what we normally use because we normally do want permissions to change.

The important parts of my config file are:


<replicationFarmSet>
    <replicationFarm name="intranetFarm">
        <nodeRef useNode="Intranet"/>
    </replicationFarm>
</replicationFarmSet>

<definition name="silobin_reverse_deployment">

    <reverseSource useReplicationFarm="intranetFarm">
        <sourceFilesystem area="/web/nrm/cgi-bin">
            <pathSpecification>
                <path name="silo"/>
            </pathSpecification>
        </sourceFilesystem>
    </reverseSource>

    <reverseTarget>
        <targetFilesystem area="/iwmnt/default/main/silobin/WORKAREA/webdev"/>
        <comparisonRules dateDifferent="yes" ignoreModes="no" ignoreUser="yes" ignoreGroup="yes"/>
        <transferRules doDeletes="yes"/>
        <permissionRules  group="webdev"
                          user="tsadmin">
        </permissionRules>
    </reverseTarget>

</definition>

Any assistance in helping me figure out what may be causing the permissions to change would be greatly appreciated.

Find more posts tagged with

Comments

Migrateduser

Specifying user and group in permissionRules skips ACL operations so that permissions are not preserved. The files have the ownership of the OD process in such scenario.
Check out the OD admin guide for permissionRules settings.

Adam Stoller

Specifying user and group in permissionRules skips ACL operations so that permissions are not preserved. The files have the ownership of the OD process in such scenario.
Check out the OD admin guide for permissionRules settings.

I'm not saying you're wrong - but can you provide a specific reference for this or provide the text you are citing from the manual?
I took a look and didn't see anything about this (other than that you cannot use the 'user' and 'group' settings the same way when running in non-root mode)

Migrateduser

Few lines from Page 198 OD admin guide 6.0.1
Hope it helps.

Enabling UNIX-Based Deployments When Extended ACLs Are Present

Deployments running on UNIX hosts where extended ACLs are present (DFS, AFS, and so
forth) might fail. When deploying files between OpenDeploy UNIX hosts, OpenDeploy
attempts, by default, to replicate the ACLs from the source to the target. Imposing specific
user-group ownerships is done through the permissionRules element’s user and group
attributes.
On some UNIX file systems, the OpenDeploy process may be prevented from setting ACLs
on deployed files and directories, which causes the deployments to fail.This is caused by
extended security mechanisms introduced by file systems such as AFS and DFS.
In response to this limitation, OpenDeploy supports skipping the set ACL operations. With
this functionality, the deployed items take on the ownership of the running OpenDeploy
process.
To use the enhanced functionality, configure the permissionRules element in the
deployment configuration in the following manner:
[html][/html]
Note: "_iwod_user_" and group="_iwod_group_" are the literal values, not variables.
When the OpenDeploy server sees these special keywords, the set ACLs operations will be
skipped. For example:
[html]

[/html]
This causes OpenDeploy to deploy files to the target on the receiver if the date is different
between sender file and receiver file, and not apply the original ownership to the deployed
items. The deployed items have ownership of the OpenDeploy process.

Adam Stoller

Few lines from Page 198 OD admin guide 6.0.1
Hope it helps.

Enabling UNIX-Based Deployments When Extended ACLs Are Present

Deployments running on UNIX hosts where extended ACLs are present (DFS, AFS, and so forth) might fail. [...]
In response to this limitation, OpenDeploy supports skipping the set ACL operations. With this functionality, the deployed items take on the ownership of the running OpenDeploy process.
To use the enhanced functionality, configure the permissionRules element in the deployment configuration in the following manner:
[html][/html] Note: "_iwod_user_" and group="_iwod_group_" are the literal values, not variables.
When the OpenDeploy server sees these special keywords, the set ACLs operations will be skipped. [...]

The highlighted words in the above are what sets this information distinct from what was described, at least from what we know about it:

get set.Thanks for providing the reference.

brizrobbo

[QUOTE=ghoti]The highlighted words in the above are what sets this information distinct from what was described, at least from what we know about it:

Thanks for the clues. FYI: All the relevent filesystems are VxFS mounted as UFS (I guess that gives us Extended ACLs).I'll chase up with IWOV support about the expected action for the permission mode bits in this case.