I found this a little amazing, but SWSoft don’t actually fully support their own software.

“Unfortunately, SWSoft does not fully support the API that is built in to Plesk and more than likely, they will request that we first perform an upgrade to the latest version of Plesk before they provide any further support.”, Rackspace.

The Fault:
“Domain adding was failed. Error: Can`t resolve ID for IP ()”

NOT Working Correctly
* Server 3 (Plesk 7.5.2)

Working Correctly
* Server 2 (Plesk 7.1.7)
* Server 1 (Plesk 7.5.4)

The IP Address does exist in the domains table, for all servers.

Working Servers:

* Server Name: Server 2

mysql> SELECT * FROM IP_Addresses;
+----+-----------------+-----------------+-------+-----------+--------------------+-------------------+
| id | ip_address | mask | iface | type | ssl_certificate_id | default_domain_id |
+----+-----------------+-----------------+-------+-----------+--------------------+-------------------+
| 2 | 212.100.254.166 | 255.255.255.0 | eth0 | shared | 1 | 47 |
| 3 | 10.230.166.4 | 255.255.255.192 | eth1 | exclusive | 1 | NULL |
| 4 | 192.168.1.20 | 255.255.255.0 | eth0 | exclusive | 1 | 22 |
| 5 | 10.230.166.8 | 255.255.255.192 | eth1 | exclusive | 1 | NULL |
+----+-----------------+-----------------+-------+-----------+--------------------+-------------------+
4 rows in set (0.00 sec)

—————-

Server Name: Server 1

mysql> SELECT * FROM IP_Addresses;

+----+---------------+-----------------+-------+-----------+--------------------+-------------------+
| id | ip_address | mask | iface | type | ssl_certificate_id | default_domain_id |
+----+---------------+-----------------+-------+-----------+--------------------+-------------------+
| 1 | 70.85.198.202 | 255.255.255.248 | eth0 | shared | 1 | NULL |
| 2 | 70.85.198.203 | 255.255.255.248 | eth0 | shared | 1 | NULL |
| 3 | 70.85.198.204 | 255.255.255.248 | eth0 | exclusive | 1 | 65 |
| 4 | 70.85.198.205 | 255.255.255.248 | eth0 | shared | 1 | NULL |
| 5 | 70.85.198.206 | 255.255.255.248 | eth0 | exclusive | 7 | 15 |
+----+---------------+-----------------+-------+-----------+--------------------+-------------------+
5 rows in set (0.00 sec)

—————

Failed Server

Server name: Server 3

mysql> SELECT * FROM IP_Addresses;

+----+---------------+-----------------+-------+-----------+--------------------+-------------------+
| id | ip_address | mask | iface | type | ssl_certificate_id | default_domain_id |
+----+---------------+-----------------+-------+-----------+--------------------+-------------------+
| 4 | 10.230.166.7 | 255.255.255.192 | eth1 | exclusive | 1 | 0 |
| 5 | 192.168.1.22 | 255.255.255.0 | eth0 | shared | 1 | 0 |
| 6 | 192.168.1.223 | 255.255.255.0 | eth0 | shared | 1 | 0 |
+----+---------------+-----------------+-------+-----------+--------------------+-------------------+
3 rows in set (0.00 sec)

——-

One fundamental aspect that I noticed from observation is that Server3 had the columns default_domain_id default value set to 0 where as on all other installations had the value set to NULL. The assumption was that the record 0 for the default IP ID against the domain. Although ALTER’ing the table and testing against each resulted without sucess.

Testing against all IP’s in the waidev6 table results in the following.

* 1. [10.230.166.7] – Domain adding was failed. Error: IP address ‘10.230.166.7′ is not present in client ip pool.
* 2. [192.168.1.22] – Domain adding was failed. Error: Can`t resolve ID for IP ()
* 3. [192.168.1.223] – Domain adding was failed. Error: Can`t resolve ID for IP ()

The XML response for this is…

<?xml version="1.0" encoding="UTF-8"?>

<packet version="1.3.1.0">
  <domain>
    <add>
      <result>
        <status>error</status>
        <errcode>2307</errcode>
        <errtext>Domain adding was failed. Error: Can`t resolve ID for IP ()</errtext>
      </result>
    </add>
  </domain>
</packet>

The payload of the XML document sent across via the XMLRPC request.

<packet version="1.3.1.0">
<domain>
  <add>
    <gen_setup>
      <name>testgen8.com</name>
      <client_id>1</client_id>
      <status>0</status>
      <ip_address>192.168.1.223</ip_address>
      <vrt_hst>
        <ftp_login>catalina0</ftp_login>
        <ftp_password>057177a</ftp_password>
        <ftp_quota>0</ftp_quota>
        <fp>false</fp>
        <fp_ssl>false</fp_ssl>
        <fp_auth>false</fp_auth>
        <fp_admin_login>miaumiaul
        </fp_admin_login>
        <fp_admin_password>lalalalallaa<fp_admin_password>
        <ssl>false</ssl>
        <shell>/bin/false</shell>
        <php>true</php>
        <ssi>false</ssi>
        <cgi>false</cgi>
        <mod_perl>false</mod_perl>
        <mod_python>false</mod_python>
        <asp>false</asp>
        <asp_dot_net>false</asp_dot_net>
        <coldfusion>false</coldfusion>
        <webstat>awstats</webstat>
        <errdocs>false</errdocs>
        <at_domains>true</at_domains>
      </vrt_hst>
      <htype>vrt_hst</htype>
    </gen_setup>
    <hosting>
      <vrt_hst>
        <ftp_login>catalina0</ftp_login>
        <ftp_password>057177a</ftp_password>
        <ftp_quota>0</ftp_quota>
        <fp>false</fp>
        <fp_ssl>false</fp_ssl>
        <fp_auth>false</fp_auth>
        <fp_admin_login>miaumiaul</fp_admin_login>
        <fp_admin_password>lalalalallaa
        </fp_admin_password>
        <ssl>false</ssl>
        <shell>/bin/false</shell>
        <php>true</php>
        <ssi>false</ssi>
        <cgi>false</cgi>
        <mod_perl>false</mod_perl>
        <mod_python>false</mod_python>
        <asp>false</asp>
        <asp_dot_net>false</asp_dot_net>
        <coldfusion>false</coldfusion>
        <webstat>awstats</webstat>
        <errdocs>false</errdocs>
        <at_domains>true</at_domains>
      </vrt_hst>
      <htype>vrt_hst</htype>
    </hosting>
    <prefs>
      <www>true</www>
    </prefs>
   </add>
  </domain>
</packet>

I have also been told that this error also occurs on Windows.