openldap-technical

openldap-technical@openldap.org

3 participants
9937 discussions

Re: memberof in openldap
by Howard Chu 28 Mar '14

28 Mar '14

Brad Hartlove wrote: > I get everything you said. I also understand that this may be a valid > permissions issue. If the answer is "it isn't supposed to be done and the > server will prevent that", that is what I will go with. This is not my > first dance, but if I already knew every detail of LDAP's code, I wouldn't > be on this mailing list. There is no such thing as "LDAP's code" - LDAP is a protocol definition built on a data model. There is "OpenLDAP code" and "SunDS code" etc., various other implementations of the protocol and data model. It is well documented that Sun/Netscape/RedHat/Microsoft implemented the specs incorrectly. As I have said, I am seeing this defined in > another LDAP's objectClass, so someone figured it out right, wrong, or > indifferent. I am not here to argue, so if that is what I go with, so be > it. > Brad Hartlove > > -----Original Message----- > From: Howard Chu [mailto:hyc@symas.com] > Sent: Friday, March 28, 2014 11:08 AM > To: Michael Ströder; brad.hartlove(a)g2-inc.com; > openldap-technical(a)openldap.org > Subject: Re: memberof in openldap > > Michael Ströder wrote: >> Brad Hartlove wrote: >>> The core problem is why can I not add the operational attribute to my >>> custom objectclass. >> >> Operational attributes are simply not normal user attributes. >> >> If your LDAP client is supposed to alter an attribute via LDAP it has >> to be a user attribute. Period. > > That's only a partial answer. > > Brad, the answer is "go read the LDAP spec" - operational attributes are > never part of any objectclass definition, and the server is free to use > them in any entry regardless of objectclass. > > The OpenLDAP manpages are not here to teach you the basics of LDAP. You're > expected to read the specs and know the basics of LDAP. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Syncrepl Multi-Master with multiple BDB backends
by Michael 28 Mar '14

28 Mar '14

I have two servers i'd like to setup to do MMR. I have several BDB backends that I would like to replicate. My question is do I need to create a "replicate" user for each BDB backend as well as a syncrepl statement under each BDB definition and an acl to allow the sync user to read the each BDB? Consider the slapd configuration below. Or is is possible to just setup one user with read access to all of my BDB backends and then setup just one syncrepl statement? serverID 1 ldap://txeduds1 serverID 2 ldap://txeduds2 database bdb suffix "dc=il,dc=edu,dc=com" rootdn "cn=LDAPAdmin,dc=il,dc=edu,dc=com" rootpw xxxx directory /var/lib/ldap/ldap.edu.il monitoring off syncrepl rid=001 provider=ldap://txeduds1:389 type=refreshAndPersist retry="60 10 300 +" searchbase="dc=il,dc=edu,dc=com" attrs="*,+" schemachecking=off bindmethod=simple starttls=no tls_reqcert=never binddn="cn=ilreplicator,ou=ilservice,dc=il,dc=edu,dc=com" credentials=xxxx ##Syncrepl overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 mirrormode on limits dn.exact="cn=ilreplicator,ou=ilservice,dc=il,dc=edu,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited #################################################################################### #################################################################################### access to attrs=userpassword by dn.base="cn=njreplicator,ou=njservice,dc=nj,dc=edu,dc=com read by self write by anonymous auth by * none database bdb suffix "dc=nj,dc=edu,dc=com" rootdn "cn=LDAPAdmin,dc=nj,dc=edu,dc=com" rootpw xxxx directory /var/lib/ldap/ldap.edu.nj monitoring off syncrepl rid=001 provider=ldap://txeduds1:389 type=refreshAndPersist retry="60 10 300 +" searchbase="dc=nj,dc=edu,dc=com" attrs="*,+" schemachecking=off bindmethod=simple starttls=no tls_reqcert=never binddn="cn=njreplicator,ou=njservice,dc=nj,dc=edu,dc=com" credentials=xxx ##Syncrepl overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 mirrormode on limits dn.exact="cn=njreplicator,ou=njservice,dc=nj,dc=edu,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited #################################################################################### #################################################################################### access to attrs=userpassword by dn.base="cn=gareplicator,ou=gaservice,dc=ga,dc=edu,dc=com" read by self write by anonymous auth by * none database bdb suffix "dc=ga,dc=edu,dc=com" rootdn "cn=LDAPAdmin,dc=ga,dc=edu,dc=com" rootpw xxx directory /var/lib/ldap/ldap.edu.ga syncrepl rid=001 provider=ldap://txeduds1:389 type=refreshAndPersist retry="60 10 300 +" searchbase="dc=ga,dc=edu,dc=com" attrs="*,+" schemachecking=off bindmethod=simple starttls=no tls_reqcert=never binddn="cn=gareplicator,ou=gaservice,dc=ga,dc=edu,dc=com" credentials=xxx ##Syncrepl overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 mirrormode on

2 2

cn=config replication mistake
by Ferenc Wagner 28 Mar '14

28 Mar '14

Hi, First, please let me tell you the story of my adventure yesterday. I'll summarize my questions at the end. I've set up a simple master-slave replicated system some time ago (stock Debian wheezy OpenLDAP, version 2.4.31-1+nmu2): dn: olcDatabase={0}config,cn=config olcSyncrepl: {0}rid=1 provider=ldap://elm.niif.hu [...] dn: olcDatabase={1}mdb,cn=config olcSyncrepl: {0}rid=2 provider=ldap://elm.niif.hu [...] The slave opened two connections to the master, and everything worked fine. Then I enabled TLS and put in a CNAME record, so that the master became accessible as ldaps://ldap-master.niif.hu. I decided to also switch over the replication traffic to the SSL channel, so ldapmodified the above attributes to contain provider=ldaps://ldap-master.niif.hu. This pretty much broke the system, because the master server suddenly started to replicate from itself, thus became read-only. Finding no other option, I stopped the "master" slapd and edited back the providers to their previous values (above) in the olcDatabase={0}config.ldif and olcDatabase={1}mdb.ldif files under the cn=config directory of my server configuration. I know these files should not be edited, but I found no other way. This move made the master recognized itself again in the provider URI, so it did not start replicating and became writeable. My edits, however, did not propagate to the slave, probably because I did not change the internal attributes (entryCSN?) so this was expected. Also, slapcat started to report CRC warnings in some LDIF files while dumping the databases, which was also understandable for the edited ones, but not so much for cn=config.ldif (if I remember correctly). I tried to fix these by doing some dummy changes by ldapmodify to the database entries. For both, I added an extra olcAccess attribute, then deleted it. These operations made the slave switch back its syncrepl connections to the ldap port from ldaps, but also instantly broke the slave server, which stopped returning results and instead logged lots of slapd[27944]: => mdb_idl_fetch_key: cursor failed: Invalid argument (22) lines. Having no better idea, I restarted the slave server, which fortunately returned it to normal working condition. So, my questions: 1. How does the "self-recognition" (by which the master does not start replicating from itself) work, why did it fail when I changed the provider URI to ldaps? Did using a CNAME (instead of some FQDN of the server) confuse it? Could this be fixed by adding an appropriate subjectAltName to the server TLS certificate? Or by adding some olcServerID attributes? 2. How could I have handled the read-only situation, instead of editing forbidden LDIF files? Would setting olcMirrorMode have been possible (without olcServerIDs around)? 3. Is my setup in a reliable and consistent state now, or should I expect sudden future failures? I mean, were the "cursor failed" errors fixed for good by the slave server restart? Please also feel free to educate me on any other points, as needed. :) -- Thanks, Feri.

2 2

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical