[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: replica not replicating
Well,
the problem was that in the replica section, i passed with credentials
option, the password encrypted (such credentials={crypt}blabla), while
it had to be the clear text password... cuz of the one encryption
(stupid me!!!). it is replicating now :-D
this raises my second question: since the /etc/openldap/slapd.conf is
world readable, is there a more secure way to set this password in the
credentials option?
thanx for all the help (the debugging option on the commandline really
saved me ;) !
johnny
On Mon, 2003-02-17 at 18:19, Jason C. Leach wrote:
> On Mon, Feb 17, 2003 at 02:41:31PM +0100, Johnny Morano wrote:
> > Feb 17 14:32:18 devel slapd[17204]: daemon: socket() failed errno=97
> > (Address family not supported by protocol)
>
> This is a typical err msg. It does not effect replication.
>
> > also, the configfile of the master ldap server, states that it should
> > use this (replogfile /var/log/slapd/slapd.replog) file for replication
> > logging, but instead /var/lib/ldap/replica/slurpd.replog is being used,
> > anybody any clues why? the replog file that is in the config, remains
> > empty.
>
> slurp is responsible for replication. Thats probably why it goes to
> slurp's log file.
>
> > now, the replog file (in /var/lib/ldap/replica) reports the changes made
> > in the master server, but doesn't replicate them to the slave, see log
> <snip>
> > -
> > replace: modifyTimestamp
> > modifyTimestamp: 20030217120803Z
>
> This is a normal entry.
>
> Try running slurp with something like:
> /usr/sbin/slurpd -d 4 -t /var/spool/slurpd
> And it should write debug info to the console. You can better id some
> error messages from it. One I ran into was giving permision on the
> slave server for the master account to make modifications, including
> to the password attributes. The errors from the commmand above will
> help identify this.
>
>
> --
> ......................
> ..... Jason C. Leach
> ..
>
> Current PGP/GPG Key ID: 43AD2024