On 10/23/2015 04:57 PM, Simo Sorce wrote:
On 23/10/15 08:39, Petr Vobornik wrote:
not sure if the change in2606f5aecd6ac0db31abb515b691529bb7eaf14e was a
mistake or done on purpose.
- realm, hostname, dirman_passwd, port, starttls=True)
+ realm, hostname, dirman_passwd, port)
which causes, e.g.:
ipa-csreplica-manage -p Secret123 list ipa.example.com
cannot connect to 'ldaps://ipa.example.com:389': TLS error
-5938:Encountered end of file
Attached patch reverts it.
I am not sure it was a mistake, we have changed replication from using
TLS to always use LDAP+GSSAPI, so why is ipa-csreplica-manage depending
on ldaps anyway ?
It may need to when dealing with very old domains where we have split
instances for CS and IPA, but not in anything modern. I would rather
change the command to cope with using LDAP+GSSAPI.
A simple revert may break something in replica promotion, would need to
be tested with a full master+replica install.
I had this patch applied in branch while developing Topology graph -
promotion of several replicas worked. Replica promotion uses new
CAReplicationManager - not CSReplicationManager so it shouldn't be
affected. CSReplicationManager is used only in
get_cs_replication_manager call. This call is used only in
ipa-csreplica-manage and ipa_restore.py.
Without this patch the related functionality in both
ipa-csreplica-manage and ipa_restore.py (see
https://fedorahosted.org/freeipa/ticket/5479#comment:2 ) doesn't work.
I don't think that changing ipa-csreplica-manage is worth the effort
given that we want to deprecate the tool.
Therefore I propose to go with this patch.
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code