Article ID: 119531, created on Jan 9, 2014, last review on Oct 24, 2015

  • Applies to:
  • Plesk Automation

How does it work?

  1. It is important to understand how communication between the Paralllels Plesk Automation Management Node (MN) and Service Nodes work. All nodes have a public IP (frontnet) and private IP (backnet or communication IP address) and these IP addresses are used according to the scheme below:

    scheme

  2. Determine which IP address is used as public and which is used for communication between nodes. This can be done using the following two methods:

    • To find this on the MN, run the command below (NOTE: use a non-existent file name, because if you select an existing file with defined IP mapping, the utility will try to change IP addresses on your MN without confirmation):

      ~# /usr/local/ppa/bin/ppa.ip_address /tmp/new_file
      

      Check this file to find the communication IP address:

      # cat /tmp/someuniqname
      # You should edit IP addresses to reflect your future settings.
      
      Old main ip=10.39.87.15
      New main ip=10.39.87.15
      
      Old communication ip=192.168.0.15
      New communication ip=192.168.0.15
      

      As you can see, address 192.168.0.15 is used for communication by the MN.

    • For example, you tried to deploy a node, the task failed and you want to find which IP address was used as the backnet (communication) IP. To determine which IP address was selected for communication on the Service Node, you should find out which address is listening on port 8352:

      • Linux:

        # netstat -ntpl | grep 8352
        tcp        0      0 192.168.0.13:8352            0.0.0.0:*                   LISTEN      30878/pleskd
        
      • Windows:

        C:\>netstat -ano | findstr :8352
        tcp        0      0 192.168.0.16:8352            0.0.0.0:*                   LISTEN     
        

      As you can see, IP addresses 192.168.0.13 and 192.168.0.16 are listening on port 8352. This means they are used as communication IP addresses on the Service Nodes.

  3. After you have found the communication IP address (e.g. 192.168.0.13), you can use the check_service_node utility to check Service Node availability:

    ~# /usr/local/ppa/bin/check_service_node --ip 192.168.0.13
    

    It is important to use the communication IP address to check.

What can be wrong?

There may be cases when:

  • check_service_node does not show errors, but Service Node deployment still fails.
  • check_service_node does not work at all, but the Service Node is reachable and can be deployed.

When you deploy a new node, the following should be mandatory:

  • The Service Node communication IP address should be reachable from your MN.
  • Requests to the Service Node communication IP address should come from your MN communication IP (192.168.0.15)

This is important because firewall rules are created for communication IP addresses on nodes, and if requests are not coming from these addresses (because of incorrect routing), they are blocked:

Chain PPA-SN-Rules-INPUT (2 references)
 pkts bytes target     prot opt in     out     source               destination
  0     0 ACCEPT     tcp  --  *      *       192.168.0.15         0.0.0.0/0
  0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0

Example

In a common issue, you use private IP addresses on the MN and Service Node, but routing is configured incorrectly. This means the Service Node address is reachable by ping, but requests are not coming from the private address of the MN.

You can check this in the following way:

  1. On the Management Node, run tcpdump:

    ~# tcpdump -pn -i any -vvA port 80
    
  2. From the Service Node, run telnet to 192.168.0.15 (the MN communication IP):

    ~# telnet 192.168.0.15 80
    
  3. Check the tcpdump output:

    tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
    09:41:03.128202 IP (tos 0x10, ttl  64, id 39372, offset 0, flags [DF], proto: TCP (6), length: 60) 10.39.87.13.49912 > 192.168.0.15.http: S, cksum 0x1a10 (correct), 1968665456:1968665456(0) win 14600 <mss 1460,sackOK,timestamp 2612062908 0,nop,wscale 7>
    

    As you can see, the request came from IP address 10.39.87.13, not from 192.168.0.13. As a result, it was blocked by the firewall (because access to port 8352 is only allowed for the communication IP address 192.168.0.13).

Search Words

Failed to execute command 'install_win_sn.exe'. Check 'c:\POA_Deploy' at host '192.168.0.49' for more details.

Registering Service nodes

--port 8490 is closed.

Automated WinRM Enabling Failed Error during WinRM enabling on Script exit code is -1. Script output (stdout/stderr): Operation timed out

не выполняются задачи в панели управления

Error connecting to mail server

horde Error connecting to mail server.

Error connecting to mail server.

Automated WinRM Enabling Failed Error during WinRM enabling on '8.35.36.203'. Script exit code is -1. Script output (stdout/stderr): Operation timed out/

не выполняются задачи в панели управления

Automated WinRM Enabling Failed Error during WinRM enabling on

Failed to execute command 'install_win_sn.exe'. Check 'c:\POA_Deploy' at host for more details

e0aff7830fa22f92062ee4db78133079 caea8340e2d186a540518d08602aa065

Email subscription for changes to this article
Save as PDF