Fedora directory users - Jun 2005 - replication: edit agreements, and tls?

Hi all, 

Two quick questions on managing replication via the console: 

1. I want to edit an existing replication agreement by clicking on the 
agreement, going to the connection tab, and enabling SSL. However, even 
though I''m logged in as admin, those options are all greyed out. Am I
forced
to create a whole new agreement just to make this change? 

2. If I create a replication agreement and specify my consumer''s port
as
"389", but enable SSL, will it use TLS, or will things just fail
because it
tries to connect to 389 without a start_tls call? Must I choose port 636 to 
do replication over SSL? 

Thanks,
brian.

Brian K. Jones wrote:
>Hi all, 
>
>Two quick questions on managing replication via the console: 
>
>1. I want to edit an existing replication agreement by clicking on the 
>agreement, going to the connection tab, and enabling SSL. However, even 
>though I''m logged in as admin, those options are all greyed out. Am
I forced
>to create a whole new agreement just to make this change? 
>  
>
Once created, you won''t be able to change connection method of a 
replication agreement in console.  However, you can right click on the 
existing agreement and use the duplicate option.
>2. If I create a replication agreement and specify my consumer''s
port as
>"389", but enable SSL, will it use TLS, or will things just fail
because it
>tries to connect to 389 without a start_tls call? Must I choose port 636 to 
>do replication over SSL? 
>  
>
It will not work unless 389 is your consumer''s SSL port. 
You''ll need to
specify the SSL port of your consumer in the replication agreement in 
order to replicate over SSL.

Regards,
--
toto
>Thanks,
>brian.
>
>--
>Fedora-directory-users mailing list
>Fedora-directory-users@redhat.com
>https://www.redhat.com/mailman/listinfo/fedora-directory-users
>  
>

Brian K. Jones wrote:
>Hi all, 
>
>Two quick questions on managing replication via the console: 
>
>1. I want to edit an existing replication agreement by clicking on the 
>agreement, going to the connection tab, and enabling SSL. However, even 
>though I''m logged in as admin, those options are all greyed out. Am
I forced
>to create a whole new agreement just to make this change?
>  
>
Was your server enabled to use SSL?  If so, could be a bug.  Try using 
startconsole -D > log 2>&1 - send the log file to this list.
>2. If I create a replication agreement and specify my consumer''s
port as
>"389", but enable SSL, will it use TLS, or will things just fail
because it
>tries to connect to 389 without a start_tls call? Must I choose port 636 to 
>do replication over SSL? 
>  
>
I don''t think replication will work with startTLS.  That would be a
nice
enhancement.
>Thanks,
>brian.
>
>--
>Fedora-directory-users mailing list
>Fedora-directory-users@redhat.com
>https://www.redhat.com/mailman/listinfo/fedora-directory-users
>  
>

Rich Megginson wrote:
> Brian K. Jones wrote:
>
>> Hi all,
>> Two quick questions on managing replication via the console:
>> 1. I want to edit an existing replication agreement by clicking on
>> the agreement, going to the connection tab, and enabling SSL.
>> However, even though I''m logged in as admin, those options are
all
>> greyed out. Am I forced to create a whole new agreement just to make
>> this change?
>>  
>>
> Was your server enabled to use SSL?  If so, could be a bug.  Try using
> startconsole -D > log 2>&1 - send the log file to this list.
The graying-out in this case was an enhancement to avoid giving false
hope to admins.

A limitation on the server side is that a replication agreement''s
target
host, port and connection type can''t be modified while the server is
running - DSA unwilling to perform.  It has to be recreated or possibly
edited in offline mode.  Maybe this could use some enhancement (followed
by Console unenhancement), but I''d rank replication StartTLS support
higher on the nice-to-have list.

>A limitation on the server side is that a replication agreement''s
target
>host, port and connection type can''t be modified while the server
is
>running - DSA unwilling to perform.  It has to be recreated or possibly
>edited in offline mode.  Maybe this could use some enhancement (followed
>by Console unenhancement), but I''d rank replication StartTLS
support
>higher on the nice-to-have list.
>  
>
Changing the connection properties while the server is up is likely
to take a long time to completely debug. That''s because the replication
connection
management state machine code is rather complicated and hard to modify.

However, adding support for start tls is quite easy.

If you feel like it you can always take the server down and
edit the replication agreement directly. But hey, replication
agreements are created approximately never (like a few times
when you''re figuring out how the thing works, then once or
twice when you deploy). So making the process silky-smooth
for some even yet more uncommon corner case like
changing from non-ssl to ssl seems like not a great use
of limited programming and testing time (IMHO).

David Boreham wrote:
>
>> A limitation on the server side is that a replication
agreement''s target
>> host, port and connection type can''t be modified while the
server is
>> running - DSA unwilling to perform.  It has to be recreated or possibly
>> edited in offline mode.  Maybe this could use some enhancement
(followed
>> by Console unenhancement), but I''d rank replication StartTLS
support
>> higher on the nice-to-have list.
>>  
>>
> Changing the connection properties while the server is up is likely
> to take a long time to completely debug. That''s because the
> replication connection
> management state machine code is rather complicated and hard to modify.
>
> However, adding support for start tls is quite easy.
>
> If you feel like it you can always take the server down and
> edit the replication agreement directly. But hey, replication
> agreements are created approximately never (like a few times
> when you''re figuring out how the thing works, then once or
> twice when you deploy). So making the process silky-smooth
> for some even yet more uncommon corner case like
> changing from non-ssl to ssl seems like not a great use
> of limited programming and testing time (IMHO).
Oh yeah, I didn''t mean to suggest it would be the best investment of
time and effort.  It was looked at a couple of years ago with the same
as your conclusion, that''s why I grayed-out the fields in the Console
instead.
But it''s not as rare as one would think that replication agreement
properties need changing, it happens in some large deployments in
failovers and such.  But in that case it wouldn''t make sense to perform
it via the Console anyway, it''s done by script, and then it''s
nearly as
simple to just replace the replication agreement as Brian first suggested.