openldap-bugs

openldap-bugs@openldap.org

1 participants
20953 discussions

Re: (ITS#4814) Tree Archiving
by wells_robert_frank＠yahoo.com 24 Jan '07

24 Jan '07

--0-2146048140-1169674999=:43135 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Apologies - This did in fact work. I had not been aware of the backend DB functionality. Regards, RFW Quanah Gibson-Mount <quanah(a)stanford.edu> wrote: --On Wednesday, January 24, 2007 6:55 PM +0000 wells_robert_frank(a)yahoo.com wrote: > Full_Name: Bob Wells > Version: 2.3.33 > OS: Linux RH 4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (63.81.96.200) Isn't this just the modrdn operation? It is supported when using the back-hdb database. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html --0-2146048140-1169674999=:43135 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Apologies - This did in fact work.  I had not been aware of the backend DB functionality. Regards, RFW Quanah Gibson-Mount <quanah(a)stanford.edu> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> --On Wednesday, January 24, 2007 6:55 PM +0000 wells_robert_frank(a)yahoo.com wrote: > Full_Name: Bob Wells > Version: 2.3.33 > OS: Linux RH 4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (63.81.96.200) Isn't this just the modrdn operation? It is supported when using the back-hdb database. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html </blockquote> --0-2146048140-1169674999=:43135--

1 0

Re: (ITS#4813) glue/syncrepl
by hyc＠symas.com 24 Jan '07

24 Jan '07

aej(a)wpi.edu wrote: > Full_Name: Allan E. Johannesen > Version: 2.3.33 > OS: Linux EL 4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (130.215.24.208) > > > I have two synrepl slaves and entries in both of them seem to degrade, over > time, into "objectClass: glue" entities. > > These entries are not updated, so this degradation appears to be autonomous in > the slaves. The slaves have identical problems, the master retains the > structure of the entries. > > I see IS#4626 which has this same sort of problem, and perhaps I should have > followed on to that, but I can say that this problem must be much worse in > 2.3.33 than previously, since this has only happened to me since upgrading to > this release. > > My ou people is reduced to glue as is the ou access. The simplesecurity object > is gone entirely from the slaves' database. This is only the beginning of the > display of differences in the data. > > These entries were not modified since the database creation, and the > disintegration only occurs in the slaves. > > Let me know if more info is needed. Since you mention that this occurs more often in 2.3.33 than in "previous releases" - what previous version are you comparing to? Please provide the relevant section of your slave slapd.conf - the database clause and its syncrepl statement at least. Are there any ACLs on the provider that would prevent the slave from seeing parts of the affected entries? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4814) Tree Archiving
by quanah＠stanford.edu 24 Jan '07

24 Jan '07

--On Wednesday, January 24, 2007 6:55 PM +0000 wells_robert_frank(a)yahoo.com wrote: > Full_Name: Bob Wells > Version: 2.3.33 > OS: Linux RH 4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (63.81.96.200) Isn't this just the modrdn operation? It is supported when using the back-hdb database. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

(ITS#4814) Tree Archiving
by wells_robert_frank＠yahoo.com 24 Jan '07

24 Jan '07

Full_Name: Bob Wells Version: 2.3.33 OS: Linux RH 4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.81.96.200) REQUEST FEATURE: Need capability to move an entire entry beneath another branch in the tree. Example: uid=jdoe,ou=customers,dc=acme,dc=com (Customer exists) uid=jdoe,ou=archive,ou=customers,dc=acme,dc=com (Customer account deleted from within application and moved to archive tree branch) Currently, we do not believe openLDAP supports this capability. We have used rebind and rename. We are unable to find a way to do what we need it to do. Therefore, we request this type of feature in the product. Thanks in advance, Bob Wells-070124

1 0

Crypt invalide credential
by Arrouan 24 Jan '07

24 Jan '07

Hi, I'm using OpenLDAP under Linux/Gentoo (with crypt enabled). I can bind user with SSHA password, but i can't bind user with CRYPT password. OpenLDAP is link with Postfix/Courier and need CRYPT password. I check the ACL and it seem the issue isn't there. Anyone know how to fix this issue ? I have other postfix+openldap server and they all work without any problem. Thanks

2 1

Re:(ITS#4810) syncprov follows referrals
by dieter＠dkluenter.de 23 Jan '07

23 Jan '07

Hi, this is my test setup ##provider### slapd.conf pidfile /tmp/run/slapd1.pid argsfile /tmp/run/slapd1.args loglevel sync modulepath /usr/local/libexec/openldap moduleload syncprov.la access to dn.base="" by * read access to dn.base="cn=Subschema" by * read suffix "dc=my-domain,dc=com" rootdn "cn=Manager,dc=my-domain,dc=com" rootpw secret directory /tmp/slapd1/ index objectClass eq overlay syncprov -------------------- initial.ldif dn: dc=my-domain,dc=com objectclass: domain dc: my-domain dn: ou=organisation 1,dc=my-domain,dc=com objectclass: organizationalUnit ou: organisation 1 dn: ou=organisation 2,dc=my-domain,dc=com objectclass: organizationalUnit ou: organisation 2 dn: cn=Foo Bar,ou=organisation 1,dc=my-domain,dc=com objectclass: inetorgperson cn: Foo Bar sn: Bar mail: foobar(a)my-domain.com telephoneNumber: +49.40.2997714 dn: cn=Bar Foo,ou=organisation 2,dc=my-domain,dc=com objectclass: alias objectclass: extensibleObject aliasedObjectName: cn=Foo Bar,ou=organisation 1,dc=my-domain,dc=com cn: Bar Foo sn: Foo --------------- ## Consumer #### slapd.conf include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema pidfile /tmp/run/slapd2.pid argsfile /tmp/run/slapd2.args loglevel sync access to dn.base="" by * read access to dn.base="cn=Subschema" by * read database bdb suffix "dc=my-domain,dc=com" rootdn "cn=Manager,dc=my-domain,dc=com" rootpw secret directory /tmp/slapd2/ index objectClass eq syncrepl rid=02 provider=ldap://localhost:9001 binddn=cn=Manager,dc=my-domain,dc=com bindmethod=simple credentials=secret searchbase="dc=my-domain,dc=com" scope=sub type=refreshAndPersist retry="5 5 300 5" -------------------- After starting the comsumer, the initial dataset gets replicated. If adding the following entries (using web2ldap) to the provider dn: cn=Mike Miller,ou=organisation 1,dc=my-domain,dc=com sn: Miller cn: Mike Miller mail: mmiller(a)my-domain.com telephoneNumber: +49.40.4450003 objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person dn: cn=Miller Mike,ou=organisation 2,dc=my-domain,dc=com aliasedObjectName: cn=Mike Miller,ou=organisation 1,dc=my-domain,dc=com cn: Miller Mike objectClass: alias objectClass: extensibleObject dn: cn=Joe Smith,ou=organisation 1,dc=my-domain,dc=com sn: Smith cn: Joe Smith mail: jsmith(a)my-domain.com telephoneNumber: +49.40.4450004 objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person dn: cn=Smith Joe,ou=organisation 2,dc=my-domain,dc=com aliasedObjectName: cn=Joe Smith,ou=organisation 1,dc=my-domain,dc=com cn: Smith Joe objectClass: alias objectClass: extensibleObject the alias objects are not replicated, only after a consumer restart. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

1 0

Re: (ITS#4810) syncprov follows referrals
by dieter＠dkluenter.de 23 Jan '07

23 Jan '07

Am Montag, 22. Januar 2007 22:28 schrieb Pierangelo Masarati: > dieter(a)dkluenter.de wrote: > > Full_Name: Dieter Kluenter > > Version: 2.4.2alpha > > OS: linux > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (84.142.177.66) > > > > > > When adding a alias abject to the provider, syncprov fowllows the > > referral and is not updating the alias object to the consumer, > > Dieter, > > are you talking about aliases or referrals? Hi Ando, In this particular case I am talking about aliases. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

1 0

(ITS#4813) glue/syncrepl
by aej＠wpi.edu 23 Jan '07

23 Jan '07

Full_Name: Allan E. Johannesen Version: 2.3.33 OS: Linux EL 4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (130.215.24.208) I have two synrepl slaves and entries in both of them seem to degrade, over time, into "objectClass: glue" entities. These entries are not updated, so this degradation appears to be autonomous in the slaves. The slaves have identical problems, the master retains the structure of the entries. I see IS#4626 which has this same sort of problem, and perhaps I should have followed on to that, but I can say that this problem must be much worse in 2.3.33 than previously, since this has only happened to me since upgrading to this release. My ou people is reduced to glue as is the ou access. The simplesecurity object is gone entirely from the slaves' database. This is only the beginning of the display of differences in the data. These entries were not modified since the database creation, and the disintegration only occurs in the slaves. Let me know if more info is needed. Thanks. *** users.ldapv2.2007.01.23.ldif.pure Tue Jan 23 09:10:50 2007 --- users.ldapv2back.2007.01.23.ldif.pure Tue Jan 23 09:10:53 2007 *************** *** 10,18 **** dn: ou=People,dc=WPI,dc=EDU objectClass: top ! objectClass: organizationalUnit ! ou: People ! structuralObjectClass: organizationalUnit dn: wpieduPersonUUID=62081c7c52ec30c556d6c558896983ee,ou=People,dc=WPI,dc=EDU objectClass: top --- 10,17 ---- dn: ou=People,dc=WPI,dc=EDU objectClass: top ! objectClass: glue ! structuralObjectClass: glue dn: wpieduPersonUUID=62081c7c52ec30c556d6c558896983ee,ou=People,dc=WPI,dc=EDU objectClass: top *************** *** 1498,1514 **** dn: ou=Access,dc=WPI,dc=EDU objectClass: top ! objectClass: organizationalUnit ! ou: Access ! structuralObjectClass: organizationalUnit ! ! dn: cn=retiresql,ou=Access,dc=WPI,dc=EDU ! objectClass: top ! objectClass: simpleSecurityObject ! objectClass: applicationProcess ! cn: retiresql ! userPassword:: e1NTSEF9Qno0NllDM2pwRWZSZGh6OFdRY2RWNWpjdklaWHM0ekU= ! structuralObjectClass: applicationProcess dn: wpieduPersonUUID=d9e775ae9449c616c6952d860e634ad6,ou=People,dc=WPI,dc=EDU objectClass: top --- 1497,1504 ---- dn: ou=Access,dc=WPI,dc=EDU objectClass: top ! objectClass: glue ! structuralObjectClass: glue dn: wpieduPersonUUID=d9e775ae9449c616c6952d860e634ad6,ou=People,dc=WPI,dc=EDU objectClass: top

1 0

(ITS#4812) ldapmodify doesn't report error when the server closed the connection
by rhafer＠suse.de 23 Jan '07

23 Jan '07

Full_Name: Ralf Haferkamp Version: 2.3, HEAD OS: Any URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.166.107) ldapmodify doesn't report errors from a failed ldap_result() call. This can be reproduce by using ldapmodify via stdin and connecting to a server with a very short idletimeout. If the MODIFY operation is sent after the connection is closed no error message is shown to the user. The only indication of a failure is the EXIT code of ldapmodify. This is fixed in HEAD now.

1 0

Re: (ITS#4809) Replication of operational attributes when performing modrdn operation
by hyc＠symas.com 23 Jan '07

23 Jan '07

Thomas.Fritz(a)bam.de wrote: > Full_Name: Thomas Fritz > Version: 2.3.33 > OS: Debian Gnu/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (141.63.61.111) > > > We are using OpenLDAP 2.3.33 in a master/slave setup with slurpd and hdb > backend. > > When performing the modrdn operation against the master, no update directives > for the attributes 'modifiersName', 'modifyTimestamp', and 'entryCSN' are > written to the replog file. Hence, the databases of master and slave differ by > the values of these attributes after replication. > > This bug can be reproduced using e.g. the ldapmodrdn tool. OpenLDAP versions > back to (at least) 2.3.24 are affected. This is not a bug, it is a consequence of the design of slurpd. slurpd uses LDIF (RFC2849) for its replog format, and simply propagates LDAP operations as recorded there. In LDIF a modrdn record can only specify newrdn, deleteoldrdn, and newsuperior parameters. Likewise, these are the only parameters that can be specified in an LDAP modrdn operation. This design limitation is one of many reasons why slurpd has been deprecated. If you want to perform replication and preserve these attributes, you can use syncrepl instead. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

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