openldap-technical

openldap-technical@openldap.org

9 participants
9868 discussions

Using LMDB without memory mapped files
by José Felix Torre Santos 20 Jan '16

20 Jan '16

Hello. I am using LMDB in an investigation project. It works perfectly with persistence and concurrent processes. But in some occasions I want to run an standalone process without persistence and as fast as possible. I could do it with other binary-tree libraries written in C, but I’d like not to rewrite mi code. Is there any way to configure or modify LMDB code to work in main memory instead memory mapped files? Thanks in advance. [cid:image9234d9.PNG@cd3fba1a.44af0ea3]<http://www.semantic-systems.com> José Felix Torre Santos Responsable de Plataforma Repcon jts(a)semantic-systems.com T: +34 94 454 55 50 SOPORTE: +34 902 310 123 www.semantic-systems.com<http://www.semantic-systems.com> [cid:imaged7b0f2.PNG@4b89a6f6.41bfb648] ________________________________ Este correo electrónico y en su caso cualquier fichero adjunto al mismo contienen información de carácter confidencial exclusivamente dirigida a sus destinatarios. Queda prohibida su divulgación, copia o distribución a terceros sin la previa autorización escrita de SEMANTIC SYSTEMS, S.L. En el caso de haber recibido este correo electrónico por error, rogamos nos notifique inmediatamente esta circunstancia mediante su reenvío a la dirección electrónica del remitente. Los datos personales que Ud. nos haya facilitado y, especialmente su dirección de correo electrónico, figuran incorporados a un fichero con el fin de gestionar nuestras relaciones y cuya responsabilidad corresponde a SEMANTIC SYSTEMS, S.L., que garantiza el tratamiento de sus datos de carácter personal de conformidad con la Ley Orgánica 15/1999, de Protección de Datos de Carácter Personal. Ud. podrá ejercitar sus derechos de acceso, rectificación, cancelación y oposición ante SEMANTIC SYSTEMS, S.L., en la Avenida del Txoriherri nº 9 2º planta – Derio (48160) Vizcaya The information contained in and/or attached to this e-mail message is intended solely for the use of the addressees. It is not to be disclosed, copied or distributed to any third party without the prior written permission of SEMANTIC SYSTEMS, S.L. If you have received this email in error, please immediately notify us by forwarding to the sender's email address. Personal data provided to us and especially your email address, are stored in a file in order to manage our relationships and SEMANTIC SYSTEMS, S.L. is the responsible, ensuring the processing of your personal data in accordance with the Organic Law 15/1999 of 13 December on the Protection of Personal Data. You can exercise your rights of access, rectification, cancellation and opposition to SEMANTIC SYSTEMS, S.L., Avenida del Txoriherri nº 9 2º planta – Derio (48104) Vizcaya

2 1

slapd dying with mdb databases
by Angel L. Mateo 19 Jan '16

19 Jan '16

Hello, After changing my databases from hdb to mdb I'm having problems with it. My problem is that after a few days of slapd running without any problem (this time it has been more than a week), then it suddenly dies and whenever I restart it, it dies immediately. I have run slapd with -d 16000 and last debug message it shows is: 569decb8 <= root access granted 569decb8 => access_allowed: search access granted by manage(=mwrscxd) ../../../../../servers/slapd/back-mdb/../../../libraries/liblmdb/mdb.c:5276: Assertion 'NUMKEYS(mp) > 1' failed in mdb_page_search_root() In order to be able to run again, I have to delete the database and start slapd with no db (so it reloads it completely with syncrepl). I'm running openldap 2.4.43 (compiled by me) in a ubuntu 14.04 server. Any help? -- Angel L. Mateo Martínez Sección de Telemática Área de Tecnologías de la Información y las Comunicaciones Aplicadas (ATICA) http://www.um.es/atica Tfo: 868887590 Fax: 868888337

2 1

Output differs when searching via translucent proxy
by M. P. 15 Jan '16

15 Jan '16

Hello all, We have an installation of openldap like this: master <- slave <- translucent proxy. All the installation is on debian Jessie 8.2 with slapd version 2.4.40+dfsg-1+deb8u1. When searching/binding with ldapsearch everything seems ok. I mean I have the results I expect. We have an application called CAS to authenticate users on web appplications and there is where things start to be strange. When configuring CAS to communicate with the slave, there is no problem, users can authenticate without issue. But when CAS is configured to communicate with the translucent proxy, there is not possible for users to be authenticated. I looked a different places, changed different parameters playing with ldap protocol, search reference responses, automatic referral chasing, ... but can't make it work. In the logs I have this: ldapsearch request: the output is ok from client to translucent proxy: slapd[8845]: conn=1019 fd=13 ACCEPT from IP=10.93.64.180:57730 (IP=0.0.0.0:389) slapd[8845]: conn=1019 op=0 BIND dn="uid=cas-auth,ou=SI,ou=access,dc=domain,dc=com" method=128 slapd[8845]: conn=1019 op=0 BIND dn="uid=cas-auth,ou=SI,ou=access,dc=domain,dc=com" mech=SIMPLE ssf=0 slapd[8845]: conn=1019 op=0 RESULT tag=97 err=0 text= slapd[8845]: conn=1019 op=1 SRCH base="ou=people,dc=domain,dc=com" scope=2 deref=3 filter="(uid=myuser)" slapd[8845]: conn=1019 op=1 SRCH attr=1.1 slapd[8845]: conn=1019 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= slapd[8845]: conn=1019 op=2 UNBIND slapd[8845]: conn=1019 fd=13 closed from tranlucent proxy to slave: slapd[6491]: conn=1759 fd=25 ACCEPT from IP=10.93.64.207:37513 (IP=0.0.0.0:389) slapd[6491]: conn=1759 op=0 [IP=10.93.64.180 USERNAME=uid=cas-auth,ou=SI,ou=access,dc=domain,dc=com] BIND dn="uid=cas-auth,ou=SI,ou=access,dc=domain,dc=com" method=128 slapd[6491]: conn=1759 op=0 [IP=10.93.64.180 USERNAME=uid=cas-auth,ou=SI,ou=access,dc=domain,dc=com] BIND dn="uid=cas-auth,ou=SI,ou=Access,dc=domain,dc=com" mech=SIMPLE ssf=0 slapd[6491]: conn=1759 op=0 [IP=10.93.64.180 USERNAME=uid=cas-auth,ou=SI,ou=access,dc=domain,dc=com] RESULT tag=97 err=0 text= slapd[6491]: conn=1759 op=1 [IP=10.93.64.180 USERNAME=uid=cas-auth,ou=SI,ou=access,dc=domain,dc=com] SRCH base="ou=people,dc=domain,dc=com" scope=2 deref=3 filter="(uid=myuser)" slapd[6491]: conn=1759 op=1 [IP=10.93.64.180 USERNAME=uid=cas-auth,ou=SI,ou=access,dc=domain,dc=com] SRCH attr=* + slapd[6491]: conn=1759 op=1 [IP=10.93.64.180 USERNAME=uid=cas-auth,ou=SI,ou=access,dc=domain,dc=com] SEARCH RESULT tag=101 err=0 nentries=1 text= slapd[6491]: conn=1759 op=2 UNBIND slapd[6491]: conn=1759 fd=25 closed CAS request: I don't have the output I expect from client to translucent proxy: slapd[8845]: conn=1017 fd=13 ACCEPT from IP=10.93.64.180:57109 (IP=0.0.0.0:389) slapd[8845]: conn=1017 op=0 BIND dn="uid=cas-auth,ou=si,ou=access,dc=domain,dc=com" method=128 slapd[8845]: conn=1017 op=0 BIND dn="uid=cas-auth,ou=si,ou=access,dc=domain,dc=com" mech=SIMPLE ssf=0 slapd[8845]: conn=1017 op=0 RESULT tag=97 err=0 text= slapd[8845]: conn=1017 op=1 SRCH base="ou=People,dc=domain,dc=com" scope=2 deref=3 filter="(uid=myuser)" slapd[8845]: conn=1017 op=1 SRCH attr=1.1 slapd[8845]: conn=1017 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= slapd[8845]: conn=1017 fd=13 closed (connection lost) from tranlucent proxy to slave: slapd[6491]: conn=1747 fd=13 ACCEPT from IP=10.93.64.207:35881 (IP=0.0.0.0:389) slapd[6491]: conn=1747 op=0 [IP=10.93.64.180 USERNAME=uid=cas-auth,ou=si,ou=access,dc=domain,dc=com] BIND dn="uid=cas-auth,ou=si,ou=access,dc=domain,dc=com" method=128 slapd[6491]: conn=1747 op=0 [IP=10.93.64.180 USERNAME=uid=cas-auth,ou=si,ou=access,dc=domain,dc=com] BIND dn="uid=cas-auth,ou=SI,ou=Access,dc=domain,dc=com" mech=SIMPLE ssf=0 slapd[6491]: conn=1747 op=0 [IP=10.93.64.180 USERNAME=uid=cas-auth,ou=si,ou=access,dc=domain,dc=com] RESULT tag=97 err=0 text= slapd[6491]: conn=1747 op=1 UNBIND slapd[6491]: conn=1747 fd=13 closed The configuration part relative to translucent: # Entry 1: olcOverlay={3}translucent,olcDatabase={2}mdb,cn=config dn: olcOverlay={3}translucent,olcDatabase={2}mdb,cn=config objectclass: olcConfig objectclass: olcOverlayConfig objectclass: olcTranslucentConfig objectclass: top olcoverlay: {3}translucent olctranslucentbindlocal: TRUE # Entry 2: olcDatabase={0}ldap,olcOverlay={3}translucent,olcDatabase={2}m... dn: olcDatabase={0}ldap,olcOverlay={3}translucent,olcDatabase={2}mdb,cn=conf ig objectclass: olcConfig objectclass: olcLDAPConfig objectclass: olcTranslucentDatabase objectclass: olcDatabaseConfig olcdatabase: {0}ldap olcdbchasereferrals: TRUE olcdbidassertauthzfrom: {0}* olcdbidassertbind: bindmethod="simple" binddn="uid=roaccess,ou=access,dc=dom ain,dc=com" credentials="hideme" mode="self" olcdbsessiontrackingrequest: TRUE olcdburi: ldap://ldap-data.domain.it I do not really know where to look else. I'll continue to try different things to make it work but any idea/suggestion/correction is welcome. Thank you in advance for your time. -- ------------ M. P.

1 1

Merging databases with translucent
by M. P. 14 Jan '16

14 Jan '16

Hi, We are on a process of merging datas from a remote database to a local database. The two databases have the same base dn. To ease this process, I thought for a way to make a union of the remote database and the local database until remote datas are merged to local database. From my reading I found this thread http://thread.gmane.org/gmane.network.openldap.technical/11893 that is something that correspond I think to what I want. The practical part is done on a debian jessie 8.2 with openldap 2.4.40+dfsg-1+deb8u1 version. The local database definition is like this. # Entry 1: olcDatabase={2}mdb,cn=config dn: olcDatabase={2}mdb,cn=config objectclass: olcDatabaseConfig objectclass: olcMdbConfig olcaccess: ... olcdatabase: {2}mdb olcdbdirectory: /var/lib/ldap/base_dn olcdbindex: ... olcdbmaxsize: 104857600 olclimits: ... olcrootdn: cn=admin,dc=base,dc=dn olcrootpw: {SSHA}....... olcsuffix: dc=base,dc=dn olcsyncrepl: ... olcupdateref: ldap://master.ldap.server/ To this database definition I have added this part to make translucent work. # ldapadd -Y EXTERNAL -H ldapi:/// << EOF dn: olcOverlay=translucent,olcDatabase={2}mdb,cn=config objectClass: olcConfig objectClass: olcOverlayConfig objectClass: olcTranslucentConfig objectClass: top olcOverlay: translucent EOF # ldapadd -Y EXTERNAL -H ldapi:/// << EOF dn: olcDatabase=ldap,olcOverlay={3}translucent,olcDatabase={2}mdb,cn=config objectClass: olcConfig objectClass: olcLDAPConfig objectClass: olcTranslucentDatabase objectClass: olcDatabaseConfig olcDbURI: ldap://remote-ldap.server olcDbIDAssertBind: bindmethod="simple" binddn="cn=binddn,dc=base,dc=dn" credentials="onepassword" mode="self" EOF With this configuration, I can see on the local server, the entries that are available on the remote server only, an ldapsearch does not return entries available on the local server. Is this the normal behavior ? Another problem is that when I restart slapd, I have an error like this slapd[3440]: @(#) $OpenLDAP: slapd (Sep 11 2015 15:11:55) $#012#011buildd@babin:/build/openldap-nFTO9j/openldap-2.4.40+dfsg/debian/build/servers/slapd slapd[3441]: syncprov_db_open: invalid config, lastmod must be enabled slapd[3441]: backend_startup_one (type=mdb, suffix="dc=linkeo,dc=com"): bi_db_open failed! (-1) slapd[3441]: DIGEST-MD5 common mech free slapd[3441]: slapd stopped. I have to reload config without dn: olcOverlay=translucent,olcDatabase={2}mdb,cn=config and dn: olcDatabase=ldap,olcOverlay={3}translucent,olcDatabase={2}mdb,cn=config entries to make slapd start properly. Can somebody tell me what I have done wrong ? Thanks, -- ------------ M. P.

3 6

LMBD questions (stat & copy)
by Bruno Freudensprung 14 Jan '16

14 Jan '16

Hi, I am trying to detect MDB_MAP_FULL based on mdb_stat(txn, dbi, &stat) results and I am wondering if I am on the right track or doing things correctly. I have a small and simple test program (http://pastebin.com/SPCYgWMC) exhibiting the following behavior (consistent between Windows 7 64-bit and Ubuntu 15.10 64-bit - latest version of lmdb cloned and recompiled on Linux): * Inserting 20990 key value pairs in a database is OK when using one transaction. Just before commiting the write transaction, mdb_stat(txn, dbi, &stat) shows that the total number of pages (253) is very close the the number of pages of the map (256). Indeed, adding another entry leads to MDB_MAP_FULL. To put it shortly, this scenario looks OK (I am assuming there might be 3 "internal-purpose" pages not shown by mdb_stat) and can be tested by setting the stat_test variable to 0 at line 20 of the test program. * Inserting same 20990 key value pairs in a database fails (MDB_MAP_FULL encountered at 19357) when using two consecutive write transactions. Just before MDB_MAP_FULL, mdb_stat(txn, dbi, &stat) shows that the total number of pages (232) is "quite far" from the the number of pages of the map (256), leading my MDB_MAP_FULL detection heuristic to fail. It means that only 92% of the total amount of data can be sucessfully added to the database. Other scenarii (with same key/value lengths though) stop at 85% only. This can be tested by setting the stat_test variable to 1 (line 20). By "total number of pages" I mean ms_branch_pages + ms_leaf_pages + ms_overflow_pages. Do you think I am on a wrong track? (maybe mdb_stat does not show 24 "internal-purpose" pages in the second case? or I am forgetting something?). One last remark: it seems that mdb_env_copy(db, copy_dir) is possible during a write transaction on Windows (like stated in the documentation), but not on Linux (the test program seems to be stopped on a mutex at line 62). This can be tested by changing the copy_test variable to 1 at line 19. Is it expected given my program? Best regards, Bruno.

2 7

slapd dies
by BÖSCH Christian 14 Jan '16

14 Jan '16

hi, i have two openldap servers 2.4.43 on freebsd 10.2 with multimaster replication. if i add on one node a dynamicobject, the other node dies immediatly. has anybody an idea? regards,chris --- added this: dn: uid=vkw-guest,ou=people,o=abc.net sn: VKW Guest objectClass: organizationalPerson objectClass: person objectClass: dynamicObject objectClass: inetLocalMailRecipient objectClass: inetOrgPerson objectClass: top uid: vkw-guest cn: VKW Guest the log says: Jan 13 13:08:40 openldap2 slapd[75017]: daemon: activity on 1 descriptor Jan 13 13:08:40 openldap2 slapd[75017]: daemon: activity on: Jan 13 13:08:40 openldap2 slapd[75017]: 30r Jan 13 13:08:40 openldap2 slapd[75017]: Jan 13 13:08:40 openldap2 slapd[75017]: daemon: read activity on 30 Jan 13 13:08:40 openldap2 slapd[75017]: daemon: select: listen=6 active_threads=0 tvp=zero Jan 13 13:08:40 openldap2 slapd[75017]: daemon: select: listen=7 active_threads=0 tvp=zero Jan 13 13:08:40 openldap2 slapd[75017]: daemon: select: listen=8 active_threads=0 tvp=zero Jan 13 13:08:40 openldap2 slapd[75017]: daemon: select: listen=9 active_threads=0 tvp=zero Jan 13 13:08:40 openldap2 slapd[75017]: daemon: select: listen=10 active_threads=0 tvp=zero Jan 13 13:08:40 openldap2 slapd[75017]: connection_get(30) Jan 13 13:08:40 openldap2 slapd[75017]: connection_get(30): got connid=0 Jan 13 13:08:40 openldap2 slapd[75017]: =>do_syncrepl rid=021 Jan 13 13:08:40 openldap2 slapd[75017]: =>do_syncrep2 rid=021 Jan 13 13:08:40 openldap2 slapd[75017]: do_syncrep2: rid=021 cookie=rid=021,sid=001,csn=20160113120840.025550Z#000000#001#000000 Jan 13 13:08:40 openldap2 slapd[75017]: syncrepl_message_to_entry: rid=021 DN: uid=vkw-guest,ou=people,o=abc.net, UUID: 2074bc1e-4e3a-1035-92a1-ed72d2e7074a Jan 13 13:08:40 openldap2 slapd[75017]: >>> dnPrettyNormal: <uid=vkw-guest,ou=people,o=abc.net> Jan 13 13:08:40 openldap2 slapd[75017]: <<< dnPrettyNormal: <uid=vkw-guest,ou=people,o=abc.net>, <uid=vkw-guest,ou=people,o=abc.net> Jan 13 13:08:40 openldap2 slapd[75017]: >>> dnPretty: <cn=admin,o=xyz.net> Jan 13 13:08:40 openldap2 slapd[75017]: <<< dnPretty: <cn=admin,o=xyz.net> Jan 13 13:08:40 openldap2 slapd[75017]: >>> dnNormalize: <cn=admin,o=xyz.net> Jan 13 13:08:40 openldap2 slapd[75017]: <<< dnNormalize: <cn=admin,o=xyz.net> Jan 13 13:08:40 openldap2 slapd[75017]: >>> dnPretty: <cn=admin,o=xyz.net> Jan 13 13:08:40 openldap2 slapd[75017]: <<< dnPretty: <cn=admin,o=xyz.net> Jan 13 13:08:40 openldap2 slapd[75017]: >>> dnNormalize: <cn=admin,o=xyz.net> Jan 13 13:08:40 openldap2 slapd[75017]: <<< dnNormalize: <cn=admin,o=xyz.net> Jan 13 13:08:40 openldap2 slapd[75017]: >>> dnPretty: <uid=vkw-guest,ou=people,o=abc.net> Jan 13 13:08:40 openldap2 slapd[75017]: <<< dnPretty: <uid=vkw-guest,ou=people,o=abc.net> Jan 13 13:08:40 openldap2 slapd[75017]: >>> dnNormalize: <uid=vkw-guest,ou=people,o=abc.net> Jan 13 13:08:40 openldap2 slapd[75017]: <<< dnNormalize: <uid=vkw-guest,ou=people,o=abc.net> Jan 13 13:08:40 openldap2 slapd[75017]: >>> dnPretty: <cn=Subschema> Jan 13 13:08:40 openldap2 slapd[75017]: <<< dnPretty: <cn=Subschema> Jan 13 13:08:40 openldap2 slapd[75017]: >>> dnNormalize: <cn=Subschema> Jan 13 13:08:40 openldap2 slapd[75017]: <<< dnNormalize: <cn=subschema> Jan 13 13:08:40 openldap2 slapd[75017]: syncrepl_entry: rid=021 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jan 13 13:08:40 openldap2 slapd[75017]: => mdb_search Jan 13 13:08:40 openldap2 slapd[75017]: mdb_dn2entry("o=abc.net") Jan 13 13:08:40 openldap2 slapd[75017]: => mdb_dn2id("o=abc.net") Jan 13 13:08:40 openldap2 slapd[75017]: <= mdb_dn2id: got id=0x1 Jan 13 13:08:40 openldap2 slapd[75017]: => mdb_entry_decode: Jan 13 13:08:40 openldap2 slapd[75017]: <= mdb_entry_decode Jan 13 13:08:40 openldap2 slapd[75017]: => access_allowed: search access to "o=abc.net" "entry" requested Jan 13 13:08:40 openldap2 slapd[75017]: <= root access granted Jan 13 13:08:40 openldap2 slapd[75017]: => access_allowed: search access granted by manage(=mwrscxd) Jan 13 13:08:40 openldap2 slapd[75017]: search_candidates: base="o=abc.net" (0x00000001) scope=2 Jan 13 13:08:40 openldap2 slapd[75017]: => mdb_filter_candidates Jan 13 13:08:40 openldap2 slapd[75017]: EQUALITY Jan 13 13:08:40 openldap2 slapd[75017]: => mdb_equality_candidates (entryUUID) Jan 13 13:08:40 openldap2 slapd[75017]: => key_read Jan 13 13:08:40 openldap2 slapd[75017]: mdb_idl_fetch_key: [5ec43656] Jan 13 13:08:40 openldap2 slapd[75017]: <= mdb_index_read: failed (-30798) Jan 13 13:08:40 openldap2 slapd[75017]: <= mdb_equality_candidates: id=0, first=0, last=0 Jan 13 13:08:40 openldap2 slapd[75017]: <= mdb_filter_candidates: id=0 first=0 last=0 Jan 13 13:08:40 openldap2 slapd[75017]: mdb_search_candidates: id=0 first=0 last=0 Jan 13 13:08:40 openldap2 slapd[75017]: mdb_search: no candidates Jan 13 13:08:40 openldap2 slapd[75017]: send_ldap_result: conn=-1 op=0 p=0 Jan 13 13:08:40 openldap2 slapd[75017]: send_ldap_result: err=0 matched="" text="" Jan 13 13:08:40 openldap2 slapd[75017]: syncrepl_entry: rid=021 be_search (0) Jan 13 13:08:40 openldap2 slapd[75017]: syncrepl_entry: rid=021 uid=vkw-guest,ou=people,o=abc.net Jan 13 13:08:40 openldap2 slapd[75017]: slap_queue_csn: queueing 0x846348780 20160113120840.025550Z#000000#001#000000 Jan 13 13:08:40 openldap2 slapd[75017]: ==> unique_add <uid=vkw-guest,ou=people,o=abc.net> Jan 13 13:08:40 openldap2 slapd[75017]: => access_allowed: manage access to "uid=vkw-guest,ou=people,o=abc.net" "entry" requested Jan 13 13:08:40 openldap2 slapd[75017]: <= root access granted Jan 13 13:08:40 openldap2 slapd[75017]: => access_allowed: manage access granted by manage(=mwrscxd) Jan 13 13:08:40 openldap2 slapd[75017]: unique_add: administrative bypass, skipping Jan 13 13:08:40 openldap2 slapd[75017]: => mdb_entry_get: ndn: "ou=people,o=abc.net" Jan 13 13:08:40 openldap2 slapd[75017]: => mdb_entry_get: oc: "dynamicObject", at: "(null)" Jan 13 13:08:40 openldap2 slapd[75017]: mdb_dn2entry("ou=people,o=abc.net") Jan 13 13:08:40 openldap2 slapd[75017]: => mdb_dn2id("ou=people,o=abc.net") Jan 13 13:08:40 openldap2 slapd[75017]: <= mdb_dn2id: got id=0x3 Jan 13 13:08:40 openldap2 slapd[75017]: => mdb_entry_decode: Jan 13 13:08:40 openldap2 slapd[75017]: <= mdb_entry_decode Jan 13 13:08:40 openldap2 slapd[75017]: => mdb_entry_get: found entry: "ou=people,o=abc.net" Jan 13 13:08:40 openldap2 slapd[75017]: <= mdb_entry_get: failed to find objectClass dynamicObject Jan 13 13:08:40 openldap2 slapd[75017]: mdb_entry_get: rc=16

3 4

add sortvals after database loaded?
by Phil Pishioneri 14 Jan '16

14 Jan '16

Environment: slapd: openldap-ltb-2.4.42-1.el6.x86_64 config: slapd.conf (file) database: mdb After a database has been loaded, can the sortvals option be added/changed without having to dump and reload the database? The slapd.conf (and slapd-config) man page doesn't mention any need for a reload, but wanted to verify. -Phil

2 2

Removing olcAccess entry
by Katherine Faella 12 Jan '16

12 Jan '16

For the life of me I can not figure out the syntax for performing this. Here is my snippet of config.ldif: dn: olcDatabase={1}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcSuffix: dc=sakai,dc=uri,dc=edu olcAccess: {0}to * by peername.ip="131.128.1.0%255.255.255.0" +0 break by peername.ip="131.128.122.0%255.255.255.0" +0 break by peername.ip="158.123 .255.8%255.255.255.248" +0 break by peername.ip="127.0.0.1" +0 break olcAccess: {1}to * by dn.regex="^URIEduauthid=.+,dc=sakai,dc=uri,dc=edu$$" read by * auth olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=Manager,dc=sakai,dc=uri,dc=edu ..... I need to remove the olcAccess {0} as we need to access this server from new ips. We are using a firewall to protect the server going forward. I have created the file removeips containing: dn: olcDatabase={1}hdb,cn=config changetype: modify delete: olcAccess olcAccess: {1} Running the command ldapmodify -W -x -h antons.uri.edu -D "cn=admin,cn=config" -f /root/ldapscripts/removeips gives me: modifying entry "olcDatabase={1}hdb,cn=config" ldap_modify: No such attribute (16) additional info: modify/delete: olcAccess: no such attribute What am I doing wrong? Thanks, Kathy -- Katherine Faella tel: (401) 874-4469 Senior Technical Programmer kmf(a)uri.edu University of Rhode Island University Computing Systems(UCS) 210 Flagg Road Kingston, Rhode Island

4 4

lmdb VL32 high virtual address usage
by Jeremiah Morrill 11 Jan '16

11 Jan '16

This sort of coincides with ITS issue 8347 I just reported. With ldmb VL32, I’ve noticed that it can eat up a lot of memory space. Sometimes ~500mb for an 800mb db after reading every record, one by one using the same readonly transaction/cursor. I found that modifying MDB_ERPAGE_SIZE from 16384 to 256 brought virtual memory usage down substantially (~30megs). I have not noticed any adverse effects from this change or MDB_MAP_FULL. The mapped address spaces to seem to get deallocated on the close of the environment, not the transaction, which sounds like its being cached in the env->me_rpages for reasons explained in mdb_rpage_get comments. Is the mem map cache supposed to be this aggressive by design, or just because this area of the code is so new...or simply a usage error on my part? If it’s by design, could there be a consideration to make MDB_ERPAGE_SIZE a #define’able value in the public lmdb.h so one could tweak the behavior? -Jer

2 1

Re: what databases are to be replicated for a slave?
by Jephte Clain 09 Jan '16

09 Jan '16

2015-12-29 20:38 GMT+04:00 Quanah Gibson-Mount <quanah(a)zimbra.com>: > --On Tuesday, December 29, 2015 12:48 PM +0400 Jephte Clain > <jephte.clain(a)univ-reunion.fr> wrote: > > > >>> No. Replicas do not accept writes. Replicas do not have a master >>> configuration for cn=config. Replica's do not have server IDs. >> >> ok I guess I understand. this is the reason why I usually call them >> "slaves", not replicas (but I messed things up and called them replicas >> this time ^^) >> I also have replicas that only replicate data (or a subset of data) for >> some services > > > No. The terms replica and slave are interchangeable. As are master and > provider. Given the very negative connotations of the concept of masters > and slaves, the preferred terms are "provider" instead of "master" and > "replica" instead of "slaves". Aaargh, now I can't help thinking about "providers" whipping "replicas". slapd can be so cruel sometimes :-) And in case you wonder, here in reunion island we have a (relatively) long history of slavery. We even have a day to commemorate abolition of slavery: december 20th > > >> the slaves are there in case of catastrophic failure of both masters (we >> had one of these failure for another service due to a problem with the >> shared storage. No one want to have this kind of emergency...) >> If the master(s) crash, I just have to choose a slave as the new master, >> slapcat the cn=config database, update the provider address, slapadd the >> updated config, and update the loadbalancer settings. this is a bit of >> work but at least we can restore service in a (relatively) small amount >> of time. > > > If they accept writes, they are not slaves/replicas. If you are replicating > cn=config across all the systems, then they must all be masters. Your > general description above sounds like you do not correctly understand how > MMR functions. OK... I finally understand what was bothering you My replicas do _not_ accept writes. Sorry to have let you think so I have two setups: - a "legacy" one, with one master accessible to the applications that can write, and two complete replicas (data + cn=config) behind a loadbalancer for the reads. One of these replicas could become the new master if the needs arise. And there are a bunch of partial replicas (only a subset of data) for some specific services. The reason is on our vmware farm, network access is regularly cut (don't know why, the system guy neither), and these services cannot reconnect on their own... piece of #$*! software :( - a "new" one, with two masters in mirror mode (only one get the writes at anytime thanks to the loadbalancer), and two replicas (only data) which get all the reads. I feel like configuring chaining to be able to write from the replicas, but I have no experience of the benefits of this configuration... I have read the admin guide several times, but I am open to any suggestion to improve my skills > >>> Accesslog is unique to a given master. >> >> Ok that's what I wanted to know for sure >> >> Shouldn't the doc stat this clearly? > > > Please file an ITS noting the docs should be updated on this point. Ok. I may even provide a patch. I'll do it tomorrow. Have a nice day/night (don't know where you live ^^) Regards, Jephté -- Jephté CLAIN | Développeur, Intégrateur d'applications Service Système d'Information Direction des Systèmes d'Information Tél: +262 262 93 86 31 || Gsm: +262 692 29 58 24

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