OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Archive.Incoming/2264
Full headers

From: quanah@stanford.edu
Subject: Slurpd failes to log changes for downed hosts
Compose comment
Download message
State:
0 replies:
1 followups: 1

Major security issue: yes  no

Notes:

Notification:


Date: Mon, 13 Jan 2003 22:53:26 GMT
From: quanah@stanford.edu
To: openldap-its@OpenLDAP.org
Subject: Slurpd failes to log changes for downed hosts
Full_Name: Quanah Gibson-Mount
Version: 2.1.10
OS: Solaris 8
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (171.64.19.82)


Hello,

On January 10th, prior to testing of the mechanism used for writing changes to
our directory server, I added in a number of new replicas to our system --
ldap5-ldap9.  ldap1-ldap4 were already in as replicas.  Of ldap1-4, ldap3 was
down.  Of ldap5-ldap9, ldap7 was the only one up.  I then stopped &
restarted
slapd & slurpd.  After the weekend was over, /var/log/replog was size 0.  No
record of the changes has been saved for ldap3, ldap5-6, or ldap8-9. 
Replication did occur correctly to the systems that were up (1,2,4,7).  There is
something seriously flawed in slurpd.  Stopping and restarting slapd/slurpd
today, and then making a change, shows that the same behaviour continues (except
that 3 has been brought up, and replication correctly occurs to it).  

Here is my replica configuration:

# Replica Directives

replica         host=ldap9.stanford.edu:389
                tls=yes bindmethod=sasl
                binddn=cn=replicator,cn=applications,dc=stanford,dc=edu
saslmech=gssapi

replica         host=ldap8.stanford.edu:389
                tls=yes bindmethod=sasl
                binddn=cn=replicator,cn=applications,dc=stanford,dc=edu
saslmech=gssapi

replica         host=ldap7.stanford.edu:389
                tls=yes bindmethod=sasl
                binddn=cn=replicator,cn=applications,dc=stanford,dc=edu
saslmech=gssapi

replica         host=ldap6.stanford.edu:389
                tls=yes bindmethod=sasl
                binddn=cn=replicator,cn=applications,dc=stanford,dc=edu
saslmech=gssapi

replica         host=ldap5.stanford.edu:389
                tls=yes bindmethod=sasl
                binddn=cn=replicator,cn=applications,dc=stanford,dc=edu
saslmech=gssapi

replica         host=ldap4.stanford.edu:389
                tls=yes bindmethod=sasl
                binddn=cn=replicator,cn=applications,dc=stanford,dc=edu
saslmech=gssapi

replica         host=ldap3.stanford.edu:389
                tls=yes bindmethod=sasl
                binddn=cn=replicator,cn=applications,dc=stanford,dc=edu
saslmech=gssapi

replica         host=ldap2.stanford.edu:389
                tls=yes bindmethod=sasl
                binddn=cn=replicator,cn=applications,dc=stanford,dc=edu
saslmech=gssapi

replica         host=ldap1.stanford.edu:389
                tls=yes bindmethod=sasl
                binddn=cn=replicator,cn=applications,dc=stanford,dc=edu
saslmech=gssapi

replogfile      /var/log/replog




--Quanah


Followup 1

Download message
Date: Mon, 13 Jan 2003 15:44:00 -0800
From: Quanah Gibson-Mount <quanah@stanford.edu>
To: openldap-its@OpenLDAP.org
Subject: (ITS#2264)
close this ticket, was looking at the wrong replog file.

--Quanah

--On Monday, January 13, 2003 10:53 PM +0000 openldap-its@OpenLDAP.org 
wrote:

>
> *** THIS IS AN AUTOMATICALLY GENERATED REPLY ***
>
> Thanks for your report to the OpenLDAP Issue Tracking System.  Your
> report has been assigned the tracking number ITS#2264.
>
> One of our support engineers will look at your report in due course.
> Note that this may take some time because our support engineers
> are volunteers.  They only work on OpenLDAP when they have spare
> time.
>
> If you need to provide additional information in regards to your
> issue report, you may do so by replying to this message.  Note that
> any mail sent to openldap-its@openldap.org with (ITS#2264)
> in the subject will automatically be attached to the issue report.
>
> 	mailto:openldap-its@openldap.org?subject=(ITS#2264)
>
> You may follow the progress of this report by loading the following
> URL in a web browser:
>     http://www.OpenLDAP.org/its/index.cgi?findid=2264
>
> Please remember to retain your issue tracking number (ITS#2264)
> on any further messages you send to us regarding this report.  If
> you don't then you'll just waste our time and yours because we
> won't be able to properly track the report.
>
> Please note that the Issue Tracking System is not intended to
> be used to seek help in the proper use of OpenLDAP Software.
> Such requests will be closed.
>
> OpenLDAP Software is user supported.
> 	http://www.OpenLDAP.org/support/
>
> --------------
> Copyright 1999-2003 The OpenLDAP Foundation, All Rights Reserved.
>



--
Quanah Gibson-Mount
Senior Systems Administrator
ITSS/TSS/Computing Systems
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org