openldap-technical

openldap-technical@openldap.org

7 participants
9864 discussions

AW: openldap 2.2.x
by Pörschke, Gunnar 02 Nov '12

02 Nov '12

With my ldap client, JXplore, I import a subtree and get this error message: [LDAP: error code 21 - postalAddress: value #0 invalid per syntax]; remaining name 'uid=reskes(a)circa,ou=Users,ou=DATA,ou=fis-vl.bund.de,o=IRCusers,l=CIRCA' The import job fails (same result with slapadd). This are the data: postalAddress:: TmllZGVyc+RjaHNpc2NoZXMgTGFuZGVzYW10IGb8ciBWZXJicmF1Y2hlcnNj aHV0eiB1bmQgTGViZW5zbWl0dGVsc2ljaGVyaGVpdCwgRGV6ZXJuYXQgMjMsIFBvc3RmYWNoIDM 5NDksIDI2MDI5IE9sZGVuYnVyZw== -----Ursprüngliche Nachricht----- Von: Pörschke, Gunnar Gesendet: Donnerstag, 1. November 2012 13:51 An: 'openldap-technical(a)openldap.org' Betreff: openldap 2.2.x Hi all, we have an very old openldap running and we need to migrate data to latest openldap version. I create an ldif but the data in that file are encoded "base64". Is there a trick to disable that? My plan is to export everything from openldap 2.2 database (lbdb) without base64 encoding so I can easily use slapadd to add this data to a database on my new openldap 2.4.2x system Thank you for any idea. Gunnar

3 2

Re: Index Add Failures
by Kyle Smith 01 Nov '12

01 Nov '12

Thanks for the input, Quanah. I really appreciate it. On Thu, Nov 1, 2012 at 1:10 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > > --On Thursday, November 01, 2012 1:04 PM -0400 Kyle Smith < > alacer.cogitatus(a)gmail.com> wrote: > > Is it possbile to use MMR to my advantage to switch over? For example, >> take down 1 of the servers, switch the db config from bdb to mdb, and >> then restart with a blank database (with appropriate structure) and >> have the MMR take care of backfilling the mdb entries? Then I wouldn't >> have to export to ldif, convert the db, and reimport while possibly >> loosing data from the other systems. >> > > Hi Kyle, > > I'm not sure what you are trying to avoid here... Slapcat/slapadd are > always faster than sync replication. Why would you lose data from the > other server while doing this? contextCSNs should be preserved w/ > slapcat/slapadd, so the server being converted will just catch up using > sync replication as before. You may wish to look at ITS#7427 though. The > fix for that is in current RE24. > > > --Quanah > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

1 0

Re: Index Add Failures
by Kyle Smith 01 Nov '12

01 Nov '12

Is it possbile to use MMR to my advantage to switch over? For example, take down 1 of the servers, switch the db config from bdb to mdb, and then restart with a blank database (with appropriate structure) and have the MMR take care of backfilling the mdb entries? Then I wouldn't have to export to ldif, convert the db, and reimport while possibly loosing data from the other systems. On Thu, Nov 1, 2012 at 12:57 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > > --On Thursday, November 01, 2012 12:36 PM -0400 Kyle Smith < > alacer.cogitatus(a)gmail.com> wrote: > > Ok, I have been running 2.4.32 for some time with no issues. Yesterday, 2 >> different servers (both part of a 4-way MMR) produced an "index add >> failure" and an "index delete failure". I went back over the bdb >> DB_CONFIG Settings (listed below) and everything looks nominal to me. >> Would it just make more sense to switch from bdb to mdb instead of >> troubleshooting these "random" errors too much? I also noticed that the >> number of "deadlocks" corresponds to the number of errors that were >> produced. Is there correlation there? >> > > I would suggest back-mdb in OpenLDAP 2.4.33 over back-hdb, yes. It will > remove these deadlock issues entirely. When you configure the back-mdb > backend in cn=config, be sure to have: > > olcDbEnvFlags: writemap > olcDbEnvFlags: nometasync > > set as well. This makes back-mdb writes significantly faster than writes > to back-bdb/hdb. (Some 2x faster in my testing so far). > > > --Quanah > > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

2 1

openldap 2.2.x
by Pörschke, Gunnar 01 Nov '12

01 Nov '12

Hi all, we have an very old openldap running and we need to migrate data to latest openldap version. I create an ldif but the data in that file are encoded "base64". Is there a trick to disable that? My plan is to export everything from openldap 2.2 database (lbdb) without base64 encoding so I can easily use slapadd to add this data to a database on my new openldap 2.4.2x system Thank you for any idea. Gunnar

2 1

Re: Problem in sync-repling multiple databases
by Marco Pizzoli 31 Oct '12

31 Oct '12

Hi Quanah, On Mon, Oct 29, 2012 at 6:16 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > --On Monday, October 29, 2012 8:52 AM +0100 Marco Pizzoli < > marco.pizzoli(a)gmail.com> wrote: > > If I try to configure a second replica configration targeted directly to >> (in example) to ou=ou3, then that ou get replicated. >> >> Any help/advice is welcome. >> > > Hi Marco, > > You have not provided any useful information with which to help you, so > there is not really any advice one can offer you. I.e., you have not > provided the configuration you are using on your master and replicas in the > scenario where you have multiple DBs. > You are absolutely right and I'm aware of it... The problem is in this case I can't provide any (even similar to)real configuration. Both from technical limitation (remote server with no possibility of copy/paste) and corporate policy*. I was hoping to find a known logical problem/bug, so to continue myself. I read an answer from Howard to another user some times ago telling him that is a known problem in OL2.3 not handling well subordinate db's and syncrepl, so I asked from help in this topic. The suggestion (from another user) was, for that release, to configure a syncrepl directive for each of the subordinate db's. This is what I did and in the end I succeded in syncrepling also other db's. If you have general guidance, know issues to share in cases similar to these and so on... I would be interested in it. Thanks for your comprehension Marco * Continuing experimenting I found also 2 or 3 cases in which I'm able to crash OL 2.4.33 (in one case by simply slapadding using back-mdb) but I CAN'T provide any material to file a "valid" ITS. I'm sorry about that. > > --Quanah > > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

2 1

Setting a whole subtree temporarily read-only based on an attribute?
by Peter Mogensen 31 Oct '12

31 Oct '12

Hi, I've been reading the slapd.access back and forth a few times in search for a way to make an ACL, which defines read (and only read) access to a whole subtree in the DIT based on the value of an attribute of the subtree root node. I've found out how to do it for a named user by defining a group attribute on the node like this: olcAccess: {2}to dn.regex="^.+,o=([^,]+),dc=example,dc=com" by group/NamedObject/denied.expand="o=$1,dc=example,dc=com" read by * +0 break But this only denies the named DNs write access. What I want to to deny everybody write access to everything below the o=$1 RDN. Conceptually I would also imagine, that this would belong in the <WHAT> clause of the ACL and not in the <WHO> clause, but I can't find any mechanism to do stuff like: access to dn.<which-have-attr-set-to-readonly>.children by * read What is the text-book way to do this? regards, Peter

1 0

Error : when create usermachine in LDAP
by rodrigo tavares 31 Oct '12

31 Oct '12

Hello, I try to create a computer in LDAP, come this message: Error in OpenLDAP recording computer.* What is wrong ? Rodrigo Faria

3 5

read/write password/... attributes from/in SQL DB directly
by Denny Schierz 31 Oct '12

31 Oct '12

hi, our usermanagement is running on a Postgres (later MariaDB) database and have some (cron)scripts, that push/delete the new users into the LDAP tree. If the user changes his password (passwd/linux) it is only written to the LDAP side and one other script, reads the new password out and writes it into the user mgt DB back. I want to ask: is there a way, to let LDAP read/write this or more attributes to the DB directly? We thought also to switch the dbdm to the mySQL backend, but I think, it isn't a good idea for ~4.000 active accounts and several netboot clients. cu denny

1 1

OpenLDAP - how to correct invalid cn values
by Whiteman, Craig 30 Oct '12

30 Oct '12

A bug in a PHP script<http://www.linuxquestions.org/questions/showthread.php?p=4813771> has caused some entries in the LDAP database<http://www.linuxquestions.org/questions/showthread.php?p=4813771> to have invalid values: # James + Bond, people, mi6.gov.uk dn: cn=James+sn=Bond,ou=people,dc=mi6,dc=gov,dc=uk sn: Bond givenName: James cn:: U3RldmUg gecos:: U3RldmUg As you can see, the cn: and gecos: have the invalid values - they should be James Bond. I did attempt to correct the problem with ldapmodify by putting the following into a file called updateCN.ldif: dn: cn=James+sn=Bond,ou=people,dc=mi6,dc=gov,dc=uk changetype:modify replace: cn cn: James Bond and executing the following command: ldapmodify -x -W -D "cn=admin,dc=mi6,dc=gov,dc=uk" -f updateCN.ldif This returned the following error Enter LDAP Password: modifying entry "cn=James+sn=Bond,ou=people,dc=mi6,dc=gov,dc=uk" ldap_modify: Naming violation (64) additional info: value of naming attribute 'cn' is not present in entry I have also tried ldapmodrdn: ldapmodrdn -r -f updateCN.ldif with updateCN.ldif: dn: cn=James Bond+sn=Bond,ou=people,dc=mi6,dc=gov,dc=uk cn=James Bond $ ldapmodrdn -r -f updateCN.ldif SASL/DIGEST-MD5 authentication started Please enter your password: ldap_sasl_interactive_bind_s: Internal (implementation specific) error (80) additional info: SASL(-13): user not found: no secret in database and ldapmodify -f updateCN.ldif with updateCN.ldif: dn: cn=James Bond+sn=Bond,ou=people,dc=mi6,dc=gov,dc=uk changetype: modrdn newrdn: cn=James Bond deleteoldrdn: 1 $ ldapmodify -f updateCN.ldif SASL/DIGEST-MD5 authentication started Please enter your password: ldap_sasl_interactive_bind_s: Internal (implementation specific) error (80) additional info: SASL(-13): user not found: no secret in database How can I correct the invalid values in the LDAP database? THINK BEFORE YOU PRINT====================================================================== The information contained in this email is intended only for the individual to whom it is addressed. It may contain legally privileged or confidential information or otherwise be exempt from disclosure. If you have received this message in error or there are any problems, please notify the sender immediately and delete the message from your computer. YOU MUST NOT use, disclose, copy or alter this message for any unauthorized purpose. Neither Electricity North West Limited nor any of its subsidiaries will be liable for any direct, special, indirect or consequential damages as a result of any virus being passed on, or arising from the alteration of the contents of this message by a third party. Electricity North West Limited 304 Bridgewater Place, Birchwood Park Warrington WA3 6XG, Registered in England and Wales Registration No 02366949 ===========================================================================================

3 4

max. numbers of subordinate databases
by Dieter Klünter 29 Oct '12

29 Oct '12

Hello, I have a strange requirement to setup a Server with as much as possible subordinate databases. In a test environment I could create any number of databases, but a one level search presents the results of 27 databases and after this an internal error is reported. (thread_pool_setkey failed err (12)) I did this tests with back-hdb and back-mdb. Is there any way to increase the number of subordinate databases? -Dieter -- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID:DA147B05 53°37'09,95"N 10°08'02,42"E

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical