• The new Python extension is now available. It allows customers to deploy and manage WSGI-based Python applications on their websites directly from Plesk.
  • Debian 11 has reached its end-of-life (vendor EOL date - August 31, 2026). Plesk Obsidian 18.0.81 is the last release to support it.
    If you are running Plesk Obsidian on Debian 11, we recommend you upgrade those servers to Debian 12 using our dist-upgrade tool.
  • We plan to deprecate and remove the support for XML RPC protocol versions earlier than 1.6.9.1 in Plesk Obsidian 18.0.82. We strongly recommend that you update all existing integrations using earlier versions of the XML RPC protocol to comply with the version 1.6.9.1 specification.

Forwarded to devs Firewall file_get_contents Problem

marksman1907

New Pleskian
TITLE:
Firewall file_get_contents Problem​
PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE:
CentOS Linux 7.4.1708 Plesk Onyx Versiyon 17.5.3 # 37​
PROBLEM DESCRIPTION:
Hello, I have the following errors when I activate the plesk firewall: file_get_contents does not work on all my sites.
How should I set up the firewall ?


Warning: file_get_contents(): php_network_getaddresses: getaddrinfo failed: Name or service not known in ************* on line 80

Warning: file_get_contents(****************): failed to open stream: php_network_getaddresses: getaddrinfo failed: Name or service not known in **************** on line 80​
STEPS TO REPRODUCE:
add a rule​
ACTUAL RESULT:
Warning: file_get_contents(): php_network_getaddresses: getaddrinfo failed: Name or service not known in ************* on line 80

Warning: file_get_contents(****************): failed to open stream: php_network_getaddresses: getaddrinfo failed: Name or service not known in **************** on line 80​
EXPECTED RESULT:
problem solution​
ANY ADDITIONAL INFORMATION:
​
YOUR EXPECTATIONS FROM PLESK SERVICE TEAM:
Help with sorting out​
 
From developer:

The error occurs because file_get_contents cannot determine the address of the server from which to get the file. If there is no error with the firewall turned off, then the problem is in the established rules of the firewall. DNS service uses 53 port and need check that firewall doesn't block outgoing tcp and incoming/outgoing udp traffic.

In order to say something more specific, we need additional information:

  • did the client establish additional rules, if so, which ones?
  • what is the script for setting iptables?
  • what list of rules is issued by the command: `iptables -L`?
If the customer did not add their own rules, the customer can try to turn off and re-enable the firewall.
 
Back
Top