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 - dhcp not working with ldap configuration
Summary: dhcp not working with ldap configuration
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: bind99
Version: 25
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Petr Menšík
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1352314 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-03-24 11:32 UTC by DaLiV
Modified: 2021-06-14 08:23 UTC (History)
14 users (show)

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.
Clone Of:
Environment:
Last Closed: 2017-11-15 17:54:09 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 835013 0 unspecified CLOSED querying for IPv6 DNS records when IPv6 is disabled on the host 2022-05-16 11:32:56 UTC

Internal Links: 835013

Description DaLiV 2015-03-24 11:32:27 UTC
Description of problem:
dhcp server not starning

Version-Release number of selected component (if applicable):
4.3.1-12
4.3.2-2

How reproducible:
was working configuration ldap+dhcp on FC20
upgraded to FC21 - not more working
tried to recompile from fc22 and from rawhide - same results


Steps to Reproduce:
1. start openldap server (fc21 repo)
2. start dhcp server - error can't connect

debug process:
strace dhcpd -t 2>&1| grep -i connect

Actual results:
!!! no any connect to 127.0.0.1 initiated !!!

Expected results:
connect(4, {sa_family=AF_INET, sin_port=htons(389), sin_addr=inet_addr("127.0.0.1")}, 16) = 0

dhcpd connected to the ldap server with given credentials


Additional info:
recompiled from FC20 repo latest update dhcp-4.2.7-2 - THAT WORKS

rebuilt rpm from FC22 repo - also not working 
rebuilt акщь rawhide repo (4.3.2-2) - the same (not working)

Comment 1 Fedora End Of Life 2015-11-04 12:58:11 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.

Comment 2 DaLiV 2015-11-04 14:57:05 UTC
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;

Comment 3 Lorenzo Sartoratti 2015-11-16 13:03:07 UTC
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

Comment 4 DaLiV 2016-01-23 22:54:39 UTC
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 ...

Comment 5 DaLiV 2016-01-23 23:08:47 UTC
patch correction.

Comment 6 Valerio Pulese 2016-04-15 13:58:45 UTC
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

Comment 8 DaLiV 2016-07-03 15:22:20 UTC
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 ...

Comment 9 DaLiV 2016-07-03 15:28:09 UTC
P.S. the same patch working for FC24 ... checked

Comment 10 Kevin Fenzi 2016-07-04 16:19:25 UTC
*** Bug 1352314 has been marked as a duplicate of this bug. ***

Comment 11 Matus Honek 2016-07-08 15:25:58 UTC
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

Comment 12 Jiri Popelka 2016-07-12 17:12:27 UTC
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

Comment 13 DaLiV 2016-08-12 21:27:23 UTC
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 ...

Comment 14 Pavel Šimerda (pavlix) 2016-12-07 10:38:12 UTC
(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.

Comment 15 Pavel Šimerda (pavlix) 2016-12-07 10:42:21 UTC
(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.

Comment 16 Pavel Šimerda (pavlix) 2016-12-07 10:46:59 UTC
(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.

Comment 17 Petr Menšík 2016-12-07 11:57:27 UTC
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.

Comment 18 Petr Menšík 2017-02-28 15:52:44 UTC
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

Comment 19 Fedora Update System 2017-11-01 11:37:24 UTC
bind99-9.9.10-3.P3.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-b89e9f62d8

Comment 20 Fedora Update System 2017-11-01 11:38:06 UTC
bind99-9.9.10-3.P3.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-00b24f9251

Comment 21 Fedora Update System 2017-11-01 11:38:37 UTC
bind99-9.9.11-3.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-b0f6ce0915

Comment 22 Fedora Update System 2017-11-01 16:05:06 UTC
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

Comment 23 Fedora Update System 2017-11-01 16:58:16 UTC
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

Comment 24 Fedora Update System 2017-11-01 17:23:44 UTC
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

Comment 25 Fedora Update System 2017-11-07 22:18:07 UTC
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.

Comment 26 Fedora Update System 2017-11-11 03:11:16 UTC
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.

Comment 27 Fedora Update System 2017-11-13 19:31:23 UTC
bind-9.10.5-3.P3.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-b68d7f3b8b

Comment 28 Fedora Update System 2017-11-13 19:31:51 UTC
bind-9.11.1-3.P3.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-d9cf76b94f

Comment 29 Fedora Update System 2017-11-13 19:32:18 UTC
bind-9.11.1-8.P3.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-5acfc0cae5

Comment 30 Fedora Update System 2017-11-14 03:14:15 UTC
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

Comment 31 Fedora Update System 2017-11-14 04:10:10 UTC
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

Comment 32 Fedora Update System 2017-11-14 10:58:54 UTC
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

Comment 33 Fedora Update System 2017-11-15 17:54:09 UTC
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.

Comment 34 Fedora Update System 2017-11-22 02:28:47 UTC
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.

Comment 35 jfgibbins@yahoo.com 2021-05-29 18:06:02 UTC
Problem still exists in Fedora 34.

Comment 36 Pavel Zhukov 2021-06-14 08:23:41 UTC
(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 .


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