- openldap-bugs - openldap.org

(ITS#6247)
by daniel＠pluta.biz 09 May '10

09 May '10

An updated version of the patch can be downloaded from here: ftp://ftp.openldap.org/incoming/daniel-pluta-100509.patch

1 0

(ITS#6547) config.guess needs updating
by panth13＠gmail.com 07 May '10

07 May '10

Full_Name: Bryan Stopp Version: 2.4.21 OS: AIX6.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (65.197.28.158) The latest version of the config.guess that is bundled with the source is about 5 years out of date. It doesn't pick up new operating systems (specifically AIX6.? in my case). Can someone grab the latest from GNU? (http://cvs.savannah.gnu.org/viewvc/config/config/config.guess) -B

1 0

(ITS#6546) Default olcRootDN of "cn=config" should be documented
by bugs＠mark.ziesemer.com 07 May '10

07 May '10

Full_Name: Mark A. Ziesemer Version: 2.4.21 OS: Ubuntu Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:470:1f11:3ae:4d06:cdd1:50ce:9c64) While using the "cn=config" configuration, I found that "cn=config" is also the default olcRootDN. By just configuring a olcRootPW , login to the config database is possible using "cn=config" and the configured olcRootPW. This default should be documented in the admin guide, etc. IRC user hyc on #openldap mentioned "it's been the default since 2005", but "I can't find the reference either, perhaps we lost it."

1 0

Re: (ITS#6545) delta-syncrepl rejects modification master accepted
by Frank.Swasey＠uvm.edu 06 May '10

06 May '10

On 5/6/10 3:18 PM, Quanah Gibson-Mount wrote: > Can you please show the contents of the accesslog databsae for this > change? dn: reqStart=20100506114012.000002Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20100506114012.000002Z reqEnd: 20100506114012.000003Z reqType: modify reqSession: 1006 reqAuthzID: cn=manager,dc=uvm,dc=edu reqDN: uid=fcswasey,ou=People,dc=uvm,dc=edu reqResult: 0 reqMod: sn:= Swasey reqMod: sn:= Swasey reqMod: entryCSN:= 20100506114012.200297Z#000000#000#000000 reqMod: modifiersName:= cn=manager,dc=uvm,dc=edu reqMod: modifyTimestamp:= 20100506114012Z entryUUID: 7ba18504-6f3b-450a-8420-a101ba6b76c5 creatorsName: cn=accesslog createTimestamp: 20100506114012Z entryCSN: 20100506114012.200297Z#000000#000#000000 modifiersName: cn=accesslog modifyTimestamp: 20100506114012Z entryDN: reqStart=20100506114012.000002Z,cn=accesslog subschemaSubentry: cn=Subschema hasSubordinates: FALSE -- Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900)

1 0

Re: (ITS#6545) delta-syncrepl rejects modification master accepted
by quanah＠zimbra.com 06 May '10

06 May '10

--On Wednesday, May 05, 2010 5:37 PM +0000 Frank.Swasey(a)uvm.edu wrote: > Full_Name: Francis Swasey > Version: 2.4.22 > OS: Red Hat Enterprise Linux 5 update 5 64-bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (132.198.107.64) > > > Platform: Red Hat Enterprise Linux 5, update 5, 64-bit > OpenLDAP: 2.4.22 (locally compiled), configured with delta-syncrepl. > > The following modify ldif successfully applies to the master: > > dn: uid=fcswasey,ou=People,dc=uvm,dc=edu > changetype: modify > replace: sn > sn: Swasey > - > replace: sn > sn: Swasey > - > > syncrepl_message_to_op: rid=100 mods check (sn: value #0 provided more > than once) Can you please show the contents of the accesslog databsae for this change? Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6545) delta-syncrepl rejects modification master accepted
by Frank.Swasey＠uvm.edu 05 May '10

05 May '10

Full_Name: Francis Swasey Version: 2.4.22 OS: Red Hat Enterprise Linux 5 update 5 64-bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (132.198.107.64) Platform: Red Hat Enterprise Linux 5, update 5, 64-bit OpenLDAP: 2.4.22 (locally compiled), configured with delta-syncrepl. The following modify ldif successfully applies to the master: dn: uid=fcswasey,ou=People,dc=uvm,dc=edu changetype: modify replace: sn sn: Swasey - replace: sn sn: Swasey - In OpenLDAP 2.3 -- this modify ldif deck failed because the "sn" attribute is presented twice. In OpenLDAP 2.4 -- it works, but the delta-syncrepl replica pukes on it with this error: syncrepl_message_to_op: rid=100 mods check (sn: value #0 provided more than once)

1 0

Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
by ryans＠aweber.com 05 May '10

05 May '10

I made an important discovery this morning (with a fresh set of eyes...): without Pierangelo's patch, chaining does *NOT* work, as originally stated. So, the patch does fix the broken test that started this ITS, making it both valid and absolutely necessary, but alas, the functionality of the chaining configuration is the same with both the patched and unpatched package: the DN is not being passed through, so the automatic chasing of the referral does not work. Here is an example with ldapvi: ### Command issued on slave to change one attribute of user uid=ryans,ou=Users,dc=example,dc=com ryans@slave:~# ldapvi --ldap-conf --starttls -h localhost --bind=simple -D cn=admin,dc=example,dc=com -w `cat /etc/ldap.secret` --discover 159 entries read add: 0, rename: 0, modify: 1, delete: 0 Action? [yYqQvVebB*rsf+?] y Received referral to ldap://ldapmaster.example.com/uid=ryans,ou=Users,dc=example,dc=com. You are not logged in to ldap://ldapmaster.example.com:389 yet. Type '!' or 'y' to do so. Rebind? [y!nB*qQ?] ### Logs on slave generated by ldapvi command May 5 10:27:04 slave slapd[30408]: conn=44 fd=41 ACCEPT from IP=127.0.0.1:34118 (IP=0.0.0.0:389) May 5 10:27:04 slave slapd[30408]: conn=44 op=0 EXT oid=1.3.6.1.4.1.1466.20037 May 5 10:27:04 slave slapd[30408]: conn=44 op=0 STARTTLS May 5 10:27:04 slave slapd[30408]: conn=44 op=0 RESULT oid= err=0 text= May 5 10:27:04 slave slapd[30408]: conn=44 fd=41 TLS established tls_ssf=128 ssf=128 May 5 10:27:04 slave slapd[30408]: conn=44 op=1 BIND dn="cn=admin,dc=example,dc=com" method=128 May 5 10:27:04 slave slapd[30408]: conn=44 op=1 BIND dn="cn=admin,dc=example,dc=com" mech=SIMPLE ssf=0 May 5 10:27:04 slave slapd[30408]: conn=44 op=1 RESULT tag=97 err=0 text= May 5 10:27:04 slave slapd[30408]: conn=44 op=2 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" May 5 10:27:04 slave slapd[30408]: conn=44 op=2 SRCH attr=+ * May 5 10:27:04 slave slapd[30408]: conn=44 op=2 ENTRY dn="" May 5 10:27:04 slave slapd[30408]: conn=44 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= May 5 10:27:04 slave slapd[30408]: conn=44 op=3 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(objectClass=*)" May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY dn="dc=example,dc=com" May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY dn="cn=admin,dc=example,dc=com" May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY dn="ou=users,dc=example,dc=com" May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY dn="ou=groups,dc=example,dc=com" May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY dn="uid=xxxxx,ou=users,dc=example,dc=com" May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY dn="uid=ryans,ou=users,dc=example,dc=com" May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY dn="uid=xxxxx,ou=users,dc=example,dc=com" May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY dn="cn=xxxxx,ou=groups,dc=example,dc=com" May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY dn="cn=ryans,ou=groups,dc=example,dc=com" May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY dn="cn=xxxxxx,ou=groups,dc=example,dc=com" May 5 10:27:04 slave slapd[30408]: conn=44 op=3 SEARCH RESULT tag=101 err=0 nentries=159 text= May 5 10:27:22 slave slapd[30408]: conn=44 op=4 MOD dn="uid=ryans,ou=Users,dc=example,dc=com" May 5 10:27:22 slave slapd[30408]: conn=44 op=4 MOD attr=displayColor May 5 10:27:22 slave slapd[30408]: conn=44 op=4 RESULT tag=103 err=10 text= The referral is generated (err=10), and sent to the master, and here's what the logs there look like: ### Logs on master generated by referral May 5 10:43:04 ldap1 slapd[8794]: conn=402475 fd=273 ACCEPT from IP=10.0.1.196:43376 (IP=0.0.0.0:389) May 5 10:43:04 ldap1 slapd[8794]: conn=402475 op=0 BIND dn="" method=128 May 5 10:43:04 ldap1 slapd[8794]: conn=402475 op=0 RESULT tag=97 err=0 text= May 5 10:43:04 ldap1 slapd[8794]: conn=402475 op=1 MOD dn="uid=ryans,ou=Users,dc=example,dc=com" May 5 10:43:04 ldap1 slapd[8794]: conn=402475 op=1 MOD attr=displayColor May 5 10:43:04 ldap1 slapd[8794]: conn=402475 op=1 RESULT tag=103 err=8 text=modifications require authentication May 5 10:43:04 ldap1 slapd[8794]: conn=402475 op=2 UNBIND May 5 10:43:04 ldap1 slapd[8794]: conn=402475 fd=273 closed May 5 10:43:04 ldap1 slapd[8794]: conn=402476 fd=273 ACCEPT from IP=10.0.1.196:43377 (IP=0.0.0.0:389) As you can see, the DN is empty. It might be worth mentioning that I have tried the olcDbURI with dotted-quads, hostnames, and with and without quotes, and the value portions of the attr=value pairs in the olcDbIDAssertBind attribute with and without quotes, to no avail, though I did not expect it to. I have also tried with and without TLS (my configuration supports both) in the chaining configuration, and explicitly with olcDbChaseReferrals set to TRUE, though that should be the default. I've also tried with and without proxy authz (authzTo/authzFrom) in a vain attempt to get this working, as is mentioned above in this ITS (because it is referenced in the Admin Guide section on chaining), but that too failed. However, most of this would seem unnecessary since test022-ppolicy does almost none of them, although that test was recently patched to detect the bug fixed by Pierangelo's patch so it may not be an ironclad example. But since there's no other officially documented example of setting up chaining with cn=config, it's really all the community has to go on. Again, for reference, the most recent configuration used is provided below: 1 cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}back_hdb.la olcModuleLoad: {1}autogroup.la olcModuleLoad: {2}back_ldap.la 20 olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain 21 olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbURI: "ldap://10.1.1.164:389" olcDbStartTLS: start olcDbIDAssertBind: bindmethod="simple" binddn="cn=admin,dc=example,dc=com" credentials="secret" mode="self" olcDbChaseReferrals: TRUE If you want an example using an officially distributed tool, or one that doesn't handle referrals, here it is, using ldappasswd: ### Command issued on slave ryans@slave:~# ldappasswd -h localhost uid=ryans,ou=Users,dc=example,dc=com New password: Re-enter new password: Enter LDAP Password: Result: Strong(er) authentication required (8) Additional info: only authenticated users may change passwords ### Slave side logs using ldappasswd May 5 10:30:47 slave slapd[30408]: conn=47 fd=41 ACCEPT from IP=127.0.0.1:32947 (IP=0.0.0.0:389) May 5 10:30:47 slave slapd[30408]: conn=47 op=0 EXT oid=1.3.6.1.4.1.1466.20037 May 5 10:30:47 slave slapd[30408]: conn=47 op=0 STARTTLS May 5 10:30:47 slave slapd[30408]: conn=47 op=0 RESULT oid= err=0 text= May 5 10:30:47 slave slapd[30408]: conn=47 fd=41 TLS established tls_ssf=128 ssf=128 May 5 10:30:47 slave slapd[30408]: conn=47 op=1 BIND dn="uid=ryans,ou=Users,dc=example,dc=com" method=128 May 5 10:30:47 slave slapd[30408]: conn=47 op=1 BIND dn="uid=ryans,ou=Users,dc=example,dc=com" mech=SIMPLE ssf=0 May 5 10:30:47 slave slapd[30408]: conn=47 op=1 RESULT tag=97 err=0 text= May 5 10:30:47 slave slapd[30408]: conn=47 op=2 EXT oid=1.3.6.1.4.1.4203.1.11.1 May 5 10:30:47 slave slapd[30408]: conn=47 op=2 PASSMOD id="uid=ryans,ou=Users,dc=example,dc=com" new May 5 10:30:47 slave slapd[30408]: conn=47 op=2 RESULT oid= err=8 text=only authenticated users may change passwords

1 0

(ITS#6544) how to implement password policy
by dsbrar16＠yahoo.com 05 May '10

05 May '10

Full_Name: Devender Singh Version: openldap 2.4.16 OS: RHEL5.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (122.177.190.226) Hello Dear, Please let me know, how to implement ppolicy in openldap2.4.16. I am using RHEL5.4 I have followed below steps on installation time: ************************************************** Installing BerkeleyDB ************************************************** 1) Create build_unix directory in /opt directory 2) Copy db-4.7.25.tar.gz to /opt/build_unix directory 3) Goto /opt/build_unix directory 4) gzip -d db-4.7.25.tar.gz 5) tar xvf db-4.7.25.tar 6) db-4.7.25/dist/configure 7) make 8) make install 9) vi /root/.bash_profile 10) Add below lines in .bash_profile of root user export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/BerkeleyDB.4.7/lib export LD_RUN_PATH=$LD_RUN_PATH:/usr/local/BerkeleyDB.4.7/lib 11) Close existing PUTTY and start new PUTTY ************************************************** Before Installation check the below packages: #rpm qa|grep openssl* After the above command if you dont find the all openssl packages than install them via yum command ************************************************** Installing OpenLDAP ************************************************** 1) Copy openldap-stable-20090411.tgz to /opt directory 2) gunzip -c openldap-stable-20090411.tgz | tar xf - 3) cd openldap-2.4.16 4) CPPFLAGS="-I/usr/local/BerkeleyDB.4.7/include -I/usr/local/ssl/include/openssl" 5) export CPPFLAGS 6) LDFLAGS="-L/usr/local/lib -L/usr/local/BerkeleyDB.4.7/lib -L/usr/local/ssl/lib -R/usr/local/lib -R/usr/local/BerkeleyDB.4.7/lib -R/usr/local/ssl/lib" 7) export LDFLAGS 8) LD_LIBRARY_PATH="/usr/local/BerkeleyDB.4.7/lib" 9) export LD_LIBRARY_PATH 10) ./configure 11) make depend 12) make 13) make install 14) vi /root/.bash_profile 15) Add OpenLDAP sbin path in .bash_profile of root user (E.g. export PATH=$PATH:$HOME/bin:/usr/local/sbin) 16) Close existing PUTTY and start new PUTTY ************************************************** Thanks in Advance. Regards, Devender Singh (+919818107222)

1 0

Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
by ryans＠aweber.com 04 May '10

04 May '10

Ryan Steele wrote: > Actually, it would appear I'm hitting the same problem as the OP in this thread: > > http://markmail.org/message/fhfhzy5uehh6e4us#query:openldap chain "modifications require > authentication"+page:1+mid:fhfhzy5uehh6e4us+state:results > > > I say that because when I get prompted for authentication by the slave (instead of having the referral handled > server-side), I see this corresponding entry in the master's logs: > > May 4 12:22:43 ldap1 slapd[8794]: conn=226810 fd=50 ACCEPT from IP=10.x.x.x:45081 (IP=0.0.0.0:389) > May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=0 BIND dn="" method=128 > May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=0 RESULT tag=97 err=0 text= > May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=1 MOD dn="uid=ryans,ou=Users,dc=example,dc=com" > May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=1 MOD attr=displayColor > May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=1 RESULT tag=103 err=8 text=modifications require authentication > May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=2 UNBIND > May 4 12:22:43 ldap1 slapd[8794]: conn=226810 fd=50 closed > > > So, it looks like the DN is not being passed through for some reason. Still working on trying to track it down... > The same issue affects ldappasswd (it refuses to change the passwd because it thinks the user has not bound to the directory), so it's not just third party utilities. It really does appear as though the chain overlay is stripping the DN before sending the request out to the master, because the logs seem to indicate that the request makes it to the master and fails because there is no DN before a referral is presented to the client that initially sent the update to the slave. I added the 'ACL' loglevel to what I already use ('stats' and 'sync'), just to confirm that it is wasn't being denied by ACL's or anything like that. I do see references to the 'authzFrom' and 'authzTo' attributes in the admin guide's section on chaining, and on the FAQ (http://www.openldap.org/faq/data/cache/1425.html), but the example in test022-ppolicy does not use them, so I would not think that they are required or causing this problem. In any case, I did add olcDbIDAssertAuthzFrom: {0}"*" to the slaves (as the FAQ says) just to be absolutely sure, but it made no difference. I initially thought that the uncommenting of that check was responsible for this behavior, but the followup I sent just prior to this has a link to an OpenLDAP mailing list thread that was made in February, well before these changes that you made, Pierangelo. In either case, the behavior is broken. Exactly where, I'm still trying to figure out, but would definitely appreciate any input from more seasoned OpenLDAP developers.

1 0

Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
by ryans＠aweber.com 04 May '10

04 May '10

Actually, it would appear I'm hitting the same problem as the OP in this thread: http://markmail.org/message/fhfhzy5uehh6e4us#query:openldap chain "modifications require authentication"+page:1+mid:fhfhzy5uehh6e4us+state:results I say that because when I get prompted for authentication by the slave (instead of having the referral handled server-side), I see this corresponding entry in the master's logs: May 4 12:22:43 ldap1 slapd[8794]: conn=226810 fd=50 ACCEPT from IP=10.x.x.x:45081 (IP=0.0.0.0:389) May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=0 BIND dn="" method=128 May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=0 RESULT tag=97 err=0 text= May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=1 MOD dn="uid=ryans,ou=Users,dc=example,dc=com" May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=1 MOD attr=displayColor May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=1 RESULT tag=103 err=8 text=modifications require authentication May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=2 UNBIND May 4 12:22:43 ldap1 slapd[8794]: conn=226810 fd=50 closed So, it looks like the DN is not being passed through for some reason. Still working on trying to track it down...

1 0

Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
by ryans＠aweber.com 04 May '10

04 May '10

After patching, and using the same configuration as I had when the chain overlay was causing issues with slapcat and restarting slapd, I now get prompted with a referral instead of it being automatically chased. However, it does automatically fill in the DN and password to rebind with: root@somehost:~# ldapvi -h localhost --bind=simple -D cn=admin,dc=example,dc=com -w `cat /etc/ldap.secret` --discover 159 entries read add: 0, rename: 0, modify: 1, delete: 0 Action? [yYqQvVebB*rsf+?] y Received referral to ldap://ldapmaster.example.com/uid=ryans,ou=Users,dc=example,dc=com. You are not logged in to ldap://ldapmaster.example.com:389 yet. Type '!' or 'y' to do so. Rebind? [y!nB*qQ?] y --- Login Type M-h for help on key bindings. Filter or DN: cn=admin,dc=example,dc=com Password: *********** Bound as cn=admin,dc=example,dc=com. Done. Before, I never got prompted with this message when using ldapvi, which makes me think that chaining is no longer working. For reference, I am using the same configuration as is documented in test022-ppolicy: dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}back_hdb.la olcModuleLoad: {1}autogroup.la olcModuleLoad: {2}syncprov.la olcModuleLoad: {3}back_ldap.la dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbURI: ldap://ldapmaster.example.com olcDbIDAssertBind: bindmethod=simple binddn="cn=admin,dc=example,dc=com" credentials=SECRET mode=self I am still looking in to what might be causing this to fail.

1 0

(ITS#6247)
by daniel＠pluta.biz 03 May '10

03 May '10

I've enabled <g-differential> format as default for the Root-DSE's serverTime attribute (and thus removed the #ifdef CTM_G_DIFFERENTIAL_SERVERTIME). The updated patch can be downloaded from here: ftp://ftp.openldap.org/incoming/daniel-pluta-100503.patch Please use -DCTM during compilation. Below is a sample schema file called "example.schema" and some sample data called "example.ldif". In addition also some sample ldif change files and filter statements are provided to: - offer you some first, quick and easy testing possibilities regarding "LDAP server side current time matching"'s matching rules in action - and to give us a chance to get more detailed feedback regarding problems concerning the LDAP specification in common (e.g. violation of the standard) and slapd in detail. Many thanks! Depending on your feedback and the current status of the discussion on ldapext the code will be updated accordingly. It's currently just a prototype, the obviously open implementation TODOs are: - use operation's time-stamp instead of system calls (OpenLDAP 2.5?) - X.680 duration-syntax (instead of custom offset fun: "n#n#n#n#n#n") - further cleanups: function aggregation / coding style / ... - integration into "make test"? e.g. using FTPL: http://www.code-wizards.com/projects/libfaketime (?!) #========================================= $: cat example.schema attributetype ( 1.3.6.1.4.1.7650.666.1.1.1 NAME 'demoTs1' DESC 'draft-pluta-ldap-srv-side-current-time-match: 1st demo attribute' EQUALITY nowMatch ORDERING nowOrderingMatch SYNTAX 1.3.6.1.4.1.7650.6.2.3.1.0 ) attributetype ( 1.3.6.1.4.1.7650.666.1.1.2 NAME 'demoTs2' DESC 'draft-pluta-ldap-srv-side-current-time-match: 2nd demo attribute' EQUALITY nowMatch ORDERING nowOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) attributetype ( 1.3.6.1.4.1.7650.666.1.1.3 NAME 'demoTs3' DESC 'draft-pluta-ldap-srv-side-current-time-match: 3rd demo attribute (violat es RFC4517)' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) objectclass ( 1.3.6.1.4.1.7650.666.1.2.1 NAME 'ctmDemo' DESC 'draft-pluta-ldap-srv-side-current-time-match: demo objectClass' AUXILIARY MAY ( demoTs1 $ demoTs2 $ demoTs3 ) ) #==DATA======================================= $: cat example.ldif dn: dc=example,dc=com objectClass: domain objectClass: extensibleObject objectClass: top dn: ou=dev,dc=example,dc=com objectClass: organizationalUnit objectClass: top objectClass: ctmDemo ou: dev demoTs1: 20100101000000Z demoTs2: 20100101000000Z demoTs3: 20100101000000Z #==LDIF=CHANGE=FILES========================== $: cat add_delete.ldif dn: ou=dev,dc=example,dc=com changetype: modify delete: demoTs1 demoTs1: 20100101000000Z - add: demoTs1 demoTs1: 20100201000001Z dn: ou=dev,dc=example,dc=com changetype: modify delete: demoTs2 demoTs2: 20100101000000Z - add: demoTs2 demoTs2: 20100201000001Z dn: ou=dev,dc=example,dc=com changetype: modify delete: demoTs3 demoTs3: 20100101000000Z - add: demoTs3 demoTs3: 20100201000001Z #----------------------------------------- $: cat add_mv.ldif dn: ou=dev,dc=example,dc=com changetype: modify add: demoTs1 demoTs1: 20110201000000Z - add: demoTs1 demoTs1: 20120201000000Z - add: demoTs1 demoTs1: 20130201000000Z - add: demoTs1 demoTs1: 20100201000000Z dn: ou=dev,dc=example,dc=com changetype: modify add: demoTs2 demoTs2: 20110201000000Z - add: demoTs2 demoTs2: 20120201000000Z - add: demoTs2 demoTs2: 20130201000000Z - add: demoTs2 demoTs2: 20100201000000Z dn: ou=dev,dc=example,dc=com changetype: modify add: demoTs3 demoTs3: 20110201000000Z - add: demoTs3 demoTs3: 20120201000000Z - add: demoTs3 demoTs3: 20130201000000Z - add: demoTs3 demoTs3: 20100201000000Z #----------------------------------------- $: cat reset.ldif dn: ou=dev,dc=example,dc=com changetype: modify delete: demoTs1 - add: demoTs1 demoTs1: 20100101000000Z dn: ou=dev,dc=example,dc=com changetype: modify delete: demoTs2 - add: demoTs2 demoTs2: 20100101000000Z dn: ou=dev,dc=example,dc=com changetype: modify delete: demoTs3 - add: demoTs3 demoTs3: 20100101000000Z #==FILTER=STATEMENTS====================== #BTW: You can use the FakeTime Preload Library #(link above) to easily fake slapd's time to #get constant results for automatic testing (demoTs1=20100101000000Z) (demoTs1<=NOW) (demoTs1>=NOW) (demoTs1>=-2#0#0#0#0#0) (demoTs2=20100101000000Z) (demoTs2<=NOW) (demoTs2>=NOW) (demoTs2<=0#-1#0#0#0#0) (demoTs3=20100101000000Z) #Only possible if compiled using: #-DRFC4517_ASSERTION_SYNTAX_VIOLATION (demoTs3<=NOW) (demoTs3>=NOW)

1 0

Re: (ITS#6543) make test failure
by quanah＠zimbra.com 03 May '10

03 May '10

--On Monday, May 03, 2010 3:50 PM +0000 sven.falempin(a)gmail.com wrote: > No race errors found after 10 iterations > Found 2 errors >>>>>>> Exiting with a false success status for now >>>>>> ./scripts/test058-syncrepl-asymmetric completed OK for hdb. The point of these lines about exiting with false success is that you are to ignore the issue. I.e., please don't file a bug report about failure with test058. That's why it exits with "success". --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6543) make test failure
by sven.falempin＠gmail.com 03 May '10

03 May '10

Full_Name: Sven Version: 2.4.21 OS: OpenBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.80.162.131) Using OpenBSD 4.3 or OpenBSD 4.7 with both bdb 4.6.21 and 5.0.21 The following test failed , to help reproduction i do a trick explained below: >>>>> Starting test058-syncrepl-asymmetric for hdb... running defines.sh Initializing master configurations... Initializing search configurations... Starting central master slapd on TCP/IP port 9011... [...] lots of output [...] Using ldapdelete to delete entry on site1 master... Starting central master again... Using ldapsearch to check that entry was deleted on central master... Using ldapsearch to check that entry was deleted on central search... No race errors found after 10 iterations Found 2 errors >>>>>> Exiting with a false success status for now >>>>> ./scripts/test058-syncrepl-asymmetric completed OK for hdb. To trigger the failure i do an ugly #find / | grep whatever

1 0

Re: (ITS#6247)
by Kurt＠OpenLDAP.org 02 May '10

02 May '10

In regards to my X.501 comments, see "Matching Rule Requirements" = section of X.501(93). Note that only the 93 edition is normative here. I note that you actually need to specify the syntaxes and matching rules = in X.500 terms, and then simply specify a string representation for the = syntaxes for use in LDAP. See RFC 4521, Section 5.1 (for LDAP Syntaxes) = and 5.2 (for Matching Rules) and Section 5 more generally for schema. As far as your I-D goes, I currently deferring to Steve's initial review = at this early stage in its development because I'm busy and I trust = Steve to tease out any obvious ASN.1, X.500, and/or LDAP issues with = your I-D and to "educate" you as might be necessary. I'll join in = later, possibly after you revise your I-D once or twice to address = Steve's comments. -- Kurt=

1 0

Re: (ITS#6247)
by daniel＠pluta.biz 02 May '10

02 May '10

Kurt Zeilenga schrieb: > On May 1, 2010, at 12:31 PM, daniel(a)pluta.biz wrote: > >> The patch can be downloaded here: >> ftp://ftp.openldap.org/incoming/daniel-pluta-100501.patch >> >> Changes: >> - removed extensible matching rules strictly associated with >> dedicated syntaxes >> - added two universal matching rules instead: >> - nowMach (equality matching rule) >> - nowOrdering (ordering matching rule) >> - these two rules also support extensible match filters > > Your comments imply these rules could be used as attribute type > equality and ordering rules. In general my intention is neither to violate X.501 nor changing the ASN.1 Generalized Time syntax. Instead the introduction of a compatible/similar/derived attribute value syntax (e.g. generalizedTime') which supports matching against client-side known time-stamps *and* server-relative time-stamps (like NOW or NOW-1Y3M... or X.680 period formats) seems to be fine for me. In the following generalizedTime' is such a kind of a (very) similar syntax to the well-defined generalizedTime. Regarding the EQ/ORD matching rule applicability: The attribute type is generalizedTime' and the assertion value is for example NOW which server-internally implicitly also represents a (at least some kind of possibly not ITU specified?) generalizedTime' conform assertion value: NOW is the at client side unknown current time of the server in generalizedTime'. What's your suggestion regarding a possible solution on how to support EQ and ORD matching of attribute values compared to the server side current time? > I don't believe the met the > requirements (see X.501) to be used in that manner. That is, they > only make sense as extensible matching rules. I really would like to try to understand your concerns. Could you please give me some links to chapters/sections in X.501 where I can find more details. Note: I've currently only access to the standard of the year 2006. The class is generalizedTime' and during EQ/ORD matching two instances of generalizedTime' are compared: 1. Attribute value of an entry (generalizedTime') 2. Assertion value aka expanded-NOW (generalizedTime') >> To publish a correct server current time time-stamp value within Root-DSE: >> - apply the bugfix from ITS#6541 >> - and use -DCTM_G_DIFFERENTIAL_SERVERTIME > > #ifdef's should, IMO, be generally avoided. it will be removed as soon as the above mentioned bug is fixed in HEAD >> To extend generalizedTime attribute types to also support "NOW" as >> assertion value: >> - use -DCTM_RFC4517_MR_AV_SYNTAX_VIOLATION > > The generalized time syntax is not ours to alter. Introduction of > such a change would, it seem, lead to interoperability problems. In my opinion the chosen name for the #ifdef is more than obvious. Additionally the related comment in the patch's source already say's that this "extension" is more a violation than an extension. That's why the #ifdef currently is and probably stays in action (or will be removed) in the future. As a side-effect this #ifdef could possibly invoke some disussions... ;-) It's probably worth to discuss this (violation) in more detail to provide a solution in regard to a broader applicability of this matching feature in LDAP. Broader/easier usage/readbility is also the background I've decided to skip the extensible matching rules and introduce EQ and ORD instead. E.g. Clients that are connecting to a server that announces the supportedFeature "current time matching" could make notice of that and also support "NOW" as assertion value for createTimestamp and so on... (I've not very well thought about that in detail, yet). You are right, it's just a work in progress and you are very welcome to join the discussion on ldapext.

1 0

Re: (ITS#6542) Segmentation Fault if config file (ldif) got changed
by hyc＠symas.com 01 May '10

01 May '10

felix.schuster(a)gmx.at wrote: > Full_Name: Felix > Version: 2.4.19 > OS: Linux/Gentoo > URL: > Submission from: (NULL) (78.142.131.97) > > > Using the new configuration scheme, I changed > /etc/openldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif of a running openldap > instance. When I tried to restart openldap it gaves me a Segmentation Fault > error. Even if I called the changes off, openldap refused to start (furthermore > segfaulted). I needed to get a copy of the original configuration file from my > backup to successfully start openldap again. > I think it's somewhere ok to deny working with a hand-changed configuration, but > I think we will need a friendly advise, no unfriendly Segementation Fault error. > cn=config is an LDAP database. Like any other LDAP database, you are only supposed to use ldapadd/modify/delete to write to it while slapd is running. You would probably get segfaults if you hand-edited the data files in a back-bdb database too. And no, we will not add code to protect from such misuse. -- -- 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#6542) Segmentation Fault if config file (ldif) got changed
by felix.schuster＠gmx.at 01 May '10

01 May '10

Full_Name: Felix Version: 2.4.19 OS: Linux/Gentoo URL: Submission from: (NULL) (78.142.131.97) Using the new configuration scheme, I changed /etc/openldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif of a running openldap instance. When I tried to restart openldap it gaves me a Segmentation Fault error. Even if I called the changes off, openldap refused to start (furthermore segfaulted). I needed to get a copy of the original configuration file from my backup to successfully start openldap again. I think it's somewhere ok to deny working with a hand-changed configuration, but I think we will need a friendly advise, no unfriendly Segementation Fault error.

1 0

Re: (ITS#6247)
by Kurt＠OpenLDAP.org 01 May '10

01 May '10

On May 1, 2010, at 12:31 PM, daniel(a)pluta.biz wrote: > Hi, >=20 > just some changes and cleanups according the still ongoing discussion = on=20 > ldapext. I recommend consideration of this patch be deferred until the = specification is less of a work-in-a-progress. >=20 > The patch can be downloaded here:=20 > ftp://ftp.openldap.org/incoming/daniel-pluta-100501.patch >=20 > Changes: > - removed extensible matching rules strictly associated with=20 > dedicated syntaxes > - added two universal matching rules instead: > - nowMach (equality matching rule) > - nowOrdering (ordering matching rule) > - these two rules also support extensible match filters Your comments imply these rules could be used as attribute type equality = and ordering rules. I don't believe the met the requirements (see = X.501) to be used in that manner. That is, they only make sense as = extensible matching rules. >=20 > To publish a correct server current time time-stamp value within = Root-DSE: > - apply the bugfix from ITS#6541 > - and use -DCTM_G_DIFFERENTIAL_SERVERTIME #ifdef's should, IMO, be generally avoided. >=20 >=20 > To extend generalizedTime attribute types to also support "NOW" as=20 > assertion value: > - use -DCTM_RFC4517_MR_AV_SYNTAX_VIOLATION The generalized time syntax is not ours to alter. Introduction of such = a change would, it seem, lead to interoperability problems. >=20 >=20 > Beware of patching conflicts in schema_init.c: > This patch contains small redundant parts from my parallel = contribution=20 > in ITS#6532 >=20 > Regards, > Daniel >=20 >=20

1 0

(ITS#6247)
by daniel＠pluta.biz 01 May '10

01 May '10

Hi, just some changes and cleanups according the still ongoing discussion on ldapext. The patch can be downloaded here: ftp://ftp.openldap.org/incoming/daniel-pluta-100501.patch Changes: - removed extensible matching rules strictly associated with dedicated syntaxes - added two universal matching rules instead: - nowMach (equality matching rule) - nowOrdering (ordering matching rule) - these two rules also support extensible match filters To publish a correct server current time time-stamp value within Root-DSE: - apply the bugfix from ITS#6541 - and use -DCTM_G_DIFFERENTIAL_SERVERTIME To extend generalizedTime attribute types to also support "NOW" as assertion value: - use -DCTM_RFC4517_MR_AV_SYNTAX_VIOLATION Beware of patching conflicts in schema_init.c: This patch contains small redundant parts from my parallel contribution in ITS#6532 Regards, Daniel

1 0

(ITS#6541) liblutil/ultils.c: lutil_localtime() <g-differential> timestamp format bug
by daniel＠pluta.biz 01 May '10

01 May '10

Full_Name: Daniel Pluta Version: HEAD OS: - URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:470:9feb:ff02:91d5:32:f2b:def0) Hi, for a description and a possible patch (to small for an upload ;-)) please see: http://www.openldap.org/lists/openldap-devel/201003/msg00012.html Cheers

1 0

Re: (ITS#6534) bad ifdef/elif clause in liblutil
by h.b.furuseth＠usit.uio.no 30 Apr '10

30 Apr '10

quanah(a)zimbra.com writes: > Actually, the issue seems to be name changes in the header files under BSD. > This causes TIOCNOTTY to end up being undefined. That would not give the error message shown in <http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg776021.html>: build/buildd-openldap_2.4.21-1-kfreebsd-amd64-VWAqZY/openldap-2.4.21/libraries/liblutil/detach.c:131:7: error: missing binary operator before token "long" Line 131 is "#elif TIOCNOTTY". There's no 'long' there is TIOCNOTTY is undefined, it'd just evaluate to #elif 0. So my guess is that TIOCNOTTY somewhere is defined to expand to an expression involving a (long) cast. -- Hallvard

1 0

Re: (ITS#6456) Feature Request
by j＠gropefruit.com 29 Apr '10

29 Apr '10

It works exactly as I had hoped. Thank you for implementing this, I = believe it will be an asset to others besides myself. J > This is now implemented in back-ldap (idassert-passthru, = olcDbIDAssertPassThru, undocumented yet). > Basically, identities matching rules formally identical to those of = idassert-authz=46rom do not undergo identity assertion. =20 > This rule is checked before idassert-authzFrom, so in case an identity = matches both, passthru wins. Please test and report. > p.=20

1 0

Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
by quanah＠zimbra.com 29 Apr '10

29 Apr '10

--On Thursday, April 29, 2010 5:38 PM +0000 ryans(a)aweber.com wrote: > Great, many thanks for your efforts in confirming. Just out of > curiosity, when the fix is actually committed, will the commit number or > source code file be present in the ITS, so that one can easily > cross-reference the ITS with a particular file or set of files from CVS > HEAD? And again, please let me know if there's anything I can do to help > facilitate the process, or make it easier for you and/or the other > developers. I'm happy to test, patch the test scripts, et cetera. Unfortunately no, that type of commit -> bug integration does not currently exist, although I think it is a highly desirable feature and one that has been discussed for implementation. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
by ryans＠aweber.com 29 Apr '10

29 Apr '10

> Date: Thu, 29 Apr 2010 17:30:42 +0200 (CEST) > Subject: Re: (ITS#6540) test022-ppolicy is flawed, > masks serious stability issue > From: masarati(a)aero.polimi.it > To: ryans(a)aweber.com > Cc: openldap-its(a)openldap.org > >> I already >> figured out myself how to reproduce the issue you're having, so you don't >> need to rebuild yet. You'll have to as soon as the issue is fixed. > > Try this patch: > > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-29-chain.1.patch> > > It removes the offending check. I don't quite remember the reason (it > dates 4.5 years ago). However, I've checked and all tests pass fine, > including the one you pointed out. To reproduce, I modified test022 to > write the configuration on disk (-F option to consumer slapd); at the end > of the test, I tried slapd on the resulting database. Fails with > 2.4.22/HEAD, succeeds with this patch. > > Please test and report. > > p. > Sure, will do that now and report back. Thanks. -Ryan

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs