Bug 1000184 - nsupdate commands do not explicitly specify zone to modify
Summary: nsupdate commands do not explicitly specify zone to modify
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Node
Version: 1.2.0
Hardware: Unspecified
OS: Linux
unspecified
high
Target Milestone: ---
: ---
Assignee: Miciah Dashiel Butler Masters
QA Contact: libra bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-08-22 21:40 UTC by Dan Trainor
Modified: 2017-03-08 17:35 UTC (History)
6 users (show)

Fixed In Version: rubygem-openshift-origin-dns-nsupdate-1.5.3-1.el6op
Doc Type: Bug Fix
Doc Text:
Previously the nsupdate DNS did not specify the zone to modify, causing DNS updates to fail. The rubygem-openshift-origin-dns-nsupdate plug-in in the current release of OpenShift Enterprise has been updated, and DNS now updates correctly.
Clone Of:
Environment:
Last Closed: 2013-09-25 15:30:27 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:1275 0 normal SHIPPED_LIVE OpenShift Enterprise 1.2.3 bug fix and enhancement update 2013-09-25 19:26:23 UTC

Description Dan Trainor 2013-08-22 21:40:21 UTC
Description of problem:

Then 'rhc app create/delete' command invokes plugins/dns/nsupdate/lib/openshift/nsupdate_plugin.rb:158 through the broker.  The broker crafts an nsupdate that omits an explicit zone declaration often resulting in a failed nsupdate execution.  Example:

      # compose the nsupdate add command
      cmd += %{nsupdate <<EOF
#{keystring}
server #{@server} #{@port}
update delete #{fqdn}
send
quit
EOF
}

This is present on all nsupdate payloads contained in nsupdate_plugin.rb.

Though nsupdate has a way of automatically figuring out the zone to update based on tokenizing the FQDN and trying to find SOA and checking if the nameserver is authoratative for that zone, most modern DNS servers restrict such information leakage to such a degree that this process fails, though some nameservers do allow this kind of information leakage, which may make this bug difficult to isolate.

Explicitly adding a 'zone' directive and giving it a value of #{fqdn} should resolve this.



Version-Release number of selected component (if applicable):
> rubygem-openshift-origin-dns-nsupdate-1.5.2-1.1.el6op.noarch

How reproducible:

Always


Steps to Reproduce:
1. rhc app delete appname
2. ...
3. ...

Actual results:

App deletes from disk, but complete deletion never happens; app meta data lingers in mongo, and dns entry never gets deleted.  


Expected results:

Every part of app, including dns entry, gets deleted


Additional info:

Started DELETE "/broker/rest/domains/mb/applications/testme.json" for 127.0.0.1 at 2013-08-21 22:30:15 -0700

Processing by ApplicationsController#destroy as JSON

  Parameters: {"domain_id"=>"mb", "id"=>"testme"}

error deleting app record testme-mb.qa02.shift.domain.tld

 

["/opt/rh/ruby193/root/usr/share/gems/gems/openshift-origin-dns-nsupdate-1.5.2/lib/openshift/nsupdate_plugin.rb:215:in `deregister_application'", "/opt/rh/ruby193/root/usr/share/gems/gems/openshift-origin-controller-1.10.1/app/models/gear.rb:101:in `deregister_dns'", "/opt/rh/ruby193/root/usr/share/gems/gems/openshift-origin-controller-1.10.1/app/models/pending_app_op_group.rb:221:in `block in execute'", "/opt/rh/ruby193/root/usr/share/gems/gems/openshift-origin-controller-1.10.1/app/models/pending_app_op_group.rb

...........................................................................................................................................................................................

............................................................................................................................................................................................

 

error deleting app record testme-mb.qa02.shift.domain.tld

Completed 500 Internal Server Error in 4225ms

Comment 2 Miciah Dashiel Butler Masters 2013-08-22 21:54:27 UTC
We already have @zone, which gets its value from the BIND_ZONE setting in /etc/openshift/plugins.d/openshift-origin-dns-nsupdate.conf, so this will be an easy fix.

Comment 3 openshift-github-bot 2013-08-23 16:47:11 UTC
Commit pushed to master at https://github.com/openshift/origin-server

https://github.com/openshift/origin-server/commit/691a046d8ca36bd426e720cd25627751c07d84a4
plugins/dns/nsupdate: Specify zone

Make the nsupdate DNS plug-in send the zone, if it is set, to the DNS
server.  The nsupdate plug-in inherits the BIND_ZONE setting from the
bind plug-in on which it was based, but it was not actually sending the
zone even when it had it.

This commit fixes bug 1000184.

Comment 5 Gaoyun Pei 2013-08-26 09:42:14 UTC
Verify this bug on puddle 1.2/2013-08-23

The related patch was merged in, and when deleting apps, no error logs on broker.

Comment 7 Miciah Dashiel Butler Masters 2013-09-16 20:47:29 UTC
To clarify, nsupdate would try to guess the zone when we didn't specify it (which we now do).

Comment 10 errata-xmlrpc 2013-09-25 15:30:27 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1275.html


Note You need to log in before you can comment on or make changes to this bug.