Re: [Freeipa-devel] [PATCH] 1051 Fix CS replica management

[Martin Kosek]

On 10/08/2012 05:12 PM, Jan Cholasta wrote:
 Hi,
 
 On 20.9.2012 19:38, Rob Crittenden wrote:
 Jan Cholasta wrote:
 Hi,

 Dne 31.8.2012 19:43, Rob Crittenden napsal(a):
 The naming in CS replication agreements is different from IPA
 agreements, we have to live with what the create. The master side should
 be on the local side, replica1, not the remote. This required reversing
 a few master variables.

 Pass in the force flag to del_link.

 Do a better job of finding the agreements on each side.

 This should be ipa-csreplica-manage more in line with
 ipa-replica-manage.

 rob


 Rob, can you please rebase the patch on top of current master? There
 were some dogtag 10 related changes to ipa-csreplica-manage since you
 posted the patch.

 Honza


 I re-tested after the merge and found some problems with my initial
 approach. The problem stems from the naming convention that dogtag uses
 when creating the initial agreements. It is hard to predict how things
 were set up later so rather than trying to reconstruct the DN we search
 for it and pass it when deleting agreements.

 rob
 
 So far I have found this:
 
   * Deleting a bridge link that connects two islands of replicas works, 
 but
 it should not (I was told that this is expected, as no complex graph 
 algorithms
 are engaged to detect this kind of errors).

Exactly, I hit this error when I was a similar Rob's patch for
ipa-replica-manage (ticket 2797). I used topology A - B - C - D - E and I was
able to delete C. We may want to log an enhancement ticket for this.

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 0082/0083 Handle NotFound exception when establishing trust

[Martin Kosek]

On 10/08/2012 02:22 PM, Alexander Bokovoy wrote:
 On Mon, 08 Oct 2012, Petr Vobornik wrote:
 On 10/05/2012 08:14 PM, Alexander Bokovoy wrote:
 On Fri, 05 Oct 2012, Petr Vobornik wrote:
 On 10/05/2012 03:24 PM, Alexander Bokovoy wrote:
 On Fri, 05 Oct 2012, Petr Vobornik wrote:
 On 10/04/2012 05:06 PM, Alexander Bokovoy wrote:

 Hi,

 two attached patches attempt to solve
 https://fedorahosted.org/freeipa/ticket/3103

 We cannot make educated guess where trusted domain's DNS server is
 located as we ended up with NotFound exception precisely because we
 were
 unable to discover trusted domain's domain controller location.

 Thus, all we can do is to suggest ways to fix the issue. Since
 suggestion becomes relatively long (multi-line, at least), it creates
 few issues for current exception error message handling:
 - root_logger does not use textui to format output
 - textui is only printing to standard output
 - multi-line error messages thus become non-wrapped
 - localizing such messages would become a harder context-wise.

 Web UI is showing error message as a single paragraph (p/), all
 multi-line markup would be lost.

 In the end, I decided to support list-based multi-line error
 messages in
 PublicError class. Its constructor will join all list-based arguments
 into single string per argument (first patch).

 In Web UI I've added special text processing of error messages that
 splits message into multiple lines and wraps those which start with a
 TAB symbol into 'error-message-hinted' span to visually separate it
 from
 the rest of error message. Trust code uses this to display
 suggested CLI
 command to set up DNS forwarder (second patch).

 In the end, CLI shows such error message fine (note tabulated CLI
 command):
 ---

 # ipa trust-add --type=ad --admin Administrator@ad.local1 --password
 ad.local1
 Active directory domain administrator's password: ipa: ERROR:
 Unable to
 resolve domain controller for 'ad.local1' domain. IPA manages DNS,
 please configure forwarder to 'ad.local1' domain by using following
 CLI
 command. Please replace DNS_SERVER and IP_ADDRESS by name and
 address of
 the domain's name server:
   ipa dnszone-add ad.local1 --name-server=DNS_SERVER
 --admin-email='hostmaster@ad.local1' --force --forwarder=IP_ADDRESS
 --forward-policy=only
 When using Web UI, please create DNS zone for domain 'ad.local1' first
 and then set forwarder and forward policy
 ---


 Web UI looks like this: http://abbra.fedorapeople.org/.paste/ui.png



 You have undeclared identifier: lines.

 I recommend to run `jsl -conf jsl.conf` command in install/ui folder
 to prevent these issues.
 Fixed.


 I'm not convinced that beautify call should be in command object. I
 would rather see it in error_dialog.
 I moved everything to error_dialog and used $() selectors instead of
 directly playing with text.

 1)
 +var error_message = $('span /', {});

 I would rather see a div / as a container. Span is and should
 contain only inline elements.
 Fixed.

 2)
 var line_span = $('span /', {
   class: 'error-message-hinted',
   text: lines[i].substr(1)
   }).appendTo(container);

 Why do you use span for hinted message and p for other lines?
 Shouldn't we use p for both?
 Fixed to use p everywhere.


 3) var line_span is declared twice. JS use function scope, not block
 scope.
 Fixed.

 Thanks for the review. New patch 0082 attached.


 ACK on the UI part with a little change (updated patch attached):
class: 'error-message-hinted',
 needs to be changed to
'class': 'error-message-hinted',
 because class is a keyword and should not be used this way. Sorry that I
 missed it before.
 Thanks!
 
 
 The patch works as advertised. I would give ACK to the python part of 82 and
 patch 83 as well but probably someone more skilled in python and ipa
 internals should do it.

 Why do you have to concatenate the value in PublicErrors' __init__ method?
 Shouldn't it be a responsibility of error source (in this case 'execute_ad'
 method)? - just a question, not an issue
 This is a good question and gives me some space to explain why certain
 decisions are made.
 
 The whole idea of the patch is to introduce a way to provide multi-line
 error messages as a feature of error handling in the FreeIPA framework.
 
 Suppose we had to join multiple lines always before creating an error
 object. This means we would have hundreds of '\n'.join() calls across
 the code. Besides maintenance burden, it would also make computational
 burden later if we would add proper content formating (which we don't do
 now for errors) -- since we would need to split strings later to
 reformat them.
 
 Python is flexible enough to discover parameter types which
 allows to design APIs that easer to use. Easier to use means least
 surprise for the caller rather than callee. 

Re: [Freeipa-devel] [PATCH] ipa-adtrust-install: create fallback group with ldif file

[Martin Kosek]

On 10/08/2012 07:50 PM, Simo Sorce wrote:
 On Mon, 2012-10-08 at 18:35 +0200, Sumit Bose wrote:

 Thank you for the review, both issues are fixed in the new version.

 Ack,
 Simo.
 

Pushed to master, ipa-3-0.

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [RFC] Reload trust data in ipadb

[Martin Kosek]

On 10/08/2012 10:54 PM, Simo Sorce wrote:
 On Mon, 2012-10-08 at 22:40 +0200, Sumit Bose wrote:
 On Fri, Oct 05, 2012 at 08:44:41AM -0400, Simo Sorce wrote:
 On Fri, 2012-10-05 at 13:32 +0200, Sumit Bose wrote:
  
 This part look fine, I wonder if we shouldn't make it even longer than 1
 min.

 I would prefer to keep it 1 minute to make the user experience better in
 the case where trust is added to more than one domain.

 I have opened https://fedorahosted.org/freeipa/ticket/3156 to track the
 reload issue.

 New version attatched.
 
 ACK,
 Simo.
 

Rebased and pushed to master, ipa-3-0.

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] Fix up trust attributes on trust-add

[Martin Kosek]

On 10/08/2012 06:32 PM, Sumit Bose wrote:
 On Fri, Oct 05, 2012 at 09:17:47PM +0300, Alexander Bokovoy wrote:
 On Fri, 05 Oct 2012, Simo Sorce wrote:
 A onliner but better to have it validated by a second pair of eyes.
 Yep. Go ahead.

 The origin of USES_RC4_ENCRYPTION comes from Samba 3 code in net utility
 that Sumit implemented ~1.5 year ago.
 
 I didn't found any issues while testing. ACK
 
 bye,
 Sumit
 

Pushed to master, ipa-3-0.

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] ipa-adtrust-install: create fallback group with ldif file

[Martin Kosek]

On 10/09/2012 10:23 AM, Martin Kosek wrote:
 On 10/08/2012 07:50 PM, Simo Sorce wrote:
 On Mon, 2012-10-08 at 18:35 +0200, Sumit Bose wrote:

 Thank you for the review, both issues are fixed in the new version.

 Ack,
 Simo.

 
 Pushed to master, ipa-3-0.
 
 Martin
 

I accidentally pushed older version of Sumit's patch, so I prepared an
interdiff of these 2 patches. While at it, I squashed a one-liner amending a
name of the default SMB group in a list of protected groups in group.py (patch
attached),

Pushed to master, ipa-3-0.

Martin
From f520888da2b3aebe8cd4d00fb95ca52f777a3116 Mon Sep 17 00:00:00 2001
From: Martin Kosek mko...@redhat.com
Date: Tue, 9 Oct 2012 11:03:00 +0200
Subject: [PATCH] Minor fixes for default SMB group

This patch contains additional minor fixes which were proposed during
review but were not pushed (accidentaly). Also amends a name of the
default SMB group in a list of protected groups in group.py.

https://fedorahosted.org/freeipa/ticket/3147
---
 install/share/default-smb-group.ldif | 2 +-
 ipalib/plugins/group.py  | 2 +-
 ipaserver/install/adtrustinstance.py | 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/install/share/default-smb-group.ldif b/install/share/default-smb-group.ldif
index 8d89f67cc7d8be66375c9accb038b3c20a4d4be4..abcc8a945a8187529044beeb73262b5434070b48 100644
--- a/install/share/default-smb-group.ldif
+++ b/install/share/default-smb-group.ldif
@@ -1,7 +1,7 @@
 dn: cn=Default SMB Group,cn=groups,cn=accounts,$SUFFIX
 changetype: add
 cn: Default SMB Group
-description: Fallback group for primary group RID, do not add user to this group
+description: Fallback group for primary group RID, do not add users to this group
 gidnumber: 999
 objectclass: top
 objectclass: ipaobject
diff --git a/ipalib/plugins/group.py b/ipalib/plugins/group.py
index 1611e422bbef3d1ee9c71a819b7f9cc13cd819ab..a174ba62cc32a7fb83474f52e2621521553889af 100644
--- a/ipalib/plugins/group.py
+++ b/ipalib/plugins/group.py
@@ -107,7 +107,7 @@ Example:
ipa group-add-member ad_admins --groups ad_admins_external
 )
 
-PROTECTED_GROUPS = (u'admins', u'trust admins', u'default_smb_group')
+PROTECTED_GROUPS = (u'admins', u'trust admins', u'default smb group')
 
 class group(LDAPObject):
 
diff --git a/ipaserver/install/adtrustinstance.py b/ipaserver/install/adtrustinstance.py
index 41030223d1f644ba6a6557ac90d8f518fcba9c29..d86f9f51463912c3541a27118843c30d88439ae5 100644
--- a/ipaserver/install/adtrustinstance.py
+++ b/ipaserver/install/adtrustinstance.py
@@ -238,8 +238,8 @@ class ADTRUSTInstance(service.Service):
 try:
 self.admin_conn.getEntry(fb_group_dn, ldap.SCOPE_BASE)
 except errors.NotFound:
-self.print_msg(Failed to add fallback group.)
-return
+self.print_msg(Failed to add fallback group.)
+return
 
 try:
 mod = [(ldap.MOD_ADD, self.ATTR_FALLBACK_GROUP, fb_group_dn)]
-- 
1.7.11.4

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH 0074] Fix zone removal in persistent search update_zone()

[Adam Tkac]

On Fri, Oct 05, 2012 at 01:15:13PM +0200, Petr Spacek wrote:
 Hello,
 
 Fix zone removal in persistent search update_zone().
 
 Without this patch any zone removed through ipa dnszone-del will
 remain active and will return SERVFAILs.

Ack

 From e09eebf3c370ff4106013cdeda10a80782e26611 Mon Sep 17 00:00:00 2001
 From: Petr Spacek pspa...@redhat.com
 Date: Fri, 5 Oct 2012 13:02:37 +0200
 Subject: [PATCH] Fix zone removal in persistent search update_zone() handler.
 
 Signed-off-by: Petr Spacek pspa...@redhat.com
 ---
  src/ldap_helper.c | 20 ++--
  1 file changed, 10 insertions(+), 10 deletions(-)
 
 diff --git a/src/ldap_helper.c b/src/ldap_helper.c
 index 
 68b635f84b4c9015752667510c0497e5f56bc7ab..199b345bb604c30bfa8a3690afc844ca8b264e89
  100644
 --- a/src/ldap_helper.c
 +++ b/src/ldap_helper.c
 @@ -3056,7 +3056,6 @@ update_zone(isc_task_t *task, isc_event_t *event)
   ldap_qresult_t *ldap_qresult_record = NULL;
   ldap_entry_t *entry_zone = NULL;
   ldap_entry_t *entry_record = NULL;
 - isc_boolean_t delete = ISC_TRUE;
   isc_mem_t *mctx;
   dns_name_t prevname;
   char *attrs_zone[] = {
 @@ -3073,14 +3072,16 @@ update_zone(isc_task_t *task, isc_event_t *event)
   dns_name_init(prevname, NULL);
  
   CHECK(manager_get_ldap_instance(pevent-dbname, inst));
 - CHECK(ldap_query(inst, NULL, ldap_qresult_zone, pevent-dn,
 +
 + result = ldap_query(inst, NULL, ldap_qresult_zone, pevent-dn,
LDAP_SCOPE_BASE, attrs_zone, 0,
 -  ((objectClass=idnsZone)(idnsZoneActive=TRUE;
 +  ((objectClass=idnsZone)(idnsZoneActive=TRUE)));
 + if (result != ISC_R_SUCCESS  result != ISC_R_NOTFOUND)
 + CLEANUP_WITH(result);
  
 - for (entry_zone = HEAD(ldap_qresult_zone-ldap_entries);
 - entry_zone != NULL;
 - entry_zone = NEXT(entry_zone, link)) {
 - delete = ISC_FALSE;
 + if (result == ISC_R_SUCCESS 
 + HEAD(ldap_qresult_zone-ldap_entries) != NULL) {
 + entry_zone = HEAD(ldap_qresult_zone-ldap_entries);
   CHECK(ldap_parse_zoneentry(entry_zone, inst));
  
   if (PSEARCH_MODDN(pevent-chgtype)) {
 @@ -3106,10 +3107,9 @@ update_zone(isc_task_t *task, isc_event_t *event)
   }
  
   INSIST(NEXT(entry_zone, link) == NULL); /* no multiple zones 
 with same DN */
 - }
 -
 - if (delete)
 + } else {
   CHECK(ldap_delete_zone(inst, pevent-dn, ISC_TRUE));
 + }
  
  cleanup:
   if (result != ISC_R_SUCCESS)
 -- 
 1.7.11.4
 


-- 
Adam Tkac, Red Hat, Inc.

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH 0075] Prevent misleading partial match error messages for disabled zones

[Adam Tkac]

On Fri, Oct 05, 2012 at 01:45:42PM +0200, Petr Spacek wrote:
 Hello,
 
 Prevent misleading partial match error messages for disabled zones.
 
 Following message was printed if zone e.test was disabled and LDAP
 contained zones test and e.test:
 update_zone (psearch) failed for
 'idnsName=e.test,cn=dns,dc=e,dc=org'. Zones can be outdated, run
 `rndc reload`: partial match

Ack

 From e7f7a7d6e4fb3c9e47bac22d3291d09aa3d885ab Mon Sep 17 00:00:00 2001
 From: Petr Spacek pspa...@redhat.com
 Date: Fri, 5 Oct 2012 13:37:18 +0200
 Subject: [PATCH] Prevent misleading partial match error messages for
  disabled zones.
 
 Following message was printed if zone e.test was disabled and LDAP
 contained zones test and e.test:
 update_zone (psearch) failed for 'idnsName=e.test,cn=dns,dc=e,dc=org'. Zones 
 can be outdated, run `rndc reload`: partial match
 
 Signed-off-by: Petr Spacek pspa...@redhat.com
 ---
  src/ldap_helper.c | 5 ++---
  1 file changed, 2 insertions(+), 3 deletions(-)
 
 diff --git a/src/ldap_helper.c b/src/ldap_helper.c
 index 
 199b345bb604c30bfa8a3690afc844ca8b264e89..d4bb6db10b0e79f8777fde3c5f344298af87ce56
  100644
 --- a/src/ldap_helper.c
 +++ b/src/ldap_helper.c
 @@ -815,10 +815,9 @@ ldap_delete_zone2(ldap_instance_t *inst, dns_name_t 
 *name, isc_boolean_t lock)
   }
  
   result = zr_get_zone_ptr(inst-zone_register, name, zone);
 - if (result == ISC_R_NOTFOUND) {
 + if (result == ISC_R_NOTFOUND || result == DNS_R_PARTIALMATCH) {
   log_debug(1, zone '%s' not found in zone register, 
 zone_name_char);
 - result = ISC_R_SUCCESS;
 - goto cleanup;
 + CLEANUP_WITH(ISC_R_SUCCESS);
   } else if (result != ISC_R_SUCCESS)
   goto cleanup;
  
 -- 
 1.7.11.4
 


-- 
Adam Tkac, Red Hat, Inc.

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH 0071] Fix potential crash caused by failing zone_register allocation.

[Adam Tkac]

On Tue, Oct 02, 2012 at 03:21:08PM +0200, Petr Spacek wrote:
 Hello,
 
 Fix potential crash caused by failing zone_register allocation.
 
 Problematic call flow:
 new_ldap_instance - zr_create (returns failure) -
 destroy_ldap_instance - zr_get_rbt (*crash*)

Ack

 From 9d96a9c4a4ac5b592ed5874132e0618b1b259de0 Mon Sep 17 00:00:00 2001
 From: Petr Spacek pspa...@redhat.com
 Date: Tue, 2 Oct 2012 15:16:27 +0200
 Subject: [PATCH] Fix potential crash caused by failing zone_register
  allocation.
 
 Signed-off-by: Petr Spacek pspa...@redhat.com
 ---
  src/ldap_helper.c | 7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)
 
 diff --git a/src/ldap_helper.c b/src/ldap_helper.c
 index 
 38d86afa521dcf0e6b58ebb38635ff0fffbedd2a..629c76732c86af2a614e589a5afff18136068a66
  100644
 --- a/src/ldap_helper.c
 +++ b/src/ldap_helper.c
 @@ -516,7 +516,7 @@ destroy_ldap_instance(ldap_instance_t **ldap_instp)
  {
   ldap_instance_t *ldap_inst;
   dns_rbtnodechain_t chain;
 - dns_rbt_t *rbt;
 + dns_rbt_t *rbt = NULL;
   isc_result_t result = ISC_R_SUCCESS;
   const char *db_name;
  
 @@ -530,7 +530,10 @@ destroy_ldap_instance(ldap_instance_t **ldap_instp)
*
* NOTE: This should be probably done in zone_register.c
*/
 - rbt = zr_get_rbt(ldap_inst-zone_register);
 + if (ldap_inst-zone_register != NULL)
 + rbt = zr_get_rbt(ldap_inst-zone_register);
 + if (rbt == NULL)
 + result = ISC_R_NOTFOUND;
  
   /* Potentially ISC_R_NOSPACE can occur. Destroy codepath has no way to
* return errors, so kill BIND.
 -- 
 1.7.11.4
 


-- 
Adam Tkac, Red Hat, Inc.

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH 0076] Fix crashes on BIND reload caused by improper error handling during new zone addition

[Adam Tkac]

On Fri, Oct 05, 2012 at 05:00:14PM +0200, Petr Spacek wrote:
 Hello,
 
 Fix crashes on BIND reload caused by improper error handling
 during new zone addition.
 
 Crash can be triggered by invalid query/transfer/update ACLs
 or potentially by error in zr_get_zone_ptr().
 
 I found this problem during PATCH 75 testing, so there is a new ticket:
 https://fedorahosted.org/bind-dyndb-ldap/ticket/93

Ack

 From d0e958cac75035b212f87f00fade080b025d0a23 Mon Sep 17 00:00:00 2001
 From: Petr Spacek pspa...@redhat.com
 Date: Fri, 5 Oct 2012 14:41:57 +0200
 Subject: [PATCH] Fix crashes on BIND reload caused by improper error handling
  during new zone addition.
 
 Crash can be triggered by invalid query/transfer/update ACLs
 or potentially by error in zr_get_zone_ptr().
 
 https://fedorahosted.org/bind-dyndb-ldap/ticket/93
 
 Signed-off-by: Petr Spacek pspa...@redhat.com
 ---
  src/ldap_helper.c | 14 --
  1 file changed, 12 insertions(+), 2 deletions(-)
 
 diff --git a/src/ldap_helper.c b/src/ldap_helper.c
 index 
 d4bb6db10b0e79f8777fde3c5f344298af87ce56..0e1cf6f7a6986db126aaa5329dbe9abbc98c8bf4
  100644
 --- a/src/ldap_helper.c
 +++ b/src/ldap_helper.c
 @@ -1031,6 +1031,7 @@ ldap_parse_zoneentry(ldap_entry_t *entry, 
 ldap_instance_t *inst)
   isc_result_t result;
   isc_boolean_t unlock = ISC_FALSE;
   isc_boolean_t publish = ISC_FALSE;
 + isc_boolean_t published = ISC_FALSE;
   isc_task_t *task = inst-task;
   isc_uint32_t ldap_serial;
   isc_uint32_t zr_serial; /* SOA serial value from in-memory zone 
 register */
 @@ -1074,12 +1075,13 @@ ldap_parse_zoneentry(ldap_entry_t *entry, 
 ldap_instance_t *inst)
  
   /* Check if we are already serving given zone */
   result = zr_get_zone_ptr(inst-zone_register, name, zone);
 - if (result != ISC_R_SUCCESS) { /* TODO: What about other errors? */
 + if (result == ISC_R_NOTFOUND || result == DNS_R_PARTIALMATCH) {
   CHECK(create_zone(inst, name, zone));
   CHECK(zr_add_zone(inst-zone_register, zone, dn));
   publish = ISC_TRUE;
   log_debug(2, created zone %p: %s, zone, dn);
 - }
 + } else if (result != ISC_R_SUCCESS)
 + CLEANUP_WITH(result);
  
   log_debug(2, Setting SSU table for %p: %s, zone, dn);
   /* Get the update policy and update the zone with it. */
 @@ -1119,6 +1121,7 @@ ldap_parse_zoneentry(ldap_entry_t *entry, 
 ldap_instance_t *inst)
   if (publish) {
   /* Everything is set correctly, publish zone */
   CHECK(publish_zone(inst, zone));
 + published = ISC_TRUE;
   }
  
   /*
 @@ -1178,6 +1181,13 @@ ldap_parse_zoneentry(ldap_entry_t *entry, 
 ldap_instance_t *inst)
   }
  
  cleanup:
 + if (publish  !published) { /* Failure in ACL parsing or so. */
 + log_error_r(zone '%s': publishing failed, rolling back due to,
 + entry-dn);
 + result = zr_del_zone(inst-zone_register, name);
 + if (result != ISC_R_SUCCESS)
 + log_error_r(zone '%s': rollback failed, entry-dn);
 + }
   if (unlock)
   isc_task_endexclusive(task);
   if (dns_name_dynamic(name))
 -- 
 1.7.11.4
 


-- 
Adam Tkac, Red Hat, Inc.

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH 0078] Use automatic connection management in LDAP modification code to prevent potential deadlock

[Adam Tkac]

On Mon, Oct 08, 2012 at 04:46:54PM +0200, Petr Spacek wrote:
 Hello,
 
 Use automatic connection management in LDAP modification code to
 prevent potential deadlock.
 
 Without this patch the plugin will deadlock when modify_ldap_common()
 is called with PTR synchronization enabled and only single
 connection is available in the connection pool.

Nack

If I read the patch correctly, it leaves unused ldap_conn parameters in
ldap_modify_do() and modify_soa_record() functions.

Those params are always NULL so they can be safely removed. Please also remove
the autoconn variable from ldap_modify_do()

Regards, Adam

 From 5ad686a95510b1584c85d672ec845b27504f746c Mon Sep 17 00:00:00 2001
 From: Petr Spacek pspa...@redhat.com
 Date: Mon, 8 Oct 2012 16:41:40 +0200
 Subject: [PATCH] Use automatic connection management in LDAP modification
  code to prevent potential deadlock.
 
 Without this patch the plugin will deadlock when modify_ldap_common()
 is called with PTR synchronization enabled and only single
 connection is available in the connection pool.
 
 Signed-off-by: Petr Spacek pspa...@redhat.com
 ---
  src/ldap_helper.c | 11 ---
  1 file changed, 4 insertions(+), 7 deletions(-)
 
 diff --git a/src/ldap_helper.c b/src/ldap_helper.c
 index 
 f8df1b29871c28a1eeecfa93d5d91edd1aee3944..03adb83bdc34593ec527facd3e3fc60755a4de22
  100644
 --- a/src/ldap_helper.c
 +++ b/src/ldap_helper.c
 @@ -2593,7 +2593,6 @@ modify_ldap_common(dns_name_t *owner, ldap_instance_t 
 *ldap_inst,
  {
   isc_result_t result;
   isc_mem_t *mctx = ldap_inst-mctx;
 - ldap_connection_t *ldap_conn = NULL;
   ld_string_t *owner_dn = NULL;
   LDAPMod *change[3] = { NULL };
   LDAPMod *change_ptr = NULL;
 @@ -2630,8 +2629,6 @@ modify_ldap_common(dns_name_t *owner, ldap_instance_t 
 *ldap_inst,
  
   CHECK(dn_to_dnsname(mctx, zone_dn, zone_name, NULL));
  
 - CHECK(ldap_pool_getconnection(ldap_inst-pool, ldap_conn));
 -
   result = zr_get_zone_settings(ldap_inst-zone_register, zone_name,
 zone_settings);
   if (result != ISC_R_SUCCESS) {
 @@ -2655,7 +2652,7 @@ modify_ldap_common(dns_name_t *owner, ldap_instance_t 
 *ldap_inst,
   CHECK(discard_from_cache(cache, owner));
  
   if (rdlist-type == dns_rdatatype_soa) {
 - result = modify_soa_record(ldap_inst, ldap_conn, 
 str_buf(owner_dn),
 + result = modify_soa_record(ldap_inst, NULL, str_buf(owner_dn),
  HEAD(rdlist-rdata));
   goto cleanup;
   }
 @@ -2666,7 +2663,7 @@ modify_ldap_common(dns_name_t *owner, ldap_instance_t 
 *ldap_inst,
   CHECK(ldap_rdttl_to_ldapmod(mctx, rdlist, change[1]));
   }
   
 - CHECK(ldap_modify_do(ldap_inst, ldap_conn, str_buf(owner_dn), change, 
 delete_node));
 + CHECK(ldap_modify_do(ldap_inst, NULL, str_buf(owner_dn), change, 
 delete_node));
  
   /* Keep the PTR of corresponding A/ record synchronized. */
   if (rdlist-type == dns_rdatatype_a || rdlist-type == 
 dns_rdatatype_) {
 @@ -2824,13 +2821,13 @@ modify_ldap_common(dns_name_t *owner, ldap_instance_t 
 *ldap_inst,
   change_ptr = NULL;
  
   /* Modify PTR record. */
 - CHECK(ldap_modify_do(ldap_inst, ldap_conn, 
 str_buf(owner_dn_ptr), change, delete_node));
 + CHECK(ldap_modify_do(ldap_inst, NULL, str_buf(owner_dn_ptr),
 +  change, delete_node));
   (void) discard_from_cache(ldap_instance_getcache(ldap_inst),
 dns_fixedname_name(ptr_name));
   }
   
  cleanup:
 - ldap_pool_putconnection(ldap_inst-pool, ldap_conn);
   str_destroy(owner_dn_ptr);
   str_destroy(owner_dn);
   str_destroy(str_ptr);
 -- 
 1.7.11.4
 


-- 
Adam Tkac, Red Hat, Inc.

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] Cannot create signed Firefox extension on a replica

[Petr Viktorin]

While working on https://fedorahosted.org/freeipa/ticket/3150, I came 
across this scenario:


I have a 2.2 master I don't want to upgrade. I want to create a 3.0 
replica from it.


I found that when creating the replica file, the Signing-Cert (used to 
sign the browser config .jar and, newly, .xpi) is not included. It never 
leaves the original master. And the original master can't sign the 
extension because it's 2.2, so it only knows how to sign the old .jar 
(and only on install).


Similarly, 2.2 replicas that get upgraded to 3.0 can't sign the new 
extension. And they don't even know which server has the original 
Signing-Cert, so even a trick like SSHing to it to steal the cert won't 
work.


Old 2.2 installations where the original master was destroyed won't have 
the Signing-Cert at all any more.


Am I right? I must admit my grasp of the code could be better.


Can I generate a new signing cert in replica-install to sign the 
extension? Would that clash with the old one (and with ones from other 
replicas)?

Can we distribute an unsigned extension?


--
Petr³

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 321 Move CRL publish directory to IPA owned directory

[Martin Kosek]

On 10/08/2012 09:29 PM, Rob Crittenden wrote:
 Martin Kosek wrote:
 - Original Message -
 From: Rob Crittenden rcrit...@redhat.com
 To: Martin Kosek mko...@redhat.com
 Cc: freeipa-devel@redhat.com
 Sent: Monday, October 8, 2012 8:18:47 PM
 Subject: Re: [Freeipa-devel] [PATCH] 321 Move CRL publish directory to IPA
 owned directory

 Martin Kosek wrote:
 Currently, CRL files are being exported to /var/lib/pki-ca
 sub-directory, which is then served by httpd to clients. However,
 this approach has several disadvantages:
* We depend on pki-ca directory structure and relevant
permissions.
  If pki-ca changes directory structure or permissions on
  upgrade,
  IPA may break. This is also a root cause of the latest error,
  where
  the pki-ca directory does not have X permission for others and
  CRL
  publishing by httpd breaks.
* Since the directory is not static and is generated during
  ipa-server-install, RPM upgrade of IPA packages report errors
  when
  defining SELinux policy for these directories.

 Move CRL publish directory to /var/lib/ipa/pki-ca/publish (common
 for
 both dogtag 9 and 10) which is created on RPM upgrade, i.e. SELinux
 policy
 configuration does not report any error. The new CRL publish
 directory
 is used for both new IPA installs and upgrades, where contents of
 the directory (CRLs) is first migrated to the new location and then
 the
 actual configuration change is made.

 https://fedorahosted.org/freeipa/ticket/3144


 ---

 We may choose to postpone this patch to later version, it is quite
 disruptive.
 I can produce a hotfix in that case, which would only fix the
 permission of the
 pki-ca directory.

 Martin

 This looks good, just a couple of questions.

 Should the old files be removed?

 Yeah, this is something I wonder about too. One one side, users may be get
 confused if there are 2 publish directories with the same content (a least
 until a next CRL generation). But on the other side, I was cautious not to
 delete something important in a case when something goes wrong. But maybe I
 am just being over-cautious and we can delete it, or maybe move directory to
 publish.deleted. In a worst case scenario, CRLs should be generated again,
 in about 4 hours...


 Should some error handling be added around the copy to ensure it is
 successful? This would blow up if the disk was full, for example.

 I think this is covered, I have there a try..except clause for this case:

 +for f in crl_files:
 +try:
 +copy_crl_file(f)
 +except Exception, e:
 +root_logger.error('Cannot move CRL file to new directory:
 %s', e)

 Just the exception is caught on a higher level and error is reported to user.
 Not sure what to do in this case - report error to user, do not change the
 location and ask user to resolve the error? Or just report error and continue
 with CRL publish directory change as I do currently?

 Martin

 
 Ah, I was looking at too low a level.
 
 I think this is fine. I wonder if we should log/document somewhere in big
 flashing letters that the stuff has been moved. It is rather clear in the logs
 now, I suppose, if you look carefully.
 
 I guess it isn't really that big a deal now since we just have server certs. 
 It
 would take a whole ton of revocations to grow the CRLs that quickly, so maybe
 my concerns are overblown.
 
 rob

CRL size may quickly grown for someone who rapidly adds/removes client hosts or
services as we revoke such certificates with 4 - superseded.. About the user
info - maybe we should also allow output of ipa-upgradeconfig's stderr stream
as we did with ipa-ldap-updater. This way, user would receive error message
when CRL copy operation fails.

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] [PATCH] 221 Add mime type to httpd ipa.conf for xpi exetension

[Petr Vobornik]

Some configuration doesn't give proper mime type to xpi files. This 
patch explicitly sets it.


https://fedorahosted.org/freeipa/ticket/3094
--
Petr Vobornik
From f35fd8856fdb9e16361b977aba62266c71c9e76f Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Tue, 9 Oct 2012 10:17:16 +0200
Subject: [PATCH] Add mime type to httpd ipa.conf for xpi exetension

Some configuration doesn't give proper mime type to xpi files. This patch explicitly sets it.

https://fedorahosted.org/freeipa/ticket/3094
---
 install/conf/ipa.conf | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/install/conf/ipa.conf b/install/conf/ipa.conf
index ed50a35b58a7c379e0dcd737162d5c9b00c3e3f0..5cd1d8c59ae06a0437e64911040cc726e7b7317f 100644
--- a/install/conf/ipa.conf
+++ b/install/conf/ipa.conf
@@ -1,5 +1,5 @@
 #
-# VERSION 8 - DO NOT REMOVE THIS LINE
+# VERSION 9 - DO NOT REMOVE THIS LINE
 #
 # This file may be overwritten on upgrades.
 #
@@ -20,6 +20,7 @@ LimitRequestFieldSize 10
 
 # This is required so the auto-configuration works with Firefox 2+
 AddType application/java-archivejar
+AddType application/x-xpinstall xpi
 
 
 # FIXME: WSGISocketPrefix is a server-scope directive.  The mod_wsgi package
-- 
1.7.11.4

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Cannot create signed Firefox extension on a replica

[Alexander Bokovoy]

On Tue, 09 Oct 2012, Petr Viktorin wrote:
While working on https://fedorahosted.org/freeipa/ticket/3150, I came 
across this scenario:


I have a 2.2 master I don't want to upgrade. I want to create a 3.0 
replica from it.


I found that when creating the replica file, the Signing-Cert (used 
to sign the browser config .jar and, newly, .xpi) is not included. It 
never leaves the original master. And the original master can't sign 
the extension because it's 2.2, so it only knows how to sign the old 
.jar (and only on install).


Similarly, 2.2 replicas that get upgraded to 3.0 can't sign the new 
extension. And they don't even know which server has the original 
Signing-Cert, so even a trick like SSHing to it to steal the cert 
won't work.


Old 2.2 installations where the original master was destroyed won't 
have the Signing-Cert at all any more.


Am I right? I must admit my grasp of the code could be better.


Can I generate a new signing cert in replica-install to sign the 
extension? Would that clash with the old one (and with ones from 
other replicas)?

Can we distribute an unsigned extension?
We can distribute it unsigned. 


But your question sparkled another one: should we backport
firefox extension work to 2.2? Since it is client-side that gets
upgraded to Firefox 15, chances are high that soon existing 2.2 installs
would not be manageable via browser on newer clients unless manually
configured.

--
/ Alexander Bokovoy

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 221 Add mime type to httpd ipa.conf for xpi exetension

[Alexander Bokovoy]

On Tue, 09 Oct 2012, Petr Vobornik wrote:
Some configuration doesn't give proper mime type to xpi files. This 
patch explicitly sets it.


https://fedorahosted.org/freeipa/ticket/3094
--
Petr Vobornik



From f35fd8856fdb9e16361b977aba62266c71c9e76f Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Tue, 9 Oct 2012 10:17:16 +0200
Subject: [PATCH] Add mime type to httpd ipa.conf for xpi exetension

Some configuration doesn't give proper mime type to xpi files. This patch 
explicitly sets it.

https://fedorahosted.org/freeipa/ticket/3094

ACK.

--
/ Alexander Bokovoy

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Cannot create signed Firefox extension on a replica

[Petr Vobornik]

On 10/09/2012 01:25 PM, Petr Viktorin wrote:

While working on https://fedorahosted.org/freeipa/ticket/3150, I came
across this scenario:

I have a 2.2 master I don't want to upgrade. I want to create a 3.0
replica from it.

I found that when creating the replica file, the Signing-Cert (used to
sign the browser config .jar and, newly, .xpi) is not included. It never
leaves the original master. And the original master can't sign the
extension because it's 2.2, so it only knows how to sign the old .jar
(and only on install).

Similarly, 2.2 replicas that get upgraded to 3.0 can't sign the new
extension. And they don't even know which server has the original
Signing-Cert, so even a trick like SSHing to it to steal the cert won't
work.

Old 2.2 installations where the original master was destroyed won't have
the Signing-Cert at all any more.

Am I right? I must admit my grasp of the code could be better.


Can I generate a new signing cert in replica-install to sign the
extension? Would that clash with the old one (and with ones from other
replicas)?
Can we distribute an unsigned extension?




Just some additional info:
 * The extension doesn't have to be signed to be installable. It just 
shows that the source is not verified.
 * The signing cert has a weird label (hostname?) Object Signing Cert 
which is really confusing when used in Firefox dialog while installing 
the extension
 * The signing cert doesn't auto renew 
https://fedorahosted.org/freeipa/ticket/3032


--
Petr Vobornik

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH 0076] Fix crashes on BIND reload caused by improper error handling during new zone addition

[Petr Spacek]

On 10/09/2012 01:15 PM, Adam Tkac wrote:

On Fri, Oct 05, 2012 at 05:00:14PM +0200, Petr Spacek wrote:

Hello,

 Fix crashes on BIND reload caused by improper error handling
 during new zone addition.

 Crash can be triggered by invalid query/transfer/update ACLs
 or potentially by error in zr_get_zone_ptr().

I found this problem during PATCH 75 testing, so there is a new ticket:
https://fedorahosted.org/bind-dyndb-ldap/ticket/93


Ack


Pushed to master:
6a86b1fd08ca37c64435690efd49115c828871a9

Petr^2 Spacek




 From d0e958cac75035b212f87f00fade080b025d0a23 Mon Sep 17 00:00:00 2001
From: Petr Spacek pspa...@redhat.com
Date: Fri, 5 Oct 2012 14:41:57 +0200
Subject: [PATCH] Fix crashes on BIND reload caused by improper error handling
  during new zone addition.


___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH 0074] Fix zone removal in persistent search update_zone()

[Petr Spacek]

On 10/09/2012 01:08 PM, Adam Tkac wrote:

On Fri, Oct 05, 2012 at 01:15:13PM +0200, Petr Spacek wrote:

Hello,

Fix zone removal in persistent search update_zone().

Without this patch any zone removed through ipa dnszone-del will
remain active and will return SERVFAILs.


Ack


Pushed to master:
7edccd62fd9c03ba1431a2a4595072938a58d986

Petr^2 Spacek




 From e09eebf3c370ff4106013cdeda10a80782e26611 Mon Sep 17 00:00:00 2001
From: Petr Spacek pspa...@redhat.com
Date: Fri, 5 Oct 2012 13:02:37 +0200
Subject: [PATCH] Fix zone removal in persistent search update_zone() handler.


___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH 0075] Prevent misleading partial match error messages for disabled zones

[Petr Spacek]

On 10/09/2012 01:09 PM, Adam Tkac wrote:

On Fri, Oct 05, 2012 at 01:45:42PM +0200, Petr Spacek wrote:

Hello,

 Prevent misleading partial match error messages for disabled zones.

 Following message was printed if zone e.test was disabled and LDAP
 contained zones test and e.test:
 update_zone (psearch) failed for
'idnsName=e.test,cn=dns,dc=e,dc=org'. Zones can be outdated, run
`rndc reload`: partial match


Ack


Pushed to master:
8b45aeadbf75b732bd6c95151d762d8fe89d9ea8

Petr^2 Spacek




 From e7f7a7d6e4fb3c9e47bac22d3291d09aa3d885ab Mon Sep 17 00:00:00 2001
From: Petr Spacek pspa...@redhat.com
Date: Fri, 5 Oct 2012 13:37:18 +0200
Subject: [PATCH] Prevent misleading partial match error messages for
  disabled zones.


___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH 0071] Fix potential crash caused by failing zone_register allocation.

[Petr Spacek]

On 10/09/2012 01:12 PM, Adam Tkac wrote:

On Tue, Oct 02, 2012 at 03:21:08PM +0200, Petr Spacek wrote:

Hello,

Fix potential crash caused by failing zone_register allocation.

Problematic call flow:
new_ldap_instance - zr_create (returns failure) -
destroy_ldap_instance - zr_get_rbt (*crash*)


Ack


Pushed to master:
01bfbeb77db85780312dadddcda7d9979ef13633

Petr^2 Spacek




 From 9d96a9c4a4ac5b592ed5874132e0618b1b259de0 Mon Sep 17 00:00:00 2001
From: Petr Spacek pspa...@redhat.com
Date: Tue, 2 Oct 2012 15:16:27 +0200
Subject: [PATCH] Fix potential crash caused by failing zone_register
  allocation.



___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 221 Add mime type to httpd ipa.conf for xpi exetension

[Martin Kosek]

On 10/09/2012 01:52 PM, Alexander Bokovoy wrote:
 On Tue, 09 Oct 2012, Petr Vobornik wrote:
 Some configuration doesn't give proper mime type to xpi files. This patch
 explicitly sets it.

 https://fedorahosted.org/freeipa/ticket/3094
 -- 
 Petr Vobornik
 
 From f35fd8856fdb9e16361b977aba62266c71c9e76f Mon Sep 17 00:00:00 2001
 From: Petr Vobornik pvobo...@redhat.com
 Date: Tue, 9 Oct 2012 10:17:16 +0200
 Subject: [PATCH] Add mime type to httpd ipa.conf for xpi exetension

 Some configuration doesn't give proper mime type to xpi files. This patch
 explicitly sets it.

 https://fedorahosted.org/freeipa/ticket/3094
 ACK.
 

Pushed to master, ipa-3-0.

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 321 Move CRL publish directory to IPA owned directory

[Martin Kosek]

On 10/09/2012 03:48 PM, Rob Crittenden wrote:
 Martin Kosek wrote:
 On 10/08/2012 09:29 PM, Rob Crittenden wrote:
 Martin Kosek wrote:
 - Original Message -
 From: Rob Crittenden rcrit...@redhat.com
 To: Martin Kosek mko...@redhat.com
 Cc: freeipa-devel@redhat.com
 Sent: Monday, October 8, 2012 8:18:47 PM
 Subject: Re: [Freeipa-devel] [PATCH] 321 Move CRL publish directory to IPA
 owned directory

 Martin Kosek wrote:
 Currently, CRL files are being exported to /var/lib/pki-ca
 sub-directory, which is then served by httpd to clients. However,
 this approach has several disadvantages:
 * We depend on pki-ca directory structure and relevant
 permissions.
   If pki-ca changes directory structure or permissions on
   upgrade,
   IPA may break. This is also a root cause of the latest error,
   where
   the pki-ca directory does not have X permission for others and
   CRL
   publishing by httpd breaks.
 * Since the directory is not static and is generated during
   ipa-server-install, RPM upgrade of IPA packages report errors
   when
   defining SELinux policy for these directories.

 Move CRL publish directory to /var/lib/ipa/pki-ca/publish (common
 for
 both dogtag 9 and 10) which is created on RPM upgrade, i.e. SELinux
 policy
 configuration does not report any error. The new CRL publish
 directory
 is used for both new IPA installs and upgrades, where contents of
 the directory (CRLs) is first migrated to the new location and then
 the
 actual configuration change is made.

 https://fedorahosted.org/freeipa/ticket/3144


 ---

 We may choose to postpone this patch to later version, it is quite
 disruptive.
 I can produce a hotfix in that case, which would only fix the
 permission of the
 pki-ca directory.

 Martin

 This looks good, just a couple of questions.

 Should the old files be removed?

 Yeah, this is something I wonder about too. One one side, users may be get
 confused if there are 2 publish directories with the same content (a least
 until a next CRL generation). But on the other side, I was cautious not to
 delete something important in a case when something goes wrong. But maybe I
 am just being over-cautious and we can delete it, or maybe move directory 
 to
 publish.deleted. In a worst case scenario, CRLs should be generated 
 again,
 in about 4 hours...


 Should some error handling be added around the copy to ensure it is
 successful? This would blow up if the disk was full, for example.

 I think this is covered, I have there a try..except clause for this case:

 +for f in crl_files:
 +try:
 +copy_crl_file(f)
 +except Exception, e:
 +root_logger.error('Cannot move CRL file to new directory:
 %s', e)

 Just the exception is caught on a higher level and error is reported to 
 user.
 Not sure what to do in this case - report error to user, do not change the
 location and ask user to resolve the error? Or just report error and 
 continue
 with CRL publish directory change as I do currently?

 Martin


 Ah, I was looking at too low a level.

 I think this is fine. I wonder if we should log/document somewhere in big
 flashing letters that the stuff has been moved. It is rather clear in the 
 logs
 now, I suppose, if you look carefully.

 I guess it isn't really that big a deal now since we just have server 
 certs. It
 would take a whole ton of revocations to grow the CRLs that quickly, so 
 maybe
 my concerns are overblown.

 rob

 CRL size may quickly grown for someone who rapidly adds/removes client hosts 
 or
 services as we revoke such certificates with 4 - superseded.. About the user
 info - maybe we should also allow output of ipa-upgradeconfig's stderr stream
 as we did with ipa-ldap-updater. This way, user would receive error message
 when CRL copy operation fails.

 Martin

 
 I think the patch is fine as-is. Can you open a new ticket on a mechanism to
 alert the user to upgrade things to review?

https://fedorahosted.org/freeipa/ticket/3157

 
 ACK
 
 rob
 

Rebased and pushed to master, ipa-3-0.

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 1055 update audit cert renewal time

[Martin Kosek]

On 09/21/2012 12:37 AM, yi zhang wrote:
 On 09/20/2012 02:58 PM, Rob Crittenden wrote:
 Updated patch. The value of
 policyset.caLogSigningSet.2.constraint.params.range needs to be bumped to 720
 as well.
 I keep doing my test and let everyone know the test result.
 
 Yi
 

Hello Yi, any updates with your certificate tests with regards to this patch?

Thanks,
Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 1059 single CRL generator

[Rob Crittenden]

Martin Kosek wrote:

On 10/04/2012 06:17 PM, Rob Crittenden wrote:

This changes the way IPA generates CRLs for new installs only.

The first master installed is configured as the CRL generator. An entry is
added to cn=masters that designates it.

When a replica is installed it queries this entry so it knows where to forward
CRL requests. CRL files are not available on cloned CAs (so /ipa/crl will
return not found). It is possible to get a CRL directly from the clone CA via
http://hostname:9180/ca/ee/ca/getCRL?op=getCRLcrlIssuingPoint=MasterCRL

rob


I tested new IPA server + replica with your patch and the CRL was now generated
only on the CRL master. I also tried OCSP (though this may not be relevant) and
it worked for me too.

1) I do not understand the following block in set_crl_master(self, suffix):

+try:
+self.admin_conn.addEntry(entry)
+except ldap.ALREADY_EXISTS, e:
+root_logger.debug(failed to set CA as CRL generator)
+raise e

- when we hit ldap.ALREADY_EXISTS, we are actually OK because cn=CRL is set, 
right?
- AFAIK, addEntry should  return our errors, i.e. errors.DuplicateEntry
- s/raise e/raise/

I think you may have wanted to rather catch for more general LDAP error and
then report a real error and not just a debug note.

2) In get_crl_master:

+except Exception, e:
+root_logger.debug(Could not connect to the Directory Server on
%s: %s % (master_host, str(e)))
+raise e

s/raise e/raise/

+except errors.NotFound, e:
+root_logger.debug(failed to find CA CRL generator)
+self.crl_master = None

- e is actually not used, except errors.NotFound would be enough

3) Majorish issue I hit with the actual CRL publishing on our server (F17). I
always get 403 Forbidden error when trying to download CRL from the CRL master:

# wget --ca-certificate /etc/ipa/ca.crt https://`hostname`/ipa/crl/MasterCRL.bin
--2012-10-05 03:32:58--
https://vm-120.idm.lab.bos.redhat.com/ipa/crl/MasterCRL.bin
Resolving vm-120.idm.lab.bos.redhat.com... 10.16.78.120
Connecting to vm-120.idm.lab.bos.redhat.com|10.16.78.120|:443... connected.
HTTP request sent, awaiting response... 403 Forbidden
2012-10-05 03:32:58 ERROR 403: Forbidden.

I tracked the problem down to too strict permission on /var/lib/pki-ca
directory which is being published by httpd which does not have access to it:

# ll /var/lib/pki-ca

drwxrwx---. 11 pkiuser pkiuser 4096 Oct  5 03:00 pki-ca

When I fixed the permission:
# chmod o+x /var/lib/pki-ca/

I was able to get pass the Forbidden error and actually retrieved the CRL.
Adding Ade on CC list to follow on this permission issue.


I was thinking about usability of this new approach, we may want to make user
life easier in a perspective of CRL master managing. I have following
enhancements in mind:

- mark CRL master in ipa-replica-manage list, or ipa-csreplica-manage list:

# ipa-csreplica-manage list
Directory Manager password:

vm-065.idm.lab.bos.redhat.com: master [CRL]
vm-120.idm.lab.bos.redhat.com: master

- when removing master with CRL by ipa-replica-manage del we should warn user
and inform him what he should do next to amend the situation. I am thinking
about 2 new commands for ipa-csreplica-manage:

* ipa-csreplica-manage crl-promote
   - promote current master as the new CRL master, enable CRL generation in
CS.cfg, mark master as the new CRL master in cn=masters
* ipa-csreplica-manage crl-update
   - update CS.cfg of current CA replica and point master.ca.agent.* to current
CRL master

I can work on those enhancements if we agree on them.

Martin



Andrew provided some feedback out-of-band and my solution was overly 
complex. Here is a much simpler patch which does away with all the 
hand-waving around knowing who the CRL generator is.


rob
From 06153bc8b809ef52c2999657e280e424b1135552 Mon Sep 17 00:00:00 2001
From: Rob Crittenden rcrit...@redhat.com
Date: Tue, 9 Oct 2012 10:40:20 -0400
Subject: [PATCH] Configure the initial CA as the CRL generator.

Any installed clones will have CRL generation explicitly disabled.
It is a manual process to make a different CA the CRL generator.
There should be only one.

https://fedorahosted.org/freeipa/ticket/3051
---
 ipaserver/install/cainstance.py | 12 
 1 file changed, 12 insertions(+)

diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py
index c37c261f2933f5c9c4eb3b2133fca638716eb59d..30a8274a6bff874e6ff50f1f090c41074cca662d 100644
--- a/ipaserver/install/cainstance.py
+++ b/ipaserver/install/cainstance.py
@@ -1238,6 +1238,18 @@ class CAInstance(service.Service):
 'https://%s/ipa/crl/MasterCRL.bin' % ipautil.format_netloc(self.fqdn),
 quotes=False, separator='=')
 
+# If we are the initial master then we are the CRL generator, otherwise
+# we point to that master for CRLs.
+if not self.clone:
+# These next two are defaults, but I want to be 

[Freeipa-devel] [Fwd: [Pki-announce] Announcing Dogtag 10.0.0 beta 1 release]

[Ade Lee]

---BeginMessage---
The Dogtag team is proud to announce version Dogtag v10.0.0 beta 1.

A build is available for Fedora 18 in the updates-testing repo.  Please
try it out and provide karma to move it to the F18 stable repo.

Daily developer builds for Fedora 17 and 18 are available at
http://nkinder.fedorapeople.org/dogtag-devel/fedora/

== Build Versions ==
pki-core-10.0.0-0.43.b1.fc18
pki-ra-10.0.0-0.9.b1.fc18
pki-tps-10.0.0-0.9.b1.fc18
dogtag-pki-10.0.0-0.10.b1.fc18
dogtag-pki-theme-10.0.0-0.2.b1.fc18
pki-console-10.0.0-0.8.b1.fc18

== Highlights since Dogtag v. 10.0.0 alpha 2 (Oct 1 2012) ==

* Merged pki-silent into pki-server.
* Added Provides to packages replacing obsolete packages.
* Added needed link for updated d9 - d10 instances. Found in IPA
  testing.
* Backed up CS.cfg before upgrading from d9 - d10
* New selinux policy for all components.  The Java components now take
  advantage of a tomcat domain defined in the base selinux policy, and 
  the RA/TPS policies have been cleaned up considerably.  The policy that is
  now delivered is very close to the final version that will be delivered
  in the base policy.  That will be a deliverable for beta 2.
* Selinux context for startup scripts for all components set so that
  runcon is not required.
* Cleaned up lock and pid files generation and removal for java
  processes.
* Rebuilt packages against the latest F18 base selinux policy packages
  to resolve an issue in installing pki-selinux due to removal of a
  boolean in F18 base selinux policies.  This issue was reported by IPA.

== Notes for F17 ==
* F17 requires an selinux version that is still in updates-testing.
Enable this repo to upgrade accordingly.

* F17 tomcat has a bug in the way it handles pid files.
https://bugzilla.redhat.com/show_bug.cgi?id=863307.  Prior to creating
an instance, you need to perform the following workaround:

In the file, /usr/sbin/tomcat-sysd, change the line:
export CATALINA_PID=/var/run/${NAME}.pid
to: 
export CATALINA_PID=${CATALINA_PID:-/var/run/${NAME}.pid}

== Feedback ==

Please provide comments, bugs and other feedback via the pki-devel 
mailing list: http://www.redhat.com/mailman/listinfo/pki-devel

== Detailed Changelog ==

Ade Lee (11):
5ef10ba Update selinux-policy version to fix error from latest policy
81596ba fix spec typo
919434b Added build requires for version of selinux-policy-devel
5014442 Update release to b1
9cd11bc Fix name of CS.cfg backup file
63237d3 Backup CS.cfg before d10 update
da73f97 Changes to start pki_ra and pki_tps in correct context
6e79c7c add selinux context for pkidaemon, remove unneeded pid/lock code
f542060 move common policy into tps, ra templates
dbc6dec Use the tomcat selinux domain for the Java processes
3d5dc3b Added needed link for updated d9 - d10 instances

Endi Dewata (3):
23c70bd Merged pki-silent into pki-server.
79a3d82 Renamed shared folder to server.
753d55e Added Provides to packages replacing obsolete packages. 
 


___
Pki-announce mailing list
pki-annou...@redhat.com
https://www.redhat.com/mailman/listinfo/pki-announce
---End Message---
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] [PATCHES] 0086-0088 Generate Firefox extension on upgrades

[Petr Viktorin]

https://fedorahosted.org/freeipa/ticket/3150


Patch 0086:
I found an old unused function while working on this, the patch removes it.

Patch 0087:
Replica files generated on older masters don't contain the Firefox 
extension files. Skip installing them in this case.


Patch 0088:
Servers upgraded from IPA 2.2 need the Firefox extension installed. This 
is done in ipa-upgradeconfig if they're missing.
I made the setup_firefox_extension method independent on the 
httpinstance state (which is mostly set in create_instance).
Similarly, the files are installed ipa-replica-install if they're 
missing (i.e. skipped by the previous patch).
If the Signing-Cert is not on this master, create an unsigned extension 
using the zip command. I needed to add Popen's `cwd` argument to 
ipautil.run() to get the right filenames out of zip.


The patches add copy_template_file and copy_file_if_exists utilities 
I've written for some of my WIP patches, expect me to use them more when 
I get time to work on the installer code.


--
Petr³
From 2e81d46f2481c34cf58b3c66cdb6850b025a5488 Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Tue, 9 Oct 2012 04:10:06 -0400
Subject: [PATCH] ipa-upgradeconfig: Remove the upgrade_httpd_selinux function

This function was never called from anywhere.
---
 install/tools/ipa-upgradeconfig | 9 -
 1 file changed, 9 deletions(-)

diff --git a/install/tools/ipa-upgradeconfig b/install/tools/ipa-upgradeconfig
index 6c0437180c2b47f4d88154741c96648975b30d34..c74ebe33d228c20508e734c7d5c9b41573145003 100644
--- a/install/tools/ipa-upgradeconfig
+++ b/install/tools/ipa-upgradeconfig
@@ -296,15 +296,6 @@ def upgrade_ipa_profile(realm):
 else:
 root_logger.debug('CA is not configured')
 
-def upgrade_httpd_selinux(fstore):
-
-Update SElinux configuration for httpd instance in the same way as the
-new server installation does.
-
-root_logger.info('[Verifying the Apache SELinux configuration]')
-http = httpinstance.HTTPInstance(fstore)
-http.configure_selinux_for_httpd()
-
 def named_enable_psearch():
 
 From IPA 3.0, persistent search is a preferred mechanism for new DNS zone
-- 
1.7.11.4

From dd5934af098648860e253c24ab8d3dc63c05f8d7 Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Mon, 8 Oct 2012 08:02:55 -0400
Subject: [PATCH] replica-install: Don't copy Firefox config extension files
 if they're not in the replica file

This allows cloning from older masters.

https://fedorahosted.org/freeipa/ticket/3150
---
 install/tools/ipa-replica-install | 7 +--
 ipaserver/install/installutils.py | 6 ++
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/install/tools/ipa-replica-install b/install/tools/ipa-replica-install
index c1679c723bc50fb318b4fa1a0ff10d6032c991b4..2bc571c2edf466d8e60121d79e7a0e17630b439b 100755
--- a/install/tools/ipa-replica-install
+++ b/install/tools/ipa-replica-install
@@ -207,8 +207,11 @@ def install_http(config, auto_redirect):
 try:
 shutil.copy(config.dir + /preferences.html, /usr/share/ipa/html/preferences.html)
 shutil.copy(config.dir + /configure.jar, /usr/share/ipa/html/configure.jar)
-shutil.copy(config.dir + /krb.js, /usr/share/ipa/html/krb.js)
-shutil.copy(config.dir + /kerberosauth.xpi, /usr/share/ipa/html/kerberosauth.xpi)
+installutils.copy_file_if_exists(
+config.dir + /krb.js, /usr/share/ipa/html/krb.js)
+installutils.copy_file_if_exists(
+config.dir + /kerberosauth.xpi,
+/usr/share/ipa/html/kerberosauth.xpi)
 except Exception, e:
 print error copying files:  + str(e)
 sys.exit(1)
diff --git a/ipaserver/install/installutils.py b/ipaserver/install/installutils.py
index 754d5fc98f3122cc82064c039236f5916eabf469..d662b63cd1b2b3844406beab73985bfbb60deb56 100644
--- a/ipaserver/install/installutils.py
+++ b/ipaserver/install/installutils.py
@@ -566,6 +566,12 @@ def rmtree(path):
 except Exception, e:
 root_logger.error('Error removing %s: %s' % (path, str(e)))
 
+
+def copy_file_if_exists(src, dest):
+if os.path.exists(src):
+shutil.copy(src, dest)
+
+
 def is_ipa_configured():
 
 Using the state and index install files determine if IPA is already
-- 
1.7.11.4

From 04bd0ba7e431804e56b91f0bfb70676b70c10fb2 Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Mon, 8 Oct 2012 07:54:47 -0400
Subject: [PATCH] Create Firefox extension on upgrade and replica-install

If the signing cert is not available, create an unsigned extension.

Add a zip dependency to the specfile.

https://fedorahosted.org/freeipa/ticket/3150
---
 freeipa.spec.in   |  4 +++
 install/tools/ipa-replica-install |  3 ++
 install/tools/ipa-upgradeconfig   | 11 +++
 ipapython/ipautil.py  | 13 ++--
 ipaserver/install/httpinstance.py | 69 

Re: [Freeipa-devel] [PATCH] 1055 update audit cert renewal time

[Martin Kosek]

On 09/20/2012 11:58 PM, Rob Crittenden wrote:
 Rob Crittenden wrote:
 The CA audit certificate is initially valid for two years but its
 profile has it renewing at six months. This bumps the value up to two
 years to match the other certificates.

 This relies on Petr's and Ade's dogtag 10 patches.
 
 Updated patch. The value of 
 policyset.caLogSigningSet.2.constraint.params.range
 needs to be bumped to 720 as well.
 
 rob
 

1) I do not see the updated patch with the described change

2) Patch needs a rebase

3) In upgrade_ipa_profile function, please rather adopt the concept of
restarting the CA just once (ca_restart variable), at the end of the
ipa-upgraceconfig. With your change, CA would be restarted at least twice -
once for audit cert renewal update and then for CRL location change.

Otherwise it works OK - profile is updated.

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCHES] 0086-0088 Generate Firefox extension on upgrades

[Petr Viktorin]

On 10/09/2012 05:16 PM, Petr Viktorin wrote:

https://fedorahosted.org/freeipa/ticket/3150


Patch 0086:
I found an old unused function while working on this, the patch removes it.

Patch 0087:
Replica files generated on older masters don't contain the Firefox
extension files. Skip installing them in this case.

Patch 0088:
Servers upgraded from IPA 2.2 need the Firefox extension installed. This
is done in ipa-upgradeconfig if they're missing.
I made the setup_firefox_extension method independent on the
httpinstance state (which is mostly set in create_instance).
Similarly, the files are installed ipa-replica-install if they're
missing (i.e. skipped by the previous patch).
If the Signing-Cert is not on this master, create an unsigned extension
using the zip command. I needed to add Popen's `cwd` argument to
ipautil.run() to get the right filenames out of zip.

The patches add copy_template_file and copy_file_if_exists utilities
I've written for some of my WIP patches, expect me to use them more when
I get time to work on the installer code.



In my previous mail I've attached an old version of patch 88. Please use 
this one. Sorry!


--
Petr³
From a19e5d1e0129a5f498b4b9c276e1e768c1c4e8ba Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Mon, 8 Oct 2012 07:54:47 -0400
Subject: [PATCH] Create Firefox extension on upgrade and replica-install

If the signing cert is not available, create an unsigned extension.

Add a zip dependency to the specfile.

https://fedorahosted.org/freeipa/ticket/3150
---
 freeipa.spec.in   |  4 +++
 install/tools/ipa-replica-install |  3 ++
 install/tools/ipa-upgradeconfig   | 11 +++
 ipapython/ipautil.py  | 17 +++---
 ipaserver/install/httpinstance.py | 69 ++-
 5 files changed, 78 insertions(+), 26 deletions(-)

diff --git a/freeipa.spec.in b/freeipa.spec.in
index 7c8314a04dbd01303c9122b4822b074bc7bbff88..b700fa6cb5606b65a2814935e7c7e7cd53f7b868 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -173,6 +173,7 @@ Requires(postun): python initscripts chkconfig
 %endif
 Requires: python-dns
 Requires: keyutils
+Requires: zip
 
 # We have a soft-requires on bind. It is an optional part of
 # IPA but if it is configured we need a way to require versions
@@ -783,6 +784,9 @@ fi
 %ghost %attr(0644,root,apache) %config(noreplace) %{_sysconfdir}/ipa/ca.crt
 
 %changelog
+* Mon Oct  9 2012 Petr Viktorin pvikt...@redhat.com - 2.99.0-48
+- Add zip dependency, needed for creating unsigned Firefox extensions
+
 * Mon Oct  1 2012 Martin Kosek mko...@redhat.com - 2.99.0-47
 - Require samba packages instead of samba4 packages obsoleted in Fedora 18 and later
 - Add libwbclient-devel BuildRequires to pick up libwbclient.h on Fedora 18 and later
diff --git a/install/tools/ipa-replica-install b/install/tools/ipa-replica-install
index 2bc571c2edf466d8e60121d79e7a0e17630b439b..1aab5997a9048d6e18ddbd6bf28d4a74dae6519b 100755
--- a/install/tools/ipa-replica-install
+++ b/install/tools/ipa-replica-install
@@ -216,6 +216,9 @@ def install_http(config, auto_redirect):
 print error copying files:  + str(e)
 sys.exit(1)
 
+http.setup_firefox_extension(config.realm_name, config.domain_name,
+subject_base=0= + config.realm_name)
+
 return http
 
 def install_bind(config, options):
diff --git a/install/tools/ipa-upgradeconfig b/install/tools/ipa-upgradeconfig
index c74ebe33d228c20508e734c7d5c9b41573145003..5e5b0f6c0f030c739162183e149701f737d77e64 100644
--- a/install/tools/ipa-upgradeconfig
+++ b/install/tools/ipa-upgradeconfig
@@ -281,6 +281,16 @@ def cleanup_kdc(fstore):
 fstore.untrack_file(filename)
 root_logger.debug('Uninstalling %s', filename)
 
+def setup_firefox_extension(fstore):
+Set up the Firefox configuration extension, if it's not set up yet
+
+root_logger.info('[Setting up Firefox extension]')
+http = httpinstance.HTTPInstance(fstore)
+realm = api.env.realm
+domain = api.env.domain
+subject_base = 0= + realm
+http.setup_firefox_extension(realm, domain, subject_base)
+
 def upgrade_ipa_profile(realm):
 
 Update the IPA Profile provided by dogtag
@@ -522,6 +532,7 @@ def main():
 
 cleanup_kdc(fstore)
 upgrade_ipa_profile(api.env.realm)
+setup_firefox_extension(fstore)
 changed_psearch = named_enable_psearch()
 changed_autoincrement = named_enable_serial_autoincrement()
 if changed_psearch or changed_autoincrement:
diff --git a/ipapython/ipautil.py b/ipapython/ipautil.py
index 11433b4be832c1f6a79d17056e830c9582f3ca6e..0b519c2957f63770f9a28d7abe9083f724a9cf40 100644
--- a/ipapython/ipautil.py
+++ b/ipapython/ipautil.py
@@ -223,8 +223,17 @@ def template_str(txt, vars):
 return val
 
 def template_file(infilename, vars):
-txt = open(infilename).read()
-return template_str(txt, vars)
+Read a file and perform template substitutions
+with open(infilename) as f:
+ 

Re: [Freeipa-devel] [PATCH] 1055 update audit cert renewal time

[Rob Crittenden]

Martin Kosek wrote:

On 09/20/2012 11:58 PM, Rob Crittenden wrote:

Rob Crittenden wrote:

The CA audit certificate is initially valid for two years but its
profile has it renewing at six months. This bumps the value up to two
years to match the other certificates.

This relies on Petr's and Ade's dogtag 10 patches.


Updated patch. The value of policyset.caLogSigningSet.2.constraint.params.range
needs to be bumped to 720 as well.

rob



1) I do not see the updated patch with the described change

2) Patch needs a rebase

3) In upgrade_ipa_profile function, please rather adopt the concept of
restarting the CA just once (ca_restart variable), at the end of the
ipa-upgraceconfig. With your change, CA would be restarted at least twice -
once for audit cert renewal update and then for CRL location change.

Otherwise it works OK - profile is updated.

Martin



done

rob
From f186b8871a910a9d89fc27a1e6c1b396a7c2d29f Mon Sep 17 00:00:00 2001
From: Rob Crittenden rcrit...@redhat.com
Date: Tue, 9 Oct 2012 11:25:27 -0400
Subject: [PATCH] Set renewal time for the CA audit certificate to 720 days.

The initial certificate is issued for two years but renewals are
for six months for some reason. This fixes it for new and updated
IPA installs.

https://fedorahosted.org/freeipa/ticket/2951
---
 install/tools/ipa-upgradeconfig | 21 ++---
 ipaserver/install/cainstance.py | 33 +
 2 files changed, 47 insertions(+), 7 deletions(-)

diff --git a/install/tools/ipa-upgradeconfig b/install/tools/ipa-upgradeconfig
index cb2164c0c3ed6d751dacc94633df2c1c257aa038..4ed718a9b9faea0821db5642544e9bb1194dbce4 100644
--- a/install/tools/ipa-upgradeconfig
+++ b/install/tools/ipa-upgradeconfig
@@ -211,14 +211,15 @@ def upgrade_pki(fstore):
 
 This requires enabling SSL renegotiation.
 
+configured_constants = dogtag.configured_constants()
 root_logger.info('[Verifying that CA proxy configuration is correct]')
-if not os.path.exists('/etc/pki-ca/CS.cfg'):
+if not os.path.exists(configured_constants.CS_CFG_PATH):
 root_logger.debug('No CA detected in /etc/pki-ca')
 return
 
 http = httpinstance.HTTPInstance(fstore)
 http.enable_mod_nss_renegotiate()
-if not installutils.get_directive('/etc/pki-ca/CS.cfg',
+if not installutils.get_directive(configured_constants.CS_CFG_PATH,
   'proxy.securePort', '=') and \
 os.path.exists('/usr/bin/pki-setup-proxy'):
 ipautil.run(['/usr/bin/pki-setup-proxy', '-pki_instance_root=/var/lib'
@@ -285,17 +286,24 @@ def cleanup_kdc(fstore):
 def upgrade_ipa_profile(ca):
 
 Update the IPA Profile provided by dogtag
+
+Returns True if restart is needed, False otherwise.
 
 root_logger.info('[Verifying that CA service certificate profile is updated]')
 if ca.is_configured():
-if ca.enable_subject_key_identifier():
-root_logger.debug('Subject Key Identifier updated, restarting CA')
-ca.restart()
+ski = ca.enable_subject_key_identifier()
+if ski:
+root_logger.debug('Subject Key Identifier updated.')
 else:
 root_logger.debug('Subject Key Identifier already set.')
+audit = ca.set_audit_renewal()
+if audit or ski:
+return True
 else:
 root_logger.debug('CA is not configured')
 
+return False
+
 def upgrade_httpd_selinux(fstore):
 
 Update SElinux configuration for httpd instance in the same way as the
@@ -609,14 +617,13 @@ def main():
 pass
 
 cleanup_kdc(fstore)
-upgrade_ipa_profile(ca)
 changed_psearch = named_enable_psearch()
 changed_autoincrement = named_enable_serial_autoincrement()
 if changed_psearch or changed_autoincrement:
 # configuration has changed, restart the name server
 root_logger.info('Changes to named.conf have been made, restart named')
 bindinstance.BindInstance(fstore).restart()
-ca_restart = ca_restart or enable_certificate_renewal(ca)
+ca_restart = ca_restart or enable_certificate_renewal(ca) or upgrade_ipa_profile(ca)
 
 if ca_restart:
 root_logger.info('pki-ca configuration changed, restart pki-ca')
diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py
index 30a8274a6bff874e6ff50f1f090c41074cca662d..d6769d8e69f125526101f2d0402d1254ba5957bc 100644
--- a/ipaserver/install/cainstance.py
+++ b/ipaserver/install/cainstance.py
@@ -562,6 +562,7 @@ class CAInstance(service.Service):
 self.step(set up CRL publishing, self.__enable_crl_publish)
 self.step(set certificate subject base, self.__set_subject_in_config)
 self.step(enabling Subject Key Identifier, self.enable_subject_key_identifier)
+self.step(setting audit signing renewal to 2 years, self.set_audit_renewal)
 self.step(configuring certificate server to start on boot, 

Re: [Freeipa-devel] [PATCH] 1056 sudorule cn uniqueness

[Martin Kosek]

On 09/14/2012 05:13 PM, Rob Crittenden wrote:
 Rob Crittenden wrote:
 A sudorule dn uses ipaUniqueId as the cn so we have to do a search to
 ensure uniqueness. This leaves us vulnerable to a race. Configure the
 uniqueness plugin to ensure no dups.

 rob
 
 Add missing attribute to the fresh install ldif. I had already fixed this in
 the update, missed it on fresh install.
 
 rob
 

Works fine. Reproduced the issue with simple ldapadd.

ACK if you change the whitespace error below:

# git apply /home/mkosek/freeipa-rcrit-1056-2-sudorule-uniqueness.patch
/home/mkosek/freeipa-rcrit-1056-2-sudorule-uniqueness.patch:70: new blank line
at EOF.
+
warning: 1 line adds whitespace errors.

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 1055 update audit cert renewal time

[Martin Kosek]

On 10/09/2012 05:29 PM, Rob Crittenden wrote:
 Martin Kosek wrote:
 On 09/20/2012 11:58 PM, Rob Crittenden wrote:
 Rob Crittenden wrote:
 The CA audit certificate is initially valid for two years but its
 profile has it renewing at six months. This bumps the value up to two
 years to match the other certificates.

 This relies on Petr's and Ade's dogtag 10 patches.

 Updated patch. The value of 
 policyset.caLogSigningSet.2.constraint.params.range
 needs to be bumped to 720 as well.

 rob


 1) I do not see the updated patch with the described change

 2) Patch needs a rebase

 3) In upgrade_ipa_profile function, please rather adopt the concept of
 restarting the CA just once (ca_restart variable), at the end of the
 ipa-upgraceconfig. With your change, CA would be restarted at least twice -
 once for audit cert renewal update and then for CRL location change.

 Otherwise it works OK - profile is updated.

 Martin

 
 done
 
 rob

ACK. Pushed to master, ipa-3-0.

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCHES] 0086-0088 Generate Firefox extension on upgrades

[Petr Vobornik]

On 10/09/2012 05:26 PM, Petr Viktorin wrote:

On 10/09/2012 05:16 PM, Petr Viktorin wrote:

https://fedorahosted.org/freeipa/ticket/3150


Patch 0086:
I found an old unused function while working on this, the patch
removes it.

Patch 0087:
Replica files generated on older masters don't contain the Firefox
extension files. Skip installing them in this case.

Patch 0088:
Servers upgraded from IPA 2.2 need the Firefox extension installed. This
is done in ipa-upgradeconfig if they're missing.
I made the setup_firefox_extension method independent on the
httpinstance state (which is mostly set in create_instance).
Similarly, the files are installed ipa-replica-install if they're
missing (i.e. skipped by the previous patch).
If the Signing-Cert is not on this master, create an unsigned extension
using the zip command. I needed to add Popen's `cwd` argument to
ipautil.run() to get the right filenames out of zip.

The patches add copy_template_file and copy_file_if_exists utilities
I've written for some of my WIP patches, expect me to use them more when
I get time to work on the installer code.



In my previous mail I've attached an old version of patch 88. Please use
this one. Sorry!




nack

1) patch 83-01 doesn't apply.

2) When pwd is supplied to setup_firefox_extension `db = 
certs.CertDB(realm, subject_base=subject_base)` is skipped and therefore 
`db.has_nickname` will fail.



--
Petr Vobornik

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 1059 single CRL generator

[Martin Kosek]

On 10/09/2012 04:43 PM, Rob Crittenden wrote:
 Martin Kosek wrote:
 On 10/04/2012 06:17 PM, Rob Crittenden wrote:
 This changes the way IPA generates CRLs for new installs only.

 The first master installed is configured as the CRL generator. An entry is
 added to cn=masters that designates it.

 When a replica is installed it queries this entry so it knows where to 
 forward
 CRL requests. CRL files are not available on cloned CAs (so /ipa/crl will
 return not found). It is possible to get a CRL directly from the clone CA 
 via
 http://hostname:9180/ca/ee/ca/getCRL?op=getCRLcrlIssuingPoint=MasterCRL

 rob

 I tested new IPA server + replica with your patch and the CRL was now 
 generated
 only on the CRL master. I also tried OCSP (though this may not be relevant) 
 and
 it worked for me too.

 1) I do not understand the following block in set_crl_master(self, suffix):

 +try:
 +self.admin_conn.addEntry(entry)
 +except ldap.ALREADY_EXISTS, e:
 +root_logger.debug(failed to set CA as CRL generator)
 +raise e

 - when we hit ldap.ALREADY_EXISTS, we are actually OK because cn=CRL is set,
 right?
 - AFAIK, addEntry should  return our errors, i.e. errors.DuplicateEntry
 - s/raise e/raise/

 I think you may have wanted to rather catch for more general LDAP error and
 then report a real error and not just a debug note.

 2) In get_crl_master:

 +except Exception, e:
 +root_logger.debug(Could not connect to the Directory Server on
 %s: %s % (master_host, str(e)))
 +raise e

 s/raise e/raise/

 +except errors.NotFound, e:
 +root_logger.debug(failed to find CA CRL generator)
 +self.crl_master = None

 - e is actually not used, except errors.NotFound would be enough

 3) Majorish issue I hit with the actual CRL publishing on our server (F17). I
 always get 403 Forbidden error when trying to download CRL from the CRL 
 master:

 # wget --ca-certificate /etc/ipa/ca.crt 
 https://`hostname`/ipa/crl/MasterCRL.bin
 --2012-10-05 03:32:58--
 https://vm-120.idm.lab.bos.redhat.com/ipa/crl/MasterCRL.bin
 Resolving vm-120.idm.lab.bos.redhat.com... 10.16.78.120
 Connecting to vm-120.idm.lab.bos.redhat.com|10.16.78.120|:443... connected.
 HTTP request sent, awaiting response... 403 Forbidden
 2012-10-05 03:32:58 ERROR 403: Forbidden.

 I tracked the problem down to too strict permission on /var/lib/pki-ca
 directory which is being published by httpd which does not have access to it:

 # ll /var/lib/pki-ca

 drwxrwx---. 11 pkiuser pkiuser 4096 Oct  5 03:00 pki-ca

 When I fixed the permission:
 # chmod o+x /var/lib/pki-ca/

 I was able to get pass the Forbidden error and actually retrieved the CRL.
 Adding Ade on CC list to follow on this permission issue.


 I was thinking about usability of this new approach, we may want to make user
 life easier in a perspective of CRL master managing. I have following
 enhancements in mind:

 - mark CRL master in ipa-replica-manage list, or ipa-csreplica-manage list:

 # ipa-csreplica-manage list
 Directory Manager password:

 vm-065.idm.lab.bos.redhat.com: master [CRL]
 vm-120.idm.lab.bos.redhat.com: master

 - when removing master with CRL by ipa-replica-manage del we should warn 
 user
 and inform him what he should do next to amend the situation. I am thinking
 about 2 new commands for ipa-csreplica-manage:

 * ipa-csreplica-manage crl-promote
- promote current master as the new CRL master, enable CRL generation in
 CS.cfg, mark master as the new CRL master in cn=masters
 * ipa-csreplica-manage crl-update
- update CS.cfg of current CA replica and point master.ca.agent.* to 
 current
 CRL master

 I can work on those enhancements if we agree on them.

 Martin

 
 Andrew provided some feedback out-of-band and my solution was overly complex.
 Here is a much simpler patch which does away with all the hand-waving around
 knowing who the CRL generator is.
 
 rob

This looks OK code-wise, I will wait for dogtag guys to confirm that this is
the right approach.

Btw. I think we may want to file a RFE to implement some command to promote a
replica to CRL master (like ipa-csreplica-manage crl-promote proposed
earlier). Users may want to promote a replica when the master crashes or is to
be replaced. Some way to migrate CRL list (if not replicated already) to the
promoted replica would also be needed.

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 1059 single CRL generator

[Rob Crittenden]

Martin Kosek wrote:

On 10/09/2012 04:43 PM, Rob Crittenden wrote:

Martin Kosek wrote:

On 10/04/2012 06:17 PM, Rob Crittenden wrote:

This changes the way IPA generates CRLs for new installs only.

The first master installed is configured as the CRL generator. An entry is
added to cn=masters that designates it.

When a replica is installed it queries this entry so it knows where to forward
CRL requests. CRL files are not available on cloned CAs (so /ipa/crl will
return not found). It is possible to get a CRL directly from the clone CA via
http://hostname:9180/ca/ee/ca/getCRL?op=getCRLcrlIssuingPoint=MasterCRL

rob


I tested new IPA server + replica with your patch and the CRL was now generated
only on the CRL master. I also tried OCSP (though this may not be relevant) and
it worked for me too.

1) I do not understand the following block in set_crl_master(self, suffix):

+try:
+self.admin_conn.addEntry(entry)
+except ldap.ALREADY_EXISTS, e:
+root_logger.debug(failed to set CA as CRL generator)
+raise e

- when we hit ldap.ALREADY_EXISTS, we are actually OK because cn=CRL is set,
right?
- AFAIK, addEntry should  return our errors, i.e. errors.DuplicateEntry
- s/raise e/raise/

I think you may have wanted to rather catch for more general LDAP error and
then report a real error and not just a debug note.

2) In get_crl_master:

+except Exception, e:
+root_logger.debug(Could not connect to the Directory Server on
%s: %s % (master_host, str(e)))
+raise e

s/raise e/raise/

+except errors.NotFound, e:
+root_logger.debug(failed to find CA CRL generator)
+self.crl_master = None

- e is actually not used, except errors.NotFound would be enough

3) Majorish issue I hit with the actual CRL publishing on our server (F17). I
always get 403 Forbidden error when trying to download CRL from the CRL master:

# wget --ca-certificate /etc/ipa/ca.crt https://`hostname`/ipa/crl/MasterCRL.bin
--2012-10-05 03:32:58--
https://vm-120.idm.lab.bos.redhat.com/ipa/crl/MasterCRL.bin
Resolving vm-120.idm.lab.bos.redhat.com... 10.16.78.120
Connecting to vm-120.idm.lab.bos.redhat.com|10.16.78.120|:443... connected.
HTTP request sent, awaiting response... 403 Forbidden
2012-10-05 03:32:58 ERROR 403: Forbidden.

I tracked the problem down to too strict permission on /var/lib/pki-ca
directory which is being published by httpd which does not have access to it:

# ll /var/lib/pki-ca

drwxrwx---. 11 pkiuser pkiuser 4096 Oct  5 03:00 pki-ca

When I fixed the permission:
# chmod o+x /var/lib/pki-ca/

I was able to get pass the Forbidden error and actually retrieved the CRL.
Adding Ade on CC list to follow on this permission issue.


I was thinking about usability of this new approach, we may want to make user
life easier in a perspective of CRL master managing. I have following
enhancements in mind:

- mark CRL master in ipa-replica-manage list, or ipa-csreplica-manage list:

# ipa-csreplica-manage list
Directory Manager password:

vm-065.idm.lab.bos.redhat.com: master [CRL]
vm-120.idm.lab.bos.redhat.com: master

- when removing master with CRL by ipa-replica-manage del we should warn user
and inform him what he should do next to amend the situation. I am thinking
about 2 new commands for ipa-csreplica-manage:

* ipa-csreplica-manage crl-promote
- promote current master as the new CRL master, enable CRL generation in
CS.cfg, mark master as the new CRL master in cn=masters
* ipa-csreplica-manage crl-update
- update CS.cfg of current CA replica and point master.ca.agent.* to current
CRL master

I can work on those enhancements if we agree on them.

Martin



Andrew provided some feedback out-of-band and my solution was overly complex.
Here is a much simpler patch which does away with all the hand-waving around
knowing who the CRL generator is.

rob


This looks OK code-wise, I will wait for dogtag guys to confirm that this is
the right approach.

Btw. I think we may want to file a RFE to implement some command to promote a
replica to CRL master (like ipa-csreplica-manage crl-promote proposed
earlier). Users may want to promote a replica when the master crashes or is to
be replaced. Some way to migrate CRL list (if not replicated already) to the
promoted replica would also be needed.

Martin



Andrew suggested I specify that we do not monitor cloned revocations on 
the server not generating CRLs, so I added that.


The last question is what we do about redirecting users on the 
non-generating masters.


We can do it easily with a line like this in Apache:

RewriteRule ^/ipa/crl/MasterCRL.bin 
https://$FQDN:9444/ca/ee/ca/getCRL?op=getCRLcrlIssuingPoint=MasterCRL 
[L,R=301,NC]


The tricky part is writing this properly. The CA can be added 
post-install so I don't think simply adding this to ipa-rewrite.conf 
will work well. Is adding another template configuration file for Apache 
overkill?


rob
From 

Re: [Freeipa-devel] [PATCH] 1051 Fix CS replica management

[Rob Crittenden]

Martin Kosek wrote:

On 10/08/2012 05:12 PM, Jan Cholasta wrote:

Hi,

On 20.9.2012 19:38, Rob Crittenden wrote:

Jan Cholasta wrote:

Hi,

Dne 31.8.2012 19:43, Rob Crittenden napsal(a):

The naming in CS replication agreements is different from IPA
agreements, we have to live with what the create. The master side should
be on the local side, replica1, not the remote. This required reversing
a few master variables.

Pass in the force flag to del_link.

Do a better job of finding the agreements on each side.

This should be ipa-csreplica-manage more in line with
ipa-replica-manage.

rob



Rob, can you please rebase the patch on top of current master? There
were some dogtag 10 related changes to ipa-csreplica-manage since you
posted the patch.

Honza



I re-tested after the merge and found some problems with my initial
approach. The problem stems from the naming convention that dogtag uses
when creating the initial agreements. It is hard to predict how things
were set up later so rather than trying to reconstruct the DN we search
for it and pass it when deleting agreements.

rob


So far I have found this:

   * Deleting a bridge link that connects two islands of replicas works, but
it should not (I was told that this is expected, as no complex graph algorithms
are engaged to detect this kind of errors).


Exactly, I hit this error when I was a similar Rob's patch for
ipa-replica-manage (ticket 2797). I used topology A - B - C - D - E and I was
able to delete C. We may want to log an enhancement ticket for this.

Martin



Right, and ipa-csreplica-manage doesn't even have the basic last_link 
checking code that ipa-replica-manage has, nor the ruv code. We decided 
to push that to a future release.


This patch should fix up the basics.

rob
From 82abfb2f235bd8f01a29fa08f41c464f7efd9349 Mon Sep 17 00:00:00 2001
From: Rob Crittenden rcrit...@redhat.com
Date: Thu, 30 Aug 2012 16:24:10 -0400
Subject: [PATCH] Fix CS replication management.

The master side should be on the local side, replica1, not the
remote. This required reversing a few master variables. This impacts
the naming of the replication agreements.

When deleting an agreement pass in the DN of that agreement
rather than trying to calculate what it is on-the-fly. We cannot
be sure which side is the master/clone and since we search for it
anyway to determine if the agreement exists it is more correct
to use what we find.

The force flag wasn't being passed into del_link so there was no way
to force a deletion.

https://fedorahosted.org/freeipa/ticket/2858
---
 install/tools/ipa-csreplica-manage | 58 ++
 ipaserver/install/replication.py   | 22 +++
 2 files changed, 57 insertions(+), 23 deletions(-)

diff --git a/install/tools/ipa-csreplica-manage b/install/tools/ipa-csreplica-manage
index 39cfa58511ae552cae64798c7559303fda27866a..5fce48a3759a0de55193a2d025f3af4543ddb32e 100755
--- a/install/tools/ipa-csreplica-manage
+++ b/install/tools/ipa-csreplica-manage
@@ -176,7 +176,7 @@ def list_replicas(realm, host, replica, dirman_passwd, verbose):
 peers[ent.getValue('cn')] = ['CA not configured', '']
 
 except Exception, e:
-sys.exit(Failed to get data from '%s': %s % (host, convert_error(e)))
+sys.exit(Failed to get data from '%s' while trying to list replicas: %s % (host, convert_error(e)))
 finally:
 conn.unbind_s()
 
@@ -205,18 +205,21 @@ def del_link(realm, replica1, replica2, dirman_passwd, force=False):
 repl1 = CSReplicationManager(realm, replica1, dirman_passwd, PORT, True)
 
 repl1.hostnames = [replica1, replica2]
-type1 = repl1.get_agreement_type(replica2)
 
-repl_list = repl1.find_ipa_replication_agreements()
-if not force and len(repl_list) = 1:
-print Cannot remove the last replication link of '%s' % replica1
-print Please use the 'del' command to remove it from the domain
-sys.exit(1)
+repl_list1 = repl1.find_replication_agreements()
+
+# Find the DN of the replication agreement to remove
+replica1_dn = None
+for e in repl_list1:
+if e.getValue('nsDS5ReplicaHost') == replica2:
+replica1_dn = e.dn
+break
+
+if replica1_dn is None:
+sys.exit('%s' has no replication agreement for '%s' % (replica1, replica2))
+
+repl1.hostnames = [replica1, replica2]
 
-except ldap.NO_SUCH_OBJECT:
-sys.exit('%s' has no replication agreement for '%s' % (replica1, replica2))
-except errors.NotFound:
-sys.exit('%s' has no replication agreement for '%s' % (replica1, replica2))
 except ldap.SERVER_DOWN, e:
 sys.exit(Unable to connect to %s: %s % (ipautil.format_netloc(replica1, PORT), convert_error(e)))
 except Exception, e:
@@ -226,12 +229,31 @@ def del_link(realm, replica1, replica2, dirman_passwd, force=False):
 repl2 = 

Re: [Freeipa-devel] [PATCH] 1059 single CRL generator

[Rob Crittenden]

Rob Crittenden wrote:

Martin Kosek wrote:

On 10/09/2012 04:43 PM, Rob Crittenden wrote:

Martin Kosek wrote:

On 10/04/2012 06:17 PM, Rob Crittenden wrote:

This changes the way IPA generates CRLs for new installs only.

The first master installed is configured as the CRL generator. An
entry is
added to cn=masters that designates it.

When a replica is installed it queries this entry so it knows where
to forward
CRL requests. CRL files are not available on cloned CAs (so
/ipa/crl will
return not found). It is possible to get a CRL directly from the
clone CA via
http://hostname:9180/ca/ee/ca/getCRL?op=getCRLcrlIssuingPoint=MasterCRL


rob


I tested new IPA server + replica with your patch and the CRL was
now generated
only on the CRL master. I also tried OCSP (though this may not be
relevant) and
it worked for me too.

1) I do not understand the following block in set_crl_master(self,
suffix):

+try:
+self.admin_conn.addEntry(entry)
+except ldap.ALREADY_EXISTS, e:
+root_logger.debug(failed to set CA as CRL generator)
+raise e

- when we hit ldap.ALREADY_EXISTS, we are actually OK because cn=CRL
is set,
right?
- AFAIK, addEntry should  return our errors, i.e. errors.DuplicateEntry
- s/raise e/raise/

I think you may have wanted to rather catch for more general LDAP
error and
then report a real error and not just a debug note.

2) In get_crl_master:

+except Exception, e:
+root_logger.debug(Could not connect to the Directory
Server on
%s: %s % (master_host, str(e)))
+raise e

s/raise e/raise/

+except errors.NotFound, e:
+root_logger.debug(failed to find CA CRL generator)
+self.crl_master = None

- e is actually not used, except errors.NotFound would be enough

3) Majorish issue I hit with the actual CRL publishing on our server
(F17). I
always get 403 Forbidden error when trying to download CRL from the
CRL master:

# wget --ca-certificate /etc/ipa/ca.crt
https://`hostname`/ipa/crl/MasterCRL.bin
--2012-10-05 03:32:58--
https://vm-120.idm.lab.bos.redhat.com/ipa/crl/MasterCRL.bin
Resolving vm-120.idm.lab.bos.redhat.com... 10.16.78.120
Connecting to vm-120.idm.lab.bos.redhat.com|10.16.78.120|:443...
connected.
HTTP request sent, awaiting response... 403 Forbidden
2012-10-05 03:32:58 ERROR 403: Forbidden.

I tracked the problem down to too strict permission on /var/lib/pki-ca
directory which is being published by httpd which does not have
access to it:

# ll /var/lib/pki-ca

drwxrwx---. 11 pkiuser pkiuser 4096 Oct  5 03:00 pki-ca

When I fixed the permission:
# chmod o+x /var/lib/pki-ca/

I was able to get pass the Forbidden error and actually retrieved
the CRL.
Adding Ade on CC list to follow on this permission issue.


I was thinking about usability of this new approach, we may want to
make user
life easier in a perspective of CRL master managing. I have following
enhancements in mind:

- mark CRL master in ipa-replica-manage list, or
ipa-csreplica-manage list:

# ipa-csreplica-manage list
Directory Manager password:

vm-065.idm.lab.bos.redhat.com: master [CRL]
vm-120.idm.lab.bos.redhat.com: master

- when removing master with CRL by ipa-replica-manage del we
should warn user
and inform him what he should do next to amend the situation. I am
thinking
about 2 new commands for ipa-csreplica-manage:

* ipa-csreplica-manage crl-promote
- promote current master as the new CRL master, enable CRL
generation in
CS.cfg, mark master as the new CRL master in cn=masters
* ipa-csreplica-manage crl-update
- update CS.cfg of current CA replica and point
master.ca.agent.* to current
CRL master

I can work on those enhancements if we agree on them.

Martin



Andrew provided some feedback out-of-band and my solution was overly
complex.
Here is a much simpler patch which does away with all the hand-waving
around
knowing who the CRL generator is.

rob


This looks OK code-wise, I will wait for dogtag guys to confirm that
this is
the right approach.

Btw. I think we may want to file a RFE to implement some command to
promote a
replica to CRL master (like ipa-csreplica-manage crl-promote proposed
earlier). Users may want to promote a replica when the master crashes
or is to
be replaced. Some way to migrate CRL list (if not replicated already)
to the
promoted replica would also be needed.

Martin



Andrew suggested I specify that we do not monitor cloned revocations on
the server not generating CRLs, so I added that.

The last question is what we do about redirecting users on the
non-generating masters.

We can do it easily with a line like this in Apache:

RewriteRule ^/ipa/crl/MasterCRL.bin
https://$FQDN:9444/ca/ee/ca/getCRL?op=getCRLcrlIssuingPoint=MasterCRL
[L,R=301,NC]

The tricky part is writing this properly. The CA can be added
post-install so I don't think simply adding this to ipa-rewrite.conf
will work well. Is adding another template configuration file for Apache
overkill?

rob


Here is my