Re: (ITS#5133) Synchronous replication on slave doesn't notice lost network connection
by stelios.xx.grigoriadis＠ericsson.com
We also have a patch for the stable version should anybody be interested
in it.
-----
# This patch file is derived from OpenLDAP Software. All of the
modifications to OpenLDAP Software
# represented in the following patch(es) were developed by Stelios
Grigoriadis stelios.xx.grigoriadis(a)ericsson.com.
# These modifications are not subject to any license of Ericsson AB.
# I, Stelios Grigoriadis, hereby place the following modifications to
OpenLDAP Software (and only these modifications)
# into the public domain. Hence, these modifications may be freely used
and/or redistributed for any purpose with or
# without attribution and/or other notice.
# Bug Fix - This patch fixes the bug ITS#5133.
# The fix works as follows. A periodic check in the runqueue (called
do_mastercheck). The intervall is determined by
# a slapd.conf parameter (mastercheckint) in the syncrepl section and is
optional. If it's not specified, it's not
# inserted in the runqueue.
--- servers/slapd/syncrepl.c 2007-10-05 10:36:13.000000000 +0200
+++ syncrepl.c 2008-05-13 14:27:09.000000000 +0200
@@ -78,6 +78,7 @@
int si_manageDSAit;
int si_slimit;
int si_tlimit;
+ int si_mastercheck_int;
int si_refreshDelete;
int si_refreshPresent;
int si_syncdata;
@@ -89,6 +90,9 @@
ldap_pvt_thread_mutex_t si_mutex;
} syncinfo_t;
+/* Necessary in order to use asynchronous searches in mastercheck */
+static ber_int_t ps_msgid;
+
static int syncuuid_cmp( const void *, const void * );
static void avl_ber_bvfree( void * );
static void syncrepl_del_nonpresent( Operation *, syncinfo_t *,
BerVarray, struct berval * );
@@ -314,7 +318,6 @@
BerElement *ber = (BerElement *)&berbuf;
LDAPControl c[2], *ctrls[3];
struct timeval timeout;
- ber_int_t msgid;
int rc;
int rhint;
char *base;
@@ -402,7 +405,7 @@
rc = ldap_search_ext( si->si_ld, base, scope, filter, attrs, attrsonly,
ctrls, NULL, si->si_tlimit > 0 ? &timeout : NULL,
- si->si_slimit, &msgid );
+ si->si_slimit, &ps_msgid );
ber_free_buf( ber );
return rc;
}
@@ -667,7 +670,7 @@
tout_p = NULL;
}
- while (( rc = ldap_result( si->si_ld, LDAP_RES_ANY, LDAP_MSG_ONE,
+ while (( rc = ldap_result( si->si_ld, ps_msgid, LDAP_MSG_ONE,
tout_p, &res )) > 0 )
{
if ( slapd_shutdown ) {
@@ -2769,6 +2772,7 @@
#define OLDAUTHCSTR "bindprincipal"
#define EXATTRSSTR "exattrs"
#define MANAGEDSAITSTR "manageDSAit"
+#define MASTERCHECKINTSTR "mastercheckint"
/* FIXME: unused */
#define LASTMODSTR "lastmod"
@@ -3198,6 +3202,17 @@
Debug( LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->msg, 0 );
return 1;
}
+ } else if ( !strncasecmp( c->argv[ i ], MASTERCHECKINTSTR "=",
+ STRLENOF( MASTERCHECKINTSTR "=" ) ) )
+ {
+ val = c->argv[ i ] + STRLENOF( MASTERCHECKINTSTR "=" );
+ if ( lutil_atoi( &si->si_mastercheck_int, val )
!= 0 || si->si_mastercheck_int < 0 ) {
+ snprintf( c->msg, sizeof( c->msg ),
+ "invalid master check interval
value \"%s\".\n",
+ val );
+ Debug( LDAP_DEBUG_ANY, "%s: %s.\n", c->log,
c->msg, 0 );
+ return 1;
+ }
} else if ( !strncasecmp( c->argv[ i ], SYNCDATASTR "=",
STRLENOF( SYNCDATASTR "=" ) ) )
{
@@ -3273,6 +3288,7 @@
si->si_tlimit = 0;
si->si_slimit = 0;
si->si_conn_setup = 0;
+ si->si_mastercheck_int = 0;
si->si_presentlist = NULL;
LDAP_LIST_INIT( &si->si_nonpresentlist );
@@ -3435,6 +3451,68 @@
ber_dupbv( bv, &bc );
}
+static void *
+do_mastercheck(
+ void *ctx,
+ void *arg )
+{
+ struct re_s* rtask = arg;
+ syncinfo_t *si = ( syncinfo_t * ) rtask->arg;
+ int rc;
+ char *search_attrs[] = { NULL };
+ LDAPMessage *res = 0;
+ struct timeval timeout;
+ timeout.tv_sec = 0;
+ timeout.tv_usec = 0;
+ static int mc_msg=-1;
+
+ ldap_pvt_thread_mutex_lock( &si->si_mutex );
+ if (si->si_ld) {
+ if (mc_msg != -1) {
+ res=0;
+ ldap_result(si->si_ld, mc_msg, 1, &timeout, &res);
+ if (res) { ldap_msgfree(res);}
+ if (rc != LDAP_SUCCESS) {
+ ldap_abandon_ext(si->si_ld, mc_msg, NULL, NULL);
+ }
+ }
+ mc_msg=-1;
+ rc=ldap_search_ext(si->si_ld, "", LDAP_SCOPE_BASE,
"(objectClass=*)", search_attrs,
+ 0, NULL, NULL, NULL, 0, &mc_msg);
+ if (rc != LDAP_SUCCESS) {
+ Debug(LDAP_DEBUG_ANY,"Failed to send\n",0,0,0);
+ }
+ }
+
+ ldap_pvt_thread_mutex_lock( &slapd_rq.rq_mutex );
+
+ if ( ldap_pvt_runqueue_isrunning( &slapd_rq, rtask )) {
+ ldap_pvt_runqueue_stoptask( &slapd_rq, rtask );
+ }
+
+ rtask->interval.tv_sec = si->si_mastercheck_int;
+ ldap_pvt_runqueue_resched( &slapd_rq, rtask, 0 );
+
+ ldap_pvt_thread_mutex_unlock( &slapd_rq.rq_mutex );
+
+ ldap_pvt_thread_mutex_unlock( &si->si_mutex );
+}
+
+static int add_mastercheck( ConfigArgs *c ) {
+ int rc;
+ syncinfo_t *si = c->be->be_syncinfo;
+
+ if ( si->si_mastercheck_int == 0 )
+ return 0;
+
+ rc = ldap_pvt_runqueue_insert( &slapd_rq, si->si_mastercheck_int * 60,
+ do_mastercheck, si, "do_mastercheck",
c->be->be_suffix[0].bv_val );
+ if (rc < 0)
+ Debug( LDAP_DEBUG_ANY, "failed to add syncinfo\n", 0, 0, 0 );
+
+ return rc;
+}
+
int
syncrepl_config( ConfigArgs *c )
{
@@ -3470,5 +3548,6 @@
} else if ( add_syncrepl( c ) ) {
return(1);
}
+ add_mastercheck( c );
return config_sync_shadow( c );
}
14 years, 10 months
Re: (ITS#5510) Does GSSAPI failure kill slapd?
by hyc＠symas.com
aej(a)WPI.EDU wrote:
>>>>>> "rein" == Rein Tollevik<rein(a)OpenLDAP.org> writes:
>
> rein> Could you also "print *so" from frame 5, the entry from frame 4 looks
> rein> corrupt.
>
> connection_read(33): no connection!
> SASL [conn=27] Failure: GSSAPI Error: The context has expired (No error)
> sb_sasl_write: failed to encode packet: generic failure
> send_search_entry: conn 27 ber write failed.
> slapd: rq.c:92: ldap_pvt_runqueue_remove: Assertion `e == entry' failed.
>
> Program received signal SIGABRT, Aborted.
> [Switching to Thread 1986071456 (LWP 27434)]
> 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
> (gdb) where
> #0 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
> #1 0x00ad8815 in raise () from /lib/tls/libc.so.6
> #2 0x00ada279 in abort () from /lib/tls/libc.so.6
> #3 0x00ad1d91 in __assert_fail () from /lib/tls/libc.so.6
> #4 0x08114473 in ldap_pvt_runqueue_remove (rq=0x82c1820, entry=0x6b2a) at rq.c:92
> #5 0x080ffd9f in syncprov_free_syncop (so=0x8403c88) at syncprov.c:744
> #6 0x0810011d in syncprov_qtask (ctx=0x76610210, arg=0x845e880) at syncprov.c:949
> #7 0x08113cfd in ldap_int_thread_pool_wrapper (xpool=0x82e6c78) at tpool.c:663
> #8 0x00d123cc in start_thread () from /lib/tls/libpthread.so.0
> #9 0x00b7a1ae in clone () from /lib/tls/libc.so.6
> (gdb) frame 5
> #5 0x080ffd9f in syncprov_free_syncop (so=0x8403c88) at syncprov.c:744
> 744 ldap_pvt_runqueue_remove(&slapd_rq, so->s_qtask );
> (gdb) print so
> $1 = (syncops *) 0x8403c88
> (gdb) print *so
> $2 = {s_next = 0x0, s_base = {bv_len = 6, bv_val = 0x83f9b50 "cn=log"}, s_eid = 1, s_op = 0x83fe748, s_rid = 1, s_sid = -1,
> s_filterstr = {bv_len = 46, bv_val = 0x7881811c "0\001.\b\022"}, s_flags = 2, s_inuse = 0, s_res = 0x0, s_restail = 0x0,
> s_qtask = 0x845e880, s_mutex = {__m_reserved = 1, __m_count = 0, __m_owner = 0x6b2a, __m_kind = 0, __m_lock = {__status = 1,
> __spinlock = 0}}}
This is extremely odd - the structure definition clearly shows the value of
s_qtask that should have been passed to ldap_pvt_runqueue_remove, and yet your
trace shows that the value that actually got passed is s_mutex.__m_owner. This
looks like a pretty major compiler bug, assuming the trace is correct. What
version of compiler did you use, were you using optimization? Can you try with
a different version and/or without optimization?
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
14 years, 10 months
Re: (ITS#5514) Query about openLDAP on windows
by ando＠sys-net.it
sushmita_mishra(a)infosys.com wrote:
> I want to use openLDAP for authentication, for this purpose I have gone
> through the documents available at <www.openldap.org/doc/admin24/>. In all these
> documents, I found the installation for openLDAP directory server is given for
> LINUX or UNIX only and not for Windows.
>
> My query is Can we install openLDAP directory server on windows machine? If yes
> can you please send me the steps for installing/configuring openLDAP directory
> server on windows machine?
Please direct OpenLDAP software usage questions to the openldap-software
mailing lists; the ITS is to track bugs and issues. This ITS will be
closed.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
14 years, 10 months
Re: (ITS#5511) SIGABRT in slapo-unique when setting uidNumber to 0
by h.b.furuseth＠usit.uio.no
Confirmed in HEAD.
Unique makes too small buffer for filter "(uidNumber=0)", so
build_filter() line 931: assert( len >= 0 && len < ks );
fails because len == ks == 13 == strlen(filter).
slapd.conf:
include ...core.schema
include ...cosine.schema
include ...nis.schema
database bdb
directory /tmp/db
suffix uid=dwhite
rootdn uid=dwhite
rootpw secret
overlay unique
unique_attributes uidNumber
'ldapadd'ed ldif:
dn: uid=dwhite
objectClass: account
objectClass: posixAccount
uid: dwhite
uidNumber: 0
cn: Dan White
gidNumber: 1
homeDirectory: /home/dwhite
--
Hallvard
14 years, 10 months
Re: (ITS#5133) Synchronous replication on slave doesn't notice lost network connection
by stelios.xx.grigoriadis＠ericsson.com
We have created a patch that works for us. An updated version is
available for 2.4.9
The patch is using the parameter "mastercheckint" in slapd.conf, if
present. A separate
thread then continously askes the master for the root DSE.
An excerpt from the slapd.conf file:
# from master ldapt1.roadrunner
syncrepl rid=102
provider=ldap://ldapt1.roadrunner
type=refreshAndPersist
retry="10 10 60 +"
searchbase="dc=example,dc=com"
filter="(objectClass=*)"
scope=sub
schemachecking=off
sizelimit=500000
timelimit=360000
bindmethod=simple
mastercheckint=5 ### THIS is the new parameter.
binddn="cn=admin,dc=example,dc=com"
credentials=secret
updateref ldap://ldapt1.roadrunner
overlay syncprov
If the master unexpectedly terminates (eg. due to a power failure) the
replicas will get
a new connection once it's up again.
The patch is available at:
http://www.freewebs.com/stigri/Stelios-Grigoriadis-its5133-080514.patch
It must be run while in openlda-2.4.9 directory.
/Stelios Grigoriadis
14 years, 10 months
Re: (ITS#5507) Ldap clients leak file descriptors
by jsafrane＠redhat.com
Hallvard B Furuseth wrote:
> I've no idea how SELinux works, so I'm not up to testing any of what
> I'm saying here myself, but some notes follow anyway. Please clarify:
>
>> On system protected by SELinux, when an application with active LDAP
>> connection tries to exec() binary with different security context,
>> SELinux inspects all opened filedescriptors, including the ldap one,
>> and denies access to the ones, which do not conform active policy (the
>> executed binary is not authorized to contact LDAP servers). Users are
>> then annoyed by security warnings in the logs.
>
> More to the point, some of those security warnings may indicate real
> security problems. Bind with password, exec some application, and then
> that application has the bound user's access to LDAP.
That's exactly the case SELinux is trying to prevent.
> The message could be indicating a bug in the app - that it should
> release its resources (such as descriptors) before exec().
> Except, I presume this happens in system() as well?
> I'd be unfortunate if LDAP apps could not use system() safely.
I assume system() calls fork() and exec() internally, so yes, it's
protected as well.
SELinux can be extensively configured and if an admin thinks that
executed application can safely use inherited ldap connection, he/she
can allow it. But this is nearly impossible, because LDAP can be
integrated into pam (via nss_ldap). If pam uses nss_ldap, then really
lot of applications use ldap client indirectly. And nss_ldap can be
configured to keep the connection open for certain time so it's reused,
and the applications don't know, if the pam with nss_ldap has opened
ldap connection and they can't close it.
>> +#ifdef _GNU_SOURCE
>> + fcntl(s, F_SETFD, FD_CLOEXEC);
>> +#endif
>
> _GNU_SOURCE depends on the compiler flags. Please try
> #ifdef FD_CLOEXEC
> instead.
Agreed..
> Also I expect the same should be done in os-local.c:ldap_pvt_socket(),
Yes, it should. Again, please use fcntl(s, F_SETFD, FD_CLOEXEC);
Jan
14 years, 10 months
Re: (ITS#5504) ldapsearch hangs retrieving info
by Javier.Fernandez＠cern.ch
Thanks Quanah for your time. I have some answers/comments inline:
Quanah Gibson-Mount escribió:
> --On Wednesday, May 14, 2008 9:56 AM +0000 Javier.Fernandez(a)cern.ch
> wrote:
>
>> unfortunately there?s no update for openladp under SL4, that?s why we
>> are using such version. In fact I see no newer versions but for Fedora
>> and Mandriva
> <http://staff.telkomsa.net/packages/>
> or
> <http://www.symas.com>
I have tried installing last 2.4 version for RH but I get the same
result, since problem is not related to ldap version I'm afraid
>> In fact, other sites are living nice with that version or older ones.
>> In any case, I have compiled and built latest stable version from
>> openldap project webpage (2.3.39) and I get the same problem. I'm not
>> saying this is a bug from ldap, but something with local area network
>> configuration.
>>
>> I'm asking for some support to debug this problem actually.
> If the bug is not specifically in the OpenLDAP software, I suggest you
> peruse:
>
> <http://www.openldap.org/support/>
Well, this is the first thing I tried, but I got no solutions
browsing through the pages and therefore I tried this mailing list
referenced from that link.
> I would note I don't see anything particular in what you provide
> indicating the problem is with ldapsearch. What version of OpenLDAP
> is the server in question running (I see it is OpenLDAP by querying
> its rootDSE)?
>
> I'll note that a *limited* ldapsearch works just fine:
>
> [quanah@freelancer ~]$ ldapsearch -x -H ldap://exp-bdii.cern.ch:2170
> -b "" -s base +
> # extended LDIF
> #
> # LDAPv3
snip
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 2
> # numEntries: 1
That works fine for me.
> I would also note that for me, doing a dump of the entire server works
> just fine:
>
> ldapsearch -x -H ldap://exp-bdii.cern.ch:2170 -b "o=grid"
>
> results in:
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 43962
> # numEntries: 43961
I do not reach that point, in fact that is the problem: command gets
stuck retrieving one of the entries, in particular today it hangs at:
GlueCEAccessControlBaseRule: VO:ops
GlueForeignKey: GlueClusterUniqueID=ce104.cern.ch
GlueInformationServiceURL:
ldap://ce104.cern.ch:2170/mds-vo-name=resource,o=gr
id
GlueSchemaVersionMajor: 1
GlueSchemaVersionMinor: 3
and after a long long time, the output gives/jumps to another entry...
and it continues dripping entries from time to time for an indefinite
period until the command gives timeout.
A ping to exp-bdii.cern.ch gives an average delay of 40ms which I
consider normal.
From any other sites (e.g. any machine from CERN) the command works
fine in any openldap version, although I do not see any summary at the
end with such big number of entries and results as you do.
>
> Adding -d -1 to the query, I eventually see the same thing you do:
>
I just added it to perform some debugging but I do not know how to
interpret the results.
Once more: any hint on how to trace back this problem would be
really apreciated.
Thank you very much.
--
+--------------------------------------------------------------+
Javier Fernandez Menendez
Grupo de Fisica de AAEE
Universidad de Oviedo
C/ Calvo Sotelo, s/n
33005 Oviedo
Phone: +34 985106252
mailto:Javier.Fernandez@cern.ch
+---------------------------------------------------------------+
14 years, 10 months
Re: (ITS#5512) Doc contribution for search privileges in 2.4
by ghenry＠suretecsystems.com
> Hello,
>
> ITS #5400 outlines a change in the privileges required by search
> operations in
> 2.4. I would like to suggest documentation for this in the admin guide
> (the
> slapd.access man page is already accurate).
>
> Please find propositions here:
> 1) http://www.phillipoux.net/jonathan-clarke-20080515-upgrading.patch
> Explanation and example in the "Upgrading from 2.3" appendix.
>
> 2) http://www.phillipoux.net/jonathan-clarke-20080515-access-control.patch
> Detail of the required privileges on the "entry" pseudo-attribute in the
> access
> control section (static and dynamic config - same text is repeated twice).
>
>
> As a side note, I encountered a "452 Error writing file: No space left on
> device." error on ftp.openldap.org/incoming while trying to upload these
> patches.
>
Thanks for this. I was hoping to do this tomorrow as I've been so busy
this week, but now I don't need to!
Will patch, review and provide feedback as soon as I can.
Gavin.
--
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghenry(a)suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
Suretec Systems is a limited company registered in Scotland. Registered
number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie,
Aberdeenshire, AB51 4FP.
14 years, 10 months
(ITS#5514) Query about openLDAP on windows
by sushmita_mishra＠infosys.com
Full_Name: Sushmita Mishra
Version: 2.3.41
OS: Windows XP
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (220.225.64.6)
Hi,
I want to use openLDAP for authentication, for this purpose I have gone
through the documents available at <www.openldap.org/doc/admin24/>. In all these
documents, I found the installation for openLDAP directory server is given for
LINUX or UNIX only and not for Windows.
My query is Can we install openLDAP directory server on windows machine? If yes
can you please send me the steps for installing/configuring openLDAP directory
server on windows machine?
Thanks,
Sushmita Mishra
14 years, 10 months
(ITS#5513) back-ldap+ppolicy bind assertion failure
by mbackes＠symas.com
Full_Name: Matthew Backes
Version: 2.3, 2.4
OS: linux
URL:
Submission from: (NULL) (76.88.99.93)
A basic back-ldap configuration with the password policy overlay stacked on top
results in an assertfail for the second bind. e.g. given a working (possibly
empty db) on ldap://localhost:1389/...
include ...../core.schema
include ...../ppolicy.schema
modulepath .....
moduleload back_ldap.la
moduleload ppolicy.la
database ldap
suffix ""
uri ldap://localhost:1389/
After performing a successful remote bind, the next bind attempt halts the
back-ldap directory with:
slapd: bind.c:905: ldap_back_getconn: Assertion `( li->li_idassert.si_flags &
(0x02U) )' failed.
where 0x02U here is LDAP_BACK_AUTH_OVERRIDE.
This happens under both OpenLDAP 2.3 and 2.4.
14 years, 10 months
