Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1205168
Summary: | dhcp not working with ldap configuration | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | DaLiV <daliv.tyw> |
Component: | bind99 | Assignee: | Petr Menšík <pemensik> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 25 | CC: | jfgibbins, jpopelka, jv+fedora, lorenzo.sartoratti, mhonek, mruprich, msehnout, pemensik, p.v.ieperen, pzhukov, rmeggins, thozza, valerio, zdohnal |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | bind99-9.9.10-3.P3.fc26 bind99-9.9.11-3.fc27 | Doc Type: | Bug Fix |
Doc Text: |
Cause:
OLD patch to openldap broke possibility of connection dhcp server to ldap backend
Fix:
--- openldap.spec 2016-01-24 00:19:53.000000000 +0200
+++ openldap.spec 2016-01-24 01:07:27.011604306 +0200
@@ -26,7 +26,6 @@ Patch1: openldap-sql-linking.patch
Patch2: openldap-reentrant-gethostby.patch
Patch3: openldap-smbk5pwd-overlay.patch
Patch4: openldap-man-sasl-nocanon.patch
-Patch5: openldap-ai-addrconfig.patch
# nss patches, unlikely to ever get upstreamed
Patch11: openldap-nss-update-list-of-ciphers.patch
Patch12: openldap-tls-no-reuse-of-tls_session.patch
@@ -141,7 +140,6 @@ AUTOMAKE=%{_bindir}/true autoreconf -fi
%patch2 -p1
%patch3 -p1
%patch4 -p1
-%patch5 -p1
%patch11 -p1
%patch12 -p1
%patch13 -p1
Result:
dhcp from repositories is working as expected.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2017-11-15 17:54:09 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: |
Description
DaLiV
2015-03-24 11:32:27 UTC
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. versions affected dhcp-server-4.3.3-5.fc23.x86_64 also devel version dhcp-server-4.3.3-6 sample dhcpd.conf: --- ldap-server localhost; ldap-port 389; ldap-ssl off; ldap-base-dn "cn=DHCP Config,dc=xx"; ldap-dhcp-server-cn "xxx.xxx.xx"; ldap-username "uid=dhcp,ou=xxx,dc=xx"; ldap-password "xxxxx"; ldap-method static; Exactly the same problem, same Fedora version of DaliV Tried to compile 4.3.2, but the server stop for the same issue. Now we are running a rebuilded version of 4.2.7 of Fedora 20 and it works. Lorenzo NOT WORKING : dhcp-server-4.3.3-8.P1.fc23.x86_64 AND !!! more NOT COMPILING: dhcp-4.2.7-2 (to isc-bind libraries linking broken) BUT found the problem : openldap libraries ... patch that come from fc17 openldap.spec --- openldap.spec 2016-01-24 00:19:53.000000000 +0200 +++ openldap.spec 2016-01-24 00:32:13.685287795 +0200 @@ -26,7 +26,7 @@ Patch1: openldap-sql-linking.patch Patch2: openldap-reentrant-gethostby.patch Patch3: openldap-smbk5pwd-overlay.patch Patch4: openldap-man-sasl-nocanon.patch -#Patch5: openldap-ai-addrconfig.patch +Patch5: openldap-ai-addrconfig.patch # nss patches, unlikely to ever get upstreamed Patch11: openldap-nss-update-list-of-ciphers.patch Patch12: openldap-tls-no-reuse-of-tls_session.patch @@ -141,7 +141,7 @@ AUTOMAKE=%{_bindir}/true autoreconf -fi %patch2 -p1 %patch3 -p1 %patch4 -p1 -#%patch5 -p1 +%patch5 -p1 %patch11 -p1 %patch12 -p1 %patch13 -p1 commenting, recompiling - and dhcp working ... NOTE2: related call to function, that come to the problem in dhcp ldap.c -> that redirects to openldap package: trace of calling ldap ldap_sasl_bind_s ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP 127.0.0.1:389 ldap_connect_to_host: getaddrinfo failed: invalid value for ai_flags ldap_err2string ldap_err2string Error: Cannot login into ldap server 127.0.0.1:389: Can't contact LDAP server if ((ret = ldap_sasl_bind_s (ld, ldap_username, LDAP_SASL_SIMPLE,&creds, NULL, NULL, NULL)) != LDAP_SUCCESS) emotions: Want so anything work-make it by yourself ... 9 months jpopelka from redhat ignores OWN changeset leading to the bugs ... seems dead person ... patch correction. After further investigations we find the following: 1) dhcpd 4.3.3 doesnt even try to connect to ldap server because dynamic linking route ldap connection through libirs_export.so -> getaddrinfo() instead of (g)libc.so -> getaddrinfo() ldd /usr/sbin/dhcpd ... libirs-export.so.91 => /usr/lib64/bind99/libirs-export.so.91 (0x00007f1b4a3ab000) libdns-export.so.169 => /usr/lib64/bind99/libdns-export.so.169 (0x00007f1b4a066000) libisccfg-export.so.90 => /usr/lib64/bind99/libisccfg-export.so.90 (0x00007f1b49e57000) libisc-export.so.106 => /usr/lib64/bind99/libisc-export.so.106 (0x00007f1b49c01000) ... libldap-2.4.so.2 => /lib64/libldap-2.4.so.2 (0x00007f1b494b7000) libsystemd.so.0 => /lib64/libsystemd.so.0 (0x00007f1b4942f000) libc.so.6 => /lib64/libc.so.6 (0x00007f1b4906e000) ... As simple workaround run: LD_PRELOAD=/lib64/libc.so.6 dhcpd or rebuild it changing linking order in dhcp/server/Makefile:410 -lc -ldns -lisccfg -lisc -lirs \ 2) dhcpd 4.2.7 works because it's not linked with libirs-export dhcpd 4.3.3/omapip/isclib.c:44-58 dhcp_dns_client_setservers() uses rs_resconf_load() and irs_resconf_getnameservers() from libirs-export 3) glibc and libirs getaddrinfo() use different MASK to test hints.flags glibc-2.22/sysdeps/posix/getaddrinfo.c 2341: if (hints->ai_flags & ~(AI_PASSIVE|AI_CANONNAME|AI_NUMERICHOST|AI_ADDRCONFIG|AI_V4MAPPED #ifdef HAVE_LIBIDN |AI_IDN|AI_CANONIDN|AI_IDN_ALLOW_UNASSIGNED |AI_IDN_USE_STD3_ASCII_RULES #endif |AI_NUMERICSERV|AI_ALL)) return EAI_BADFLAGS; bind-9.9.8-P4]/lib/irs/getaddrinfo.c (fail with EAI_BADFLAGS) 188: #define ISC_AI_MASK (AI_PASSIVE|AI_CANONNAME|AI_NUMERICHOST) 211: if ((hints->ai_flags & ~(ISC_AI_MASK)) != 0) return (EAI_BADFLAGS); ldap_connect_to_host() openldap/-2.4.40/libraries/libldap/os-ip.c:600 set hints.ai_flags = AI_ADDRCONFIG = 0x20; 4) similar problem: https://gist.github.com/wiedi/3e85738a237944d2ac1d may be ... but also can read RTFM at https://fedoraproject.org/wiki/QA/Networking/NameResolution/ADDRCONFIG?rd=Networking/NameResolution/ADDRCONFIG#Current_implementation_of_AI_ADDRCONFIG_considered_harmful version 24 ... RELESAED STILL BUGGY ... what software you preffer of two ? a) that is claimed as "optimized", but not working OR b) that works, but not optimized think B choice is more safe ... as optimization may be made in future ... but not working in ver ... and not working in next ver ... and still not working - that make software UNUSABLE ... and lead to lost of peoples who preferred product for that good Quality ... this bug must have URGENT Severity !!! as anyone who think to use (for example) dhcp with ldap backend (sure also other softwares can catch similar bug on connection to ldap server) - they try - write simpiest config that must work - see that not works - and change distro to another (where is more prognosable functionality) otherwise they must search bugzilla for all bugs related ... look at patch , recompile , and so on ... and that not all will do, as not all like programming and recompiling ... P.S. the same patch working for FC24 ... checked *** Bug 1352314 has been marked as a duplicate of this bug. *** Originaly, the patch has been included [1] due to real cases of huge load when AI_ADDRCONFIG flag was missing. Reverting the patch would cause regression, thus this is not the way we could go. We would have to workaround the issue somehow. As Valerio nicely states in #c6, dhcp exchanged glibc for bind99 and brought a different (ISC-specific) implementation of getaddrinfo(). This function does not implement the AI_ADDRCONFIG flag processing and rather bails out when it is present (actually it does this for many more flags when compared to glibc). I have read the Fedora wikipage in #c7. As it states, the decision is on developer. The option has been included due to the regression as described above. Current state of openldap in Fedora uses AI_ADDRCONFIG flag only if it is defined. Even bind9 itself seems to workaround it's own implementation of getaddrinfo() in lib/bind9/getaddresses.c because of this flag. From my point of view, either bind9's implementation of getaddrinfo() should be corrected or dhcp should undefine AI_ADDRCONFIG before if it does not want this flag to be used (due to it not being supported by the library it includes). Based on what I described above I am changing the component back to dhcp to further develop this. Also CCing bind99 maintainer msehnout, so that he may pose his opinion on this. I am open to further discussion. [1] bug 835013 CCing Pavel Simerda, RHEL dhcp maintainer and also author of the Fedora wiki page mentioned in comment #7. Pavel, it'd be great if you could take another look at this bug and let me know what do you think would be the best solution ? Thank you ok ... while you decide what to do - AT LEAST change dhcpd.service to something similar to below content. /so will be possible to start it from repository without driving into bug reports/ FC25 - same problem persist ... simple no any of ways providing on networking components - bad Quality sign ... [Unit] Description=DHCPv4 Server Daemon Documentation=man:dhcpd(8) man:dhcpd.conf(5) Wants=network-online.target After=network-online.target After=time-sync.target [Service] Type=notify Environment=LD_PRELOAD=/lib64/libc.so.6 ExecStart=/usr/sbin/dhcpd -f -cf /etc/dhcp/dhcpd.conf -user dhcpd -group dhcpd --no-pid StandardError=null [Install] WantedBy=multi-user.target ----- offtopic some time before RH & FC was good products, but now seems learning from microsoft how to make worst... as in repository LONG time selfallow to have unworkable product ... (In reply to DaLiV from comment #13) > ----- > offtopic > some time before RH & FC was good products, but now seems learning from > microsoft how to make worst... as in repository LONG time selfallow to have > unworkable product ... This is a bugzilla ticket for the latest release of a community distribution called Fedora, not a place to discuss history and preferences. (In reply to DaLiV from comment #13) > [Service] > Type=notify > Environment=LD_PRELOAD=/lib64/libc.so.6 > ExecStart=/usr/sbin/dhcpd -f -cf /etc/dhcp/dhcpd.conf -user dhcpd -group > dhcpd --no-pid > StandardError=null You are suggesting to use LD_PRELOAD, right? That looks like a decent workaround to get it quickly up and running but not a proper solution for distribution IMO. (In reply to Matus Honek from comment #11) > Originaly, the patch has been included [1] due to real cases of huge load > when AI_ADDRCONFIG flag was missing. Reverting the patch would cause > regression, thus this is not the way we could go. We would have to > workaround the issue somehow. > > As Valerio nicely states in #c6, dhcp exchanged glibc for bind99 and brought > a different (ISC-specific) implementation of getaddrinfo(). This function > does not implement the AI_ADDRCONFIG flag processing and rather bails out > when it is present (actually it does this for many more flags when compared > to glibc). > > I have read the Fedora wikipage in #c7. As it states, the decision is on > developer. The option has been included due to the regression as described > above. > > Current state of openldap in Fedora uses AI_ADDRCONFIG flag only if it is > defined. Even bind9 itself seems to workaround it's own implementation of > getaddrinfo() in lib/bind9/getaddresses.c because of this flag. The definition of the flag is checked at compile time, right? In a real program you would have to re-try getaddrinfo without the flag if it returns EAI_BADFLAGS. > From my point of view, either bind9's implementation of getaddrinfo() should > be corrected or dhcp should undefine AI_ADDRCONFIG before if it does not > want this flag to be used (due to it not being supported by the library it > includes). I don't have time to look at the code but I agree that bind9 implementation should accept all flags accepted by glibc on the same system. I'm setting needinfo to msehnout so he can either look at it or find someone to do that. I think it is problem of BIND libraries used. Libirs should not export getaddrinfo without any prefix. Maybe if it provided more functionality, but definitely not if there is less flags supported. I will modify order of libraries of bind99-libs unless it creates any problems. Can please you try again with build against scratch build [1]? Does it fix your problem when not breaking anything else? [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=18108764 bind99-9.9.10-3.P3.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-b89e9f62d8 bind99-9.9.10-3.P3.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-00b24f9251 bind99-9.9.11-3.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-b0f6ce0915 bind99-9.9.11-3.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-b0f6ce0915 bind99-9.9.10-3.P3.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-b89e9f62d8 bind99-9.9.10-3.P3.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-00b24f9251 bind99-9.9.10-3.P3.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report. bind99-9.9.11-3.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report. bind-9.10.5-3.P3.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-b68d7f3b8b bind-9.11.1-3.P3.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-d9cf76b94f bind-9.11.1-8.P3.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-5acfc0cae5 bind-9.10.5-3.P3.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-b68d7f3b8b bind-9.11.1-3.P3.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-d9cf76b94f bind-9.11.1-8.P3.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-5acfc0cae5 bind-9.11.1-8.P3.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report. bind-9.11.1-3.P3.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report. Problem still exists in Fedora 34. (In reply to jfgibbins from comment #35) > Problem still exists in Fedora 34. It's better to report new bug instead... It'd save me a lot of time on investigation. I was noticed this comment during investigation of https://bugzilla.redhat.com/show_bug.cgi?id=1823749 . |