Problem on DNS zone creation after update to 3.1.14p1

Discussion in 'ISPConfig 3 Priority Support' started by tritema, Jul 19, 2019.

  1. tritema

    tritema Member HowtoForge Supporter

    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
     

    Attached Files:

    Last edited: Jul 23, 2019
  2. tritema

    tritema Member HowtoForge Supporter

    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
     
  3. till

    till Super Moderator Staff Member ISPConfig Developer

    Not as far as I know. But the above error is probably fine and happened before as well as changes are written in order, so when you add a zone and then the records, then the zone is written first and produces this message when the records get added in the next steps then, it will go away. This can not be avoided as the slave server does not know at this time that more records get added. I guess you might just not had log level set to debug before sp you did not notice this debug message.
     
  4. tritema

    tritema Member HowtoForge Supporter

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

    tritema Member HowtoForge Supporter

    until 3.1.13 works like a charm
     
  6. till

    till Super Moderator Staff Member ISPConfig Developer

    Then you should check whet comes next in debug log, the above message is not an error, its the normal way these things get processed.
     
  7. tritema

    tritema Member HowtoForge Supporter

    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
     
    Last edited: Jul 22, 2019
  8. till

    till Super Moderator Staff Member ISPConfig Developer

    You can debug PHP code either by using a PHP debugger or by adding some debug code which writes the information that you want to get to a log file.

    The $app->db->datalogInsert is an internal function which is not used by any external application and the remote API uses it in the right way, you can see this e.g. in the Migration Toolkit which uses almost all remote API functions and it works fine with 3.1.13 and 3.1.14 without requiring any changes.
     
  9. till

    till Super Moderator Staff Member ISPConfig Developer

    As a side note, you said that no job existed on the slave server, which is ok. The datalog is on the master, not on the slave. You have to look into the sys_datalog table of the master server and not on the slave server. The slave connects directly to the master database server and fetches the job from there.
     
  10. tritema

    tritema Member HowtoForge Supporter

    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.
     
  11. tritema

    tritema Member HowtoForge Supporter

    basically the job created from dns_templatezone_add seems not added on the master datalog anymore
     
    Last edited: Jul 22, 2019
  12. till

    till Super Moderator Staff Member ISPConfig Developer

    Ok, I'll check that. The function dns_templatezone_add is not often used and none of our tools uses it so it might be that there is an issue with that function.
     
  13. tritema

    tritema Member HowtoForge Supporter

    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
     
    Last edited: Jul 23, 2019
  14. till

    till Super Moderator Staff Member ISPConfig Developer

  15. tritema

    tritema Member HowtoForge Supporter

Share This Page