Re: [Freeipa-devel] [PATCH] 825 add dogtag replication management
Jan Cholasta wrote:
On 15.7.2011 21:24, Rob Crittenden wrote:
Rich Megginson wrote:
On 07/15/2011 10:57 AM, Rob Crittenden wrote:
Rich Megginson wrote:
On 07/15/2011 08:01 AM, Rob Crittenden wrote:
Martin Kosek wrote:
On Fri, 2011-07-15 at 14:43 +0200, Jan Cholasta wrote:
On 15.7.2011 05:42, Rob Crittenden wrote:
Add a separate tool for now to do dogtag replication agreement
management. The syntax is the same for IPA agreements with the
exception
that the DM password is always required and it isn't possible to
delegate the management of this.
ticket https://fedorahosted.org/freeipa/ticket/1250
rob
NACK
'ipa-csreplica-manage list server' doesn't list the peers of the
specified server, but the peers of localhost.
Connecting already connected pair of replicas duplicates the
replication
information ('ipa-csreplica-manage list server' shows the same
hostname
twice).
There is trailing whitespace on line 87 of the patch.
BTW I don't understand why is it possible (or necessary?) to be
able to
have CS replication topology that is different from the main IPA
replication topology (ipa-csreplica-manage allows you to do
that). Is
there a reason for this?
Honza
And some issues from me:
1) Unhelpful error message when force-syncing from a master
without a
replication agreement:
# ipa-csreplica-manage force-sync --from=HOST
Directory Manager password:
ipa: ERROR: Unable to find replication agreement for
vm-060.idm.lab.bos.redhat.com
unexpected error: Unable to proceed
2) Minor stuff in man page:
Unindented Exit statuses:
EXIT STATUS
0 if the command was successful
1 if an error occurred
Missing dot: The default is the machine on which the command is run
Not
honoured by the re-initialize command.
Otherwise it looks good.
Martin
This should address all the issues raised.
The reason for different topology has several reasons:
1. A given IPA server may not have a CA installed
2. Some aspects of ipa-replica-manage can be delegated. We can't
delegate CS replica management because it is in a different directory
server. We don't have users stored there so can't map the GSSAPI
credentials. So only Directory Manager can operate on it for now.
3. Flexibility. You may want way more connections for users than for
the CA.
+ if starttls:
+ self.conn = ipaldap.IPAdmin(hostname, port=port)
+ ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, CACERT)
Why in the starttls case do you not call ipaldap.IPAdmin(hostname,
port=PORT, cacert=CACERT) ?
Because the port is the non-secure port and opening an SSL connection
to it failed.
Ah, ok. So that tells IPAdmin to use this CACERT and to use ldaps.
+ managers = entry.getValues('nsDS5ReplicaBindDN')
+ if replica_binddn not in managers:
You might want to use the dn.py code, or at least normalize the DNs in
managers before comparing
That's a good idea.
+ if master is None:
+ entry.setValues('nsds5replicaupdateschedule', '-2359
0123456')
You should just omit nsds5replicaupdateschedule
It failed with an operations erorr when I tried removing the attribute
either directly with a MOD_DELETE or doing a MOD_REPLACE with nothing.
I assume this is another attribute in cn=config that once set cannot
be undone.
Right. Ok. When you add the agreement entry, you can just omit it. But
if you are trying to modify an existing agreement entry, you can't
MOD_DELETE it or MOD_REPLACE with an empty value.
Ok, good point about normalizing, updated patch attached.
rob
Everything I found is fixed. You might want to take a look at what
Martin found, though.
Honza
Updated patch to use the DN class a bit more.
rob
From 19eb76779357277b059875803b4fb76791393b02 Mon Sep 17 00:00:00 2001
From: Rob Crittenden rcrit...@redhat.com
Date: Thu, 14 Jul 2011 23:35:01 -0400
Subject: [PATCH] Create tool to manage dogtag replication agreements
For the most part the existing replication code worked with the
following exceptions:
- Added more port options
- It assumed that initial connections were done to an SSL port. Added
ability to use startTLS
- It assumed that the name of the agreement was the same on both sides.
In dogtag one is marked as master and one as clone. A new option is
added, master, the determines which side we're working on or None
if it isn't a dogtag agreement.
- Don't set the attribute exclude list on dogtag agreements
- dogtag doesn't set a schedule by default (which is actually recommended
by 389-ds). This causes problems when doing a force-sync though so
if one is done we set a schedule to run all the time. Otherwise the
temporary schedule can't be removed (LDAP operations error).
https://fedorahosted.org/freeipa/ticket/1250
---
freeipa.spec.in |7 +-
install/tools/Makefile.am|1 +
install/tools/ipa-csreplica-manage | 452 ++
install/tools/man/Makefile.am|1 +
install/tools/man/ipa-csreplica-manage.1 | 93 ++
Re: [Freeipa-devel] [PATCH] 825 add dogtag replication management
On 07/18/2011 09:34 AM, Rob Crittenden wrote:
Jan Cholasta wrote:
On 15.7.2011 21:24, Rob Crittenden wrote:
Rich Megginson wrote:
On 07/15/2011 10:57 AM, Rob Crittenden wrote:
Rich Megginson wrote:
On 07/15/2011 08:01 AM, Rob Crittenden wrote:
Martin Kosek wrote:
On Fri, 2011-07-15 at 14:43 +0200, Jan Cholasta wrote:
On 15.7.2011 05:42, Rob Crittenden wrote:
Add a separate tool for now to do dogtag replication agreement
management. The syntax is the same for IPA agreements with the
exception
that the DM password is always required and it isn't possible to
delegate the management of this.
ticket https://fedorahosted.org/freeipa/ticket/1250
rob
NACK
'ipa-csreplica-manage list server' doesn't list the peers of the
specified server, but the peers of localhost.
Connecting already connected pair of replicas duplicates the
replication
information ('ipa-csreplica-manage list server' shows the same
hostname
twice).
There is trailing whitespace on line 87 of the patch.
BTW I don't understand why is it possible (or necessary?) to be
able to
have CS replication topology that is different from the main IPA
replication topology (ipa-csreplica-manage allows you to do
that). Is
there a reason for this?
Honza
And some issues from me:
1) Unhelpful error message when force-syncing from a master
without a
replication agreement:
# ipa-csreplica-manage force-sync --from=HOST
Directory Manager password:
ipa: ERROR: Unable to find replication agreement for
vm-060.idm.lab.bos.redhat.com
unexpected error: Unable to proceed
2) Minor stuff in man page:
Unindented Exit statuses:
EXIT STATUS
0 if the command was successful
1 if an error occurred
Missing dot: The default is the machine on which the command is
run
Not
honoured by the re-initialize command.
Otherwise it looks good.
Martin
This should address all the issues raised.
The reason for different topology has several reasons:
1. A given IPA server may not have a CA installed
2. Some aspects of ipa-replica-manage can be delegated. We can't
delegate CS replica management because it is in a different
directory
server. We don't have users stored there so can't map the GSSAPI
credentials. So only Directory Manager can operate on it for now.
3. Flexibility. You may want way more connections for users than
for
the CA.
+ if starttls:
+ self.conn = ipaldap.IPAdmin(hostname, port=port)
+ ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, CACERT)
Why in the starttls case do you not call ipaldap.IPAdmin(hostname,
port=PORT, cacert=CACERT) ?
Because the port is the non-secure port and opening an SSL connection
to it failed.
Ah, ok. So that tells IPAdmin to use this CACERT and to use ldaps.
+ managers = entry.getValues('nsDS5ReplicaBindDN')
+ if replica_binddn not in managers:
You might want to use the dn.py code, or at least normalize the
DNs in
managers before comparing
That's a good idea.
+ if master is None:
+ entry.setValues('nsds5replicaupdateschedule', '-2359
0123456')
You should just omit nsds5replicaupdateschedule
It failed with an operations erorr when I tried removing the
attribute
either directly with a MOD_DELETE or doing a MOD_REPLACE with
nothing.
I assume this is another attribute in cn=config that once set cannot
be undone.
Right. Ok. When you add the agreement entry, you can just omit it. But
if you are trying to modify an existing agreement entry, you can't
MOD_DELETE it or MOD_REPLACE with an empty value.
Ok, good point about normalizing, updated patch attached.
rob
Everything I found is fixed. You might want to take a look at what
Martin found, though.
Honza
Updated patch to use the DN class a bit more.
ack
rob
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 825 add dogtag replication management
Rich Megginson wrote:
On 07/18/2011 09:34 AM, Rob Crittenden wrote:
Jan Cholasta wrote:
On 15.7.2011 21:24, Rob Crittenden wrote:
Rich Megginson wrote:
On 07/15/2011 10:57 AM, Rob Crittenden wrote:
Rich Megginson wrote:
On 07/15/2011 08:01 AM, Rob Crittenden wrote:
Martin Kosek wrote:
On Fri, 2011-07-15 at 14:43 +0200, Jan Cholasta wrote:
On 15.7.2011 05:42, Rob Crittenden wrote:
Add a separate tool for now to do dogtag replication agreement
management. The syntax is the same for IPA agreements with the
exception
that the DM password is always required and it isn't possible to
delegate the management of this.
ticket https://fedorahosted.org/freeipa/ticket/1250
rob
NACK
'ipa-csreplica-manage list server' doesn't list the peers of the
specified server, but the peers of localhost.
Connecting already connected pair of replicas duplicates the
replication
information ('ipa-csreplica-manage list server' shows the same
hostname
twice).
There is trailing whitespace on line 87 of the patch.
BTW I don't understand why is it possible (or necessary?) to be
able to
have CS replication topology that is different from the main IPA
replication topology (ipa-csreplica-manage allows you to do
that). Is
there a reason for this?
Honza
And some issues from me:
1) Unhelpful error message when force-syncing from a master
without a
replication agreement:
# ipa-csreplica-manage force-sync --from=HOST
Directory Manager password:
ipa: ERROR: Unable to find replication agreement for
vm-060.idm.lab.bos.redhat.com
unexpected error: Unable to proceed
2) Minor stuff in man page:
Unindented Exit statuses:
EXIT STATUS
0 if the command was successful
1 if an error occurred
Missing dot: The default is the machine on which the command is
run
Not
honoured by the re-initialize command.
Otherwise it looks good.
Martin
This should address all the issues raised.
The reason for different topology has several reasons:
1. A given IPA server may not have a CA installed
2. Some aspects of ipa-replica-manage can be delegated. We can't
delegate CS replica management because it is in a different
directory
server. We don't have users stored there so can't map the GSSAPI
credentials. So only Directory Manager can operate on it for now.
3. Flexibility. You may want way more connections for users than
for
the CA.
+ if starttls:
+ self.conn = ipaldap.IPAdmin(hostname, port=port)
+ ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, CACERT)
Why in the starttls case do you not call ipaldap.IPAdmin(hostname,
port=PORT, cacert=CACERT) ?
Because the port is the non-secure port and opening an SSL connection
to it failed.
Ah, ok. So that tells IPAdmin to use this CACERT and to use ldaps.
+ managers = entry.getValues('nsDS5ReplicaBindDN')
+ if replica_binddn not in managers:
You might want to use the dn.py code, or at least normalize the
DNs in
managers before comparing
That's a good idea.
+ if master is None:
+ entry.setValues('nsds5replicaupdateschedule', '-2359
0123456')
You should just omit nsds5replicaupdateschedule
It failed with an operations erorr when I tried removing the
attribute
either directly with a MOD_DELETE or doing a MOD_REPLACE with
nothing.
I assume this is another attribute in cn=config that once set cannot
be undone.
Right. Ok. When you add the agreement entry, you can just omit it. But
if you are trying to modify an existing agreement entry, you can't
MOD_DELETE it or MOD_REPLACE with an empty value.
Ok, good point about normalizing, updated patch attached.
rob
Everything I found is fixed. You might want to take a look at what
Martin found, though.
Honza
Updated patch to use the DN class a bit more.
ack
rob
pushed to master and ipa-2-0
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 825 add dogtag replication management
On 15.7.2011 05:42, Rob Crittenden wrote:
Add a separate tool for now to do dogtag replication agreement
management. The syntax is the same for IPA agreements with the exception
that the DM password is always required and it isn't possible to
delegate the management of this.
ticket https://fedorahosted.org/freeipa/ticket/1250
rob
NACK
'ipa-csreplica-manage list server' doesn't list the peers of the
specified server, but the peers of localhost.
Connecting already connected pair of replicas duplicates the replication
information ('ipa-csreplica-manage list server' shows the same hostname
twice).
There is trailing whitespace on line 87 of the patch.
BTW I don't understand why is it possible (or necessary?) to be able to
have CS replication topology that is different from the main IPA
replication topology (ipa-csreplica-manage allows you to do that). Is
there a reason for this?
Honza
--
Jan Cholasta
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 825 add dogtag replication management
On Fri, 2011-07-15 at 14:43 +0200, Jan Cholasta wrote:
On 15.7.2011 05:42, Rob Crittenden wrote:
Add a separate tool for now to do dogtag replication agreement
management. The syntax is the same for IPA agreements with the exception
that the DM password is always required and it isn't possible to
delegate the management of this.
ticket https://fedorahosted.org/freeipa/ticket/1250
rob
NACK
'ipa-csreplica-manage list server' doesn't list the peers of the
specified server, but the peers of localhost.
Connecting already connected pair of replicas duplicates the replication
information ('ipa-csreplica-manage list server' shows the same hostname
twice).
There is trailing whitespace on line 87 of the patch.
BTW I don't understand why is it possible (or necessary?) to be able to
have CS replication topology that is different from the main IPA
replication topology (ipa-csreplica-manage allows you to do that). Is
there a reason for this?
Honza
And some issues from me:
1) Unhelpful error message when force-syncing from a master without a
replication agreement:
# ipa-csreplica-manage force-sync --from=HOST
Directory Manager password:
ipa: ERROR: Unable to find replication agreement for
vm-060.idm.lab.bos.redhat.com
unexpected error: Unable to proceed
2) Minor stuff in man page:
Unindented Exit statuses:
EXIT STATUS
0 if the command was successful
1 if an error occurred
Missing dot: The default is the machine on which the command is run Not
honoured by the re-initialize command.
Otherwise it looks good.
Martin
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 825 add dogtag replication management
Martin Kosek wrote:
On Fri, 2011-07-15 at 14:43 +0200, Jan Cholasta wrote:
On 15.7.2011 05:42, Rob Crittenden wrote:
Add a separate tool for now to do dogtag replication agreement
management. The syntax is the same for IPA agreements with the exception
that the DM password is always required and it isn't possible to
delegate the management of this.
ticket https://fedorahosted.org/freeipa/ticket/1250
rob
NACK
'ipa-csreplica-manage list server' doesn't list the peers of the
specified server, but the peers of localhost.
Connecting already connected pair of replicas duplicates the replication
information ('ipa-csreplica-manage list server' shows the same hostname
twice).
There is trailing whitespace on line 87 of the patch.
BTW I don't understand why is it possible (or necessary?) to be able to
have CS replication topology that is different from the main IPA
replication topology (ipa-csreplica-manage allows you to do that). Is
there a reason for this?
Honza
And some issues from me:
1) Unhelpful error message when force-syncing from a master without a
replication agreement:
# ipa-csreplica-manage force-sync --from=HOST
Directory Manager password:
ipa: ERROR: Unable to find replication agreement for
vm-060.idm.lab.bos.redhat.com
unexpected error: Unable to proceed
2) Minor stuff in man page:
Unindented Exit statuses:
EXIT STATUS
0 if the command was successful
1 if an error occurred
Missing dot: The default is the machine on which the command is run Not
honoured by the re-initialize command.
Otherwise it looks good.
Martin
This should address all the issues raised.
The reason for different topology has several reasons:
1. A given IPA server may not have a CA installed
2. Some aspects of ipa-replica-manage can be delegated. We can't
delegate CS replica management because it is in a different directory
server. We don't have users stored there so can't map the GSSAPI
credentials. So only Directory Manager can operate on it for now.
3. Flexibility. You may want way more connections for users than for the CA.
rob
From ab416ad4e7bc6e73fda59f86551d2d54a1534511 Mon Sep 17 00:00:00 2001
From: Rob Crittenden rcrit...@redhat.com
Date: Thu, 14 Jul 2011 23:35:01 -0400
Subject: [PATCH] Create tool to manage dogtag replication agreements
For the most part the existing replication code worked with the
following exceptions:
- Added more port options
- It assumed that initial connections were done to an SSL port. Added
ability to use startTLS
- It assumed that the name of the agreement was the same on both sides.
In dogtag one is marked as master and one as clone. A new option is
added, master, the determines which side we're working on or None
if it isn't a dogtag agreement.
- Don't set the attribute exclude list on dogtag agreements
- dogtag doesn't set a schedule by default (which is actually recommended
by 389-ds). This causes problems when doing a force-sync though so
if one is done we set a schedule to run all the time. Otherwise the
temporary schedule can't be removed (LDAP operations error).
https://fedorahosted.org/freeipa/ticket/1250
---
freeipa.spec.in |7 +-
install/tools/Makefile.am|1 +
install/tools/ipa-csreplica-manage | 452 ++
install/tools/man/Makefile.am|1 +
install/tools/man/ipa-csreplica-manage.1 | 93 ++
ipaserver/install/dsinstance.py |4 +-
ipaserver/install/replication.py | 77 --
7 files changed, 610 insertions(+), 25 deletions(-)
create mode 100755 install/tools/ipa-csreplica-manage
create mode 100644 install/tools/man/ipa-csreplica-manage.1
diff --git a/freeipa.spec.in b/freeipa.spec.in
index e4aa0f6265d37dd250bfdb0d9ea80023744223aa..fc539ca7b5c74995de476892835832317672ae6b 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -365,6 +365,7 @@ fi
%{_sbindir}/ipa-replica-install
%{_sbindir}/ipa-replica-prepare
%{_sbindir}/ipa-replica-manage
+%{_sbindir}/ipa-csreplica-manage
%{_sbindir}/ipa-server-certinstall
%{_sbindir}/ipa-ldap-updater
%{_sbindir}/ipa-compat-manage
@@ -437,6 +438,7 @@ fi
%{_mandir}/man1/ipa-replica-conncheck.1.gz
%{_mandir}/man1/ipa-replica-install.1.gz
%{_mandir}/man1/ipa-replica-manage.1.gz
+%{_mandir}/man1/ipa-csreplica-manage.1.gz
%{_mandir}/man1/ipa-replica-prepare.1.gz
%{_mandir}/man1/ipa-server-certinstall.1.gz
%{_mandir}/man1/ipa-server-install.1.gz
@@ -504,7 +506,10 @@ fi
%ghost %attr(0644,root,apache) %config(noreplace) %{_sysconfdir}/ipa/default.conf
%changelog
-* Wed Jul 6 2011 Adam Young ayo...@redhat.com - 2.0.90-5
+* Thu Jul 14 2011 Rob Crittenden rcrit...@redhat.com - 2.0.90-6
+- Add ipa-csreplica-manage tool.
+
+* Wed Jul 6 2011 Adam Young ayo...@redhat.com - 2.0.90-5
- Add HTML file describing issues with HBAC deny rules
* Fri Jun 17 2011 Rob Crittenden rcrit...@redhat.com - 2.0.90-4
diff --git a/install/tools/Makefile.am
Re: [Freeipa-devel] [PATCH] 825 add dogtag replication management
On 07/15/2011 08:01 AM, Rob Crittenden wrote:
Martin Kosek wrote:
On Fri, 2011-07-15 at 14:43 +0200, Jan Cholasta wrote:
On 15.7.2011 05:42, Rob Crittenden wrote:
Add a separate tool for now to do dogtag replication agreement
management. The syntax is the same for IPA agreements with the
exception
that the DM password is always required and it isn't possible to
delegate the management of this.
ticket https://fedorahosted.org/freeipa/ticket/1250
rob
NACK
'ipa-csreplica-manage list server' doesn't list the peers of the
specified server, but the peers of localhost.
Connecting already connected pair of replicas duplicates the
replication
information ('ipa-csreplica-manage list server' shows the same hostname
twice).
There is trailing whitespace on line 87 of the patch.
BTW I don't understand why is it possible (or necessary?) to be able to
have CS replication topology that is different from the main IPA
replication topology (ipa-csreplica-manage allows you to do that). Is
there a reason for this?
Honza
And some issues from me:
1) Unhelpful error message when force-syncing from a master without a
replication agreement:
# ipa-csreplica-manage force-sync --from=HOST
Directory Manager password:
ipa: ERROR: Unable to find replication agreement for
vm-060.idm.lab.bos.redhat.com
unexpected error: Unable to proceed
2) Minor stuff in man page:
Unindented Exit statuses:
EXIT STATUS
0 if the command was successful
1 if an error occurred
Missing dot: The default is the machine on which the command is run Not
honoured by the re-initialize command.
Otherwise it looks good.
Martin
This should address all the issues raised.
The reason for different topology has several reasons:
1. A given IPA server may not have a CA installed
2. Some aspects of ipa-replica-manage can be delegated. We can't
delegate CS replica management because it is in a different directory
server. We don't have users stored there so can't map the GSSAPI
credentials. So only Directory Manager can operate on it for now.
3. Flexibility. You may want way more connections for users than for
the CA.
+if starttls:
+self.conn = ipaldap.IPAdmin(hostname, port=port)
+ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, CACERT)
Why in the starttls case do you not call ipaldap.IPAdmin(hostname,
port=PORT, cacert=CACERT) ?
+managers = entry.getValues('nsDS5ReplicaBindDN')
+if replica_binddn not in managers:
You might want to use the dn.py code, or at least normalize the DNs in
managers before comparing
+if master is None:
+entry.setValues('nsds5replicaupdateschedule', '-2359
0123456')
You should just omit nsds5replicaupdateschedule
suggest using the dn.py code in the new csreplica manage script
rob
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 825 add dogtag replication management
Rich Megginson wrote:
On 07/15/2011 08:01 AM, Rob Crittenden wrote:
Martin Kosek wrote:
On Fri, 2011-07-15 at 14:43 +0200, Jan Cholasta wrote:
On 15.7.2011 05:42, Rob Crittenden wrote:
Add a separate tool for now to do dogtag replication agreement
management. The syntax is the same for IPA agreements with the
exception
that the DM password is always required and it isn't possible to
delegate the management of this.
ticket https://fedorahosted.org/freeipa/ticket/1250
rob
NACK
'ipa-csreplica-manage list server' doesn't list the peers of the
specified server, but the peers of localhost.
Connecting already connected pair of replicas duplicates the
replication
information ('ipa-csreplica-manage list server' shows the same hostname
twice).
There is trailing whitespace on line 87 of the patch.
BTW I don't understand why is it possible (or necessary?) to be able to
have CS replication topology that is different from the main IPA
replication topology (ipa-csreplica-manage allows you to do that). Is
there a reason for this?
Honza
And some issues from me:
1) Unhelpful error message when force-syncing from a master without a
replication agreement:
# ipa-csreplica-manage force-sync --from=HOST
Directory Manager password:
ipa: ERROR: Unable to find replication agreement for
vm-060.idm.lab.bos.redhat.com
unexpected error: Unable to proceed
2) Minor stuff in man page:
Unindented Exit statuses:
EXIT STATUS
0 if the command was successful
1 if an error occurred
Missing dot: The default is the machine on which the command is run Not
honoured by the re-initialize command.
Otherwise it looks good.
Martin
This should address all the issues raised.
The reason for different topology has several reasons:
1. A given IPA server may not have a CA installed
2. Some aspects of ipa-replica-manage can be delegated. We can't
delegate CS replica management because it is in a different directory
server. We don't have users stored there so can't map the GSSAPI
credentials. So only Directory Manager can operate on it for now.
3. Flexibility. You may want way more connections for users than for
the CA.
+if starttls:
+self.conn = ipaldap.IPAdmin(hostname, port=port)
+ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, CACERT)
Why in the starttls case do you not call ipaldap.IPAdmin(hostname,
port=PORT, cacert=CACERT) ?
Because the port is the non-secure port and opening an SSL connection to
it failed.
+managers = entry.getValues('nsDS5ReplicaBindDN')
+if replica_binddn not in managers:
You might want to use the dn.py code, or at least normalize the DNs in
managers before comparing
That's a good idea.
+if master is None:
+entry.setValues('nsds5replicaupdateschedule', '-2359
0123456')
You should just omit nsds5replicaupdateschedule
It failed with an operations erorr when I tried removing the attribute
either directly with a MOD_DELETE or doing a MOD_REPLACE with nothing. I
assume this is another attribute in cn=config that once set cannot be
undone.
rob
suggest using the dn.py code in the new csreplica manage script
rob
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 825 add dogtag replication management
On 07/15/2011 10:57 AM, Rob Crittenden wrote:
Rich Megginson wrote:
On 07/15/2011 08:01 AM, Rob Crittenden wrote:
Martin Kosek wrote:
On Fri, 2011-07-15 at 14:43 +0200, Jan Cholasta wrote:
On 15.7.2011 05:42, Rob Crittenden wrote:
Add a separate tool for now to do dogtag replication agreement
management. The syntax is the same for IPA agreements with the
exception
that the DM password is always required and it isn't possible to
delegate the management of this.
ticket https://fedorahosted.org/freeipa/ticket/1250
rob
NACK
'ipa-csreplica-manage list server' doesn't list the peers of the
specified server, but the peers of localhost.
Connecting already connected pair of replicas duplicates the
replication
information ('ipa-csreplica-manage list server' shows the same
hostname
twice).
There is trailing whitespace on line 87 of the patch.
BTW I don't understand why is it possible (or necessary?) to be
able to
have CS replication topology that is different from the main IPA
replication topology (ipa-csreplica-manage allows you to do that). Is
there a reason for this?
Honza
And some issues from me:
1) Unhelpful error message when force-syncing from a master without a
replication agreement:
# ipa-csreplica-manage force-sync --from=HOST
Directory Manager password:
ipa: ERROR: Unable to find replication agreement for
vm-060.idm.lab.bos.redhat.com
unexpected error: Unable to proceed
2) Minor stuff in man page:
Unindented Exit statuses:
EXIT STATUS
0 if the command was successful
1 if an error occurred
Missing dot: The default is the machine on which the command is
run Not
honoured by the re-initialize command.
Otherwise it looks good.
Martin
This should address all the issues raised.
The reason for different topology has several reasons:
1. A given IPA server may not have a CA installed
2. Some aspects of ipa-replica-manage can be delegated. We can't
delegate CS replica management because it is in a different directory
server. We don't have users stored there so can't map the GSSAPI
credentials. So only Directory Manager can operate on it for now.
3. Flexibility. You may want way more connections for users than for
the CA.
+if starttls:
+self.conn = ipaldap.IPAdmin(hostname, port=port)
+ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, CACERT)
Why in the starttls case do you not call ipaldap.IPAdmin(hostname,
port=PORT, cacert=CACERT) ?
Because the port is the non-secure port and opening an SSL connection
to it failed.
Ah, ok. So that tells IPAdmin to use this CACERT and to use ldaps.
+managers = entry.getValues('nsDS5ReplicaBindDN')
+if replica_binddn not in managers:
You might want to use the dn.py code, or at least normalize the DNs in
managers before comparing
That's a good idea.
+if master is None:
+entry.setValues('nsds5replicaupdateschedule', '-2359
0123456')
You should just omit nsds5replicaupdateschedule
It failed with an operations erorr when I tried removing the attribute
either directly with a MOD_DELETE or doing a MOD_REPLACE with nothing.
I assume this is another attribute in cn=config that once set cannot
be undone.
Right. Ok. When you add the agreement entry, you can just omit it.
But if you are trying to modify an existing agreement entry, you can't
MOD_DELETE it or MOD_REPLACE with an empty value.
rob
suggest using the dn.py code in the new csreplica manage script
rob
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 825 add dogtag replication management
Rich Megginson wrote:
On 07/15/2011 10:57 AM, Rob Crittenden wrote:
Rich Megginson wrote:
On 07/15/2011 08:01 AM, Rob Crittenden wrote:
Martin Kosek wrote:
On Fri, 2011-07-15 at 14:43 +0200, Jan Cholasta wrote:
On 15.7.2011 05:42, Rob Crittenden wrote:
Add a separate tool for now to do dogtag replication agreement
management. The syntax is the same for IPA agreements with the
exception
that the DM password is always required and it isn't possible to
delegate the management of this.
ticket https://fedorahosted.org/freeipa/ticket/1250
rob
NACK
'ipa-csreplica-manage list server' doesn't list the peers of the
specified server, but the peers of localhost.
Connecting already connected pair of replicas duplicates the
replication
information ('ipa-csreplica-manage list server' shows the same
hostname
twice).
There is trailing whitespace on line 87 of the patch.
BTW I don't understand why is it possible (or necessary?) to be
able to
have CS replication topology that is different from the main IPA
replication topology (ipa-csreplica-manage allows you to do that). Is
there a reason for this?
Honza
And some issues from me:
1) Unhelpful error message when force-syncing from a master without a
replication agreement:
# ipa-csreplica-manage force-sync --from=HOST
Directory Manager password:
ipa: ERROR: Unable to find replication agreement for
vm-060.idm.lab.bos.redhat.com
unexpected error: Unable to proceed
2) Minor stuff in man page:
Unindented Exit statuses:
EXIT STATUS
0 if the command was successful
1 if an error occurred
Missing dot: The default is the machine on which the command is run
Not
honoured by the re-initialize command.
Otherwise it looks good.
Martin
This should address all the issues raised.
The reason for different topology has several reasons:
1. A given IPA server may not have a CA installed
2. Some aspects of ipa-replica-manage can be delegated. We can't
delegate CS replica management because it is in a different directory
server. We don't have users stored there so can't map the GSSAPI
credentials. So only Directory Manager can operate on it for now.
3. Flexibility. You may want way more connections for users than for
the CA.
+ if starttls:
+ self.conn = ipaldap.IPAdmin(hostname, port=port)
+ ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, CACERT)
Why in the starttls case do you not call ipaldap.IPAdmin(hostname,
port=PORT, cacert=CACERT) ?
Because the port is the non-secure port and opening an SSL connection
to it failed.
Ah, ok. So that tells IPAdmin to use this CACERT and to use ldaps.
+ managers = entry.getValues('nsDS5ReplicaBindDN')
+ if replica_binddn not in managers:
You might want to use the dn.py code, or at least normalize the DNs in
managers before comparing
That's a good idea.
+ if master is None:
+ entry.setValues('nsds5replicaupdateschedule', '-2359
0123456')
You should just omit nsds5replicaupdateschedule
It failed with an operations erorr when I tried removing the attribute
either directly with a MOD_DELETE or doing a MOD_REPLACE with nothing.
I assume this is another attribute in cn=config that once set cannot
be undone.
Right. Ok. When you add the agreement entry, you can just omit it. But
if you are trying to modify an existing agreement entry, you can't
MOD_DELETE it or MOD_REPLACE with an empty value.
Ok, good point about normalizing, updated patch attached.
rob
From 4beef93e15295fad48df5944c94b72c1ba2a303f Mon Sep 17 00:00:00 2001
From: Rob Crittenden rcrit...@redhat.com
Date: Thu, 14 Jul 2011 23:35:01 -0400
Subject: [PATCH] Create tool to manage dogtag replication agreements
For the most part the existing replication code worked with the
following exceptions:
- Added more port options
- It assumed that initial connections were done to an SSL port. Added
ability to use startTLS
- It assumed that the name of the agreement was the same on both sides.
In dogtag one is marked as master and one as clone. A new option is
added, master, the determines which side we're working on or None
if it isn't a dogtag agreement.
- Don't set the attribute exclude list on dogtag agreements
- dogtag doesn't set a schedule by default (which is actually recommended
by 389-ds). This causes problems when doing a force-sync though so
if one is done we set a schedule to run all the time. Otherwise the
temporary schedule can't be removed (LDAP operations error).
https://fedorahosted.org/freeipa/ticket/1250
---
freeipa.spec.in |7 +-
install/tools/Makefile.am|1 +
install/tools/ipa-csreplica-manage | 452 ++
install/tools/man/Makefile.am|1 +
install/tools/man/ipa-csreplica-manage.1 | 93 ++
ipaserver/install/dsinstance.py |4 +-
ipaserver/install/replication.py | 81 --
7 files changed, 614 insertions(+), 25 deletions(-)
create mode 100755 install/tools/ipa-csreplica-manage
create mode 100644
Re: [Freeipa-devel] [PATCH] 825 add dogtag replication management
On 07/15/2011 01:24 PM, Rob Crittenden wrote:
Rich Megginson wrote:
On 07/15/2011 10:57 AM, Rob Crittenden wrote:
Rich Megginson wrote:
On 07/15/2011 08:01 AM, Rob Crittenden wrote:
Martin Kosek wrote:
On Fri, 2011-07-15 at 14:43 +0200, Jan Cholasta wrote:
On 15.7.2011 05:42, Rob Crittenden wrote:
Add a separate tool for now to do dogtag replication agreement
management. The syntax is the same for IPA agreements with the
exception
that the DM password is always required and it isn't possible to
delegate the management of this.
ticket https://fedorahosted.org/freeipa/ticket/1250
rob
NACK
'ipa-csreplica-manage list server' doesn't list the peers of the
specified server, but the peers of localhost.
Connecting already connected pair of replicas duplicates the
replication
information ('ipa-csreplica-manage list server' shows the same
hostname
twice).
There is trailing whitespace on line 87 of the patch.
BTW I don't understand why is it possible (or necessary?) to be
able to
have CS replication topology that is different from the main IPA
replication topology (ipa-csreplica-manage allows you to do
that). Is
there a reason for this?
Honza
And some issues from me:
1) Unhelpful error message when force-syncing from a master
without a
replication agreement:
# ipa-csreplica-manage force-sync --from=HOST
Directory Manager password:
ipa: ERROR: Unable to find replication agreement for
vm-060.idm.lab.bos.redhat.com
unexpected error: Unable to proceed
2) Minor stuff in man page:
Unindented Exit statuses:
EXIT STATUS
0 if the command was successful
1 if an error occurred
Missing dot: The default is the machine on which the command is run
Not
honoured by the re-initialize command.
Otherwise it looks good.
Martin
This should address all the issues raised.
The reason for different topology has several reasons:
1. A given IPA server may not have a CA installed
2. Some aspects of ipa-replica-manage can be delegated. We can't
delegate CS replica management because it is in a different directory
server. We don't have users stored there so can't map the GSSAPI
credentials. So only Directory Manager can operate on it for now.
3. Flexibility. You may want way more connections for users than for
the CA.
+ if starttls:
+ self.conn = ipaldap.IPAdmin(hostname, port=port)
+ ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, CACERT)
Why in the starttls case do you not call ipaldap.IPAdmin(hostname,
port=PORT, cacert=CACERT) ?
Because the port is the non-secure port and opening an SSL connection
to it failed.
Ah, ok. So that tells IPAdmin to use this CACERT and to use ldaps.
+ managers = entry.getValues('nsDS5ReplicaBindDN')
+ if replica_binddn not in managers:
You might want to use the dn.py code, or at least normalize the DNs in
managers before comparing
That's a good idea.
+ if master is None:
+ entry.setValues('nsds5replicaupdateschedule', '-2359
0123456')
You should just omit nsds5replicaupdateschedule
It failed with an operations erorr when I tried removing the attribute
either directly with a MOD_DELETE or doing a MOD_REPLACE with nothing.
I assume this is another attribute in cn=config that once set cannot
be undone.
Right. Ok. When you add the agreement entry, you can just omit it. But
if you are trying to modify an existing agreement entry, you can't
MOD_DELETE it or MOD_REPLACE with an empty value.
Ok, good point about normalizing, updated patch attached.
The new script ipa-csreplica-manage does a lot of DN manipulation -
would be better to use the DN class for creating, parsing, and
formatting DN strings.
rob
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 825 add dogtag replication management
On 15.7.2011 21:24, Rob Crittenden wrote:
Rich Megginson wrote:
On 07/15/2011 10:57 AM, Rob Crittenden wrote:
Rich Megginson wrote:
On 07/15/2011 08:01 AM, Rob Crittenden wrote:
Martin Kosek wrote:
On Fri, 2011-07-15 at 14:43 +0200, Jan Cholasta wrote:
On 15.7.2011 05:42, Rob Crittenden wrote:
Add a separate tool for now to do dogtag replication agreement
management. The syntax is the same for IPA agreements with the
exception
that the DM password is always required and it isn't possible to
delegate the management of this.
ticket https://fedorahosted.org/freeipa/ticket/1250
rob
NACK
'ipa-csreplica-manage list server' doesn't list the peers of the
specified server, but the peers of localhost.
Connecting already connected pair of replicas duplicates the
replication
information ('ipa-csreplica-manage list server' shows the same
hostname
twice).
There is trailing whitespace on line 87 of the patch.
BTW I don't understand why is it possible (or necessary?) to be
able to
have CS replication topology that is different from the main IPA
replication topology (ipa-csreplica-manage allows you to do
that). Is
there a reason for this?
Honza
And some issues from me:
1) Unhelpful error message when force-syncing from a master without a
replication agreement:
# ipa-csreplica-manage force-sync --from=HOST
Directory Manager password:
ipa: ERROR: Unable to find replication agreement for
vm-060.idm.lab.bos.redhat.com
unexpected error: Unable to proceed
2) Minor stuff in man page:
Unindented Exit statuses:
EXIT STATUS
0 if the command was successful
1 if an error occurred
Missing dot: The default is the machine on which the command is run
Not
honoured by the re-initialize command.
Otherwise it looks good.
Martin
This should address all the issues raised.
The reason for different topology has several reasons:
1. A given IPA server may not have a CA installed
2. Some aspects of ipa-replica-manage can be delegated. We can't
delegate CS replica management because it is in a different directory
server. We don't have users stored there so can't map the GSSAPI
credentials. So only Directory Manager can operate on it for now.
3. Flexibility. You may want way more connections for users than for
the CA.
+ if starttls:
+ self.conn = ipaldap.IPAdmin(hostname, port=port)
+ ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, CACERT)
Why in the starttls case do you not call ipaldap.IPAdmin(hostname,
port=PORT, cacert=CACERT) ?
Because the port is the non-secure port and opening an SSL connection
to it failed.
Ah, ok. So that tells IPAdmin to use this CACERT and to use ldaps.
+ managers = entry.getValues('nsDS5ReplicaBindDN')
+ if replica_binddn not in managers:
You might want to use the dn.py code, or at least normalize the DNs in
managers before comparing
That's a good idea.
+ if master is None:
+ entry.setValues('nsds5replicaupdateschedule', '-2359
0123456')
You should just omit nsds5replicaupdateschedule
It failed with an operations erorr when I tried removing the attribute
either directly with a MOD_DELETE or doing a MOD_REPLACE with nothing.
I assume this is another attribute in cn=config that once set cannot
be undone.
Right. Ok. When you add the agreement entry, you can just omit it. But
if you are trying to modify an existing agreement entry, you can't
MOD_DELETE it or MOD_REPLACE with an empty value.
Ok, good point about normalizing, updated patch attached.
rob
Everything I found is fixed. You might want to take a look at what
Martin found, though.
Honza
--
Jan Cholasta
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 825 add dogtag replication management
Add a separate tool for now to do dogtag replication agreement
management. The syntax is the same for IPA agreements with the exception
that the DM password is always required and it isn't possible to
delegate the management of this.
ticket https://fedorahosted.org/freeipa/ticket/1250
rob
From eebffc5a9718321ada78a5baddfc34743f001aed Mon Sep 17 00:00:00 2001
From: Rob Crittenden rcrit...@redhat.com
Date: Thu, 14 Jul 2011 23:35:01 -0400
Subject: [PATCH] Create tool to manage dogtag replication agreements
For the most part the existing replication code worked with the
following exceptions:
- Added more port options
- It assumed that initial connections were done to an SSL port. Added
ability to use startTLS
- It assumed that the name of the agreement was the same on both sides.
In dogtag one is marked as master and one as clone. A new option is
added, master, the determines which side we're working on or None
if it isn't a dogtag agreement.
- Don't set the attribute exclude list on dogtag agreements
- dogtag doesn't set a schedule by default (which is actually recommended
by 389-ds). This causes problems when doing a force-sync though so
if one is done we set a schedule to run all the time. Otherwise the
temporary schedule can't be removed (LDAP operations error).
https://fedorahosted.org/freeipa/ticket/1250
---
freeipa.spec.in |7 +-
install/tools/Makefile.am|1 +
install/tools/ipa-csreplica-manage | 445 ++
install/tools/man/Makefile.am|1 +
install/tools/man/ipa-csreplica-manage.1 | 92 ++
ipaserver/install/dsinstance.py |4 +-
ipaserver/install/replication.py | 77 --
7 files changed, 602 insertions(+), 25 deletions(-)
create mode 100755 install/tools/ipa-csreplica-manage
create mode 100644 install/tools/man/ipa-csreplica-manage.1
diff --git a/freeipa.spec.in b/freeipa.spec.in
index e4aa0f6265d37dd250bfdb0d9ea80023744223aa..fc539ca7b5c74995de476892835832317672ae6b 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -365,6 +365,7 @@ fi
%{_sbindir}/ipa-replica-install
%{_sbindir}/ipa-replica-prepare
%{_sbindir}/ipa-replica-manage
+%{_sbindir}/ipa-csreplica-manage
%{_sbindir}/ipa-server-certinstall
%{_sbindir}/ipa-ldap-updater
%{_sbindir}/ipa-compat-manage
@@ -437,6 +438,7 @@ fi
%{_mandir}/man1/ipa-replica-conncheck.1.gz
%{_mandir}/man1/ipa-replica-install.1.gz
%{_mandir}/man1/ipa-replica-manage.1.gz
+%{_mandir}/man1/ipa-csreplica-manage.1.gz
%{_mandir}/man1/ipa-replica-prepare.1.gz
%{_mandir}/man1/ipa-server-certinstall.1.gz
%{_mandir}/man1/ipa-server-install.1.gz
@@ -504,7 +506,10 @@ fi
%ghost %attr(0644,root,apache) %config(noreplace) %{_sysconfdir}/ipa/default.conf
%changelog
-* Wed Jul 6 2011 Adam Young ayo...@redhat.com - 2.0.90-5
+* Thu Jul 14 2011 Rob Crittenden rcrit...@redhat.com - 2.0.90-6
+- Add ipa-csreplica-manage tool.
+
+* Wed Jul 6 2011 Adam Young ayo...@redhat.com - 2.0.90-5
- Add HTML file describing issues with HBAC deny rules
* Fri Jun 17 2011 Rob Crittenden rcrit...@redhat.com - 2.0.90-4
diff --git a/install/tools/Makefile.am b/install/tools/Makefile.am
index c6ecd92876adb5ba5dd5eef041502c27e56bb811..fc615ec04f324c2d9c98dc8cf674938e1064bec6 100644
--- a/install/tools/Makefile.am
+++ b/install/tools/Makefile.am
@@ -12,6 +12,7 @@ sbin_SCRIPTS = \
ipa-replica-install \
ipa-replica-prepare \
ipa-replica-manage \
+ ipa-csreplica-manage \
ipa-server-certinstall \
ipactl \
ipa-compat-manage \
diff --git a/install/tools/ipa-csreplica-manage b/install/tools/ipa-csreplica-manage
new file mode 100755
index ..6267d304269ceafe3120fa2b97f54a3bcdfadef1
--- /dev/null
+++ b/install/tools/ipa-csreplica-manage
@@ -0,0 +1,445 @@
+#! /usr/bin/python -E
+# Authors: Rob Crittenden rcrit...@redhat.com
+#
+# Based on ipa-replica-manage by Karl MacMillan kmacmil...@mentalrootkit.com
+#
+# Copyright (C) 2011 Red Hat
+# see file 'COPYING' for use and warranty information
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see http://www.gnu.org/licenses/.
+#
+import sys
+import os
+
+import getpass, ldap, krbV
+import logging
+
+from ipapython import ipautil
+from ipaserver.install import replication, installutils
+from ipaserver import ipaldap
+from ipapython import version
+from ipalib import api, errors, util
+from
