openldap-software May 2008

openldap-software@openldap.org

64 participants
55 discussions

why my virtual memory still increasing when openldap is running?
by 何萍 27 May '08

27 May '08

openldap: 2.0.17 ; OS: RH9.0 my virtual memory still increasing , no matter what operation i did, such as search/add/modify. the top result is: Mem: 3608380k av, 3218344k used, 390036k free, 0k shrd, 82776k buff 2062984k actv, 56724k in_d, 97036k in_c Swap: 3124560k av, 5312k used, 3119248k free 2868164k cached PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND 9415 root 15 0 122M 122M 1156 S 3.7 3.4 1:22 3 slapd and it quickly to 500M, when the system's memory near to 10M, openldap could not work properly

3 2

Re: smbk5pwd crash for missing symbol
by Guillaume Rousse 27 May '08

27 May '08

Love Hörnquist Åstrand a écrit : > 26 maj 2008 kl. 08.27 skrev Guillaume Rousse: > >> Hello list(s). >> >> I'm having a crash as soon as I attempt to change my password when >> smbk5pwd is activating. strace shows an unresolved symbol in >> smbk5pwd.so: _kadm5_free_keys >> >> Heimdal source code shows this function is defined in libkadm5srv.so >> (/usr/lib/libkadm5srv.so.8.0.1) for heimdal 1.1. But this seems to be >> a private symbol, as objdump -T doesn't list it. Looking at heimdal >> Makefile.am, it seems a special configuration file is used >> (lib/krb5/version-script.map) to filter exported symbols, if linker >> support the use of -Wl,--version-script option. I couldn't find any >> description of this option. >> >> Is this possible smbk5pwd author would have by mistake used a private >> function, only working because he build heimdal on a host whose linker >> doesn't support --version-script option ? >> >> I'm using heimdal 1.1 and openldap 2.4.8 on mandriva linux. > > > I unexported the function since there was no function that returned key > set-data. > > Same goes for _kadm5_set_keys() that also is an internal function. > > Since 1.0 you can use hdb_generate_key_set_password and hdb_free_keys to > generate the key data. I tried this approach (patch attached). Converting _kadm5_free_keys to hdb_free_keys is trivial, as the former is just a wrapper over the second. However, converting _kadm5_set_keys to hdb_generate_key_set_password is much more difficult. I first tried to inline all code from _kadm5_set_keys in smbk5pwd.c. However, gcc complains about "request for member ‘context’ in something not a structure or union" because it doesn't have any clue about the nature of kadm_context, which is a void ponter for smbk5pwd. Trying to cast it as a kadm5_server_context pointer fails, as this seems also to be a private heimdal structure... Given my lack of C knowledge, I'm a bit stuck there. -- Guillaume Rousse Moyens Informatiques - INRIA Futurs Tel: 01 69 35 69 62 --- smbk5pwd.c~ 2008-02-12 00:34:15.000000000 +0100 +++ smbk5pwd.c 2008-05-27 10:59:32.000000000 +0200 @@ -368,6 +368,8 @@ struct berval *keys; int kvno, i; Attribute *a; + Key *local_keys; + size_t local_num_keys; if ( !SMBK5PWD_DO_KRB5( pi ) ) break; @@ -396,7 +398,27 @@ op->o_log_prefix, e->e_name.bv_val, 0 ); } - ret = _kadm5_set_keys(kadm_context, &ent, qpw->rs_new.bv_val); + /* _kadm5_set_keys is a private function, inline its code here */ + ret = hdb_generate_key_set_password(kadm_context->context, + ent.principal, qpw->rs_new.bv_val, + &local_keys, &local_num_keys); + if (ret != 0) + break; + + hdb_free_keys(kadm_context->context, ent.keys.len, ent.keys.val); + ent.keys.val = local_keys; + ent.keys.len = local_num_keys; + + hdb_entry_set_pw_change_time(kadm_context->context, &ent, 0); + + if (krb5_config_get_bool_default(kadm_context->context, NULL, FALSE, + "kadmin", "save-password", NULL)) { + ret = hdb_entry_set_password(kadm_context->context, + kadm_context->db, &ent, qpw->rs_new.bv_val); + if (ret != 0) + break; + } + hdb_seal_keys(context, db, &ent); krb5_free_principal( context, ent.principal ); @@ -415,7 +437,7 @@ } BER_BVZERO( &keys[i] ); - _kadm5_free_keys(kadm_context, ent.keys.len, ent.keys.val); + hdb_free_keys(kadm_context, ent.keys.len, ent.keys.val); if ( i != ent.keys.len ) { ber_bvarray_free( keys );

1 0

Update strategy: 2.3.34 to 2.3.41 or even 2.4.9 ?
by openldap.lists＠frei-family.ch 27 May '08

27 May '08

Hi List, we're currently running OpenLDAP 2.3.34 with BDB 4.5.20p2 for the backend in production (Solaris 8, 2 million reads per day). This combination has run fine and stable for almost a year. Apart from syncrepl we're not using any special features/overlays. Now the platform to which that OpenLDAP setup belongs is rebuilt (Solaris 10) and I have an opportunity to carry out some lifecycle but wonder if I should remain at 2.3.34 or upgrade to 2.3.41 or even 2.4.9. A pro would defnitely be to reach a later OpenLDAP version without having to do the upgrade with the pressure of a productive environment. The con which makes me hesitate is that it's currently running very well - and, never change a winning team... How would you proceed in that situation and why ? Thanks for your thoughts Christoph

7 8

Pls help:delete missing in multi-master environment
by ST Wong (ITSC) 26 May '08

26 May '08

Hi all, I set up a 2 server multi-master environment using OpenLDAP 2.4.9 + BerkeleyDB 4.6 on CentOS 5.1. Make test and simple load test on add/mod/del are okay. However, seems some records are not replicated in delete phrase when there are lot of simultaneous delete operations (e.g. 10 threads spawned from 2 clients to add/del 100 users in each threads). I'm newbie to syncrepl and have no idea about the problem are scanning debug output. My slapd.conf syncrepl section follows: #master overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 #consumer syncrepl rid=001 provider=ldaps://192.168.28.69 starttls=yes tls_reqcert=never tls_cacert=/etc/CA/cacert.pem type=refreshAndPersist retry="5 + 5 +" searchbase="dc=mydomain,dc=hk" schemachecking=off bindmethod=simple binddn="cn=replicator,ou=People,dc=mydomain,dc=edu" credentials=secret Would anyone pls help? Sorry for the newbie question. Thanks a lot. /st wong

2 1

Permission denied while opening odbcinst.ini
by Andreas Backman 25 May '08

25 May '08

Hi all! I'm trying to configure an OpenLDAP server with a mySQL server as back-end. This is what happens when i try to start the server. root@ldap:~# slapd -d1 --------- backsql_open_db_handle(): SQLConnect() to database "MySQL" failed. Return code: -1 nativeErrCode=0 SQLengineState=IM002 msg="[unixODBC][Driver Manager]Data source name not found, and no default driver specified" --------- I couldn't find anything wrong with my configuration (see odbc.ini and odbcinst.ini below) so i tried strace: root@ldap:~# strace -o /tmp/out.txt slapd root@ldap:~# grep odbc /tmp/out.txt open("/usr/lib/libodbc.so.1", O_RDONLY) = 3 open("/etc/odbcinst.ini", O_RDONLY) = -1 EACCES (Permission denied) access("/etc/odbc.ini", F_OK) = 0 stat64("/etc/odbc.ini", {st_mode=S_IFREG|0644, st_size=598, ...}) = 0 open("/etc/odbcinst.ini", O_RDONLY) = -1 EACCES (Permission denied) Permissions of odbc.ini and odbcinst.ini root@ldap:/etc# ls odbc*.ini -l -rw-r--r-- 1 root root 598 2008-05-23 08:50 odbc.ini -rw-r--r-- 1 root root 549 2008-05-23 08:49 odbcinst.ini Contents of my odbc.ini and odbcinst.ini: odbc.ini: --------- [MySQL] Description = MySQL test database Driver = MySQL SERVER = 192.168.100.38 USER = root PASSWORD = *** PORT = 3306 DATABASE = kplatsen ---------- odbsinst.ini ---------- [MySQL] Description = MySQL driver for Linux & Win32 Driver = /usr/lib/odbc/libmyodbc3.so Setup = /usr/lib/odbc/libmyodbc3S.so FileUsage = 1 [Default] Driver = /usr/lib/odbc/libmyodbc.so UsageCount = 1 ---------- I've tested the ODBC-connection with: root@ldap:~# isql MySQL and it works... Please help!

2 1

URL-encoding noew mandatory with ldapi access ?
by Guillaume Rousse 23 May '08

23 May '08

Hello list. By setting up an heimdal KDC with an ldap backend, I found a strange issue: URI-encoding '/' character seems to be mandatory with openldap 2.4 clients (at least 2.4.9) now: [root@stalingrad rousse]# ldapsearch -H ldapi:///var/run/ldap/ldapi DNS SRV: Could not turn DN="var/run/ldap/ldapi" into a domain -> NOK [root@stalingrad rousse]# ldapsearch -H 'ldapi://%2fvar%2frun%2fldap%2fldapi' -> OK is this intentional ? -- Guillaume Rousse Moyens Informatiques - INRIA Futurs Tel: 01 69 35 69 62

4 3

Unexpected crash
by Francis Swasey 23 May '08

23 May '08

I had an unexpected and completely undocumented crash of slapd this morning. I'm looking for some hints on tracking it down. Here's the background. We are running 2.3.41 (locally built RPM) on RedHat EL 4 with four slave servers (running the same 2.3.41 and RHEL4). We use a nightly update process where we slapcat the master database, apply the changes from the systems of record (students, employees, retirees, etc) to the LDIF, generate an ldapmodify data stream and run ldapmodify to apply the changes. The student system made some massive changes this morning which caused us to generate an ldapmodify input file with 31,973 changes (adds, modifies, modrdn's) in it. The ldapmodify on the master took 8 minutes. The delta-syncrepl to the slave/replica servers took 33 to 44 minutes. The replica delta-syncrepl processes seem to have been averaging about 800 changes per minute, which is quite slow for what I was expecting. Since it took so long for the replica's to get all the changes, they fell more than the 10 minutes behind the master server and the person on call got paged (nagios monitoring of the replica and master CSN's). The person on call had not been properly trained (my fault) to look for the syncrepl messages in the syslog on the replica servers and thus they issued a restart on one of the replicas (thinking that something was hung). The replica restarted properly, but the master seems to have crashed without a sound at the same time. There was no core file generated and I haven't found anything logged in the syslog on the master. slapd was started on the master, and the output of the startup says that the accesslog database had an unclean shutdown and needed to be recovered (which it was successfully). I'm wondering the following things: 1) Is it possible that one of the ITS's for syncrepl that will be included in 2.3.42 would address this crash? Any suggestions on tracking down why it crashed? 2) Does it appear that I have a configuration problem (the delta-syncrepl taking about five times as long to get the changes out to the replicas as it took to apply them on the master)? Where would you suggest I look if it is likely? Thanks, -- Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900)

3 9

Solaris 10 Install error during Make
by Paul Stephens 22 May '08

22 May '08

Hi, Am attempting to install OpenLDAP version 2.4.9 on Solaris 10 (kernel Generic_127111-05) with gcc 3.4.6. The configure and the make depend both seem to work well. The make crashes during the make of the libldap (everything beforehand seems fine): Entering subdirectory libldap make[2]: Entering directory `/home/openldap-2.4.9/libraries/libldap' rm -f version.c ../../build/mkversion -v "2.4.9" libldap.la > version.c /bin/sh ../..//libtool --mode=compile gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c bind.c mkdir .libs gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c bind.c -fPIC -DPIC -o .libs/bind.o gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c bind.c -o bind.o >/dev/null 2>&1 /bin/sh ../..//libtool --mode=compile gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c open.c gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c open.c -fPIC -DPIC -o .libs/open.o gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c open.c -o open.o >/dev/null 2>&1 /bin/sh ../..//libtool --mode=compile gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c result.c gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c result.c -fPIC -DPIC -o .libs/result.o gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c result.c -o result.o >/dev/null 2>&1 /bin/sh ../..//libtool --mode=compile gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c error.c gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c error.c -fPIC -DPIC -o .libs/error.o gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c error.c -o error.o >/dev/null 2>&1 /bin/sh ../..//libtool --mode=compile gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c compare.c gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c compare.c -fPIC -DPIC -o .libs/compare.o gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c compare.c -o compare.o >/dev/null 2>&1 /bin/sh ../..//libtool --mode=compile gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c search.c gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c search.c -fPIC -DPIC -o .libs/search.o gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c search.c -o search.o >/dev/null 2>&1 /bin/sh ../..//libtool --mode=compile gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c controls.c gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c controls.c -fPIC -DPIC -o .libs/controls.o gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c controls.c -o controls.o >/dev/null 2>&1 /bin/sh ../..//libtool --mode=compile gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c messages.c gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c messages.c -fPIC -DPIC -o .libs/messages.o gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c messages.c -o messages.o >/dev/null 2>&1 /bin/sh ../..//libtool --mode=compile gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c references.c gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c references.c -fPIC -DPIC -o .libs/references.o gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c references.c -o references.o >/dev/null 2>&1 /bin/sh ../..//libtool --mode=compile gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c extended.c gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c extended.c -fPIC -DPIC -o .libs/extended.o gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c extended.c -o extended.o >/dev/null 2>&1 /bin/sh ../..//libtool --mode=compile gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c cyrus.c gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c cyrus.c -fPIC -DPIC -o .libs/cyrus.o gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c cyrus.c -o cyrus.o >/dev/null 2>&1 /bin/sh ../..//libtool --mode=compile gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c modify.c gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c modify.c -fPIC -DPIC -o .libs/modify.o gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c modify.c -o modify.o >/dev/null 2>&1 /bin/sh ../..//libtool --mode=compile gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c add.c gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c add.c -fPIC -DPIC -o .libs/add.o gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c add.c -o add.o >/dev/null 2>&1 /bin/sh ../..//libtool --mode=compile gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c modrdn.c gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c modrdn.c -fPIC -DPIC -o .libs/modrdn.o gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c modrdn.c -o modrdn.o >/dev/null 2>&1 /bin/sh ../..//libtool --mode=compile gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c delete.c gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c delete.c -fPIC -DPIC -o .libs/delete.o gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c delete.c -o delete.o >/dev/null 2>&1 /bin/sh ../..//libtool --mode=compile gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c abandon.c gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c abandon.c -fPIC -DPIC -o .libs/abandon.o gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c abandon.c -o abandon.o >/dev/null 2>&1 /bin/sh ../..//libtool --mode=compile gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c sasl.c gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c sasl.c -fPIC -DPIC -o .libs/sasl.o gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c sasl.c -o sasl.o >/dev/null 2>&1 /bin/sh ../..//libtool --mode=compile gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c sbind.c gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c sbind.c -fPIC -DPIC -o .libs/sbind.o gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c sbind.c -o sbind.o >/dev/null 2>&1 /bin/sh ../..//libtool --mode=compile gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c unbind.c gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c unbind.c -fPIC -DPIC -o .libs/unbind.o gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c unbind.c -o unbind.o >/dev/null 2>&1 /bin/sh ../..//libtool --mode=compile gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c cancel.c gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c cancel.c -fPIC -DPIC -o .libs/cancel.o gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c cancel.c -o cancel.o >/dev/null 2>&1 /bin/sh ../..//libtool --mode=compile gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c filter.c gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c filter.c -fPIC -DPIC -o .libs/filter.o gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c filter.c -o filter.o >/dev/null 2>&1 /bin/sh ../..//libtool --mode=compile gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c free.c gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c free.c -fPIC -DPIC -o .libs/free.o gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c free.c -o free.o >/dev/null 2>&1 /bin/sh ../..//libtool --mode=compile gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c sort.c gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c sort.c -fPIC -DPIC -o .libs/sort.o gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c sort.c -o sort.o >/dev/null 2>&1 /bin/sh ../..//libtool --mode=compile gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c passwd.c gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c passwd.c -fPIC -DPIC -o .libs/passwd.o gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c passwd.c -o passwd.o >/dev/null 2>&1 /bin/sh ../..//libtool --mode=compile gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c whoami.c gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c whoami.c -fPIC -DPIC -o .libs/whoami.o gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c whoami.c -o whoami.o >/dev/null 2>&1 /bin/sh ../..//libtool --mode=compile gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c getdn.c gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c getdn.c -fPIC -DPIC -o .libs/getdn.o gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c getdn.c -o getdn.o >/dev/null 2>&1 /bin/sh ../..//libtool --mode=compile gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c getentry.c gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c getentry.c -fPIC -DPIC -o .libs/getentry.o gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c getentry.c -o getentry.o >/dev/null 2>&1 /bin/sh ../..//libtool --mode=compile gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c getattr.c gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c getattr.c -fPIC -DPIC -o .libs/getattr.o gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c getattr.c -o getattr.o >/dev/null 2>&1 /bin/sh ../..//libtool --mode=compile gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c getvalues.c gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c getvalues.c -fPIC -DPIC -o .libs/getvalues.o gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c getvalues.c -o getvalues.o >/dev/null 2>&1 /bin/sh ../..//libtool --mode=compile gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c addentry.c gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c addentry.c -fPIC -DPIC -o .libs/addentry.o gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c addentry.c -o addentry.o >/dev/null 2>&1 /bin/sh ../..//libtool --mode=compile gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c request.c gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c request.c -fPIC -DPIC -o .libs/request.o gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c request.c -o request.o >/dev/null 2>&1 /bin/sh ../..//libtool --mode=compile gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c os-ip.c gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c os-ip.c -fPIC -DPIC -o .libs/os-ip.o os-ip.c: In function `ldap_pvt_is_socket_ready': os-ip.c:197: error: storage size of 'sin' isn't known os-ip.c: In function `ldap_pvt_inet_aton': os-ip.c:417: error: dereferencing pointer to incomplete type os-ip.c: In function `ldap_connect_to_host': os-ip.c:436: error: storage size of 'hints' isn't known os-ip.c:449: error: `SOCK_STREAM' undeclared (first use in this function) os-ip.c:449: error: (Each undeclared identifier is reported only once os-ip.c:449: error: for each function it appears in.) os-ip.c:454: error: `SOCK_DGRAM' undeclared (first use in this function) os-ip.c:471: error: `ldap_int_inet4or6' undeclared (first use in this function) os-ip.c:493: error: dereferencing pointer to incomplete type os-ip.c:494: error: dereferencing pointer to incomplete type os-ip.c:501: error: dereferencing pointer to incomplete type os-ip.c:511: error: dereferencing pointer to incomplete type os-ip.c:522: error: `AF_INET' undeclared (first use in this function) os-ip.c:525: error: dereferencing pointer to incomplete type os-ip.c:533: error: dereferencing pointer to incomplete type os-ip.c:533: error: dereferencing pointer to incomplete type os-ip.c: In function `ldap_host_connected_to': os-ip.c:629: error: storage size of 'sabuf' isn't known os-ip.c:648: error: dereferencing pointer to incomplete type os-ip.c:650: error: `AF_LOCAL' undeclared (first use in this function) os-ip.c:665: error: `AF_INET' undeclared (first use in this function) os-ip.c:667: error: storage size of 'localhost' isn't known os-ip.c:668: error: `INADDR_ANY' undeclared (first use in this function) os-ip.c:670: error: dereferencing pointer to incomplete type os-ip.c:679: error: dereferencing pointer to incomplete type make[2]: *** [os-ip.lo] Error 1 make[2]: Leaving directory `/home/openldap-2.4.9/libraries/libldap' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/home/openldap-2.4.9/libraries' make: *** [all-common] Error 1 Sorry for the newbie question but am I missing an additional application or something. Cheers and thanks Paul

2 1

suffixmassaging to ancestor suffix
by Jean-Jacques Puig 21 May '08

21 May '08

Hi, I'm working on the following tree structure (represented here with dn chunks): z `-- y |-- o1 |-- o2 | `-- c | |-- e1 | |-- e2 | |-- e3 | `-- e4 |-- o3 |-- s1 |-- s2 |-- s3 `-- s4 where 'dc=y,dc=z' is base dn. Entries o* have same objectClass, so have s* and e*. The tree contains duplicate information: for any i, all attributes in e$i can be mapped to attributes in the corresponding s$i, and c entry contains no information wrt my applications. e* are end nodes (leaves), while s* are not. Suffix 'dc=y,dc=z' is served by a single database. My goal is to get rid of the c subtree with no side effects for my applications and with limited risks as a whole. I currently do this with slapd-relay and slapo-rwm. I first attempted: database relay suffix "ou=c,ou=o2,dc=y,dc=z" relay "dc=y,dc=z" overlay rwm rwm-suffixmassage "dc=y,dc=z" When I inserted this definition before that of the database serving suffix "dc=y,dc=z", I had the following error: cannot find database of relay dn "dc=y,dc=z" in "olcRelay <dn>. This makes sense. When I inserted this definition after that of the database serving suffix "dc=y,dc=z", I had: <suffix> namingContext "ou=c,ou=o2,dc=y,dc=z" already served by a preceding bdb database serving namingContext "dc=y,dc=z". This also makes sense. I got rid of the '^relay' line, so as not to refer to a specific database, and inserted the definition before "dc=y,dc=z" database; slaptest passed. When I tested a simple search on objectClasses , I had a burst of slapd crashes (our server is run within a shell loop), and no log. I thought first that a infinite loop exhausting memory might be the explanation, bouncing from 'ou=c,ou=o2,dc=y,dc=z" to "dc=y,dc=z" and back again. I was for some time deceived in thinking so because I did not notice at first that rwm-suffixemassage implied recursive rewrite and I was doing tests on suffix such as 'ou=c,ou=o2,ou=c,ou=o2,dc=y,dc=z' to assert loop situation. Eventually, I could not reproduce the failing situation, and it seems there is no loop. Am I right about this ? What actually happens when rewriting to an ancestor suffix without 'relay' reference ? In such a situation, is there any way to inforce relay to a later-defined database ? I further had to remap classes and attributes: rwm-map objectclass E S rwm-map attribute e_att1 s_att1 rwm-map attribute e_att2 s_att2 where E is objectclass of e*, S objectclass of s*, e_att1, e_att2 attributes of E, s_att1, s_att2 attributes of S. This works fine, but on searches such as: ldapsearch -s one -b 'ou=c,ou=o2,dc=y,dc=z' objectClass=E I get all attributes related to S. Normal but not desirable. I thus added: rwm-map attribute * The preceeding command then returns... nothing. How can I make this search work while limiting attributes mapping ? Because it's necessary, I further added access rules: access to dn.base="ou=c,ou=o2,dc=y,dc=z" by * read stop access to dn.one="ou=c,ou=o2,dc=y,dc=z" by * read stop access to * by * none stop I wanted to deny read access deeper in the tree (there are passwords hashes out there). Is there another way to constrain scope on consultations on 'ou=c,ou=o2,dc=y,dc=z' ? Btw, are the above rules expressed in the simplest way ? In order to limit entries attributes visibility, as I could not use rwm-map attribute *, I mention e_att* as attrs= in the #2 access rule. But there again the search would return no result. What am I missing ? From a general perspective, is the slapd-relay slapo-rwm combination the relevant way to solve my issue ? Thanks ! -- Jean-Jacques Puig

1 0

memory usage of dn attributes
by Jason Dusek 20 May '08

20 May '08

Are DNs optimized in any way, for lookup or storage? Or are they merely packed into strings and searched lexicographically? I'm curious because DNs are the only allowed key for the referential integrity. If they are searched using string operations, that would be pretty slow relative to shorter strings (UID) or plain old Int values. -- _jsn

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software May 2008