why my virtual memory still increasing when openldap is running?
by 何萍
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
12 years, 7 months
Re: smbk5pwd crash for missing symbol
by Guillaume Rousse
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 );
12 years, 7 months
Update strategy: 2.3.34 to 2.3.41 or even 2.4.9 ?
by openldap.lists＠frei-family.ch
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
12 years, 7 months
Pls help:delete missing in multi-master environment
by ST Wong (ITSC)
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
12 years, 7 months
Permission denied while opening odbcinst.ini
by Andreas Backman
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!
12 years, 7 months
URL-encoding noew mandatory with ldapi access ?
by Guillaume Rousse
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
12 years, 7 months
Unexpected crash
by Francis Swasey
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)
12 years, 7 months
Solaris 10 Install error during Make
by Paul Stephens
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
12 years, 7 months
suffixmassaging to ancestor suffix
by Jean-Jacques Puig
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
12 years, 8 months
memory usage of dn attributes
by Jason Dusek
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
12 years, 8 months
