Automatic named.conf Check

Abstract

At this page we will describe the ideas for coding automatic named.conf check when processing job queue for secondary only zones.

Normal Workflow

The normal workflow when the user either creates or modifies a zone is as follows:

  1. User either creates or modifies a zone.
  2. A job is submitted for the slave servers.
  3. iDNS job queue is run at the slave servers.
  4. BIND9 named.d/slave.zones is deployed at the slave servers.
  5. The appropriate rndc reload command is run at the slaves.
  6. The slave servers job records are deleted from tJob

Updated Workflow

For implementing named.conf check before pushing the changes into production mode, we would follow the following workflow:

  1. User either creates or modifies a zone.
  2. A job is submitted for the master server. Note the following: The job executed by the master won't be a real Zone Mod/New job. It will be a CheckSlave job.
  3. A job is submitted for the slave servers.
  4. CheckSlave will build a test /usr/local/idns/named.d/slave.zones.preview file. (At master server.)
  5. CheckSlave Run named-checkconf /usr/local/idns/named.conf.preview (At master server.)
  6. If previous command fails, will create tLog entry for immediate admin action. Also, will create tJob record that won't allow further job queue processing. Probably we can send an email too to a previosly configured email address via tConfiguration. All the three iDNS interfaces should display a message in case of this special halt job existence, notifying the users that their changes won't take place until maintenance window is over at the servers. No jobs will be submitted by the interfaces either while the halt tJob record exists.
  7. Master server job is deleted from tJob.
  8. iDNS job queue is run at the slave servers.
  9. BIND9 named.d/slave.zones is deployed at the slave servers.
  10. The appropriate rndc reload command is run at the slaves.
  11. The slave servers job records are deleted from tJob