- openldap-bugs - openldap.org

Re: (ITS#5245) auditlog man page and feature request
by hyc＠symas.com 04 Dec '07

04 Dec '07

ghenry(a)suretecsystems.com wrote: > Hi, > > I've just committed my additions and being my first proper man page work, > would someone be so kind as to check I'm using the right syntax. > > It looks and reads ok via man anyway. Looks OK, but your example shouldn't use olcModule. OpenLDAP doesn't support modules by default; anybody who enables module support should already have read the docs for moduleload and modulepath. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

i have problem with ldap
by francis kigmo 04 Dec '07

04 Dec '07

that is the message [root@localhost samba]# ldappasswd -s projet ldap_sasl_interactive_bind_s: No such attribute i need help

2 1

(ITS#5258) memberof-Overlay issue when deleting all values of the "memberof-member-ad" attribute
by rhafer＠suse.de 04 Dec '07

04 Dec '07

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: - URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.197.88) I use the following slapo-memberof config: memberof-group-oc mygroup memberof-member-ad mymember memberof-memberof-ad mymemberof where "mygroup" has "mymember" as an optional ('MAY') attribute. If I know remove all values of "mymember" from a "mygroup" object. With an operation like this: dn: <groupdn> changetype: modify delete: mymember The "mymemberof" Attributes of the associated objects are not updated accordingly.

1 0

Re: (ITS#5245) auditlog man page and feature request
by ghenry＠suretecsystems.com 03 Dec '07

03 Dec '07

Hi, I've just committed my additions and being my first proper man page work, would someone be so kind as to check I'm using the right syntax. It looks and reads ok via man anyway. Thanks, Gavin.

1 0

Re: (ITS#5256) encoding of guide.sdf
by dieter＠dkluenter.de 03 Dec '07

03 Dec '07

"Gavin Henry" <ghenry(a)suretecsystems.com> writes: > <quote who="dieter(a)dkluenter.de"> >> Full_Name: Dieter Kluenter >> Version: REL_ENG_2_4 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (84.142.202.173) >> >> >> Hi, >> the guide *.sdf files are UTF-8 encoded, but the online availeable HTML >> files >> seem to be iso8859-1 encoded, which leeds to display errors, an example is >> part >> 9.2.1. >> ... proxyâs efficiency ... > > Is this something I can fix, or is it part of the doc build for the main > site? Whoever is compiling the *.sdf files and putting the result online, so I think it is part of the doc build process. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

1 0

Re: (ITS#5257) test008 hanging in bdb
by h.b.furuseth＠usit.uio.no 03 Dec '07

03 Dec '07

I should have appended a 'backtrace full', not just backtrace. Here: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth2-071203.bz2 (Stange, my submitted ITS isn't arriving though the confirmation message did. Hopefully ITS will pick this "reply" up anyway...) -- Hallvard

1 0

(ITS#5257) test008 hanging in bdb
by h.b.furuseth＠usit.uio.no 03 Dec '07

03 Dec '07

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-071203.tbz Submission from: (NULL) (129.240.6.233) Submitted by: hallvard test008 is hanging. slapd_daemon_task is waiting in epoll_wait(), main in pthread_join(), all other threads in bdb. Backtrace, output and testrun attached. I can reattach with gdb and check further, if someone says what to check.

1 0

Re: (ITS#5256) encoding of guide.sdf
by ghenry＠suretecsystems.com 02 Dec '07

02 Dec '07

hyc(a)symas.com wrote: > hyc(a)symas.com wrote: >> ghenry(a)suretecsystems.com wrote: >>> <quote who="dieter(a)dkluenter.de"> >>>> Hi, >>>> the guide *.sdf files are UTF-8 encoded, but the online availeable HTML >>>> files >>>> seem to be iso8859-1 encoded, which leeds to display errors, an example is >>>> part >>>> 9.2.1. >>>> ... proxyâs efficiency ... >>> Is this something I can fix, or is it part of the doc build for the main >>> site? >> It's in the SDF source files, therefore something you should fix. I don't know >> what text editor you used on those files, but you should use something else, >> or use one that you can set to just ISO8859-1. >> >> I can't think of a grep regex that will detect 8-bit characters, but you need >> to find them all and get rid of them. > > (Used a binary editor to generate a regexp for [ 0x80 - 0xff ]). There were > only two occurrences in the sdf files; both in backends.sdf. Both are the same > character, an apostrophe used instead of a single quote. > > (binary patch xx) > X=`cat xx` > % grep "[$X]" *.sdf > backends.sdf:same connection. This connection pooling strategy can enhance the > proxys > backends.sdf:maybe stored procedures cant be considered programming, anyway ;). > I use Vim and gedit. The above would have been copy and paste from the FAQ. I'll do a Vim trigger to clean up things like this before a commit/make. Thanks all. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

Re: (ITS#5256) encoding of guide.sdf
by h.b.furuseth＠usit.uio.no 02 Dec '07

02 Dec '07

hyc(a)symas.com writes: > I can't think of a grep regex that will detect 8-bit characters, but > you need to find them all and get rid of them. grep -v '[^ -~<tab>]' where you type ^V tab to the shell to get the <tab>. To search for probably-UTF-8 chars: perl -ne '/[\300-\377][\200-\277]/ && print "$ARGV:$_"' To search for probably-not-UTF-8 8-bit chars: perl -ne '/[\300-\377](?![\200-\277])|(^|[^\200-\377])[\200-\277]/ && print "$ARGV:$_"' -- Regards, Hallvard

1 0

Re: (ITS#5256) encoding of guide.sdf
by kurt＠OpenLDAP.org 02 Dec '07

02 Dec '07

On Dec 2, 2007, at 8:10 PM, ghenry(a)suretecsystems.com wrote: > <quote who="dieter(a)dkluenter.de"> >> Full_Name: Dieter Kluenter >> Version: REL_ENG_2_4 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (84.142.202.173) >> >> >> Hi, >> the guide *.sdf files are UTF-8 encoded, but the online availeable >> HTML >> files >> seem to be iso8859-1 encoded, which leeds to display errors, an >> example is >> part >> 9.2.1. >> ... proxy’s efficiency ... > > Is this something I can fix, or is it part of the doc build for the > main > site? You can avoid using non-ASCII characters... > > >> >> -Dieter >> >> >> > >

1 0

Re: imporvement to slapo-constraint (ITS#4987)
by manu＠netbsd.org 02 Dec '07

02 Dec '07

> Please upload a new patch file which contains both of these notices and then > your diff (updated if > appropriate), and then send an email update to the ITS referencing the new > patch file. Here we are: ftp://ftp.openldap.org/incoming/manu-071202.patch ftp://ftp.openldap.org/incoming/manu-pkg-071202.tgz -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: (ITS#5256) encoding of guide.sdf
by hyc＠symas.com 02 Dec '07

02 Dec '07

hyc(a)symas.com wrote: > ghenry(a)suretecsystems.com wrote: >> <quote who="dieter(a)dkluenter.de"> >>> Hi, >>> the guide *.sdf files are UTF-8 encoded, but the online availeable HTML >>> files >>> seem to be iso8859-1 encoded, which leeds to display errors, an example is >>> part >>> 9.2.1. >>> ... proxyâs efficiency ... >> Is this something I can fix, or is it part of the doc build for the main >> site? > > It's in the SDF source files, therefore something you should fix. I don't know > what text editor you used on those files, but you should use something else, > or use one that you can set to just ISO8859-1. > > I can't think of a grep regex that will detect 8-bit characters, but you need > to find them all and get rid of them. (Used a binary editor to generate a regexp for [ 0x80 - 0xff ]). There were only two occurrences in the sdf files; both in backends.sdf. Both are the same character, an apostrophe used instead of a single quote. (binary patch xx) X=`cat xx` % grep "[$X]" *.sdf backends.sdf:same connection. This connection pooling strategy can enhance the proxys backends.sdf:maybe stored procedures cant be considered programming, anyway ;). -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5256) encoding of guide.sdf
by hyc＠symas.com 02 Dec '07

02 Dec '07

ghenry(a)suretecsystems.com wrote: > <quote who="dieter(a)dkluenter.de"> >> Hi, >> the guide *.sdf files are UTF-8 encoded, but the online availeable HTML >> files >> seem to be iso8859-1 encoded, which leeds to display errors, an example is >> part >> 9.2.1. >> ... proxy’s efficiency ... > > Is this something I can fix, or is it part of the doc build for the main > site? It's in the SDF source files, therefore something you should fix. I don't know what text editor you used on those files, but you should use something else, or use one that you can set to just ISO8859-1. I can't think of a grep regex that will detect 8-bit characters, but you need to find them all and get rid of them. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5256) encoding of guide.sdf
by ghenry＠suretecsystems.com 02 Dec '07

02 Dec '07

<quote who="dieter(a)dkluenter.de"> > Full_Name: Dieter Kluenter > Version: REL_ENG_2_4 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.142.202.173) > > > Hi, > the guide *.sdf files are UTF-8 encoded, but the online availeable HTML > files > seem to be iso8859-1 encoded, which leeds to display errors, an example is > part > 9.2.1. > ... proxy’s efficiency ... Is this something I can fix, or is it part of the doc build for the main site? > > -Dieter > > >

1 0

(ITS#5256) encoding of guide.sdf
by dieter＠dkluenter.de 02 Dec '07

02 Dec '07

Full_Name: Dieter Kluenter Version: REL_ENG_2_4 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.142.202.173) Hi, the guide *.sdf files are UTF-8 encoded, but the online availeable HTML files seem to be iso8859-1 encoded, which leeds to display errors, an example is part 9.2.1. ... proxy’s efficiency ... -Dieter

1 0

Re: (ITS#5254) core dump on Solaris 9 when with threads
by hyc＠symas.com 01 Dec '07

01 Dec '07

mills(a)cc.umanitoba.ca wrote: > Full_Name: Gary Mills > Version: openldap-2.3.38 > OS: Solaris 9 SPARC > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.78.105.29) back-ldbm is deprecated and has been deleted from OpenLDAP 2.4. It is known to have many problems. Berkeley DB 3.1.17 is ancient, and also known to have many bugs. Don't use ldbm, and use a recent version of BerkeleyDB. Nobody is going to spend any time investigating these broken code bases. > > > Here's how openldap-2.3.38 was built: > > PATH=/opt/SUNWspro/bin:/usr/bin:/usr/ccs/bin:/usr/sbin; export PATH > > env CC=cc \ > INSTALL=/usr/ucb/install \ > CPPFLAGS="-I/usr/local/src/db/db-3.1.17/build_unix > -I/usr/local/src/OpenSSL/openssl-0.9.8f/include" \ > LDFLAGS="-R/usr/local/lib -L/usr/local/src/db/db-3.1.17/build_unix > -L/usr/local/src/OpenSSL/openssl-0.9.8f/lib" \ > ./configure \ > --disable-proctitle \ > --enable-crypt \ > --disable-bdb \ > --disable-hdb \ > --enable-ldbm \ > --enable-perl > > In simple tests with an ldbm database, it works correctly. With many clients, > it > dump core hundreds of times a day. The dumps vary, but suggest a memory > management > problem. Here are two: -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5254) core dump on Solaris 9 when with threads
by mills＠cc.umanitoba.ca 01 Dec '07

01 Dec '07

I neglected to mention that compiling Openldap without threads resulted in a perfectly stable server. Threads seem to be handled incorrectly, somehow. -- -Gary Mills- -Unix Support- -U of M Academic Computing and Networking-

1 0

(ITS#5255) Outlook 2003 says: The search could not be completed.
by mills＠cc.umanitoba.ca 01 Dec '07

01 Dec '07

Full_Name: Gary Mills Version: openldap-2.3.38 OS: Solaris 9 SPARC URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.78.105.29) Here's how Openldap was compiled: PATH=/opt/SUNWspro/bin:/usr/bin:/usr/ccs/bin:/usr/sbin; export PATH env CC=cc \ INSTALL=/usr/ucb/install \ CPPFLAGS="-I/usr/local/src/db/db-3.1.17/build_unix -I/usr/local/src/OpenSSL/openssl-0.9.8f/include" \ LDFLAGS="-R/usr/local/lib -L/usr/local/src/db/db-3.1.17/build_unix -L/usr/local/src/OpenSSL/openssl-0.9.8f/lib" \ ./configure \ --disable-proctitle \ --enable-crypt \ --disable-bdb \ --disable-hdb \ --enable-ldbm \ --without-threads \ --enable-perl When using an ldbm database, Microsoft Outlook 2003 clients report this error when they attempt a search: The search could not be completed. MAPI_E_CALL_FAILED The LDAP logs show this message: critical control unavailable in context This happens because Openldap advertizes the pagedResults control, even though the ldbm backend does not support it. When OL 2003 obtains the list of available controls, the LDAP server does not know which back end it will use. When OL 2003 does a query, it goes to the ldbm back end which does not support that control. OL 2003 marks it critical, making the situation impossible. In this situation, I'm using only the ldbm back end, so I removed the pagedResults control in servers/slapd/controls.c to fix the problem. Here's my patch: *** controls.Oc Tue Jan 2 15:43:55 2007 --- controls.c Thu Nov 29 19:53:12 2007 *************** *** 123,132 **** --- 123,134 ---- SLAP_CTRL_GLOBAL|SLAP_CTRL_SEARCH, NULL, parseValuesReturnFilter, LDAP_SLIST_ENTRY_INITIALIZER(next) }, #endif + #ifdef VANILLA { LDAP_CONTROL_PAGEDRESULTS, (int)offsetof(struct slap_control_ids, sc_pagedResults), SLAP_CTRL_SEARCH, NULL, parsePagedResults, LDAP_SLIST_ENTRY_INITIALIZER(next) }, + #endif #ifdef LDAP_DEVEL { LDAP_CONTROL_SORTREQUEST, (int)offsetof(struct slap_control_ids, sc_sortedResults), Adding an access list to the config file did not work.

1 0

(ITS#5254) core dump on Solaris 9 when with threads
by mills＠cc.umanitoba.ca 01 Dec '07

01 Dec '07

Full_Name: Gary Mills Version: openldap-2.3.38 OS: Solaris 9 SPARC URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.78.105.29) Here's how openldap-2.3.38 was built: PATH=/opt/SUNWspro/bin:/usr/bin:/usr/ccs/bin:/usr/sbin; export PATH env CC=cc \ INSTALL=/usr/ucb/install \ CPPFLAGS="-I/usr/local/src/db/db-3.1.17/build_unix -I/usr/local/src/OpenSSL/openssl-0.9.8f/include" \ LDFLAGS="-R/usr/local/lib -L/usr/local/src/db/db-3.1.17/build_unix -L/usr/local/src/OpenSSL/openssl-0.9.8f/lib" \ ./configure \ --disable-proctitle \ --enable-crypt \ --disable-bdb \ --disable-hdb \ --enable-ldbm \ --enable-perl In simple tests with an ldbm database, it works correctly. With many clients, it dump core hundreds of times a day. The dumps vary, but suggest a memory management problem. Here are two: # mdb /usr/local/libexec/slapd /var/core/core.slapd.3610 Loading modules: [ libc.so.1 libthread.so.1 ld.so.1 ] > ::status debugging core file of slapd (32-bit) from electra executable file: /opt/local/libexec/slapd initial argv: slapd threading model: multi-threaded status: process terminated by SIGSEGV (Segmentation Fault) > ::stack is_ad_subtype+0x4c(30000, 3b0120, 33abb0, 33a698, 181ae30, 15949a4) attrs_find+0x2c(181b458, 3b0120, 33a698, 400, 181ae30, 15949a4) 0x8cba4(3d0e08, 17d4e80, 15949c4, 3bd000, 0, fdbff725) test_filter+0x388(3d0e08, 17d4e80, 15949c4, 14baa8, ffffffe0, fdbff8b1) 0x8c808(3d0e08, 17d4e80, 15949c4, 7, ffffffe0, fdbff8f1) test_filter+0x784(3d0e08, 17d4e80, 15949d4, 2, 0, 0) ldbm_back_search+0x12d0(3d0e08, fdbffd50, 0, fdbff2a4, 0, fdbff9fd) fe_op_search+0x594(3d0e08, fdbffd50, 3d0efc, fdbffab0, 0, 0) do_search+0xf54(3d0e08, fdbffd50, fdbffd40, 0, 0, 0) 0x5bbf8(fdbffe14, 3d0e08, 0, 0, 0, 0) 0x153f5c(3aacb8, 0, 0, 0, 0, 0) libthread.so.1`_lwp_start(0, 0, 0, 0, 0, 0) # mdb /usr/local/libexec/slapd /var/core/core.slapd.25318 Loading modules: [ libc.so.1 libthread.so.1 ld.so.1 ] > ::status debugging core file of slapd (32-bit) from electra executable file: /opt/local/libexec/slapd initial argv: slapd threading model: multi-threaded status: process terminated by SIGSEGV (Segmentation Fault) > ::stack str2entry2+0xfec(40c010, 0, 2ee1bc, 7, ffffffe0, fe3ff8f1) id2entry_rw+0x484(3d0820, 1da9, 0, 2, 0, 0) ldbm_back_search+0xa14(3d0e08, fe3ffd50, 0, fe3ff2a4, 81010100, ff00) fe_op_search+0x594(3d0e08, fe3ffd50, 3d0efc, 14388f4, fe3ffab0, 1438e4c) do_search+0xf54(3d0e08, fe3ffd50, fe3ffd40, 0, 0, 0) 0x5bbf8(fe3ffe14, 3d0e08, 0, 0, 0, 0) 0x153f5c(3aacb8, 0, 0, 0, 0, 0) libthread.so.1`_lwp_start(0, 0, 0, 0, 0, 0)

1 0

Re: (ITS#5252) Several SQL Bugs in back-sql
by ando＠sys-net.it 01 Dec '07

01 Dec '07

h.goebel(a)goebel-consult.de wrote: > Full_Name: > Version: 2.3.38 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (79.207.201.247) > > > Debugging marks in sql-statement may lead to wrong results. > > The interface I implemented yields statements like this when using Thunderbird > for searching for 'Klaus'. Thunderbird tries to look up in email, name and given > name. > Ans in my setup, search is restricted to "(objectclass=evolutionPerson)". > > SELECT DISTINCT > ldap_entries.id,res_partner_address.id, > text('evolutionPerson') AS objectClass,ldap_entries.dn AS dn FROM > ldap_entries,res_partner_address,ldap_entry_objclasses > WHERE > res_partner_address.id=ldap_entries.keyval > AND ldap_entries.oc_map_id=1 > AND 9=9 > AND ((2=2 OR ( ldap_entries.id=ldap_entry_objclasses.entry_id > AND ldap_entry_objclasses.oc_name='evolutionPerson')) > AND (( upper(email) LIKE '%KLAUS%') > OR (upper(name) LIKE '%KLAUS%') > OR 7=7 > OR (upper(substring(name from '\\S+..$')) LIKE '%KLAUS%'))) > > 1) "OR 7=7 OR" renders the whole last AND-clause useless: No selection is done > on email, name or givenname. Thus all records are returned. > > 2) "2=2 OR" renders the restriction to a specific objectclass useless. > > In Bug 5198 Pierangelo Masarati say, that a good RDBMs is optimizing this > part away. And exactly this is the problem. This is required to implement attribute and objectClass inheritance, which is required by LDAP. So please don't call them "bugs", they're required hacks. If they're not in place, back-sql would give the wrong response to queries; if they're in place, back-sql would give the right response, possibly inefficiently on braindead RDBMSes. Please choose what you prefer: the wrong answer quickly or the right one maybe slower? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5252) Several SQL Bugs in back-sql
by h.goebel＠goebel-consult.de 30 Nov '07

30 Nov '07

Full_Name: Version: 2.3.38 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (79.207.201.247) Debugging marks in sql-statement may lead to wrong results. The interface I implemented yields statements like this when using Thunderbird for searching for 'Klaus'. Thunderbird tries to look up in email, name and given name. Ans in my setup, search is restricted to "(objectclass=evolutionPerson)". SELECT DISTINCT ldap_entries.id,res_partner_address.id, text('evolutionPerson') AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,res_partner_address,ldap_entry_objclasses WHERE res_partner_address.id=ldap_entries.keyval AND ldap_entries.oc_map_id=1 AND 9=9 AND ((2=2 OR ( ldap_entries.id=ldap_entry_objclasses.entry_id AND ldap_entry_objclasses.oc_name='evolutionPerson')) AND (( upper(email) LIKE '%KLAUS%') OR (upper(name) LIKE '%KLAUS%') OR 7=7 OR (upper(substring(name from '\\S+..$')) LIKE '%KLAUS%'))) 1) "OR 7=7 OR" renders the whole last AND-clause useless: No selection is done on email, name or givenname. Thus all records are returned. 2) "2=2 OR" renders the restriction to a specific objectclass useless. In Bug 5198 Pierangelo Masarati say, that a good RDBMs is optimizing this part away. And exactly this is the problem.

1 0

Re: (ITS#5251) getaddrinfo might return duplicate results
by hyc＠symas.com 29 Nov '07

29 Nov '07

Ralf Haferkamp wrote: > On Donnerstag, 29. November 2007, hyc(a)symas.com wrote: >> rhafer(a)suse.de wrote: >>> Full_Name: Ralf Haferkamp >>> Version: All >>> OS: Linux, glibc 2.7 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (89.166.161.148) >>> >>> >>> Newer versions of glibc (2.7) in my case might return duplicate addrinfo >>> structs in the results under certain circumstances. According to the >>> friendly glibc maintainer ;) this is not a bug: >>> http://sources.redhat.com/bugzilla/show_bug.cgi?id=4980 >>> Unfortunately he doesn't give a reason for this change in behavior. >> Interesting. In that bug report the /etc/hosts file has 127.0.0.1 once and >> ::1 once, so why is 127.0.0.1 being returned twice? That is clearly bogus. > The glibc code explicitly checks the /etc/hosts entry for IN6_IS_ADDR_LOOPBACK > and returns the the in_attr_t for INADDR_LOOPBACK in that case. For reasons > that the glibc author seemingly doesn't want to share with the outer world. We're calling getaddrinfo with hints.ai_family = AF_UNSPEC, so we should be getting both IPv4 and IPv6 addresses back. In this case, converting the V6 address to V4 format is obviously not desired. Also RFC2553 pretty much forbids this: (Page 25) Also note that the IPv6 hex addresses "::" and "::1" MUST NOT be treated as IPv4- compatible addresses, and if the address is "::", HOST_NOT_FOUND MUST be returned and a query of the address not performed. Also for the macro in section 6.7 IN6_IS_ADDR_V4COMPAT MUST return false for "::" and "::1". >>> BTW, I didn't find any reference in the related RFCs that state that the >>> getaddrinfo results need to be unique (nor the opposite). >>> In my current builds I simply patched slapd to check the getaddrinfo() >>> results for uniqueness in the slap_get_listner_addresses() function. Has >>> anybody a better idea how to fix this? >> I'm sure there's nothing that states that the returned info is required to >> be unique. The returned data must accurately reflect the host databases >> being queried though. If you put "127.0.0.1 localhost" twice in /etc/hosts, >> then it's reasonable to get it returned twice. But if it's only in there >> once, then returning it twice is a bug. > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5251) getaddrinfo might return duplicate results
by rhafer＠suse.de 29 Nov '07

29 Nov '07

On Donnerstag, 29. November 2007, hyc(a)symas.com wrote: > rhafer(a)suse.de wrote: > > Full_Name: Ralf Haferkamp > > Version: All > > OS: Linux, glibc 2.7 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (89.166.161.148) > > > > > > Newer versions of glibc (2.7) in my case might return duplicate addrinfo > > structs in the results under certain circumstances. According to the > > friendly glibc maintainer ;) this is not a bug: > > http://sources.redhat.com/bugzilla/show_bug.cgi?id=4980 > > Unfortunately he doesn't give a reason for this change in behavior. > > Interesting. In that bug report the /etc/hosts file has 127.0.0.1 once and > ::1 once, so why is 127.0.0.1 being returned twice? That is clearly bogus. The glibc code explicitly checks the /etc/hosts entry for IN6_IS_ADDR_LOOPBACK and returns the the in_attr_t for INADDR_LOOPBACK in that case. For reasons that the glibc author seemingly doesn't want to share with the outer world. > > BTW, I didn't find any reference in the related RFCs that state that the > > getaddrinfo results need to be unique (nor the opposite). > > In my current builds I simply patched slapd to check the getaddrinfo() > > results for uniqueness in the slap_get_listner_addresses() function. Has > > anybody a better idea how to fix this? > > I'm sure there's nothing that states that the returned info is required to > be unique. The returned data must accurately reflect the host databases > being queried though. If you put "127.0.0.1 localhost" twice in /etc/hosts, > then it's reasonable to get it returned twice. But if it's only in there > once, then returning it twice is a bug. -- Ralf

1 0

Re: (ITS#5251) getaddrinfo might return duplicate results
by hyc＠symas.com 29 Nov '07

29 Nov '07

rhafer(a)suse.de wrote: > Full_Name: Ralf Haferkamp > Version: All > OS: Linux, glibc 2.7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (89.166.161.148) > > > Newer versions of glibc (2.7) in my case might return duplicate addrinfo structs > in the results under certain circumstances. According to the friendly glibc > maintainer ;) this is not a bug: > http://sources.redhat.com/bugzilla/show_bug.cgi?id=4980 > Unfortunately he doesn't give a reason for this change in behavior. Interesting. In that bug report the /etc/hosts file has 127.0.0.1 once and ::1 once, so why is 127.0.0.1 being returned twice? That is clearly bogus. > BTW, I didn't find any reference in the related RFCs that state that the > getaddrinfo results need to be unique (nor the opposite). > In my current builds I simply patched slapd to check the getaddrinfo() results > for uniqueness in the slap_get_listner_addresses() function. Has anybody a > better idea how to fix this? I'm sure there's nothing that states that the returned info is required to be unique. The returned data must accurately reflect the host databases being queried though. If you put "127.0.0.1 localhost" twice in /etc/hosts, then it's reasonable to get it returned twice. But if it's only in there once, then returning it twice is a bug. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5248) non-atomic signal variables
by h.b.furuseth＠usit.uio.no 29 Nov '07

29 Nov '07

Howard Chu writes: > OK, you're right, it's trivial, and I see that the configure script > already #defines sig_atomic_t to int if the system doesn't already > define it. So your suggested changes are harmless, go ahead and make > them. If you're going to that trouble, you should change gotintr to > use an explicitly defined contiguous range of values. OK, later.. that's why I filed an its first (in particular, need to look at WAKE_LISTENER first.) Which makes the rest of this reply irrelevant to the ITS, so skip it if that helps your blood pressure: > Backward compatibility only reinforces my point, since int has always > been atomic in the past. Where do you get that from? A brief search find nothing like that in the draft and standard versions I've lying around. It would also mean that sig_atomic_t would be a pointless type. >> Otherwise the standard would not have needed to define sig_atomic_t. > > Note that sig_atomic_t is an *optional* part of the standard; > implementations are not required to provide it. Irrelevant. Freestanding implementations need not provide it (nor most of the rest of the C library), but <signal.h> requires it. > The standard says it is impossible for arithmetic operations on valid > values to generate trap representations. Think about it - if it were > *possible* for intermediate states to be invalid, (...) A signal breaks the rest of the execution model. A variable need not be in an "intermediate state" according to that model when a signal arrives. Otherwise C could not use *any* inherently non-atomic types, which would rather limit which CPUs could support C. That's why the standard says signal handlers can do so aburdly few things in the first place. > Nobody is stupid enough to design a machine like that, and the > standard guarantees that programmers never have to worry about such a > stupidity ever existing. > (...) > Not on any machine ever built (for which a C translator exists). On the countrary, the existence of such hosts is precicely why the section about signal handlers explicitly contradicts you. And as Doug Gwyn said, even the little part it does guarantee was hard to get agreement for. -- Regards, Hallvard

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs