openldap-bugs August 2017

openldap-bugs@openldap.org

19 participants
52 discussions

Re: (ITS#8707) slapd: Add systemd service notification support
by fumiyas＠osstech.co.jp 07 Aug '17

07 Aug '17

Hi, Sorry, I'm not good at English. :-) On Tue, 08 Aug 2017 05:12:02 +0900, Ryan Tandy wrote: > > I guess MAINPID= is actually needed, unless we run slapd with -d, regardless of > > whether we set Type=forking or Type=notify. Not exactly "needed", but better to > > have it than not. > > I experimented a bit with a service file. It seems to work well with either Type=forking and NotifyAccess=all, or Type=notify and ExecStart=slapd -d none. The latter (disabling forking) is definitely what systemd upstream recommends. I think so too. I don't like forking, thus I use "Type=notify" and "ExecStart=slapd -d0 ..." in my slapd.service file. > In either case, MAINPID= didn't actually seem to help anything. Yes. > NotifyAccess=main has a chicken-and-egg problem, because systemd needs to know the main PID in order for us to send it the message containing the PID! :) I think the only reasonable way to leave forking enabled would be to also require a PIDFile= setting, which solves that problem. But I'd rather sidestep the entire thing, omit MAINPID= as well, and > Looking at the systemctl output I still think STATUS= is redundant and could be omitted. > > So I guess my recommendation for the notify call boils down to: > > rc = sd_notify( 1, "READY=1" ); Agreed. I'll fix servers/slapd/daemon.c later. Thank you. > and a slapd.service along the lines of: > > [Unit] > Description=OpenLDAP server > > [Service] > Type=notify > ExecStart=%LIBEXECDIR%/slapd -h 'ldap:/// ldapi:///' -d0 > > [Install] > WantedBy=multi-user.target > > (basically identical to the example in systemd.service(5).) My slapd.service file: [Unit] Description=OpenLDAP Server After=syslog.target network-online.target Documentation=man:slapd Documentation=man:slapd.conf Documentation=man:slapd-config Documentation=man:slapd-bdb Documentation=man:slapd-hdb Documentation=man:slapd-mdb [Service] Type=notify ExecStart=%LIBEXECDIR%/slapd -d 0 -h "ldapi:/// ldap:///" [Install] WantedBy=multi-user.target Any comment? -- -- Name: SATOH Fumiyasu @ OSS Technology Corp. (fumiyas @ osstech co jp) -- Business Home: http://www.OSSTech.co.jp/ -- GitHub Home: https://GitHub.com/fumiyas/ -- PGP Fingerprint: BBE1 A1C9 525A 292E 6729 CDEC ADC2 9DCA 5E1C CBCA

1 0

Re: (ITS#8707) slapd: Add systemd service notification support
by ryan＠nardis.ca 07 Aug '17

07 Aug '17

On Mon, Aug 07, 2017 at 01:12:02PM -0700, Ryan Tandy wrote: >Side note: the version message from slapd appears in the journal >twice, once with the timestamp and once without... not sure exactly >why! Sorry, meant to delete this paragraph before sending. The difference between "-dnone" and "-d0" is precisely an extra log to stderr :)

1 0

Re: (ITS#8707) slapd: Add systemd service notification support
by ryan＠nardis.ca 07 Aug '17

07 Aug '17

On Mon, Aug 07, 2017 at 12:23:27PM -0700, Ryan Tandy wrote: >I guess MAINPID= is actually needed, unless we run slapd with -d, regardless of >whether we set Type=forking or Type=notify. Not exactly "needed", but better to >have it than not. I experimented a bit with a service file. It seems to work well with either Type=forking and NotifyAccess=all, or Type=notify and ExecStart=slapd -d none. The latter (disabling forking) is definitely what systemd upstream recommends. In either case, MAINPID= didn't actually seem to help anything. NotifyAccess=main has a chicken-and-egg problem, because systemd needs to know the main PID in order for us to send it the message containing the PID! :) I think the only reasonable way to leave forking enabled would be to also require a PIDFile= setting, which solves that problem. But I'd rather sidestep the entire thing, omit MAINPID= as well, and Looking at the systemctl output I still think STATUS= is redundant and could be omitted. So I guess my recommendation for the notify call boils down to: rc = sd_notify( 1, "READY=1" ); and a slapd.service along the lines of: [Unit] Description=OpenLDAP server [Service] Type=notify ExecStart=%LIBEXECDIR%/slapd -h 'ldap:/// ldapi:///' -d0 [Install] WantedBy=multi-user.target (basically identical to the example in systemd.service(5).) Side note: the version message from slapd appears in the journal twice, once with the timestamp and once without... not sure exactly why!

1 0

Re: (ITS#8707) slapd: Add systemd service notification support
by ryan＠nardis.ca 07 Aug '17

07 Aug '17

On Mon, Aug 07, 2017 at 01:30:44PM +0000, fumiyas(a)osstech.co.jp wrote: >I've created patches for slapd to add systemd service notification >(sd_notify(3)) support. Thanks for working on this! I'm also interested in having this feature. What do you think about including a slapd.service file? I know OpenLDAP has traditionally not included an init script, but systemd units are intended to be distro-agnostic as far as possible, and shipped by upstream projects in most cases, unlike init scripts. Ideally I'd like to include a template in the source and have the build system fill in the autoconf'ed path (i.e. to slapd) and have 'make install' install it to the right place. Autoconf bits look fine to me. >+ rc = sd_notifyf( 1, >+ "READY=1\n" >+ "STATUS=slapd: ready to serve connections...\n" >+ "MAINPID=%lu", >+ (unsigned long) getpid() ); unset_environment=1 seems reasonable, it's a little unfortunate that we can't call (for example) sd_notify("STOPPING=1") afterward, but it feels worthwhile compared to having to sanitize the environment when forking a child process. I'm not sure the STATUS= message adds value compared to just the basic readiness notification; can you comment on why you included it? I guess MAINPID= is actually needed, unless we run slapd with -d, regardless of whether we set Type=forking or Type=notify. Not exactly "needed", but better to have it than not. I see you've placed this call later than the parent's exit point. Any comments about the timing of this relative to the parent's exit, and to the listener startup and so on? Are the listeners more likely to be ready to serve connections at this point? I seem to recall that in the past there was opposition to moving the parent's exit later, but I can't remember why. (and I still wish we could do that, and dispense with the ldapsearch-loop hacks...) cheers, Ryan

1 0

(ITS#8707) slapd: Add systemd service notification support
by fumiyas＠osstech.co.jp 07 Aug '17

07 Aug '17

Full_Name: SATOH Fumiyasu Version: master OS: URL: Submission from: (NULL) (118.240.43.13) I've created patches for slapd to add systemd service notification (sd_notify(3)) support. Please see the following URLs: * Patch for master * https://github.com/osstech-jp/openldap/commit/4313f8685ac3365fe71639d378740… * Patch for 2.4.x (OPENLDAP_REL_ENG_2_4) * https://github.com/osstech-jp/openldap/commit/977d4483470d150839714cece64ae…

1 0

Re: (ITS#8706) illogical return from ldap_search_ext_s()
by hyc＠symas.com 04 Aug '17

04 Aug '17

kurt.w.heberlein(a)hpe.com wrote: > Full_Name: Kurt Heberlein > Version: 2.4.40+patches > OS: Debian Wheezy > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (66.168.54.228) > > > Using simple binding with TLS, i have a successfully bound (authenticated) user, > and using the same LDAP*, i experience intermittent failures attempting to > retrieve the user's memberOf list. The failure manifests itself as a return > from ldap_search_ext_s() with a return code of LDAP_SUCCESS but a NULL results > pointer. > > Most of the time this call correctly returns the list of groups the user is a > member of, but intermittently it returns a NULL list even though the return code > is LDAP_SUCCESS. There is no other error indication. What am i missing? Read RFC 4511. The ITS is for bug reports, not technical questions. There's no bug here. Closing this ITS. -- -- 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#8706) illogical return from ldap_search_ext_s()
by kurt.w.heberlein＠hpe.com 04 Aug '17

04 Aug '17

Full_Name: Kurt Heberlein Version: 2.4.40+patches OS: Debian Wheezy URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (66.168.54.228) Using simple binding with TLS, i have a successfully bound (authenticated) user, and using the same LDAP*, i experience intermittent failures attempting to retrieve the user's memberOf list. The failure manifests itself as a return from ldap_search_ext_s() with a return code of LDAP_SUCCESS but a NULL results pointer. Most of the time this call correctly returns the list of groups the user is a member of, but intermittently it returns a NULL list even though the return code is LDAP_SUCCESS. There is no other error indication. What am i missing? The call looks like this: ret = ldap_search_ext_s(lp, base, scope, filter, attrs, 0, NULL, NULL, NULL, -1, &res); if(ret != LDAP_SUCCESS) { ... } else { assert(res != NULL); for(msg = ldap_first_message(lp, res); msg != NULL; msg = ldap_next_message(lp, msg)) { ... Where lp is the LDAP* pointer of for the successful bind of user base = "DC=EMEA,DC=AD,DC=SOMECOMPANY,DC=COM" scope = LDAP_SCOPE_SUBTREE filter = "(&(objectClass=user)(sAMAccountName=someusername))" attrs = attrs[0] = "memberOf" attrs[0] = NULL i dont find any documentation that indicates that res could be NULL after LDAP_SUCCESS is returned from the search. Thanks

1 0

Re: (ITS#8690) syncprov memory leak
by quanah＠symas.com 03 Aug '17

03 Aug '17

--On Tuesday, August 01, 2017 8:33 PM +0000 quanah(a)symas.com wrote: > With the patch applied, test019 sporadically segfaults after doing a > delete op on an entry. Took me 12/50 iterations with back-mdb, 2/50 > with back-bdb. But just 1/1 on two other occasions, so while it's not > every iteration, it's fairly repeatable. I will work on getting a > backtrace as well. With the current code, test050 sporadically fails (Took me 8/50 iterations): 5983d09b do_syncrep2: rid=012 cookie=rid=012,sid=002,csn=20170804014043.003558Z#000000#003#000000 5983d09b bdb_delete: deleted id=00000018 dn="cn=To be deleted by server 3,dc=example,dc=com" 5983d09b send_ldap_result: conn=-1 op=0 p=0 5983d09b send_ldap_result: err=0 matched="" text="" 5983d09b syncprov_sendresp: to=002, cookie=rid=011,sid=001,csn=20170804014043.003558Z#000000#003#000000 5983d09b => send_search_entry: conn 1012 dn="cn=To be deleted by server 3,dc=example,dc=com" ber_flush2: 175 bytes to sd 26 5983d09b <= send_search_entry: conn 1012 exit. 5983d09b slap_graduate_commit_csn: removing 0x7f93ac113800 20170804014043.003558Z#000000#003#000000 5983d09b syncrepl_entry: rid=013 be_delete cn=To be deleted by server 3,dc=example,dc=com (0) 5983d09b slap_queue_csn: queueing 0x7f93ac107860 20170804014043.003558Z#000000#003#000000 5983d09b bdb_modify: dc=example,dc=com 5983d09b bdb_modify: txn1 id: 8000004e 5983d09b bdb_dn2entry("dc=example,dc=com") 5983d09b bdb_modify: txn2 id: 8000004f 5983d09b bdb_modify_internal: 0x00000001: dc=example,dc=com 5983d09b bdb_modify_internal: replace contextCSN 5983d09b => entry_encode(0x00000001): dc=example,dc=com 5983d09b <= entry_encode(0x00000001): dc=example,dc=com 5983d09b syncprov_sendresp: to=004, cookie=rid=011,sid=001,csn= 5983d09b slap_build_sync_ctrl: ber_flatten2 failed (-1) 5983d09b send_ldap_result: conn=1013 op=1 p=3 5983d09b send_ldap_result: err=80 matched="" text="internal error" 5983d09b send_ldap_response: msgid=2 tag=101 err=80 ber_flush2: 146 bytes to sd 30 5983d09b conn=1013 op=1 SEARCH RESULT tag=101 err=80 duration=-1427710511.244ms nentries=0 text=internal error Aug 3 18:40:43 ub16 kernel: [42374.949965] slapd[30897]: segfault at 8000004e ip 00007f93bccb5cc0 sp 00007f93ba1aaa10 error 4 in libc-2.23.so[7f93bcc67000+1c0000] --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8705) Windows registry key creation incorrect
by quanah＠openldap.org 02 Aug '17

02 Aug '17

Full_Name: Quanah Gibson-Mount Version: 2.4.45 OS: Windows 10 64-bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) When installing OpenLDAP on windows, it creates a registry key for the Eventlog to map startup/shutdown events. There was an attempt to fix the problem with the key value back in 2003, 6e8adce9d94ffff125d6acce669c35245d73d0df. However, the fix is incorrect. Without 6e8adce9d94ffff125d6acce669c35245d73d0df, the key value is set to (on a 64-bit install): "C:\Program Files\OpenLDAP\slapd.exe service" With 6e8adce9d94ffff125d6acce669c35245d73d0df, the key value is set to (on a 64-bit install): "C:\Program" The value that works is: "C:\Program Files\OpenLDAP\slapd.exe" The goal of 6e8adce9d94ffff125d6acce669c35245d73d0df was to strip of " service", but since it simply parses on a single space, if the install path has a space elsewhere in it, you end up with the incorrect value noted above.

1 0

Re: (ITS#8701) account usability control for password less logins
by benjamin.chang＠oracle.com 02 Aug '17

02 Aug '17

Question about a proposed workaround: Would it be possible to use slapo-ppolicy to set the pwdPolicySubentry attribute for each user to provide the desired 1.3.6.1.4.1.42.2.27.9.5.8 control response (see http://ldapwiki.com/wiki/Account%20Usability%20Request%20Control), i.e., can pwdPolicySubentry be used supply the sub-entry and related operational attributes needed to validate users for password-less logins?

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs August 2017