perfsonar development work

[Loukik Kudarimoti <>]

Guilherme, thanks for bringing this to our notice.

Strangely, I have never encountered this problem and haven't heard from 
testers about this problem either. However, I agree that its best to 
avoid it by taking appropriate precautions mainly because the 
precautions seem to be simple and straight forward (although a new RC 
will be necessary for all java services)

I prefer the first approach (use of 127.0.0.1 or localhost). The second 
one could lead to security problems like you mentioned.

Loukik.


Guilherme Fernandes wrote:
> Hi all,
>
> Dimitri came across an old bug that I had discussed some time ago with 
> Roman (when he was defining the base ant targets for the release), and 
> that somehow had been cast aside. When installing a Java service, at 
> the pre-install step you have to choose the IP (or hostname) of your 
> server (that will be the target.server var). Most commonly this will 
> be configured as the IP the server can be contacted on by external 
> clients, since is also the IP used in the service.r.acces_point 
> variable that is sent to the LS, and not localhost or 127.0.0.1 as 
> it's normally used by the testers.
>
> The problem is actually at the ant deploy step. When the target tries 
> to process the wsdd through the AdminService service using an 
> IP/hostname other than localhost or 127.0.0.1, it _sometimes_ gives 
> the error: [..]Remote administrator access is not allowed![..] (note 
> that this is not the error that occurs when you don't wait for tomcat 
> to fully start, that one is: [..] The requested resource 
> (/perfSONAR-CLMP-1.0/services/AdminService) is not available. [..]). 
> Strangely enough, I can't replay it in FreeBSD, only in linux (and 
> actually only tested it in Debian and Ubuntu), but wouldn't make much 
> sense to be so restricted since the tomcat/axis should be the same.
>
> I could think of two ways to fix this. The first one is changing the 
> axis-deploy-targets.xml line:
> <property name="adminService" 
> value="http://${target.server}:${target.port}/${deploy.root}/services/AdminService"; 
> />
> to
> <property name="adminService" 
> value="http://127.0.0.1:${target.port}/${deploy.root}/services/AdminService"; 
> />. This would mean that the service would always be installed in the 
> current machine (I think this is fairly safe to assume, I wonder if 
> anyone would run the steps in one machine to install the service in 
> another (via nfs, for example)).
>
> The other way would be copying a default 'server-config.wsdd' to the 
> service's WEB-INF directory before executing that step. This 
> server-config.wsdd would need the following lines (besides other 
> default configuration):
> <service name="AdminService" provider="java:MSG">
>  <parameter name="allowedMethods" value="AdminService"/>
>  <parameter name="enableRemoteAdmin" value="*true*"/>
>  <parameter name="className" value="org.apache.axis.utils.Admin"/>
>  <namespace>http://xml.apache.org/axis/wsdd/</namespace>
> </service>
> The main problem with this approach is that it would raise a security 
> issue (so we would have to ask the user to change it back to false).
>
> Assuming ${target.server} to be localhost or 127.0.0.1 and asking the 
> user what's the service's service.r.acces_point (in case he wants LS 
> Registration) would mean the same restrictions as the first proposed fix.
>
> Guilherme