openldap-technical

openldap-technical@openldap.org

21 participants
9802 discussions

PANIC: bdb fatal region
by ldap＠mm.st 17 Mar '11

17 Mar '11

I am rebuilding our aging pre 2.2 openldap servers that ran ldbm backend and slurpd. We ran this setup without any issues for many years. The new setup is: RH5 openldap 2.3.43 (Stock RH) bdb backend 4.4.20 (Stock RH) Entries in db- about 1820 LDIF file is about 1.2M Memory- Master 4GB Slave 2GB (will add two more slaves) Database section of slapd.conf: database bdb suffix "o=example.com" rootdn "cn=root">cn=root">cn=root">cn=root,o=example.com" rootpw {SSHA} ..... cachesize 1900 checkpoint 512 30 directory /var/lib/ldap index objectClass,uid,uidNumber,gidNumber,memberUid,uniqueMember eq index cn,mail,surname,givenname eq,subinitial DB_CONFIG: set_cachesize 0 4153344 1 set_lk_max_objects 1500 set_lk_max_locks 1500 set_lk_max_lockers 1500 set_lg_regionmax 1048576 set_lg_bsize 32768 set_lg_max 131072 set_lg_dir /var/lib/ldap set_flags DB_LOG_AUTOREMOVE This new setup appeared to work great for the last 10 days or so. I was able to authenticate clients, add records etc. Running slapd_db_stat -m and slapd_db_stat -c seem to indicate everything was ok. Before I put this setup into production, I got slurpd to function. Then decided to disable slurpd to use syncrepl in refreshonly mode. This also seemed to work fine. I'm not sure if the replication started this or not, but wanted to include all the events that let up to this. I have started to get: bdb(o=example.com): PANIC: fatal region error detected; run recovery On both servers at different times. During this time slapd continues to run which seems to confuse clients that try to use it and they will not try the other server that is listed in ldap.conf. To recover I did: service ldap stop, slapd_db_recover -h /var/lib/ldap, service ldap start. I then commented all the replication stuff out in the slapd.conf and restarted ldap. It will run for a while (varies 5 minutes - ?) then I get the same errors and clients are unable to authenticate. On one of the servers I deleted all the files (except DB_CONFIG) and did a slapadd of a ldif file that I generated every night (without stopping slapd). Same results once I started slapd again. I have enabled debug for slapd and have not seen anything different, I attached gdb to the running slapd and no errors are noted. I even copied a backup copy of slapd.conf prior to the replication settings (even though they are commented out) thinking that maybe something in there was causing it.. Then after several recoveries as described above the systems seem to be working again. One has not generated the error for for over 5.5 hours the other has not had any problems for 2 hours. For some reason after that period when the errors showed up for a while, things seem to be working again, at least for now. I'm nervous about putting this into production until I can get this to function properly without these issues. During the 10 day period with everything working good, the slave would occasional (rarely) get the error and I would do a recovery, but we thought this was due to possible hardware problems. Now I'm not so sure. I have a monitor script that runs slapd_db_stat -m and -c every 5 minutes and nothing seems wrong there, I far as I can tell. I'm hoping someone can help me determine possible causes or things to look at.

3 2

Re: syncrepl consumer with several providers, is it working?
by LALOT Dominique 17 Mar '11

17 Mar '11

Hi Quanah, OK, that's not so easy to migrate large infrastructures, but if you don't see other problems (about our setup), we will migrate our providers to the same version. I'm surprised, replication should be stable for years and in the real world you can't have all your servers at the same level. We are lucky that we can do that, sometimes, it's not possible. Thanks Dom 2011/3/16 Quanah Gibson-Mount <quanah(a)zimbra.com> > --On Wednesday, March 16, 2011 4:13 PM +0100 LALOT Dominique < > dom.lalot(a)gmail.com> wrote: > > Hello, >> >> I'm a little bit worried about that mail and the fact that our setup is >> getting out of sync sometimes. >> http://www.openldap.org/lists/openldap-software/200505/msg00324.html >> >> versions: the providers are all 2.4. The consumer is 2.4.23, some >> providers 2.4.21 one 2.4.11 >> > > Running multiple different versions on your master is a great way to ensure > things will not work properly. I don't know why you are surprised at having > problems. > > --Quanah > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > -- Dominique LALOT Ingénieur Systèmes et Réseaux http://annuaire.univmed.fr/showuser.php?uid=lalot

1 0

multi-master and consumers
by Troy Knabe 16 Mar '11

16 Mar '11

I have a couple of master ldap servers and several consumer ldap servers. Can I set it up so that both masters sync to the consumers? That way if I lose a master, my consumers would all still be updated? Thanks -Troy

2 1

Can system schema attribute matching rules be overwritten?
by LIM Chin Ho 15 Mar '11

15 Mar '11

Hi, Say for eg, the attribute cn, it is default to caseIgnoreMatch by openldap, can we overwrite it to caseExactMatch in our own schema? Or there is no way to do it. Thanks! Chinho

1 0

OpenLDAP.org takes very long time to load
by sim123 15 Mar '11

15 Mar '11

Hi There, just wanted to check, is it only I who is facing this issue? Thanks.

5 4

Re: delta-sync - ContextCSN on proivder older than consumers
by Yuri Bank 14 Mar '11

14 Mar '11

I'm using the latest stable version: OpenLDAP 2.4.23 ( running on Ubuntu 10.10 ) I've also included the relevant configuration for my Provider and Consumer[s]. Consumer[s] # {1}hdb, config dn: olcDatabase={1}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=test,dc=com olcAccess: {0}to attrs=userPassword by dn="cn=admin,dc=test,dc=com" write by an onymous auth by self write by group.exact="cn=DCNAS,o=Groups,dc=test,dc=com" w rite by * none olcAccess: {1}to attrs=shadowLastChange by self write by * read olcAccess: {2}to dn.base="" by * read olcAccess: {3}to * by dn="cn=admin,dc=test,dc=com" write by group.exact="cn=DCN AS,o=Groups,dc=test,dc=com" write by * read olcLastMod: TRUE olcRootDN: cn=admin,dc=test,dc=com olcRootPW: test olcSyncrepl: {0}rid=001 provider=ldap://10.81.255.30 bindmethod=simple binddn= "cn=admin,dc=test,dc=com" credentials=test searchbase="dc=test,dc=com" logba se="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshOnly retry="60 +" interval=00:00:00:30 syncdata =accesslog olcUpdateRef: ldap://10.81.255.30 olcDbCheckpoint: 512 30 olcDbConfig: {0}set_cachesize 0 2097152 0 olcDbConfig: {1}set_lk_max_objects 1500 olcDbConfig: {2}set_lk_max_locks 1500 olcDbConfig: {3}set_lk_max_lockers 1500 olcDbIndex: objectClass eq olcDbIndex: uid eq olcDbIndex: uidNumber eq olcDbIndex: cn eq olcDbIndex: memberOf eq olcDbIndex: entryUUID eq Provider: # {1}hdb, config dn: olcDatabase={1}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=test,dc=com olcAccess: {0}to attrs=userPassword by dn="cn=admin,dc=test,dc=com" write by an onymous auth by self write by group.exact="cn=DCNAS,o=Groups,dc=test,dc=com" w rite by * none olcAccess: {1}to attrs=shadowLastChange by self write by * read olcAccess: {2}to dn.base="" by * read olcAccess: {3}to * by dn="cn=admin,dc=test,dc=com" write by group.exact="cn=DCN AS,o=Groups,dc=test,dc=com" write by * read olcLastMod: TRUE olcRootDN: cn=admin,dc=test,dc=com olcRootPW: test olcDbCheckpoint: 512 30 olcDbConfig: {0}set_cachesize 0 2097152 0 olcDbConfig: {1}set_lk_max_objects 1500 olcDbConfig: {2}set_lk_max_locks 1500 olcDbConfig: {3}set_lk_max_lockers 1500 olcDbIndex: objectClass eq olcDbIndex: entryCSN eq olcDbIndex: entryUUID eq olcDbIndex: uid eq olcDbIndex: uidNumber eq olcDbIndex: cn eq olcDbIndex: memberOf eq # {1}syncprov, {1}hdb, config dn: olcOverlay={1}syncprov,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {1}syncprov olcSpNoPresent: TRUE # {2}accesslog, {1}hdb, config dn: olcOverlay={2}accesslog,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: {2}accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogPurge: 07+00:00 01+00:00 olcAccessLogSuccess: TRUE # {2}hdb, config dn: olcDatabase={2}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {2}hdb olcDbDirectory: /var/lib/ldap/accesslog olcSuffix: cn=accesslog olcRootDN: cn=admin,dc=test,dc=com olcDbIndex: default eq olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart # {0}syncprov, {2}hdb, config dn: olcOverlay={0}syncprov,olcDatabase={2}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE -Yuri On Sun, Mar 13, 2011 at 11:47 AM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > --On Saturday, March 12, 2011 8:59 PM -0800 Yuri Bank <yuribank(a)gmail.com> > wrote: > > >> I've found an interesting issue with delta-sync replication in which the >> > > > The first thing you should always provide is the version of OpenLDAP you > are using. > > --Quanah > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

4 8

execve problem with back-shell
by Michael Smith 14 Mar '11

14 Mar '11

Hello all. I'm working with openLDAP again, after some years' hiatus, and very glad of it. I'm having a problem which I hope somebody's seen before. I'm trying to use back-shell (to avoid relearning Perl) for a quick-and dirty solution to a problem too tedious to describe here. Here's the relevant bits of slapd.conf: -------------- moduleload back_shell.la backend shell database shell suffix "dc=foo,dc=bar,dc=com" rootdn "cn=admin,dc=foo,dc=bar,dc=com" rootpw secretissimum-secretissimorum add /usr/local/bin/backshell.sh bind /usr/local/bin/backshell.sh compare /usr/local/bin/backshell.sh delete /usr/local/bin/backshell.sh modify /usr/local/bin/backshell.sh modrdn /usr/local/bin/backshell.sh search /usr/local/bin/backshell.sh unbind /usr/local/bin/backshell.sh syncrepl rid=123 provider=ldap://127.0.0.1 type=refreshOnly interval=00:00:00:05 searchbase="dc=foo,dc=bar,dc=com" scope=sub bindmethod=simple binddn="uid=mik,ou=Managers,dc=foo,dc=bar,dc=com" credentials="M0$tsecret" ------------- backshell.sh is moronically simple at the moment: ---------------- #!/bin/bash while read LINE do /bin/echo $LINE >>/var/lib/ldap2/replog.txt done echo RESULT ---------------- Commands to execute slapd: ~$ sudo su # /usr/sbin/slapd -d 0x4400 -f /etc/ldap/slapd2.conf -h "ldap://127.0.0.1:3889" -u openldap -g openldap --------------- Varia: ~$ which bash /bin/bash ~$ ls -ld /var/lib/ldap2 drwxr-xr-x 2 openldap openldap 4096 2011-03-04 13:10 /var/lib/ldap2 Debug output from slapd: @(#) $OpenLDAP: slapd 2.4.9 (Jul 30 2010 00:42:11) $ buildd@vernadsky:/build/buildd/openldap2.3-2.4.9/debian/build/servers/slapd WARNING: No dynamic config support for database shell. slapd starting syncrepl_entry: rid=123 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=123 inserted UUID f25a0996-d888-102f-9c2e-559808098a6b execv failed shell: fgets failed: Success (0) str2result () expecting "RESULT" --------------------- ... over and over again. strace says: [pid 19068] execve("/usr/local/bin/backshell.sh", ["/usr/local/bin/backshell.sh"], ["SHELL=/bin/bash", "TERM=xterm", "USER=root", "LS_COLORS=no=00:fi=00:di=01;34:l"..., "SUDO_USER=mike", "SUDO_UID=1001", "USERNAME=root", "PATH=/usr/local/sbin:/usr/local/"..., "MAIL=/var/mail/root", "PWD=/home/mike", "LANG=en_US.UTF-8", "SHLVL=1", "SUDO_COMMAND=/bin/su", "HOME=/root", "LOGNAME=root", "LESSOPEN=| /usr/bin/lesspipe %s", "SUDO_GID=1001", "LESSCLOSE=/usr/bin/lesspipe %s %"..., "_=/usr/sbin/slapd"]) = -1 EACCES (Permission denied) ------------- Doesn't look like it's even able to execute my little program, right? So this may be more a question about the subtleties of execve (and possibly its interactions with sudo?) than about openldap, but if some kind soul can set me on the right path, I'd be most grateful. I've manpaged and googled everything I could think of, and drawn a blank. -- -- Michael J. Smith mjs(a)smithbowen.net

6 11

newbie scenario
by Lumeng Lim 14 Mar '11

14 Mar '11

mind you i've only managed to setup ldap server under ubuntu for now. we have 2 sites to manage and I would like for users( about 250 users total) in both sites that is connected via vpn to be able to login to samba/ldap in HQ are there things to consider before going about just setting up ldap and samba? assuming that samba is going to be used as pdc and fileserver.

2 1

Modified Records Deleted - Multimaster
by John s 13 Mar '11

13 Mar '11

Hi All, I have 2 way ldap multimaster setup . Recently User names are disappeared from two Master servers . Observed that when records are modified at one Master, records are removed from two servers next day . Enabled the logs and found no errors . Let me know during the syncrepl replication is their any chance of modified records being deleted from other Master server ... Thanks in advance for any help . Ldap Version: 2.4 Regards John

2 1

Dynamic modules unloading
by Коновалов Андрей Але ксандрович 13 Mar '11

13 Mar '11

Hello! I have OpenLDAP 2.4.24 built with -enable-dynamic and --enable-modules options So, dynamic modules support is on and my question is: Why can i load module (for example: dn: cn=module{0},cn=config changeType: modify add: olcModuleLoad olcModuleLoad: translucent.la ) But when i'm trying to unload it (because it's not used at all), i cant do this anywhere? dn: cn=module{0},cn=config changeType: modify delete: olcModuleLoad olcModuleLoad: {6}translucent.la # the same with simply olcModuleLoad: translucent.la modifying entry "cn=module{0},cn=config" ldap_modify: Other (e.g., implementation specific) error (80) additional info: cannot delete olcModuleLoad If it is not realised yet, you may consume my question as a feature request :)

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical