On 03/12/2012 11:30 AM, mjames@guesswho.com wrote:
Thanks for your previous help. I built a
new server, CentOS 6.2, added the epel-389-ds-base and epel
repos, then installed 389-ds via yum. I ran setup-ds-admin.pl
with the “Typical” setup option, user nobody, and registered
with one of our existing configuration servers. I created the
supplier bind DN on the new server per the installation docs.
*
At this point, I can’t establish a
replication agreement. I open the 389-console on existing
server and use the GUI to create a new replication agreement
on userRoot. I accepted the defaults, entered the correct bind
DN and password. At the end of the wizard, it fails with “LDAP
server is unwilling to perform”. In the error log, I see one
error. Any help is appreciated. Thanks, Mike
Can you run the console with -D 9 -f console.log, reproduce the
problem, remove any sensitive information from console.log, and post
console.log to this list?
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
03-12-2012, 04:30 PM
LDAP server is unwilling to perform
Thanks for your previous help. I built a new server, CentOS 6.2, added the epel-389-ds-base and epel repos, then installed 389-ds via yum. I ran setup-ds-admin.pl with the “Typical” setup option, user nobody, and registered with one of our existing configuration servers. I created the supplier bind DN on the new server per the installation docs.
*
At this point, I can’t establish a replication agreement. I open the 389-console on existing server and use the GUI to create a new replication agreement on userRoot. I accepted the defaults, entered the correct bind DN and password. At the end of the wizard, it fails with “LDAP server is unwilling to perform”. In the error log, I see one error. Any help is appreciated. Thanks, Mike
*
[12/Mar/2012:13:26:46 -0400] NSMMReplicationPlugin - agmtlist_add_callback: Can't start agreement "cn=389 to analog-01v,cn=replica,cn=dc3d<MY_DOMAIN>2c dc3dcom,cn=mapping tree,cn=config"
*
Existing server: RHEL 5.7 32-bit
[root@x-web-389-01 ~]# rpm -qa | grep 389
389-admin-console-1.1.8-1.el5
389-ds-base-libs-1.2.9.9-1.el5
389-ds-console-doc-1.2.6-1.el5
389-adminutil-1.1.14-1.el5
389-dsgw-1.1.7-2.el5
389-ds-console-1.2.6-1.el5
389-console-1.1.7-3.el5
389-admin-1.1.23-1.el5
389-admin-console-doc-1.1.8-1.el5
389-ds-base-1.2.9.9-1.el5
389-ds-1.2.1-1.el5
*
*
New server: CentOS 6.2
[root@x-analog-01v ~]# rpm -qa | grep 389
389-ds-console-doc-1.2.6-1.el6.noarch
389-ds-base-libs-1.2.10.3-1.el6.x86_64
389-ds-1.2.2-1.el6.noarch
389-console-1.1.7-1.el6.noarch
389-admin-console-1.1.8-1.el6.noarch
389-dsgw-1.1.7-2.el6.x86_64
389-adminutil-1.1.14-2.el6.x86_64
389-admin-1.1.25-1.el6.x86_64
389-admin-console-doc-1.1.8-1.el6.noarch
389-ds-base-1.2.10.3-1.el6.x86_64
389-ds-console-1.2.6-1.el6.noarch
*
*
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
03-12-2012, 05:39 PM
LDAP server is unwilling to perform
Pls. see attached. Thx.
*
Mike
*
From: Rich Megginson [mailto:rmeggins@redhat.com]
Sent: Monday, March 12, 2012 1:30 PM
To: General discussion list for the 389 Directory server project.
Cc: Michael James
Subject: Re: [389-users] LDAP server is unwilling to perform
*
On 03/12/2012 11:30 AM, mjames@guesswho.com wrote:
Thanks for your previous help. I built a new server, CentOS 6.2, added the epel-389-ds-base and epel repos, then installed 389-ds via yum. I ran setup-ds-admin.pl with the “Typical” setup option, user nobody, and registered with one of our existing configuration servers. I created the supplier bind DN on the new server per the installation docs.
*
At this point, I can’t establish a replication agreement. I open the 389-console on existing server and use the GUI to create a new replication agreement on userRoot. I accepted the defaults, entered the correct bind DN and password. At the end of the wizard, it fails with “LDAP server is unwilling to perform”. In the error log, I see one error. Any help is appreciated. Thanks, Mike
Can you run the console with -D 9 -f console.log, reproduce the problem, remove any sensitive information from console.log, and post console.log to this list?
On 03/12/2012 12:39 PM, mjames@guesswho.com wrote:
Pls.
see attached. Thx.
Hmm - nothing to go on there - please turn on the Replication log
level and reproduce the problem - then the errors log may contain
more clues
http://port389.org/wiki/FAQ#Troubleshooting
*
Mike
*
From:
Rich Megginson [mailto:rmeggins@redhat.com]
Sent: Monday, March 12, 2012 1:30 PM
To: General discussion list for the 389 Directory
server project.
Cc: Michael James
Subject: Re: [389-users] LDAP server is unwilling
to perform
*
On 03/12/2012 11:30 AM, mjames@guesswho.com
wrote:
Thanks for your previous help. I built a
new server, CentOS 6.2, added the epel-389-ds-base and epel
repos, then installed 389-ds via yum. I ran setup-ds-admin.pl
with the “Typical” setup option, user nobody, and registered
with one of our existing configuration servers. I created the
supplier bind DN on the new server per the installation docs.
*
At this point, I can’t establish a
replication agreement. I open the 389-console on existing
server and use the GUI to create a new replication agreement
on userRoot. I accepted the defaults, entered the correct bind
DN and password. At the end of the wizard, it fails with “LDAP
server is unwilling to perform”. In the error log, I see one
error. Any help is appreciated. Thanks, Mike
Can you run the console with
-D 9 -f console.log, reproduce the problem, remove any
sensitive information from console.log, and post console.log
to this list?
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
03-13-2012, 02:41 PM
LDAP server is unwilling to perform
Pls see attached new console.log. Thanks.
*
Mike
*
From: Rich Megginson [mailto:rmeggins@redhat.com]
Sent: Monday, March 12, 2012 3:14 PM
To: General discussion list for the 389 Directory server project.
Cc: Michael James
Subject: Re: [389-users] LDAP server is unwilling to perform
*
On 03/12/2012 12:39 PM, mjames@guesswho.com wrote:
Pls. see attached. Thx.
Hmm - nothing to go on there - please turn on the Replication log level and reproduce the problem - then the errors log may contain more clues
http://port389.org/wiki/FAQ#Troubleshooting
*
Mike
*
From: Rich Megginson [mailto:rmeggins@redhat.com]
Sent: Monday, March 12, 2012 1:30 PM
To: General discussion list for the 389 Directory server project.
Cc: Michael James
Subject: Re: [389-users] LDAP server is unwilling to perform
*
On 03/12/2012 11:30 AM, mjames@guesswho.com wrote:
Thanks for your previous help. I built a new server, CentOS 6.2, added the epel-389-ds-base and epel repos, then installed 389-ds via yum. I ran setup-ds-admin.pl with the “Typical” setup option, user nobody, and registered with one of our existing configuration servers. I created the supplier bind DN on the new server per the installation docs.
*
At this point, I can’t establish a replication agreement. I open the 389-console on existing server and use the GUI to create a new replication agreement on userRoot. I accepted the defaults, entered the correct bind DN and password. At the end of the wizard, it fails with “LDAP server is unwilling to perform”. In the error log, I see one error. Any help is appreciated. Thanks, Mike
Can you run the console with -D 9 -f console.log, reproduce the problem, remove any sensitive information from console.log, and post console.log to this list?
On 03/13/2012 09:41 AM, mjames@guesswho.com wrote:
Pls see
attached new console.log. Thanks.
If you follow the directions at http://port389.org/wiki/FAQ#Troubleshooting
to enable the Replication log level, the extra information will be
in the directory server errors log, not the console log -
/var/log/dirsrv/slapd-INST/errors
*
Mike
*
From:
Rich Megginson [mailto:rmeggins@redhat.com]
Sent: Monday, March 12, 2012 3:14 PM
To: General discussion list for the 389 Directory
server project.
Cc: Michael James
Subject: Re: [389-users] LDAP server is unwilling
to perform
*
On 03/12/2012 12:39 PM, mjames@guesswho.com
wrote:
Pls. see
attached. Thx.
Hmm - nothing to go on there
- please turn on the Replication log level and reproduce the
problem - then the errors log may contain more clues
http://port389.org/wiki/FAQ#Troubleshooting
*
Mike
*
From:
Rich Megginson [mailto:rmeggins@redhat.com]
Sent: Monday, March 12, 2012 1:30 PM
To: General discussion list for the 389 Directory
server project.
Cc: Michael James
Subject: Re: [389-users] LDAP server is unwilling
to perform
*
On 03/12/2012 11:30 AM, mjames@guesswho.com
wrote:
Thanks for your previous help. I built a
new server, CentOS 6.2, added the epel-389-ds-base and epel
repos, then installed 389-ds via yum. I ran setup-ds-admin.pl
with the “Typical” setup option, user nobody, and registered
with one of our existing configuration servers. I created the
supplier bind DN on the new server per the installation docs.
*
At this point, I can’t establish a
replication agreement. I open the 389-console on existing
server and use the GUI to create a new replication agreement
on userRoot. I accepted the defaults, entered the correct bind
DN and password. At the end of the wizard, it fails with “LDAP
server is unwilling to perform”. In the error log, I see one
error. Any help is appreciated. Thanks, Mike
Can you run the console with
-D 9 -f console.log, reproduce the problem, remove any
sensitive information from console.log, and post console.log
to this list?
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
*
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
03-13-2012, 03:23 PM
LDAP server is unwilling to perform
Sorry, forgot to send this to the list.
*
From: Michael James
Sent: Tuesday, March 13, 2012 12:13 PM
To: 'Rich Megginson'
Subject: RE: [389-users] LDAP server is unwilling to perform
*
That’s a big *IF* there… I did turn up the logging. Attached is the error log, trimmed to around the time that I tried to create the new replication agreement. Sorry about that.
*
From: Rich Megginson [mailto:rmeggins@redhat.com]
Sent: Tuesday, March 13, 2012 11:51 AM
To: General discussion list for the 389 Directory server project.
Cc: Michael James
Subject: Re: [389-users] LDAP server is unwilling to perform
*
On 03/13/2012 09:41 AM, mjames@guesswho.com wrote:
Pls see attached new console.log. Thanks.
If you follow the directions at http://port389.org/wiki/FAQ#Troubleshooting to enable the Replication log level, the extra information will be in the directory server errors log, not the console log - /var/log/dirsrv/slapd-INST/errors
*
Mike
*
From: Rich Megginson [mailto:rmeggins@redhat.com]
Sent: Monday, March 12, 2012 3:14 PM
To: General discussion list for the 389 Directory server project.
Cc: Michael James
Subject: Re: [389-users] LDAP server is unwilling to perform
*
On 03/12/2012 12:39 PM, mjames@guesswho.com wrote:
Pls. see attached. Thx.
Hmm - nothing to go on there - please turn on the Replication log level and reproduce the problem - then the errors log may contain more clues
http://port389.org/wiki/FAQ#Troubleshooting
*
Mike
*
From: Rich Megginson [mailto:rmeggins@redhat.com]
Sent: Monday, March 12, 2012 1:30 PM
To: General discussion list for the 389 Directory server project.
Cc: Michael James
Subject: Re: [389-users] LDAP server is unwilling to perform
*
On 03/12/2012 11:30 AM, mjames@guesswho.com wrote:
Thanks for your previous help. I built a new server, CentOS 6.2, added the epel-389-ds-base and epel repos, then installed 389-ds via yum. I ran setup-ds-admin.pl with the “Typical” setup option, user nobody, and registered with one of our existing configuration servers. I created the supplier bind DN on the new server per the installation docs.
*
At this point, I can’t establish a replication agreement. I open the 389-console on existing server and use the GUI to create a new replication agreement on userRoot. I accepted the defaults, entered the correct bind DN and password. At the end of the wizard, it fails with “LDAP server is unwilling to perform”. In the error log, I see one error. Any help is appreciated. Thanks, Mike
Can you run the console with -D 9 -f console.log, reproduce the problem, remove any sensitive information from console.log, and post console.log to this list?
[13/Mar/2012:11:25:25 -0400] - slapd shutting down - signaling operation threads
[13/Mar/2012:11:25:25 -0400] - slapd shutting down - waiting for 27 threads to terminate
[13/Mar/2012:11:25:25 -0400] - slapd shutting down - closing down internal subsystems and plugins
[13/Mar/2012:11:25:25 -0400] NSMMReplicationPlugin - changelog program - _cl5TrimMain: exiting
[13/Mar/2012:11:25:25 -0400] NSMMReplicationPlugin - changelog program - _cl5DBClose: deleting DB object 98ec028
[13/Mar/2012:11:25:25 -0400] NSMMReplicationPlugin - changelog program - _cl5DBClose: closing databases in /etc/dirsrv/replication/changelogdb
[13/Mar/2012:11:25:25 -0400] NSMMReplicationPlugin - changelog program - _cl5DBCloseFile: Closing database /etc/dirsrv/replication/changelogdb/3f5b1504-1dd211b2-8eccc06e-e3450000_4e49489b000000010000.db4
[13/Mar/2012:11:25:25 -0400] NSMMReplicationPlugin - changelog program - _cl5DBCloseFile: Closed the changelog database handle for /etc/dirsrv/replication/changelogdb/3f5b1504-1dd211b2-8eccc06e-e3450000_4e49489b000000010000.db4 (rc: 0)
[13/Mar/2012:11:25:25 -0400] - Waiting for 4 database threads to stop
[13/Mar/2012:11:25:25 -0400] - All database threads now stopped
[13/Mar/2012:11:25:25 -0400] - replica_destroy
[13/Mar/2012:11:25:25 -0400] - slapd stopped.
[13/Mar/2012:11:26:25 -0400] - 389-Directory/1.2.9.9 B2011.244.2040 starting up
[13/Mar/2012:11:26:25 -0400] NSMMReplicationPlugin - changelog program - _cl5AppInit: fetched backend dbEnv (926d0b8)
[13/Mar/2012:11:26:25 -0400] NSMMReplicationPlugin - changelog program - _cl5NewDBFile: semaphore /etc/dirsrv/replication/changelogdb/3f5b1504-1dd211b2-8eccc06e-e3450000.sema
[13/Mar/2012:11:26:25 -0400] NSMMReplicationPlugin - changelog program - _cl5NewDBFile: maxConcurrentWrites=2
[13/Mar/2012:11:26:25 -0400] NSMMReplicationPlugin - changelog program - _cl5GetEntryCount: 335 changes for replica 3f5b1504-1dd211b2-8eccc06e-e3450000
[13/Mar/2012:11:26:25 -0400] NSMMReplicationPlugin - changelog program - _cl5AddDBFile: Added new DB object 93b3540
[13/Mar/2012:11:26:25 -0400] NSMMReplicationPlugin - changelog program - _cl5DBOpenFileByReplicaName: created new DB object 93b3540
[13/Mar/2012:11:26:25 -0400] NSMMReplicationPlugin - changelog program - _cl5DBOpen: opened 1 existing databases in /etc/dirsrv/replication/changelogdb
[13/Mar/2012:11:26:25 -0400] NSMMReplicationPlugin - Found replication agreement named "cn=389 to analog,cn=replica,cn=dc3DMYDOMAIN2C dc3Dcom,cn=mapping tree,cn=config".
[13/Mar/2012:11:26:25 -0400] NSMMReplicationPlugin - The replication agreement named "cn=389 to analog,cn=replica,cn=dc3DMYDOMAIN2C dc3Dcom,cn=mapping tree,cn=config" could not be correctly parsed. No replication will occur with this replica.
[13/Mar/2012:11:26:25 -0400] NSMMReplicationPlugin - agmtlist_config_init: found 0 replication agreements in DIT
[13/Mar/2012:11:26:25 -0400] NSMMReplicationPlugin - changelog program - _cl5GetDBFile: found DB object 93b3540 for database /etc/dirsrv/replication/changelogdb/3f5b1504-1dd211b2-8eccc06e-e3450000_4e49489b000000010000.db4
[13/Mar/2012:11:26:25 -0400] - _csngen_adjust_local_time: gen state before 4f5f17550001:1331631889:0:68
[13/Mar/2012:11:26:25 -0400] - _csngen_adjust_local_time: gen state after 4f5f67650000:1331652385:0:68
[13/Mar/2012:11:26:25 -0400] NSMMReplicationPlugin - ruv_add_csn_inprogress: successfully inserted csn 4f5f6765000000010000 into pending list
[13/Mar/2012:11:26:25 -0400] NSMMReplicationPlugin - Purged state information from entry o=NetscapeRoot up to CSN 4f55130d000100010000
[13/Mar/2012:11:26:25 -0400] NSMMReplicationPlugin - csn=4f5f6765000000010000 process postop: canceling operation csn
[13/Mar/2012:11:26:25 -0400] - slapd started. Listening on All Interfaces port 389 for LDAP requests
[13/Mar/2012:11:26:27 -0400] NSMMReplicationPlugin - changelog program - _cl5GetDBFile: found DB object 93b3540 for database /etc/dirsrv/replication/changelogdb/3f5b1504-1dd211b2-8eccc06e-e3450000_4e49489b000000010000.db4
[13/Mar/2012:11:26:27 -0400] NSMMReplicationPlugin - changelog program - cl5GetOperationCount: found DB object 93b3540
[13/Mar/2012:11:29:02 -0400] NSMMReplicationPlugin - changelog program - _cl5GetDBFile: found DB object 93b3540 for database /etc/dirsrv/replication/changelogdb/3f5b1504-1dd211b2-8eccc06e-e3450000_4e49489b000000010000.db4
[13/Mar/2012:11:29:02 -0400] NSMMReplicationPlugin - changelog program - cl5GetOperationCount: found DB object 93b3540
[13/Mar/2012:11:31:12 -0400] NSMMReplicationPlugin - agmt_add: begin
[13/Mar/2012:11:31:12 -0400] NSMMReplicationPlugin - agmtlist_add_callback: Can't start agreement "cn=389-01 to analog-01v,cn=replica,cn=dc3dMYDOMAIN2c dc3dcom,cn=mapping tree,cn=config"
[13/Mar/2012:11:31:20 -0400] - _csngen_adjust_local_time: gen state before 4f5f67650001:1331652385:0:68
[13/Mar/2012:11:31:20 -0400] - _csngen_adjust_local_time: gen state after 4f5f688c0000:1331652680:0:68
[13/Mar/2012:11:31:20 -0400] NSMMReplicationPlugin - ruv_add_csn_inprogress: successfully inserted csn 4f5f688c000000010000 into pending list
[13/Mar/2012:11:31:20 -0400] NSMMReplicationPlugin - Purged state information from entry cn=ResourcePage,ou=1.1,ou=Console,ou=cn3DDirectory Manager,ou=UserPreferences,ou=MYDOMAIN.com,o=Netsc apeRoot up to CSN 4f55130d000100010000
[13/Mar/2012:11:31:20 -0400] NSMMReplicationPlugin - changelog program - _cl5GetDBFileByReplicaName: found DB object 93b3540 for database /etc/dirsrv/replication/changelogdb/3f5b1504-1dd211b2-8eccc06e-e3450000_4e49489b000000010000.db4
[13/Mar/2012:11:31:20 -0400] NSMMReplicationPlugin - changelog program - _cl5GetDBFileByReplicaName: found DB object 93b3540 for database /etc/dirsrv/replication/changelogdb/3f5b1504-1dd211b2-8eccc06e-e3450000_4e49489b000000010000.db4
[13/Mar/2012:11:31:20 -0400] NSMMReplicationPlugin - ruv_update_ruv: successfully committed csn 4f5f688c000000010000
[13/Mar/2012:11:31:20 -0400] NSMMReplicationPlugin - ruv_add_csn_inprogress: successfully inserted csn 4f5f688c000100010000 into pending list
[13/Mar/2012:11:31:20 -0400] NSMMReplicationPlugin - Purged state information from entry cn=ResourcePage,ou=1.1,ou=Console,ou=cn3DDirectory Manager,ou=UserPreferences,ou=MYDOMAIN.com,o=Netsc apeRoot up to CSN 4f562e0c000000010000
[13/Mar/2012:11:31:20 -0400] NSMMReplicationPlugin - changelog program - _cl5GetDBFileByReplicaName: found DB object 93b3540 for database /etc/dirsrv/replication/changelogdb/3f5b1504-1dd211b2-8eccc06e-e3450000_4e49489b000000010000.db4
[13/Mar/2012:11:31:20 -0400] NSMMReplicationPlugin - changelog program - _cl5GetDBFileByReplicaName: found DB object 93b3540 for database /etc/dirsrv/replication/changelogdb/3f5b1504-1dd211b2-8eccc06e-e3450000_4e49489b000000010000.db4
[13/Mar/2012:11:31:20 -0400] NSMMReplicationPlugin - ruv_update_ruv: successfully committed csn 4f5f688c000100010000
[13/Mar/2012:11:31:20 -0400] NSMMReplicationPlugin - ruv_add_csn_inprogress: successfully inserted csn 4f5f688c000200010000 into pending list
[13/Mar/2012:11:31:20 -0400] NSMMReplicationPlugin - Purged state information from entry cn=General,ou=1.1,ou=Console,ou=cn3DDirectory Manager,ou=UserPreferences,ou=MYDOMAIN.com,o=Netsc apeRoot up to CSN 4f562e0c000100010000
[13/Mar/2012:11:31:20 -0400] NSMMReplicationPlugin - changelog program - _cl5GetDBFileByReplicaName: found DB object 93b3540 for database /etc/dirsrv/replication/changelogdb/3f5b1504-1dd211b2-8eccc06e-e3450000_4e49489b000000010000.db4
[13/Mar/2012:11:31:20 -0400] NSMMReplicationPlugin - changelog program - _cl5GetDBFileByReplicaName: found DB object 93b3540 for database /etc/dirsrv/replication/changelogdb/3f5b1504-1dd211b2-8eccc06e-e3450000_4e49489b000000010000.db4
[13/Mar/2012:11:31:20 -0400] NSMMReplicationPlugin - ruv_update_ruv: successfully committed csn 4f5f688c000200010000
[13/Mar/2012:11:31:20 -0400] NSMMReplicationPlugin - ruv_add_csn_inprogress: successfully inserted csn 4f5f688c000300010000 into pending list
[13/Mar/2012:11:31:20 -0400] NSMMReplicationPlugin - Purged state information from entry cn=General,ou=1.1,ou=Console,ou=cn3DDirectory Manager,ou=UserPreferences,ou=MYDOMAIN.com,o=Netsc apeRoot up to CSN 4f562e0c000200010000
[13/Mar/2012:11:31:20 -0400] NSMMReplicationPlugin - changelog program - _cl5GetDBFileByReplicaName: found DB object 93b3540 for database /etc/dirsrv/replication/changelogdb/3f5b1504-1dd211b2-8eccc06e-e3450000_4e49489b000000010000.db4
[13/Mar/2012:11:31:20 -0400] NSMMReplicationPlugin - changelog program - _cl5GetDBFileByReplicaName: found DB object 93b3540 for database /etc/dirsrv/replication/changelogdb/3f5b1504-1dd211b2-8eccc06e-e3450000_4e49489b000000010000.db4
[13/Mar/2012:11:31:20 -0400] NSMMReplicationPlugin - ruv_update_ruv: successfully committed csn 4f5f688c000300010000
[13/Mar/2012:11:31:22 -0400] - _csngen_adjust_local_time: gen state before 4f5f688c0004:1331652680:0:68
[13/Mar/2012:11:31:22 -0400] - _csngen_adjust_local_time: gen state after 4f5f688e0000:1331652682:0:68
[13/Mar/2012:11:31:22 -0400] NSMMReplicationPlugin - ruv_add_csn_inprogress: successfully inserted csn 4f5f688e000000010000 into pending list
[13/Mar/2012:11:31:22 -0400] NSMMReplicationPlugin - Purged state information from entry cn=General,ou=1.1,ou=Console,ou=cn3DDirectory Manager,ou=UserPreferences,ou=MYDOMAIN.com,o=Netsc apeRoot up to CSN 4f562e0c000300010000
[13/Mar/2012:11:31:22 -0400] NSMMReplicationPlugin - ruv_add_csn_inprogress: successfully inserted csn 4f5f688e000100010000 into pending list
[13/Mar/2012:11:31:22 -0400] NSMMReplicationPlugin - changelog program - _cl5GetDBFileByReplicaName: found DB object 93b3540 for database /etc/dirsrv/replication/changelogdb/3f5b1504-1dd211b2-8eccc06e-e3450000_4e49489b000000010000.db4
[13/Mar/2012:11:31:22 -0400] NSMMReplicationPlugin - Purged state information from entry cn=General,ou=1.1,ou=Console,ou=cn3DDirectory Manager,ou=UserPreferences,ou=MYDOMAIN.com,o=Netsc apeRoot up to CSN 4f562e0c000300010000
[13/Mar/2012:11:31:22 -0400] NSMMReplicationPlugin - changelog program - _cl5GetDBFileByReplicaName: found DB object 93b3540 for database /etc/dirsrv/replication/changelogdb/3f5b1504-1dd211b2-8eccc06e-e3450000_4e49489b000000010000.db4
[13/Mar/2012:11:31:22 -0400] NSMMReplicationPlugin - ruv_update_ruv: successfully committed csn 4f5f688e000000010000
[13/Mar/2012:11:31:22 -0400] NSMMReplicationPlugin - changelog program - _cl5GetDBFileByReplicaName: found DB object 93b3540 for database /etc/dirsrv/replication/changelogdb/3f5b1504-1dd211b2-8eccc06e-e3450000_4e49489b000000010000.db4
[13/Mar/2012:11:31:22 -0400] NSMMReplicationPlugin - changelog program - _cl5GetDBFileByReplicaName: found DB object 93b3540 for database /etc/dirsrv/replication/changelogdb/3f5b1504-1dd211b2-8eccc06e-e3450000_4e49489b000000010000.db4
[13/Mar/2012:11:31:22 -0400] NSMMReplicationPlugin - ruv_update_ruv: successfully committed csn 4f5f688e000100010000
[13/Mar/2012:11:31:27 -0400] NSMMReplicationPlugin - changelog program - _cl5GetDBFile: found DB object 93b3540 for database /etc/dirsrv/replication/changelogdb/3f5b1504-1dd211b2-8eccc06e-e3450000_4e49489b000000010000.db4
[13/Mar/2012:11:31:27 -0400] NSMMReplicationPlugin - changelog program - cl5GetOperationCount: found DB object 93b3540
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
03-13-2012, 03:24 PM
Rich Megginson
LDAP server is unwilling to perform
On 03/13/2012 10:23 AM, mjames@guesswho.com wrote:
Sorry,
forgot to send this to the list.
There appears to be something wrong with your replication agreement
entry, but I have no idea what.* That information should be in the
logs but it is not.* Can you post your replication agreement entry
to the list?
Subject: RE: [389-users] LDAP server is unwilling
to perform
*
That’s a big *IF*
there… I did turn up the logging. Attached is the error log,
trimmed to around the time that I tried to create the new
replication agreement. Sorry about that.
*
From:
Rich Megginson [mailto:rmeggins@redhat.com]
Sent: Tuesday, March 13, 2012 11:51 AM
To: General discussion list for the 389 Directory
server project.
Cc: Michael James
Subject: Re: [389-users] LDAP server is unwilling
to perform
*
On 03/13/2012 09:41 AM, mjames@guesswho.com
wrote:
Pls see
attached new console.log. Thanks.
If you follow the directions
at http://port389.org/wiki/FAQ#Troubleshooting
to enable the Replication log level, the extra information
will be in the directory server errors log, not the console
log - /var/log/dirsrv/slapd-INST/errors
*
Mike
*
From:
Rich Megginson [mailto:rmeggins@redhat.com]
Sent: Monday, March 12, 2012 3:14 PM
To: General discussion list for the 389 Directory
server project.
Cc: Michael James
Subject: Re: [389-users] LDAP server is unwilling
to perform
*
On 03/12/2012 12:39 PM, mjames@guesswho.com
wrote:
Pls. see
attached. Thx.
Hmm - nothing to go on there
- please turn on the Replication log level and reproduce the
problem - then the errors log may contain more clues
http://port389.org/wiki/FAQ#Troubleshooting
*
Mike
*
From:
Rich Megginson [mailto:rmeggins@redhat.com]
Sent: Monday, March 12, 2012 1:30 PM
To: General discussion list for the 389 Directory
server project.
Cc: Michael James
Subject: Re: [389-users] LDAP server is unwilling
to perform
*
On 03/12/2012 11:30 AM, mjames@guesswho.com
wrote:
Thanks for your previous help. I built a
new server, CentOS 6.2, added the epel-389-ds-base and epel
repos, then installed 389-ds via yum. I ran setup-ds-admin.pl
with the “Typical” setup option, user nobody, and registered
with one of our existing configuration servers. I created the
supplier bind DN on the new server per the installation docs.
*
At this point, I can’t establish a
replication agreement. I open the 389-console on existing
server and use the GUI to create a new replication agreement
on userRoot. I accepted the defaults, entered the correct bind
DN and password. At the end of the wizard, it fails with “LDAP
server is unwilling to perform”. In the error log, I see one
error. Any help is appreciated. Thanks, Mike
Can you run the console with -D 9
-f console.log, reproduce the problem, remove any sensitive
information from console.log, and post console.log to this
list?
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
*
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
*
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
03-13-2012, 03:42 PM
LDAP server is unwilling to perform
Looks like this:
*
[root@x-web-389-01 ~]# ldapsearch -xLLL -D "cn=directory manager" -W -b cn=config "cn=389 to analog"********************* ************************* ************************* *********************
Enter LDAP Password:
dn: cn=389 to analog,cn=replica,cn=dc3DMYDOMAIN2C dc3Dcom,cn=mapping tree,cn=config
objectClass: top
objectClass: nsDS5ReplicationAgreement
description: x-web-389-01 to x-analog-01
cn: 389 to analog
nsDS5ReplicaRoot: dc=MYDOMAIN,dc=com
nsDS5ReplicaHost: x-analog-01.MYDOMAIN.com
nsDS5ReplicaPort: 389
nsDS5ReplicaBindDN: cn=repman,cn=config
nsDS5ReplicaTransportInfo: LDAP
nsDS5ReplicaBindMethod: SIMPLE
nsDS5ReplicaCredentials: {DES}/DnkVyIX/let6epFs+gfjw==
nsds50ruv: {replicageneration} 4eb7e52b000000010000
nsds50ruv: {replica 2 ldap://x-analog-01.MYDOMAIN.com:389} 4ec1600f000000020000 4ec29e53000000020000
nsds50ruv: {replica 1 ldap://x-web-389-01.MYDOMAIN.com:389} 4ec116e4000000010000 4f329c1c000100010000
nsruvReplicaLastModified: {replica 2 ldap://x-analog-01.MYDOMAIN.com:389} 00000000
nsruvReplicaLastModified: {replica 1 ldap://x-web-389-01.MYDOMAIN.com:389} 00000000
nsds5replicareapactive: 0
nsds5replicaLastUpdateStart: 0
nsds5replicaLastUpdateEnd: 0
nsds5replicaChangesSentSinceStartup:
nsds5replicaLastUpdateStatus: 0 No replication sessions started since server startup
nsds5replicaUpdateInProgress: FALSE
nsds5replicaLastInitStart: 0
nsds5replicaLastInitEnd: 0
*
*
*
From: Rich Megginson [mailto:rmeggins@redhat.com]
Sent: Tuesday, March 13, 2012 12:24 PM
To: General discussion list for the 389 Directory server project.
Cc: Michael James
Subject: Re: [389-users] LDAP server is unwilling to perform
*
On 03/13/2012 10:23 AM, mjames@guesswho.com wrote:
Sorry, forgot to send this to the list.
There appears to be something wrong with your replication agreement entry, but I have no idea what.* That information should be in the logs but it is not.* Can you post your replication agreement entry to the list?
*
From: Michael James
Sent: Tuesday, March 13, 2012 12:13 PM
To: 'Rich Megginson'
Subject: RE: [389-users] LDAP server is unwilling to perform
*
That’s a big *IF* there… I did turn up the logging. Attached is the error log, trimmed to around the time that I tried to create the new replication agreement. Sorry about that.
*
From: Rich Megginson [mailto:rmeggins@redhat.com]
Sent: Tuesday, March 13, 2012 11:51 AM
To: General discussion list for the 389 Directory server project.
Cc: Michael James
Subject: Re: [389-users] LDAP server is unwilling to perform
*
On 03/13/2012 09:41 AM, mjames@guesswho.com wrote:
Pls see attached new console.log. Thanks.
If you follow the directions at http://port389.org/wiki/FAQ#Troubleshooting to enable the Replication log level, the extra information will be in the directory server errors log, not the console log - /var/log/dirsrv/slapd-INST/errors
*
Mike
*
From: Rich Megginson [mailto:rmeggins@redhat.com]
Sent: Monday, March 12, 2012 3:14 PM
To: General discussion list for the 389 Directory server project.
Cc: Michael James
Subject: Re: [389-users] LDAP server is unwilling to perform
*
On 03/12/2012 12:39 PM, mjames@guesswho.com wrote:
Pls. see attached. Thx.
Hmm - nothing to go on there - please turn on the Replication log level and reproduce the problem - then the errors log may contain more clues
http://port389.org/wiki/FAQ#Troubleshooting
*
Mike
*
From: Rich Megginson [mailto:rmeggins@redhat.com]
Sent: Monday, March 12, 2012 1:30 PM
To: General discussion list for the 389 Directory server project.
Cc: Michael James
Subject: Re: [389-users] LDAP server is unwilling to perform
*
On 03/12/2012 11:30 AM, mjames@guesswho.com wrote:
Thanks for your previous help. I built a new server, CentOS 6.2, added the epel-389-ds-base and epel repos, then installed 389-ds via yum. I ran setup-ds-admin.pl with the “Typical” setup option, user nobody, and registered with one of our existing configuration servers. I created the supplier bind DN on the new server per the installation docs.
*
At this point, I can’t establish a replication agreement. I open the 389-console on existing server and use the GUI to create a new replication agreement on userRoot. I accepted the defaults, entered the correct bind DN and password. At the end of the wizard, it fails with “LDAP server is unwilling to perform”. In the error log, I see one error. Any help is appreciated. Thanks, Mike
Can you run the console with -D 9 -f console.log, reproduce the problem, remove any sensitive information from console.log, and post console.log to this list?
Could you try removing the white space (by editing your dse.ldif)?
1. shutdown the server
2. edit /etc/dirsrv/slapd-YOURID/dse.ldif
dn: cn=389 to analog,cn=replica,cn=dc3DMYDOMAIN2C dc3Dcom,cn=mapping tree,cn=config
==>
dn: cn=389 to analog,cn=replica,cn=dc3DMYDOMAIN2Cdc3Dcom,cn=mapp ing tree,cn=config
3. restart the server
nsds5replicaLastUpdateStatus:
0 No replication sessions started since server startup
nsds5replicaUpdateInProgress:
FALSE
nsds5replicaLastInitStart:
0
nsds5replicaLastInitEnd:
0
*
*
*
From:
Rich Megginson [mailto:rmeggins@redhat.com]
Sent: Tuesday, March 13, 2012 12:24 PM
To: General discussion list for the 389 Directory
server project.
Cc: Michael James
Subject: Re: [389-users] LDAP server is unwilling
to perform
*
On 03/13/2012 10:23 AM, mjames@guesswho.com
wrote:
Sorry, forgot
to send this to the list.
There appears to be something
wrong with your replication agreement entry, but I have no
idea what.* That information should be in the logs but it is
not.* Can you post your replication agreement entry to the
list?
Subject: RE: [389-users] LDAP server is unwilling
to perform
*
That’s a big *IF*
there… I did turn up the logging. Attached is the error log,
trimmed to around the time that I tried to create the new
replication agreement. Sorry about that.
*
From:
Rich Megginson [mailto:rmeggins@redhat.com]
Sent: Tuesday, March 13, 2012 11:51 AM
To: General discussion list for the 389 Directory
server project.
Cc: Michael James
Subject: Re: [389-users] LDAP server is unwilling
to perform
*
On 03/13/2012 09:41 AM, mjames@guesswho.com
wrote:
Pls see
attached new console.log. Thanks.
If you follow the directions
at http://port389.org/wiki/FAQ#Troubleshooting
to enable the Replication log level, the extra information
will be in the directory server errors log, not the console
log - /var/log/dirsrv/slapd-INST/errors
*
Mike
*
From:
Rich Megginson [mailto:rmeggins@redhat.com]
Sent: Monday, March 12, 2012 3:14 PM
To: General discussion list for the 389 Directory
server project.
Cc: Michael James
Subject: Re: [389-users] LDAP server is unwilling
to perform
*
On 03/12/2012 12:39 PM, mjames@guesswho.com
wrote:
Pls. see
attached. Thx.
Hmm - nothing to go on there -
please turn on the Replication log level and reproduce the
problem - then the errors log may contain more clues
http://port389.org/wiki/FAQ#Troubleshooting
*
Mike
*
From:
Rich Megginson [mailto:rmeggins@redhat.com]
Sent: Monday, March 12, 2012 1:30 PM
To: General discussion list for the 389 Directory
server project.
Cc: Michael James
Subject: Re: [389-users] LDAP server is unwilling
to perform
*
On 03/12/2012 11:30 AM, mjames@guesswho.com
wrote:
Thanks for your previous help. I built a
new server, CentOS 6.2, added the epel-389-ds-base and epel
repos, then installed 389-ds via yum. I ran setup-ds-admin.pl
with the “Typical” setup option, user nobody, and registered
with one of our existing configuration servers. I created the
supplier bind DN on the new server per the installation docs.
*
At this point, I can’t establish a
replication agreement. I open the 389-console on existing
server and use the GUI to create a new replication agreement
on userRoot. I accepted the defaults, entered the correct bind
DN and password. At the end of the wizard, it fails with “LDAP
server is unwilling to perform”. In the error log, I see one
error. Any help is appreciated. Thanks, Mike
Can you run the console with -D 9
-f console.log, reproduce the problem, remove any sensitive
information from console.log, and post console.log to this
list?
LDAP server is unwilling to perform
