Bug 1261155
| Summary: | nsupdate exits on first GSSAPI error instead of processing other commands | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Dan Lavu <dlavu> | ||||||
| Component: | sssd | Assignee: | Pavel Reichl <preichl> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Dan Lavu <dlavu> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 7.2 | CC: | dlavu, drieden, grajaiya, jgalipea, jhrozek, lslebodn, mkosek, mzidek, nsoman, pbrezina, preichl, pspacek, sgoveas, thozza, tlavigne | ||||||
| Target Milestone: | rc | Keywords: | Reopened, TestBlocker | ||||||
| Target Release: | 7.2 | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | sssd-1.13.0-33.el7 | Doc Type: | Bug Fix | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | |||||||||
| : | 1262430 (view as bug list) | Environment: | |||||||
| Last Closed: | 2015-11-19 11:40:34 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
Forgot to mention, logs show that dyndns is set to false and update_ptr is true, sssd.conf and is not adhering to the defaults values. Configuration is posted below. [sssd] domains = sssdad2012r2.com config_file_version = 2 services = nss, pam [domain/sssdad2012r2.com] ad_domain = sssdad2012r2.com krb5_realm = SSSDAD2012R2.COM realmd_tags = manages-system joined-with-adcli cache_credentials = True id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = True use_fully_qualified_names = True fallback_homedir = /home/%u@%d access_provider = ad [sssd] debug_level = 0xFFFF [domain/sssdad2012r2.com] debug_level = 0xFFFF Upstream ticket: https://fedorahosted.org/sssd/ticket/2783 Dan, do I understand it correctly that it seems that we have changed default value of dyndns_update option for AD from true to false? (In reply to Pavel Reichl from comment #4) > Dan, do I understand it correctly that it seems that we have changed default > value of dyndns_update option for AD from true to false? I checked the source code of sssd-1.13.0-26.el7.x86_64 and the default value for dyndns_update_ptr is TRUE; it was not changed. My understanding is that ptr record is not updated even though it should be. In the attached log you can see: "Option dyndns_update is FALSE" Does setting dyndns_update explicitly to true help? That would confirm that we have wrong defaults. Yes Michal I agree that would help, but I'm not able to replicate the issue so far only Dan and Lukas seem to be able to replicate. Dan, could you upload log files for sssd.conf from comment#2 ? Created attachment 1072059 [details]
sssd_logs_with_dyndns_update_true
Hello. According the last log you do not have configured IPv6 reverse zone in AD. Quick look to AD DNS configuration confirms that - I can see only IPv4 zone in there. (In reply to Petr Spacek from comment #15) > Hello. According the last log you do not have configured IPv6 reverse zone > in AD. Quick look to AD DNS configuration confirms that - I can see only > IPv4 zone in there. That's wrong approach. Many users could have configured just a IPv4 reverse zone. Because they do not care about IPv6 on server side. But clients can have IPv6 addresses which new sssd will try to use in nsupdate. It worked before an update and does not work aftert an upgrade. That's really bad user experience and moreover customers can notice it after a long time. The right approach will be to update just parts which can be updated (IPv4 in this case) Okay then, in that case we have to fix a bug in nsupdate. nsupdate apparently exists on GSSAPI failure when called with option -g and does not process other command blocks (separated by 'send' command). This is different than behavior for other errors where nsupdate just skips the block which failed and continues with the next block of commands. Dan, the bug is in nsupdate. Please be so kind and respect that. Petr, Yes, sorry people wanted me to add the keywords. Reproducer: Store this in a file called "upd": update add nsupdate.test.redhat.com 666 IN A 192.0.2.1 send update add nsupdate.test.redhat.com 666 IN TXT "HELLo!" send And compare output from following commands: $ nsupdate /tmp/upd update failed: REFUSED update failed: REFUSED $ nsupdate -g /tmp/upd tkey query failed: GSSAPI error: Major = Unspecified GSS failure. Minor code may provide more information, Minor = Server DNS/xxx not found in Kerberos database. You can see that first run without GSSAPI tried both command blocks but the second run with GSSAPI failed on first command block and did not continue. * master: eeac17ebbe38f16deaa8599231cccfc97aaac85c Verified, on sssd-client-1.13.0-33.el7.x86_64 , against automated test suite. Upstream ticket: https://fedorahosted.org/sssd/ticket/2783 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. https://rhn.redhat.com/errata/RHSA-2015-2355.html |
Created attachment 1071439 [details] sssd_no_ptr.log Description of problem: This looks like a regression, tests are failing to update the ptr record using the ad provider. Version-Release number of selected component (if applicable): sssd-client-1.13.0-26.el7.x86_64 How reproducible: Always Steps to Reproduce: 1. realm join sssd2012r2.com 2. check AD for the PTR record 3. Actual results: A record exists, PTR does not Expected results: A record and PTR record exits Additional info: