cancel
Showing results for 
Search instead for 
Did you mean: 

FSR deployment configuration (firewall config?)

dmakovey
Champ in-the-making
Champ in-the-making
Hi,

I'm trying to get FSR deployment to work in my setup and after a bit of head-bumping and tcpdump sniffing I came to conclusion that despite of what http://wiki.alfresco.com/wiki/WCM_Deployment_Features says about the only port (44100 by default) Alfresco is trying to communicate using other port numbers as well. No my question is that in order to get some manageable configuration on FireWall I need to limit the range of ports FSR and Alfresco are trying to negotiate. How can I do this?

As an example: having server "A" running Alfresco and server "R" running receiver Once I have everything configured and initiate deployment I see that initially A:33312 is trying to connect to R:44100, but after some "back and forward" A:59960 is trying to connect to R:49848 and naturally firewall drops that connection after which Alfresco complains that it can't deploy content.

What I need it to be able to "predict" all the ports on R, to which A will try to connect. Better yet - I'd like to define which port range is "safe" to use for both.
2 REPLIES 2

dmakovey
Champ in-the-making
Champ in-the-making
I found it "the hard way" by reading Springs framework documentation that there is one method not covered by default 'application-context.xml' which is :

  <property name="servicePort">
       <value>${dep.service.port}</value>
  </property>

with corresponding entry in 'deployment.properties'


dep.service.port=44101

This allowed me to set "initiation" port to 44100 and "follow-up" port to 44101 and now Firewall rules are clean and connections are coming through as expected. Is there anything I "broke" by doing it?

mrogers
Star Contributor
Star Contributor
I can confirm that nothing is broken by setting the rmi.service.port.

And this is now part of the default configuration from Labs 3b onwards.

P.S.  You can also run the FSR over a single port by setting rmi.service.port and rmi.registry.port to the same number.   I expect there to be a bit of a performance penalty for doing this but it does work for me.