openldap-technical

openldap-technical@openldap.org

7 participants
9864 discussions

memberof in openldap
by Brad Hartlove 28 Mar '14

28 Mar '14

I have been trying to include the memberOf attribute in a new objectClass. If I just set it to "MAY" (for example), it complains about using an operational attribute in my definition. I have seen quite a few Q&As about this, but I am really trying to understand where this issue is originating. Maybe I haven't looked at the right one yet. OpenDJ has the ability to utilize it in custom classes, so I was hoping to be able to also do the same in OpenLDAP. Thoughts?

4 5

OpenLDAP Installation and Extending Schema Walkthru
by Tim Watkins 27 Mar '14

27 Mar '14

I am somewhat knew to LDAP and have been trying to find a fully functioning WalkThru to install OpenLDAP 2.4.39 on an Ubuntu 12.04 or 13.10. After installing I would like to have the same for extending the Schema. I have tried multiple times with ones that I have found online or YouTube, but so far, everything is missing something or another. If someone has document to point me that is complete, it would be greatly appreciated! Tim

1 1

What is the default of `-b`?
by Peng Yu 27 Mar '14

27 Mar '14

Hi, The man page says the following. `-b` *searchbase* : Use *searchbase* as the starting point for the search instead of the default. I'm wondering what is the default. If I don't specify -b, I will get an error. Does anyone know how show all the contents from the database? Thanks. $ sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=config dn dn: cn=config dn: cn=module{0},cn=config dn: cn=schema,cn=config dn: cn={0}core,cn=schema,cn=config dn: cn={1}cosine,cn=schema,cn=config dn: cn={2}nis,cn=schema,cn=config dn: cn={3}inetorgperson,cn=schema,cn=config dn: olcBackend={0}hdb,cn=config dn: olcDatabase={-1}frontend,cn=config dn: olcDatabase={0}config,cn=config dn: olcDatabase={1}hdb,cn=config $ sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// dn No such object (32) -- Regards, Peng

2 1

Re: Kerberos issue running OpenLDAP on Mac OS X Mavericks
by Dan White 27 Mar '14

27 Mar '14

Putting the email list back into the CC. On 03/20/14 10:16 -0500, Denis Ahearn wrote: >Thanks for responding Dan. We have spent the past several days taking the >information you provided and trying to get smarter about how OpenLDAP and >Kerberos work on Mac OS X Mavericks. Unfortunately we haven't made much >progress. I think it may be because the way we are trying to use OpenLDAP >is not the standard way that Apple intends it to be used from a server or >client standpoint, so there doesn't seem to be any documentation available >that speaks directly to our use case. Responses to your questions are >listed below. > >>> If you are authenticating against Active Directory, how does slapd fit >>> into the picture? > >Our Rails app authenticates using Active Directory only in staging and >production. We're using OpenLDAP (slapd) in our local development >environments to simulate this (i.e. to provide a local LDAP server that >serves the purpose that Active Directory does in production). To test >locally, we define an organization, groups and users in ldif files that get >loaded into OpenLDAP using ldapadd. > >>> Do you have an authz-regex rule mapping the authentication identity to >>> this? Can you reproduce this problem with ldapsearch/ldapwhoami, using >>> the same parameters as your ruby code? > >Are you referring to setting an authz-regex rule in slapd.conf? If so, we >do not have any authz-regex rules in our slapd.conf. I attached the >slapd.conf and ldap.conf files that are being used with OpenLDAP if that >helps. > >>> It appears your client has a kerberos ticket, and is attempting GSSAPI >>> authentication. You can verify that with klist or your OS's kerberos >>> utilities. > >I ran the klist command on the Mac that is having this issue. Output is >below: > >$ klist > >Credentials cache: API:77A8E90B-01BF-4F18-A94E-035C3AB25A59 > > Principal: dahearn(a)BWD.INT > > Issued Expires Principal > > >>> The client side Ruby code may allow you to configure a sasl mechanism. >>> If not, see ldap.conf(5) and set an appropriate LDAPSASL_MECH >>> environment variable or set SASL_MECH within your home .ldaprc file >>> (to, for instance, DIGEST-MD5). > >We tried the suggestions you listed above, none of which seemed to have any >effect on OpenLDAP's behavior (output in slapd.log is exactly the same). I'm still not clear if ruby is attempting SASL GSSAPI authentication or not. Your syslog (auth facility) may tell you that. Since you have a ticket, it's certainly possible. You can disable GSSAPI in a couple of additional ways: 1) Remove the SASL GSSAPI shared library, assuming your cyrus sasl install was compiled using shared libraries. pluginviewer (or saslpluginview) should list the mechanisms which are installed. 2) Configure a slapd.conf SASL configuration, on the server, which explicitly lists which mechanisms you wish to offer. The FAQ at: http://www.cyrussasl.org/mediawiki/index.php/FAQ details how to *enable* GSSAPI for slapd. Find out where cyrus sasl is looking for config files (e.g. /usr/lib/sasl2 or /etc/sasl2) and create a slapd.conf file with this line: mech_list: PLAIN LOGIN DIGEST-MD5 Are you performing pass-through authentication? In that case, try running saslauthd in debug mode for testing. >We are only using OpenLDAP in our development environment as a way to store >groups and users for testing purposes, and to provide an LDAP server that >our application can talk to in the same way it talks to Active Directory in >our production environment. We rely upon logic in the application (the >Ruby Devise and CanCan gems) to provide the necessary authentication and >authorization services. What I think we need to do is make OpenLDAP not >use Kerberos or other authentication mechanisms, but I haven't been able to >figure out if this is possible and if so, how to do that. Does this sound >like the way to go? If so, can you provide any assistance in setting this >up? Is there anything else I can send you to help you understand our setup? Replace the ruby authentication step with a ldapsearch/ldapwhoami call (with a -d -1 option for debugging on the client side). Or see if you can specify a debug option within Ruby (assuming it is using libldap). If you can figure out how your ruby code is connecting to the server in this way, your problem will likely stand out pretty quickly. A wireshark trace of the ruby ldap connection may help with that as well. -- Dan White

2 3

Changing cert paths may cause openldap to stop
by Nick Milas 27 Mar '14

27 Mar '14

Hi, On 2.4.39 (CentOS 5.10 x86_64), I found that if I attempt to change certificate values but there is an error in a path, openldap stops. I would expect this should be avoided. Openldap should reject the modification and not stop. Running the modification below, it hungs; we press Ctrl-C (and we print a full backtrace), then we find slapd is stopped. Please check the output below. Best regards, Nick Example: ------------------------------------------------------------------------------- Modification file: /root/work/certmod2: ------------------------------------------------------------------------------- dn: cn=config changetype: modify replace: olcTLSCACertificateFile olcTLSCACertificateFile: /usr/local/openldap/etc/openldap/certs/chain-2241.pem - replace: olcTLSCertificateFile olcTLSCertificateFile: /usr/local/openldap/etc/openldap/certs/cert-2241.pem - replace: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /usr/local/openldap/etc/openldap/certs/priv-2241.pem ------------------------------------------------------------------------------- In this case priv-2241.pem does not exist (the correct value would be: key-2241.pem). ------------------------------------------------------------------------------- Modification attempt: ------------------------------------------------------------------------------- # /usr/local/openldap/bin/ldapmodify -h localhost -x -v -W -D "cn=admin,cn=config" -f /root/work/certmod2 ldap_initialize( ldap://localhost ) Enter LDAP Password: replace olcTLSCACertificateFile: /usr/local/openldap/etc/openldap/certs/chain-2241.pem replace olcTLSCertificateFile: /usr/local/openldap/etc/openldap/certs/cert-2241.pem replace olcTLSCertificateKeyFile: /usr/local/openldap/etc/openldap/certs/priv-2241.pem modifying entry "cn=config" <it hungs and we press Ctrl-C> ldap_result: Can't contact LDAP server (-1) ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- (gdb) backtrace full #0 0x00000033bf830265 in raise () from /lib64/libc.so.6 No symbol table info available. #1 0x00000033bf831d10 in abort () from /lib64/libc.so.6 No symbol table info available. #2 0x00000033bf829706 in __assert_fail () from /lib64/libc.so.6 No symbol table info available. #3 0x000000000044f66d in slap_send_ldap_result (op=0xcd75580, rs=0x2ba278651c20) at result.c:813 tmp = <value optimized out> otext = 0x2ba278650664 "" oref = 0x0 __PRETTY_FUNCTION__ = "slap_send_ldap_result" #4 0x000000000042ca7f in config_back_modify (op=0xcd75580, rs=0x2ba278651c20) at bconfig.c:5926 cfb = 0x8787a0 ce = 0xffffffff last = 0x600000000 ml = 0x6 ca = {argc = 2, argv = 0xce77200, argv_size = 513, line = 0xce75c00 "/usr/local/openldap/etc/openldap/certs/priv-2241.pem", tline = 0xc81a880 "\220d\224\f", fname = 0x5c7c99 "slapd", lineno = 0, log = "olcTLSCertificateKeyFile: value #0", '\000' <repeats 4089 times>, reply = {err = 0, msg = '\000' <repeats 255 times>}, depth = 0, valx = -1, values = {v_int = 209823808, v_uint = 209823808, v_long = 209823808, v_ulong = 209823808, v_ber_t = 209823808, v_string = 0xc81a840 "/usr/local/openldap/etc/openldap/certs/priv-2241.pem", v_bv = {bv_len = 209823808, bv_val = 0x0}, v_dn = {vdn_dn = {bv_len = 209823808, bv_val = 0x0}, vdn_ndn = {bv_len = 0, bv_val = 0x0}}, v_ad = 0xc81a840}, rvalue_vals = 0x0, rvalue_nvals = 0x0, op = 0, type = 8, ca_op = 0xcd75580, be = 0x87a520, bi = 0x0, ca_entry = 0xc81ab48, ca_private = 0xc81a280, cleanup = 0x427850 <config_tls_cleanup>, table = Cft_Global} rdn = {bv_len = 2, bv_val = 0xc81a7e0 "cn=config"} rad = 0xc7c4e90 do_pause = 1 #5 0x0000000000455ff7 in fe_op_modify (op=0xcd75580, rs=0x2ba278651c20) at modify.c:303 repl_user = <value optimized out> bd = 0x87a520 textbuf = "\005\000\000\000\000\000\000\000xZ\327\f\000\000\000\000h[\327\f\000\000\000\000\003\000\000\000\000\000\000\000\b\000\000\000\000\000\000\000\270Z\327\f\000\000\000\000P\271}\f\000\000\000\000\000\\\347\f\000\000\000\000\320[\347\f\000\000\000\000:\213E", '\000' <repeats 21 times>, "4\000\000\000\000\000\000\000\000\\\347\f\000\000\000\000\270U\327\f", '\000' <repeats 12 times>, "@\\\347\f", '\000' <repeats 12 times>"\340, \272}\f\000\000\000\000\020", '\000' <repeats 15 times>"\304, XE\000\000\000\000\000\340:\306\f\000\000\000\000\000\001\000\000\000\000\000\000\320\032ex\242+\000\000@\034ex\242+\000\000\200U\327\f\000\000\000\000\001\000\000\000\000\000\000\000\270U\327\f\000\000\000\000\250U\327\f\000\000\000\000\340:\306\f\000\000\000\000\251\063"... #6 0x0000000000456762 in do_modify (op=0xcd75580, rs=0x2ba278651c20) at modify.c:177 dn = {bv_len = 9, bv_val = 0xcd75459 "cn=config"} textbuf = "\000\b\000\000\000\000\000\000\000\001\000\000\000\000\000\000 \000\000\000\000\000\000\000\004", '\000' <repeats 15 times>"\377, \017\000\000\000\000\000\000\260\005\002", '\000' <repeats 14 times>"\360, \377\377\377\377\377\377\000\000\000\000~", '\000' <repeats 27 times>"\271, \312\065\062\"", '\000' <repeats 11 times>"\340, I\265\277\063\000\000\000\000\000\020\000\000\000\000\000\000\000\020\000\000\000\000\000\001\000\000\000\000\000\000\000\340:\306\f\000\000\000\000\000\000\020\000\000\000\000\000\236@\207\277\063", '\000' <repeats 13 times>, "\020\000\000\000\000\000p\035ex\242+\000\000Mc[\000\000\000\000\000\000\000\020\000\000\000\000\000\373\210E\000\000\000\000\000\001\000\000\000\000\000\000\000\330\002I\000\000\000\000\000\200U\327\f\000\000\000\000]\226F\---Type <return> to continue, or q <return> to quit--- 000\000\000\000" tmp = 0x0 #7 0x000000000043f0d5 in connection_operation (ctx=0x2ba278651d70, arg_v=<value optimized out>) at connection.c:1155 rc = <value optimized out> cancel = <value optimized out> op = 0xcd75580 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = -1, sr_matched = 0x0, sr_text = 0x2ba278650664 "", sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = { r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 102 opidx = SLAP_OP_MODIFY conn = 0xc9c2d20 memctx = 0xcc63ae0 memctx_null = 0x0 __PRETTY_FUNCTION__ = "connection_operation" #8 0x000000000043f6af in connection_read_thread (ctx=0x2ba278651d70, argv=<value optimized out>) at connection.c:1291 s = 12 #9 0x000000000058d92c in ldap_int_thread_pool_wrapper (xpool=0xc7c8430) at tpool.c:688 task = 0xcd752f0 work_list = <value optimized out> ctx = {ltu_id = 47976804591936, ltu_key = {{ltk_key = 0x43e040, ltk_data = 0xcd75950, ltk_free = 0x43e110 <conn_counter_destroy>}, { ltk_key = 0x48ff50, ltk_data = 0xcc63ae0, ltk_free = 0x48ff70 <slap_sl_mem_destroy>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 30 times>}} kctx = <value optimized out> keyslot = 435 hash = <value optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #10 0x00002ba23235583d in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #11 0x00000033bf8d526d in clone () from /lib64/libc.so.6 No symbol table info available. -------------------------------------------------------------------------------

1 0

Failure in 2.4.32: similar experiences?
by Nick Urbanik 26 Mar '14

26 Mar '14

Dear Folks, We have some moderately busy OpenLDAP servers, OpenLDAP 2.4.32 running on CentOS 5.8 on HP BL495cG6 blades, with 24GB RAM, in a cluster of four, using LVS to balance the load. They peak at just over 3000 LDAP connections per second. They stopped serving requests, or at least, began serving them so slowly that they caused an outage. After my colleague restarted slapd, they resumed serving the requests. slapd didn't die, or dump core. Sadly, since the most minimal logging produces 25GB per day, so we have that turned off, and after the event, I now am graphing some of the statistics from the monitor database, though that provides less detail than I would wish. My questions: ============= Has anyone had a similar experience of failure with this version of OpenLDAP specifically, or with any other version? Has anyone any suggestions on what might have happened? I am upgrading LDAP to 2.4.39, but would like to know if there is a known problem that I will resolve by this upgrade. Here is a "sanitised" view of our configuration: # slapd.conf generated by /usr/bin/conform include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/local.schema include /etc/openldap/schema/prefs.schema loglevel stats allow bind_v2 pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args tool-threads 8 password-hash {CRYPT} password-crypt-salt-format "$1$%.8s" TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt TLSCertificateFile /etc/openldap/ldap.syd.crt TLSCertificateKeyFile /etc/openldap/ldap.syd.key ############################################################ # GLOBAL database definition ############################################################ access to dn.base="" by peername.ip=133.3.193.2 read by peername.ip=19.21.201.10 read by * read access to dn.base="cn=Subschema" by * read ############################################################ # ou=tree1,ou=name database definition ############################################################ database bdb suffix "ou=tree1,ou=name" rootdn cn=manager,ou=tree1,ou=name rootpw root-password directory /var/lib/ldap/ou=tree1,ou=name index domain eq,pres index entryCSN eq index entryUUID eq index mail eq,pres index objectClass eq index uid eq,pres shm_key 331 cachesize 100000 idlcachesize 100000 checkpoint 32768 30 idletimeout 3600 writetimeout 90000 access to dn.base="ou=tree1,ou=name" by peername.ip=96.76.69.162 read by * none break access to dn.subtree="ou=tree1,ou=name" by dn.base="cn=Reader,ou=tree1,ou=name" read by peername.ip=205.191.75.42 read by peername.ip=198.132.212.127 read by peername.ip=101.169.45.146 read by peername.ip=212.38.134.82 read by peername.ip=127.0.0.1 read by peername.ip=49.15.162.36 read by peername.ip=142.226.69.215 read by peername.ip=236.107.103.158 read by peername.ip=57.167.92.229 read by peername.ip=138.57.161.36 read by peername.ip=99.33.110.154 read by peername.ip=196.119.159.149 read by peername.ip=44.116.9.128 read by peername.ip=122.234.222.27 read by self peername.ip=154.238.170.210 read by self peername.ip=31.62.15.241 read by self peername.ip=163.226.124.118 read by self peername.ip=92.190.127.61 read by self peername.ip=125.225.28.232 read by self peername.ip=122.148.131.239 read by self peername.ip=118.160.216.124 read by self peername.ip=74.226.71.41 read by self peername.ip=179.149.175.90 read by self peername.ip=235.160.10.186 read by self peername.ip=125.80.123.119 read by self peername.ip=185.5.66.203 read by self peername.ip=158.224.9.61 read by self peername.ip=46.146.95.97 read by self peername.ip=6.182.235.60 read by self peername.ip=7.137.32.196 read by self peername.ip=204.184.227.24 read by self peername.ip=56.10.14.169 read by self peername.ip=165.49.58.78 read by self peername.ip=165.211.155.235 read by self peername.ip=119.216.126.40 read by self peername.ip=94.212.46.227 read by self peername.ip=210.225.203.227 read by self peername.ip=171.235.159.67 read by self peername.ip=28.94.19.93 read by self peername.ip=206.12.128.149 read by self peername.ip=18.223.36.165 read by self peername.ip=35.164.112.79 read by self peername.ip=145.100.109.232 read by self peername.ip=10.230.19.137 read by self peername.ip=86.124.99.133 read by self peername.ip=56.223.60.177 read by self peername.ip=140.114.55.210 read by self peername.ip=216.13.135.39 read by self peername.ip=5.93.220.80 read by self peername.ip=87.215.35.140 read by self peername.ip=162.101.170.221 read by self peername.ip=100.59.12.102 read by self peername.ip=58.223.90.131 read by self peername.ip=124.165.37.123 read by self peername.ip=11.178.120.42 read by self peername.ip=99.205.107.56 read by self peername.ip=31.26.172.88 read by self peername.ip=211.133.184.38 read by self peername.ip=84.215.59.209 read by self peername.ip=13.70.104.6 read by self peername.ip=111.100.110.74 read by self peername.ip=190.199.36.1 read by self peername.ip=236.212.185.240 read by self peername.ip=180.4.69.152 read by self peername.ip=38.63.162.124 read by self peername.ip=68.34.84.216 read by self peername.ip=43.41.142.100 read by self peername.ip=118.225.164.10 read by self peername.ip=40.26.24.236 read by self peername.ip=197.161.148.167 read by self peername.ip=148.163.210.9 read by self peername.ip=161.141.31.120 read by self peername.ip=85.59.211.7 read by self peername.ip=237.59.225.239 read by self peername.ip=29.114.216.84 read by anonymous auth by * none break syncrepl rid=001 provider=ldap://master:389 type=refreshAndPersist bindmethod=simple binddn=cn=syncrepl,ou=tree1,ou=name credentials=syncrepl-password searchbase="ou=tree1,ou=name" retry="5 10 60 +" ############################################################ # ou=tree2,ou=name database definition ############################################################ database bdb suffix "ou=tree2,ou=name" rootdn cn=manager,ou=tree2,ou=name rootpw root-password directory /var/lib/ldap/ou=tree2,ou=name index avcid eq index entryCSN eq index entryUUID eq index gsid eq index objectClass eq shm_key 320 cachesize 100000 idlcachesize 100000 checkpoint 32768 30 idletimeout 3600 writetimeout 90000 access to dn.base="ou=tree2,ou=name" by peername.ip=1.224.5.235 read by * none break access to dn.subtree="ou=tree2,ou=name" by dn.base="cn=Reader,ou=tree2,ou=name" read by peername.ip=124.182.243.237 read by peername.ip=73.200.132.164 read by peername.ip=5.106.199.123 read by peername.ip=243.60.43.234 read by peername.ip=127.0.0.1 read by anonymous auth by * none break syncrepl rid=010 provider=ldap://master:389 type=refreshAndPersist bindmethod=simple binddn=cn=syncrepl,ou=tree2,ou=name credentials=syncrepl-password searchbase="ou=tree2,ou=name" retry="5 10 60 +" ############################################################ # ou=tree3,ou=name database definition ############################################################ database bdb suffix "ou=tree3,ou=name" rootdn cn=manager,ou=tree3,ou=name rootpw root-password directory /var/lib/ldap/ou=tree3,ou=name index entryCSN eq index entryUUID eq index fnn eq index lineid eq index objectClass eq index serviceid eq index ullsid eq shm_key 74 cachesize 100000 idlcachesize 100000 checkpoint 32768 30 idletimeout 3600 writetimeout 90000 access to dn.base="ou=tree3,ou=name" by peername.ip=100.131.166.211 read by * none break access to dn.subtree="ou=tree3,ou=name" by dn.base="cn=Reader,ou=tree3,ou=name" read by peername.ip=39.236.93.167 read by peername.ip=48.145.97.90 read by peername.ip=143.186.10.231 read by peername.ip=35.68.19.116 read by peername.ip=127.0.0.1 read by anonymous auth by * none break syncrepl rid=008 provider=ldap://master:389 type=refreshAndPersist bindmethod=simple binddn=cn=syncrepl,ou=tree3,ou=name credentials=syncrepl-password searchbase="ou=tree3,ou=name" retry="5 10 60 +" ############################################################ # ou=tree4,ou=name database definition ############################################################ database bdb suffix "ou=tree4,ou=name" rootdn cn=manager,ou=tree4,ou=name rootpw root-password directory /var/lib/ldap/ou=tree4,ou=name index cn eq index entryCSN eq index entryUUID eq index objectClass eq shm_key 195 cachesize 100000 idlcachesize 100000 checkpoint 32768 30 idletimeout 3600 writetimeout 90000 access to dn.base="ou=tree4,ou=name" by peername.ip=26.233.142.132 read by * none break access to dn.subtree="ou=tree4,ou=name" by dn.base="cn=Reader,ou=tree4,ou=name" read by peername.ip=127.0.0.1 read by anonymous auth by * none break access to dn.subtree="" by peername.ip=101.156.205.102 read by peername.ip=136.25.130.235 read by peername.ip=136.206.49.17 read by peername.ip=37.21.18.99 read by * none break syncrepl rid=002 provider=ldap://master:389 type=refreshAndPersist bindmethod=simple binddn=cn=syncrepl,ou=tree4,ou=name credentials=syncrepl-password searchbase="ou=tree4,ou=name" retry="5 10 60 +" ############################################################ # ou=tree5,ou=name database definition ############################################################ database bdb suffix "ou=tree5,ou=name" rootdn cn=manager,ou=tree5,ou=name rootpw root-password directory /var/lib/ldap/ou=tree5,ou=name index entryCSN eq index entryUUID eq index gsid eq index objectClass eq index uid eq shm_key 626 cachesize 100000 idlcachesize 100000 checkpoint 32768 30 idletimeout 3600 writetimeout 90000 access to dn.base="ou=tree5,ou=name" by peername.ip=225.143.210.78 read by * none break access to dn.subtree="ou=tree5,ou=name" by dn.base="cn=Reader,ou=tree5,ou=name" read by peername.ip=106.154.145.84 read by peername.ip=197.28.75.183 read by peername.ip=179.151.185.161 read by peername.ip=4.60.182.12 read by peername.ip=127.0.0.1 read by anonymous auth by * none break syncrepl rid=011 provider=ldap://master:389 type=refreshAndPersist bindmethod=simple binddn=cn=syncrepl,ou=tree5,ou=name credentials=syncrepl-password searchbase="ou=tree5,ou=name" retry="5 10 60 +" ############################################################ # ou=tree6,ou=name database definition ############################################################ database bdb suffix "ou=tree6,ou=name" rootdn cn=manager,ou=tree6,ou=name rootpw root-password directory /var/lib/ldap/ou=tree6,ou=name index entryCSN eq index entryUUID eq index objectClass eq index uid eq index username eq shm_key 290 cachesize 100000 idlcachesize 100000 checkpoint 32768 30 idletimeout 3600 writetimeout 90000 access to dn.base="ou=tree6,ou=name" by peername.ip=195.44.90.201 read by * none break access to dn.subtree="ou=tree6,ou=name" by dn.base="cn=Reader,ou=tree6,ou=name" read by peername.ip=131.55.25.176 read by peername.ip=52.151.227.147 read by peername.ip=144.91.87.53 read by peername.ip=51.236.131.115 read by peername.ip=127.0.0.1 read by anonymous auth by * none break syncrepl rid=009 provider=ldap://master:389 type=refreshAndPersist bindmethod=simple binddn=cn=syncrepl,ou=tree6,ou=name credentials=syncrepl-password searchbase="ou=tree6,ou=name" retry="5 10 60 +" ############################################################ # ou=tree7,ou=name database definition ############################################################ database bdb suffix "ou=tree7,ou=name" rootdn cn=manager,ou=tree7,ou=name rootpw root-password directory /var/lib/ldap/ou=tree7,ou=name index entryCSN eq index entryUUID eq index objectClass eq index uid eq index username eq shm_key 105 cachesize 100000 idlcachesize 100000 checkpoint 32768 30 idletimeout 3600 writetimeout 90000 access to dn.base="ou=tree7,ou=name" by peername.ip=82.36.151.29 read by peername.ip=69.183.15.150 read by * none break access to dn.subtree="ou=tree7,ou=name" by peername.ip=81.44.61.5 read by peername.ip=75.34.88.223 read by peername.ip=40.106.122.233 read by dn.base="cn=Reader,ou=tree7,ou=name" read by peername.ip=127.0.0.1 read by anonymous auth by * none break syncrepl rid=003 provider=ldap://master:389 type=refreshAndPersist bindmethod=simple binddn=cn=syncrepl,ou=tree7,ou=name credentials=syncrepl-password searchbase="ou=tree7,ou=name" retry="5 10 60 +" ############################################################ # ou=tree8,ou=name database definition ############################################################ database bdb suffix "ou=tree8,ou=name" rootdn cn=manager,ou=tree8,ou=name rootpw root-password directory /var/lib/ldap/ou=tree8,ou=name index entryCSN eq index entryUUID eq index objectClass eq index uid eq index username eq shm_key 280 cachesize 100000 idlcachesize 100000 checkpoint 32768 30 idletimeout 3600 writetimeout 90000 access to dn.base="ou=tree8,ou=name" by peername.ip=221.195.40.138 read by * none break access to dn.subtree="ou=tree8,ou=name" by dn.base="cn=Reader,ou=tree8,ou=name" read by peername.ip=211.28.110.6 read by peername.ip=4.134.128.66 read by peername.ip=194.183.122.54 read by peername.ip=89.223.206.194 read by peername.ip=28.88.175.182 read by peername.ip=209.169.46.101 read by peername.ip=230.21.178.118 read by peername.ip=41.55.202.55 read by peername.ip=127.0.0.1 read by anonymous auth by * none break syncrepl rid=004 provider=ldap://master:389 type=refreshAndPersist bindmethod=simple binddn=cn=syncrepl,ou=tree8,ou=name credentials=syncrepl-password searchbase="ou=tree8,ou=name" retry="5 10 60 +" ############################################################ # ou=tree9,ou=name database definition ############################################################ database bdb suffix "ou=tree9,ou=name" rootdn cn=manager,ou=tree9,ou=name rootpw root-password directory /var/lib/ldap/ou=tree9,ou=name index entryCSN eq index entryUUID eq index objectClass eq index uid eq index username eq shm_key 122 cachesize 100000 idlcachesize 100000 checkpoint 32768 30 idletimeout 3600 writetimeout 90000 access to dn.base="ou=tree9,ou=name" by peername.ip=153.54.1.23 read by * none break access to dn.subtree="ou=tree9,ou=name" by dn.base="cn=Reader,ou=tree9,ou=name" read by peername.ip=164.215.79.230 read by peername.ip=52.205.194.57 read by peername.ip=69.215.8.144 read by peername.ip=240.46.54.48 read by peername.ip=127.0.0.1 read by anonymous auth by * none break syncrepl rid=006 provider=ldap://master:389 type=refreshAndPersist bindmethod=simple binddn=cn=syncrepl,ou=tree9,ou=name credentials=syncrepl-password searchbase="ou=tree9,ou=name" retry="5 10 60 +" ############################################################ # ou=tree10,ou=name database definition ############################################################ database bdb suffix "ou=tree10,ou=name" rootdn cn=manager,ou=tree10,ou=name rootpw root-password directory /var/lib/ldap/ou=tree10,ou=name index entryCSN eq index entryUUID eq index mtaMacAddress eq index mtaSubcriberKey eq index objectClass eq shm_key 548 cachesize 100000 idlcachesize 100000 checkpoint 32768 30 idletimeout 3600 writetimeout 90000 access to dn.base="ou=tree10,ou=name" by peername.ip=111.64.19.131 read by * none break access to dn.subtree="ou=tree10,ou=name" by dn.base="cn=Reader,ou=tree10,ou=name" read by peername.ip=49.225.102.91 read by peername.ip=169.2.225.154 read by peername.ip=177.202.224.166 read by peername.ip=56.152.182.238 read by peername.ip=157.83.196.154 read by peername.ip=66.220.12.152 read by peername.ip=132.204.57.43 read by peername.ip=222.142.242.198 read by peername.ip=153.130.78.144 read by peername.ip=166.31.243.77 read by peername.ip=226.40.169.1 read by peername.ip=224.110.119.208 read by peername.ip=15.227.192.210 read by peername.ip=45.56.216.152 read by peername.ip=127.0.0.1 read by anonymous auth by * none break syncrepl rid=000 provider=ldap://master:389 type=refreshAndPersist bindmethod=simple binddn=cn=syncrepl,ou=tree10,ou=name credentials=syncrepl-password searchbase="ou=tree10,ou=name" retry="5 10 60 +" ############################################################ # ou=tree11,ou=name database definition ############################################################ database bdb suffix "ou=tree11,ou=name" rootdn cn=manager,ou=tree11,ou=name rootpw root-password directory /var/lib/ldap/ou=tree11,ou=name index entryCSN eq index entryUUID eq index objectClass eq index uid eq index username eq shm_key 215 cachesize 100000 idlcachesize 100000 checkpoint 32768 30 idletimeout 3600 writetimeout 90000 access to dn.base="ou=tree11,ou=name" by peername.ip=51.114.241.35 read by * none break access to dn.subtree="ou=tree11,ou=name" by dn.base="cn=Reader,ou=tree11,ou=name" read by peername.ip=17.32.79.33 read by peername.ip=140.205.127.168 read by peername.ip=190.147.122.157 read by peername.ip=170.66.104.2 read by peername.ip=45.154.226.85 read by peername.ip=116.172.183.88 read by peername.ip=96.51.58.70 read by peername.ip=85.240.27.171 read by peername.ip=127.0.0.1 read by anonymous auth by * none break syncrepl rid=005 provider=ldap://master:389 type=refreshAndPersist bindmethod=simple binddn=cn=syncrepl,ou=tree11,ou=name credentials=syncrepl-password searchbase="ou=tree11,ou=name" retry="5 10 60 +" ############################################################ # ou=tree12,ou=name database definition ############################################################ database monitor rootdn cn=manager,ou=tree12,ou=name rootpw root-password access to dn.subtree="ou=tree12,ou=name" by peername.ip=127.0.0.1 read by * none -- Nick Urbanik http://nicku.org 808-71011 nick.urbanik(a)optusnet.com.au GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24 I disclaim, therefore I am.

1 0

MDB_MAP_FULL: Environment mapsize limit reached
by Aleksander Dzierżanowski 26 Mar '14

26 Mar '14

Hello OpenLDAP guru & fans. Recently I was trying to migrate from 'bdb' to 'mdb' backend by adding temporary additional instance of OpenLDAP. Unfortunately I'm unable to import database both using 'slapadd' or regular replication mechanism. What I got is exact same error: slapadd -b o=mysuffix < /tmp/mysuffix.ldif 5332ec95 => mdb_idl_insert_keys: c_put id failed: MDB_MAP_FULL: Environment mapsize limit reached (-30792) 5332ec95 => mdb_tool_entry_put: index_entry_add failed: err=80 5332ec95 => mdb_tool_entry_put: txn_aborted! Internal error (80) slapadd: could not add entry dn="uid=myuser,ou=People,ou=developers,o=suffix" (line=2080): txn_aborted! Internal error (80) _# 9.26% eta none elapsed none spd 2.3 M/s Closing DB... My bdb 'maxsize' argument is set to 1GB. Database is really small, it contain just few hundred of small entries. My OpenLDAP version is 2.4.38 from OpenLTB project (I'm unable to use 2.4.39 because I need to use CentOS 6.4 version, latest one is for 6.5). Changing only backend to 'bdb' in configuration make import succesfull. Any advices? regards, -- Aleksander

1 1

Not adding attributes
by espeake＠oreillyauto.com 26 Mar '14

26 Mar '14

I have just started getting this error in the past 10 days. There has not been any configuration changes that we can find. In googleing this error I am not finding anything that matches it. If I create an ldif file to add these for the user, that works fine. Mar 25 16:42:21 tn-ldap-1 slapd[14976]: conn=33594 op=17: memberof_value_modify DN="uid=dsmith174,ou=users,dc=oreillyauto,dc=com" add locationEntry="ou=Store4351,ou=Locations,dc=oreillyauto,dc=com" failed err=32 Mar 25 16:42:22 tn-ldap-1 slapd[14976]: conn=33594 op=19: memberof_value_modify DN="uid=dsmith174,ou=users,dc=oreillyauto,dc=com" add oreillyGroup="cn=Store Non-Management,ou=Groups,dc=oreillyauto,dc=com" failed err=32 Mar 25 16:42:22 tn-ldap-1 slapd[14976]: conn=33594 op=21: memberof_value_modify DN="uid=dsmith174,ou=users,dc=oreillyauto,dc=com" add oreillyGroup="cn=Store,ou=Groups,dc=oreillyauto,dc=com" failed err=32 What I do wonder about though in my olcDatabase={1}hdb folder I have two memberOf overlays. This is the first one. # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 a078db21 dn: olcOverlay={0}memberof objectClass: olcOverlayConfig objectClass: olcMemberOf olcOverlay: {0}memberof olcMemberOfDangling: ignore olcMemberOfRefInt: TRUE olcMemberOfGroupOC: groupOfUniqueNames olcMemberOfMemberAD: uniqueMember olcMemberOfMemberOfAD: oreillyGroup structuralObjectClass: olcMemberOf creatorsName: cn=config entryUUID: 91cea156-9e13-1032-84c3-0151b658a842 createTimestamp: 20130820183919Z entryCSN: 20130820183919.833799Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20130820183919Z This is the second one. # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 fe8a4925 dn: olcOverlay={1}memberof objectClass: olcOverlayConfig objectClass: olcMemberOf olcOverlay: {1}memberof olcMemberOfDangling: ignore olcMemberOfRefInt: TRUE olcMemberOfGroupOC: oreillyOrgUnit olcMemberOfMemberAD: uniqueMember olcMemberOfMemberOfAD: locationEntry structuralObjectClass: olcMemberOf creatorsName: cn=config entryUUID: 91ceb650-9e13-1032-84c4-0151b658a842 createTimestamp: 20130820183919Z entryCSN: 20130820183919.834337Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20130820183919Z I have am looking through the application to see if something could have changed in the way it is presenting the data. I haven't found anything yet. Am I correct in that an error 32 means that it couldn't find the uid to add the group to? Thanks, Eric Speake Web Systems Administrator O'Reilly Auto Parts (417) 862-2674 Ext. 1975 This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS � 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.

2 2

question about openldap restore with command sldapadd
by xiaoming zhao 26 Mar '14

26 Mar '14

All, I got one question, when doing openldap restore, in our script, we tried to remove the openldap/data directory, then restore the backup openldap files. but since we have other data added in openldap database after backup. then if we doing backup, it will remove the data newly added after backup. I tried to sldapadd with "-c" option, but the sldapadd command retrun value is 1. so we can't know if this is a error because of existing entry or some other error. Do you have any idea how to handle this case? ignore the existing entry when doing sldapadd. Thanks, Eric.

2 6

unsubscribe
by Alex Samad - Yieldbroker 26 Mar '14

26 Mar '14

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical