Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
I am not sure if I am using repl-monitor.pl in a wrong way. But from my understanding, either we use it simplest as possible like this:
repl-monitor.pl -s -c ipanew:389 -w secret12
and the current instance in 389 port has a replication agreement like this:
dn: cn=torhel6,cn=replica,cn=dc\3Dmyexample\2Cdc\3Dcom,cn=mapping tree,cn=config
objectClass: top
objectClass: nsDS5ReplicationAgreement
cn: torhel6
nsDS5ReplicaHost: ipaclient.example.com
nsDS5ReplicaRoot: dc=myexample,dc=com
nsDS5ReplicaPort: 636
nsDS5ReplicaTransportInfo: SSL
nsDS5ReplicaBindDN: cn=replication manager,cn=config
nsDS5ReplicaBindMethod: SIMPLE
nsDS5ReplicaCredentials: secret12
it seems the server "ipaclient.example.com:636" is added to the list of servers and in
sub get_replicas
{
....
....
$conn = new Mozilla::LDAP::Conn ($host, $shadowport, "$binddn", $bindpwd, $bindcert);
....
....
the connection is done with the right host and port but the bind cert is empty.
So, the connection hangs.
It seems to be the same if I use "-f file" with the connections to the server usingport 389 because it's still browsing the agreemnts (from what I have seen) and trying to use the host and port defined in the agreement.
Perhaps I am not using the script as expected ?
Please, feel free to close this bug if it's the case.
Version-Release number of selected component (if applicable):
389-ds-base-1.3.4.0-30.el7_2.x86_64
How reproducible:
it's shown in description.
Hi German,
you should pass cert file in the connection string like this:
-c "host:port:binddn:bindpwd:bindcert"
Or specify the same in the replication config file.
German this appears to work correctly for me:
repl-monitor.pl -c localhost.localdomain:636:cn=directory manager:password:/etc/dirsrv/slapd-localhost/ -s
Supplier: localhost.localdomain:636
-----------------------------------
Replica Root: dc=example,dc=com
Replica ID: 1
Max CSN: 58dabb25000000010000 (03/28/2017 15:36:05)
-
Consumer: localhost.localdomain:6360 ldap://localhost.localdomain:6360/
Type: consumer
Time Lag: 0:00:00
Supplier Max CSN: 58dabb25000000010000 (03/28/2017 15:36:05)
Consumer Max CSN: 58dabb25000000010000 (03/28/2017 15:36:05)
Last Modify Time: 3/28/2017 15:36:05
Supplier: localhost.localdomain:636
Sent/Skipped: 5 / 0
Update Status: Error (0) Replica acquired successfully: Incremental update succeeded
Update Started: 03/28/2017 15:36:05
Update Ended: 03/28/2017 15:36:05
Schedule: always in sync
SSL: n
You do have to set the cert dir and secure port in the connection details because it is using SSL in the agreement.
On a side note - I did find a problem with the output not detecting that SSL is being used.
Back to the original issue... Does the example above work for you? Or is there a different scenario I should try?
Hi Mark,
thanks. Let's close this bug.
In fact, if we have several repl. agreements and one of them under ssl and not the others, for instance, and in the connection details we decide to use clear port, this could fail.
But if we use the secure port will not, as you have shown.
Thanks. Let's close it.
Description of problem: I am not sure if I am using repl-monitor.pl in a wrong way. But from my understanding, either we use it simplest as possible like this: repl-monitor.pl -s -c ipanew:389 -w secret12 and the current instance in 389 port has a replication agreement like this: dn: cn=torhel6,cn=replica,cn=dc\3Dmyexample\2Cdc\3Dcom,cn=mapping tree,cn=config objectClass: top objectClass: nsDS5ReplicationAgreement cn: torhel6 nsDS5ReplicaHost: ipaclient.example.com nsDS5ReplicaRoot: dc=myexample,dc=com nsDS5ReplicaPort: 636 nsDS5ReplicaTransportInfo: SSL nsDS5ReplicaBindDN: cn=replication manager,cn=config nsDS5ReplicaBindMethod: SIMPLE nsDS5ReplicaCredentials: secret12 it seems the server "ipaclient.example.com:636" is added to the list of servers and in sub get_replicas { .... .... $conn = new Mozilla::LDAP::Conn ($host, $shadowport, "$binddn", $bindpwd, $bindcert); .... .... the connection is done with the right host and port but the bind cert is empty. So, the connection hangs. It seems to be the same if I use "-f file" with the connections to the server usingport 389 because it's still browsing the agreemnts (from what I have seen) and trying to use the host and port defined in the agreement. Perhaps I am not using the script as expected ? Please, feel free to close this bug if it's the case. Version-Release number of selected component (if applicable): 389-ds-base-1.3.4.0-30.el7_2.x86_64 How reproducible: it's shown in description.