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.
> I'm still not convinced that we need a special directory just for this purpose.
> It seems to me we should be able to reuse an existing directory, either an
> existing upload "tmp" directory, or an existing application staging directory.
>
>> As to D):
>> Regard the tips as Sahoo suggest, we can try to enforce use of vc like
>> protocol or automatically decorate the url with vc protocol
> I think that's the wrong approach.
>
> I think we should ignore this issue for now and leave it to a future one-pager.
>