Re: Slurpd x Syncrepl [RESOLVIDO]
Ol lista,
Resolvi o problema adicionado as opes abaixo:
moduleload syncprov
overlay syncprov
syncprov-checkpoint 100 600
syncprov-sessionlog 1000
sessionlog 1 1000
paulobruck1 escreveu:
Ol Anderson
estava com o mesmo problema h 5 minutos atrs
vc pode repassar o seu slapd.conf do master e do slave na lista???
[]s
Em Seg, 2007-08-06 s 16:56 -0300, Anderson Eckhardt escreveu:
As mesmas configuraes apontando para um servidor LDAP
com o Debian Sarge funciona, eu apenas modifico o endereo
apontando para o LDAP no servidor Debian Etch e no funciona,
acredito que seja alguma mudana no OpenLdap, mais verifiquei
as releases e no encontrei nada que justifique.
Lembrando que o usurio em ambos os servidores possui permisso de
escrita.
Tiago Dias escreveu:
Voc est utilizando ACL?
Caso sim verifique as configuraes.
Caso no criei uma para dar direitos ao usurio admin, para o que
contudo que est sendo replicado.
J testei com o usurio administrador da Base
e mesmo assim no funcionou.
[]s
Em 06/08/07, Anderson Eckhardt [EMAIL PROTECTED] escreveu:
Bom dia pessoal,
Primeiramente obrigado pela dicas
Como era de se imaginar optei pelo syncrepl ;)
at fiz alguns testes com o slurpd que apenas comprovaram o que foi dito, mas no consegui fazer o syncrepl
funcionar no Debian Etch, apenas no Sarge.
Seguem alguns logs:
Servidor SLAVE(syncrepl)
Aug 6 10:29:34 hercules slapd[7087]: slapd starting
Aug 6 10:29:34 hercules slapd[7087]: do_syncrep2: got
search entry without control
Servidor Master
Aug 6 10:30:10 osiris slapd[12998]: conn=13 fd=11 ACCEPT
from IP=192.168.x.59:41287
Aug 6 10:30:10 osiris slapd[12998]: conn=13 op=0 BIND dn=""
method=128
Aug 6 10:30:10 osiris slapd[12998]: conn=13 op=0 RESULT
tag=97 err=0 text=
Aug 6 10:30:10 osiris slapd[12998]: conn=13 op=1 SRCH
base="dc=teste,dc=com,dc=br" scope=2 deref=0
filter="(objectClass=*)"
Aug 6 10:30:10 osiris slapd[12998]: conn=13 op=1 SRCH
attr=* +
Aug 6 10:30:10 osiris slapd[16259]: slap_global_control:
unrecognized control: 1.3.6.1.4.1.4203.1.9.1.1
Aug 6 10:30:10 osiris slapd[16259]: send_search_entry: conn
5 ber write failed.
Aug 6 10:30:11 osiris slapd[12998]: conn=13 op=2 UNBIND
Aparentemente algum erro de permisso, mas a senha
est correta.
A configurao est basicamente assim:
rootdn "cn=admin,dc=teste,dc=com,dc=br"
rotpw "{SSHA}teste"
syncrepl rid=123
provider=ldaps://ldap.teste
type=refreshOnly
interval=00:00:00:30
searchbase="dc=teste,dc=com,dc=br"
scope=sub
bindmethod=simple
binddn="cn=admin,dc=teste,dc=com,dc=br"
credentials="teste..."
Desde j obrigado.
[]s
Tiago Dias escreveu:
SLURPD
1. Lento
2. Pesado
3. Replicao toda a Base
SYNCREPL
1. Leve
2. Rpido (definio de tempo para replicao)
3. Replicao de toda a(s) base(s) ou de parte
dela(s).
Em 01/08/07, *Felipe Augusto van de Wiel (faw)*
[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
escreveu:
Ol Anderson,
On 01-08-2007 09:07, Anderson Eckhardt wrote:
Ol Lista,
Algum sabe informar qual a melhor opo para replicao
de Bases LDAP, slurd ou syncrepl, e por qu ?
Depende. :-)
slurpd o modelo antigo que segue o estilo push
de atualizao, ou seja, o master empurra as mudanas
para os slaves.
syncrepl a verso mais nova e usa uma idia
Re: Slurpd x Syncrepl
Bom dia pessoal,
Primeiramente obrigado pela dicas e desculpem a
demora em responder...
Como era de se imaginar optei pelo syncrepl ;)
at fiz alguns testes com o slurpd que apenas
comprovaram o que foi dito, mas no consegui o syncrepl funcionar no
Debian Etch,
testei as mesmas configuraes com servidores Debian Sarge e funcionou.
Seguem alguns logs:
Servidor SLAVE(syncrepl)
Aug 6 10:29:34 hercules slapd[7087]: slapd starting
Aug 6 10:29:34 hercules slapd[7087]: do_syncrep2: got search entry
without control
Servidor Master
Aug 6 10:30:10 osiris slapd[12998]: conn=13 fd=11 ACCEPT from
IP=192.168.x.59:41287
Aug 6 10:30:10 osiris slapd[12998]: conn=13 op=0 BIND dn="" method=128
Aug 6 10:30:10 osiris slapd[12998]: conn=13 op=0 RESULT tag=97 err=0
text=
Aug 6 10:30:10 osiris slapd[12998]: conn=13 op=1 SRCH
base="dc=teste,dc=com,dc=br" scope=2 deref=0 filter="(objectClass=*)"
Aug 6 10:30:10 osiris slapd[12998]: conn=13 op=1 SRCH attr=* +
Aug 6 10:30:10 osiris slapd[16259]: slap_global_control: unrecognized
control: 1.3.6.1.4.1.4203.1.9.1.1
Aug 6 10:30:10 osiris slapd[16259]: send_search_entry: conn 5 ber
write failed.
Aug 6 10:30:11 osiris slapd[12998]: conn=13 op=2 UNBIND
Aparentemente algum erro de permisso, mas a senha est
correta.
A configurao est basicamente assim:
rootdn "cn=admin,dc=teste,dc=com,dc=br"
rotpw "{SSHA}teste"
syncrepl rid=123
provider=ldaps://ldap.teste
type=refreshOnly
interval=00:00:00:30
searchbase="dc=teste,dc=com,dc=br"
scope=sub
bindmethod=simple
binddn="cn=admin,dc=teste,dc=com,dc=br"
credentials="teste..."
Desde j obrigado.
[]s
Tiago Dias escreveu:
SLURPD
1. Lento
2. Pesado
3. Replicao toda a Base
SYNCREPL
1. Leve
2. Rpido (definio de tempo para replicao)
3. Replicao de toda a(s) base(s) ou de parte dela(s).
Em 01/08/07, *Felipe Augusto van de Wiel (faw)*
[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
escreveu:
Ol Anderson,
On 01-08-2007 09:07, Anderson Eckhardt wrote:
Ol Lista,
Algum sabe informar qual a melhor opo para replicao
de Bases LDAP, slurd ou syncrepl, e por qu ?
Depende. :-)
slurpd o modelo antigo que segue o estilo push
de atualizao, ou seja, o master empurra as mudanas
para os slaves.
syncrepl a verso mais nova e usa uma idia
similar ao estilo de atualizao do DNS, h casos e
cenrios para cada uma delas.
Gostara de saber tambm quais so as principais
vantagens e desvantagens de ambos os sistemas ?
Geralmente, o slurpd tende a ser mais lento e
"pesado" nas operaes, sua forma incremental tem chances
de perder sincronia e no recuperar.
O syncrepl sendo mais recente foi desenhado para
suportar perdas de sincronias e recuperar o que foi
perdido, mas isso pode no acontecer dependendo de
alguns itens do cenrio em questo.
Desde j obrigado.
[]s
Abrao,
--
To UNSUBSCRIBE, email to
[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact
[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
--
Tiago Dias da Silva
Administrador de Sistemas GNU/Linux
HomePage: www.dias.eti.br http://www.dias.eti.br
Email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
"A mente que se abre a uma nova
idia jamais voltar ao seu tamanho original"
(Albert Einstein)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Slurpd x Syncrepl
Você está utilizando ACL?
Caso sim verifique as configurações.
Caso não criei uma para dar direitos ao usuário admin, para o que contéudo
que está sendo replicado.
Em 06/08/07, Anderson Eckhardt [EMAIL PROTECTED] escreveu:
Bom dia pessoal,
Primeiramente obrigado pela dicas e desculpem a
demora em responder...
Como era de se imaginar optei pelo syncrepl ;)
até fiz alguns testes com o slurpd que apenas
comprovaram o que foi dito, mas não consegui o syncrepl funcionar no
Debian Etch,
testei as mesmas configurações com servidores Debian Sarge e funcionou.
Seguem alguns logs:
Servidor SLAVE(syncrepl)
Aug 6 10:29:34 hercules slapd[7087]: slapd starting
Aug 6 10:29:34 hercules slapd[7087]: do_syncrep2: got search entry
without control
Servidor Master
Aug 6 10:30:10 osiris slapd[12998]: conn=13 fd=11 ACCEPT from IP=
192.168.x.59:41287
Aug 6 10:30:10 osiris slapd[12998]: conn=13 op=0 BIND dn= method=128
Aug 6 10:30:10 osiris slapd[12998]: conn=13 op=0 RESULT tag=97 err=0
text=
Aug 6 10:30:10 osiris slapd[12998]: conn=13 op=1 SRCH
base=dc=teste,dc=com,dc=br scope=2 deref=0 filter=(objectClass=*)
Aug 6 10:30:10 osiris slapd[12998]: conn=13 op=1 SRCH attr=* +
Aug 6 10:30:10 osiris slapd[16259]: slap_global_control: unrecognized
control: 1.3.6.1.4.1.4203.1.9.1.1
Aug 6 10:30:10 osiris slapd[16259]: send_search_entry: conn 5 ber write
failed.
Aug 6 10:30:11 osiris slapd[12998]: conn=13 op=2 UNBIND
Aparentemente algum erro de permissão, mas a senha está correta.
A configuração está basicamente assim:
rootdn cn=admin,dc=teste,dc=com,dc=br
rotpw {SSHA}teste
syncrepl rid=123
provider=ldaps://ldap.teste
type=refreshOnly
interval=00:00:00:30
searchbase=dc=teste,dc=com,dc=br
scope=sub
bindmethod=simple
binddn=cn=admin,dc=teste,dc=com,dc=br
credentials=teste...
Desde já obrigado.
[]s
Tiago Dias escreveu:
SLURPD
1. Lento
2. Pesado
3. Replicação toda a Base
SYNCREPL
1. Leve
2. Rápido (definição de tempo para replicação)
3. Replicação de toda a(s) base(s) ou de parte dela(s).
Em 01/08/07, *Felipe Augusto van de Wiel (faw)*
[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] [EMAIL PROTECTED]
escreveu:
Olá Anderson,
On 01-08-2007 09:07, Anderson Eckhardt wrote:
Olá Lista,
Alguém sabe informar qual a melhor opção para replicação
de Bases LDAP, slurd ou syncrepl, e por quê ?
Depende. :-)
slurpd é o modelo antigo que segue o estilo push
de atualização, ou seja, o master empurra as mudanças
para os slaves.
syncrepl é a versão mais nova e usa uma idéia
similar ao estilo de atualização do DNS, há casos e
cenários para cada uma delas.
Gostaría de saber também quais são as principais
vantagens e desvantagens de ambos os sistemas ?
Geralmente, o slurpd tende a ser mais lento e
pesado nas operações, sua forma incremental tem chances
de perder sincronia e não recuperar.
O syncrepl sendo mais recente foi desenhado para
suportar perdas de sincronias e recuperar o que foi
perdido, mas isso pode não acontecer dependendo de
alguns itens do cenário em questão.
Desde já obrigado.
[]s
Abraço,
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED][EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED][EMAIL PROTECTED]
--
Tiago Dias da Silva
Administrador de Sistemas GNU/Linux
HomePage: www.dias.eti.br http://www.dias.eti.brhttp://www.dias.eti.br
Email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [EMAIL PROTECTED]
A mente que se abre a uma nova
idéia jamais voltará ao seu tamanho original
(Albert Einstein)
-- To UNSUBSCRIBE, email to
[EMAIL PROTECTED] with a subject of
unsubscribe. Trouble? Contact [EMAIL PROTECTED]
--
Tiago Dias da Silva
Administrador de Sistemas GNU/Linux
HomePage: www.dias.eti.br
Email: [EMAIL PROTECTED]
A mente que se abre a uma nova idéia jamais voltará ao seu tamanho
original
(Albert Einstein)
Re: Slurpd x Syncrepl
J testei com o usurio adminitrador da Base
e mesmo assim no funcionou.
[]s
Tiago Dias escreveu:
Voc est utilizando ACL?
Caso sim verifique as configuraes.
Caso no criei uma para dar direitos ao usurio admin, para o que
contudo que est sendo replicado.
Em 06/08/07, Anderson Eckhardt [EMAIL PROTECTED]
escreveu:
Bom dia pessoal,
Primeiramente obrigado pela dicas e desculpem a
demora em responder...
Como era de se imaginar optei pelo syncrepl ;)
at fiz alguns testes com o slurpd que apenas
comprovaram o que foi dito, mas no consegui o syncrepl funcionar no
Debian Etch,
testei as mesmas configuraes com servidores Debian Sarge e funcionou.
Seguem alguns logs:
Servidor SLAVE(syncrepl)
Aug 6 10:29:34 hercules slapd[7087]: slapd starting
Aug 6 10:29:34 hercules slapd[7087]: do_syncrep2: got search entry
without control
Servidor Master
Aug 6 10:30:10 osiris slapd[12998]: conn=13 fd=11 ACCEPT from
IP=192.168.x.59:41287
Aug 6 10:30:10 osiris slapd[12998]: conn=13 op=0 BIND dn="" method=128
Aug 6 10:30:10 osiris slapd[12998]: conn=13 op=0 RESULT tag=97 err=0
text=
Aug 6 10:30:10 osiris slapd[12998]: conn=13 op=1 SRCH
base="dc=teste,dc=com,dc=br" scope=2 deref=0 filter="(objectClass=*)"
Aug 6 10:30:10 osiris slapd[12998]: conn=13 op=1 SRCH attr=* +
Aug 6 10:30:10 osiris slapd[16259]: slap_global_control: unrecognized
control: 1.3.6.1.4.1.4203.1.9.1.1
Aug 6 10:30:10 osiris slapd[16259]: send_search_entry: conn 5 ber
write failed.
Aug 6 10:30:11 osiris slapd[12998]: conn=13 op=2 UNBIND
Aparentemente algum erro de permisso, mas a senha est
correta.
A configurao est basicamente assim:
rootdn "cn=admin,dc=teste,dc=com,dc=br"
rotpw "{SSHA}teste"
syncrepl rid=123
provider=ldaps://ldap.teste
type=refreshOnly
interval=00:00:00:30
searchbase="dc=teste,dc=com,dc=br"
scope=sub
bindmethod=simple
binddn="cn=admin,dc=teste,dc=com,dc=br"
credentials="teste..."
Desde j obrigado.
[]s
Tiago Dias escreveu:
SLURPD
1. Lento
2. Pesado
3. Replicao toda a Base
SYNCREPL
1. Leve
2. Rpido (definio de tempo para replicao)
3. Replicao de toda a(s) base(s) ou de parte dela(s).
Em 01/08/07, *Felipe Augusto van de Wiel (faw)*
[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
escreveu:
Ol Anderson,
On 01-08-2007 09:07, Anderson Eckhardt wrote:
Ol Lista,
Algum sabe informar qual a melhor opo para replicao
de Bases LDAP, slurd ou syncrepl, e por qu ?
Depende. :-)
slurpd o modelo antigo que segue o estilo push
de atualizao, ou seja, o master empurra as mudanas
para os slaves.
syncrepl a verso mais nova e usa uma idia
similar ao estilo de atualizao do DNS, h casos e
cenrios para cada uma delas.
Gostara de saber tambm quais so as principais
vantagens e desvantagens de ambos os sistemas ?
Geralmente, o slurpd tende a ser mais lento e
"pesado" nas operaes, sua forma incremental tem chances
de perder sincronia e no recuperar.
O syncrepl sendo mais recente foi desenhado para
suportar perdas de sincronias e recuperar o que foi
perdido, mas isso pode no acontecer dependendo de
alguns itens do cenrio em questo.
Desde j obrigado.
[]s
Abrao,
--
To UNSUBSCRIBE, email to
[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact
[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
--
Tiago Dias da Silva
Administrador de Sistemas GNU/Linux
HomePage: www.dias.eti.br
http://www.dias.eti.br
Email: [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
"A mente que se abre a uma nova
idia jamais voltar ao seu tamanho original"
(Albert Einstein)
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
--
Tiago Dias da Silva
Administrador de Sistemas GNU/Linux
HomePage: www.dias.eti.br
Email:
[EMAIL PROTECTED]
"A mente que se abre a uma nova idia jamais voltar ao seu tamanho
original"
(Albert Einstein)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Slurpd x Syncrepl
As mesmas configuraes apontando para um servidor LDAP
com o Debian Sarge funciona, eu apenas modifico o endereo
apontando para o LDAP no servidor Debian Etch e no funciona,
acredito que seja alguma mudana no OpenLdap, mais verifiquei
as releases e no encontrei nada que justifique.
Lembrando que o usurio em ambos os servidores possui permisso de
escrita.
Tiago Dias escreveu:
Voc est utilizando ACL?
Caso sim verifique as configuraes.
Caso no criei uma para dar direitos ao usurio admin, para o que
contudo que est sendo replicado.
J testei com o usurio administrador da Base
e mesmo assim no funcionou.
[]s
Em 06/08/07, Anderson Eckhardt [EMAIL PROTECTED]
escreveu:
Bom dia pessoal,
Primeiramente obrigado pela dicas e desculpem a
demora em responder...
Como era de se imaginar optei pelo syncrepl ;)
at fiz alguns testes com o slurpd que apenas
comprovaram o que foi dito, mas no consegui o syncrepl funcionar no
Debian Etch,
testei as mesmas configuraes com servidores Debian Sarge e funcionou.
Seguem alguns logs:
Servidor SLAVE(syncrepl)
Aug 6 10:29:34 hercules slapd[7087]: slapd starting
Aug 6 10:29:34 hercules slapd[7087]: do_syncrep2: got search entry
without control
Servidor Master
Aug 6 10:30:10 osiris slapd[12998]: conn=13 fd=11 ACCEPT from
IP=192.168.x.59:41287
Aug 6 10:30:10 osiris slapd[12998]: conn=13 op=0 BIND dn="" method=128
Aug 6 10:30:10 osiris slapd[12998]: conn=13 op=0 RESULT tag=97 err=0
text=
Aug 6 10:30:10 osiris slapd[12998]: conn=13 op=1 SRCH
base="dc=teste,dc=com,dc=br" scope=2 deref=0 filter="(objectClass=*)"
Aug 6 10:30:10 osiris slapd[12998]: conn=13 op=1 SRCH attr=* +
Aug 6 10:30:10 osiris slapd[16259]: slap_global_control: unrecognized
control: 1.3.6.1.4.1.4203.1.9.1.1
Aug 6 10:30:10 osiris slapd[16259]: send_search_entry: conn 5 ber
write failed.
Aug 6 10:30:11 osiris slapd[12998]: conn=13 op=2 UNBIND
Aparentemente algum erro de permisso, mas a senha est
correta.
A configurao est basicamente assim:
rootdn "cn=admin,dc=teste,dc=com,dc=br"
rotpw "{SSHA}teste"
syncrepl rid=123
provider=ldaps://ldap.teste
type=refreshOnly
interval=00:00:00:30
searchbase="dc=teste,dc=com,dc=br"
scope=sub
bindmethod=simple
binddn="cn=admin,dc=teste,dc=com,dc=br"
credentials="teste..."
Desde j obrigado.
[]s
Tiago Dias escreveu:
SLURPD
1. Lento
2. Pesado
3. Replicao toda a Base
SYNCREPL
1. Leve
2. Rpido (definio de tempo para replicao)
3. Replicao de toda a(s) base(s) ou de parte dela(s).
Em 01/08/07, *Felipe Augusto van de Wiel (faw)*
[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
escreveu:
Ol Anderson,
On 01-08-2007 09:07, Anderson Eckhardt wrote:
Ol Lista,
Algum sabe informar qual a melhor opo para replicao
de Bases LDAP, slurd ou syncrepl, e por qu ?
Depende. :-)
slurpd o modelo antigo que segue o estilo push
de atualizao, ou seja, o master empurra as mudanas
para os slaves.
syncrepl a verso mais nova e usa uma idia
similar ao estilo de atualizao do DNS, h casos e
cenrios para cada uma delas.
Gostara de saber tambm quais so as principais
vantagens e desvantagens de ambos os sistemas ?
Geralmente, o slurpd tende a ser mais lento e
"pesado" nas operaes, sua forma incremental tem chances
de perder sincronia e no recuperar.
O syncrepl sendo mais recente foi desenhado para
suportar perdas de sincronias e recuperar o que foi
perdido, mas isso pode no acontecer dependendo de
alguns itens do cenrio em questo.
Desde j obrigado.
[]s
Abrao,
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
--
Tiago Dias da Silva
Administrador de Sistemas GNU/Linux
HomePage: www.dias.eti.br
http://www.dias.eti.br
Email: [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
"A mente que se abre a uma nova
idia jamais voltar ao seu tamanho original"
(Albert Einstein)
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
--
Tiago Dias da Silva
Administrador de Sistemas GNU/Linux
Re: Slurpd x Syncrepl
Olá Anderson
estava com o mesmo problema há 5 minutos atrás
vc pode repassar o seu slapd.conf do master e do slave na lista???
[]s
Em Seg, 2007-08-06 às 16:56 -0300, Anderson Eckhardt escreveu:
As mesmas configurações apontando para um servidor LDAP
com o Debian Sarge funciona, eu apenas modifico o endereço
apontando para o LDAP no servidor Debian Etch e não funciona,
acredito que seja alguma mudança no OpenLdap, mais verifiquei
as releases e não encontrei nada que justifique.
Lembrando que o usuário em ambos os servidores possui permissão de
escrita.
Tiago Dias escreveu:
Você está utilizando ACL?
Caso sim verifique as configurações.
Caso não criei uma para dar direitos ao usuário admin, para o que
contéudo que está sendo replicado.
Já testei com o usuário administrador da Base
e mesmo assim não funcionou.
[]s
Em 06/08/07, Anderson Eckhardt [EMAIL PROTECTED] escreveu:
Bom dia pessoal,
Primeiramente obrigado pela dicas e desculpem a
demora em responder...
Como era de se imaginar optei pelo syncrepl ;)
até fiz alguns testes com o slurpd que apenas
comprovaram o que foi dito, mas não consegui o syncrepl
funcionar no Debian Etch,
testei as mesmas configurações com servidores Debian Sarge e
funcionou.
Seguem alguns logs:
Servidor SLAVE(syncrepl)
Aug 6 10:29:34 hercules slapd[7087]: slapd starting
Aug 6 10:29:34 hercules slapd[7087]: do_syncrep2: got
search entry without control
Servidor Master
Aug 6 10:30:10 osiris slapd[12998]: conn=13 fd=11 ACCEPT
from IP=192.168.x.59:41287
Aug 6 10:30:10 osiris slapd[12998]: conn=13 op=0 BIND dn=
method=128
Aug 6 10:30:10 osiris slapd[12998]: conn=13 op=0 RESULT
tag=97 err=0 text=
Aug 6 10:30:10 osiris slapd[12998]: conn=13 op=1 SRCH
base=dc=teste,dc=com,dc=br scope=2 deref=0
filter=(objectClass=*)
Aug 6 10:30:10 osiris slapd[12998]: conn=13 op=1 SRCH
attr=* +
Aug 6 10:30:10 osiris slapd[16259]: slap_global_control:
unrecognized control: 1.3.6.1.4.1.4203.1.9.1.1
Aug 6 10:30:10 osiris slapd[16259]: send_search_entry: conn
5 ber write failed.
Aug 6 10:30:11 osiris slapd[12998]: conn=13 op=2 UNBIND
Aparentemente algum erro de permissão, mas a senha
está correta.
A configuração está basicamente assim:
rootdn cn=admin,dc=teste,dc=com,dc=br
rotpw {SSHA}teste
syncrepl rid=123
provider=ldaps://ldap.teste
type=refreshOnly
interval=00:00:00:30
searchbase=dc=teste,dc=com,dc=br
scope=sub
bindmethod=simple
binddn=cn=admin,dc=teste,dc=com,dc=br
credentials=teste...
Desde já obrigado.
[]s
Tiago Dias escreveu:
SLURPD
1. Lento
2. Pesado
3. Replicação toda a Base
SYNCREPL
1. Leve
2. Rápido (definição de tempo para replicação)
3. Replicação de toda a(s) base(s) ou de parte
dela(s).
Em 01/08/07, *Felipe Augusto van de Wiel (faw)*
[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
escreveu:
Olá Anderson,
On 01-08-2007 09:07, Anderson Eckhardt wrote:
Olá Lista,
Alguém sabe informar qual a melhor opção para replicação
de Bases LDAP, slurd ou syncrepl, e por quê ?
Depende. :-)
