openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#5321) slapindex fails to create cn=config from configuration file
by joshua＠itsecureadmin.com 10 Jan '08

10 Jan '08

Quanah Gibson-Mount wrote: > --On Thursday, January 10, 2008 9:09 PM +0000 joshua(a)itsecureadmin.com >> Full_Name: Joshua Miller >> Version: 2.4.7 >> OS: CentOS 5 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (198.134.96.10) > > What makes you think you should be using slapindex to do this? The admin guide suggests that any slap* command should do this: http://www.openldap.org/doc/admin24/slapdconf2.html#cn=config Also, the slapd-config man page: Alternatively, an existing slapd.conf file can be converted to the new format using slapd or any of the slap tools: slaptest -f /etc/openldap/slapd.conf -F ETCDIR/slapd.d Thanks, -- Joshua M. Miller - RHCE,VCP

1 0

Re: (ITS#5321) slapindex fails to create cn=config from configuration file
by quanah＠zimbra.com 10 Jan '08

10 Jan '08

--On Thursday, January 10, 2008 9:09 PM +0000 joshua(a)itsecureadmin.com wrote: > Full_Name: Joshua Miller > Version: 2.4.7 > OS: CentOS 5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (198.134.96.10) > > > OL Version 2.4.7 > Berkely DB 4.6 > OS CentOS 5 > > Command: slapindex What makes you think you should be using slapindex to do this? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5321) slapindex fails to create cn=config from configuration file
by joshua＠itsecureadmin.com 10 Jan '08

10 Jan '08

Full_Name: Joshua Miller Version: 2.4.7 OS: CentOS 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (198.134.96.10) OL Version 2.4.7 Berkely DB 4.6 OS CentOS 5 Command: slapindex ISSUE: When attempting to generate cn=config from a configuration file using slapindex, no cn=config is generated: # cd /etc/openldap # mkdir slapd.d # /usr/sbin/slapindex -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d # echo $? 0 Program exits without error. # ls /etc/openldap/slapd.d Subsequently, running this command immediately after generates the appropriate cn=config: # slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d config file testing succeeded # ll slapd.d total 8 drwxr-x--- 4 root root 4096 Jan 10 13:07 cn=config -rw------- 1 root root 1097 Jan 10 13:07 cn=config.ldif #

1 0

Re: (ITS#5320) bug on the filter functionnality =*
by quanah＠zimbra.com 10 Jan '08

10 Jan '08

--On Thursday, January 10, 2008 3:31 PM +0000 jpgressard(a)hotmail.com wrote: > I tested the same query on the version 2.4.6 and it was working. > Furthermore, if I amend the query to (&(sn=XXX*)(givenName=D*)), or > (sn=XXX*) I find the entry. As noted when 2.4.7 was released, you want to regenerate your indices. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5320) bug on the filter functionnality =*
by h.b.furuseth＠usit.uio.no 10 Jan '08

10 Jan '08

jpgressard(a)hotmail.com writes: > The query (&(sn=XXXXXX*)(givenName=*))can not find the entry below. Does it help to stop slapd, run sbin/slapindex, and restart slapd? You need to do that if you edit slapd.conf's index statements, and possibly when you upgrade. -- Hallvard

1 0

(ITS#5320) bug on the filter functionnality =*
by jpgressard＠hotmail.com 10 Jan '08

10 Jan '08

Full_Name: Jean-Paul Gressard Version: 2.4.7 OS: Madrake distribution (v10) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (158.232.2.8) The query (&(sn=XXXXXX*)(givenName=*))can not find the entry below. dn: uid=XXXXXXDDDDD14977,l=Geneva,c=CH,o=who,o=directoryroot sn: XXXXXX objectClass: inetOrgPerson uid: XXXXXXDDDDD14977 telephoneNumber: 14977 o: who givenName: DDDDD cn: XXXXXX, DDDDD I tested the same query on the version 2.4.6 and it was working. Furthermore, if I amend the query to (&(sn=XXX*)(givenName=D*)), or (sn=XXX*) I find the entry.

1 0

Re: (ITS#5316) authzTo unevaluated in 2.4.7
by hyc＠symas.com 10 Jan '08

10 Jan '08

m.erde(a)gmx.net wrote: > First, I actually meant of course "authzid" in ITS > > After some tests, I found out that the filter expression in authzTo- > Attribute of the authentication entity caused the Problems: While > > authzTo: ldap:///ou=users,ou=accounts,dc=dom??one?(uid=*) > > does not work (with uid as rdn), > > authzTo: ldap:///ou=users,ou=accounts,dc=dom??one?(objectClass=*) > > does. Regenerate your presence index on uid. http://www.openldap.org/lists/openldap-software/200712/msg00193.html This ITS will be closed. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5319) Rename on same DN failes
by abartlet＠samba.org 09 Jan '08

09 Jan '08

Full_Name: Andrew Bartlett Version: HEAD CVS OS: Fedora 8 URL: Submission from: (NULL) (59.167.251.137) Renaming a DN to itself, whether or not changing case, fails. This should succeed, preferably for all cases, so that it is possible to change the case of an RDN. This would also assist Samba4, as AD supports these renames, and I am working on a mapping layer from OpenLDAP to Samba4. Howard Chu notes on the openldap-technical list that logic to allow this existed in the past, but appears to have been lost.

1 0

Re: (ITS#5312) ldapmodify(1) man page claims that "changetype:" not necessary
by hyc＠symas.com 09 Jan '08

09 Jan '08

h.b.furuseth(a)usit.uio.no wrote: > Howard Chu writes: >>> If anything, the LDIF RFC could be revised instead. This format has >>> been supported since umich ldap (before the LDIF RFC was written). >> That doesn't mean it has any relevance today; there's plenty of stuff >> UMich did that was long since deprecated. > > True, but this was not deprecated that I know of. It is now. ;) The outcome of the original discussion, which Kurt again reminded me of today, was that ldapmodify should quit its guessing games and just accept valid LDIF input. The description of the exceptions in the manpage seemed imply they were there to accommodate slurpd users, who needed a mechanism for applying failed updates to a target server. Now that all slurpd/replog support has been dropped, there really is no more justification for these exceptions. > Snipping a bit from the -devel thread: > Howard Chu wrote: >> (Did I mention that I've always thought the mod-spec definition was >> garbage? The format I use for the logschema has none of these problems >> or inefficiences...) > > As far as I can tell Logschema doesn't support full LDIF modify though. > reqMod is unordered, so one cannot make two modifications to the same > attribute. E.g. "delete: foo" followed by "replace: foo". I suppose reqMod should be made ordered. My point about logschema is that reqMod's syntax doesn't require separators/terminators or as many redundant attribute references. attr:- foo attr:+ bar is a far more efficient representation than delete: attr attr: foo - add: attr attr: bar - The logschema format is also easily grep-able without resorting to grep windowing and other such hassles. > Maybe it's time to take this to the ldapext list and hear what others > do. This is really getting off topic, unless you're suggesting that we spec this for a new version of LDIF. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5316) authzTo unevaluated in 2.4.7
by m.erde＠gmx.net 09 Jan '08

09 Jan '08

First, I actually meant of course "authzid" in ITS After some tests, I found out that the filter expression in authzTo- Attribute of the authentication entity caused the Problems: While authzTo: ldap:///ou=users,ou=accounts,dc=dom??one?(uid=*) does not work (with uid as rdn), authzTo: ldap:///ou=users,ou=accounts,dc=dom??one?(objectClass=*) does. -Mat

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs