Problem on DNS zone creation after update to 3.1.14p1

Dear,

after upgrading our ISPConfig to the latest stable (3.1.14p1) we are experiencing a problem on DNS creation.
Basically on the master server (we are in a master-slave environment) from the interface the zone exist correctly (screenshot.jpg) but when we run the job on the slave server the script tell us that:

Code:

19.07.2019-18:08 - DEBUG - Replicated from master: REPLACE INTO `dns_soa` (`id`,`sys_userid`,`sys_groupid`,`sys_perm_user`,`sys_perm_group`,`sys_perm_other`,`server_id`,`origin`,`ns`,`mbox`,`serial`,`refresh`,`retry`,`expire`,`minimum`,`ttl`,`active`,`xfer`,`also_notify`,`update_acl`,`dnssec_initialized`,`dnssec_wanted`,`dnssec_last_signed`,`dnssec_info`) VALUES ('4323','915','915','riud','ru','','40','test1749.com.','ns***.*****.com.','tech******.','2019071901','7200','540','604800','3600','3600','Y','******','','','N','N','0',NULL)
19.07.2019-18:08 - DEBUG - Calling function 'soa_update' from plugin 'bind_plugin' raised by event 'dns_soa_update'.
19.07.2019-18:08 - DEBUG - Writing BIND domain file failed: /etc/bind/pri.test1749.com zone test1749.com/IN: has no NS records zone test1749.com/IN: not loaded due to errors.
19.07.2019-18:08 - DEBUG - Reason for Bind restart failure: zone test1749.com/IN: has no NS records

but obviously is not the case because as you can see from the screenshot, the ns are set on the zone.
What happen there? Something on the dns file creation is changed?

ty

 

Ok problem rise when we create the zone from api.
The DNS zone job, is not added on the queue of the job.
Something is change on that field after the last update?

ty

 

yes but in that way the file is not written on the disk, so the domain is not added on bind... :-(

 

until 3.1.13 works like a charm

 

After debugging more, I see that problem happen because the DNS zone that we create from api (we interface a whmcs-plugin with ispconfig host creation) is correctly inserted into ispconfig master interface, but for some reason, does not exist any job of zone creation on the slave server.

One stuff that I see changed is $app->db->datalogInsert method that now require an associative array as $insert_data instead an sql query as before.

How can I debug why no job is put in the queue also if the record are correctly inserted on the main interface?
Log does not help, because basically just does not exist any dns-related job on the job runned.

Any ideas?

ty

 

For the DNS stuff not exist job also on datalog of the master server.
We use the function dns_templatezone_add in order to create the zone.
And for a reason that actually i can't understand, that stopped working from when we have upgraded to 3.1.14p1.

 

basically the job created from dns_templatezone_add seems not added on the master datalog anymore

 

ok going deeper i see that for some reasons that actually i haven't found yet, for the DNS record (both soa and rr) the insert from the api does not save the user on the SESSION array:

Code:

USERNAME:
SESSION: Array
(
    [client_login] => 0
    [client_sys_userid] => 0
    => Array
        (
[.....no admin user here]
            [plugin_cache] => Array
                (
                    [client:client:eek:n_after_insert] => Array
                        (
                            [0] => Array
                                (
                                    [plugin] => clients_template_plugin
                                    [function] => apply_client_templates
                                    [module] =>
                                )

                        )

so when the script meet datalogSave for dns entry, they are not inserted into sys_datalog because $SESSION is set but $username is not set:

Code:

File: /usr/local/ispconfig/interface/lib/classes/db_mysql.inc.php
Method: datalogSave
Row: 711
 if(isset($_SESSION)) {
  $username = $_SESSION['s']['user']['username'];
  // we are here but $username is empty
} else {
  $username = 'admin';
}

as workaround if I set $username='admin' also in the IF statement, the query are put into the sys_datalog and then processed by the slave server.
Obviously this is not a solution that I want in production, but we really need to understand why the dns plugins does not save username on the session.
And I can assure that untill 3.1.13 worked well.

Hope this help to understand what happen here, because i'm sure that every people that use ispconfig connected with control panel (like whmcs does) at this time is not be able to create the host.

ty

 

thank you for the bug report.