Issue 2264 - Slurpd failes to log changes for downed hosts
Summary: Slurpd failes to log changes for downed hosts
Status: VERIFIED FIXED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: unspecified
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-01-13 22:53 UTC by Quanah Gibson-Mount
Modified: 2007-10-18 11:17 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Howard Chu 2003-01-13 16:25:09 UTC
changed state Open to Closed
Comment 1 Quanah Gibson-Mount 2003-01-13 22:53:26 UTC
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

Comment 2 Quanah Gibson-Mount 2003-01-13 23:44:00 UTC
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

Comment 3 Howard Chu 2007-10-18 11:17:26 UTC
moved from Incoming to Archive.Incoming