- openldap-bugs - openldap.org

Re: (ITS#8958) 2nd cn=config update blocks slapd while adding subordinate index
by h.b.furuseth＠usit.uio.no 19 Jan '19

19 Jan '19

Testing again 'subordinate' looks irrelevant. I wonder what I did in my original and bigger testcase to make it seem relevant. On 1/19/19 6:30 PM, Howard Chu wrote: > This is not really surprising. I don't know these interactions well enough to be unsurprised. It's not hard to guess that modify(olcDbIndex) might be heavy and had better be tested. A simple test says it returns quickly. I don't know why the ongoing indexing keeps cn=config locked after the operation succeeded, instead of keeping something in the indexed DB locked. I wouldn't expect others to guess that either. > Are you suggesting the indexing task should stop if another config mod comes in? I'm suggesting to fail the 2nd operation if that's what it takes. Or only hang if the user passes some LDAP control. I'm suggesting that config pauses should be brief. Server hangs are bad. Even a crash can be better when other load-balanced servers can take over. Not that I'm suggesting that "fix":-)

1 0

Re: (ITS#8958) 2nd cn=config update blocks slapd while adding subordinate index
by hyc＠symas.com 19 Jan '19

19 Jan '19

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard Breien Furuseth > Version: 2.4.47, master > OS: Linux x86_64 > URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-190119.tgz > Submission from: (NULL) (193.90.50.50) > > > Use cn=config to add an index to a subordinate database, > then make a 2nd cn=config change. 2nd change waits while > (I assume) indexing, and blocks other slapd operations. > So ldapwhoami during 2nd change takes 5 seconds. > > To reproduce: ./bug.sh > To debug, attach gdb in another terminal during 2nd MOD. > gdb -q ../servers/slapd/slapd `cat slapd.pid` > > trace.txt shows the 2nd config_back_modify() waiting > in slap_pause_server(). This is not really surprising. Are you suggesting the indexing task should stop if another config mod comes in? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8958) 2nd cn=config update blocks slapd while adding subordinate index
by h.b.furuseth＠usit.uio.no 19 Jan '19

19 Jan '19

Full_Name: Hallvard Breien Furuseth Version: 2.4.47, master OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-190119.tgz Submission from: (NULL) (193.90.50.50) Use cn=config to add an index to a subordinate database, then make a 2nd cn=config change. 2nd change waits while (I assume) indexing, and blocks other slapd operations. So ldapwhoami during 2nd change takes 5 seconds. To reproduce: ./bug.sh To debug, attach gdb in another terminal during 2nd MOD. gdb -q ../servers/slapd/slapd `cat slapd.pid` trace.txt shows the 2nd config_back_modify() waiting in slap_pause_server().

1 0

(ITS#8957) Handling of TLS in async mode
by vsmith＠interlinknetworks.com 14 Jan '19

14 Jan '19

Full_Name: Vernon Smith Version: 2.4.47 OS: Ubuntu 12.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2601:40d:4300:679a:8d9a:95ec:46f9:30fd) I looked at the release notes and there have been a few issues with Async mode with TSL in 2.4. I had been using 2.3.20 with my own patches to make Async mode with TLS work with my aplication. I need to upgrade to 2.4 but I have tried many version of it and none have worked. The basic issue is that the TLS code is never called so LDAPS connections fail. My symptoms are very similar to the bug report that caused a fix in 2.4.26 but 2.4.26 is not working for me. I see the same issue with 2.4.47. If I don't use LDAP_OPT_CONNECT_ASYNC then the connection works and I get this trace: ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP test.interlinknetworks.com:636 ldap_new_socket: 10 ldap_prepare_socket: 10 ldap_connect_to_host: Trying 192.168.3.26:636 ldap_pvt_connect: fd: 10 tm: 3 async: 0 ldap_ndelay_on: 10 attempting to connect: connect errno: 115 ldap_int_poll: fd: 10 tm: 3 ldap_is_sock_ready: 10 ldap_ndelay_off: 10 ldap_pvt_connect: 0 TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:unknown state TLS certificate verification: depth: 1, err: 0, subject: /C=AA/ST=Michigan/L=Ann Arbor/O=Interlink Networks, Inc./OU=Quality Assurance/CN=autoTest CA/emailAddress=QAtest(a)interlinknetworks.com, issuer: /C=AA/ST=Michigan/L=Ann Arbor/O=Interlink Networks, Inc./OU=Quality Assurance/CN=autoTest CA/emailAddress=QAtest(a)interlinknetworks.com TLS certificate verification: depth: 0, err: 0, subject: /C=US/ST=Michigan/L=Ann Arbor/O=Interlink Networks Services, LLC./OU=Quality Assurance/CN=test.interlinknetworks.com/emailAddress=QAtest@interlinknetwor…, issuer: /C=AA/ST=Michigan/L=Ann Arbor/O=Interlink Networks, Inc./OU=Quality Assurance/CN=autoTest CA/emailAddress=QAtest(a)interlinknetworks.com TLS trace: SSL_connect:unknown state TLS trace: SSL_connect:unknown state TLS trace: SSL_connect:unknown state TLS trace: SSL_connect:unknown state TLS trace: SSL_connect:unknown state TLS trace: SSL_connect:unknown state TLS trace: SSL_connect:unknown state TLS trace: SSL_connect:unknown state ldap_open_defconn: successful ldap_send_server_request But with LDAP_OPT_CONNECT_ASYNC enabled I never see the TLS code called and the connection fails. The trace is: ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP test.interlinknetworks.com:636 ldap_new_socket: 10 ldap_prepare_socket: 10 ldap_connect_to_host: Trying 192.168.3.26:636 ldap_pvt_connect: fd: 10 tm: 3 async: -1 ldap_ndelay_on: 10 attempting to connect: connect errno: 115 ldap_open_defconn: successful ldap_send_server_request ... ldap_result ld 0x9bd6f70 msgid 1 wait4msg ld 0x9bd6f70 msgid 1 (timeout 0 usec) wait4msg continue ld 0x9bd6f70 msgid 1 all 1 ** ld 0x9bd6f70 Connections: * host: test.interlinknetworks.com port: 636 (default) refcnt: 2 status: Connected last used: Mon Jan 14 15:33:57 2019 ** ld 0x9bd6f70 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x9bd6f70 request count 1 (abandoned 0) ** ld 0x9bd6f70 Response Queue: Empty ld 0x9bd6f70 response count 0 ldap_chkResponseList ld 0x9bd6f70 msgid 1 all 1 ldap_chkResponseList returns ld 0x9bd6f70 NULL ldap_int_select read1msg: ld 0x9bd6f70 msgid 1 all 1 ber_get_next failed. ldap_err2string ... Can't contact LDAP server Thanks, Vern

1 0

(ITS#8956) Update slapd-sql(5) man page to remove BDB reference
by quanah＠openldap.org 12 Jan '19

12 Jan '19

Full_Name: Quanah Gibson-Mount Version: 2.4.47 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) The slapd-sql(5) man page has the following blurb: It is NOT designed as a general-purpose backend that uses RDBMS instead of BerkeleyDB (as the standard BDB backend does), though it can be used as such with several limitations. Given the deprecation of BDB based backends, this should be updated to reference LMDB and back-mdb.

1 0

Re: (ITS#8951) Replication stalls
by quanah＠symas.com 10 Jan '19

10 Jan '19

--On Wednesday, January 02, 2019 7:44 PM +0000 whm(a)dropbox.com wrote: > Bill Hi Bill, I believe this issue was resolved by setting a keepalive in the syncrepl stanza. Can you confirm? Thanks! Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8954) LMDB double-commit double-free heap crash
by hyc＠symas.com 06 Jan '19

06 Jan '19

robin.rowe(a)venturehollywood.com wrote: > Full_Name: Robin Rowe > Version: --branch OPENLDAP_REL_ENG_2_4 > OS: Windows 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (23.242.20.216) > > > LMDB becomes unstable if we double-commit the same transaction. Caused by > freeing me_txn0 again after 2nd commit had previously free it. This is not an LMDB bug, this is a stupid user error. http://www.lmdb.tech/doc/group__mdb.html#ga846fbd6f46105617ac9f4d76476f6597 Closing this. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8954) LMDB double-commit double-free heap crash
by robin.rowe＠venturehollywood.com 06 Jan '19

06 Jan '19

Full_Name: Robin Rowe Version: --branch OPENLDAP_REL_ENG_2_4 OS: Windows 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (23.242.20.216) LMDB becomes unstable if we double-commit the same transaction. Caused by freeing me_txn0 again after 2nd commit had previously free it. To experience this bug, add a second commit to sample-mdb.c about line 43, deliberately cause a double-commit: sprintf(sval, "%03x %d foo bar", 32, 3141592); rc = mdb_put(txn, dbi, &key, &data, 0); rc = mdb_txn_commit(txn); #ifndef HIDE_DOUBLE_FREE_BUG rc = mdb_txn_commit(txn);// 2nd commit destabilizes LMDB env #endif if (rc) { What's different after a double-commit... mdb.c:3470 rc = MDB_BAD_TXN; // Detected double-commit mdb.c:3471 goto fail; // Jumps away into unsafe code path... ...Much later, at end of program: mdb_env_close(env); // Heap crash here, double-free! return 0; } Double-commit eventually crashes us with double-free in mdb_env_close here: mdb.c:5076 free(env->me_dirty_list); mdb.c:5076 free(env->me_txn0); // 2nd commit already freed // txn pointed to by me_txn0! Granted it is a user mistake to commit the same transaction twice. However, because the crash won't happen until much later, when env is freed, any LMDB users who make this mistake will be quite perplexed. Will anyone fix this? Robin

1 0

Re: (ITS#8953) Windows lmdb warnings and a memory error
by hyc＠symas.com 04 Jan '19

04 Jan '19

robin.rowe(a)cinepaint.org wrote: > Full_Name: Robin Rowe > Version: --branch OPENLDAP_REL_ENG_2_4 > OS: Windows 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (23.242.20.216) > > > Thanks for lmdb! > > Building lmdb in Visual Studio 2017 produces warnings a memory error due to > returning address of local variable from function mdb_strerror. Many warnings > for integer truncation without using a cast. None of these seem severe. Will > anyone clean this up? None of these are meaningful, so no. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8953) Windows lmdb warnings and a memory error
by robin.rowe＠cinepaint.org 04 Jan '19

04 Jan '19

Full_Name: Robin Rowe Version: --branch OPENLDAP_REL_ENG_2_4 OS: Windows 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (23.242.20.216) Thanks for lmdb! Building lmdb in Visual Studio 2017 produces warnings a memory error due to returning address of local variable from function mdb_strerror. Many warnings for integer truncation without using a cast. None of these seem severe. Will anyone clean this up? I used these switches in my cmake file to cut down the warnings: add_definitions(-D_CRT_SECURE_NO_DEPRECATE) add_definitions(-D_CRT_NONSTDC_NO_DEPRECATE) # Necessary for building mdb_dkey for mtest6: add_definitions(-DMDB_DEBUG) Visual Studio 2017 Build Output: 2>mdb.c liblmdb\mdb.c(1640): warning C4267: '=': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(1831): warning C4267: 'initializing': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(2014): warning C4267: '+=': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(2053): warning C4267: '=': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(2028): warning C4267: 'initializing': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(2258): warning C4267: '=': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(2278): warning C4267: '=': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(2164): warning C4267: 'initializing': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(2439): warning C4267: '=': conversion from 'size_t' to 'unsigned short', possible loss of data liblmdb\mdb.c(2893): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data liblmdb\mdb.c(2894): warning C4267: 'function': conversion from 'size_t' to 'int', possible loss of data liblmdb\mdb.c(3360): warning C4267: '=': conversion from 'size_t' to 'DWORD', possible loss of data liblmdb\mdb.c(3361): warning C4267: 'function': conversion from 'size_t' to 'DWORD', possible loss of data liblmdb\mdb.c(3300): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data liblmdb\mdb.c(3510): warning C4267: '=': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(3514): warning C4267: '=': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(3550): warning C4267: '=': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(3553): warning C4267: '=': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(3568): warning C4267: '=': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(3875): warning C4244: '+=': conversion from '__int64' to 'off_t', possible loss of data liblmdb\mdb.c(3988): warning C4267: '=': conversion from 'size_t' to 'LONG', possible loss of data liblmdb\mdb.c(4334): warning C4996: 'GetVersion': was declared deprecated 2>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\sysinfoapi.h(184): note: see declaration of 'GetVersion' liblmdb\mdb.c(4719): warning C4244: 'function': conversion from 'mdb_hash_t' to 'unsigned long', possible loss of data liblmdb\mdb.c(5226): warning C4267: '=': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(5229): warning C4267: '=': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(5234): warning C4244: 'return': conversion from 'ssize_t' to 'int', possible loss of data liblmdb\mdb.c(5260): warning C4244: 'return': conversion from 'ssize_t' to 'int', possible loss of data liblmdb\mdb.c(5708): warning C4267: '=': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(5716): warning C4267: '=': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(5728): warning C4267: '=': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(5729): warning C4267: '=': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(6559): warning C4267: '=': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(6674): warning C4267: '=': conversion from 'size_t' to 'uint16_t', possible loss of data liblmdb\mdb.c(6756): warning C4267: '=': conversion from 'size_t' to 'uint16_t', possible loss of data liblmdb\mdb.c(6762): warning C4267: '=': conversion from 'size_t' to 'indx_t', possible loss of data liblmdb\mdb.c(6818): warning C4267: '=': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(6898): warning C4146: unary minus operator applied to unsigned type, result still unsigned liblmdb\mdb.c(6906): warning C4267: '=': conversion from 'size_t' to 'unsigned short', possible loss of data liblmdb\mdb.c(7027): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data liblmdb\mdb.c(6854): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data liblmdb\mdb.c(7299): warning C4267: '-=': conversion from 'size_t' to 'indx_t', possible loss of data liblmdb\mdb.c(7339): warning C4267: '=': conversion from 'size_t' to 'indx_t', possible loss of data liblmdb\mdb.c(7347): warning C4267: '=': conversion from 'size_t' to 'unsigned short', possible loss of data liblmdb\mdb.c(7350): warning C4267: '=': conversion from 'size_t' to 'unsigned short', possible loss of data liblmdb\mdb.c(7352): warning C4267: '=': conversion from 'size_t' to 'unsigned short', possible loss of data liblmdb\mdb.c(7312): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data liblmdb\mdb.c(7413): warning C4267: '+=': conversion from 'size_t' to 'indx_t', possible loss of data liblmdb\mdb.c(7475): warning C4333: '>>': right shift by too large amount, data loss liblmdb\mdb.c(7811): warning C4267: '=': conversion from 'size_t' to 'unsigned short', possible loss of data liblmdb\mdb.c(7934): warning C4267: 'function': conversion from 'size_t' to 'int', possible loss of data liblmdb\mdb.c(8697): warning C4267: '-=': conversion from 'size_t' to 'indx_t', possible loss of data liblmdb\mdb.c(8705): warning C4267: '-=': conversion from 'size_t' to 'indx_t', possible loss of data liblmdb\mdb.c(8713): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data liblmdb\mdb.c(8715): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data liblmdb\mdb.c(9297): warning C4267: '=': conversion from 'size_t' to 'unsigned short', possible loss of data liblmdb\mdb.c(9484): warning C4267: '=': conversion from 'size_t' to 'DWORD', possible loss of data liblmdb\mdb.c(9520): warning C4267: '=': conversion from 'size_t' to 'DWORD', possible loss of data 2>midl.c liblmdb\midl.c(44): warning C4267: 'initializing': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\midl.c(146): warning C4267: '+=': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\midl.c(176): warning C4267: 'function': conversion from 'size_t' to 'int', possible loss of data 2>Generating Code... 2>c:\code\github\libunistd\lmdb\liblmdb\mdb.c(1515): warning C4172: returning address of local variable or temporary: buf 2>Db.cpp 2>liblmdb.vcxproj -> C:\Code\github\libunistd\build\lmdb\Debug\liblmdb.lib 2>Done building project "liblmdb.vcxproj". ========== Rebuild All: 2 succeeded, 0 failed, 0 skipped =========

1 0

Re: (ITS#8952) olcIdleTimeout < 4 causes high CPU usage on some systems
by hyc＠symas.com 02 Jan '19

02 Jan '19

openldap-bugs(a)PaulSD.com wrote: > Both epoll and the solaris /dev/poll infrastructure support only millisecond > resolution, not microsecond resolution, so I assume the microseconds were simply > dropped for simplicity. > > Could (tvp)->tv_sec*1000 be changed to (tvp)->tv_sec*1000+(tvp)->tv_usec/1000 to > correct this issue? > https://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=servers/s… > https://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=servers/s… Thanks for the report. Changed in git master, please test. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8952) olcIdleTimeout < 4 causes high CPU usage on some systems
by openldap-bugs＠PaulSD.com 02 Jan '19

02 Jan '19

Full_Name: Paul Donohue Version: 2.4.44-20.el7 OS: RHEL7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (172.58.184.58) After upgrading from OpenLDAP 2.2 to OpenLDAP 2.4, we noticed much higher than expected CPU usage on our LDAP servers, particularly on our master server (which only accepts connections from our slave servers, and therefore should generally be idle). After doing lots of profiling and debugging, we managed to determine that the problem was caused by our olcIdleTimeout setting, which we had set to 3. slapd_daemon_task divides olcIdleTimeout by 4 and sets the seconds and microseconds values of a timeval structure appropriately: https://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=servers/s… https://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=servers/s… In OpenLDAP 2.2, this timeval structure is then passed directly as the timeout parameter to a select() call: https://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=servers/s… However, in OpenLDAP 2.4, this timeval structure is passed to SLAP_EVENT_WAIT. There are four different implementations of SLAP_EVENT_WAIT. The kqueue and winsock implementations handle this timeout properly, but the epoll and solaris implementations drop the microseconds value and use only the seconds value. (We are using the epoll implementation.) Therefore, if olcIdleTimeout is less than 4 and there are any open connections to the server, then epoll_wait is always called with a zero timeout, which causes the slapd_daemon_task while loop to spin continuously and consume CPU. It looks like this issue has been present since epoll support was first added to OpenLDAP: https://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commit;h=b7d4e1a… Both epoll and the solaris /dev/poll infrastructure support only millisecond resolution, not microsecond resolution, so I assume the microseconds were simply dropped for simplicity. Could (tvp)->tv_sec*1000 be changed to (tvp)->tv_sec*1000+(tvp)->tv_usec/1000 to correct this issue? https://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=servers/s… https://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=servers/s…

1 0

(ITS#8951) Replication stalls
by whm＠dropbox.com 02 Jan '19

02 Jan '19

Full_Name: Bill MacAllister Version: 2.4.46 OS: Ubuntu 16.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (50.247.112.108) We have been seeing replication stall on many of our replicas. Once replication stalls is never recovers on its own and the slapd process on the replica needs to be restarted. As soon as slapd is restarted on a replica it catches up to the master. By examining the ContextCSNs it appears that all stalls at exactly the same point. Our configuration is a single master with 20 replicas. Most replicas are deployed in pairs at remote site. Generally replicas are deployed to address latency issues at remote sites. The LDAP infrastructure provides DHCP and authorization services. The replicas and the master are all running Ubuntu 16.04 with a custom built slapd using 2.4.46 source. Our build of slapd starts with Ryan Tandys ppa source and has the following changes. - Build with OpenSSL - ITS patches 8054, 8752, and 8727 We have been seeing this problem intermittently for months now, and the problem just recently gotten worse, going from once every other month to once or twice a week. One anomaly that we have seen with the last two stalls is that only 18 of the 20 replicas stalled. The replicas that did not stall are in the same network as the master. I think that is a red herring since the stalling hosts are widely dispersed and have a variety of network paths. We use GSSAPI authentication and the directory holds no passwords. We have logs and thread dumps of the most recent stall. If you would like to see them let me know where to send them. Bill

1 0

(ITS#8950) segfault with TXN+accesslog
by ondra＠openldap.org 02 Jan '19

02 Jan '19

Full_Name: Ondrej Kuznik Version: master OS: Linux URL: Submission from: (NULL) (82.10.24.68) Trying to reproduce a potential lockup between TXN support and accesslog, I have instead come across a segfault in TXN handling. With the following config: database mdb suffix cn=log directory ./log database mdb suffix cn=test directory ./db overlay accesslog logdb cn=log logops writes Make sure cn=test entry exists and issue ldapmodify -E '!txn=commit' with dn: cn=test changetype: modify slapd segfaults with the following picked up by valgrind: ==10599== Invalid read of size 8 ==10599== at 0x509ACD: txn_end_extop (txn.c:243) ==10599== by 0x49A7D9: fe_extended (extended.c:222) ==10599== by 0x49A505: do_extended (extended.c:177) ==10599== by 0x44F36D: connection_operation (connection.c:1169) ==10599== by 0x44D52F: connection_read_thread (connection.c:1326) ==10599== by 0x485869E: ldap_int_thread_pool_wrapper (tpool.c:1048) ==10599== by 0x6886FA2: start_thread (pthread_create.c:486) ==10599== by 0x699988E: clone (clone.S:95) ==10599== Address 0xa552330 is on thread 3's stack ==10599== 4112 bytes below stack pointer ==10599== ==10599== Invalid read of size 8 ==10599== at 0x509AD0: txn_end_extop (txn.c:243) ==10599== by 0x49A7D9: fe_extended (extended.c:222) ==10599== by 0x49A505: do_extended (extended.c:177) ==10599== by 0x44F36D: connection_operation (connection.c:1169) ==10599== by 0x44D52F: connection_read_thread (connection.c:1326) ==10599== by 0x485869E: ldap_int_thread_pool_wrapper (tpool.c:1048) ==10599== by 0x6886FA2: start_thread (pthread_create.c:486) ==10599== by 0x699988E: clone (clone.S:95) ==10599== Address 0x20333d706f203108 is not stack'd, malloc'd or (recently) free'd ==10599== ==10599== ==10599== Process terminating with default action of signal 11 (SIGSEGV) ==10599== General Protection Fault ==10599== at 0x509AD0: txn_end_extop (txn.c:243) ==10599== by 0x49A7D9: fe_extended (extended.c:222) ==10599== by 0x49A505: do_extended (extended.c:177) ==10599== by 0x44F36D: connection_operation (connection.c:1169) ==10599== by 0x44D52F: connection_read_thread (connection.c:1326) ==10599== by 0x485869E: ldap_int_thread_pool_wrapper (tpool.c:1048) ==10599== by 0x6886FA2: start_thread (pthread_create.c:486) ==10599== by 0x699988E: clone (clone.S:95) I doesn't seem to happen without accesslog configured.

1 0

(ITS#8949) slapd crashes when adding first olcPlugin value
by ryan＠openldap.org 02 Jan '19

02 Jan '19

Full_Name: Ryan Tandy Version: 2.4, master OS: Debian URL: Submission from: (NULL) (70.66.128.207) Submitted by: ryan Initial configuration, no existing value for olcPlugin: ldapmodify -H ldap://:9000 -x -D cn=config -w secret << eof dn: olcDatabase={1}mdb,cn=config add: olcPlugin olcPlugin: preoperation ./libtestpreop-plugin.so testpreop_init eof Thread 4 "slapd" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff6020700 (LWP 17326)] 0x00005555556ee351 in slapi_int_free_object_extensions (objecttype=1, object=0x7fffec000cb0) at slapi_ext.c:298 298 if ( eblock->extensions != NULL ) { (gdb) bt #0 0x00005555556ee351 in slapi_int_free_object_extensions (objecttype=1, object=0x7fffec000cb0) at slapi_ext.c:298 #1 0x00005555555c14f3 in slap_op_free (op=0x7fffec000cb0, ctx=0x7ffff601fb90) at operation.c:113 #2 0x00005555555a62c6 in connection_operation (ctx=0x7ffff601fb90, arg_v=0x7fffec000cb0) at connection.c:1246 #3 0x00005555555a6577 in connection_read_thread (ctx=0x7ffff601fb90, argv=0xb) at connection.c:1326 #4 0x00005555556a2dff in ldap_int_thread_pool_wrapper (xpool=0x55555580cc40) at tpool.c:1048 #5 0x00007ffff7f7ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486 #6 0x00007ffff7eb089f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 It looks like we went through slap_op_alloc() with slapi_plugins_used = 0, so slapi_int_create_object_extensions() was never called, but in slap_op_free() we have added a plugin and have called slapi_int_free_object_extensions(). Can probably be fixed just by short-circuiting when eblock == NULL?

1 0

(ITS#9535) -ldb incorrectly added to SLAPD_LIBS with modular build
by quanah＠openldap.org 31 Dec '18

31 Dec '18

Full_Name: Quanah Gibson-Mount Version: 2.4.47 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) configure.in has the following section handling the BDB library: if test $ol_enable_bdb/$ol_enable_hdb != no/no; then OL_BERKELEY_DB if test $ol_cv_berkeley_db = no ; then AC_MSG_ERROR(BDB/HDB: BerkeleyDB not available) fi AC_DEFINE(HAVE_BERKELEY_DB,1, [define this if Berkeley DB is available]) dnl $ol_cv_lib_db should be yes or -ldb dnl (it could be no, but that would be an error if test $ol_cv_lib_db != yes ; then BDB_LIBS="$BDB_LIBS $ol_cv_lib_db" fi SLAPD_LIBS="$SLAPD_LIBS \$(BDB_LIBS)" ol_link_bdb=yes fi This has the effect of always attempting to link the slapd binary with the BDB library. This block should instead be: if test $ol_enable_bdb/$ol_enable_hdb != no/no; then OL_BERKELEY_DB if test $ol_cv_berkeley_db = no ; then AC_MSG_ERROR(BDB/HDB: BerkeleyDB not available) fi AC_DEFINE(HAVE_BERKELEY_DB,1, [define this if Berkeley DB is available]) dnl $ol_cv_lib_db should be yes or -ldb dnl (it could be no, but that would be an error if test $ol_cv_lib_db != yes ; then BDB_LIBS="$BDB_LIBS $ol_cv_lib_db" fi dnl link BDB library to slapd with static backend if test $ol_enable_bdb/$ol_enable_hdb != mod/mod; then SLAPD_LIBS="$SLAPD_LIBS \$(BDB_LIBS)" fi ol_link_bdb=yes fi

1 0

(ITS#9534) openldap bug
by 349020753＠qq.com 25 Dec '18

25 Dec '18

Full_Name: perfy Version: 2.4.44 OS: centos 7 64bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (1.202.220.123) (1)I have enabled the dynlist moudle as follows: [root@test01 cn=schema]# pwd /etc/openldap/slapd.d/cn=config/cn=schema [root@test01 cn=schema]# ll total 84 -rw-r-----. 1 ldap ldap 1283 Dec 18 17:50 cn={0}corba.ldif -rw-r-----. 1 ldap ldap 3625 Dec 18 17:50 cn={10}ppolicy.ldif -rw-r-----. 1 ldap ldap 1523 Dec 18 17:50 cn={11}collective.ldif -rw------- 1 ldap ldap 2727 Dec 18 17:37 cn={12}sudo.ldif -rw------- 1 ldap ldap 1013 Dec 19 01:16 cn={13}ldapns.ldif -rw-r-----. 1 ldap ldap 15546 Dec 18 17:50 cn={1}core.ldif -rw-r-----. 1 ldap ldap 11363 Dec 18 17:50 cn={2}cosine.ldif -rw-r-----. 1 ldap ldap 4489 Dec 18 17:50 cn={3}duaconf.ldif -rw-r-----. 1 ldap ldap 1693 Dec 18 17:50 cn={4}dyngroup.ldif -rw-r-----. 1 ldap ldap 2857 Dec 18 17:50 cn={5}inetorgperson.ldif -rw-r-----. 1 ldap ldap 2589 Dec 18 17:50 cn={6}java.ldif -rw-r-----. 1 ldap ldap 1519 Dec 18 17:50 cn={7}misc.ldif -rw-r-----. 1 ldap ldap 6495 Dec 18 17:50 cn={8}nis.ldif -rw-r-----. 1 ldap ldap 1323 Dec 18 17:50 cn={9}openldap.ldif [root@test01 cn=config]# cat cn=module{0}.ldif # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 e9c5e751 dn: cn=module{0} objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib64/openldap olcModuleLoad: {0}dynlist.la olcModuleLoad: {1}ppolicy.la structuralObjectClass: olcModuleList entryUUID: 78bc6ce2-972e-1038-9a09-0b17f1a1373f creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth createTimestamp: 20181218163402Z entryCSN: 20181220075834.004947Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20181220075834Z [root@test01 cn=config]# cat olcDatabase\=\{2\}bdb/olcOverlay\=\{0\}dynlist.ldif dn: olcOverlay={0}dynlist objectClass: olcOverlayConfig objectClass: olcDynamicList olcOverlay: {0}dynlist olcDlAttrSet: {0}inetOrgPerson labeledURI olcDlAttrSet: {1}groupOfURLs memberURL member structuralObjectClass: olcDynamicList entryUUID: 0ff96984-972f-1038-9a0b-0b17f1a1373f creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth createTimestamp: 20181218163815Z entryCSN: 20181221095210.059382Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth [root@test01 cn=schema]# ldapsearch -LLL -x -D "cn=Manager,dc=kb,dc=com" -b "dc=kb,dc=com" -w1234 "ou=dbhost" dn: ou=dbhost,ou=servers,dc=kb,dc=com objectClass: organizationalUnit objectClass: hostObject ou: dbhost host: test04 [root@test01 cn=config]# ldapsearch -LLL -x -D "cn=Manager,dc=kb,dc=com" -b "dc=kb,dc=com" -w1234 "uid=zhangsan" dn: uid=zhangsan,ou=People,dc=kb,dc=com objectClass: posixAccount objectClass: inetOrgPerson objectClass: shadowAccount objectClass: hostObject cn: zhangsan sn: zhangsan uid: zhangsan uidNumber: 10007 homeDirectory: /home/zhangsan loginShell: /bin/bash gecos: DBA Manager shadowLastChange: 17889 gidNumber: 10011 labeledURI: ldap:///ou=dbhost,ou=servers,dc=kb,dc=com?host userPassword:: e01ENX00UXJjT1VtNldhdStWdUJYOGcrSVBnPT0= host: test04 (2)When I search the hostname "test04" by the filter "(&(uid=zhangsan)(host=test04))", no any result is return. The corrent result should return the DN "dn: uid=zhangsan,ou=People,dc=kb,dc=com". But the result is empty. Is it a bug ? [root@test01 cn=config]# ldapsearch -LLL -x -D "cn=Manager,dc=kb,dc=com" -b "dc=kb,dc=com" -w1234 "(&(uid=zhangsan)(host=test04))"

1 0

(ITS#9533) openldap bug
by 349020753＠qq.com 25 Dec '18

25 Dec '18

Full_Name: perfy Version: 2.4.44 OS: centos 7 64bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (1.202.220.123) (1)I have enabled the dynlist moudle as follows: [root@test01 cn=schema]# pwd /etc/openldap/slapd.d/cn=config/cn=schema [root@test01 cn=schema]# ll total 84 -rw-r-----. 1 ldap ldap 1283 Dec 18 17:50 cn={0}corba.ldif -rw-r-----. 1 ldap ldap 3625 Dec 18 17:50 cn={10}ppolicy.ldif -rw-r-----. 1 ldap ldap 1523 Dec 18 17:50 cn={11}collective.ldif -rw------- 1 ldap ldap 2727 Dec 18 17:37 cn={12}sudo.ldif -rw------- 1 ldap ldap 1013 Dec 19 01:16 cn={13}ldapns.ldif -rw-r-----. 1 ldap ldap 15546 Dec 18 17:50 cn={1}core.ldif -rw-r-----. 1 ldap ldap 11363 Dec 18 17:50 cn={2}cosine.ldif -rw-r-----. 1 ldap ldap 4489 Dec 18 17:50 cn={3}duaconf.ldif -rw-r-----. 1 ldap ldap 1693 Dec 18 17:50 cn={4}dyngroup.ldif -rw-r-----. 1 ldap ldap 2857 Dec 18 17:50 cn={5}inetorgperson.ldif -rw-r-----. 1 ldap ldap 2589 Dec 18 17:50 cn={6}java.ldif -rw-r-----. 1 ldap ldap 1519 Dec 18 17:50 cn={7}misc.ldif -rw-r-----. 1 ldap ldap 6495 Dec 18 17:50 cn={8}nis.ldif -rw-r-----. 1 ldap ldap 1323 Dec 18 17:50 cn={9}openldap.ldif [root@test01 cn=config]# cat cn=module{0}.ldif # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 e9c5e751 dn: cn=module{0} objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib64/openldap olcModuleLoad: {0}dynlist.la olcModuleLoad: {1}ppolicy.la structuralObjectClass: olcModuleList entryUUID: 78bc6ce2-972e-1038-9a09-0b17f1a1373f creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth createTimestamp: 20181218163402Z entryCSN: 20181220075834.004947Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20181220075834Z [root@test01 cn=config]# cat olcDatabase\=\{2\}bdb/olcOverlay\=\{0\}dynlist.ldif dn: olcOverlay={0}dynlist objectClass: olcOverlayConfig objectClass: olcDynamicList olcOverlay: {0}dynlist olcDlAttrSet: {0}inetOrgPerson labeledURI olcDlAttrSet: {1}groupOfURLs memberURL member structuralObjectClass: olcDynamicList entryUUID: 0ff96984-972f-1038-9a0b-0b17f1a1373f creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth createTimestamp: 20181218163815Z entryCSN: 20181221095210.059382Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth [root@test01 cn=schema]# ldapsearch -LLL -x -D "cn=Manager,dc=kb,dc=com" -b "dc=kb,dc=com" -w1234 "ou=dbhost" dn: ou=dbhost,ou=servers,dc=kb,dc=com objectClass: organizationalUnit objectClass: hostObject ou: dbhost host: test04 [root@test01 cn=config]# ldapsearch -LLL -x -D "cn=Manager,dc=kb,dc=com" -b "dc=kb,dc=com" -w1234 "uid=zhangsan" dn: uid=zhangsan,ou=People,dc=kb,dc=com objectClass: posixAccount objectClass: inetOrgPerson objectClass: shadowAccount objectClass: hostObject cn: zhangsan sn: zhangsan uid: zhangsan uidNumber: 10007 homeDirectory: /home/zhangsan loginShell: /bin/bash gecos: DBA Manager shadowLastChange: 17889 gidNumber: 10011 labeledURI: ldap:///ou=dbhost,ou=servers,dc=kb,dc=com?host userPassword:: e01ENX00UXJjT1VtNldhdStWdUJYOGcrSVBnPT0= host: test04 (2)When I search the hostname "test04" by the filter "(&(uid=zhangsan)(host=test04))", no any result is return. The corrent result should return the DN "dn: uid=zhangsan,ou=People,dc=kb,dc=com". But no result is empty. Is it a bug ? [root@test01 cn=config]# ldapsearch -LLL -x -D "cn=Manager,dc=kb,dc=com" -b "dc=kb,dc=com" -w1234 "(&(uid=zhangsan)(host=test04))"

1 0

(ITS#9532) Ambiguos documentation for default LogLevel
by dpa-openldap＠aegee.org 24 Dec '18

24 Dec '18

Full_Name: &#1044;&#1080;&#1083;&#1103;&#1085; &#1055;&#1072;&#1083;&#1072;&#1091;&#1079;&#1086;&#1074; Version: 2.4.47 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (46.5.16.188) If LogLevel is not specified, does it default to 0 or to 256 (stats)? The documentation says default is stats in: man/man5/slapd.conf.5:691:The loglevel defaults to \fBstats\fP. guide/admin/tuning.sdf:121:The default of {{loglevel stats}} (256) is really the best bet. There's a corollary to guide/admin/tuning.sdf-141-The default syslog level is stats (256) which logs the basic parameters of each And the default for loglevel 0 is defined at: man/man5/slapd-config.5:630:In fact, if no olcLogLevel (or a 0 level) is defined, no logging occurs, man/man5/slapd-config.5-631-so at least the man/man5/slapd-config.5-632-.B none man/man5/slapd-config.5-633-level is required to have high priority messages logged. Here mixed feelings: guide/admin/slapdconfig.sdf-193-\Default: guide/admin/slapdconfig.sdf-194- guide/admin/slapdconfig.sdf:195:E: loglevel stats guide/admin/slapdconfig.sdf-196- guide/admin/slapdconfig.sdf:197:Basic stats logging is configured by default. However, if no loglevel is guide/admin/slapdconfig.sdf-198-defined, no logging occurs (equivalent to a 0 level). guide/admin/slapdconfig.sdf-199- guide/admin/slapdconf2.sdf-237- guide/admin/slapdconf2.sdf-238-\Default: guide/admin/slapdconf2.sdf-239- guide/admin/slapdconf2.sdf:240:E: olcLogLevel stats guide/admin/slapdconf2.sdf-241- guide/admin/slapdconf2.sdf:242:Basic stats logging is configured by default. However, if no olcLogLevel is guide/admin/slapdconf2.sdf-243-defined, no logging occurs (equivalent to a 0 level). guide/admin/slapdconf2.sdf-244- I suggest describing all default values at a single place.

1 0

Re: (ITS#8890) Bug fix patches unbreaking the build on x32 systems
by hyc＠symas.com 19 Dec '18

19 Dec '18

Thorsten Glaser wrote: > Howard Chu dixit: > >> Thanks to the wonderful geniuses at Microsoft, not all the world >> uses LP64. IL32 is a thing. And this code works on those platforms. > > These changes do not break LLP64 (this is the correct name > for the 64-bit Windows model). Yes, they do, but you're clearly too stupid to understand that, despite having had it explained to you multiple times. Your patch tries to store the value of a long long into a buffer only large enough for a long. That is fucking stupid. Bye. -- -- Howard Chu CTO, 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#8890) Bug fix patches unbreaking the build on x32 systems
by tg＠mirbsd.de 19 Dec '18

19 Dec '18

Howard Chu dixit: >Thanks to the wonderful geniuses at Microsoft, not all the world >uses LP64. IL32 is a thing. And this code works on those platforms. These changes do not break LLP64 (this is the correct name for the 64-bit Windows model). >If you're going to submit a patch, submit a correct one. It's that The buffer size is a separate issue from this. Feel free to fix it, now that you found it. The patch I submit fixed your software on systems where time_t doesn=E2=80=99t fit into a long, all of them, and that *will* include 64-bit Windows at least in 2038, except some architectures need these fixes right now. They don=E2=80=99t break anything else before 2038, and afterwards, nothing new is broken worsely either. >simple. If you refuse to do that, then go away. You know what, I=E2=80=99ll just do that and leave you to fix your software on your own, clearly you are oh so utterly competent in doing that. //mirabilos --=20 =E2=80=9CIt is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.=E2=80=9D =09-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2

1 0

Re: (ITS#8890) Bug fix patches unbreaking the build on x32 systems
by hyc＠symas.com 19 Dec '18

19 Dec '18

Thorsten Glaser wrote: > Howard Chu dixit: >=20 >> This patch of yours *introduces a bug*. If you wanted to actually *fix= * >> something you should have made sure the malloc'd buffer - which only h= appens >> 2 lines above the lines you change - was large enough to store a long = long. >=20 > That=E2=80=99s not a new bug, then. > That=E2=80=99s a completely separate Y2038 issue of *yours* that > will happen on all platforms, and has nothing to do with > long vs. long long, since a long on an LP64 platform *is* > already as wide as a long long. Thanks to the wonderful geniuses at Microsoft, not all the world uses LP64. IL32 is a thing. And this code works on those platforms. Far more machines than have ever or ever will run X32. If you want patches for your obscure system adopted, you have to make sure not to break anything else. > In addition to that, use of snprintf will prevent this > from being worse than a mere truncation. If you're going to submit a patch, submit a correct one. It's that simple= . If you refuse to do that, then go away. --=20 -- Howard Chu CTO, 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#8890) Bug fix patches unbreaking the build on x32 systems
by tg＠mirbsd.de 19 Dec '18

19 Dec '18

Howard Chu dixit: >This patch of yours *introduces a bug*. If you wanted to actually *fix* >something you should have made sure the malloc'd buffer - which only happe= ns >2 lines above the lines you change - was large enough to store a long long= =2E That=E2=80=99s not a new bug, then. That=E2=80=99s a completely separate Y2038 issue of *yours* that will happen on all platforms, and has nothing to do with long vs. long long, since a long on an LP64 platform *is* already as wide as a long long. In addition to that, use of snprintf will prevent this from being worse than a mere truncation. bye, //mirabilos --=20 Solange man keine schmutzigen Tricks macht, und ich meine *wirklich* schmutzige Tricks, wie bei einer doppelt verketteten Liste beide Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend.=09=09-- Andreas Bogk =C3=BCber boehm-gc in d.a.s.r

1 0

Re: (ITS#8890) Bug fix patches unbreaking the build on x32 systems
by hyc＠symas.com 19 Dec '18

19 Dec '18

Thorsten Glaser wrote: > I know my way *very* well around the time_t issue because > I=E2=80=99ve been having them on MirBSD/i386 years before x32 even > existed, and am experienced in how to fix them. >From here it only looks like you're experienced in how to break things. This patch of yours *introduces a bug*. If you wanted to actually *fix* something you should have made sure the malloc'd buffer - which only happ= ens 2 lines above the lines you change - was large enough to store a long lon= g. That's just plain sloppy. It's as careless as submitting a patch to fix a no-op, and just wasting my time. +--- a/contrib/slapd-modules/smbk5pwd/smbk5pwd.c ++++ b/contrib/slapd-modules/smbk5pwd/smbk5pwd.c +@@ -605,7 +605,7 @@ static int smbk5pwd_exop_passwd( + keys[0].bv_val =3D ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) ); + keys[0].bv_len =3D snprintf(keys[0].bv_val, + LDAP_PVT_INTTYPE_CHARS(long), +- "%ld", slap_get_time()); ++ "%lld", (long long)slap_get_time()); + BER_BVZERO( &keys[1] ); + + ml->sml_desc =3D ad_sambaPwdLastSet; +@@ -627,7 +627,7 @@ static int smbk5pwd_exop_passwd( + keys[0].bv_val =3D ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) ); + keys[0].bv_len =3D snprintf(keys[0].bv_val, + LDAP_PVT_INTTYPE_CHARS(long), +- "%ld", slap_get_time() + pi->smb_must_change); ++ "%lld", (long long)slap_get_time() + (long long)pi->s= mb_must_change); + BER_BVZERO( &keys[1] ); + + ml->sml_desc =3D ad_sambaPwdMustChange; +@@ -650,7 +650,7 @@ static int smbk5pwd_exop_passwd( + keys[0].bv_val =3D ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) ); + keys[0].bv_len =3D snprintf(keys[0].bv_val, + LDAP_PVT_INTTYPE_CHARS(long), +- "%ld", slap_get_time() + pi->smb_can_change); ++ "%lld", (long long)slap_get_time() + (long long)pi->s= mb_can_change); + BER_BVZERO( &keys[1] ); + + ml->sml_desc =3D ad_sambaPwdCanChange; --=20 -- Howard Chu CTO, 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#8890) Bug fix patches unbreaking the build on x32 systems
by tg＠debian.org 19 Dec '18

19 Dec '18

Howard Chu dixit: >You might have correctly identified a Y2038 issue. You certainly have not >written a correct fix for it. Please drop this condescending attitude. I may or may not have discovered a Y2038 issue, but I do know for sure I=E2=80=99ve correctly fixed a problem on all architectures in which a time_t does not fit into a long. Consider this: #ifdef TEST1 typedef long foo_t; #else typedef long long foo_t; #endif foo_t bla =3D 1L; printf("%ld, %ld\n", bla, 2L); This is _supposed_ to display =E2=80=9C1, 2=E2=80=9D but will display =E2= =80=9C1, 0=E2=80=9D on little endian platforms (big endian being worse off). I know my way *very* well around the time_t issue because I=E2=80=99ve been having them on MirBSD/i386 years before x32 even existed, and am experienced in how to fix them. bye, //mirabilos --=20 16:47=E2=8E=9C=C2=ABmika:#grml=C2=BB .oO(mira ist einfach gut....) 23:= 22=E2=8E=9C=C2=ABmikap:#grml=C2=BB mirabilos: und dein bootloader ist geil :) 23:29=E2=8E=9C=C2=ABmikap:#gr= ml=C2=BB und ich finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann gleich mal auf usb-stick installieren=09-- Michael Prokop =C3=BCber MirOS b= sd4grml

1 0

Re: (ITS#8890) Bug fix patches unbreaking the build on x32 systems
by hyc＠symas.com 19 Dec '18

19 Dec '18

Thorsten Glaser wrote: > Howard Chu dixit: >=20 >> The remaining format patches for debug statements will have no impact >> on the correctness of execution or output. This and all of the >> following patches are being rejected. >=20 > There are multiple systems on which sizeof(time_t) > sizeof(long), > with more expected as 2038 dawns. >=20 > Are you saying you want to prohibit users on these platforms from > debugging OpenLDAP? >=20 >>> --- a/contrib/slapd-modules/smbk5pwd/smbk5pwd.c >>> +++ b/contrib/slapd-modules/smbk5pwd/smbk5pwd.c >>> @@ -605,7 +605,7 @@ static int smbk5pwd_exop_passwd( >>> keys[0].bv_val =3D ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) ); >>> keys[0].bv_len =3D snprintf(keys[0].bv_val, >>> LDAP_PVT_INTTYPE_CHARS(long), >>> - "%ld", slap_get_time()); >>> + "%lld", (long long)slap_get_time()); >>> BER_BVZERO( &keys[1] ); >=20 > This doesn=E2=80=99t look like debugging output to me. I already addressed that patch explicitly. "The rest" covers all the othe= rs. You might have correctly identified a Y2038 issue. You certainly have not written a correct fix for it. --=20 -- Howard Chu CTO, 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#8890) Bug fix patches unbreaking the build on x32 systems
by tg＠debian.org 19 Dec '18

19 Dec '18

Howard Chu dixit: >The remaining format patches for debug statements will have no impact >on the correctness of execution or output. This and all of the >following patches are being rejected. There are multiple systems on which sizeof(time_t) > sizeof(long), with more expected as 2038 dawns. Are you saying you want to prohibit users on these platforms from debugging OpenLDAP? >> --- a/contrib/slapd-modules/smbk5pwd/smbk5pwd.c >> +++ b/contrib/slapd-modules/smbk5pwd/smbk5pwd.c >> @@ -605,7 +605,7 @@ static int smbk5pwd_exop_passwd( >> =09=09keys[0].bv_val =3D ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) ); >> =09=09keys[0].bv_len =3D snprintf(keys[0].bv_val, >> =09=09=09LDAP_PVT_INTTYPE_CHARS(long), >> -=09=09=09"%ld", slap_get_time()); >> +=09=09=09"%lld", (long long)slap_get_time()); >> =09=09BER_BVZERO( &keys[1] ); This doesn=E2=80=99t look like debugging output to me. bye, //mirabilos --=20 Yes, I hate users and I want them to suffer. =09-- Marco d'Itri on gmane.linux.debian.devel.general

1 0

Re: (ITS#8890) Bug fix patches unbreaking the build on x32 systems
by hyc＠symas.com 19 Dec '18

19 Dec '18

tg(a)debian.org wrote: > Full_Name: mirabilos > Version: 2.4.46 > OS: Debian > URL:=20 > Submission from: (NULL) (2a01:4f8:150:946c::42:3) >=20 >=20 > I=C3=A2=E2=82=AC=E2=84=A2ve just managed to unbreak the build of openld= ap on x32 > (basically amd64ilp32: a 64-bit x86 architecture using 32-bit > =C3=A2=E2=82=AC=C5=93long=C3=A2=E2=82=AC=C2=9D and pointers) by fixing = a couple of simple GCC warnings. >=20 > Original bugreport: https://bugs.debian.org/905237 >=20 > Please find the attached patches (pretty machinal, so not > copyright-relevant) and include them in your next release. > Thanks! >=20 > --- a/clients/tools/common.c > +++ b/clients/tools/common.c > @@ -2326,7 +2326,7 @@ void tool_print_ctrls( > /* known controls */ > for ( j =3D 0; tool_ctrl_response[j].oid !=3D NULL; j++ ) { > if ( strcmp( tool_ctrl_response[j].oid, ctrls[i]->ldctl_oid ) =3D=3D= 0 ) { > - if ( !tool_ctrl_response[j].mask & tool_type ) { > + if ( !(tool_ctrl_response[j].mask & tool_type) ) { > /* this control should not appear > * with this tool; warning? */ > } This is patching an if statement with an empty body - it is a pure no-op = that the compiler will optimize away. There's no point in changing this other = than to shut up stupid static analyzer tools. But since you're not the first p= erson to run a stupid static analyzer tool and point this out, I've merged this= "fix." The following 3 patches are valid and have been merged. > --- a/servers/slapd/backend.c > +++ b/servers/slapd/backend.c > @@ -1500,7 +1500,7 @@ fe_acl_group( > * or if filter parsing fails. > * In the latter case, > * we should give up. */ > - if ( ludp->lud_filter !=3D NULL && ludp->lud_filter !=3D '\0') { > + if ( ludp->lud_filter !=3D NULL && ludp->lud_filter[0] !=3D '\0')= { > filter =3D str2filter_x( op, ludp->lud_filter ); > if ( filter =3D=3D NULL ) { > /* give up... */ > --- a/servers/slapd/overlays/constraint.c > +++ b/servers/slapd/overlays/constraint.c > @@ -446,7 +446,7 @@ constraint_cf_gen( ConfigArgs *c ) > } > =20 > if ( ap.restrict_lud->lud_attrs !=3D NULL ) { > - if ( ap.restrict_lud->lud_attrs[0] !=3D '\0' ) { > + if ( ap.restrict_lud->lud_attrs[0] !=3D NULL ) { > snprintf( c->cr_msg, sizeof( c->cr_msg ), > "%s %s: attrs not allowed in restrict URI %s\n", > c->argv[0], c->argv[1], arg); > --- a/servers/slapd/syntax.c > +++ b/servers/slapd/syntax.c > @@ -219,8 +219,8 @@ syn_add( > } > =20 > assert( (*lsei)->lsei_values !=3D NULL ); > - if ( (*lsei)->lsei_values[0] =3D=3D '\0' > - || (*lsei)->lsei_values[1] !=3D '\0' ) > + if ( (*lsei)->lsei_values[0] =3D=3D NULL > + || (*lsei)->lsei_values[1] !=3D NULL ) > { > Debug( LDAP_DEBUG_ANY, "syn_add(%s): exactly one substitute syntax= must be > present\n", > ssyn->ssyn_syn.syn_oid, 0, 0 ); This chunk no longer exists in the repo, so it's been omitted. > --- a/tests/progs/slapd-addel.c > +++ b/tests/progs/slapd-addel.c > @@ -173,7 +173,7 @@ main( int argc, char **argv ) > =20 > } > =20 > - if (( attrs =3D=3D NULL ) || ( *attrs =3D=3D '\0' )) { > + if (( attrs =3D=3D NULL ) || ( *attrs =3D=3D NULL )) { > =20 > fprintf( stderr, "%s: invalid attrs in file \"%s\".\n", > argv[0], filename ); This patch is trying to cast to a long long and print the result into a b= uffer that is explicitly sized for a long. That's clearly a bug. The remaining = format patches for debug statements will have no impact on the correctness of execution or output. This and all of the following patches are being reje= cted. > --- a/contrib/slapd-modules/smbk5pwd/smbk5pwd.c > +++ b/contrib/slapd-modules/smbk5pwd/smbk5pwd.c > @@ -605,7 +605,7 @@ static int smbk5pwd_exop_passwd( > keys[0].bv_val =3D ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) ); > keys[0].bv_len =3D snprintf(keys[0].bv_val, > LDAP_PVT_INTTYPE_CHARS(long), > - "%ld", slap_get_time()); > + "%lld", (long long)slap_get_time()); > BER_BVZERO( &keys[1] ); > =09 > ml->sml_desc =3D ad_sambaPwdLastSet; > @@ -627,7 +627,7 @@ static int smbk5pwd_exop_passwd( > keys[0].bv_val =3D ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) ); > keys[0].bv_len =3D snprintf(keys[0].bv_val, > LDAP_PVT_INTTYPE_CHARS(long), > - "%ld", slap_get_time() + pi->smb_must_change); > + "%lld", (long long)slap_get_time() + (long long)pi->smb_must_chan= ge); > BER_BVZERO( &keys[1] ); > =20 > ml->sml_desc =3D ad_sambaPwdMustChange; > @@ -650,7 +650,7 @@ static int smbk5pwd_exop_passwd( > keys[0].bv_val =3D ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) ); > keys[0].bv_len =3D snprintf(keys[0].bv_val, > LDAP_PVT_INTTYPE_CHARS(long), > - "%ld", slap_get_time() + pi->smb_can_change); > + "%lld", (long long)slap_get_time() + (long long)pi->smb_can_chang= e); > BER_BVZERO( &keys[1] ); > =20 > ml->sml_desc =3D ad_sambaPwdCanChange; > --- a/libraries/libldap/os-ip.c > +++ b/libraries/libldap/os-ip.c > @@ -282,8 +282,8 @@ ldap_int_poll( > int rc; > =09 > =20 > - osip_debug(ld, "ldap_int_poll: fd: %d tm: %ld\n", > - s, tvp ? tvp->tv_sec : -1L, 0); > + osip_debug(ld, "ldap_int_poll: fd: %d tm: %lld\n", > + s, tvp ? (long long)tvp->tv_sec : -1LL, 0); > =20 > #ifdef HAVE_POLL > { > @@ -432,8 +432,8 @@ ldap_pvt_connect(LDAP *ld, ber_socket_t > opt_tv =3D &tv; > } > =20 > - osip_debug(ld, "ldap_pvt_connect: fd: %d tm: %ld async: %d\n", > - s, opt_tv ? tv.tv_sec : -1L, async); > + osip_debug(ld, "ldap_pvt_connect: fd: %d tm: %lld async: %d\n", > + s, opt_tv ? (long long)tv.tv_sec : -1LL, async); > =20 > if ( opt_tv && ldap_pvt_ndelay_on(ld, s) =3D=3D -1 ) > return ( -1 ); > --- a/libraries/libldap/os-local.c > +++ b/libraries/libldap/os-local.c > @@ -176,8 +176,8 @@ ldap_pvt_connect(LDAP *ld, ber_socket_t > opt_tv =3D &tv; > } > =20 > - oslocal_debug(ld, "ldap_connect_timeout: fd: %d tm: %ld async: %d\n", > - s, opt_tv ? tv.tv_sec : -1L, async); > + oslocal_debug(ld, "ldap_connect_timeout: fd: %d tm: %lld async: %d\n"= , > + s, opt_tv ? (long long)tv.tv_sec : -1LL, async); > =20 > if ( ldap_pvt_ndelay_on(ld, s) =3D=3D -1 ) return -1; > =20 > --- a/libraries/libldap/result.c > +++ b/libraries/libldap/result.c > @@ -264,8 +264,8 @@ wait4msg( > Debug( LDAP_DEBUG_TRACE, "wait4msg ld %p msgid %d (infinite timeout)= \n", > (void *)ld, msgid, 0 ); > } else { > - Debug( LDAP_DEBUG_TRACE, "wait4msg ld %p msgid %d (timeout %ld usec)= \n", > - (void *)ld, msgid, (long)timeout->tv_sec * 1000000 + timeout->tv_us= ec ); > + Debug( LDAP_DEBUG_TRACE, "wait4msg ld %p msgid %d (timeout %lld usec= )\n", > + (void *)ld, msgid, (long long)timeout->tv_sec * 1000000LL + timeout= ->tv_usec > ); > } > #endif /* LDAP_DEBUG */ > =20 > --- a/servers/slapd/back-ldap/bind.c > +++ b/servers/slapd/back-ldap/bind.c > @@ -3008,14 +3008,14 @@ ldap_back_conn2str( const ldapconn_base_ > } > =20 > if ( lc->lcb_create_time !=3D 0 ) { > - len =3D snprintf( tbuf, sizeof(tbuf), "%ld", lc->lcb_create_time ); > + len =3D snprintf( tbuf, sizeof(tbuf), "%lld", (long long)lc->lcb_cre= ate_time > ); > if ( ptr + sizeof(" created=3D") + len >=3D end ) return -1; > ptr =3D lutil_strcopy( ptr, " created=3D" ); > ptr =3D lutil_strcopy( ptr, tbuf ); > } > =20 > if ( lc->lcb_time !=3D 0 ) { > - len =3D snprintf( tbuf, sizeof(tbuf), "%ld", lc->lcb_time ); > + len =3D snprintf( tbuf, sizeof(tbuf), "%lld", (long long)lc->lcb_tim= e ); > if ( ptr + sizeof(" modified=3D") + len >=3D end ) return -1; > ptr =3D lutil_strcopy( ptr, " modified=3D" ); > ptr =3D lutil_strcopy( ptr, tbuf ); > --- a/servers/slapd/back-meta/config.c > +++ b/servers/slapd/back-meta/config.c > @@ -1277,8 +1277,8 @@ meta_back_cf_gen( ConfigArgs *c ) > if ( mc->mc_network_timeout =3D=3D 0 ) { > return 1; > } > - bv.bv_len =3D snprintf( c->cr_msg, sizeof(c->cr_msg), "%ld", > - mc->mc_network_timeout ); > + bv.bv_len =3D snprintf( c->cr_msg, sizeof(c->cr_msg), "%lld", > + (long long)mc->mc_network_timeout ); > bv.bv_val =3D c->cr_msg; > value_add_one( &c->rvalue_vals, &bv ); > break; > --- a/servers/slapd/overlays/dds.c > +++ b/servers/slapd/overlays/dds.c > @@ -417,7 +417,7 @@ dds_op_add( Operation *op, SlapReply *rs > assert( ttl <=3D DDS_RF2589_MAX_TTL ); > =20 > bv.bv_val =3D ttlbuf; > - bv.bv_len =3D snprintf( ttlbuf, sizeof( ttlbuf ), "%ld", ttl ); > + bv.bv_len =3D snprintf( ttlbuf, sizeof( ttlbuf ), "%lld", (long long= )ttl ); > assert( bv.bv_len < sizeof( ttlbuf ) ); > =20 > /* FIXME: apparently, values in op->ora_e are malloc'ed > @@ -695,7 +695,7 @@ dds_op_modify( Operation *op, SlapReply > goto done; > } > =20 > - bv_entryTtl.bv_len =3D snprintf( textbuf, sizeof( textbuf ), "%ld"= , entryTtl > ); > + bv_entryTtl.bv_len =3D snprintf( textbuf, sizeof( textbuf ), "%lld= ", (long > long)entryTtl ); > break; > =20 > default: > @@ -917,7 +917,7 @@ dds_response( Operation *op, SlapReply * > ttl =3D (ttl < 0) ? 0 : ttl; > assert( ttl <=3D DDS_RF2589_MAX_TTL ); > =20 > - len =3D snprintf( ttlbuf, sizeof(ttlbuf), "%ld", ttl ); > + len =3D snprintf( ttlbuf, sizeof(ttlbuf), "%lld", (long long)ttl ); > if ( len < 0 ) > { > goto done; > @@ -1177,7 +1177,7 @@ dds_op_extended( Operation *op, SlapRepl > ttlmod.sml_values =3D ttlvalues; > ttlmod.sml_numvals =3D 1; > ttlvalues[ 0 ].bv_val =3D ttlbuf; > - ttlvalues[ 0 ].bv_len =3D snprintf( ttlbuf, sizeof( ttlbuf ), "%ld",= ttl ); > + ttlvalues[ 0 ].bv_len =3D snprintf( ttlbuf, sizeof( ttlbuf ), "%lld"= , (long > long)ttl ); > BER_BVZERO( &ttlvalues[ 1 ] ); > =20 > /* the entryExpireTimestamp is added by modify */ > @@ -1205,8 +1205,8 @@ dds_op_extended( Operation *op, SlapRepl > rs->sr_rspoid =3D ch_strdup( slap_EXOP_REFRESH.bv_val ); > =20 > Log3( LDAP_DEBUG_TRACE, LDAP_LEVEL_INFO, > - "%s REFRESH dn=3D\"%s\" TTL=3D%ld\n", > - op->o_log_prefix, op->o_req_ndn.bv_val, ttl ); > + "%s REFRESH dn=3D\"%s\" TTL=3D%lld\n", > + op->o_log_prefix, op->o_req_ndn.bv_val, (long long)ttl ); > } > =20 > ber_free_buf( ber ); > --- a/servers/slapd/overlays/pcache.c > +++ b/servers/slapd/overlays/pcache.c > @@ -2728,8 +2728,8 @@ pc_bind_search( Operation *op, SlapReply > pbi->bi_flags |=3D BI_HASHED; > } else { > Debug( pcache_debug, "pc_bind_search: cache is stale, " > - "reftime: %ld, current time: %ld\n", > - pbi->bi_cq->bindref_time, op->o_time, 0 ); > + "reftime: %lld, current time: %lld\n", > + (long long)pbi->bi_cq->bindref_time, (long long)op->o_time, 0 ); > } > } else if ( pbi->bi_si ) { > /* This search result is going into the cache */ > @@ -3831,9 +3831,9 @@ pc_cf_gen( ConfigArgs *c ) > struct berval bv; > switch( c->type ) { > case PC_MAIN: > - bv.bv_len =3D snprintf( c->cr_msg, sizeof( c->cr_msg ), "%s %d %d %= d %ld", > + bv.bv_len =3D snprintf( c->cr_msg, sizeof( c->cr_msg ), "%s %d %d %= d %lld", > cm->db.bd_info->bi_type, cm->max_entries, cm->numattrsets, > - cm->num_entries_limit, cm->cc_period ); > + cm->num_entries_limit, (long long)cm->cc_period ); > bv.bv_val =3D c->cr_msg; > value_add_one( &c->rvalue_vals, &bv ); > break; > @@ -3875,12 +3875,12 @@ pc_cf_gen( ConfigArgs *c ) > /* HEADS-UP: always print all; > * if optional =3D=3D 0, ignore */ > bv.bv_len =3D snprintf( c->cr_msg, sizeof( c->cr_msg ), > - " %d %ld %ld %ld %ld", > + " %d %lld %lld %lld %lld", > temp->attr_set_index, > - temp->ttl, > - temp->negttl, > - temp->limitttl, > - temp->ttr ); > + (long long)temp->ttl, > + (long long)temp->negttl, > + (long long)temp->limitttl, > + (long long)temp->ttr ); > bv.bv_len +=3D temp->querystr.bv_len + 2; > bv.bv_val =3D ch_malloc( bv.bv_len+1 ); > ptr =3D bv.bv_val; > @@ -3897,9 +3897,9 @@ pc_cf_gen( ConfigArgs *c ) > for (temp=3Dqm->templates; temp; temp=3Dtemp->qmnext) { > if ( !temp->bindttr ) continue; > bv.bv_len =3D snprintf( c->cr_msg, sizeof( c->cr_msg ), > - " %d %ld %s ", > + " %d %lld %s ", > temp->attr_set_index, > - temp->bindttr, > + (long long)temp->bindttr, > ldap_pvt_scope2str( temp->bindscope )); > bv.bv_len +=3D temp->bindbase.bv_len + temp->bindftemp.bv_len + 4; > bv.bv_val =3D ch_malloc( bv.bv_len + 1 ); > --- a/servers/slapd/syncrepl.c > +++ b/servers/slapd/syncrepl.c > @@ -2395,8 +2395,8 @@ syncrepl_message_to_op( > op->o_callback =3D &cb; > slap_op_time( &op->o_time, &op->o_tincr ); > =20 > - Debug( LDAP_DEBUG_SYNC, "syncrepl_message_to_op: %s tid %x\n", > - si->si_ridtxt, op->o_tid, 0 ); > + Debug( LDAP_DEBUG_SYNC, "syncrepl_message_to_op: %s tid %lx\n", > + si->si_ridtxt, (unsigned long)op->o_tid, 0 ); > =20 > switch( op->o_tag ) { > case LDAP_REQ_ADD: > @@ -2905,8 +2905,8 @@ syncrepl_entry( > int freecsn =3D 1; > =20 > Debug( LDAP_DEBUG_SYNC, > - "syncrepl_entry: %s LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_%s) tid %x\n", > - si->si_ridtxt, syncrepl_state2str( syncstate ), op->o_tid ); > + "syncrepl_entry: %s LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_%s) tid %lx\n", > + si->si_ridtxt, syncrepl_state2str( syncstate ), (unsigned long)op->o= _tid ); > =20 > if (( syncstate =3D=3D LDAP_SYNC_PRESENT || syncstate =3D=3D LDAP_SYN= C_ADD ) ) { > if ( !si->si_refreshPresent && !si->si_refreshDone ) { >=20 >=20 --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8944) Support Microsoft AD DirSync as a consumer
by hyc＠openldap.org 18 Dec '18

18 Dec '18

Full_Name: Howard Chu Version: 2.5 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.233.39.182) Submitted by: hyc Code in master is now available for operating slapd as a replication consumer against Microsoft ActiveDirectory using their DirSync protocol. Note that no attempt has been made to work with anything other than user and group entries. A sample config, based on the test017 syncrepl consumer config: #### include ./schema/core.schema include ./schema/cosine.schema include ./schema/inetorgperson.schema include ./schema/nis.schema include ./schema/msuser.schema attributeoptions range= database mdb suffix "dc=ldapsync,dc=local" rootdn "cn=Replica,dc=ldapsync,dc=local" rootpw secret directory ./testrun/db.2.a index objectClass eq index cn,sn,uid pres,eq,sub index entryUUID,entryCSN eq syncrepl rid=1 provider=ldap://ldapsync/ binddn="cn=Administrator,cn=users,dc=ldapsync,dc=local" bindmethod=simple credentials=MSAD-secret searchbase="dc=ldapsync,dc=local" filter="(|(objectClass=user)(objectclass=group))" schemachecking=off scope=sub type=dirSync interval=00:00:00:03 updateref ldap://ldapsync/ database monitor #### Note that DirSync doesn't have a persist mode, it only works by refreshOnly-style polling. DirSync support for Modifications is quite braindead; the protocol has no way to indicate deletion of single-valued attributes. This has been left as-is for now, possibly some workarounds can be added for that later.

1 0

Re: (ITS#8943) speed up parallel add/delete
by derek＠shannon-data.com 13 Dec '18

13 Dec '18

On Thursday, December 13, 2018 07:54:12 AM Derek Zhou wrote: > > On December 13, 2018 1:47:44 AM GMT+08:00, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > >Hi, > > > >Thanks for the report! I have some questions: > > > >a) Did you test with writemap enabled for mdb? > No, but I did test the unpatched slapd with writemap. it was not much faster. I can test the patch with writemap to see what happens. I tested my patch with writemap, it works with same marginal performance gain like without the patch. -- Derek Zhou Shannon Systems http://www.shannon-sys.com

1 0

Re: (ITS#8943) speed up parallel add/delete
by derek＠shannon-data.com 13 Dec '18

13 Dec '18

On December 13, 2018 1:47:44 AM GMT+08:00, Quanah Gibson-Mount <quanah@sym= as=2Ecom> wrote: >Hi, > >Thanks for the report! I have some questions: > >a) Did you test with writemap enabled for mdb? No, but I did test the unpatched slapd with writemap=2E it was not much fa= ster=2E I can test the patch with writemap to see what happens=2E > >b) Did you test the effect on other operating systems? (I=2Ee=2E, Windows= ,=20 >Solaris, FreeBSD, etc)? No , I dont have any=2E The only thing I have is a x86-64 pc with linux=2E= I did try to avoid touching any os specific codes > >c) Did you test multiple filesystems under Linux(I=2Ee=2E, ext2, ext3, >ext4,=20 >xfs, etc)? > no=2E I only tested with ext4=2E >d) What filesystem did you use when testing? Was journaling enabled or > >disabled? What was the default flush behavior of the filesystem you >used? I used nobarrier, data=3Dwriteback mount options, which are faster than th= e default, but not significantly=2E I am using a very fast SSD though=2E >I=2Ee=2E, if you set dbnosync at the mdb level, the underlying filesystem >flush=20 >behavior will then be in effect (with ext4, for example, this defaults >to 5=20 >seconds) something like that=2E it also depends on vm setting, like dirty ratio=2E > >e) Did you test when the database is also writing to an underlying=20 >accesslog database that is also backed by mdb? > no, I dont konw how=2E --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E

1 0

Re: (ITS#8943) speed up parallel add/delete
by quanah＠symas.com 12 Dec '18

12 Dec '18

--On Wednesday, December 12, 2018 3:54 AM +0000 derek(a)shannon-data.com wrote: > Full_Name: Derek Zhou > Version: 2.4 git HEAD > OS: linux > URL: > Submission from: (NULL) (116.236.169.22) > > > the mdb backend does not really support parallelism in rw transactions, so > add/delete are serialized by a mutex inside the mdb backend as small > transactions. In my patch, all add/delete are put in a queue and executed > in a dedicated worker thread. It may seem pointless at first, but by > doing them all in the same thread, now I can merge concurrent ops from > different clients into larger transactions, and reduce the number of > expensive txn_commit calls (fsyncs). Hi, Thanks for the report! I have some questions: a) Did you test with writemap enabled for mdb? b) Did you test the effect on other operating systems? (I.e., Windows, Solaris, FreeBSD, etc)? c) Did you test multiple filesystems under Linux(I.e., ext2, ext3, ext4, xfs, etc)? d) What filesystem did you use when testing? Was journaling enabled or disabled? What was the default flush behavior of the filesystem you used? I.e., if you set dbnosync at the mdb level, the underlying filesystem flush behavior will then be in effect (with ext4, for example, this defaults to 5 seconds) e) Did you test when the database is also writing to an underlying accesslog database that is also backed by mdb? Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8943) speed up parallel add/delete
by derek＠shannon-data.com 12 Dec '18

12 Dec '18

Full_Name: Derek Zhou Version: 2.4 git HEAD OS: linux URL: Submission from: (NULL) (116.236.169.22) the mdb backend does not really support parallelism in rw transactions, so add/delete are serialized by a mutex inside the mdb backend as small transactions. In my patch, all add/delete are put in a queue and executed in a dedicated worker thread. It may seem pointless at first, but by doing them all in the same thread, now I can merge concurrent ops from different clients into larger transactions, and reduce the number of expensive txn_commit calls (fsyncs). http://proxy.shannon-data.com/~derek/patches/openldap/0001-add-rw_worker-in… http://proxy.shannon-data.com/~derek/patches/openldap/0002-add-config-varia… Legal notice ============ The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Derek Zhou <derek(a)shannon-data.com>. I have not assigned rights and/or interest in this work to any party. I, Derek Zhou, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#8847) New LDAP URL syntax to support binding to specific IP address at client side
by hyc＠symas.com 11 Dec '18

11 Dec '18

Sharma, Ramakant 2. (Nokia - IN/Bangalore) wrote: >>> The work of parse_and_validate is wasted since you call inet_pton bot= h for >>>validating and for using the result later. You should simply save the = IPv4 and IPv6 binary >>>addresses when the validation succeeds. There should be no get_IPvX_fr= om_lst() functions >>>at all. >=20 > I am bit confused regarding this point. >=20 > The intent of parse_and_validate_sourceip() is to set only valid intern= et address=A0 to=A0 "ldo_local_IP_addresses" so that we don=92t overwrite > =93ldo_local_IP_addresses=94 in case user provides some invalid address= es either from ldap.conf or from application. Sure, the validation step is required. The result of validation is either= a struct in_addr or a struct in6_addr. You should simply store them directly in the ldapoptions struct. Maybe ad= d a flag to tell that each one has been set. > Now during connect, the need is to get either IPv4 or IPv6 internet add= ress based on target LDAP server's address family type. So, once it is kn= own that target > LDAP server is using IPv4 or IPv6. Code will fetch the related configur= ed bind IP from "ldo_local_IP_addresses". Yes. All that should be required here is to fetch the struct in_addr or i= n6_addr value accordingly. >=20 > Since at this step we are not sure at which index the related bind IP i= s present so, I used inet_pton call to get the matching internet bind IP = (internet > address) from the list (intent was not to use binary address) This is stupid and wasted work. > If the concern is to avoid inet_pton call at this stage then, I can use= "." to search IPv4 and ":" to search IPv6 address in respective getters = (because we > already know that at this stage the fetched IP will always be valid) This is stupid and wasted work. > Kindly let me know your opinion. >=20 > =A0 >=20 > BR, >=20 > Ramakant Sharma >=20 > Senior R&D Engineer >=20 > Nokia Networks, Bangalore >=20 > =A0 >=20 --=20 -- Howard Chu CTO, 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#8847) New LDAP URL syntax to support binding to specific IP address at client side
by hyc＠symas.com 06 Dec '18

06 Dec '18

Thanks for the updated patch. diff --git a/include/ldap.h b/include/ldap.h index c58c576d3..78e07d49f 100644 --- a/include/ldap.h +++ b/include/ldap.h @@ -138,6 +138,7 @@ LDAP_BEGIN_DECL #define LDAP_OPT_CONNECT_ASYNC 0x5010 /* create connections asynchronously */ #define LDAP_OPT_CONNECT_CB 0x5011 /* connection callbacks */ #define LDAP_OPT_SESSION_REFCNT 0x5012 /* session reference count */ +#define LDAP_OPT_SOCKET_BIND_ADDRESSES 0x5013 /* user configured bind IPs */ /* OpenLDAP TLS options */ #define LDAP_OPT_X_TLS 0x6000 You've got strange whitespace here. Please re-read the CONTRIBUTING docs; we use 4-column tab stops. diff --git a/libraries/libldap/bind_ip.c b/libraries/libldap/bind_ip.c new file mode 100644 index 000000000..56eddda43 --- /dev/null +++ b/libraries/libldap/bind_ip.c @@ -0,0 +1,102 @@ +/* LIBLDAP bind_ip.c*/ +/* $OpenLDAP$ */ +/* This work is part of OpenLDAP Software <http://www.openldap.org/>. + * I see no reason why these functions are exposed in their own source file or exported from libldap. parse_and_validate_sourceip() could just be a static function inside options.c get_IPvX_from_lst() can just be statics in os-ip.c. In particular, you've defined these as global but they don't have an ldap_ prefix, which is just wrong. The work of parse_and_validate is wasted since you call inet_pton both for validating and for using the result later. You should simply save the IPv4 and IPv6 binary addresses when the validation succeeds. There should be no get_IPvX_from_lst() functions at all. -- -- Howard Chu CTO, 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#8941) Font correction in man pages
by hyc＠symas.com 05 Dec '18

05 Dec '18

This is a multi-part message in MIME format. --------------7D85C9A62F3CF2635A14D300 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Jason Trupp wrote: > Tested on Ubuntu 16.04: > Linux test 4.4.0-87-generic #110-Ubuntu SMP Tue Jul 18 12:55:35 UTC 2017 > x86_64 x86_64 x86_64 GNU/Linux > Using > GNU grops (groff) version 1.22.3 > GNU troff (groff) version 1.22.3 > > We were converting the man pages to html using the following command when we > discovered the issue: > groff -man -T html This doesn't appear to be installed on a system by default. And whoever wrote that HTML driver has apparently never seen an actual Unix manpage before, as the formatting is totally wrong. I've attached the output from man2html, which shows what it should actually look like. > > And example of the error encountered is: > groff -man -T html man8/slapdn.8 > html8/slapdn.8.html~ > stdin:97: warning: can't find font `tt' > stdin:97: warning: can't find font `tt' A single missing font is no reason to completely change the formatting. The new groff appears to use "CR" instead of "tt" but I'd rather not change this until we know how far back it works/when it breaks. > I have also attached examples of the resulting html for slapadd with the > existing setting and with the suggested setting. Note the difference of the > example command in the EXAMPLES section. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------7D85C9A62F3CF2635A14D300 Content-Type: text/html; name="slapadd.html" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="slapadd.html" PEhUTUw+CjxIRUFEPgo8dGl0bGU+U0xBUEFERCg4Qyk6IDwvdGl0bGU+PC9oZWFkPgo8dGFi bGU+Cjx0aGVhZD4KPHRyPjx0ZD5TTEFQQUREKDhDKTx0ZCBhbGlnbj0iY2VudGVyIj48dGQg YWxpZ249InJpZ2h0Ij5TTEFQQUREKDhDKQo8L3RoZWFkPgo8dGZvb3Q+Cjx0cj48dGQ+T3Bl bkxEQVAgTERWRVJTSU9OPHRkIGFsaWduPSJjZW50ZXIiPlJFTEVBU0VEQVRFPHRkIGFsaWdu PSJyaWdodCI+U0xBUEFERCg4QykKPC90Zm9vdD4KPHRib2R5Pjx0cj48dGQgY29sc3Bhbj0i MyI+PGJyPjxicj48dWw+CjwhLS0gQ29weXJpZ2h0IDE5OTgtMjAxOCBUaGUgT3BlbkxEQVAg Rm91bmRhdGlvbiBBbGwgUmlnaHRzIFJlc2VydmVkLgogQ29weWluZyByZXN0cmljdGlvbnMg YXBwbHkuICBTZWUgQ09QWVJJR0hUL0xJQ0VOU0UuCiAkT3BlbkxEQVAkLS0+CjwvdWw+Cgo8 aDM+TkFNRTwvaDM+PHVsPgpzbGFwYWRkICZtaW51czsgQWRkIGVudHJpZXMgdG8gYSBTTEFQ RCBkYXRhYmFzZQo8L3VsPgoKPGgzPlNZTk9QU0lTPC9oMz48dWw+CjxiPlNCSU5ESVIvc2xh cGFkZDwvYj4KWwo8Yj4mbWludXM7YjwvYj48aT4mbmJzcDtzdWZmaXg8L2k+XQpbCjxiPiZt aW51cztjPC9iPl0KWwo8Yj4mbWludXM7ZDwvYj48aT4mbmJzcDtkZWJ1Zy1sZXZlbDwvaT5d ClsKPGI+Jm1pbnVzO2Y8L2I+PGk+Jm5ic3A7c2xhcGQuY29uZjwvaT5dClsKPGI+Jm1pbnVz O0Y8L2I+PGk+Jm5ic3A7Y29uZmRpcjwvaT5dClsKPGI+Jm1pbnVzO2c8L2I+XQpbCjxiPiZt aW51cztqPC9iPjxpPiZuYnNwO2xpbmVubzwvaT5dClsKPGI+Jm1pbnVzO2w8L2I+PGk+Jm5i c3A7bGRpZi1maWxlPC9pPl0KWwo8Yj4mbWludXM7bjwvYj48aT4mbmJzcDtkYm51bTwvaT5d ClsKPGI+Jm1pbnVzO288L2I+PGk+Jm5ic3A7b3B0aW9uPC9pPls8Yj49PC9iPjxpPnZhbHVl PC9pPl1dClsKPGI+Jm1pbnVzO3E8L2I+XQpbCjxiPiZtaW51cztzPC9iPl0KWwo8Yj4mbWlu dXM7UzwvYj48aT4mbmJzcDtTSUQ8L2k+XQpbCjxiPiZtaW51czt1PC9iPl0KWwo8Yj4mbWlu dXM7djwvYj5dClsKPGI+Jm1pbnVzO3c8L2I+XQo8L3VsPgoKPGgzPkRFU0NSSVBUSU9OPC9o Mz48dWw+CjxwPgo8Yj5TbGFwYWRkPC9iPgppcyB1c2VkIHRvIGFkZCBlbnRyaWVzIHNwZWNp ZmllZCBpbiBMREFQIERpcmVjdG9yeSBJbnRlcmNoYW5nZSBGb3JtYXQKKExESUYpIHRvIGEK PGEgaHJlZj0ic2xhcGQuOCI+PGI+c2xhcGQ8L2I+PC9hPig4KQpkYXRhYmFzZS4KSXQgb3Bl bnMgdGhlIGdpdmVuIGRhdGFiYXNlIGRldGVybWluZWQgYnkgdGhlIGRhdGFiYXNlIG51bWJl ciBvcgpzdWZmaXggYW5kIGFkZHMgZW50cmllcyBjb3JyZXNwb25kaW5nIHRvIHRoZSBwcm92 aWRlZCBMRElGIHRvCnRoZSBkYXRhYmFzZS4KRGF0YWJhc2VzIGNvbmZpZ3VyZWQgYXMKPGI+ c3Vib3JkaW5hdGU8L2I+Cm9mIHRoaXMgb25lIGFyZSBhbHNvIHVwZGF0ZWQsIHVubGVzcyA8 Yj4mbWludXM7ZzwvYj4gaXMgc3BlY2lmaWVkLgpUaGUgTERJRiBpbnB1dCBpcyByZWFkIGZy b20gc3RhbmRhcmQgaW5wdXQgb3IgdGhlIHNwZWNpZmllZCBmaWxlLgo8cD4KQWxsIGZpbGVz IGV2ZW50dWFsbHkgY3JlYXRlZCBieQo8Yj5zbGFwYWRkPC9iPgp3aWxsIGJlbG9uZyB0byB0 aGUgaWRlbnRpdHkKPGI+c2xhcGFkZDwvYj4KaXMgcnVuIGFzLCBzbyBtYWtlIHN1cmUgeW91 IGVpdGhlciBydW4KPGI+c2xhcGFkZDwvYj4Kd2l0aCB0aGUgc2FtZSBpZGVudGl0eQo8YSBo cmVmPSJzbGFwZC44Ij48Yj5zbGFwZDwvYj48L2E+KDgpCndpbGwgYmUgcnVuIGFzIChzZWUg b3B0aW9uCjxiPiZtaW51czt1PC9iPgppbgo8YSBocmVmPSJzbGFwZC44Ij48Yj5zbGFwZDwv Yj48L2E+KDgpKSwKb3IgY2hhbmdlIGZpbGUgb3duZXJzaGlwIGJlZm9yZSBydW5uaW5nCjxh IGhyZWY9InNsYXBkLjgiPjxiPnNsYXBkPC9iPjwvYT4oOCkuCjxwPgpOb3RlOiBzbGFwYWRk IHdpbGwgYWxzbyBwZXJmb3JtIHRoZSByZWxldmFudCBpbmRleGluZyB3aGlsc3QgYWRkaW5n IHRoZSBkYXRhYmFzZSBpZgphbnkgYXJlIGNvbmZpZ3VyZWQuIEZvciBzcGVjaWZpYyBkZXRh aWxzLCBwbGVhc2Ugc2VlCjxhIGhyZWY9InNsYXBpbmRleC44Ij48Yj5zbGFwaW5kZXg8L2I+ PC9hPig4KS4KPC91bD4KCjxoMz5PUFRJT05TPC9oMz48dWw+CjxwPgo8ZGwgY29tcGFjdD48 ZHQ+CjxiPiZtaW51cztiPC9iPjxpPiZuYnNwO3N1ZmZpeDwvaT4KPGRkPgpVc2UgdGhlIHNw ZWNpZmllZCA8aT5zdWZmaXg8L2k+IHRvIGRldGVybWluZSB3aGljaCBkYXRhYmFzZSB0bwph ZGQgZW50cmllcyB0by4gIFRoZSA8Yj4mbWludXM7YjwvYj4gY2Fubm90IGJlIHVzZWQgaW4g Y29uanVuY3Rpb24Kd2l0aCB0aGUKPGI+Jm1pbnVzO248L2I+Cm9wdGlvbi4KPC9kbD4KPHA+ CjxkbCBjb21wYWN0PjxkdD4KPGI+Jm1pbnVzO2M8L2I+CjxkZD4KZW5hYmxlIGNvbnRpbnVl IChpZ25vcmUgZXJyb3JzKSBtb2RlLgo8L2RsPgo8cD4KPGRsIGNvbXBhY3Q+PGR0Pgo8Yj4m bWludXM7ZDwvYj48aT4mbmJzcDtkZWJ1Zy1sZXZlbDwvaT4KPGRkPgplbmFibGUgZGVidWdn aW5nIG1lc3NhZ2VzIGFzIGRlZmluZWQgYnkgdGhlIHNwZWNpZmllZAo8aT5kZWJ1Zy1sZXZl bDwvaT47CnNlZQo8YSBocmVmPSJzbGFwZC44Ij48Yj5zbGFwZDwvYj48L2E+KDgpCmZvciBk ZXRhaWxzLgo8L2RsPgo8cD4KPGRsIGNvbXBhY3Q+PGR0Pgo8Yj4mbWludXM7ZjwvYj48aT4m bmJzcDtzbGFwZC5jb25mPC9pPgo8ZGQ+CnNwZWNpZnkgYW4gYWx0ZXJuYXRpdmUKPGEgaHJl Zj0iLi4vbWFuNS9zbGFwZC5jb25mLjUiPjxiPnNsYXBkLmNvbmY8L2I+PC9hPig1KQpmaWxl Lgo8L2RsPgo8cD4KPGRsIGNvbXBhY3Q+PGR0Pgo8Yj4mbWludXM7RjwvYj48aT4mbmJzcDtj b25mZGlyPC9pPgo8ZGQ+CnNwZWNpZnkgYSBjb25maWcgZGlyZWN0b3J5LgpJZiBib3RoCjxi PiZtaW51cztmPC9iPgphbmQKPGI+Jm1pbnVzO0Y8L2I+CmFyZSBzcGVjaWZpZWQsIHRoZSBj b25maWcgZmlsZSB3aWxsIGJlIHJlYWQgYW5kIGNvbnZlcnRlZCB0bwpjb25maWcgZGlyZWN0 b3J5IGZvcm1hdCBhbmQgd3JpdHRlbiB0byB0aGUgc3BlY2lmaWVkIGRpcmVjdG9yeS4KSWYg bmVpdGhlciBvcHRpb24gaXMgc3BlY2lmaWVkLCBhbiBhdHRlbXB0IHRvIHJlYWQgdGhlCmRl ZmF1bHQgY29uZmlnIGRpcmVjdG9yeSB3aWxsIGJlIG1hZGUgYmVmb3JlIHRyeWluZyB0byB1 c2UgdGhlIGRlZmF1bHQKY29uZmlnIGZpbGUuIElmIGEgdmFsaWQgY29uZmlnIGRpcmVjdG9y eSBleGlzdHMgdGhlbiB0aGUKZGVmYXVsdCBjb25maWcgZmlsZSBpcyBpZ25vcmVkLiBJZiBk cnktcnVuIG1vZGUgaXMgYWxzbyBzcGVjaWZpZWQsCm5vIGNvbnZlcnNpb24gd2lsbCBvY2N1 ci4KPC9kbD4KPHA+CjxkbCBjb21wYWN0PjxkdD4KPGI+Jm1pbnVzO2c8L2I+CjxkZD4KZGlz YWJsZSBzdWJvcmRpbmF0ZSBnbHVpbmcuICBPbmx5IHRoZSBzcGVjaWZpZWQgZGF0YWJhc2Ug d2lsbCBiZQpwcm9jZXNzZWQsIGFuZCBub3QgaXRzIGdsdWVkIHN1Ym9yZGluYXRlcyAoaWYg YW55KS4KPC9kbD4KPHA+CjxkbCBjb21wYWN0PjxkdD4KPGI+Jm1pbnVzO2o8L2I+PGk+Jm5i c3A7bGluZW5vPC9pPgo8ZGQ+Ckp1bXAgdG8gdGhlIHNwZWNpZmllZCBsaW5lIG51bWJlciBp biB0aGUgTERJRiBmaWxlIGJlZm9yZSBwcm9jZXNzaW5nCmFueSBlbnRyaWVzLiBUaGlzIGFs bG93cyBhIGxvYWQgdGhhdCB3YXMgYWJvcnRlZCBkdWUgdG8gZXJyb3JzIGluIHRoZQppbnB1 dCBMRElGIHRvIGJlIHJlc3VtZWQgYWZ0ZXIgdGhlIGVycm9ycyBhcmUgY29ycmVjdGVkLgo8 L2RsPgo8cD4KPGRsIGNvbXBhY3Q+PGR0Pgo8Yj4mbWludXM7bDwvYj48aT4mbmJzcDtsZGlm LWZpbGU8L2k+CjxkZD4KUmVhZCBMRElGIGZyb20gdGhlIHNwZWNpZmllZCBmaWxlIGluc3Rl YWQgb2Ygc3RhbmRhcmQgaW5wdXQuCjwvZGw+CjxwPgo8ZGwgY29tcGFjdD48ZHQ+CjxiPiZt aW51cztuPC9iPjxpPiZuYnNwO2RibnVtPC9pPgo8ZGQ+CkFkZCBlbnRyaWVzIHRvIHRoZSA8 aT5kYm51bTwvaT4tdGggZGF0YWJhc2UgbGlzdGVkIGluIHRoZQpjb25maWd1cmF0aW9uIGZp bGUuICBUaGUKPGI+Jm1pbnVzO248L2I+CmNhbm5vdCBiZSB1c2VkIGluIGNvbmp1bmN0aW9u IHdpdGggdGhlCjxiPiZtaW51cztiPC9iPgpvcHRpb24uClRvIHBvcHVsYXRlIHRoZSBjb25m aWcgZGF0YWJhc2UKPGEgaHJlZj0iLi4vbWFuNS9zbGFwZC1jb25maWcuNSI+PGI+c2xhcGQm bWludXM7Y29uZmlnPC9iPjwvYT4oNSksCnVzZSAKPGI+Jm1pbnVzO24gMDwvYj4KYXMgaXQg aXMgYWx3YXlzIHRoZSBmaXJzdCBkYXRhYmFzZS4gSXQgbXVzdCBwaHlzaWNhbGx5IGV4aXN0 Cm9uIHRoZSBmaWxlc3lzdGVtIHByaW9yIHRvIHRoaXMsIGhvd2V2ZXIuCjwvZGw+CjxwPgo8 ZGwgY29tcGFjdD48ZHQ+CjxiPiZtaW51cztvPC9iPjxpPiZuYnNwO29wdGlvbjwvaT5bPGI+ PTwvYj48aT52YWx1ZTwvaT5dCjxkZD4KU3BlY2lmeSBhbgo8aT5vcHRpb248L2k+CndpdGgg YShuIG9wdGlvbmFsKQo8aT52YWx1ZTwvaT4uClBvc3NpYmxlIGdlbmVyaWMgb3B0aW9ucy92 YWx1ZXMgYXJlOgo8L2RsPgo8cD4KPHByZT4KICAgICAgICAgICAgICBzeXNsb2c9Jmx0O3N1 YnN5c3RlbXMmZ3Q7ICAoc2VlIGAmbWludXM7cycgaW4gc2xhcGQoOCkpCiAgICAgICAgICAg ICAgc3lzbG9nJm1pbnVzO2xldmVsPSZsdDtsZXZlbCZndDsgKHNlZSBgJm1pbnVzO1MnIGlu IHNsYXBkKDgpKQogICAgICAgICAgICAgIHN5c2xvZyZtaW51czt1c2VyPSZsdDt1c2VyJmd0 OyAgIChzZWUgYCZtaW51cztsJyBpbiBzbGFwZCg4KSkKCiAgICAgICAgICAgICAgc2NoZW1h LWNoZWNrPXt5ZXN8bm99CiAgICAgICAgICAgICAgdmFsdWUtY2hlY2s9e3llc3xub30KCjwv cHJlPgo8dWw+ClRoZSA8aT5zY2hlbWEmbWludXM7Y2hlY2s8L2k+IG9wdGlvbiB0b2dnbGVz IHNjaGVtYSBjaGVja2luZyAoZGVmYXVsdCBvbik7CnRoZSA8aT52YWx1ZSZtaW51cztjaGVj azwvaT4gb3B0aW9uIHRvZ2dsZXMgdmFsdWUgY2hlY2tpbmcgKGRlZmF1bHQgb2ZmKS4KVGhl IGxhdHRlciBpcyBpbmNvbXBhdGlibGUgd2l0aCA8Yj4tcTwvYj4uCjwvdWw+CjxwPgo8ZGwg Y29tcGFjdD48ZHQ+CjxiPiZtaW51cztxPC9iPgo8ZGQ+CmVuYWJsZSBxdWljayAoZmV3ZXIg aW50ZWdyaXR5IGNoZWNrcykgbW9kZS4gIERvZXMgZmV3ZXIgY29uc2lzdGVuY3kgY2hlY2tz Cm9uIHRoZSBpbnB1dCBkYXRhLCBhbmQgbm8gY29uc2lzdGVuY3kgY2hlY2tzIHdoZW4gd3Jp dGluZyB0aGUgZGF0YWJhc2UuCkltcHJvdmVzIHRoZSBsb2FkIHRpbWUgYnV0IGlmIGFueSBl cnJvcnMgb3IgaW50ZXJydXB0aW9ucyBvY2N1ciB0aGUgcmVzdWx0aW5nCmRhdGFiYXNlIHdp bGwgYmUgdW51c2FibGUuCjwvZGw+CjxwPgo8ZGwgY29tcGFjdD48ZHQ+CjxiPiZtaW51cztz PC9iPgo8ZGQ+CmRpc2FibGUgc2NoZW1hIGNoZWNraW5nLiAgVGhpcyBvcHRpb24gaXMgaW50 ZW5kZWQgdG8gYmUgdXNlZCB3aGVuIGxvYWRpbmcKZGF0YWJhc2VzIGNvbnRhaW5pbmcgc3Bl Y2lhbCBvYmplY3RzLCBzdWNoIGFzIGZyYWN0aW9uYWwgb2JqZWN0cyBvbiBhCnBhcnRpYWwg cmVwbGljYS4gIExvYWRpbmcgbm9ybWFsIG9iamVjdHMgd2hpY2ggZG8gbm90IGNvbmZvcm0g dG8Kc2NoZW1hIG1heSByZXN1bHQgaW4gdW5leHBlY3RlZCBhbmQgaWxsIGJlaGF2aW9yLgo8 L2RsPgo8cD4KPGRsIGNvbXBhY3Q+PGR0Pgo8Yj4mbWludXM7UzwvYj48aT4mbmJzcDtTSUQ8 L2k+CjxkZD4KU2VydmVyIElEIHRvIHVzZSBpbiBnZW5lcmF0ZWQgZW50cnlDU04uICBBbHNv IHVzZWQgZm9yIGNvbnRleHRDU04KaWYgPGI+Jm1pbnVzO3c8L2I+IGlzIHNldCBhcyB3ZWxs LiAgRGVmYXVsdHMgdG8gPGI+MDwvYj4uCjwvZGw+CjxwPgo8ZGwgY29tcGFjdD48ZHQ+Cjxi PiZtaW51czt1PC9iPgo8ZGQ+CmVuYWJsZSBkcnktcnVuIChkb24ndCB3cml0ZSB0byBiYWNr ZW5kKSBtb2RlLgo8L2RsPgo8cD4KPGRsIGNvbXBhY3Q+PGR0Pgo8Yj4mbWludXM7djwvYj4K PGRkPgplbmFibGUgdmVyYm9zZSBtb2RlLgo8L2RsPgo8cD4KPGRsIGNvbXBhY3Q+PGR0Pgo8 Yj4mbWludXM7dzwvYj4KPGRkPgp3cml0ZSBzeW5jcmVwbCBjb250ZXh0IGluZm9ybWF0aW9u LgpBZnRlciBhbGwgZW50cmllcyBhcmUgYWRkZWQsIHRoZSBjb250ZXh0Q1NOCndpbGwgYmUg dXBkYXRlZCB3aXRoIHRoZSBncmVhdGVzdCBDU04gaW4gdGhlIGRhdGFiYXNlLgo8L2RsPgo8 L3VsPgoKPGgzPkxJTUlUQVRJT05TPC9oMz48dWw+CllvdXIKPGEgaHJlZj0ic2xhcGQuOCI+ PGI+c2xhcGQ8L2I+PC9hPig4KQpzaG91bGQgbm90IGJlIHJ1bm5pbmcgCndoZW4geW91IGRv IHRoaXMgdG8gZW5zdXJlIGNvbnNpc3RlbmN5IG9mIHRoZSBkYXRhYmFzZS4KPHA+CjxiPnNs YXBhZGQ8L2I+Cm1heSBub3QgcHJvdmlkZSBuYW1pbmcgb3Igc2NoZW1hIGNoZWNrcy4gIEl0 IGlzIGFkdmlzYWJsZSB0bwp1c2UKPGEgaHJlZj0iLi4vbWFuMS9sZGFwYWRkLjEiPjxiPmxk YXBhZGQ8L2I+PC9hPigxKQp3aGVuIGFkZGluZyBuZXcgZW50cmllcyBpbnRvIGFuIGV4aXN0 aW5nIGRpcmVjdG9yeS4KPC91bD4KCjxoMz5FWEFNUExFUzwvaDM+PHVsPgpUbyBpbXBvcnQg dGhlIGVudHJpZXMgc3BlY2lmaWVkIGluIGZpbGUKPGI+bGRpZjwvYj4KaW50byB5b3VyCjxh IGhyZWY9InNsYXBkLjgiPjxiPnNsYXBkPC9iPjwvYT4oOCkKZGF0YWJhc2UgZ2l2ZSB0aGUg Y29tbWFuZDoKPHA+CjxwcmU+Cjx0dD4JU0JJTkRJUi9zbGFwYWRkICZtaW51cztsIGxkaWYK PC90dD48L3ByZT4KPC91bD4KCjxoMz5TRUUgQUxTTzwvaDM+PHVsPgo8YSBocmVmPSIuLi9t YW4zL2xkYXAuMyI+PGI+bGRhcDwvYj48L2E+KDMpLAo8YSBocmVmPSIuLi9tYW41L2xkaWYu NSI+PGI+bGRpZjwvYj48L2E+KDUpLAo8YSBocmVmPSJzbGFwY2F0LjgiPjxiPnNsYXBjYXQ8 L2I+PC9hPig4KSwKPGEgaHJlZj0ic2xhcGluZGV4LjgiPjxiPnNsYXBpbmRleDwvYj48L2E+ KDgpLAo8YSBocmVmPSJzbGFwbW9kaWZ5LjgiPjxiPnNsYXBtb2RpZnk8L2I+PC9hPig4KSwK PGEgaHJlZj0iLi4vbWFuMS9sZGFwYWRkLjEiPjxiPmxkYXBhZGQ8L2I+PC9hPigxKSwKPGEg aHJlZj0ic2xhcGQuOCI+PGI+c2xhcGQ8L2I+PC9hPig4KQo8cD4KIk9wZW5MREFQIEFkbWlu aXN0cmF0b3IncyBHdWlkZSIgKDxhIGhyZWY9Imh0dHA6Ly93d3cuT3BlbkxEQVAub3JnL2Rv Yy9hZG1pbi8iPmh0dHA6Ly93d3cuT3BlbkxEQVAub3JnL2RvYy9hZG1pbi88L2E+KQo8L3Vs PgoKPGgzPkFDS05PV0xFREdFTUVOVFM8L2gzPjx1bD4KPCEtLSBTaGFyZWQgUHJvamVjdCBB Y2tub3dsZWRnZW1lbnQgVGV4dC0tPgo8Yj5PcGVuTERBUCBTb2Z0d2FyZTwvYj4KaXMgZGV2 ZWxvcGVkIGFuZCBtYWludGFpbmVkIGJ5IFRoZSBPcGVuTERBUCBQcm9qZWN0ICZsdDs8YSBo cmVmPSJodHRwOi8vd3d3Lm9wZW5sZGFwLm9yZy8iPmh0dHA6Ly93d3cub3BlbmxkYXAub3Jn LzwvYT4+Lgo8Yj5PcGVuTERBUCBTb2Z0d2FyZTwvYj4KaXMgZGVyaXZlZCBmcm9tIHRoZSBV bml2ZXJzaXR5IG9mIE1pY2hpZ2FuIExEQVAgMy4zIFJlbGVhc2UuICAKPC91bD48L3Rib2R5 PjwvdGFibGU+PC9odG1sPgo= --------------7D85C9A62F3CF2635A14D300--

1 0

RE: (ITS#8941) Font correction in man pages
by jtrupp＠symas.com 05 Dec '18

05 Dec '18

This is a multipart message in MIME format. ------=_NextPart_000_020D_01D48C74.C01EDC90 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Tested on Ubuntu 16.04: Linux test 4.4.0-87-generic #110-Ubuntu SMP Tue Jul 18 12:55:35 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux Using GNU grops (groff) version 1.22.3 GNU troff (groff) version 1.22.3 We were converting the man pages to html using the following command when we discovered the issue: groff -man -T html And example of the error encountered is: groff -man -T html man8/slapdn.8 > html8/slapdn.8.html~ stdin:97: warning: can't find font `tt' stdin:97: warning: can't find font `tt' I have also attached examples of the resulting html for slapadd with the existing setting and with the suggested setting. Note the difference of the example command in the EXAMPLES section. Thank you, Jason Trupp Symas Corporation (855) LDAP-GUY -----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Tuesday, December 4, 2018 6:34 PM To: jtrupp(a)symas.com; openldap-its(a)OpenLDAP.org Subject: Re: (ITS#8941) Font correction in man pages jtrupp(a)symas.com wrote: > Full_Name: Jason Trupp > Version: 2.4.46 > OS: Ubuntu > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.197.13.194) > > > The impacted man pages contain the following (example) .ft setting in > the "EXAMPLES" section: > > .ft tt > /opt/symas/bin/slapadd \-l ldif .ft > > "tt" refers to the mono-spaced font "teletype" which is no longer > recognized by groff/troff and modern web browsers. Nonsense. There is no relation between roff language and HTML or web browsers. > The affected man pages include: > ./man8/slapadd.8, ./man8/slapcat.8, ./man8/slapacl.8, > ./man8/slaptest.8, ./man8/slapdn.8, ./man8/slapindex.8, > ./man8/slapmodify.8, ./man8/slapd.8, ./man8/slapschema.8, > ./man8/slapauth.8 and ./man5/ldif.5 > > The current verbiage should be replaced by: > > .EX > /opt/symas/bin/slapadd \-l ldif .EE There are no such macros in my local copy of man macros, which is on a fairly recent (Ubuntu 18) distro. > Please refer to man 7 groff_man for an explanation of these settings. > The replacement syntax has been tested and works as expected. Tested on what platforms? MacOS? BSD? Solaris? What OS revision? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ ------=_NextPart_000_020D_01D48C74.C01EDC90 Content-Type: text/html; name="corrected-slapadd.8.html" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="corrected-slapadd.8.html" =0A= =0A= <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"=0A= "http://www.w3.org/TR/html4/loose.dtd">=0A= <html>=0A= <head>=0A= <meta name=3D"generator" content=3D"groff -Thtml, see www.gnu.org">=0A= <meta http-equiv=3D"Content-Type" content=3D"text/html; = charset=3DUS-ASCII">=0A= <meta name=3D"Content-Style" content=3D"text/css">=0A= <style type=3D"text/css">=0A= p { margin-top: 0; margin-bottom: 0; vertical-align: top }=0A= pre { margin-top: 0; margin-bottom: 0; vertical-align: top }=0A= table { margin-top: 0; margin-bottom: 0; vertical-align: top }=0A= h1 { text-align: center }=0A= </style>=0A= <title>SLAPADD</title>=0A= =0A= </head>=0A= <body>=0A= =0A= <h1 align=3D"center">SLAPADD</h1>=0A= =0A= <a href=3D"#NAME">NAME</a> =0A= <a href=3D"#SYNOPSIS">SYNOPSIS</a> =0A= <a href=3D"#DESCRIPTION">DESCRIPTION</a> =0A= <a href=3D"#OPTIONS">OPTIONS</a> =0A= <a href=3D"#LIMITATIONS">LIMITATIONS</a> =0A= <a href=3D"#EXAMPLES">EXAMPLES</a> =0A= <a href=3D"#SEE ALSO">SEE ALSO</a> =0A= <a href=3D"#ACKNOWLEDGEMENTS">ACKNOWLEDGEMENTS</a> =0A= =0A= <hr>=0A= =0A= =0A= <h2>NAME=0A= <a name=3D"NAME"></a>=0A= </h2>=0A= =0A= =0A= slapadd −=0A= Add entries to a SLAPD database=0A= =0A= <h2>SYNOPSIS=0A= <a name=3D"SYNOPSIS"></a>=0A= </h2>=0A= =0A= =0A= =0A= /opt/symas/bin/slapadd=0A= [−b suffix] [−c]=0A= [−d debug-level]=0A= [−f slapd.conf]=0A= [−F confdir] [−g]=0A= [−j lineno]=0A= [−l ldif-file]=0A= [−n dbnum]=0A= [−o option[=3Dvalue]]=0A= [−q] [−s]=0A= [−S SID] [−u]=0A= [−v] [−w]=0A= =0A= <h2>DESCRIPTION=0A= <a name=3D"DESCRIPTION"></a>=0A= </h2>=0A= =0A= =0A= Slapadd=0A= is used to add entries specified in LDAP Directory=0A= Interchange Format (LDIF) to a slapd(8) database. It=0A= opens the given database determined by the database number=0A= or suffix and adds entries corresponding to the provided=0A= LDIF to the database. Databases configured as=0A= subordinate of this one are also updated, unless=0A= −g is specified. The LDIF input is read from=0A= standard input or the specified file.=0A= =0A= All files=0A= eventually created by slapadd will belong to the=0A= identity slapadd is run as, so make sure you either=0A= run slapadd with the same identity slapd(8)=0A= will be run as (see option −u in=0A= slapd(8)), or change file ownership before running=0A= slapd(8).=0A= =0A= Note: slapadd=0A= will also perform the relevant indexing whilst adding the=0A= database if any are configured. For specific details, please=0A= see slapindex(8).=0A= =0A= <h2>OPTIONS=0A= <a name=3D"OPTIONS"></a>=0A= </h2>=0A= =0A= =0A= =0A= −b suffix=0A= =0A= Use the specified suffix=0A= to determine which database to add entries to. The=0A= −b cannot be used in conjunction with the=0A= −n option.=0A= =0A= <table width=3D"100%" border=3D"0" rules=3D"none" frame=3D"void"=0A= cellspacing=3D"0" cellpadding=3D"0">=0A= <tr valign=3D"top" align=3D"left">=0A= <td width=3D"11%"></td>=0A= <td width=3D"3%">=0A= =0A= =0A= −c</td>=0A= <td width=3D"8%"></td>=0A= <td width=3D"56%">=0A= =0A= =0A= enable continue (ignore errors) mode.</td>=0A= <td width=3D"22%">=0A= </td></tr>=0A= </table>=0A= =0A= =0A= −d debug-level=0A= =0A= enable debugging messages as=0A= defined by the specified debug-level; see=0A= slapd(8) for details.=0A= =0A= =0A= −f slapd.conf=0A= =0A= specify an alternative=0A= slapd.conf(5) file.=0A= =0A= =0A= −F confdir=0A= =0A= specify a config directory. If=0A= both −f and −F are specified, the=0A= config file will be read and converted to config directory=0A= format and written to the specified directory. If neither=0A= option is specified, an attempt to read the default config=0A= directory will be made before trying to use the default=0A= config file. If a valid config directory exists then the=0A= default config file is ignored. If dry-run mode is also=0A= specified, no conversion will occur.=0A= =0A= <table width=3D"100%" border=3D"0" rules=3D"none" frame=3D"void"=0A= cellspacing=3D"0" cellpadding=3D"0">=0A= <tr valign=3D"top" align=3D"left">=0A= <td width=3D"11%"></td>=0A= <td width=3D"3%">=0A= =0A= =0A= −g</td>=0A= <td width=3D"8%"></td>=0A= <td width=3D"78%">=0A= =0A= =0A= disable subordinate gluing. Only the specified database=0A= will be processed, and not its glued subordinates (if=0A= any). </td></tr>=0A= </table>=0A= =0A= =0A= −j lineno=0A= =0A= Jump to the specified line=0A= number in the LDIF file before processing any entries. This=0A= allows a load that was aborted due to errors in the input=0A= LDIF to be resumed after the errors are corrected.=0A= =0A= =0A= −l ldif-file=0A= =0A= Read LDIF from the specified=0A= file instead of standard input.=0A= =0A= =0A= −n dbnum=0A= =0A= Add entries to the=0A= dbnum-th database listed in the configuration file.=0A= The −n cannot be used in conjunction with the=0A= −b option. To populate the config database=0A= slapd−config(5), use −n 0 as it is=0A= always the first database. It must physically exist on the=0A= filesystem prior to this, however.=0A= =0A= =0A= −o option[=3D<= i>value]=0A= =0A= Specify an option with=0A= a(n optional) value. Possible generic options/values=0A= are:=0A= =0A= =0A= syslog=3D<subsystems>=0A= (see ’−s’ in slapd(8)) =0A= syslog−level=3D<level> (see ’−S’=0A= in slapd(8)) =0A= syslog−user=3D<user> (see ’−l’=0A= in slapd(8))=0A= =0A= =0A= schema-check=3D{yes|no}=0A= =0A= value-check=3D{yes|no}=0A= =0A= The=0A= schema−check option toggles schema checking=0A= (default on); =0A= the value−check option toggles value checking=0A= (default off). =0A= The latter is incompatible with -q.=0A= =0A= <table width=3D"100%" border=3D"0" rules=3D"none" frame=3D"void"=0A= cellspacing=3D"0" cellpadding=3D"0">=0A= <tr valign=3D"top" align=3D"left">=0A= <td width=3D"11%"></td>=0A= <td width=3D"3%">=0A= =0A= =0A= −q</td>=0A= <td width=3D"8%"></td>=0A= <td width=3D"78%">=0A= =0A= =0A= enable quick (fewer integrity checks) mode. Does fewer=0A= consistency checks</td></tr>=0A= </table>=0A= =0A= on the input data, and no=0A= consistency checks when writing the database. =0A= Improves the load time but if any errors or interruptions=0A= occur the resulting =0A= database will be unusable.=0A= =0A= <table width=3D"100%" border=3D"0" rules=3D"none" frame=3D"void"=0A= cellspacing=3D"0" cellpadding=3D"0">=0A= <tr valign=3D"top" align=3D"left">=0A= <td width=3D"11%"></td>=0A= <td width=3D"3%">=0A= =0A= =0A= −s</td>=0A= <td width=3D"8%"></td>=0A= <td width=3D"78%">=0A= =0A= =0A= disable schema checking. This=0A= option is intended to be used when loading</td></tr>=0A= </table>=0A= =0A= databases containing special=0A= objects, such as fractional objects on a =0A= partial replica. Loading normal objects which do not conform=0A= to =0A= schema may result in unexpected and ill behavior.=0A= =0A= <table width=3D"100%" border=3D"0" rules=3D"none" frame=3D"void"=0A= cellspacing=3D"0" cellpadding=3D"0">=0A= <tr valign=3D"top" align=3D"left">=0A= <td width=3D"11%"></td>=0A= <td width=3D"9%">=0A= =0A= =0A= =0A= −S SID </td>=0A= <td width=3D"2%"></td>=0A= <td width=3D"78%">=0A= =0A= =0A= Server ID to use in generated=0A= entryCSN. Also used for contextCSN</td></tr>=0A= </table>=0A= =0A= if −w is set as=0A= well. Defaults to 0.=0A= =0A= <table width=3D"100%" border=3D"0" rules=3D"none" frame=3D"void"=0A= cellspacing=3D"0" cellpadding=3D"0">=0A= <tr valign=3D"top" align=3D"left">=0A= <td width=3D"11%"></td>=0A= <td width=3D"3%">=0A= =0A= =0A= −u</td>=0A= <td width=3D"8%"></td>=0A= <td width=3D"69%">=0A= =0A= =0A= enable dry-run (don’t=0A= write to backend) mode.</td>=0A= <td width=3D"9%">=0A= </td></tr>=0A= <tr valign=3D"top" align=3D"left">=0A= <td width=3D"11%"></td>=0A= <td width=3D"3%">=0A= =0A= =0A= −v</td>=0A= <td width=3D"8%"></td>=0A= <td width=3D"69%">=0A= =0A= =0A= enable verbose mode.</td>=0A= <td width=3D"9%">=0A= </td></tr>=0A= <tr valign=3D"top" align=3D"left">=0A= <td width=3D"11%"></td>=0A= <td width=3D"3%">=0A= =0A= =0A= −w</td>=0A= <td width=3D"8%"></td>=0A= <td width=3D"69%">=0A= =0A= =0A= write syncrepl context information.</td>=0A= <td width=3D"9%">=0A= </td></tr>=0A= </table>=0A= =0A= After all entries are added,=0A= the contextCSN =0A= will be updated with the greatest CSN in the database.=0A= =0A= <h2>LIMITATIONS=0A= <a name=3D"LIMITATIONS"></a>=0A= </h2>=0A= =0A= =0A= Your=0A= slapd(8) should not be running when you do this to=0A= ensure consistency of the database.=0A= =0A= slapadd=0A= may not provide naming or schema checks. It is advisable to=0A= use ldapadd(1) when adding new entries into an=0A= existing directory.=0A= =0A= <h2>EXAMPLES=0A= <a name=3D"EXAMPLES"></a>=0A= </h2>=0A= =0A= =0A= To import the=0A= entries specified in file ldif into your=0A= slapd(8) database give the command:=0A= =0A= <pre style=3D"margin-left:11%; margin-top: 1em"> = /opt/symas/bin/slapadd −l ldif</pre>=0A= =0A= =0A= <h2>SEE ALSO=0A= <a name=3D"SEE ALSO"></a>=0A= </h2>=0A= =0A= =0A= =0A= ldap(3),=0A= ldif(5), slapcat(8), slapindex(8),=0A= ldapadd(1), slapd(8)=0A= =0A= "OpenLDAP=0A= Administrator’s Guide"=0A= (http://www.OpenLDAP.org/doc/admin/)=0A= =0A= <h2>ACKNOWLEDGEMENTS=0A= <a name=3D"ACKNOWLEDGEMENTS"></a>=0A= </h2>=0A= =0A= =0A= OpenLDAP=0A= Software is developed and maintained by The OpenLDAP=0A= Project <http://www.openldap.org/>. OpenLDAP=0A= Software is derived from the University of Michigan LDAP=0A= 3.3 Release.=0A= <hr>=0A= </body>=0A= </html>=0A= ------=_NextPart_000_020D_01D48C74.C01EDC90 Content-Type: text/html; name="current-slapadd.8.html" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="current-slapadd.8.html" =0A= =0A= <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"=0A= "http://www.w3.org/TR/html4/loose.dtd">=0A= <html>=0A= <head>=0A= <meta name=3D"generator" content=3D"groff -Thtml, see www.gnu.org">=0A= <meta http-equiv=3D"Content-Type" content=3D"text/html; = charset=3DUS-ASCII">=0A= <meta name=3D"Content-Style" content=3D"text/css">=0A= <style type=3D"text/css">=0A= p { margin-top: 0; margin-bottom: 0; vertical-align: top }=0A= pre { margin-top: 0; margin-bottom: 0; vertical-align: top }=0A= table { margin-top: 0; margin-bottom: 0; vertical-align: top }=0A= h1 { text-align: center }=0A= </style>=0A= <title>SLAPADD</title>=0A= =0A= </head>=0A= <body>=0A= =0A= <h1 align=3D"center">SLAPADD</h1>=0A= =0A= <a href=3D"#NAME">NAME</a> =0A= <a href=3D"#SYNOPSIS">SYNOPSIS</a> =0A= <a href=3D"#DESCRIPTION">DESCRIPTION</a> =0A= <a href=3D"#OPTIONS">OPTIONS</a> =0A= <a href=3D"#LIMITATIONS">LIMITATIONS</a> =0A= <a href=3D"#EXAMPLES">EXAMPLES</a> =0A= <a href=3D"#SEE ALSO">SEE ALSO</a> =0A= <a href=3D"#ACKNOWLEDGEMENTS">ACKNOWLEDGEMENTS</a> =0A= =0A= <hr>=0A= =0A= =0A= <h2>NAME=0A= <a name=3D"NAME"></a>=0A= </h2>=0A= =0A= =0A= slapadd −=0A= Add entries to a SLAPD database=0A= =0A= <h2>SYNOPSIS=0A= <a name=3D"SYNOPSIS"></a>=0A= </h2>=0A= =0A= =0A= =0A= /opt/symas/bin/slapadd=0A= [−b suffix] [−c]=0A= [−d debug-level]=0A= [−f slapd.conf]=0A= [−F confdir] [−g]=0A= [−j lineno]=0A= [−l ldif-file]=0A= [−n dbnum]=0A= [−o option[=3Dvalue]]=0A= [−q] [−s]=0A= [−S SID] [−u]=0A= [−v] [−w]=0A= =0A= <h2>DESCRIPTION=0A= <a name=3D"DESCRIPTION"></a>=0A= </h2>=0A= =0A= =0A= Slapadd=0A= is used to add entries specified in LDAP Directory=0A= Interchange Format (LDIF) to a slapd(8) database. It=0A= opens the given database determined by the database number=0A= or suffix and adds entries corresponding to the provided=0A= LDIF to the database. Databases configured as=0A= subordinate of this one are also updated, unless=0A= −g is specified. The LDIF input is read from=0A= standard input or the specified file.=0A= =0A= All files=0A= eventually created by slapadd will belong to the=0A= identity slapadd is run as, so make sure you either=0A= run slapadd with the same identity slapd(8)=0A= will be run as (see option −u in=0A= slapd(8)), or change file ownership before running=0A= slapd(8).=0A= =0A= Note: slapadd=0A= will also perform the relevant indexing whilst adding the=0A= database if any are configured. For specific details, please=0A= see slapindex(8).=0A= =0A= <h2>OPTIONS=0A= <a name=3D"OPTIONS"></a>=0A= </h2>=0A= =0A= =0A= =0A= −b suffix=0A= =0A= Use the specified suffix=0A= to determine which database to add entries to. The=0A= −b cannot be used in conjunction with the=0A= −n option.=0A= =0A= <table width=3D"100%" border=3D"0" rules=3D"none" frame=3D"void"=0A= cellspacing=3D"0" cellpadding=3D"0">=0A= <tr valign=3D"top" align=3D"left">=0A= <td width=3D"11%"></td>=0A= <td width=3D"3%">=0A= =0A= =0A= −c</td>=0A= <td width=3D"8%"></td>=0A= <td width=3D"56%">=0A= =0A= =0A= enable continue (ignore errors) mode.</td>=0A= <td width=3D"22%">=0A= </td></tr>=0A= </table>=0A= =0A= =0A= −d debug-level=0A= =0A= enable debugging messages as=0A= defined by the specified debug-level; see=0A= slapd(8) for details.=0A= =0A= =0A= −f slapd.conf=0A= =0A= specify an alternative=0A= slapd.conf(5) file.=0A= =0A= =0A= −F confdir=0A= =0A= specify a config directory. If=0A= both −f and −F are specified, the=0A= config file will be read and converted to config directory=0A= format and written to the specified directory. If neither=0A= option is specified, an attempt to read the default config=0A= directory will be made before trying to use the default=0A= config file. If a valid config directory exists then the=0A= default config file is ignored. If dry-run mode is also=0A= specified, no conversion will occur.=0A= =0A= <table width=3D"100%" border=3D"0" rules=3D"none" frame=3D"void"=0A= cellspacing=3D"0" cellpadding=3D"0">=0A= <tr valign=3D"top" align=3D"left">=0A= <td width=3D"11%"></td>=0A= <td width=3D"3%">=0A= =0A= =0A= −g</td>=0A= <td width=3D"8%"></td>=0A= <td width=3D"78%">=0A= =0A= =0A= disable subordinate gluing. Only the specified database=0A= will be processed, and not its glued subordinates (if=0A= any). </td></tr>=0A= </table>=0A= =0A= =0A= −j lineno=0A= =0A= Jump to the specified line=0A= number in the LDIF file before processing any entries. This=0A= allows a load that was aborted due to errors in the input=0A= LDIF to be resumed after the errors are corrected.=0A= =0A= =0A= −l ldif-file=0A= =0A= Read LDIF from the specified=0A= file instead of standard input.=0A= =0A= =0A= −n dbnum=0A= =0A= Add entries to the=0A= dbnum-th database listed in the configuration file.=0A= The −n cannot be used in conjunction with the=0A= −b option. To populate the config database=0A= slapd−config(5), use −n 0 as it is=0A= always the first database. It must physically exist on the=0A= filesystem prior to this, however.=0A= =0A= =0A= −o option[=3D<= i>value]=0A= =0A= Specify an option with=0A= a(n optional) value. Possible generic options/values=0A= are:=0A= =0A= =0A= syslog=3D<subsystems>=0A= (see ’−s’ in slapd(8)) =0A= syslog−level=3D<level> (see ’−S’=0A= in slapd(8)) =0A= syslog−user=3D<user> (see ’−l’=0A= in slapd(8))=0A= =0A= =0A= schema-check=3D{yes|no}=0A= =0A= value-check=3D{yes|no}=0A= =0A= The=0A= schema−check option toggles schema checking=0A= (default on); =0A= the value−check option toggles value checking=0A= (default off). =0A= The latter is incompatible with -q.=0A= =0A= <table width=3D"100%" border=3D"0" rules=3D"none" frame=3D"void"=0A= cellspacing=3D"0" cellpadding=3D"0">=0A= <tr valign=3D"top" align=3D"left">=0A= <td width=3D"11%"></td>=0A= <td width=3D"3%">=0A= =0A= =0A= −q</td>=0A= <td width=3D"8%"></td>=0A= <td width=3D"78%">=0A= =0A= =0A= enable quick (fewer integrity checks) mode. Does fewer=0A= consistency checks</td></tr>=0A= </table>=0A= =0A= on the input data, and no=0A= consistency checks when writing the database. =0A= Improves the load time but if any errors or interruptions=0A= occur the resulting =0A= database will be unusable.=0A= =0A= <table width=3D"100%" border=3D"0" rules=3D"none" frame=3D"void"=0A= cellspacing=3D"0" cellpadding=3D"0">=0A= <tr valign=3D"top" align=3D"left">=0A= <td width=3D"11%"></td>=0A= <td width=3D"3%">=0A= =0A= =0A= −s</td>=0A= <td width=3D"8%"></td>=0A= <td width=3D"78%">=0A= =0A= =0A= disable schema checking. This=0A= option is intended to be used when loading</td></tr>=0A= </table>=0A= =0A= databases containing special=0A= objects, such as fractional objects on a =0A= partial replica. Loading normal objects which do not conform=0A= to =0A= schema may result in unexpected and ill behavior.=0A= =0A= <table width=3D"100%" border=3D"0" rules=3D"none" frame=3D"void"=0A= cellspacing=3D"0" cellpadding=3D"0">=0A= <tr valign=3D"top" align=3D"left">=0A= <td width=3D"11%"></td>=0A= <td width=3D"9%">=0A= =0A= =0A= =0A= −S SID </td>=0A= <td width=3D"2%"></td>=0A= <td width=3D"78%">=0A= =0A= =0A= Server ID to use in generated=0A= entryCSN. Also used for contextCSN</td></tr>=0A= </table>=0A= =0A= if −w is set as=0A= well. Defaults to 0.=0A= =0A= <table width=3D"100%" border=3D"0" rules=3D"none" frame=3D"void"=0A= cellspacing=3D"0" cellpadding=3D"0">=0A= <tr valign=3D"top" align=3D"left">=0A= <td width=3D"11%"></td>=0A= <td width=3D"3%">=0A= =0A= =0A= −u</td>=0A= <td width=3D"8%"></td>=0A= <td width=3D"69%">=0A= =0A= =0A= enable dry-run (don’t=0A= write to backend) mode.</td>=0A= <td width=3D"9%">=0A= </td></tr>=0A= <tr valign=3D"top" align=3D"left">=0A= <td width=3D"11%"></td>=0A= <td width=3D"3%">=0A= =0A= =0A= −v</td>=0A= <td width=3D"8%"></td>=0A= <td width=3D"69%">=0A= =0A= =0A= enable verbose mode.</td>=0A= <td width=3D"9%">=0A= </td></tr>=0A= <tr valign=3D"top" align=3D"left">=0A= <td width=3D"11%"></td>=0A= <td width=3D"3%">=0A= =0A= =0A= −w</td>=0A= <td width=3D"8%"></td>=0A= <td width=3D"69%">=0A= =0A= =0A= write syncrepl context information.</td>=0A= <td width=3D"9%">=0A= </td></tr>=0A= </table>=0A= =0A= After all entries are added,=0A= the contextCSN =0A= will be updated with the greatest CSN in the database.=0A= =0A= <h2>LIMITATIONS=0A= <a name=3D"LIMITATIONS"></a>=0A= </h2>=0A= =0A= =0A= Your=0A= slapd(8) should not be running when you do this to=0A= ensure consistency of the database.=0A= =0A= slapadd=0A= may not provide naming or schema checks. It is advisable to=0A= use ldapadd(1) when adding new entries into an=0A= existing directory.=0A= =0A= <h2>EXAMPLES=0A= <a name=3D"EXAMPLES"></a>=0A= </h2>=0A= =0A= =0A= To import the=0A= entries specified in file ldif into your=0A= slapd(8) database give the command:=0A= =0A= <table width=3D"100%" border=3D"0" rules=3D"none" frame=3D"void"=0A= cellspacing=3D"0" cellpadding=3D"0">=0A= <tr valign=3D"top" align=3D"left">=0A= <td width=3D"8%"></td>=0A= <td width=3D"92%">=0A= =0A= =0A= /opt/symas/bin/slapadd −l ldif</td></tr>=0A= </table>=0A= =0A= <h2>SEE ALSO=0A= <a name=3D"SEE ALSO"></a>=0A= </h2>=0A= =0A= =0A= =0A= ldap(3),=0A= ldif(5), slapcat(8), slapindex(8),=0A= ldapadd(1), slapd(8)=0A= =0A= "OpenLDAP=0A= Administrator’s Guide"=0A= (http://www.OpenLDAP.org/doc/admin/)=0A= =0A= <h2>ACKNOWLEDGEMENTS=0A= <a name=3D"ACKNOWLEDGEMENTS"></a>=0A= </h2>=0A= =0A= =0A= OpenLDAP=0A= Software is developed and maintained by The OpenLDAP=0A= Project <http://www.openldap.org/>. OpenLDAP=0A= Software is derived from the University of Michigan LDAP=0A= 3.3 Release.=0A= <hr>=0A= </body>=0A= </html>=0A= ------=_NextPart_000_020D_01D48C74.C01EDC90--

1 0

Re: (ITS#8941) Font correction in man pages
by hyc＠symas.com 05 Dec '18

05 Dec '18

jtrupp(a)symas.com wrote: > Full_Name: Jason Trupp > Version: 2.4.46 > OS: Ubuntu > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.197.13.194) > > > The impacted man pages contain the following (example) .ft setting in the > "EXAMPLES" section: > > .ft tt > /opt/symas/bin/slapadd \-l ldif > .ft > > "tt" refers to the mono-spaced font "teletype" which is no longer recognized by > groff/troff and modern web browsers. Nonsense. There is no relation between roff language and HTML or web browsers. > The affected man pages include: > ./man8/slapadd.8, ./man8/slapcat.8, ./man8/slapacl.8, ./man8/slaptest.8, > ./man8/slapdn.8, ./man8/slapindex.8, ./man8/slapmodify.8, ./man8/slapd.8, > ./man8/slapschema.8, ./man8/slapauth.8 and ./man5/ldif.5 > > The current verbiage should be replaced by: > > .EX > /opt/symas/bin/slapadd \-l ldif > .EE There are no such macros in my local copy of man macros, which is on a fairly recent (Ubuntu 18) distro. > Please refer to man 7 groff_man for an explanation of these settings. The > replacement syntax has been tested and works as expected. Tested on what platforms? MacOS? BSD? Solaris? What OS revision? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8942) Font correction in man pages
by jtrupp＠symas.com 04 Dec '18

04 Dec '18

Full_Name: Jason Trupp Version: 2.4.46 OS: Ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.197.13.194) The impacted man pages contain the following (example) .ft setting in the "EXAMPLES" section: .ft tt /opt/symas/bin/slapadd \-l ldif .ft "tt" refers to the mono-spaced font "teletype" which is no longer recognized by groff/troff and modern web browsers. The affected man pages include: ./man8/slapadd.8, ./man8/slapcat.8, ./man8/slapacl.8, ./man8/slaptest.8, ./man8/slapdn.8, ./man8/slapindex.8, ./man8/slapmodify.8, ./man8/slapd.8, ./man8/slapschema.8, ./man8/slapauth.8 and ./man5/ldif.5 The current verbiage should be replaced by: .EX /opt/symas/bin/slapadd \-l ldif .EE Please refer to man 7 groff_man for an explanation of these settings. The replacement syntax has been tested and works as expected.

1 0

(ITS#8941) Font correction in man pages
by jtrupp＠symas.com 04 Dec '18

04 Dec '18

Full_Name: Jason Trupp Version: 2.4.46 OS: Ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.197.13.194) The impacted man pages contain the following (example) .ft setting in the "EXAMPLES" section: .ft tt /opt/symas/bin/slapadd \-l ldif .ft "tt" refers to the mono-spaced font "teletype" which is no longer recognized by groff/troff and modern web browsers. The affected man pages include: ./man8/slapadd.8, ./man8/slapcat.8, ./man8/slapacl.8, ./man8/slaptest.8, ./man8/slapdn.8, ./man8/slapindex.8, ./man8/slapmodify.8, ./man8/slapd.8, ./man8/slapschema.8, ./man8/slapauth.8 and ./man5/ldif.5 The current verbiage should be replaced by: .EX /opt/symas/bin/slapadd \-l ldif .EE Please refer to man 7 groff_man for an explanation of these settings. The replacement syntax has been tested and works as expected.

1 0

Re: (ITS#8940) FR: LDAP_AVA_FREE_ATTR in ldapava_free()
by hyc＠symas.com 30 Nov '18

30 Nov '18

Erik Lax wrote: > It's building a custom LDAPDN object from an internal data structure to be used with ldap_dn2str(). The use-case for such flag/pointer ownership for others may > be limited as I suspect not so many build their own LDAPDN objects from scratch. That doesn't matter. You still aren't going to be constructing from an open ended set of RDN attributeTypes. Make them constants and forget about it. > > Regards > Erik > > On 2018-11-30 16:11, Howard Chu wrote: >> Erik Lax wrote: >>> In our case the pointer/allocated string ownership is preferable moved to the LDAPAVA object for both the value and attribute as the char* does not have the >>> same lifetime as the LDAPAVA object. >> Then your app is almost certainly mis-designed. The set of attributeTypes in a schema is always finite >> and usually small; alloc'ing and free'ing the same strings over and over is foolish. >> >> Out of curiosity, what is your software actually trying to do? >>> Regards >>> Erik >>> >>> On 2018-11-30 14:51, Howard Chu wrote: >>>> erik(a)halon.se wrote: >>>>> Full_Name: Erik Lax >>>>> Version: 2.4.46 >>>>> OS: Linux >>>>> URL: >>>>> Submission from: (NULL) (212.85.68.184) >>>>> >>>>> >>>>> Hi, >>>>> >>>>> It's possible to set the flag LDAP_AVA_FREE_VALUE to clear ber values on the >>>>> LDAPAVA structure in ldapava_free() but it's not possible to set the >>>>> LDAP_AVA_FREE_ATTR to clear attributes. I suspect OpenLDAP internals does not >>>>> need to free attributes in this way (hence the missing code). >>>> Attribute Types are usually constant strings, so right, there should be no need to free them. >>>> >>>>> I'm building a custom LDAPAVA (LDAPDN) object and it would be useful to be able >>>>> to set this flags to have it properly clean up both values and attributes in >>>>> ldap_dnfree(). >>>> It would be better to simply avoid the need to free them. >>>> >>> >> > > -- -- Howard Chu CTO, 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#8940) FR: LDAP_AVA_FREE_ATTR in ldapava_free()
by erik＠halon.se 30 Nov '18

30 Nov '18

It's building a custom LDAPDN object from an internal data structure to be used with ldap_dn2str(). The use-case for such flag/pointer ownership for others may be limited as I suspect not so many build their own LDAPDN objects from scratch. Regards Erik On 2018-11-30 16:11, Howard Chu wrote: > Erik Lax wrote: >> In our case the pointer/allocated string ownership is preferable moved to the LDAPAVA object for both the value and attribute as the char* does not have the >> same lifetime as the LDAPAVA object. > Then your app is almost certainly mis-designed. The set of attributeTypes in a schema is always finite > and usually small; alloc'ing and free'ing the same strings over and over is foolish. > > Out of curiosity, what is your software actually trying to do? >> Regards >> Erik >> >> On 2018-11-30 14:51, Howard Chu wrote: >>> erik(a)halon.se wrote: >>>> Full_Name: Erik Lax >>>> Version: 2.4.46 >>>> OS: Linux >>>> URL: >>>> Submission from: (NULL) (212.85.68.184) >>>> >>>> >>>> Hi, >>>> >>>> It's possible to set the flag LDAP_AVA_FREE_VALUE to clear ber values on the >>>> LDAPAVA structure in ldapava_free() but it's not possible to set the >>>> LDAP_AVA_FREE_ATTR to clear attributes. I suspect OpenLDAP internals does not >>>> need to free attributes in this way (hence the missing code). >>> Attribute Types are usually constant strings, so right, there should be no need to free them. >>> >>>> I'm building a custom LDAPAVA (LDAPDN) object and it would be useful to be able >>>> to set this flags to have it properly clean up both values and attributes in >>>> ldap_dnfree(). >>> It would be better to simply avoid the need to free them. >>> >> >

1 0

Re: (ITS#8940) FR: LDAP_AVA_FREE_ATTR in ldapava_free()
by hyc＠symas.com 30 Nov '18

30 Nov '18

Erik Lax wrote: > In our case the pointer/allocated string ownership is preferable moved to the LDAPAVA object for both the value and attribute as the char* does not have the > same lifetime as the LDAPAVA object. Then your app is almost certainly mis-designed. The set of attributeTypes in a schema is always finite and usually small; alloc'ing and free'ing the same strings over and over is foolish. Out of curiosity, what is your software actually trying to do? > > Regards > Erik > > On 2018-11-30 14:51, Howard Chu wrote: >> erik(a)halon.se wrote: >>> Full_Name: Erik Lax >>> Version: 2.4.46 >>> OS: Linux >>> URL: >>> Submission from: (NULL) (212.85.68.184) >>> >>> >>> Hi, >>> >>> It's possible to set the flag LDAP_AVA_FREE_VALUE to clear ber values on the >>> LDAPAVA structure in ldapava_free() but it's not possible to set the >>> LDAP_AVA_FREE_ATTR to clear attributes. I suspect OpenLDAP internals does not >>> need to free attributes in this way (hence the missing code). >> Attribute Types are usually constant strings, so right, there should be no need to free them. >> >>> I'm building a custom LDAPAVA (LDAPDN) object and it would be useful to be able >>> to set this flags to have it properly clean up both values and attributes in >>> ldap_dnfree(). >> It would be better to simply avoid the need to free them. >> > > -- -- Howard Chu CTO, 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#8940) FR: LDAP_AVA_FREE_ATTR in ldapava_free()
by erik＠halon.se 30 Nov '18

30 Nov '18

In our case the pointer/allocated string ownership is preferable moved to the LDAPAVA object for both the value and attribute as the char* does not have the same lifetime as the LDAPAVA object. Regards Erik On 2018-11-30 14:51, Howard Chu wrote: > erik(a)halon.se wrote: >> Full_Name: Erik Lax >> Version: 2.4.46 >> OS: Linux >> URL: >> Submission from: (NULL) (212.85.68.184) >> >> >> Hi, >> >> It's possible to set the flag LDAP_AVA_FREE_VALUE to clear ber values on the >> LDAPAVA structure in ldapava_free() but it's not possible to set the >> LDAP_AVA_FREE_ATTR to clear attributes. I suspect OpenLDAP internals does not >> need to free attributes in this way (hence the missing code). > Attribute Types are usually constant strings, so right, there should be no need to free them. > >> I'm building a custom LDAPAVA (LDAPDN) object and it would be useful to be able >> to set this flags to have it properly clean up both values and attributes in >> ldap_dnfree(). > It would be better to simply avoid the need to free them. >

1 0

Re: (ITS#8940) FR: LDAP_AVA_FREE_ATTR in ldapava_free()
by hyc＠symas.com 30 Nov '18

30 Nov '18

erik(a)halon.se wrote: > Full_Name: Erik Lax > Version: 2.4.46 > OS: Linux > URL: > Submission from: (NULL) (212.85.68.184) > > > Hi, > > It's possible to set the flag LDAP_AVA_FREE_VALUE to clear ber values on the > LDAPAVA structure in ldapava_free() but it's not possible to set the > LDAP_AVA_FREE_ATTR to clear attributes. I suspect OpenLDAP internals does not > need to free attributes in this way (hence the missing code). Attribute Types are usually constant strings, so right, there should be no need to free them. > I'm building a custom LDAPAVA (LDAPDN) object and it would be useful to be able > to set this flags to have it properly clean up both values and attributes in > ldap_dnfree(). It would be better to simply avoid the need to free them. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8940) FR: LDAP_AVA_FREE_ATTR in ldapava_free()
by erik＠halon.se 30 Nov '18

30 Nov '18

Full_Name: Erik Lax Version: 2.4.46 OS: Linux URL: Submission from: (NULL) (212.85.68.184) Hi, It's possible to set the flag LDAP_AVA_FREE_VALUE to clear ber values on the LDAPAVA structure in ldapava_free() but it's not possible to set the LDAP_AVA_FREE_ATTR to clear attributes. I suspect OpenLDAP internals does not need to free attributes in this way (hence the missing code). I'm building a custom LDAPAVA (LDAPDN) object and it would be useful to be able to set this flags to have it properly clean up both values and attributes in ldap_dnfree(). https://github.com/openldap/openldap/blob/master/libraries/libldap/getdn.c#…

1 0

(ITS#8939) back-sql broken, backsql_oc_get_attr_mapping() fails
by jl＠conductive.de 25 Nov '18

25 Nov '18

Full_Name: Joel Linn Version: 2.4.45 as well as git OS: Ubuntu (docker image) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.120.2.83) Hi, I wanted to use back-sql and tried against our Firebird database, as that didn't work i spun up a Postgres container with the data from the sources. For both cases it seems the backend is broken as it reports empty fields when loading the attribute mappings, although they are definetly not empty: 5bfaced6 backsql_oc_get_attr_mapping(): executing at_query "SELECT sel_expr_u,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,name FROM ldap_attr_mappings WHERE oc_map_id=?" for objectClass "document" with param oc_id=2 5bfaced6 backsql_oc_get_attr_mapping(): required column #0 "name" is empty I played with the sources (moved the snprintf/DEBUG code before the field checking section that generates the error, around line 370 in schema-map.c) and found out that the first 3 columns are always null, you can confirm that by defining the at_query in slapd.conf and swapping the field names around. My guess is the binding in backsql_BindRowAsStrings is faulty. As I said i tried two different ODBC drivers. full log https://pastebin.com/4B2wjCLp configuration https://pastebin.com/JMwVVMDx

1 0

Re: (ITS#8938) ldap 2.4.40 replication
by michael＠stroeder.com 19 Nov '18

19 Nov '18

On 11/19/18 11:43 AM, p.vorkas(a)live.com wrote: > Its now been a month and i still couldn't find a way to create a replication > server. > I have transferred my old db from previous version of ldap. everything works > just fine except the replication part. > > i tried synproc etc but nothing.. does any one has some idea about that? The ITS is only used for reporting bugs. In general you should follow instructions in the OpenLDAP admin guide: https://www.openldap.org/doc/admin24/replication.html For asking usage questions please subscribe to openldap-technical mailing list and post your question there: https://www.openldap.org/lists/mm/listinfo/openldap-technical You should describe what you want to achieve, the exact version you're using, OS platform, the config you've tried and some relevant log excerpts if available. Ciao, Michael.

1 0

(ITS#8938) ldap 2.4.40 replication
by p.vorkas＠live.com 19 Nov '18

19 Nov '18

Full_Name: Panayiotis V Version: 2.4.40 OS: centos 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.116.198.226) Its now been a month and i still couldn't find a way to create a replication server. I have transferred my old db from previous version of ldap. everything works just fine except the replication part. i tried synproc etc but nothing.. does any one has some idea about that? thanks

1 0

Re: (ITS#8928) Reproducibility: Remove user, hostname, pwd from version string
by hyc＠symas.com 19 Nov '18

19 Nov '18

douglas.royds(a)taitradio.com wrote: > URL: ftp://ftp.openldap.org/incoming/douglas-royds-181120.patch > > > On 19/11/18 12:34 PM, Howard Chu wrote: > >> Thanks. According to this link, we shouldn't even need the date/time portion >> of this patch. >> >> Under the section "Reading the Variable" we have >>> gcc (>= 7, Debian >= 5.3.1-17, Debian >= 6.1.1-1) >> https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=e3e8c48c4a494d9da741c1c8e… >> >> I.e., gcc itself will set __DATE__ and __TIME__ accordingly if SOURCE_DATE_EPOCH is set. >> >> I'm inclined to just tweak WHOWHERE and let gcc handle the rest. > > > Once again, good point. I have removed the date and time changes from > the patch, and only kept the WHOWHERE change, still using the existence > of a SOURCE_DATE_EPOCH to decide whether to fix the string or not. > Thanks. Added to master. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs