Bug 431003 - dhcp ldap integration broken in dhcp-4.0.0-6.fc9
dhcp ldap integration broken in dhcp-4.0.0-6.fc9
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: dhcp (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: David Cantrell
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-30 19:58 EST by Dann Church
Modified: 2008-02-07 19:17 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-06 19:32:45 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Dann Church 2008-01-30 19:58:49 EST
Description of problem:

I have been unable to use option to store the DHCP server configuration in LDAP
using the dhcp software provided by package dhcp-4.0.0-6.fc9.  This worked
(albeit with a few bugs) using the dhcp-3.0.6-12.fc8 version.  (I am currently
running Fedora 8 but I believe the problem isn't as a result of running the FC9
package on FC8).  Steps to reproduce below.

Version-Release number of selected component (if applicable):

4.0.0.6-fc9

How reproducible:


Steps to Reproduce:
1.  Install rpm
2.  Setup LDAP server per instructions in README.ldap
3.  Install the following /etc/dhcpd.conf

ldap-server "localhost";
ldap-port 389;
ldap-base-dn "dc=test,dc=cassatt,dc=com";
ldap-username "cn=Manager,dc=test,dc=cassatt,dc=com";
ldap-password "whatever";
ldap-method dynamic;

(substitute appropriate parameters for your ldap config)

3. # /usr/sbin/dhcpd -t -cf /etc/dhcpd.conf
  
Actual results:

Not searching LDAP since ldap-server, ldap-port and ldap-base-dn were not
specified in the config file.
Internet Systems Consortium DHCP Server V3.0.6-Fedora
Copyright 2004-2007 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

Expected results:

Internet Systems Consortium DHCP Server V3.0.6-Fedora
Copyright 2004-2007 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

Additional info:

I think one of the issues is related to a mis-match of defined option values for
the ldap-<blah> attributes.  From server/stables.c:

#if defined(LDAP_CONFIGURATION)
        { "ldap-server", "t",                           &server_universe,  57, 1 },
        { "ldap-port", "d",                                    
&server_universe,  58, 1 },
        { "ldap-username", "t",                         &server_universe,  59, 1 },
        { "ldap-password", "t",                         &server_universe,  60, 1 },
        { "ldap-base-dn", "t",                          &server_universe,  61, 1 },
        { "ldap-method", "Nldap-methods.",      &server_universe,  62, 1 },
        { "ldap-debug-file", "t",                       &server_universe,  63, 1 },
        { "ldap-dhcp-server-cn", "t",           &server_universe,  64, 1 },
        { "ldap-referrals", "f",                        &server_universe,  65, 1 },
#if defined(USE_SSL)
        { "ldap-ssl", "Nldap-ssl-usage.",       &server_universe,  66, 1 },
        { "ldap-tls-reqcert", "Nldap-tls-reqcert.",     &server_universe,  67, 1 },
        { "ldap-tls-ca-file", "t",                      &server_universe,  68, 1 },
        { "ldap-tls-ca-dir", "t",                       &server_universe,  69, 1 },
        { "ldap-tls-cert", "t",                         &server_universe,  70, 1 },
        { "ldap-tls-key", "t",                          &server_universe,  71, 1 },
        { "ldap-tls-crlcheck", "Nldap-tls-crlcheck.",   &server_universe,  72, 1 },
        { "ldap-tls-ciphers", "t",                      &server_universe,  73, 1 },
        { "ldap-tls-randfile", "t",                     &server_universe,  74, 1 },

But in includes/dhcpd.h we have:

#if defined(LDAP_CONFIGURATION)
# define SV_LDAP_SERVER                         57
# define SV_LDAP_PORT                           58
# define SV_LDAP_USERNAME                       59
# define SV_LDAP_PASSWORD                       60
# define SV_LDAP_BASE_DN                        61
# define SV_LDAP_METHOD                         62
# define SV_LDAP_DEBUG_FILE                     63
# define SV_LDAP_DHCP_SERVER_CN         64
# define SV_LDAP_REFERRALS                      65
#if defined (USE_SSL)
# define SV_LDAP_SSL                            66
# define SV_LDAP_TLS_REQCERT            67
# define SV_LDAP_TLS_CA_FILE            68
# define SV_LDAP_TLS_CA_DIR                     69
# define SV_LDAP_TLS_CERT                       70
# define SV_LDAP_TLS_KEY                        71
# define SV_LDAP_TLS_CRLCHECK           72
# define SV_LDAP_TLS_CIPHERS            73
# define SV_LDAP_TLS_RANDFILE           74
#endif


These appear to be off by a factor of 10.

I updated these in dhcp-4.0.0-ldap-configuration.patch and regenerated via
rpmbuild -bb dhcp.spec but then attempting to start/check the config of dhcp
resulted in a segfault.  I'm willing to believe though that this is due to the
OS mis-match as the stack trace ended up in a function in a system library. 
Don't have that handy but can reproduce if needed.

One thing also that I notice is that there seems to be a mis-match in how the
dhcpRange is interpreted when in a subnet via when it is in a pool:

In ldap_parse_subnet function in ldap.c:

  if ((tempbv = ldap_get_values_len (ld, item->ldent, "dhcpRange")) != NULL)
    {
      for (i=0; tempbv[i] != NULL; i++)
        {
          x_strncat (cfile->inbuf, "range", LDAP_BUFFER_SIZE);
          x_strncat (cfile->inbuf, " ", LDAP_BUFFER_SIZE);
          x_strncat (cfile->inbuf, tempbv[i]->bv_val, LDAP_BUFFER_SIZE);
          x_strncat (cfile->inbuf, ";\n", LDAP_BUFFER_SIZE);
        }
    }

But in the ldap_parse_pool function in that same file, we have:


  if ((tempbv = ldap_get_values_len (ld, item->ldent, "dhcpRange")) != NULL)
    {
      x_strncat (cfile->inbuf, "range", LDAP_BUFFER_SIZE);
      for (i=0; tempbv[i] != NULL; i++)
        {
          x_strncat (cfile->inbuf, " ", LDAP_BUFFER_SIZE);
          x_strncat (cfile->inbuf, tempbv[i]->bv_val, LDAP_BUFFER_SIZE);
        }
       x_strncat (cfile->inbuf, ";\n", LDAP_BUFFER_SIZE);
    }

I believe these should parse the range statements identically.

Please let me know if there is any additional info you need.
Comment 1 David Cantrell 2008-02-06 19:32:45 EST
I cleaned up includes/dhcpd.h to match server/stables.c.  Those values should
match, that was my mistake.  Regarding the segfault, I now have this:

#0  ___vsprintf_chk (s=<value optimized out>, flags=<value optimized out>, 
    slen=<value optimized out>, format=Could not find the frame base for
"___vsprintf_chk".
) at vsprintf_chk.c:79
79	  s[0] = '\0';
(gdb) bt
#0  ___vsprintf_chk (s=<value optimized out>, flags=<value optimized out>, 
    slen=<value optimized out>, format=Could not find the frame base for
"___vsprintf_chk".
) at vsprintf_chk.c:79
#1  0x0092be8d in ___sprintf_chk (s=Could not find the frame base for
"___sprintf_chk".
) at sprintf_chk.c:33
#2  0x08085bf9 in ldap_start () at /usr/include/bits/stdio2.h:34
#3  0x08088265 in ldap_read_config () at ldap.c:1366
#4  0x08066057 in readconf () at confpars.c:70
#5  0x08051ad1 in main (argc=3, argv=0xbfb252f4) at dhcpd.c:578

Which was caused by a bad sprintf() statement in ldap_start() in server/ldap.c,
fixed by this patch:

diff -up dhcp-4.0.0/server/ldap.c.q dhcp-4.0.0/server/ldap.c
--- dhcp-4.0.0/server/ldap.c.q	2008-02-06 13:36:01.000000000 -1000
+++ dhcp-4.0.0/server/ldap.c	2008-02-06 14:30:38.000000000 -1000
@@ -799,7 +799,7 @@ ldap_start (void)
       return;
     }
 
-  sprintf("ldap://%s:%d", ldap_server, ldap_port);
+  sprintf(uri, "ldap://%s:%d", ldap_server, ldap_port);
   ldap_initialize(&ld, uri);
 
   if (ld == NULL)

Seems to be working now after the patch.  This will be fixed in
dhcp-4.0.0-9.fc9.  Thanks for the report and the excellent debugging information
which helped me reproduce it here locally.
Comment 2 Dann Church 2008-02-07 18:04:54 EST
Thanks for the prompt attention on this.  Any chance the dhcpRange issue was
sorted as well?  The "subnet" version should be correct as the pool version
interprets multiple range statements as a single statement (with bad results).

I can open a separate bug on this if you'd like.
Comment 3 David Cantrell 2008-02-07 19:17:23 EST
Let's do a separate bug for that issue.  Thanks.

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