Hi, Bill
On 6/3/2013 6:49 PM, Bill Shannon wrote:
> Hong Zhang wrote on 05/31/2013 06:48 PM:
>> On 5/31/2013 7:31 PM, Bill Shannon wrote:
>>> 吕宋平 wrote on 05/29/13 21:38:
>>>> Hi, Bill, Craig, Hong,Sahoo:
>>>> After the disscusstion recently, I pick up some of the disscussion above
>>>> and list as follows to see whether there still exist any other suggestion:
>>>> A) An option to disable the deployuri command completely should the
>>>> administrator be concerned
>>>> B) An option to limit the URI types that would be allowed
>>>> C) Allow for specification of a "sandbox" area use as the download location to
>>>> better control permissions, ownership, quotas, disk space, etc.
>>>> D) Allow for the possibility to include hooks for virus scanners or other
>>>> intrusion detection software.
>>>> As to A) and B):
>>>> Just regard the tips as Bill had mentioned that we should create an attribute
>>>> or property set with "asadmin set", If different administrators had different
>>>> privileges in the future, we could restrict the use of the "asadmin set"
>>>> command. I think the most important question here is to how to use a
>>>> local-only command to control this option("asadmin set")?
>>> I can't think of any other cases where we do anything like this, so I'm not sure
>>> we have a precedent to follow. Perhaps someone else here has some ideas?
>>>
>>> I think "asadmin set" can be used to modify most anything in domain.xml, so I'm
>>> not sure there's a way to include this configuration information in domain.xml
>>> but hide it from "asadmin set".
>>>
>>> Another option is to store this information in a separate config file, and have
>>> a local asadmin command to manipulate that config file. That seems like
>>> overkill, so I'm hoping someone else will have a better idea
>>>> As to C):
>>>> Regard to the tips as Hong, How about regarding the directory of
>>>> domains/<domain_dir>/applications/__internal/<app_name>/ as a directory to
>>>> store the application download remotely. Of course, the operation to execute
>>>> the download will be executed during the server side.
>>> Does that directory already exist? What's it used for?
>> This is an existing directory where we store/stage the uploaded applications today.
>>
>> When an application needs to be uploaded for a deployment, the application is
>> first uploaded to a temporary directory under domains/domain1/applications by
>> the payload manager, such as:
>>
>> domains/domain1/applications/xfer-6697881642146365610/
>>
>> and then moved to this internal directory for staging:
>>
>> domains/<domain_dir>/applications/__internal/<app_name>/
>>
>> So we could do something similar for this case, upload to a tmp directory and
>> then later move to the staging directory, or directly place it in the staging
>> directory.
> What operations are done on the application when it's in the staging
> directory, before it's moved to the final directory?
No, there is no final directory (maybe it's the wrong term for me to
call it staging directory). This directory is to preserve the files
uploaded during deployment so the sync logic can use them to sync the
files to remote instances.
>
> I'm just trying to figure out why we need three directories -
> an upload/download directory, a staging directory, and the "installed" directory.
>
> Is the archive stored in the upload directory, and then expanded into the
> staging directory?
The archive is first uploaded to the upload directory (when needed) and
then expanded into the installed directory (applications/<app_name>/).
The file is then moved (or copied) to applications/__internal/<app_name>
directory for sync logic to use. We had a discussion on this back in 3.1
when we implemented the clustering/synchronization logic.
Thanks,
- Hong