Re: [Freeipa-devel] minimum python version
On Tue, 06 May 2014, Fraser Tweedale wrote: Hi all, What's are the versions of Python that must be supported in the freeipa codebase? And do older branches have to support earlier versions? Any Python language features that should be avoided, by policy? Forward-portability considerations? We attempt to not overcomplicate backport efforts for stable branches. This means we "stuck" mostly with features provided by the Python 2.6 (2.6.6 in RHEL 6, for example). -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0044] Periodically refresh global ipa-kdb configuration
On Mon, 2014-05-05 at 20:08 -0400, Dmitri Pal wrote: > On 05/02/2014 02:52 PM, Simo Sorce wrote: > > On Thu, 2014-05-01 at 16:22 -0400, Nathaniel McCallum wrote: > >> On Tue, 2014-03-11 at 11:09 -0400, Simo Sorce wrote: > >>> On Tue, 2014-03-11 at 16:05 +0200, Alexander Bokovoy wrote: > On Tue, 11 Mar 2014, Jan Pazdziora wrote: > > On Mon, Feb 24, 2014 at 02:26:27PM -0500, Nathaniel McCallum wrote: > >> Before this patch, ipa-kdb would load global configuration on startup > >> and never update it. This means that if global configuration is > >> changed, > >> the KDC never receives the new configuration until it is restarted. > >> > >> This patch enables caching of the global configuration with a timeout > >> of > >> 60 seconds. > >> > >> https://fedorahosted.org/freeipa/ticket/4153 > >> >From 7daeae56671d7b3049b0341aad66c96877431bbe Mon Sep 17 00:00:00 2001 > >> From: Nathaniel McCallum > >> Date: Mon, 24 Feb 2014 14:19:13 -0500 > >> Subject: [PATCH] Periodically refresh global ipa-kdb configuration > >> > >> Before this patch, ipa-kdb would load global configuration on startup > >> and > >> never update it. This means that if global configuration is changed, > >> the > >> KDC never receives the new configuration until it is restarted. > >> > >> This patch enables caching of the global configuration with a timeout > >> of > >> 60 seconds. > >> > >> https://fedorahosted.org/freeipa/ticket/4153 > > I have only read the code and it looks sane, so depending on how much > > you consider my word about code-reading worth, ack. > > > > However, my gut feeling is that my preferred way of handling the issue > > (without knowing much about the background of the ticket) would > > probably be a HUP signal handler or something similar, rather than > > polling for current values with the value timeout. This patch > > introduces small nondeterminism to the behaviour when the usage of the > > new values cannot really be enfoced by the admin (without the daemon > > restart). > Thing is, we need the update to happen when other, non-root process > makes the changes -- in our case when IPA server running under httpd > privileges performs series of MS-RPC calls towards smbd which lead to > creating certain LDAP objects. httpd couldn't send SIGHUP to a process > not owned by httpd's effective user (non-root). > >>> Yes but this is not really the way to go. > >>> > >>> The proper fix is to use syncrepl/persistent search to get a > >>> notification of when we need to reload the configuration. > >>> > >>> On the patch itself I have a NACK due to this syntax used in various > >>> places: function()->attribute > >>> > >>> don't. do. that. ever. > >>> > >>> assign whatever come from the function to a local variable and *check* > >>> it is not null, *then* use it. > >> Attached patch fixes the NACK issue, but does not address the question > >> of the larger approach. Do we need to take a different approach? If so, > >> what is it? > > LGTM > > I might prefer slightly more explicit names for those temp vars, but > > that's not a big deal. > > > > As for the approach, moving to something like syncrepl would be a good > > idea. As it would allow us to avoid useless polling and changes would be > > applaied as soon as they become available as the syncrepl agreement > > would push them to our client. It does mean we need a way to check that > > there aren't pending changes coming down the syncrepl pipe, but we can > > do that synchronously at every entry point in the KDB. After all we do > > not need to care about a change until the KDC needs something from the > > KDB. > > > > Simo. > > > Do we need a ticket for that then? Turns out we already have one: https://fedorahosted.org/freeipa/ticket/1302 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] minimum python version
Hi all, What's are the versions of Python that must be supported in the freeipa codebase? And do older branches have to support earlier versions? Any Python language features that should be avoided, by policy? Forward-portability considerations? I look forward to your responses and will write it up in the IPA new hire guide! Cheers, Fraser ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0044] Periodically refresh global ipa-kdb configuration
On 05/02/2014 02:52 PM, Simo Sorce wrote: On Thu, 2014-05-01 at 16:22 -0400, Nathaniel McCallum wrote: On Tue, 2014-03-11 at 11:09 -0400, Simo Sorce wrote: On Tue, 2014-03-11 at 16:05 +0200, Alexander Bokovoy wrote: On Tue, 11 Mar 2014, Jan Pazdziora wrote: On Mon, Feb 24, 2014 at 02:26:27PM -0500, Nathaniel McCallum wrote: Before this patch, ipa-kdb would load global configuration on startup and never update it. This means that if global configuration is changed, the KDC never receives the new configuration until it is restarted. This patch enables caching of the global configuration with a timeout of 60 seconds. https://fedorahosted.org/freeipa/ticket/4153 >From 7daeae56671d7b3049b0341aad66c96877431bbe Mon Sep 17 00:00:00 2001 From: Nathaniel McCallum Date: Mon, 24 Feb 2014 14:19:13 -0500 Subject: [PATCH] Periodically refresh global ipa-kdb configuration Before this patch, ipa-kdb would load global configuration on startup and never update it. This means that if global configuration is changed, the KDC never receives the new configuration until it is restarted. This patch enables caching of the global configuration with a timeout of 60 seconds. https://fedorahosted.org/freeipa/ticket/4153 I have only read the code and it looks sane, so depending on how much you consider my word about code-reading worth, ack. However, my gut feeling is that my preferred way of handling the issue (without knowing much about the background of the ticket) would probably be a HUP signal handler or something similar, rather than polling for current values with the value timeout. This patch introduces small nondeterminism to the behaviour when the usage of the new values cannot really be enfoced by the admin (without the daemon restart). Thing is, we need the update to happen when other, non-root process makes the changes -- in our case when IPA server running under httpd privileges performs series of MS-RPC calls towards smbd which lead to creating certain LDAP objects. httpd couldn't send SIGHUP to a process not owned by httpd's effective user (non-root). Yes but this is not really the way to go. The proper fix is to use syncrepl/persistent search to get a notification of when we need to reload the configuration. On the patch itself I have a NACK due to this syntax used in various places: function()->attribute don't. do. that. ever. assign whatever come from the function to a local variable and *check* it is not null, *then* use it. Attached patch fixes the NACK issue, but does not address the question of the larger approach. Do we need to take a different approach? If so, what is it? LGTM I might prefer slightly more explicit names for those temp vars, but that's not a big deal. As for the approach, moving to something like syncrepl would be a good idea. As it would allow us to avoid useless polling and changes would be applaied as soon as they become available as the syncrepl agreement would push them to our client. It does mean we need a way to check that there aren't pending changes coming down the syncrepl pipe, but we can do that synchronously at every entry point in the KDB. After all we do not need to care about a change until the KDC needs something from the KDB. Simo. Do we need a ticket for that then? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0050] Fix typo in token UI javascript comment
On 5.5.2014 19:10, Nathaniel McCallum wrote: Attached. ACK. -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0046] Fix a typo in the otptoken doc string
On Mon, 2014-05-05 at 14:03 +0200, Jan Cholasta wrote: > Hi, > > On 2.5.2014 23:45, Nathaniel McCallum wrote: > > Patch attached > > ACK, but there is one additional occurence of "otp-add" in a comment in > install/ui/src/freeipa/otptoken.js. https://www.redhat.com/archives/freeipa-devel/2014-May/msg00039.html Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0050] Fix typo in token UI javascript comment
Attached.
>From de4185294e389679caac12996016f81fdb84c0f1 Mon Sep 17 00:00:00 2001
From: Nathaniel McCallum
Date: Mon, 5 May 2014 13:08:35 -0400
Subject: [PATCH] Fix typo in token UI javascript comment
---
install/ui/src/freeipa/otptoken.js | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/install/ui/src/freeipa/otptoken.js b/install/ui/src/freeipa/otptoken.js
index cf14869ce431d1a89e84687d1c88ffb500ddaf97..5040f3694976b1b13d865a9310640082b6fbeae0 100644
--- a/install/ui/src/freeipa/otptoken.js
+++ b/install/ui/src/freeipa/otptoken.js
@@ -284,7 +284,7 @@ otptoken.adder_dialog_preop = function(spec) {
/**
* OTP adder dialog
*
- * - otp-add requires 'type' to be set. At the moment IPA supports only 'totp'
+ * - otptoken-add requires 'type' to be set. At the moment IPA supports only 'totp'
* @class
* @extends IPA.entity_adder_dialog
*/
--
1.9.0
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0049] Add support for protected tokens
This also constitutes a rethinking of the token ACIs after the introduction of SELFDN support. Admins, as before, have full access to all token permissions. Normal users have read/search/compare access to all of the non-secret data for tokens assigned to them, whether protected or non-protected. Users can add or delete non-protected tokens and modify most of their metadata. However they cannot create, delete or modify protected tokens. Regardless of whether the token is protected or not, users cannot change a token's ownership or unique identity. In contrast, admins can create protected tokens. This protects the token from deletion or modification when assigned to users. Additionally, when a user account is deleted, the assigned non-protected tokens are deleted but the protected tokens are merely orphaned. This permits the token to be reassigned without having to recreate it. This last point is particularly useful in the case of hardware tokens. https://fedorahosted.org/freeipa/ticket/4228 NOTE: This patch depends on my patch 0048. >From a95e3cee5fdd7b98635d984977cbb71ad5c7aa02 Mon Sep 17 00:00:00 2001 From: Nathaniel McCallum Date: Fri, 2 May 2014 16:44:30 -0400 Subject: [PATCH] Add support for protected tokens This also constitutes a rethinking of the token ACIs after the introduction of SELFDN support. Admins, as before, have full access to all token permissions. Normal users have read/search/compare access to all of the non-secret data for tokens assigned to them, whether protected or non-protected. Users can add or delete non-protected tokens and modify most of their metadata. However they cannot create, delete or modify protected tokens. Regardless of whether the token is protected or not, users cannot change a token's ownership or unique identity. In contrast, admins can create protected tokens. This protects the token from deletion or modification when assigned to users. Additionally, when a user account is deleted, the assigned non-protected tokens are deleted but the protected tokens are merely orphaned. This permits the token to be reassigned without having to recreate it. This last point is particularly useful in the case of hardware tokens. https://fedorahosted.org/freeipa/ticket/4228 --- install/share/70ipaotp.ldif| 3 ++- install/share/default-aci.ldif | 10 +- install/updates/40-otp.update | 16 +++- ipalib/plugins/otptoken.py | 9 + ipalib/plugins/user.py | 9 - 5 files changed, 35 insertions(+), 12 deletions(-) diff --git a/install/share/70ipaotp.ldif b/install/share/70ipaotp.ldif index a40ad9ee0cfcf72ed6b79306396a29683f9e1a9d..08f639b6cd14b6dd1270a604fdd061cecb4a6482 100644 --- a/install/share/70ipaotp.ldif +++ b/install/share/70ipaotp.ldif @@ -23,7 +23,8 @@ attributeTypes: (2.16.840.1.113730.3.8.16.1.18 NAME 'ipatokenRadiusTimeout' DESC attributeTypes: (2.16.840.1.113730.3.8.16.1.19 NAME 'ipatokenRadiusRetries' DESC 'Number of allowed Retries' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'IPA OTP') attributeTypes: (2.16.840.1.113730.3.8.16.1.20 NAME 'ipatokenUserMapAttribute' DESC 'Attribute to map from the user entry for RADIUS server authentication' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'IPA OTP') attributeTypes: (2.16.840.1.113730.3.8.16.1.21 NAME 'ipatokenHOTPcounter' DESC 'HOTP counter' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'IPA OTP') -objectClasses: (2.16.840.1.113730.3.8.16.2.1 NAME 'ipaToken' SUP top ABSTRACT DESC 'Abstract token class for tokens' MUST (ipatokenUniqueID) MAY (description $ ipatokenOwner $ ipatokenDisabled $ ipatokenNotBefore $ ipatokenNotAfter $ ipatokenVendor $ ipatokenModel $ ipatokenSerial) X-ORIGIN 'IPA OTP') +attributeTypes: (2.16.840.1.113730.3.8.16.1.22 NAME 'ipatokenProtected' DESC 'Optionally marks token as Protected' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA OTP') +objectClasses: (2.16.840.1.113730.3.8.16.2.1 NAME 'ipaToken' SUP top ABSTRACT DESC 'Abstract token class for tokens' MUST (ipatokenUniqueID) MAY (description $ ipatokenOwner $ ipatokenDisabled $ ipatokenNotBefore $ ipatokenNotAfter $ ipatokenVendor $ ipatokenModel $ ipatokenSerial $ ipatokenProtected) X-ORIGIN 'IPA OTP') objectClasses: (2.16.840.1.113730.3.8.16.2.2 NAME 'ipatokenTOTP' SUP ipaToken STRUCTURAL DESC 'TOTP Token Type' MUST (ipatokenOTPkey $ ipatokenOTPalgorithm $ ipatokenOTPdigits $ ipatokenTOTPclockOffset $ ipatokenTOTPtimeStep) X-ORIGIN 'IPA OTP') objectClasses: (2.16.840.1.113730.3.8.16.2.3 NAME 'ipatokenRadiusProxyUser' SUP top AUXILIARY DESC 'Radius Proxy User' MAY (ipatokenRadiusConfigLink $ ipatokenRadiusUserName) X-ORIGIN 'IPA OTP') objectClasses: (2.16.840.1.113730.3.8.16.2.4 NAME 'ipatokenRadiusConfiguration' SUP top STRUCTURAL DESC 'Proxy Radius Configuration' MUST (cn $ ipatokenRadiusServer $ ipatokenRadiusSecret) MAY
[Freeipa-devel] [PATCH 0048] Default the token owner to the person adding the token
Creating tokens for yourself is the most common operation. Making this the default optimizes for the common case. >From a35485a2ffe4f47792203ebc5a6ef4b955bf Mon Sep 17 00:00:00 2001 From: Nathaniel McCallum Date: Mon, 5 May 2014 10:41:20 -0400 Subject: [PATCH] Default the token owner to the person adding the token Creating tokens for yourself is the most common operation. Making this the default optimizes for the common case. --- ipalib/plugins/otptoken.py | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/ipalib/plugins/otptoken.py b/ipalib/plugins/otptoken.py index 91525398d6b7fd1fc355a7a018a6f96bef109979..26a2275587f3a7ef97c65e8cea6b431c05c00157 100644 --- a/ipalib/plugins/otptoken.py +++ b/ipalib/plugins/otptoken.py @@ -241,7 +241,14 @@ class otptoken_add(LDAPCreate): if tattr in entry_attrs: del entry_attrs[tattr] -# Resolve the user's dn +# Get the UID of the person adding this token. +cur_uid = self.api.Command.user_find(whoami=True)['result'][0]['uid'][0] + +# If no owner was specified, default to the person adding this token. +if "ipatokenowner" not in entry_attrs: +entry_attrs["ipatokenowner"] = cur_uid + +# Resolve the owner's dn _normalize_owner(self.api.Object.user, entry_attrs) # Get the issuer for the URI -- 1.9.0 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES 180-182] ipatests: Improvements!
On Fri, 02 May 2014, Jakub Hrozek wrote: On Wed, Apr 30, 2014 at 03:59:01PM +0200, Tomas Babej wrote: Hi, * patch 180 fixes incorrect hostname usage when connecting to legacy clients * patch 181 sets up SSSD in debug_level 7 by default * patch 182 does the same, but on the legacy clients -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org ACK to the general intent of debug_level by default. Have you considered using the python ConfigAPI sssd has to change the sections rather than running a sed script? I agree. The patchset in current form does work fine for me in the tests. However, I'd rather wait for a new revision which incorporates changes requested by the Jakub. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0034] Deny LDAP binds for user accounts with expired principal
On Mon, 05 May 2014, Alexander Bokovoy wrote:
On Wed, 30 Apr 2014, Tomas Babej wrote:
+if (current_time > expire_time && expire_time > 0) {
+LOG_FATAL("kerberos principal in %s is
expired\n", dn);
+errMesg = "Kerberos principal is expired.";
+auth_failed = true;
+goto done;
+}
+}
I think indenting is broken for these two brackets.
Thanks Alexander, fixed.
Updated version attached.
Tomas
This version is rebased on top of OTP patches, addresses Simo's comments
and brings unit tests to cover the functionality (however, they need to
be applied on top of my patches 183-185).
Tested, works fine.
I've pushed the main patch to master. The tests will be pushed after the
dependency patches will be pushed.
Pushed patch 186 to master
* 004071a24626195994265b1bcc3ac616bb09d795 ipatests: Add test for denying
expired principals
--
/ Alexander Bokovoy
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0138] ipalib: Expose krbPrincipalExpiration in CLI
On Wed, 30 Apr 2014, Tomas Babej wrote: On 04/25/2014 11:10 AM, Jan Cholasta wrote: On 22.4.2014 13:34, Tomas Babej wrote: Updated, rebased patch attached. This API.txt change belongs in the previous patch: +capability: datetime_values 2.84 Fixed, updated patch attached. I also added several tests for the user plugin that cover the feature (and related refactoring). Thanks. Tested and they work fine. Pushed three patches to master * edb5a0c5344de88cc41f6f73098da88d754cf076 ipalib: Expose krbPrincipalExpiration in CLI * 4568a52953bc8e0193d586ebc3d8bdbd3e3e0fa0 ipatests: Fix formatting errors in test_user_plugin.py * 473a9fd23800b46b4608465ae47da523e8a2861f ipatests: Add coverage for setting krbPrincipalExpiration -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0137] ipalib: Add DateTime parameter
On Wed, 30 Apr 2014, Tomas Babej wrote:
On 04/25/2014 11:08 AM, Jan Cholasta wrote:
On 22.4.2014 13:32, Tomas Babej wrote:
Thank you for the suggestions. Updated, rebased patch is attached.
This API.txt change from the next patch belongs in this patch:
+capability: datetime_values 2.84
I think you should use the LDAP_GENERALIZED_TIME_FORMAT constant here:
+accepted_formats = ['%Y%m%d%H%M%SZ', # generalized time
This is not right:
+elif isinstance(val, datetime.datetime):
+return val
To actually decode LDAP generalized time attributes to datetime, you
need to do this:
'2.16.840.1.113719.1.301.4.41.1' : DN, # krbSubTrees
'2.16.840.1.113719.1.301.4.52.1' : DN, # krbObjectReferences
'2.16.840.1.113719.1.301.4.53.1' : DN, # krbPrincContainerRef
+
+'1.3.6.1.4.1.1466.115.121.1.24' : datetime.datetime,
}
# In most cases we lookup the syntax from the schema returned by
and this:
return val
elif target_type is unicode:
return val.decode('utf-8')
+elif target_type is datetime.datetime:
+return datetime.datetime.strptime(val,
LDAP_GENERALIZED_TIME_FORMAT)
else:
return target_type(val)
except Exception, e:
and add code for formatting datetime values to the textui backend.
Thanks for the review. I fixed all the issues, updated patch is attached.
I also added unit tests for the new DateTime parameter.
Thanks, tested them as part of kerberos principal expiration time
patches.
Pushed two patches to git master.
--
/ Alexander Bokovoy
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 588 webui: fix switching between multiple_choice_section choices
On 5.5.2014 14:40, Misnyovszki Adam wrote: On Fri, 25 Apr 2014 19:24:35 +0200 Petr Vobornik wrote: - required indicators are not present for all sections except the last - validation has wrong color for the same sections There was only one layout for all choices. Layout should not be reused because `create` method will reset layout's rows therefore it worked properly only for the last choice. https://fedorahosted.org/freeipa/ticket/4327 Works as expected, integration and manual tests ran. ACK Thanks Adam Pushed to master: 093c72d60e94d9545e38f2ad90cb24e6f44cbd62 -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 587 webui-ci: adjust id range tests to new validator
On 5.5.2014 14:05, Misnyovszki Adam wrote: On Fri, 25 Apr 2014 15:02:27 +0200 Petr Vobornik wrote: SSIA LGFM, integration tests for range now runs smoothly. ACK Thanks Adam Pushed to master: 7eff8ad7dc385070b600ddb2b2ba1f39835718b6 -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0034] Deny LDAP binds for user accounts with expired principal
On Wed, 30 Apr 2014, Tomas Babej wrote:
+if (current_time > expire_time && expire_time > 0) {
+LOG_FATAL("kerberos principal in %s is
expired\n", dn);
+errMesg = "Kerberos principal is expired.";
+auth_failed = true;
+goto done;
+}
+}
I think indenting is broken for these two brackets.
Thanks Alexander, fixed.
Updated version attached.
Tomas
This version is rebased on top of OTP patches, addresses Simo's comments
and brings unit tests to cover the functionality (however, they need to
be applied on top of my patches 183-185).
Tested, works fine.
I've pushed the main patch to master. The tests will be pushed after the
dependency patches will be pushed.
--
/ Alexander Bokovoy
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0238] Update .gitignore to skip Eclipse and Autotools file
On 5.5.2014 16:56, Tomas Hozza wrote: Hello, > >Update .gitignore to skip Eclipse and Autotools files. > >-- >Petr^2 Spacek > ACK Pushed to master: 5dbb7fa8426cd5512cd7ce99dc6546b7928cfbfb -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0237] Handle paths without trailing / in fs_dirs_create()
On 5.5.2014 16:56, Tomas Hozza wrote: Hello, > >Handle paths without trailing / in fs_dirs_create(). > >This patch should go to all branches with fs_dirs_create() function. > >-- >Petr^2 Spacek > Looks good. ACK Pushed to master: 21136d9b6933a733586fba3a83e9b2be050a948d -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0236] Fix crash in create_zone()
On 5.5.2014 16:46, Tomas Hozza wrote: Fix crash in create_zone(). dns_zone_getmgr(zone) call in cleanup section was called even if zone was NULL. This patch should go to master, v4 and v3 branches where applicable. You probably need to use debugger to reproduce this crash. I have encountered it during work on new DNSSEC code ... -- Petr^2 Spacek Looks good. ACK. Pushed to master: 7444db8200a38710f69db9d4d9c350615748ba24 -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0238] Update .gitignore to skip Eclipse and Autotools file
- Original Message - > Hello, > > Update .gitignore to skip Eclipse and Autotools files. > > -- > Petr^2 Spacek > ACK -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0237] Handle paths without trailing / in fs_dirs_create()
- Original Message - > Hello, > > Handle paths without trailing / in fs_dirs_create(). > > This patch should go to all branches with fs_dirs_create() function. > > -- > Petr^2 Spacek > Looks good. ACK Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0236] Fix crash in create_zone()
- Original Message - > Hello, > > Fix crash in create_zone(). > > dns_zone_getmgr(zone) call in cleanup section was called even if zone > was NULL. > > This patch should go to master, v4 and v3 branches where applicable. > > You probably need to use debugger to reproduce this crash. I have encountered > it during work on new DNSSEC code ... > > -- > Petr^2 Spacek > Looks good. ACK. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 18 webui otptoken test data added
On Wed, 30 Apr 2014 13:37:10 +0200
Petr Vobornik wrote:
> On 29.4.2014 16:30, Misnyovszki Adam wrote:
> > On Fri, 25 Apr 2014 17:16:48 +0200
> > Misnyovszki Adam wrote:
> >
> >> Hi,
> >> this patch adds some static test data for the webui otptoken part.
> >> Adam
> >
> > Attached corrected DN's.
> > Thanks
> > Adam
> >
>
> 1) Why otptoken_batch_del.json ends with error? Also there might be
> a defect in UI that for batch delete operation it asks for batch.json
> and not $ENTITY_batch_del.json making otptoken_batch_del.json unused
> - out of scope of this patch.
>
> 2) Why otptoken_mod.json ends with error?
>
> 3) otptoken_find.json is not needed since the search facet uses
> paging (combination of otptoken_get_records.json and
> otptoken_find_pkeys.json is enough).
>
> In general, it's OK to fake the data if there is some bug which
> causes errors and we know that it will be fixed.
Hi,
see the attached, and corrected 18 patch for otptoken static test data.
Also, I've added patch 20, for fixing the batch_del command in static
webui tests.
Thanks
Adam>From 22577cf672128231cb4b2ced7e7ee1c12da664c7 Mon Sep 17 00:00:00 2001
From: Adam Misnyovszki
Date: Wed, 30 Apr 2014 17:53:52 +0200
Subject: [PATCH 1/2] webui OTP token test data added
---
install/ui/test/data/otptoken_add.json | 43 +++
install/ui/test/data/otptoken_batch.json | 27 ++
install/ui/test/data/otptoken_batch_del.json | 27 ++
install/ui/test/data/otptoken_batch_mod.json | 34
install/ui/test/data/otptoken_find_pkeys.json | 17 ++
install/ui/test/data/otptoken_get_records.json | 57
install/ui/test/data/otptoken_mod.json | 72 ++
install/ui/test/data/otptoken_show.json| 51 ++
8 files changed, 328 insertions(+)
create mode 100644 install/ui/test/data/otptoken_add.json
create mode 100644 install/ui/test/data/otptoken_batch.json
create mode 100644 install/ui/test/data/otptoken_batch_del.json
create mode 100644 install/ui/test/data/otptoken_batch_mod.json
create mode 100644 install/ui/test/data/otptoken_find_pkeys.json
create mode 100644 install/ui/test/data/otptoken_get_records.json
create mode 100644 install/ui/test/data/otptoken_mod.json
create mode 100644 install/ui/test/data/otptoken_show.json
diff --git a/install/ui/test/data/otptoken_add.json b/install/ui/test/data/otptoken_add.json
new file mode 100644
index ..c52fc15035e0aad025294a8da1f938ee53c8e5a9
--- /dev/null
+++ b/install/ui/test/data/otptoken_add.json
@@ -0,0 +1,43 @@
+{
+"error": null,
+"id": null,
+"result": {
+"result": {
+"dn": "ipatokenuniqueid=10bd43b5-3204-4695-9225-91064f6c77b3,cn=otp,dc=example,dc=com",
+"ipatokenmodel": [
+"totp"
+],
+"ipatokenotpalgorithm": [
+"sha1"
+],
+"ipatokenotpdigits": [
+"6"
+],
+"ipatokenotpkey": [
+{
+"__base64__": "2TUYXOVTaZf/Og=="
+}
+],
+"ipatokentotpclockoffset": [
+"0"
+],
+"ipatokentotptimestep": [
+"30"
+],
+"ipatokenuniqueid": [
+"footoken"
+],
+"ipatokenvendor": [
+"FreeIPA"
+],
+"objectclass": [
+"top",
+"ipatokentotp",
+"ipatoken"
+],
+"uri": "otpauth://totp/EXAMPLE.COM:10bd43b5-3204-4695-9225-91064f6c77b3?digits=6&secret=3E2RQXHFKNUZP7Z2&period=30&algorithm=sha1&issuer=EXAMPLE.COM"
+},
+"summary": "Added OTP token \"10bd43b5-3204-4695-9225-91064f6c77b3\"",
+"value": "10bd43b5-3204-4695-9225-91064f6c77b3"
+}
+}
diff --git a/install/ui/test/data/otptoken_batch.json b/install/ui/test/data/otptoken_batch.json
new file mode 100644
index ..059b53f96ebe34036394b969f12903e8b52d69fa
--- /dev/null
+++ b/install/ui/test/data/otptoken_batch.json
@@ -0,0 +1,27 @@
+{
+"error": null,
+"id": null,
+"result": {
+"count": 1,
+"messages": [
+{
+"code": 13001,
+"message": "API Version number was not sent, forward compatibility not guaranteed. Assuming server's API version, 2.83",
+"name": "VersionMissing",
+"type": "warning"
+}
+],
+"results": [
+{
+"error": null,
+"result": {
+"failed": []
+},
+"summary": "Deleted OTP token \"10bd43b5-3204-4695-9225-91064f6c77b3\"",
+"value": [
+"10bd43b5-3204-4695-9225-91064f6c77b3"
+]
+}
+
Re: [Freeipa-devel] bind DN of executing command
Sumit Bose wrote: On Fri, May 02, 2014 at 05:06:06PM -0400, Nathaniel McCallum wrote: I need the DN of the user who is running the current command. This may be defined as the user who is bound or will bind to execute the LDAP commands I have prepared. Does anyone know how to do this in the FreeIPA api? I guess you are looking for ipa user-find --whoami If you're doing this in your own plugin, you get the current principal with: getattr(context, 'principal') Using that you can get the DN of that user with a search like this: "(&(objectclass=posixaccount)(krbprincipalname=%s))" % getattr(context, 'principal') We don't currently have a helper for this. This is rather inefficient in user-find as it searches from the basedn rather than the user container for some reason. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAP schema for DNSSEC keys
On 5.5.2014 10:45, Ludwig Krispenz wrote: Hi Petr, On 05/02/2014 08:48 PM, Petr Spacek wrote: On 1.5.2014 16:10, Rich Megginson wrote: On 04/30/2014 10:19 AM, Petr Spacek wrote: - We need to decide about object naming: - One obvious option for RDN is to use uniqueID but I don't like it. It is hard to read for humans. - Other option is to use uniqueID+PKCS#11 label or other attributes to make it more readable. Can we use multi-valued RDN? If not, why? What are technical reasons behind it? I would encourage you not to use multi-valued RDNs. There aren't any technical reasons - multi-valued RDNs are part of the LDAP standards and all conforming LDAP implementations must support them. However, they are hard to deal with - you _must_ have some sort of DN class/api on the client side to handle them, and not all clients do - many clients expect to be able to just do dnstr.lower() == dnstr2.lower() or possibly do simple escaping. As far as being human readable - the whole goal is that humans _never_ have to look at a DN. If humans have to look at and understand a DN to accomplish a task, then we have failed. I agree, users should not see them. I want to make life easier for administrators and developers *debugging* it. I'm facing UUIDs-only logs and database in oVirt for more than year now and I can tell you that it is horrible, horrible, horrible. It is PITA when I have to debug something in oVirt because I have to search for UUIDs all the time. I want to scream and jump out of the window when I see single log line with 4 or more different UUIDs... :-) Has the DogTag team reviewed this proposal? Their data storage and workflows are similar. That is very good point! Nathan, could somebody from DS team (maybe somebody involved in Password Vault) review this "vault without Vault"? Thank you! It is question if we like: nsUniqID = 0b0b7e53-957d11e3-a51dc0e5-9a05ecda nsUniqID = 8ae4190d-957a11e3-a51dc0e5-9a05ecda more than: ipk11Label=meaningful_label+ipk11Private=TRUE ipk11Label=meaningful_label+ipk11Private=FALSE there are two goals for choosing the naming attribute(s): they have to be unique in a level of the DIT and they should be meaningful/readable. I agree with Rich that technically nothing excludes multi-valued rdns, but could make things complicated for clients and in my opinion it does not increase readability. In your case: - are there really two entries with the same ipk11label, on private one not ? not all info has to be in the rdn, so you could use ipk11label as naming attribute - couldn't you just use an other attribute as anming attr where you are free to put in what you want eg cn="(True)" - we did define an ipk11uniquid to be used as naming attr for storage objects, but there are no definitions on its structure, you could use it as you like as long as it is unique (could be unique and meaningful and readable) +1 on the last suggestion Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 588 webui: fix switching between multiple_choice_section choices
On Fri, 25 Apr 2014 19:24:35 +0200 Petr Vobornik wrote: > - required indicators are not present for all sections except the last > - validation has wrong color for the same sections > > There was only one layout for all choices. Layout should not be reused > because `create` method will reset layout's rows therefore it worked > properly only for the last choice. > > https://fedorahosted.org/freeipa/ticket/4327 Works as expected, integration and manual tests ran. ACK Thanks Adam ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 587 webui-ci: adjust id range tests to new validator
On Fri, 25 Apr 2014 15:02:27 +0200 Petr Vobornik wrote: > SSIA LGFM, integration tests for range now runs smoothly. ACK Thanks Adam ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0046] Fix a typo in the otptoken doc string
Hi, On 2.5.2014 23:45, Nathaniel McCallum wrote: Patch attached ACK, but there is one additional occurence of "otp-add" in a comment in install/ui/src/freeipa/otptoken.js. Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAP schema for DNSSEC keys
Hi Petr, On 05/02/2014 08:48 PM, Petr Spacek wrote: On 1.5.2014 16:10, Rich Megginson wrote: On 04/30/2014 10:19 AM, Petr Spacek wrote: Hello list, following text summarizes schema & DIT layout for DNSSEC key storage in LDAP. This is subset of full PKCS#11 schema [0]. It stores bare keys with few metadata attributes when necessary. The intention is to make transition to full PKCS#11-in-LDAP schema [0] as easy as possible. This transition should happen in next minor version of FreeIPA. In theory, the transition should be just adding few object classes to existing objects and populating few new metadata attributes. Related object classes are marked below with "(in long-term)". Please comment on it soon. We want to implement it ASAP :-) DNSSEC key == - Asymmetric - Private key is stored in LDAP as encrypted PKCS#8 blob - Public key is published in LDAP - Encrypted with symmetric "DNSSEC master key" (see below) - Private key - represented as LDAP object with object classes: ipaEPrivateKey [1] # encrypted data ipaWrappedKey [2] # pointer to master key, outside scope of pure PKCS#11 ipk11PrivateKey [3] (in long-term) # PKCS#11 metadata - Public key - represented as LDAP object with object classes: ipaPublicKey[1] # public key data ipk11PublicKey [3] (in long-term) # PKCS#11 metadata Master key == - Symmetric - Stored in LDAP as encrypted blob - Encrypted with asymmetric "replica key" (see below) - 1 replica = 1 blob, n replicas = n blobs encrypted with different keys - A replica uses it's own key for master key en/decryption - Represented as LDAP object with object classes: ipaESecretKey [1] ipk11SecretKey [3] (in long-term) Replica key === - Asymmetric - Private key is stored on replica's disk only - Public key for all replicas is stored in LDAP - Represented as LDAP object with object classes: ipaPublicKey [1] ipk11PublicKey [3] (in long-term) DIT layout == DNSSEC key material --- - Container: cn=keys, cn=sec, cn=dns, dc=example - Private and public keys are stored as separate objects to accommodate all PKCS#11 metadata. - We need to decide about object naming: - One obvious option for RDN is to use uniqueID but I don't like it. It is hard to read for humans. - Other option is to use uniqueID+PKCS#11 label or other attributes to make it more readable. Can we use multi-valued RDN? If not, why? What are technical reasons behind it? I would encourage you not to use multi-valued RDNs. There aren't any technical reasons - multi-valued RDNs are part of the LDAP standards and all conforming LDAP implementations must support them. However, they are hard to deal with - you _must_ have some sort of DN class/api on the client side to handle them, and not all clients do - many clients expect to be able to just do dnstr.lower() == dnstr2.lower() or possibly do simple escaping. As far as being human readable - the whole goal is that humans _never_ have to look at a DN. If humans have to look at and understand a DN to accomplish a task, then we have failed. I agree, users should not see them. I want to make life easier for administrators and developers *debugging* it. I'm facing UUIDs-only logs and database in oVirt for more than year now and I can tell you that it is horrible, horrible, horrible. It is PITA when I have to debug something in oVirt because I have to search for UUIDs all the time. I want to scream and jump out of the window when I see single log line with 4 or more different UUIDs... :-) Has the DogTag team reviewed this proposal? Their data storage and workflows are similar. That is very good point! Nathan, could somebody from DS team (maybe somebody involved in Password Vault) review this "vault without Vault"? Thank you! It is question if we like: nsUniqID = 0b0b7e53-957d11e3-a51dc0e5-9a05ecda nsUniqID = 8ae4190d-957a11e3-a51dc0e5-9a05ecda more than: ipk11Label=meaningful_label+ipk11Private=TRUE ipk11Label=meaningful_label+ipk11Private=FALSE there are two goals for choosing the naming attribute(s): they have to be unique in a level of the DIT and they should be meaningful/readable. I agree with Rich that technically nothing excludes multi-valued rdns, but could make things complicated for clients and in my opinion it does not increase readability. In your case: - are there really two entries with the same ipk11label, on private one not ? not all info has to be in the rdn, so you could use ipk11label as naming attribute - couldn't you just use an other attribute as anming attr where you are free to put in what you want eg cn="(True)" - we did define an ipk11uniquid to be used as naming attr for storage objects, but there are no definitions on its structure, you could use it as you like as long as it is unique (could be unique and meaningful and readable) DNSSEC key metadata --- - Container (per-zone): cn=keys, idnsname=example.net, cn=dns -
Re: [Freeipa-devel] bind DN of executing command
On Fri, May 02, 2014 at 05:06:06PM -0400, Nathaniel McCallum wrote: > I need the DN of the user who is running the current command. This may > be defined as the user who is bound or will bind to execute the LDAP > commands I have prepared. > > Does anyone know how to do this in the FreeIPA api? I guess you are looking for ipa user-find --whoami HTH bye, Sumit > > Nathaniel > > ___ > Freeipa-devel mailing list > Freeipa-devel@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
