Re: [Freeipa-devel] LDAP conflicts resolution API
On Wed, 2011-10-19 at 09:51 -0600, Rich Megginson wrote: On 10/19/2011 09:46 AM, Simo Sorce wrote: On Wed, 2011-10-19 at 17:33 +0200, Martin Kosek wrote: Hello all, I am now investigating how to deal with LDAP conflicts resolution between replicas. Conflicting LDAP objects may be created if 2 LDAP objects (users, hosts, etc) with the same DN are created on disconnected replicas. When the replicas synchronize again, 389-ds renames one of the objects to something like this: nsuniqueid=0a950601-435311e0-86a2f5bd-3cd26022+uid=utest,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com for users OR fqdn=rhel61-client3.testrelm+nsuniqueid=807bb87f-652211e0-9e848fb2-f0f04a39,cn=computers,cn=accounts,dc=testrelm for hosts. Records like this then cannot be handled via IPA commands and can cause a wide range of problems. There are already 2 tickets filed: https://fedorahosted.org/freeipa/ticket/1025 https://fedorahosted.org/freeipa/ticket/1174 Since we cannot avoid creating these objects, we can at least help mitigate the consequences and help user remove the conflicts using our CLI (or WebUI in the future). I would like to propose a simple plugin to manage these conflicts: 1) ipa confict-find This command would find all conflicting LDAP objects using filter nsds5ReplConflict=*. Since this plugin would work with all LDAP objects we support, the most straightforward implementation would be to display raw LDAP data. I am still thinking if we could make the output prettier by finding what LDAP object is in conflict (user, host, sudorule) and display the objects in standard way as we do in ipa user-show, ipa host-show or ipa sudorule-show. I guess we could identify the conflicting object type by comparing its parent DN to all known LDAP objects container_dn. Raw LDAP data output would look like this: $ ipa conflic-find - 3 conflicts found - dn: nsuniqueid=02631581-fa5f11e0-bb339359-34a214df+uid=utest2,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com memberOf: cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com mepManagedEntry: cn=utest2,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com displayName: User Test cn: User Test objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: mepOriginEntry loginShell: /bin/sh sn: Test gecos: User Test homeDirectory: /home/utest2 krbPwdPolicyReference: cn=global_policy,cn=IDM.LAB.BOS.REDHAT.COM,cn=kerberos, dc=idm,dc=lab,dc=bos,dc=redhat,dc=com krbPrincipalName: ute...@idm.lab.bos.redhat.com givenName: User uid: utest2 initials: UT uidNumber: 145103 gidNumber: 145103 ipaUniqueID: 0636d5b6-fa5f-11e0-b85b-00163e6f5efc dn: nsuniqueid=02631582-fa5f11e0-bb339359-34a214df+cn=utest2,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com description: User private group for utest2 gidNumber: 145103 objectClass: posixgroup objectClass: ipaobject objectClass: mepManagedEntry objectClass: top cn: utest2 mepManagedBy: uid=utest2,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com ipaUniqueID: 0639ee7c-fa5f-11e0-b85b-00163e6f5efc dn: nsuniqueid=af8a5d81-fa6011e0-bb339359-34a214df+fqdn=foo.example.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com cn: foo.example.com objectClass: ipaobject objectClass: nshost objectClass: ipahost objectClass: pkiuser objectClass: ipaservice objectClass: krbprincipalaux objectClass: krbprincipal objectClass: top fqdn: foo.example.com managedBy: fqdn=foo.example.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=bos, dc=redhat,dc=com krbPrincipalName: host/foo.example@idm.lab.bos.redhat.com serverHostName: foo ipaUniqueID: d069dff8-fa60-11e0-874e-00163e6f5efc User could then copypaste DNs to manipulate the objects further: 2) ipa conflict-show DN This command would show chosen conflicting object closer + the original object it conflicts with: $ ipa conflict-show 'nsuniqueid=02631582-fa5f11e0-bb339359-34a214df+cn=utest2,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com' dn: fqdn=foo.example.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com cn: foo.example.com objectClass: ipaobject objectClass: nshost objectClass: ipahost objectClass: pkiuser objectClass: ipaservice objectClass: krbprincipalaux objectClass: krbprincipal objectClass: top fqdn: foo.example.com managedBy: fqdn=foo.example.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=bos, dc=redhat,dc=com krbPrincipalName: host/foo.example@idm.lab.bos.redhat.com serverHostName: foo ipaUniqueID:
[Freeipa-devel] [PATCH] Add kerberos mapping for clients outside the IPA domain
Hello,
Proposed patch for bug https://fedorahosted.org/freeipa/ticket/2006
Best regards,
Lars
From cd62f50c7adba7eb7e240b9b051b90ba9cb3ce70 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lars=20Sj=C3=B6str=C3=B6m?= lsjostro@lsjostro.local
Date: Thu, 20 Oct 2011 09:34:19 +0200
Subject: [PATCH] Add kerberos mapping for clients outside the IPA domain
---
ipa-client/ipa-install/ipa-client-install | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa-install/ipa-client-install
index 85d7867..fc3437e 100755
--- a/ipa-client/ipa-install/ipa-client-install
+++ b/ipa-client/ipa-install/ipa-client-install
@@ -546,7 +546,7 @@ def hardcode_ldap_server(cli_server):
return
-def configure_krb5_conf(fstore, cli_basedn, cli_realm, cli_domain, cli_server, cli_kdc, dnsok, options, filename):
+def configure_krb5_conf(fstore, cli_basedn, cli_realm, cli_domain, cli_server, cli_kdc, dnsok, options, filename, sys_cli_domain=None):
krbconf = ipaclient.ipachangeconf.IPAChangeConf(IPA Installer)
krbconf.setOptionAssignment( = )
@@ -589,6 +589,12 @@ def configure_krb5_conf(fstore, cli_basedn, cli_realm, cli_domain, cli_server, c
#[domain_realm]
dropts = [{'name':'.'+cli_domain, 'type':'option', 'value':cli_realm},
{'name':cli_domain, 'type':'option', 'value':cli_realm}]
+
+#add mapping if client is outside of IPA domain
+if sys_cli_domain:
+dropts.append({'name':'.'+sys_cli_domain, 'type':'option', 'value':cli_realm})
+dropts.append({'name':sys_cli_domain, 'type':'option', 'value':cli_realm})
+
opts.append({'name':'domain_realm', 'type':'section', 'value':dropts})
opts.append({'name':'empty', 'type':'empty'})
@@ -895,6 +901,12 @@ def install(options, env, fstore, statestore):
cli_domain = ds.getDomainName()
logging.debug(will use domain: %s\n, cli_domain)
+p = hostname.find(.)
+sys_cli_domain = hostname[p+1:]
+
+if sys_cli_domain == cli_domain:
+sys_cli_domain = None
+
if ret in (ipadiscovery.NO_LDAP_SERVER, ipadiscovery.NOT_IPA_SERVER) \
or not ds.getServerName():
logging.debug(IPA Server not found)
@@ -1015,7 +1027,7 @@ def install(options, env, fstore, statestore):
print Unable to sync time with IPA NTP server, assuming the time is in sync.
(krb_fd, krb_name) = tempfile.mkstemp()
os.close(krb_fd)
-if configure_krb5_conf(fstore, cli_basedn, cli_realm, cli_domain, cli_server, cli_kdc, dnsok, options, krb_name):
+if configure_krb5_conf(fstore, cli_basedn, cli_realm, cli_domain, cli_server, cli_kdc, dnsok, options, krb_name, sys_cli_domain):
print Test kerberos configuration failed
return CLIENT_INSTALL_ERROR
env['KRB5_CONFIG'] = krb_name
--
1.7.6.4
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 51/51] Ticket 1201 - Unable to Download Certificate with Browser
Certificates are passed through the IPA XML-RPC and JSON as binary data in DER X509 format. Queries peformed against the LDAP server also return binary DER X509 format. In all cases the binary DER data is base-64 encoded. PEM is standard text format for certificates. It also uses base64 to encode the binary DER data, but had specific formatting requirements. The base64 data must be wrapped inside PEM delimiters and the base64 data must be line wrapped at 64 characters. Most external software which accepts certificates as input will only accept DER or PEM format (e.g. openssl NSS). Although base64 is closely related to PEM it is not PEM unless the PEM delimters are present and the base64 data is line wrapped at 64 characters. We already convert binary DER certificates which have been passed as base64 in other parts of the IPA code. However this conversion has not been available in the web UI. When the web UI presented certificates it did so by filling a dialog box with a single line of base64 data. A user could not copy this data and use it as input to openssl or NSS for example. We resolve this problem by introducing new javascript functions in certificate.js. IPA.cert.pem_cert_format(text) will examine the text input and if it's already in PEM format just return it unmodified, otherwise it will line wrap the base64 data and add the PEM delimiters. Thus it is safe to call on either a previously formated PEM cert or a binary DER cert encoded as base64. This applies to pem_csr_format() as well for CSR's. Because pem_cert_format() is safe to call on either format the web UI will see the use of the flag add_pem_delimiters was eliminated except in the one case where the IPA.cert.download_dialog() was being abused to display PKCS12 binary data (pkcs12 is neither a cert nor a cert request). Because of the abuse of the cert.download_dialog() for pkcs12 it was necessary to retain the flag which in effect said do not treat the data as PEM. Modify the CSR (Certificate Signing Request) dialog box to accept a PEM formatted CSR. Remove the artifical PEM delimiters above and below the dialog box which were used to suggest the input needed to be sans the delimiters. The dialog box continues to accept bare base64 thus allowing either text format. Also note this solves the display of certificate data in the UI without touching anything existing code in the server or command line, thus it's isolated. -- John Dennis jden...@redhat.com Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From a77eb8bd018d9a63c23bc881712b21b309bf0611 Mon Sep 17 00:00:00 2001 From: John Dennis jden...@redhat.com Date: Tue, 18 Oct 2011 18:19:25 -0400 Subject: [PATCH 51/51] Ticket 1201 - Unable to Download Certificate with Browser Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Certificates are passed through the IPA XML-RPC and JSON as binary data in DER X509 format. Queries peformed against the LDAP server also return binary DER X509 format. In all cases the binary DER data is base-64 encoded. PEM is standard text format for certificates. It also uses base64 to encode the binary DER data, but had specific formatting requirements. The base64 data must be wrapped inside PEM delimiters and the base64 data must be line wrapped at 64 characters. Most external software which accepts certificates as input will only accept DER or PEM format (e.g. openssl NSS). Although base64 is closely related to PEM it is not PEM unless the PEM delimters are present and the base64 data is line wrapped at 64 characters. We already convert binary DER certificates which have been passed as base64 in other parts of the IPA code. However this conversion has not been available in the web UI. When the web UI presented certificates it did so by filling a dialog box with a single line of base64 data. A user could not copy this data and use it as input to openssl or NSS for example. We resolve this problem by introducing new javascript functions in certificate.js. IPA.cert.pem_cert_format(text) will examine the text input and if it's already in PEM format just return it unmodified, otherwise it will line wrap the base64 data and add the PEM delimiters. Thus it is safe to call on either a previously formated PEM cert or a binary DER cert encoded as base64. This applies to pem_csr_format() as well for CSR's. Because pem_cert_format() is safe to call on either format the web UI will see the use of the flag add_pem_delimiters was eliminated except in the one case where the IPA.cert.download_dialog() was being abused to display PKCS12 binary data (pkcs12 is neither a cert nor a cert request). Because of the abuse of the cert.download_dialog() for pkcs12 it was necessary to retain the flag which in effect said do not treat the data as PEM. Modify the CSR (Certificate Signing Request) dialog box to accept a PEM formatted CSR. Remove the artifical PEM delimiters above and below the dialog box which were used to suggest the input
Re: [Freeipa-devel] LDAP conflicts resolution API
On Thu, 2011-10-20 at 07:18 -0700, Nathan Kinder wrote: On 10/19/2011 11:22 PM, Martin Kosek wrote: On Wed, 2011-10-19 at 09:51 -0600, Rich Megginson wrote: On 10/19/2011 09:46 AM, Simo Sorce wrote: On Wed, 2011-10-19 at 17:33 +0200, Martin Kosek wrote: ... 3) When user decides what to do with the conflicting object, he would use the following commands: ipa conflict-rename DN NEW_RDN This command would change the conflicting LDAP objects RDN to foo2.example.com: $ ipa conflict-rename 'nsuniqueid=af8a5d81-fa6011e0-bb339359-34a214df+fqdn=foo.example.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com' foo2.example.com OR ipa conflict-del DN This command would delete conflicting LDAP objects altogether: ipa conflict-del 'nsuniqueid=af8a5d81-fa6011e0-bb339359-34a214df+fqdn=foo.example.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com' Thoughts, comments? Sounds good to me. But I wonder if we can tell DS to create/move these conflicting objects into a cn=conflicts subtree by means of configuration ? Not automatically, no. So maybe a new DS plugin should do the trick? We would just have to store original DN to some attribute if we want to enable user to just rename the conflicting object to its original location. No, I think an RFE to change the existing replication plug-in to allow an alternate conflict area would be best. Simo and I had discussed this possibility a long time back. We would allow one to configure a suffix to put conflicts in to prevent them from being in the tree that clients use. I already implemented the conflict-find, conflict-show and conflict-rename commands. But I really like your idea. Conflicts can cause quite unpredictable effects for the user. Not every user can be experienced enough to guess the replication conflicts cause that issues and use the new conflict-* commands to fix it. If all conflicts are stored to a special suffix, the end user experience will be much better. I can adapt new commands so that user can manage the conflicts when he get to it without side effects other ipa commands. Nathan, do you think you will be able to implement this change for RHEL 6.3.0? I can create a RFE bugzilla. Thanks, Martin Martin It would certainly cause some entries to disappear, but it would also prevent some of the issues with have those entries. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 023 Circular entity dependency
Fix for regression in unit test, introduced by previous patch.
--
Petr Vobornik
From f1a1a99763f38a10304c374da88857c85c9e7748 Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Thu, 20 Oct 2011 16:37:48 +0200
Subject: [PATCH] Fixing infinite loop in UI navigation unit test.
https://fedorahosted.org/freeipa/ticket/1531
It's a fix for regression introduced by previous patch.
---
install/ui/test/navigation_tests.js | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/install/ui/test/navigation_tests.js b/install/ui/test/navigation_tests.js
index 90e708ccb3daeb63031c76884bd69b608fbf5694..6df1926c3efac17c0eada193e00a6dcebf0d7093 100644
--- a/install/ui/test/navigation_tests.js
+++ b/install/ui/test/navigation_tests.js
@@ -45,9 +45,15 @@ test(Testing IPA.navigation.create()., function() {
IPA.entities = $.ordered_map();
IPA.entity_factories.user = function() {
-var that = IPA.entity({name: 'user',
- metadata:IPA.metadata.objects.user});
-that.add_facet(IPA.search_facet({'entity':that}));
+var that = IPA.entity({
+name: 'user',
+metadata:IPA.metadata.objects.user,
+facets: [
+{
+type: 'search'
+}
+]
+});
that.display = function(container){
user_mock_called = true;
--
1.7.6.4
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 023 Circular entity dependency
On 10/20/2011 1:03 PM, Petr Vobornik wrote: Fix for regression in unit test, introduced by previous patch. ACK and pushed to master. -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAP conflicts resolution API
On 10/20/2011 07:57 AM, Martin Kosek wrote: On Thu, 2011-10-20 at 07:18 -0700, Nathan Kinder wrote: On 10/19/2011 11:22 PM, Martin Kosek wrote: On Wed, 2011-10-19 at 09:51 -0600, Rich Megginson wrote: On 10/19/2011 09:46 AM, Simo Sorce wrote: On Wed, 2011-10-19 at 17:33 +0200, Martin Kosek wrote: ... 3) When user decides what to do with the conflicting object, he would use the following commands: ipa conflict-rename DN NEW_RDN This command would change the conflicting LDAP objects RDN to foo2.example.com: $ ipa conflict-rename 'nsuniqueid=af8a5d81-fa6011e0-bb339359-34a214df+fqdn=foo.example.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com' foo2.example.com OR ipa conflict-del DN This command would delete conflicting LDAP objects altogether: ipa conflict-del 'nsuniqueid=af8a5d81-fa6011e0-bb339359-34a214df+fqdn=foo.example.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com' Thoughts, comments? Sounds good to me. But I wonder if we can tell DS to create/move these conflicting objects into a cn=conflicts subtree by means of configuration ? Not automatically, no. So maybe a new DS plugin should do the trick? We would just have to store original DN to some attribute if we want to enable user to just rename the conflicting object to its original location. No, I think an RFE to change the existing replication plug-in to allow an alternate conflict area would be best. Simo and I had discussed this possibility a long time back. We would allow one to configure a suffix to put conflicts in to prevent them from being in the tree that clients use. I already implemented the conflict-find, conflict-show and conflict-rename commands. But I really like your idea. Conflicts can cause quite unpredictable effects for the user. Not every user can be experienced enough to guess the replication conflicts cause that issues and use the new conflict-* commands to fix it. If all conflicts are stored to a special suffix, the end user experience will be much better. I can adapt new commands so that user can manage the conflicts when he get to it without side effects other ipa commands. Nathan, do you think you will be able to implement this change for RHEL 6.3.0? I can create a RFE bugzilla. Go ahead and create the RFE bug against 389. We will discuss it in our weekly DS bug triage on Monday to determine the timeline. Thanks, Martin Martin It would certainly cause some entries to disappear, but it would also prevent some of the issues with have those entries. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAP conflicts resolution API
On Thu, 2011-10-20 at 07:18 -0700, Nathan Kinder wrote: But I wonder if we can tell DS to create/move these conflicting objects into a cn=conflicts subtree by means of configuration ? Not automatically, no. So maybe a new DS plugin should do the trick? We would just have to store original DN to some attribute if we want to enable user to just rename the conflicting object to its original location. No, I think an RFE to change the existing replication plug-in to allow an alternate conflict area would be best. Simo and I had discussed this possibility a long time back. We would allow one to configure a suffix to put conflicts in to prevent them from being in the tree that clients use. Yep, Martin please open a 389ds RFE. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 295 Fixed inconsistent required/optional attributes.
The dialogs and details pages have been modified to use the * symbol
to mark required fields. The automount map and the DNS zone dialogs
have been modified to update the required fields according to the
input type.
Ticket #1696
--
Endi S. Dewata
From 1320f4fc2aee116909d13b2dc388b9642815a7d8 Mon Sep 17 00:00:00 2001
From: Endi S. Dewata edew...@redhat.com
Date: Wed, 19 Oct 2011 18:11:09 -0200
Subject: [PATCH] Fixed inconsistent required/optional attributes.
The dialogs and details pages have been modified to use the * symbol
to mark required fields. The automount map and the DNS zone dialogs
have been modified to update the required fields according to the
input type.
Ticket #1696
---
install/ui/aci.js |6 +-
install/ui/add.js | 136 --
install/ui/automount.js| 28 +++--
install/ui/details.js | 49 +
install/ui/dns.js | 222
install/ui/hbac.js |3 +-
install/ui/host.js | 12 +-
install/ui/ipa.css |7 +-
install/ui/policy.js |8 +-
install/ui/service.js | 63 ++-
install/ui/sudo.js |3 +-
install/ui/test/data/ipa_init.json |2 +-
install/ui/test/details_tests.js |5 +-
install/ui/user.js |5 +-
install/ui/widget.js | 34 --
ipalib/plugins/internal.py |2 +-
16 files changed, 307 insertions(+), 278 deletions(-)
diff --git a/install/ui/aci.js b/install/ui/aci.js
index 8dcb540b6a030222136e95d5d01b5a11c29acd7f..7a331118afb05df720429f004202b410ed29eac5 100644
--- a/install/ui/aci.js
+++ b/install/ui/aci.js
@@ -35,11 +35,7 @@ IPA.entity_factories.permission = function() {
{
name: 'identity',
fields: [
-{
-factory: IPA.text_widget,
-name: 'cn',
-read_only: true
-}
+'cn'
]
},
{
diff --git a/install/ui/add.js b/install/ui/add.js
index 17418aaba4f0fe623483323a13c3d5cd608f4c71..3091c921b5fce5235d214b1654ae5cfec0e4ca25 100644
--- a/install/ui/add.js
+++ b/install/ui/add.js
@@ -35,7 +35,72 @@ IPA.add_dialog = function (spec) {
that.retry = typeof spec.retry !== 'undefined' ? spec.retry : true;
that.command = null;
-function show_edit_page(entity,result){
+that.show_edit_page = spec.show_edit_page || show_edit_page;
+
+var init = function() {
+that.create_button({
+name: 'add',
+label: IPA.messages.buttons.add,
+click: function() {
+that.hide_message();
+that.add(
+function(data, text_status, xhr) {
+var facet = IPA.current_entity.get_facet();
+var table = facet.table;
+table.refresh();
+that.close();
+},
+that.on_error);
+}
+});
+
+that.create_button({
+name: 'add_and_add_another',
+label: IPA.messages.buttons.add_and_add_another,
+click: function() {
+that.hide_message();
+that.add(
+function(data, text_status, xhr) {
+var label = that.entity.metadata.label_singular;
+var message = IPA.messages.dialogs.add_confirmation;
+message = message.replace('${entity}', label);
+that.show_message(message);
+
+var facet = IPA.current_entity.get_facet();
+var table = facet.table;
+table.refresh();
+that.reset();
+},
+that.on_error);
+}
+});
+
+that.create_button({
+name: 'add_and_edit',
+label: IPA.messages.buttons.add_and_edit,
+click: function() {
+that.hide_message();
+that.add(
+function(data, text_status, xhr) {
+that.close();
+var result = data.result.result;
+that.show_edit_page(that.entity, result);
+},
+that.on_error);
+}
+});
+
+that.create_button({
+name: 'cancel',
+label: IPA.messages.buttons.cancel,
+click: function() {
+that.hide_message();
+that.close();
+}
+});
+};
+
+function show_edit_page(entity,result) {
var pkey_name = entity.metadata.primary_key;
var pkey = result[pkey_name];
if (pkey instanceof
Re: [Freeipa-devel] LDAP conflicts resolution API
On Thu, 2011-10-20 at 08:34 -0700, Nathan Kinder wrote: On 10/20/2011 07:57 AM, Martin Kosek wrote: On Thu, 2011-10-20 at 07:18 -0700, Nathan Kinder wrote: On 10/19/2011 11:22 PM, Martin Kosek wrote: On Wed, 2011-10-19 at 09:51 -0600, Rich Megginson wrote: On 10/19/2011 09:46 AM, Simo Sorce wrote: On Wed, 2011-10-19 at 17:33 +0200, Martin Kosek wrote: ... 3) When user decides what to do with the conflicting object, he would use the following commands: ipa conflict-rename DN NEW_RDN This command would change the conflicting LDAP objects RDN to foo2.example.com: $ ipa conflict-rename 'nsuniqueid=af8a5d81-fa6011e0-bb339359-34a214df+fqdn=foo.example.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com' foo2.example.com OR ipa conflict-del DN This command would delete conflicting LDAP objects altogether: ipa conflict-del 'nsuniqueid=af8a5d81-fa6011e0-bb339359-34a214df+fqdn=foo.example.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com' Thoughts, comments? Sounds good to me. But I wonder if we can tell DS to create/move these conflicting objects into a cn=conflicts subtree by means of configuration ? Not automatically, no. So maybe a new DS plugin should do the trick? We would just have to store original DN to some attribute if we want to enable user to just rename the conflicting object to its original location. No, I think an RFE to change the existing replication plug-in to allow an alternate conflict area would be best. Simo and I had discussed this possibility a long time back. We would allow one to configure a suffix to put conflicts in to prevent them from being in the tree that clients use. I already implemented the conflict-find, conflict-show and conflict-rename commands. But I really like your idea. Conflicts can cause quite unpredictable effects for the user. Not every user can be experienced enough to guess the replication conflicts cause that issues and use the new conflict-* commands to fix it. If all conflicts are stored to a special suffix, the end user experience will be much better. I can adapt new commands so that user can manage the conflicts when he get to it without side effects other ipa commands. Nathan, do you think you will be able to implement this change for RHEL 6.3.0? I can create a RFE bugzilla. Go ahead and create the RFE bug against 389. We will discuss it in our weekly DS bug triage on Monday to determine the timeline. https://bugzilla.redhat.com/show_bug.cgi?id=747701 Thanks, Martin Thanks, Martin Martin It would certainly cause some entries to disappear, but it would also prevent some of the issues with have those entries. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
