[Freeipa-devel] [PATCH] 851-852 webui: datetime widget with datepicker
Datetime widget was transform from a simple text input to 3 separate inputs:
- date with bootstrap-datepicker
- hour
- minute
e.g.:
Validity end[ 2015-05-18 ] [23]:[01] UTC
Vendor[ abc]
Editation of seconds is not supported.
https://fedorahosted.org/freeipa/ticket/4347
--
Petr Vobornik
From 1c999d27c5f0e6dd07a2ac4b513a1d2b9409a534 Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Mon, 18 May 2015 14:29:03 +0200
Subject: [PATCH] webui: datetime widget with datepicker
Datetime widget was transform from a simple text input to 3 separate inputs:
- date with bootstrap-datepicker
- hour
- minute
e.g.:
Validity end[ 2015-05-18 ] [23]:[01] UTC
Vendor[ abc]
Editation of seconds is not supported.
https://fedorahosted.org/freeipa/ticket/4347
---
install/ui/less/widgets.less | 26
install/ui/src/freeipa/field.js | 4 -
install/ui/src/freeipa/widget.js | 250 ++-
3 files changed, 275 insertions(+), 5 deletions(-)
diff --git a/install/ui/less/widgets.less b/install/ui/less/widgets.less
index cafd3bd96264c0c1ad86a773b8ffd7f15874575f..066e074a044fc25f88ca8060c6ead2edd9d11cb0 100644
--- a/install/ui/less/widgets.less
+++ b/install/ui/less/widgets.less
@@ -91,5 +91,31 @@
max-width: 400px;
}
+// Datetime widget
+.input-group .form-control.datetime-hour,
+.input-group .form-control.datetime-minutes {
+width: 30px;
+}
+
+.datetime-widget .time-cnt {
+width: 1%;
+display: table-cell;
+
+.input-group-addon {
+border: 0;
+background: transparent;
+}
+
+.time-separator {
+padding-left: 2px;
+padding-right: 2px;
+}
+}
+
+.datetime-widget .time-group {
+display: table;
+padding-left: 10px
+}
+
// workaround for https://bugzilla.mozilla.org/show_bug.cgi?id=409254
tbody:empty { display: none; }
\ No newline at end of file
diff --git a/install/ui/src/freeipa/field.js b/install/ui/src/freeipa/field.js
index d8e249b2c5dc447d626eda88d06c828674692c6f..f26033ce25a15cface945eeecc69ca503179d30c 100644
--- a/install/ui/src/freeipa/field.js
+++ b/install/ui/src/freeipa/field.js
@@ -1122,10 +1122,6 @@ field.datetime_field = IPA.datetime_field = function(spec) {
template: datetime.templates.generalized
};
spec.data_parser = spec.formatter || 'datetime';
-spec.ui_formatter = spec.ui_formatter || spec.formatter || {
-$type: 'datetime',
-template: datetime.templates.human
-};
spec.ui_parser = spec.ui_parser || 'datetime';
var that = IPA.field(spec);
diff --git a/install/ui/src/freeipa/widget.js b/install/ui/src/freeipa/widget.js
index 125d499b683557fec9f9ece6007d3560f03ee025..1b9f7585f7e1c01b260df13d9e95a06c41958a7b 100644
--- a/install/ui/src/freeipa/widget.js
+++ b/install/ui/src/freeipa/widget.js
@@ -2473,6 +2473,254 @@ IPA.dn_formatter = function(spec) {
};
/**
+ * Datetime widget
+ * @class
+ * @extends IPA.input_widget
+ */
+IPA.datetime_widget = function(spec) {
+
+spec = spec || {};
+
+var that = IPA.input_widget(spec);
+
+that.base_css_class = that.base_css_class + ' datetime-widget';
+that.date_format = spec.data_format || '-mm-dd';
+that.date_format_tmpl = spec.date_format_tmpl || '${}-${MM}-${DD}';
+that._seconds = null;
+that._tab_pressed = false;
+
+/**
+ * bootstrap-datepicker options
+ *
+ * spec property: 'options'
+ *
+ * @property {Object}
+ */
+that.datepicker_options = lang.extend({
+format: that.date_format,
+clearBtn: true,
+autoclose: true
+}, spec.options || {});
+
+/**
+ * @inheritDoc
+ */
+that.create = function(container) {
+
+that.widget_create(container);
+
+var id_date = IPA.html_util.get_next_id(that.name);
+var id_hour = IPA.html_util.get_next_id(that.name);
+var id_min = IPA.html_util.get_next_id(that.name);
+
+// UI used if user doesn't have write rights:
+that.display_control = $('p/', {
+name: that.name,
+'class': 'form-control-static',
+style: 'display: none;'
+}).appendTo(container);
+
+// editable UI:
+that.input_group = $('div/', {
+'class': 'input-group',
+keyup: function(e) {
+if (e.keyCode === 9) that._tab_pressed = false;
+}
+}).appendTo(container);
+
+that.date_input = $('input/', {
+type: 'text',
+name: that.name,
+id: id_date,
+placeholder: that.date_format.toUpperCase(),
+'class': 'form-control datetime-date',
+keydown: function(e) {
+if (e.keyCode === 9) that._tab_pressed = true;
+}
+}).appendTo(that.input_group);
+
+var time_cnt = $('div/', {
+'class': 'time-cnt'
+
[Freeipa-devel] [PATCH 0367] Support unknown record types (RFC 3597)
Hello,
This patch is unrelated to metaDB but it should be merged before alpha, too.
Thank you for review!
Support unknown record types (RFC 3597).
Fallback to generic LDAP attribute UnknownRecord;TYP256 if attempt to
add specific attribute like URIRecord failed with LDAP_OBJECT_CLASS_VIOLATION
and always delete both attributes like URIRecord and UnknownRecord;TYPE256.
https://fedorahosted.org/bind-dyndb-ldap/ticket/157
--
Petr^2 Spacek
From 5512e894880eea1d32800f76eaf112612d4bc525 Mon Sep 17 00:00:00 2001
From: Petr Spacek pspa...@redhat.com
Date: Mon, 16 Mar 2015 22:40:36 +0100
Subject: [PATCH] Support unknown record types (RFC 3597).
Fallback to generic LDAP attribute UnknownRecord;TYP256 if attempt to
add specific attribute like URIRecord failed with LDAP_OBJECT_CLASS_VIOLATION
and always delete both attributes like URIRecord and UnknownRecord;TYPE256.
https://fedorahosted.org/bind-dyndb-ldap/ticket/157
---
src/ldap_convert.c | 67 +++--
src/ldap_convert.h | 13 ++--
src/ldap_driver.c | 9 ++
src/ldap_helper.c | 88 --
src/ldap_helper.h | 5 ++--
5 files changed, 146 insertions(+), 36 deletions(-)
diff --git a/src/ldap_convert.c b/src/ldap_convert.c
index dde10d6e989159e9f6f5086a4a12bbd165b73646..0bdb83547bec74d0f2954a4e8443ef2b70347cf8 100644
--- a/src/ldap_convert.c
+++ b/src/ldap_convert.c
@@ -19,11 +19,13 @@
*/
#include isc/buffer.h
+#include isc/hex.h
#include isc/mem.h
#include isc/util.h
#include isc/string.h
#include dns/name.h
+#include dns/rdata.h
#include dns/result.h
#include dns/types.h
@@ -394,33 +396,80 @@ ldap_attribute_to_rdatatype(const char *ldap_attribute, dns_rdatatype_t *rdtype)
/* Does attribute name end with RECORD_SUFFIX? */
if (strcasecmp(ldap_attribute + len - LDAP_RDATATYPE_SUFFIX_LEN,
- LDAP_RDATATYPE_SUFFIX))
+ LDAP_RDATATYPE_SUFFIX) == 0) {
+ region.base = ldap_attribute;
+ region.length = len - LDAP_RDATATYPE_SUFFIX_LEN;
+ /* Does attribute name start with with UNKNOWN_PREFIX? */
+ } else if (strncasecmp(ldap_attribute,
+ LDAP_RDATATYPE_UNKNOWN_PREFIX,
+ LDAP_RDATATYPE_UNKNOWN_PREFIX_LEN) == 0) {
+ region.base = ldap_attribute + LDAP_RDATATYPE_UNKNOWN_PREFIX_LEN;
+ region.length = len - LDAP_RDATATYPE_UNKNOWN_PREFIX_LEN;
+ } else
return ISC_R_UNEXPECTED;
- region.base = ldap_attribute;
- region.length = len - LDAP_RDATATYPE_SUFFIX_LEN;
result = dns_rdatatype_fromtext(rdtype, (isc_textregion_t *)region);
if (result != ISC_R_SUCCESS)
log_error_r(dns_rdatatype_fromtext() failed for attribute '%s',
ldap_attribute);
return result;
}
+/**
+ * Convert DNS rdata type to LDAP attribute name.
+ *
+ * @param[in] rdtype
+ * @param[out] target Output buffer with \0 terminated attribute name.
+ * @param[in] size Target size.
+ * @param[in] unknown ISC_TRUE = use generic syntax UnknownRecord;TYPE65333,
+ * ISC_FALSE = use type-specific mnemonic like ARecord
+ */
isc_result_t
rdatatype_to_ldap_attribute(dns_rdatatype_t rdtype, char *target,
- unsigned int size)
+ unsigned int size, isc_boolean_t unknown)
{
isc_result_t result;
char rdtype_str[DNS_RDATATYPE_FORMATSIZE];
- dns_rdatatype_format(rdtype, rdtype_str, DNS_RDATATYPE_FORMATSIZE);
- CHECK(isc_string_copy(target, size, rdtype_str));
- CHECK(isc_string_append(target, size, LDAP_RDATATYPE_SUFFIX));
-
- return ISC_R_SUCCESS;
+ if (unknown) {
+ /* UnknownRecord;TYPE65333 */
+ CHECK(isc_string_copy(target, size,
+ LDAP_RDATATYPE_UNKNOWN_PREFIX));
+ snprintf(rdtype_str, sizeof(rdtype_str), TYPE%u, rdtype);
+ CHECK(isc_string_append(target, size, rdtype_str));
+ } else {
+ /* ARecord */
+ dns_rdatatype_format(rdtype, rdtype_str, DNS_RDATATYPE_FORMATSIZE);
+ CHECK(isc_string_copy(target, size, rdtype_str));
+ CHECK(isc_string_append(target, size, LDAP_RDATATYPE_SUFFIX));
+ }
cleanup:
return result;
}
+/**
+ * Convert rdata to generic (RFC 3597) format.
+ */
+isc_result_t
+rdata_to_generic(dns_rdata_t *rdata, isc_buffer_t *target)
+{
+ isc_result_t result;
+ isc_region_t rdata_reg;
+ char buf[sizeof(\\# 65535)];
+
+ dns_rdata_toregion(rdata, rdata_reg);
+ REQUIRE(rdata_reg.length = 65535);
+
+ result = isc_string_printf(buf, sizeof(buf), \\# %u, rdata_reg.length);
+ INSIST(result == ISC_R_SUCCESS);
+ isc_buffer_putstr(target, buf);
+ if (rdata_reg.length != 0U) {
+ isc_buffer_putstr(target, );
+ CHECK(isc_hex_totext(rdata_reg, 0, , target));
+ }
+
+cleanup:
+ return result;
+}
diff --git a/src/ldap_convert.h b/src/ldap_convert.h
index daa0db0b311dd51c05ade688715550d9f70759ac..3810468af5591dbef1776c5e1ca91764b53df126 100644
--- a/src/ldap_convert.h
+++ b/src/ldap_convert.h
@@ -28,8 +28,10 @@
#include zone_register.h
#define LDAP_ATTR_FORMATSIZE 32 /* expected maximum attribute name length */
-#define LDAP_RDATATYPE_SUFFIX Record
-#define
Re: [Freeipa-devel] ipa wiki formatting
On 05/18/2015 02:51 PM, Ludwig Krispenz wrote: Hi, for our docs on the wiki there is a table of contents, which is created from the section headers an the sections in the table of contents are automatically numbered, eg 1. first chapter 1.1 subchapter 1.2 next sub 2. second but in the body of the document these numbers are not there by default, so when scrolling thru a larger document the level of a chapter is lost. There are two options to change this - change your user profile to keep the numbering in the document body - change the site profile, so that the numbering is always preserverd (can probably induvidually turne off again). Does anyone oppose to change the default ? I am not sure this is the right question - as no answers would mean we want to do this rather drastic change :-) This is the respective information from Mediawiki side: http://www.mediawiki.org/wiki/Manual:Table_of_contents#Auto-numbering I am personally cautious about just changing the default as this is not a way what big wiki sites use and I was also afraid it would change not only design pages, but also our title page for example, as it uses sections too. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0364] Remove unused files rdlist.c and rdlist.h
On (15/05/15 11:44), Petr Spacek wrote: Hello, Remove unused files rdlist.c and rdlist.h. I noticed this cruft while preparing the previous patchset. This patch is independent and applicable directly to master branch. I had an issue with applicable directly to master branch :-) I had to use 3-way merge. From 274f5ea92866c50c77c59f6dabc64c3bdf162ace Mon Sep 17 00:00:00 2001 From: Petr Spacek pspa...@redhat.com Date: Fri, 15 May 2015 11:41:02 +0200 Subject: [PATCH] Remove unused files rdlist.c and rdlist.h. --- src/Makefile.am | 2 - src/ldap_driver.c | 1 - src/ldap_helper.c | 1 - src/rdlist.c| 261 src/rdlist.h| 46 - src/zone_register.c | 1 - 6 files changed, 312 deletions(-) delete mode 100644 src/rdlist.c delete mode 100644 src/rdlist.h Functions are not used since commit a78db0312873babbccd4a94dec90b46b02c694ad Author: Petr Spacek pspa...@redhat.com Date: Wed Aug 14 14:41:17 2013 +0200 Use RBTDB instead of internal LDAP cache. make distcheck passed. ACK LS -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Revoking user/service/host certificates
On Mon, May 18, 2015 at 11:51:41AM +0200, Martin Kosek wrote:
Hi Fraser (and list),
Recently, we have proposed 2 new policies for treating user/host/service
certificates based on the per-profile policy:
a) If certificate is stored in userCertificate attribute
b) If the certificate is stored and object deleted/disabled, if the
certificate
should be also revoked
Details in:
http://www.freeipa.org/page/V4/User_Certificates#Configuration
a) is straightforward. However, I was not thinking more about case b). When
object is deleted/disabled, how will framework tell what is the profile to
check the policy?
Will it ask Dogtag via some API call? Or will the profile me stored in the
certificate itself, just like MS CA does for some certificates?
That information is stored in Dogtag, but I don't think there's
currently a straightforward way to get at it. Having it stored in
Dogtag (only) would necessitate first contacting Dogtag and looking
up the profile for each certificate to find out whether we should
revoke or not.
I do not think we should implement anything that relies on the MS
certificate template extension (in case it is not wanted, or even
causes problems for some application).
But let us take a step back - is there a situation where for one
profile (for which ipaCertProfileStoreIssued == True) we would want
to automatically revoke when principal deleted, and for another
profile not revoke? Or would it be better as a global setting or a
{user,host,service}-del option?
We would also need to work out a revocationReason; we could use
unspecified to start with, but can we / should be provide
something richer?
Cheers,
Fraser
Thanks.
--
Martin Kosek mko...@redhat.com
Supervisor, Software Engineering - Identity Management Team
Red Hat Inc.
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] ipa wiki formatting
Hi, for our docs on the wiki there is a table of contents, which is created from the section headers an the sections in the table of contents are automatically numbered, eg 1. first chapter 1.1 subchapter 1.2 next sub 2. second but in the body of the document these numbers are not there by default, so when scrolling thru a larger document the level of a chapter is lost. There are two options to change this - change your user profile to keep the numbering in the document body - change the site profile, so that the numbering is always preserverd (can probably induvidually turne off again). Does anyone oppose to change the default ? Ludwig -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Revoking user/service/host certificates
On 05/18/2015 03:36 PM, Fraser Tweedale wrote:
On Mon, May 18, 2015 at 11:51:41AM +0200, Martin Kosek wrote:
Hi Fraser (and list),
Recently, we have proposed 2 new policies for treating user/host/service
certificates based on the per-profile policy:
a) If certificate is stored in userCertificate attribute
b) If the certificate is stored and object deleted/disabled, if the
certificate
should be also revoked
Details in:
http://www.freeipa.org/page/V4/User_Certificates#Configuration
a) is straightforward. However, I was not thinking more about case b). When
object is deleted/disabled, how will framework tell what is the profile to
check the policy?
Will it ask Dogtag via some API call? Or will the profile me stored in the
certificate itself, just like MS CA does for some certificates?
That information is stored in Dogtag, but I don't think there's
currently a straightforward way to get at it. Having it stored in
Dogtag (only) would necessitate first contacting Dogtag and looking
up the profile for each certificate to find out whether we should
revoke or not.
I do not think we should implement anything that relies on the MS
certificate template extension (in case it is not wanted, or even
causes problems for some application).
I see.
But let us take a step back - is there a situation where for one
profile (for which ipaCertProfileStoreIssued == True) we would want
to automatically revoke when principal deleted, and for another
profile not revoke? Or would it be better as a global setting or a
{user,host,service}-del option?
An option would definitely be a good start, if we do not go with the
per-profile setting. Simo/Rob/others, what is your opinion here, given there is
a big difficulty in implementing per-profile policy for revoking the
certificate? Should we instead have a global configuration that would say
A) Revoke all certificates in userCertificate attribute (i.e. long term
certificates)
B) Do not revoke them
and have the option to force a change to the behavior?
We would also need to work out a revocationReason; we could use
unspecified to start with, but can we / should be provide
something richer?
Right now, when service or host is disabled/deleted, we use revocation reason
* 4 - superseded
Martin
Cheers,
Fraser
Thanks.
--
Martin Kosek mko...@redhat.com
Supervisor, Software Engineering - Identity Management Team
Red Hat Inc.
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 0005 User life cycle: del/mod/find/show stageuser commands
On 05/15/2015 04:44 PM, David Kupka wrote: Hello Thierry, thanks for the patch set. Overall functionality of ULC feature looks good to me and is definitely alpha ready. I found following issues but don't insist on fixing it right now: 1) When stageuser-activate fails due to already existent active/deleted user. DN is show instead of user name that's used in other commands (user-add, stageuser-add). $ ipa user-add tuser --first Test --last User $ ipa stageuser-add tuser --first Test --last User $ ipa stageuser-activate tuser ipa: ERROR: Active user uid=tuser,cn=users,cn=accounts,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com already exists Hi David, Jan, Thanks you so much for all those tests and feedback. I agree, some minor bugs can be fixed separatly from this main patches. You are right, It should return the user ID not the DN. 2) According to the design there should be '--only-delete' and '--also-delete' options for user-find command instead there is '--preserved' option. Honza proposed adding virtual boolean attribute 'deleted' to user entry and filter on it. The 'deleted' attribute would be useful also in user-show where is no way to tell if the displayed user is active or deleted. (Except running with --all and looking on the dn). Yes a bit late to resynch the design. The final option is 'preserved' for user-find and 'preserve' for user-del. '--only-delete' or 'also-delete' are old name that I need to replace in the design. About the 'deleted' attribute, do you think adding a DS cos virtual attribute ? 3) uidNumber and gidNumber can't be set back to '-1' once set to other value. This would be useful when admin changes its mind and want IPA to assign them. IIUC, there should be no validation in cn=staged user container. All validation should be done during stageuser-activate. Yes that comes from user plugin that enforce the number to be 0. That is a good point giving the ability to reset uidNumber/gidNumber. I will check if it is possible, how (give a value or an option to reset), and also if it would not create other issue. 4) Support for deleted - stage workflow is still missing. But I'm unsure if we agreed to finish it now or later. Yes thanks 5) Twice deleting user with '--preserve' deletes him permanently. $ ipa user-add tuser --first Test --last User $ ipa user-del tuser --preserve $ ipa user-del tuser --preserve $ ipa user-find --preserved 0 (delete) users matched Number of entries returned 0 Deleting a deleted (preserved) entry, should permanently remove the entry. Now if the second time the preserve option is present, it makes sense to not delete it. thanks theirry David - Original Message - From: thierry bordaz tbor...@redhat.com To: Jan Cholasta jchol...@redhat.com, David Kupka dku...@redhat.com Cc: freeipa-devel freeipa-devel@redhat.com Sent: Tuesday, May 12, 2015 5:05:29 PM Subject: Re: [Freeipa-devel] [PATCH] 0005 User life cycle: del/mod/find/show stageuser commands On 05/12/2015 02:17 PM, thierry bordaz wrote: On 05/05/2015 08:57 AM, Jan Cholasta wrote: Hi, Dne 28.4.2015 v 16:40 thierry bordaz napsal(a): On 04/28/2015 10:40 AM, David Kupka wrote: On 04/28/2015 10:28 AM, thierry bordaz wrote: On 04/28/2015 10:23 AM, David Kupka wrote: On 04/16/2015 01:00 PM, thierry bordaz wrote: Hello, Here is the next patch for User life cycle that introduces del/mod/find and show stageuser plugin commands. * -User Life Cycle (create containers and scoping DS plugins): *pushed* * 0001-User-Life-Cycle-Exclude-subtree-for-ipaUniqueID-gene.patch: *pushed* * 0002-User-life-cycle-stageuser-add-verb.patch: *pushed* * 0007-User-life-cycle-allows-MODRDN-from-ldap2.patch: *pushed* * 0003-User-life-cycle-new-stageuser-commands-del-mod-find-*under review *(this one)** * 0004-User-life-cycle-new-stageuser-commands-activate.patch * 0005-User-life-cycle-new-stageuser-commands-activate-prov.patch * 0006-User-life-cycle-user-del-supports-permanently-preser.patch * 0008-User-life-cycle-user-find-support-finding-delete-use.patch * 0009-User-life-cycle-support-of-user-undel.patch * 0010-User-life-cycle-DNA-DS-plugin-should-exclude-provisi.patch * 0011-User-life-cycle-lockout-provisioning-stage-and-delet.patch * 0012-User-life-cycle-Create-stage-Admin-provisioning-acco.patch * 0013-User-life-cycle-Stage-Admin-permission-priviledge.patch Thanks thierry Hi Thierry, thanks for the patch, the code looks good to me but there is probably a bug in ACIs. After creating a stage user and setting password for him I can kinit as the stage user. I'm unable to login to the IPA client and id command for this stage user responds no such user but I can kinit and invoke ipa commands. Steps: 0. build freeipa with your patch 1. # ipa-server-install 2. $ kinit admin 3. $ ipa stageuser-add
Re: [Freeipa-devel] [PATCH] 0005 User life cycle: del/mod/find/show stageuser commands
On 05/15/2015 04:44 PM, David Kupka wrote: Hello Thierry, thanks for the patch set. Overall functionality of ULC feature looks good to me and is definitely alpha ready. I found following issues but don't insist on fixing it right now: Given we are now only fixing bugs and not doing big structural changes, I would rather like to push what we have and then work on fixing the bugs that are critical for the feature. Some may be before Alpha, some after Alpha or even 4.2.1 or later versions - depending on the impact. 1) When stageuser-activate fails due to already existent active/deleted user. DN is show instead of user name that's used in other commands (user-add, stageuser-add). $ ipa user-add tuser --first Test --last User $ ipa stageuser-add tuser --first Test --last User $ ipa stageuser-activate tuser ipa: ERROR: Active user uid=tuser,cn=users,cn=accounts,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com already exists Please file ticket, can be fixed in 4.2.1 or later IMO. 2) According to the design there should be '--only-delete' and '--also-delete' options for user-find command instead there is '--preserved' option. Honza proposed adding virtual boolean attribute 'deleted' to user entry and filter on it. The 'deleted' attribute would be useful also in user-show where is no way to tell if the displayed user is active or deleted. (Except running with --all and looking on the dn). Please file ticket as well. As I talked to David, it is now difficult to distinguish between active and deleted users, user-show USER shows the user regardless if the user is active or deleted. This is something we should discuss, what is the ideal behavior. Please include this question in the ticket. 3) uidNumber and gidNumber can't be set back to '-1' once set to other value. This would be useful when admin changes its mind and want IPA to assign them. IIUC, there should be no validation in cn=staged user container. All validation should be done during stageuser-activate. We may want with filing a ticket unless there is a real demand for this. 4) Support for deleted - stage workflow is still missing. But I'm unsure if we agreed to finish it now or later. We wanted to do it also, but based on Thierry's availability, it can be done post-Alpha or even 4.2.1. 5) Twice deleting user with '--preserve' deletes him permanently. $ ipa user-add tuser --first Test --last User $ ipa user-del tuser --preserve $ ipa user-del tuser --preserve $ ipa user-find --preserved 0 (delete) users matched Number of entries returned 0 This looks as something we may want to fix before GA. Pushed to master: 273fd057a3be797a05d6c7f34fd619d3dfa09c37 When the UI (on review) is also pushed, we will have the base ULC functionality here and we can close the main RFE. Thanks everyone! Martin -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] Fwd: Re: ipa topology command
Hi, I started this discussion with Petr, but he thinks it should be better discussed here. Ludwig Original Message Subject:Re: ipa topology command Date: Mon, 18 May 2015 17:48:10 +0200 From: Petr Vobornik pvobo...@redhat.com To: Ludwig Krispenz lkris...@redhat.com On 05/18/2015 04:25 PM, Ludwig Krispenz wrote: Hi, when testing I noticed an incompleteness in the topologysegment-mod function. A segment can be onedirectional or bidirectional, and with topologysegment-mod one should be able to modify params of the corresponding replication agreement(s). In the design I had a concept of attributename[;left | ;right ] to apply the change to one or both directions. In the plugin this is implemented, but in the ipa comand it isn't. I thought it wouldn't matter since in ipa we want to have replication agreements identical. But there is one important exception: init ( nsds5beginreplicarefresh ), which should always be onedirectional. Do you have an idea how to simply chnage this ? Thanks, Ludwig This should be probably discussed on the devel list, feel free to resend it there. I'm not sure if I understand the issue correctly. But will try. Subtypes are not widely used in ipalib yet so there might be some dragons. I general an attribute with known subtypes should be handled as multiple distinct attributes(params in ipalib), e.g.,: nsds5beginreplicarefresh;left nsds5beginreplicarefresh;right The main question is for which attributes we should support specifying both direction. Wrt init: I actually didn't know what the attribute was for but after reading [1] I think that this attribute shouldn't be handled as a free-form string attribute because it starts an operation and then displays its status until it finishes. If the plugin updates the attribute with the initialization state then IMHO these are the step we should take (details could be different): 1. create both attributes: Str( 'nsds5beginreplicarefresh;left', cli_name='init-left', label='Left node initialization', doc='Status of initialization of left node', flags=['no_create', 'no_update', 'no_search'], ), Str( 'nsds5beginreplicarefresh;right', cli_name='init-right', label='Right node initialization', doc='Status of initialization of right node', flags=['no_create', 'no_update', 'no_search'], ), The attribute was made read-only so it can't be modified using segment-mod but segment-show would show its status. 2. Create: ipa topologysegment-init SEGMENT 'left'|'right' It would set 'start' to: nsds5beginreplicarefresh;left or nsds5beginreplicarefresh;right This would start the initialization process of the chosen node. 3. Create: ipa topologysegment-stop-init SEGMENT 'left'|'right' It would set 'stop' to: nsds5beginreplicarefresh;left or nsds5beginreplicarefresh;right This would stop the initialization process of the chosen node. An alternative could be `ipa topologysegment-init SEGMENT 'left'|'right' --stop` 4. Examine other nsds5* attributes if they require similar change or a change in accepted values (eg, int for nsds5replicatimeout, on|off for nsds5replicaenabled, ...) Btw, what about nsDS5ReplicaLastInitStart|Status|End attrs, is there a plan to support them by the plugin and management UI? For the alpha, we could go just with bare params and mod command enabled and then add the separate commands later. [1] https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#Replication_Attributes_under_cnReplicationAgreementName_cnreplica_cnsuffixName_cnmapping_tree_cnconfig-nsDS5BeginReplicaRefresh -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Fwd: Re: ipa topology command
On 05/18/2015 06:05 PM, Ludwig Krispenz wrote: Hi, I started this discussion with Petr, but he thinks it should be better discussed here. Ludwig Original Message Subject:Re: ipa topology command Date: Mon, 18 May 2015 17:48:10 +0200 From: Petr Vobornik pvobo...@redhat.com To: Ludwig Krispenz lkris...@redhat.com On 05/18/2015 04:25 PM, Ludwig Krispenz wrote: Hi, when testing I noticed an incompleteness in the topologysegment-mod function. A segment can be onedirectional or bidirectional, and with topologysegment-mod one should be able to modify params of the corresponding replication agreement(s). In the design I had a concept of attributename[;left | ;right ] to apply the change to one or both directions. In the plugin this is implemented, but in the ipa comand it isn't. I thought it wouldn't matter since in ipa we want to have replication agreements identical. But there is one important exception: init ( nsds5beginreplicarefresh ), which should always be onedirectional. Do you have an idea how to simply chnage this ? Thanks, Ludwig This should be probably discussed on the devel list, feel free to resend it there. I'm not sure if I understand the issue correctly. But will try. Subtypes are not widely used in ipalib yet so there might be some dragons. I general an attribute with known subtypes should be handled as multiple distinct attributes(params in ipalib), e.g.,: nsds5beginreplicarefresh;left nsds5beginreplicarefresh;right ok, for this special attribute it would make sense since initializatiion (refresh should be only in one direction), same is probably true for 'enable'. for other manage attrs, attributename: value should apply to both directions (in a bidirectional segment) attributename;left: value or attributename;right: value should override the settings for one direction, at the moment I don't see a valid use case, but since a bidirectional segment handles two replication agreements, I did at least provide the possibility. But except nsds5beginreplicarefresh I don't think we need to provide this in the first versioj of the ipa command. The main question is for which attributes we should support specifying both direction. Wrt init: I actually didn't know what the attribute was for but after reading [1] I think that this attribute shouldn't be handled as a free-form string attribute because it starts an operation and then displays its status until it finishes. it just updates the attribute of the segment, the modification is replicated to all other servers and the master whom it concerns will start an online init, no automatic monitoring provided. If you want this, we need to extend what status information is mainained in the shared tree. If the plugin updates the attribute with the initialization state then IMHO these are the step we should take (details could be different): 1. create both attributes: Str( 'nsds5beginreplicarefresh;left', cli_name='init-left', label='Left node initialization', doc='Status of initialization of left node', flags=['no_create', 'no_update', 'no_search'], ), Str( 'nsds5beginreplicarefresh;right', cli_name='init-right', label='Right node initialization', doc='Status of initialization of right node', flags=['no_create', 'no_update', 'no_search'], ), yes that would do it, maybe init-fromleft or init-from-right would be clearer The attribute was made read-only so it can't be modified using segment-mod but segment-show would show its status. what do you mean by was made read-only ? 2. Create: ipa topologysegment-init SEGMENT 'left'|'right' It would set 'start' to: nsds5beginreplicarefresh;left or nsds5beginreplicarefresh;right This would start the initialization process of the chosen node. 3. Create: ipa topologysegment-stop-init SEGMENT 'left'|'right' It would set 'stop' to: nsds5beginreplicarefresh;left or nsds5beginreplicarefresh;right This would stop the initialization process of the chosen node. An alternative could be `ipa topologysegment-init SEGMENT 'left'|'right' --stop` 4. Examine other nsds5* attributes if they require similar change or a change in accepted values (eg, int for nsds5replicatimeout, on|off for nsds5replicaenabled, ...) Btw, what about nsDS5ReplicaLastInitStart|Status|End attrs, is there a plan to support them by the plugin and management UI? For the alpha, we could go just with bare params and mod command enabled and then add the separate commands later. [1] https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#Replication_Attributes_under_cnReplicationAgreementName_cnreplica_cnsuffixName_cnmapping_tree_cnconfig-nsDS5BeginReplicaRefresh -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list:
Re: [Freeipa-devel] Fwd: Re: ipa topology command
On 05/18/2015 06:21 PM, Ludwig Krispenz wrote:
On 05/18/2015 06:05 PM, Ludwig Krispenz wrote:
Hi,
I started this discussion with Petr, but he thinks it should be better
discussed here.
Ludwig
Original Message
Subject: Re: ipa topology command
Date: Mon, 18 May 2015 17:48:10 +0200
From: Petr Vobornik pvobo...@redhat.com
To: Ludwig Krispenz lkris...@redhat.com
On 05/18/2015 04:25 PM, Ludwig Krispenz wrote:
Hi,
when testing I noticed an incompleteness in the topologysegment-mod
function.
A segment can be onedirectional or bidirectional, and with
topologysegment-mod one should be able to modify params of the
corresponding replication agreement(s). In the design I had a
concept of
attributename[;left | ;right ] to apply the change to one or both
directions. In the plugin this is implemented, but in the ipa comand it
isn't. I thought it wouldn't matter since in ipa we want to have
replication agreements identical.
But there is one important exception: init (
nsds5beginreplicarefresh ),
which should always be onedirectional.
Do you have an idea how to simply chnage this ?
Thanks,
Ludwig
I'm not sure if I understand the issue correctly. But will try.
Subtypes are not widely used in ipalib yet so there might be some
dragons. I general an attribute with known subtypes should be handled as
multiple distinct attributes(params in ipalib), e.g.,:
nsds5beginreplicarefresh;left
nsds5beginreplicarefresh;right
ok, for this special attribute it would make sense since initializatiion
(refresh should be only in one direction), same is probably true for
'enable'.
for other manage attrs,
attributename: value should apply to both directions (in a bidirectional
segment)
attributename;left: value
or
attributename;right: value
should override the settings for one direction, at the moment I don't
see a valid use case, but since a bidirectional segment handles two
replication agreements, I did at least provide the possibility.
But except nsds5beginreplicarefresh I don't think we need to provide
this in the first versioj of the ipa command.
The main question is for which attributes we should support specifying
both direction.
Wrt init:
I actually didn't know what the attribute was for but after reading [1]
I think that this attribute shouldn't be handled as a free-form string
attribute because it starts an operation and then displays its status
until it finishes.
it just updates the attribute of the segment, the modification is
replicated to all other servers and the master whom it concerns will
start an online init,
Does stop work as well?
no automatic monitoring provided. If you want this, we need to extend
what status information is mainained in the shared tree.
Since there is no update of state of the init process and the fact that
the attr is cleared when target replica gets the info ('starẗ́'|'stop'),
I think that there is no value in having it as a param(ie output of
-show command) because it will be almost always empty and therefore no
useful information would be displayed to a user.
If the plugin updates the attribute with the
initialization state then IMHO these are the step we should take
(details could be different):
1. create both attributes:
Str(
'nsds5beginreplicarefresh;left',
cli_name='init-left',
label='Left node initialization',
doc='Status of initialization of left node',
flags=['no_create', 'no_update', 'no_search'],
),
Str(
'nsds5beginreplicarefresh;right',
cli_name='init-right',
label='Right node initialization',
doc='Status of initialization of right node',
flags=['no_create', 'no_update', 'no_search'],
),
yes that would do it, maybe init-fromleft or init-from-right would be
clearer
The attribute was made read-only so it can't be modified using
segment-mod but segment-show would show its status.
what do you mean by was made read-only ?
That it won't be listed as an option of topologysegment-mod command and
therefore user is forced to use the init command (if I don't count
--setattr option).
2. Create: ipa topologysegment-init SEGMENT 'left'|'right'
It would set 'start' to:
nsds5beginreplicarefresh;left or nsds5beginreplicarefresh;right
This would start the initialization process of the chosen node.
3. Create: ipa topologysegment-stop-init SEGMENT 'left'|'right'
It would set 'stop' to:
nsds5beginreplicarefresh;left or nsds5beginreplicarefresh;right
This would stop the initialization process of the chosen node.
An alternative could be `ipa topologysegment-init SEGMENT 'left'|'right'
--stop`
4. Examine other nsds5* attributes if they require similar change or a
change in accepted values (eg, int for nsds5replicatimeout, on|off for
nsds5replicaenabled, ...)
Btw, what about nsDS5ReplicaLastInitStart|Status|End attrs, is there a
plan to support them by the plugin and management UI?
For the alpha, we could
Re: [Freeipa-devel] Fwd: Re: ipa topology command
On 05/18/2015 06:37 PM, Petr Vobornik wrote:
On 05/18/2015 06:21 PM, Ludwig Krispenz wrote:
On 05/18/2015 06:05 PM, Ludwig Krispenz wrote:
Hi,
I started this discussion with Petr, but he thinks it should be better
discussed here.
Ludwig
Original Message
Subject: Re: ipa topology command
Date: Mon, 18 May 2015 17:48:10 +0200
From: Petr Vobornik pvobo...@redhat.com
To: Ludwig Krispenz lkris...@redhat.com
On 05/18/2015 04:25 PM, Ludwig Krispenz wrote:
Hi,
when testing I noticed an incompleteness in the topologysegment-mod
function.
A segment can be onedirectional or bidirectional, and with
topologysegment-mod one should be able to modify params of the
corresponding replication agreement(s). In the design I had a
concept of
attributename[;left | ;right ] to apply the change to one or both
directions. In the plugin this is implemented, but in the ipa
comand it
isn't. I thought it wouldn't matter since in ipa we want to have
replication agreements identical.
But there is one important exception: init (
nsds5beginreplicarefresh ),
which should always be onedirectional.
Do you have an idea how to simply chnage this ?
Thanks,
Ludwig
I'm not sure if I understand the issue correctly. But will try.
Subtypes are not widely used in ipalib yet so there might be some
dragons. I general an attribute with known subtypes should be
handled as
multiple distinct attributes(params in ipalib), e.g.,:
nsds5beginreplicarefresh;left
nsds5beginreplicarefresh;right
ok, for this special attribute it would make sense since initializatiion
(refresh should be only in one direction), same is probably true for
'enable'.
for other manage attrs,
attributename: value should apply to both directions (in a bidirectional
segment)
attributename;left: value
or
attributename;right: value
should override the settings for one direction, at the moment I don't
see a valid use case, but since a bidirectional segment handles two
replication agreements, I did at least provide the possibility.
But except nsds5beginreplicarefresh I don't think we need to provide
this in the first versioj of the ipa command.
The main question is for which attributes we should support specifying
both direction.
Wrt init:
I actually didn't know what the attribute was for but after reading [1]
I think that this attribute shouldn't be handled as a free-form string
attribute because it starts an operation and then displays its status
until it finishes.
it just updates the attribute of the segment, the modification is
replicated to all other servers and the master whom it concerns will
start an online init,
Does stop work as well?
nsds5beginreplicarefresh accepts also stop and cancel, but this has
some different meaning, not stopping the online initialization.
I would only care about start, and this is needed.
no automatic monitoring provided. If you want this, we need to extend
what status information is mainained in the shared tree.
Since there is no update of state of the init process and the fact
that the attr is cleared when target replica gets the info
('starẗ́'|'stop'), I think that there is no value in having it as a
param(ie output of -show command) because it will be almost always
empty and therefore no useful information would be displayed to a user.
it is no need to show it in the show command, but ist should be visible
as an option in the topologysegment-mod command, maybe even without
accepting a value,
using init-left-right or init-right-left and automatically providing
start as value.
If the plugin updates the attribute with the
initialization state then IMHO these are the step we should take
(details could be different):
1. create both attributes:
Str(
'nsds5beginreplicarefresh;left',
cli_name='init-left',
label='Left node initialization',
doc='Status of initialization of left node',
flags=['no_create', 'no_update', 'no_search'],
),
Str(
'nsds5beginreplicarefresh;right',
cli_name='init-right',
label='Right node initialization',
doc='Status of initialization of right node',
flags=['no_create', 'no_update', 'no_search'],
),
yes that would do it, maybe init-fromleft or init-from-right would be
clearer
The attribute was made read-only so it can't be modified using
segment-mod but segment-show would show its status.
what do you mean by was made read-only ?
That it won't be listed as an option of topologysegment-mod command
and therefore user is forced to use the init command
which init command do you refer to ?
(if I don't count --setattr option).
2. Create: ipa topologysegment-init SEGMENT 'left'|'right'
It would set 'start' to:
nsds5beginreplicarefresh;left or nsds5beginreplicarefresh;right
This would start the initialization process of the chosen node.
3. Create: ipa topologysegment-stop-init SEGMENT 'left'|'right'
It would set 'stop' to:
Re: [Freeipa-devel] [PATCH] Password vault
Please take a look at the attached new patch which includes some of your
changes you proposed.
On 5/14/2015 7:17 PM, Endi Sukma Dewata wrote:
On 5/14/2015 1:42 PM, Jan Cholasta wrote:
Question: Services in IPA are identified by Kerberos principal. Why are
service vaults identified by hostname alone?
The service vaults are actually identified by the hostname and service
name assuming the principal is in this format: name/host@realm.
The vault is stored in cn=name, cn=host, cn=services, cn=vaults,
suffix. When accessing a vault service you are supposed to specify the
name and the host (except for vault-find which will return all services
in the same host):
$ ipa vault-find --host host
$ ipa vault-add name --host host
Are there other service principal formats that we need to support? Do we
need to support services of different realms?
Well, users are identified by username (uid attribute), hosts by
hostname (fqdn attribute) and services by principal name
(krbprincipalname attribute). Each of them has separate container and is
also uniquely identified by principal name. I guess it would make sense
to follow that for vaults as well, in which case service vaults should
be called host vaults (because they are created in a host-specific
container, not a service-specific one) and maybe real service vaults
should be added.
There's no plan for host vaults in the design doc, but it's not
impossible to add it in the future. What is the use case?
I suppose we can change the service vault into a container, and possibly
add generic user vaults too (in addition to private user vaults), the
interface will look like this:
$ ipa vault-add PrivateVault
$ ipa vault-add ServiceVault --service name/hostname
$ ipa vault-add SharedVault --shared
$ ipa vault-add UsersVault --user username
$ ipa vault-add HostVault --host hostname
Basically we'll need a new parameter for each new container. For the
initial implementation we only need the first 2 or 3.
I changed the 'host vaults' to become 'service vaults'. The interface
will look like this:
$ ipa vault-find --service HTTP/server.example.com
$ ipa vault-add test --service HTTP/server.example.com
I also added user vaults:
$ ipa vault-find --user testuser
$ ipa vault-add test --user testuser
Private vaults is a special case of user vaults where username=you.
Host vaults can be added later once we define the use case.
1. The following code in get_dn() is causing problems for vault-find.
dn = super(vault, self).get_dn(*keys, **options)
rdn = dn[0]
container_dn = DN(*dn[1:])
The super.get_dn() will return cn=vaults, suffix, so the rdn will
become cn=vaults and container_dn will become suffix. When combined
with the subcontainer (private/shared/service) it will produce an
invalid DN.
Right, fixed.
I should have tested the patch before posting it, my bad, sorry.
OK.
This change has been included in this patch.
2. Not sure if it'related to #1, the vault-find is failing.
$ ipa vault-find
ipa: ERROR: an internal error has occurred
The error_log shows TypeError: 'NoneType' object is not iterable
Fixed. It was caused by missing return value in vault_find.exc_callback.
We can actually ignore all NotFound errors since now all containers are
either created automatically or already created by default.
if call_func.__name__ == 'find_entries':
if isinstance(exc, errors.NotFound):
shared = options.get('shared')
# if private or service container has not been created, ignore
if not shared:
raise errors.EmptyResult(reason=str(exc))
The original code was only ignoring NotFound errors on user vaults
because previously only the user containers was supposed to be created
automatically, and there wasn't a plan to provide service container.
This change has been included and it will ignore all NotFound errors.
3. The --shared option in vault-find is now requiring an argument even
though it's a Flag.
$ ipa vault-find --shared
Usage: ipa [global-options] vault-find [CRITERIA] [options]
ipa: error: --shared option requires an argument
Fixed.
OK.
Not sure which code you changed, but the new patch doesn't exhibit this
problem.
4. The following code in get_dn() is incorrect:
principal = getattr(context, 'principal')
(name, realm) = split_principal(principal)
name = name.split('/')
if len(name) == 1:
container_dn = DN(('cn', 'users'), container_dn)
else:
container_dn = DN(('cn', 'services'), container_dn)
container_dn = DN(('cn', name[-1]), container_dn)
A service does not have a private container like users (cn=username,
cn=users, cn=vaults). The entry cn=name, cn=host, cn=services,
cn=vaults is a service vault, not a container. The service vault is used
by the admin to provide a secret for a service.
I'm not sure what the behavior should be if a service is executing a
vault command that uses a private container such as:
$ ipa vault-add test
Maybe it
[Freeipa-devel] Revoking user/service/host certificates
Hi Fraser (and list), Recently, we have proposed 2 new policies for treating user/host/service certificates based on the per-profile policy: a) If certificate is stored in userCertificate attribute b) If the certificate is stored and object deleted/disabled, if the certificate should be also revoked Details in: http://www.freeipa.org/page/V4/User_Certificates#Configuration a) is straightforward. However, I was not thinking more about case b). When object is deleted/disabled, how will framework tell what is the profile to check the policy? Will it ask Dogtag via some API call? Or will the profile me stored in the certificate itself, just like MS CA does for some certificates? Thanks. -- Martin Kosek mko...@redhat.com Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCHES 0233-0234] DNSSEC: forwarders validation
On 15/05/15 18:11, Petr Spacek wrote: On 7.5.2015 18:12, Martin Basti wrote: On 07/05/15 12:19, Petr Spacek wrote: On 7.5.2015 08:59, David Kupka wrote: On 05/06/2015 03:20 PM, Martin Basti wrote: On 05/05/15 15:00, Martin Basti wrote: On 30/04/15 15:37, David Kupka wrote: On 04/24/2015 02:56 PM, Martin Basti wrote: Patches attached. Hi, thanks for patches. 1. You changed message in DNSServerNotRespondingWarning class but not the test in ipatest/test_xmlrpc/test_dns_plugin.py nitpick. Please spell 'edns' correctly. I've seen several instances of 'ends'. Thank you, updated patches attached: * new error messages * logging to debug log server output if exception was raised * fixed test * fixed spelling Fixed tests (again) Updated patches attached The code looks good to me and tests are no longer broken. (I would prefer better fix of the tests but given that the priorities are different now it can wait.) Petr, can you please confirm that the patch set works for you? Sorry, NACK: $ ipa dnsforwardzone-add ptr.test. --forwarder=10.34.47.236 Server will check DNS forwarder(s). This may take some time, please wait ... ipa: ERROR: an internal error has occurred # /var/log/httpd/error_log ipa: ERROR: non-public: AssertionError: Traceback (most recent call last): File /usr/lib/python2.7/site-packages/ipaserver/rpcserver.py, line 350, in wsgi_execute result = self.Command[name](*args, **options) File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 443, in __call__ ret = self.run(*args, **options) File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 760, in run return self.execute(*args, **options) File /usr/lib/python2.7/site-packages/ipalib/plugins/dns.py, line , in execute **options) File /usr/lib/python2.7/site-packages/ipalib/plugins/dns.py, line 4405, in _warning_if_forwarders_do_not_work log=self.log) File /usr/lib/python2.7/site-packages/ipalib/util.py, line 715, in validate_dnssec_zone_forwarder_step2 timeout=timeout) File /usr/lib/python2.7/site-packages/ipalib/util.py, line 610, in _resolve_record assert isinstance(nameserver_ip, basestring) AssertionError ipa: INFO: [jsonserver_session] admin@IPA.EXAMPLE: dnsforwardzone_add(DNS name ptr.test., idnsforwarders=(u'10.34.47.236',), all=False, raw=False, version=u'2.116'): AssertionError This is constantly reproducible in my vm-090.abc. Let me know if you want to take a look. I'm attaching little response.patch which improves compatibility with older python-dns packages. This patch allows IPA to work while error messages are simply not as nice as they could be with latest python-dns :-) check_fwd_msg.patch is a little nitpick, just to make sure everyone understands the message. BTW why some messages in check_forwarders() are printed using 'print' and others using logger? I would prefer to use logger for everything to make sure that logs contain all the information, including warnings. Thank you for your time! Thank you, fixed. I added missing except block after forwarders validation step2. I confirm that this works but I just discovered another deficiency. Setup: - DNSSEC validation is enabled on IPA server - forwarders uses fake TLD, e.g. 'test.' - remote DNS server is responding, supports EDNS0 and so on $ ipa dnsforwardzone-add ptr.test. --forwarder=10.34.47.236 Server will check DNS forwarder(s). This may take some time, please wait ... ipa: WARNING: DNS server 10.34.78.90: query 'ptr.test. SOA': The DNS query name does not exist: ptr.test.. Huh? Let's check named log: forward zone 'ptr.test': loaded validating ./SOA: got insecure response; parent indicates it should be secure Sometimes I get SERVFAIL from IPA server, too. Unfortunately this check was the main reason for writing this patchset so we need to improve it. Maybe validate_dnssec_zone_forwarder_step2() could special-case NXDOMAIN and print the DNSSEC-validation-failed error, too? The problem is that it could trigger some false positives because NXDOMAIN may simply be caused by a delay somewhere. Any ideas? I add catch block for NXDOMAIN By the way, this is also weird: $ ipa dnsforwardzone-add ptr.test. --forwarder=10.34.47.236 Server will check DNS forwarder(s). This may take some time, please wait ... ipa: ERROR: DNS forward zone with name ptr.test. already exists Is it actually doing the check even if the forward zone exists already? (This is just nitpick, not a blocker!) The first part is written by IPA client, it is not response from server. It is just written when user use --forwarder option. Updated patch attached. -- Martin Basti From 8b14534382cdb95782483c669e6c6cc4057636d8 Mon Sep 17 00:00:00 2001 From: Martin Basti mba...@redhat.com Date: Wed, 22 Apr 2015 15:29:21 +0200 Subject: [PATCH 1/2] DNSSEC: Improve global forwarders validation Validation now provides more detailed information and less false positives failures.
