Allow Specifying Listening Ports for Tomcat/FME Web App Server

These ports that are being opened are called ephemeral ports. The current workaround is to set the ports on a system level.

Is this still the case? We have had problem with a closed firewall and to open a large range in the higher interval for FME isn't the most optional solution. It would be exelent if it was better described somewhere (at least I havent found anything more than this article) and also if the range was configurable.

Hi @johanehallgren, Unfortunately, FME Server needs to be able to use a range of ports to function with its different parts. Those upper port ranges are, as Jen has shared, ephemeral ports and are just how FME Server Components communicate on the back channels after main communication is established on the 70** ports (in most cases). So nothing has changed with this requirement. It is sort of not talked about much as not many sites have had to make changes from our defaults.

When you suggest "it isn't the most optimal solution". Did you have something else in mind?

• Is it the need to edit the config file that is a problem?
• Would a GUI help you here?
• Is there another way you would expect us to work with ports between the internal components of FME Server when they are distributed across different systems?

When you suggest "It would be excellent if it was better described...",

1. What do you want better described? The need for high range ports? or;
2. Where the FME_SERVER_PORT_POOL parameter is found in the configuration files (several places)?
3. More information in the FME Server Admin Guide?

We are always looking to improve FME Server and we are always open to suggestions!

Thanks.

Hello

The client we work with have quite rigid security demands.

The network at the company is divided into different zones with limited options to communicate between servers in different zones. Default are all ports closed for inbound traffic at all servers.

As soon a port or a range of ports should be opened the request must go thru the security-department in several steps.

In the current installation the FME Webfront is installed at VW00-4120 and the FME Engine and Core are installed at VW00-3251 (see below).

'

We have followed the documentation and opened:

TCP:445,7069-7082,7500 and 7501 from VW00-4120 to VW00-3251

And

TCP:443 from VW00-3251 to VW00-41520

Initially it seemed to worke well but in a few circumstances there was problems.

When a workspace that is started from the FME webfront and that workspace call another workspace, FME did not returned an answer with the result. We can see in the log that the job is completed but the webfront think the job isn’t completed because the result is not returned. The problem was the same when using FME Desktop and calling services in FME Server, the result wasn’t returned.

What we saw was that there was a block in the firewall in the higher range of ports. When reading this article we started to realise that there could be a non documented communication port that we were facing. We tried the proposed workaround, to restrict the range of higher ports that should be used at OS-level on the webfront-server (VW00-4120) and open those ports in the firewall and then FME started to work as it should.

After seeing how FME Server behave it must be that the FME web api calls FME Core with information about what ports are open for ephemeral communication. But that communication initialise a new communication channel from VW00-3251 (Core/Engine) to VW00-4120 (webfront) and is catched as an inbound request on VW00-4120 (and was blocked). Observe that if it’s a job that only runs one workspace, it works well with returns results. It’s only when a job calls another workspace the specific callback arise.

It would be, in our mind, much better if this call back to FME Web was either using the regular http/https way or that there was another configuration for this call in the fmeServerConfig.txt.

We added FME_SERVER_PORT_POOL setting to all web apps that use transactjob(s). Such web apps are fmerest, fmedatadownload, fmedatastreaming, fmejobsubmitter, fmenotification. The configuration can be changed as follows:

1. Find where Tomcat is installed, navigate to there in the file system.
2. Go to the properties file for each web app

    

   ...\\webapps\\fmerest\\WEB-INF\\conf\\propertiesFile.properties

    

   ...\\webapps\\fmedatadownload\\WEB-INF\\conf\\propertiesFile.properties

    

   ...\\webapps\\fmedatastreaming\\WEB-INF\\conf\\propertiesFile.properties

    

   ...\\webapps\\fmejobsubmitter\\WEB-INF\\conf\\propertiesFile.properties

    

   ...\\webapps\\fmenotification\\WEB-INF\\conf\\propertiesFile.properties
3. Find the FME_SERVER_PORT_POOL setting in propertiesFile.properties, change the setting and restart Tomcat.

This change was completed in FME Server 2018.0 b18246

Hi @johanehallgren,

I was looking at FME Server Ports and Port Diagrams lately and this KB Idea came up on my radar.

One thing that we've started recommending since FME Server 2018 is to not separate the FME Server Web Application away from the FME Server Core. This is more for supporting the new Fault Tolerant mode. We treat the FME Server Core and Web Application as "FME Server" and would then only distribute the FME Server Database, FME Server Share and FME Server Engines.

Pulling the FME Server Web Application back onto your VW00-3251 box would remove the complexity for your Port Rules. You might say that the Web Application is a Web Server and should be separated from the Core but we would share that we think FME Server is a Web Application in its entirety and can be treated as a 'black box' of sorts. Certainly, the port configuration is less involved when these two components of FME Server live together.

But with all that shared... I think it is worth us (Safe) understanding why this is occurring when there's a workspace being called within a workspace. After all, customers are still going to separate these components (because they can) and it would be good to fully understand the ports that are necessary to be open for FME Server to function properly.

To be certain we understand your scenario - can you confirm that there is a parent workspace that contains an FMEServerJobSubmitter? What other Transformers are in the parent or child workspaces that might cause network traffic?

Thank you!

First of all, thanks for your understanding.

Yes there is a parent workspace that contains a FMEServerJobSubmitter.

There are no other transformers in the parent and child workspaces that might cause network traffic.

As you maybe understand we have a client that have very high security demands. That is the reason of the FME-server configuration with a devided webapplicaton and core.

Default are all ports closed in the enterprise firewall.

Feel free to contact me at johan.hallgren.konsult(at)skb.se

Best Regards

Johan Hallgren and Johan Esko