Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
URI max length hard-coded to 64 characters #21
I'm trying to use nslcd in an AWS environment where my LDAP server is behind an Elastic Load Balancer (ELB), and where I'm referencing that load balancer via its (very verbose) A name. The A name I'm using is 74 characters long, and the "ldaps://" at the beginning makes 82 characters, but nslcd/cfg.c uses a hard-coded limit of 64 characters when parsing its tokens from the file (see the token local variable of cfg_read() at line 1268). As a result, nslcd truncates my ELB-based URI to only the first 64 characters and then tries to treat the remainder of the URI as a second URI (which it then complains doesn't start with "ldaps://").
I see two reasonable options:
The second option is clearly the better one from a functionality standpoint, but the first would require less development time, which might or might not outweigh the smaller degree of flexibility that comes with it.
NOTE: I'm aware that a workaround to this problem would be to use a DNS service to map a shorter name to the ELB. Unfortunately, that workaround is not an option for me in this case due to restrictions imposed on the project by its requirements, so I'm looking for a solution within nslcd itself rather that a DNS-based workaround.
Thanks for pointing this out. I've pushed a fix to set the maximum length to 256 characters. The current code uses fixed length buffers in almost all places in order to have simple memory management (the code it was originally forked from had very difficult to follow memory management).
This change will be in the next release but a date for that release has not yet been set.
In general, depending on your use case, it may be better to configure the LDAP server (or ELB in your case) IP address in nslcd.conf instead of a host name. The main reason for this is that during start-up nslcd can be started before networking is available and negative DNS lookups can be cached by some system components causing lookups to fail for a longer period of time.
nslcd includes a mechanism to clear its own caches and server availability state when the network is (re)connected (usually implemented by sending SIGUSR1 from the network post-up scripts). This allows for some mitigation to the above problem.
Thanks for reporting this.
Thanks for the fix, it's much appreciated.
The problem with the workaround you suggested is that an ELB is associated with potentially more than one IP address at a time (at least one per AZ in which it exists, but there can be more than one per AZ if the load on the ELB requires multiple hosts to support the traffic) and the IPs associated with the ELB can change over time.
The former is the more minor of the problems (at worst, it means that you're not load balancing across the multiple hosts that may be implementing your ELB), but the latter means that as soon as the ELB rolls over IP addresses, your entry is immediately wrong and all connections fail until some process notices and updates that config file. That limitation may be acceptable to some people under some conditions, but for me that's a deal-breaker.