Skip to main content
Denny Auerswald が「* MuleSoft *」で質問

Hi everyone, 

 

we’re facing an issue after migrating our MuleSoft Runtime Fabric (RTF) installation from Ubuntu 22 to Ubuntu 24 VMs. RTF itself installs the resource-cache application, which runs an nginx container. The nginx config (nginx.conf, from ConfigMap resource-cache-config) includes:

listen [::]:8010 default_server;

This enables an IPv6 listener. 

 

On Ubuntu 22 (with IPv6 enabled), this worked fine. But Ubuntu 24 has IPv6 disabled, so the nginx container can’t start, leading to pod deployment failures. 

 

Every time we update the ConfigMap (e.g., with a helm update or during pod moves), the IPv6 listener directive comes back, requiring manual editing. We don’t have a permanent solution. 

 

Questions:

  1. Do we need to re-install RTF on Ubuntu 24 to solve this?
  2. Is there a way to disable the IPv6 listener via a setting in the RTF helm chart (values.yaml), or some other config, to stop it reappearing?

Currently we work around it by manually editing the ConfigMap. Any best practice or official guidance would be appreciated! 

 

Thanks in advance.

4 件の回答
  1. 8月3日 12:06

    Hi all, 

     

    following up on the question of disabling the IPv6 listener for RTF’s NGINX (listen [::]:8010

    ) on Ubuntu 24, I received this official response from MuleSoft Support: 

     

    • This is a known RTF product limitation. The Helm chart currently always includes the dual-stack listener in the resource-cache-config ConfigMap, regardless of the node’s IPv6 status. There is no configuration to disable it, and manual changes are not persistent (they will be overwritten by upgrades or pod restarts).
    • An enhancement request has been raised with Engineering to allow conditional exclusion of the IPv6 listener. There is no ETA yet.
    • Recommended approaches:
      1. Enabling IPv6 on the Ubuntu 24 nodes (preferred, permanent solution).
      2. Manually removing the listen [::]:8010 default_server; line from the ConfigMap for a temporary workaround (change will not persist through upgrades or redeployments).

    Thanks for all the support and responses.  

     

    Best regards,   

    Denny 

0/9000