We attempt to deploy an entire branch into production, directly from the STAGING area on TeamSite. The branch is intranet/cr_compliance. You can see the deployment configuration in the attached file named ZERO_deploy_compliance.xml. We are running OpenDeploy not as root, but as user "odeploy" whose uid is 500005 on both the client and server. The user odeploy owns everything under the docroot on the server being deployed to.
We always perform a filelist deployment. In this example, we simply performed a Select All in the workarea and ran a job that eventually called a deployment script that invokes iwodstart with the filelist. The filelist is attached in the file cr_compliance_filelist. When this deployment is executed, every file and directory in the target area (/nike/www/zero/docs/cr_compliance) has its permissions set as we would expect, and as is set up in the deployment config (files: 664, directories: 775). However any subdirectories that are deployed do not have their permissions set as 775, instead the permissions on subdirectories are set to 555, which does not allow for write by anyone, and so the subsequent deployment of any files into subdirectories fails because the directory is not writeable. We have found no reason for this behavior on a UNIX level for the server.
If I create a more detailed filelist (see attached file cr_compliance_detailed_filelist), I can force the results I want, but not without some very undesirable results. This new filelist contains every directory, recursively, within the branch. This forces OpenDeploy to process all of the subdirectories directly, and therefore it sets the permissions on these directories properly, however it also has to process each directory on its own, so let's say this directory tree exists in the cr_compliance branch:
esh
esh/emergency_response
esh/emergency_response/documents
esh/emergency_response/images
esh/emergency_response/images/_notes
esh/emergency_response/_notes
OpenDeploy will process the esh directory, which in turn automatically processes all its subdirectories, which fail due to the problem I described above. Eventually, OpenDeploy will go to the next entry in the filelist and process esh/emergency_response. This will set up the emergency_response directory to the proper permissions, which failed during the last pass, but its subdirectories will again fail. And so on, until all the directories are processed individually. This will eventually copy all the files over and set everything up correctly permission-wise. However, the deployment log will report numerous failures. This is totally undesirable. It will make it nearly impossible to debug any real failures - distinguishing the failures that occurred because of this workaround vs. true failures will take a ridiculous amount of time.
If it weren't for the fact that we can get around this problem by specifying all the distinct directories in the filelist, I would wonder whether this is a UNIX problem. But because we can get around it this way, I'm thinking it's an OpenDeploy problem.
In addition to the attached files I have already mentioned, you will find the following log files:
od_first.log - shows the log output of the original deployment (filelist cr_compliance_filelist)
od_second.log - Shows the log output of the workaround deployment (filelist cr_compliance_detailed_filelist)
Dave SmithSr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com
