openldap-technical

openldap-technical@openldap.org

7 participants
9901 discussions

LDAP_RES_INTERMEDIATE - SYNC_ID_SET makes me in trouble
by Olivier PAVILLA 05 Apr '11

05 Apr '11

Hi everyone. I have another OpenLDAP server. luz2:/home/romain# uname -a Linux luz2 2.6.26-2-686 #1 SMP Tue Mar 9 17:35:51 UTC 2010 i686 GNU/Linux And: luz2:/home/romain# uname -a Linux luz2 2.6.26-2-686 #1 SMP Tue Mar 9 17:35:51 UTC 2010 i686 GNU/Linux luz2:/home/romain# slapd -VV @(#) $OpenLDAP: slapd 2.4.11 (Nov 26 2009 09:17:06) $ root@SD6-Casa:/tmp/buildd/openldap-2.4.11/debian/build/servers/slapd I read those lines in my /var/log/syslog: Apr 5 06:28:38 luz2 slapd[21213]: syncrepl_message_to_entry: rid=008 mods check (objectClass: value #4 invalid per syntax) Apr 5 06:28:38 luz2 slapd[21213]: do_syncrepl: rid=008 retrying Apr 5 06:38:38 luz2 slapd[21213]: do_syncrep2: rid=008 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 5 06:38:38 luz2 slapd[21213]: do_syncrep2: rid=008 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 5 06:38:38 luz2 slapd[21213]: do_syncrep2: rid=008 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 5 06:38:38 luz2 slapd[21213]: do_syncrep2: rid=008 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 5 06:38:38 luz2 slapd[21213]: do_syncrep2: rid=008 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 5 06:38:38 luz2 slapd[21213]: do_syncrep2: rid=008 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 5 06:38:38 luz2 slapd[21213]: do_syncrep2: rid=008 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 5 06:38:38 luz2 slapd[21213]: do_syncrep2: rid=008 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 5 06:38:38 luz2 slapd[21213]: do_syncrep2: rid=008 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 5 06:38:38 luz2 slapd[21213]: do_syncrep2: rid=008 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 5 06:38:38 luz2 slapd[21213]: do_syncrep2: rid=008 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 5 06:38:38 luz2 slapd[21213]: do_syncrep2: rid=008 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 5 06:38:38 luz2 slapd[21213]: do_syncrep2: rid=008 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 5 06:38:50 luz2 slapd[21213]: syncrepl_message_to_entry: rid=008 mods check (objectClass: value #4 invalid per syntax) Apr 5 06:38:50 luz2 slapd[21213]: do_syncrepl: rid=008 retrying Someone or anyone could tell me what's wrong? I didn't change anything on my server for several months. So suddenly I got those lines. Who can explain to me? Kind regards -- % scan for <<"Arnold Schwarzenegger"^J^D "Arnold Schwarzenegger": << terminator not found S.C.I.R.C. Orléans (Bøurgøgne) - I.U.F.M. Centre-Val de Løire 72 Rue du Faubourg Bourgogne -45044 ORLEANS Cedex 1 Tel : 02-38-49-26-00 mailto:ølivier.pavilla@univ-ørleans.fr http://blog.linux-squad.com -

3 2

Import of a schema file into the cn=schema, cn=config tree
by Peter Schütt 05 Apr '11

05 Apr '11

Hallo, what is the best way to import a schema file into the cn=schema,cn=config tree? Thanks for any hints. Ciao Peter Schütt

2 1

beginner -old slapd.conf
by eric 05 Apr '11

05 Apr '11

I was familiar configuring openldap with slapd.conf ver 2.3 I recently install 2.4 and am having a bear of a time trying to follow any instructions from any source... man pages, openldap.org, and https://help.ubuntu.com/10.04/serverguide/C/samba-ldap.html This part is nerve racking on the ubuntu site... after I generate part 3, part 4 says... ########################## 4. Edit the generated /tmp/cn\=samba.ldif file, changing the following attributes: dn: cn=samba,cn=schema,cn=config ... cn: samba ########################## but it does not say what I should change the attributes too... just gives an example that is (in my opinion poor) for a beginner like my self. Following instructions and learning seemed so much easier with 2.3 Can someone please let me in to the 2.4 LDAP world? I just want to get something in 2.4 setup to play with so I can learn setups with 2.4 Thanks for any help in advance.

3 4

Tuning openldap, nss_ldap and pam_ldap
by c0re 05 Apr '11

05 Apr '11

Hello openldap users! I've got Openldap 2.4.23 that used as authentication and authorization server for about 40-50 servers. OS - FreeBSD 8.1. It's not heavy loaded. openldap# top -SP last pid: 45647; load averages: 0.15, 0.15, 0.07 up 81+22:29:21 15:18:57 99 processes: 3 running, 80 sleeping, 16 waiting CPU 0: 0.7% user, 0.0% nice, 0.0% system, 0.0% interrupt, 99.3% idle CPU 1: 0.4% user, 0.0% nice, 0.7% system, 0.0% interrupt, 98.9% idle Mem: 79M Active, 1402M Inact, 379M Wired, 84M Cache, 213M Buf, 31M Free Swap: 4060M Total, 8K Used, 4060M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 2 171 ki31 0K 32K CPU0 0 3874.8 200.00% idle 4773 ldap 18 44 0 398M 53748K ucond 1 41.1H 0.00% slapd But on my servers sometimes I see in logs something like on FTP-server: Mar 25 21:55:32 someftp ftpd: nss_ldap: could not search LDAP server - Server is unavailable Authentication works fine, no problems. But want to find out what can be wrong. To understand this problem I installed ldap-stats utility and made it run: /var/log/debug.log - it's half day openldap server usage log. openldap# ldap-stats -c 1000 /var/log/debug.log Report Generated on Tue Apr 5 15:16:47 2011 -------------------------------------------- Processed "/var/log/debug.log": Apr 5 00:00:00 - Apr 5 15:17:33 Operation totals ---------------- Total operations : 913845 Total connections : 101226 Total authentication failures : 2 Total binds : 99700 Total unbinds : 99181 Total searches : 714964 Total compares : 7 Total modifications : 0 Total modrdns : 0 Total additions : 0 Total deletions : 0 Unindexed attribute requests : 0 Operations per connection : 9.03 # Uses Filter ---------- ----------------------------------------------------------- 615504 (&(objectClass=posixAccount)(uid=mailer-daemon)) 90699 (&(objectClass=posixGroup)) 6833 (&(objectClass=posixAccount)(uid=root)) 2236 (&(objectClass=posixAccount)(uid=hiddenuser1)) 669 (&(objectClass=posixGroup)(memberUid=root)) 318 (&(objectClass=posixAccount)(uid=testacc)) 87 (&(objectClass=posixGroup)(memberUid=postfix)) 87 (&(objectClass=posixAccount)(uid=postfix)) 81 (objectClass=posixAccount) 68 (&(objectClass=posixAccount)(uid=debian-exim)) 68 (&(objectClass=posixGroup)(memberUid=Debian-exim)) 39 (&(objectClass=posixAccount)(uid=normaluser)) 34 (&(objectClass=posixAccount)(uidNumber=7333)) 30 (&(objectClass=posixGroup)(memberUid=hiddenuser1)) 29 (&(objectClass=posixGroup)(memberUid=chelovek)) 29 (&(objectClass=posixAccount)(uid=chelovek)) 27 (&(objectClass=posixAccount)(uid=user0)) 23 (&(objectClass=posixAccount)(uid=nobody)) 21 (&(objectClass=posixAccount)(uid=user1)) 18 (&(objectClass=posixAccount)(uid=user2)) 16 (&(objectClass=posixAccount)(uid=user3)) 15 (&(objectClass=posixAccount)(uid=user4)) 12 (&(objectClass=posixAccount)(uid=user5)) 11 (&(objectClass=posixAccount)(uidNumber=7330)) 10 (&(objectClass=posixAccount)(uid=user15)) 9 (&(objectClass=posixAccount)(uid=user16)) 8 (&(objectClass=posixAccount)(uidNumber=7333)) 6 (&(objectClass=posixAccount)(uid=user6)) 5 (&(objectClass=posixAccount)(uid=user7)) 5 (cn=defaults) 4 (&(objectClass=posixAccount)(uidNumber=7228)) 4 (&(objectClass=shadowAccount)(uid=user1)) 4 (&(objectClass=posixAccount)(uid=user9)) 4 (&(objectClass=posixAccount)(uid=user10)) 4 (&(objectClass=posixAccount)(uid=user11)) 3 (&(objectClass=posixAccount)(uid=user12)) 3 (&(objectClass=posixAccount)(uid=user13)) 3 (&(objectClass=posixAccount)(uid=user14)) ............... and MANY others that has 1 use in this stats. I think this many queries from mail relay server. * user1 and etc - just hidden real users. What can I do to tune nss? Can you point me in a right direction? Do not know what to look at. If you need any additional information, logs and etc - I'll provide it. Thanks in advance!

1 0

Custom ldapSyntax
by Peter Schütt 05 Apr '11

05 Apr '11

Hallo, I use OpenLDAP 2.4.19 and I try to build an own gender attribute. I need a custom syntax for the value, "M" or "W". I cannot find a description for ldapsyntax, I only find an example and I try this: attributetype ( 1.3.6.1.4.1.xxxxxx.2.2.4.4 NAME ( 'gender' 'sex' ) DESC 'Gender: M for male, F for female' SYNTAX 1.3.6.1.4.1.xxxxxx.2.2.5.1 SINGLE-VALUE ) ldapsyntax ( 1.3.6.1.4.1.xxxxxx.2.2.5.1 NAME 'GenderType' DESC 'Case Insensitive Gender Type' X-VALIDATE-RE '^(?i)M|W|m|w$' ) but I think X-VALIDATE-RE is an extension for another LDAP-Server not for OpenLDAP because it does not work: [LDAP: error code 21 - gender: no validator for syntax 1.3.6.1.4.1.xxxxxx.2.2.5.1] How can I create my own custom syntax? Thanks for any hints. Ciao Peter Schütt

3 3

update referral per rid
by Hendrik van der Ploeg 05 Apr '11

05 Apr '11

Hello everyone, I have multiple syncrepl rid's defined. Every rid points to a different physical ldapprovider. But they all end with dc=domain,dc=nl. Like this: site 1: dc=n010101,dc=domain,dc=nl site 2: dc=n010102,dc=domain,dc=nl CONFIG EXAMPLE: suffix "dc=domain,dc=nl" directory /var/lib/ldap syncrepl rid=000 provider=ldaps://pdc.provider0.domain.nl syncrepl rid=001 provider=ldaps://pdc.provider1.domain.nl What I want is to assign per site/syncrepl-rid a referral so the correct update request will be sent to the right ldapprovider. Is it possible to do this? Help is very much appreciated. Best regards, Hendrik van der Ploeg Noordwijkerhout The Netherlands

1 0

Re: Antwort: Re: RHEL 6 OpenLDAP 2.4.19-15.el6 init problem
by Quanah Gibson-Mount 04 Apr '11

04 Apr '11

--On April 4, 2011 3:00:34 PM +0200 Simone Piccardi <piccardi(a)truelite.it> wrote: Hi Simone. First, keep your replies on the list. > On 01/04/2011 18:11, Quanah Gibson-Mount wrote: >> Hi Markus, >> >> While I understand this is often the case with companies, this policy is >> short sighted. If you want to have a stable, secure, and functional LDAP >> server, then you need to be able to build OpenLDAP from source. >> > That's true, but is true also for a lot of other programs. However, OpenLDAP is an amazingly complex piece of software, which a lot of other programs are not. > And if you need to build everything from source, it will become soon a > manutention nightmare (often you have to do so for a lot of different > machines). I didn't say for him to build everything from source. I said to build OpenLDAP from source. Personally, I do build everything that OpenLDAP uses from source myself, short of the kernel & gcc. > So that kind of policy is a must in a lot of cases, and your suggestion > cannot be accepted. I don't care whether or not you accept what I said. It wasn't a suggestion, it is the result of over a decade of experience working with LDAP software from a number of projects. > Not having good packages in a distribution harms everyone, but > unfortunately this is a general problem, not affecting just RedHat or > OpenLDAP. Correct. And this is something the OpenLDAP Foundation has zero control over. The distributions decide what OpenLDAP releases they include. The distributions decide what patches they apply to their OpenLDAP builds. The distributions occasionally apply their own patches to OpenLDAP that can break it in horrible ways. Distributions do not update their OpenLDAP builds after they release a particular OS, either. So again, if someone chooses against better advice to use the build a distribution provides, then they need to seek help from those who provide the build they are using. If that is not acceptable to them, then they either need to learn to build OpenLDAP themselves so they can use current releases rather than ones that have had hundreds of bugs fixed since their release, or they should use a version of OpenLDAP that comes with support from a company that provides such a thing. Symas is a good example of that. If they choose to use a distribution build, and then contact the OpenLDAP foundation about problems they face with it, the first thing they are going to be asked to do is to upgrade their software. If their policy doesn't allow that, then they need to contact the distributor. Not the foundation. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: 8 principal limitation in openldap
by Srivatsav M 04 Apr '11

04 Apr '11

appreciate any help/pointers on resolving this issue. thanks Ramakant > On 1 April 2011 03:25, Srivatsav M <srivatsav.mudumba(a)gmail.com> wrote: > >> Hi, >> >> I was triaging this issue and I ran into another mysterious area, it >> doesn't look like the number (8) of principals/RDN is the problem and infact >> the length/size of the RDN's could be the issue. Please find the >> /etc/ldap.conf files attached renamed according to the AD/openldap server >> being configured. >> >> a. In the ad_ldap_conf_size the number of characters is around 3137 for >> the nss_base_<map>. On line 122, if i just make the 80 as 8 in the end of >> the string, the command "getent passwd" is working and it lists all the >> users registered in the ldap.conf file but otherwise it doesn't show any >> user. >> >> b. In the open_ldap_conf_size_issue the number of characters is around >> 3103 for the nss_base_<map>. In the end of the file if i just comment the >> last two lines, the "getent passwd" is working and it lists all the users >> registered in the ldap.conf file but otherwise it doesn't show any user. >> >> from these findings this looks more like some buffer issue, can you >> please help me with the following. >> 1. Any particular method/file that I should be looking for to check this >> buffer size may be even in the nss_ldap library or so >> 2. If there is a buffer size issue of say around 3137 characters (bytes >> for that), what would be the best value to increase it. >> >> appreciate any help >> >> Thanks >> Ramakanth >> >> On 30 March 2011 01:17, Srivatsav M <srivatsav.mudumba(a)gmail.com> wrote: >> >>> Please find below the answers to your questions: >>> >>> 1. > >> We are using OpenLDAP for authenticating users registered in a >>> LDAP >>> >>> > >> server (Open LDAP, Active Directory). >>> >>> Which one? Or both? >>> >>> Our dev environment has openLDAP and AD servers and we have tested this issue against each of them individually and are able to reproduce it against both the types of LDAP servers >>> >>> 2. Users shouldn't be "registered in the /etc/ldap.conf file". >>> >> Can you please help me understand why I shouldn't be using this in the >>> ldap.conf file? >>> >>> 3. Please supply a full copy of your /etc/ldap.conf, or at least a >>> representative one, and provide the example output of 'getent passwd >>> username' and 'groups >>> >>> >> attached along with this mail >>> >>> username' for the user who doesn't authenticate. You may also want to supply >>> the relevant PAM configuration files. >>> >>> $ getent passwd >>> root <xxxxxxxxx> >>> test_user:somepwd:1002:1002:Test User:/home/testuser:/bin/bash >>> test_people1:*:10004:10004:Test People1:/home/test_people1:/bin/bash >>> >>> >> All external users are not able to login after adding the 8th principal/RDN >>> >>> /etc/pam.d/common-auth >>> >>> auth required pam_env.so >>> auth sufficient pam_ldap.so use_first_pass >>> auth required pam_unix2.so >>> >>> /etc/pam.d/common-account >>> >>> account required pam_unix2.so >>> account sufficient pam_localuser.so >>> account required pam_ldap.so use_first_pass >>> >>> /etc/pam.d/common-session >>> >>> >>> session required pam_limits.so >>> session required pam_unix2.so >>> session required pam_mkhomedir.so skel=/etc/skel/ >>> session optional pam_ldap.so >>> session optional pam_umask.so >>> >>> Also, please provide details of your LDAP client (distribution release, what versions of nss_ldap and pam_ldap you are running). >>> >>> >> openldap2-client-2.3.32-0.25 >>> >> nss_ldap-259-4.3 >>> >>> 4. Do we know what the actual problem is? Do we know it would be solved >>> by nss-ldapd? >>> >>> There might be a simple misunderstanding here, or a simple configuration problem, and switching software might not solve that. >>> >>> Additionally, the distribution in question may have a different preferred LDAP client. >>> >>> >> based on the above information, would it be possible for pointing any config. issues? , please do let me know if you need any further information. >>> >>> thanks >>> >>> Ramakanth >>> >>> >>> On 25 March 2011 20:23, Marco Pizzoli <marco.pizzoli(a)gmail.com> wrote: >>> >>>> Hi, >>>> I could be corrected if I'm wrong, but this problem is not related to >>>> OpenLDAP. It's a nss_ldap problem. >>>> nss_ldap is a client library that's used by linux vendors to achieves >>>> seamless integration of users against *a* LDAP server. >>>> >>>> I had a similar problem with a complex configuration and bypassed (not >>>> solved) the problem by modifying my client configuration. >>>> >>>> I reduced the number of ldap server configured to be accessed: from 4 to >>>> 3. >>>> I reduced the number of users defined in *nss_initgroups_ignoreusers*directive: i had about 40 listed in it... >>>> >>>> Etc... >>>> >>>> Make some tries and tell me if you can solve it. >>>> >>>> Marco >>>> >>>> >>>> >>>> On Thu, Mar 24, 2011 at 9:25 PM, Srivatsav M < >>>> srivatsav.mudumba(a)gmail.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> We are using OpenLDAP for authenticating users registered in a LDAP >>>>> server (Open LDAP, Active Directory). After adding 8 principals >>>>> (/etc/ldap.conf), none of the users registered in the /etc/ldap.conf file >>>>> are able to login. >>>>> >>>>> nss_base_passwd >>>>> OU=engg,DC=mycompany,DC=region,DC=someplace,DC=myarea,DC=compname,DC=parentcompname >>>>> nss_base_shadow >>>>> OU=engg,DC=mycompany,DC=region,DC=someplace,DC=myarea,DC=compname,DC=parentcompname >>>>> nss_base_group >>>>> OU=engg,DC=mycompany,DC=region,DC=someplace,DC=myarea,DC=compname,DC=parentcompname >>>>> >>>>> >>>>> Can you please share the reason for this 7 limitation in the open ldap >>>>> library. or how I can fix this issue. I am looking i for the header file in >>>>> the source files whhich has this constant or limitation defined. >>>>> >>>>> Tried googling, but it appears that no one has encountered this issue. >>>>> Some customers are running into this issue and it has become a severity 1 >>>>> issue to fix. >>>>> >>>>> Thanks >>>>> Ramakanth >>>>> >>>> >>>> >>>> >>>> -- >>>> _________________________________________ >>>> Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi. >>>> Jim Morrison >>>> >>> >>> >> >

2 1

"ldap_sasl_bind_s failed (-1)" makes me in trouble... [episode 2]
by Olivier Pavilla 04 Apr '11

04 Apr '11

As I said in my last mail. I got this: slap_client_connect: URI=ldaps://wtf.wtf.fr:636 DN="cn=replicaiufm,ou=useraccess,dc=wtf,dc=fr" ldap_sasl_bind_s failed (-1) There's this line in the /etc/ldap/ldap.conf: TLS_REQCERT never the certificate is localized in /etc/ldap/cacerts unverre:/home/olivier# cat /etc/ldap/ldap.conf | grep "TLS" TLS_CACERT /etc/ldap/cacerts/chain-4302-wtf.wtf.fr.pem TLS_CERT /etc/ldap/cacerts/chain-4302-wtf.wtf.fr.pem # TLS_CACERTDIR /etc/ldap/cacerts TLS_REQCERT never So then I added this to /etc/ldap/slapd.conf: loglevel stats args trace sync I restarted slapd: slapd -u openldap -g openldap -l LOCAL4 -s 0 -h ldap:/// ldaps:/// tail -f /var/log/syslog wrote this: Apr 4 09:12:39 unverre slapd[9061]: slapd stopped. Apr 4 09:13:21 unverre slapd[9069]: bdb_back_initialize: initialize BDB backend Apr 4 09:13:21 unverre slapd[9069]: bdb_back_initialize: Berkeley DB 4.6.21: (September 27, 2007) Apr 4 09:13:21 unverre slapd[9069]: bdb_db_init: Initializing BDB database Apr 4 09:13:21 unverre slapd[9069]: >>> dnPrettyNormal: <dc=wtf,dc=fr> Apr 4 09:13:21 unverre slapd[9069]: <<< dnPrettyNormal: <dc=wtf,dc=fr>, <dc=wtf,dc=fr> Apr 4 09:13:21 unverre slapd[9069]: >>> dnPrettyNormal: <cn=luz2,dc=wtf,dc=fr> Apr 4 09:13:21 unverre slapd[9069]: <<< dnPrettyNormal: <cn=luz2,dc=wtf,dc=fr>, <cn=luz2,dc=wtf,dc=fr> Apr 4 09:13:21 unverre slapd[9069]: >>> dnNormalize: <cn=replicaiufm,ou=useraccess,dc=wtf,dc=fr> Apr 4 09:13:21 unverre slapd[9069]: <<< dnNormalize: <cn=replicaiufm,ou=useraccess,dc=wtf,dc=fr> Apr 4 09:13:21 unverre slapd[9069]: >>> dnNormalize: <dc=wtf,dc=fr> Apr 4 09:13:21 unverre slapd[9069]: <<< dnNormalize: <dc=wtf,dc=fr> Apr 4 09:13:21 unverre slapd[9069]: >>> dnNormalize: <cn=Subschema> Apr 4 09:13:21 unverre slapd[9069]: <<< dnNormalize: <cn=subschema> [cut] Apr 4 09:13:21 unverre slapd[9070]: slapd startup: initiated. Apr 4 09:13:21 unverre slapd[9070]: backend_startup_one: starting "cn=config" Apr 4 09:13:21 unverre slapd[9070]: config_back_db_open Apr 4 09:13:21 unverre slapd[9070]: config_build_entry: "cn=config" Apr 4 09:13:21 unverre slapd[9070]: config_build_entry: "cn=module{0}" Apr 4 09:13:21 unverre slapd[9070]: config_build_entry: "cn=schema" Apr 4 09:13:21 unverre slapd[9070]: config_build_entry: "cn={0}core" Apr 4 09:13:21 unverre slapd[9070]: config_build_entry: "cn={1}cosine" Apr 4 09:13:21 unverre slapd[9070]: config_build_entry: "cn={2}nis" Apr 4 09:13:21 unverre slapd[9070]: config_build_entry: "cn={3}inetorgperson" Apr 4 09:13:21 unverre slapd[9070]: config_build_entry: "cn={4}internet2" Apr 4 09:13:21 unverre slapd[9070]: config_build_entry: "cn={5}supann" Apr 4 09:13:21 unverre slapd[9070]: config_build_entry: "cn={6}mailUniv" Apr 4 09:13:21 unverre slapd[9070]: config_build_entry: "cn={7}unrc" Apr 4 09:13:21 unverre slapd[9070]: config_build_entry: "olcDatabase={-1}frontend" Apr 4 09:13:21 unverre slapd[9070]: config_build_entry: "olcDatabase={0}config" Apr 4 09:13:21 unverre slapd[9070]: config_build_entry: "olcDatabase={1}bdb" Apr 4 09:13:21 unverre slapd[9070]: config_build_entry: "olcOverlay={0}syncprov" Apr 4 09:13:21 unverre slapd[9070]: backend_startup_one: starting "dc=wtf,dc=fr" Apr 4 09:13:21 unverre slapd[9070]: bdb_db_open: "dc=wtf,dc=fr" Apr 4 09:13:21 unverre slapd[9070]: bdb_db_open: database "dc=wtf,dc=fr": dbenv_open(/var/lib/ldap). Apr 4 09:13:21 unverre slapd[9070]: => bdb_entry_get: ndn: "dc=wtf,dc=fr" Apr 4 09:13:21 unverre slapd[9070]: => bdb_entry_get: oc: "(null)", at: "contextCSN" Apr 4 09:13:21 unverre slapd[9070]: bdb_dn2entry("dc=wtf,dc=fr") Apr 4 09:13:21 unverre slapd[9070]: => bdb_dn2id("dc=wtf,dc=fr") Apr 4 09:13:21 unverre slapd[9070]: <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) Apr 4 09:13:21 unverre slapd[9070]: slapd starting Apr 4 09:13:21 unverre slapd[9070]: =>do_syncrepl rid=008 Apr 4 09:13:21 unverre slapd[9070]: slap_client_connect: URI=ldaps://wtf.wtf.fr:636 DN="cn=replicaiufm,ou=useraccess,dc=wtf,dc=fr" ldap_sasl_bind_s failed (-1) Apr 4 09:13:21 unverre slapd[9070]: do_syncrepl: rid=008 rc -1 retrying Anyone can tall me what does mean this: slap_client_connect: URI=ldaps://wtf.wtf.fr:636 DN="cn=replicaiufm,ou=useraccess,dc=wtf,dc=fr" ldap_sasl_bind_s failed (-1) Do I got this message because of this: bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) WTH is DB_NOTFOUND? Does thi mean DB_CONFIG is missing? However unverre:/home/olivier# ls /var/lib/ldap/DB* /var/lib/ldap/DB_CONFIG -- S.C.I.R.C. Orléans (Bourgogne) - I.U.F.M. Centre-Val de Loire 72 Rue du Faubourg Bourgogne - 45044 ORLEANS Cedex 1 Tel : 02-38-49-**-** , mailto:ølivier.pavilla@univ-orleans.fr

2 1

could not work in C++?
by owen nirvana 04 Apr '11

04 Apr '11

I try to access ldap data in C++, and write a small example which open and close ldap, compiled by g++ error is the following: error: 'ldap_init' was not decalred in this scope error: 'ldap_simple_bind_s' was not decalred in this scope error: 'ldap_unbind' was not decalred in this scope I have added extern "C" {} block. With my means, it will be compiled using gcc actually. So it work fine in gcc, it should be fine in g++. gtalk:freeespeech@gmail.com

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical