Re: [Freeipa-devel] Web services in freeIPA
I have to install the new version, I have the 3.2 installed.
I have to integrate the web apps to my web administration site, so i can add,
remove, update and find users.
Thanks
Alexandre Santos
On 07 Feb 2014, at 15:15, Alexandre Santos asan...@uc.pt wrote:
Thanks, i´m new to this json. How can i find the methods available and there
options?
Thanks
Alexandre Santos
On 07 Feb 2014, at 09:45, Alexander Bokovoy aboko...@redhat.com wrote:
On Fri, 07 Feb 2014, Alexandre Santos wrote:
Hi Martin,
I´ve tried your example and i get this error:
curl -v \
-H Content-Type:application/json \
-H Accept:applicaton/json\
--negotiate -u : \
--delegation always \
--cacert /etc/ipa/ca.crt \
-d '{method:user_find,params:[[],{}],id:0}' \
-X POST https://ipa/ipa/json
...
User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7
NSS/3.13.6.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Host: pi
Content-Type:application/json
Accept:applicaton/json
Content-Length: 48
HTTP/1.1 200 Success
Date: Thu, 06 Feb 2014 16:42:26 GMT
Server: Apache/2.2.15 (CentOS)
Connection: close
Transfer-Encoding: chunked
Content-Type: application/json; charset=utf-8
{
error: {
code: 911,
message: Missing or invalid HTTP Referer, missing,
name: {
__base64__: UmVmZXJlckVycm9y
}
},
id: null,
principal: “admin@ipa,
result: null,
version: 3.0.0
* Closing connection #0
Any suggestion?
You need to set the referrer.
-H referer:https://ipa.mybox/ipa/ui/index.html
--
/ Alexander Bokovoy
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy
On 01/28/2014 09:35 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 01/23/2014 02:17 PM, Petr Viktorin wrote: ... The URL endpoint /ipa/rest suggests that if we implement a complete REST API for IPA it would live here. Is the API supposed to be future-compatible? (The API itself seems to be a good subset of a complete REST API, but can we easily add an frontend with authentication, i18n, etc. here later, and keep the limitations for unauthenticated access?) Perhaps /ipa/smartproxy would be a better choice? It was future-proofing. I'm fine with changing the URI, it is probably a good thing to save that name. +1 for moving to /ipa/smartproxy/rest, we will want a complete REST interface in ipa/rest/ in the future. I rather opened a ticket to track that: https://fedorahosted.org/freeipa/ticket/4168 Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Web services in freeIPA
As this is not documented, I am thinking the easiest approach will be to open
Web UI and see what JSON requests it sends to IPA for desired actions. I tested
that for example with Chrome developer tools and I could easily see that for
showing a particular user it uses following JSON:
{method:user_show,params:[[fbar],{all:true,rights:true}]}
or for user-del:
{method:user_del,params:[[fbar],{}]}
Martin
On 02/10/2014 10:13 AM, Alexandre Santos wrote:
I have to install the new version, I have the 3.2 installed.
I have to integrate the web apps to my web administration site, so i can add,
remove, update and find users.
Thanks
Alexandre Santos
On 07 Feb 2014, at 15:15, Alexandre Santos asan...@uc.pt wrote:
Thanks, i´m new to this json. How can i find the methods available and there
options?
Thanks
Alexandre Santos
On 07 Feb 2014, at 09:45, Alexander Bokovoy aboko...@redhat.com wrote:
On Fri, 07 Feb 2014, Alexandre Santos wrote:
Hi Martin,
I´ve tried your example and i get this error:
curl -v \
-H Content-Type:application/json \
-H Accept:applicaton/json\
--negotiate -u : \
--delegation always \
--cacert /etc/ipa/ca.crt \
-d '{method:user_find,params:[[],{}],id:0}' \
-X POST https://ipa/ipa/json
...
User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7
NSS/3.13.6.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Host: pi
Content-Type:application/json
Accept:applicaton/json
Content-Length: 48
HTTP/1.1 200 Success
Date: Thu, 06 Feb 2014 16:42:26 GMT
Server: Apache/2.2.15 (CentOS)
Connection: close
Transfer-Encoding: chunked
Content-Type: application/json; charset=utf-8
{
error: {
code: 911,
message: Missing or invalid HTTP Referer, missing,
name: {
__base64__: UmVmZXJlckVycm9y
}
},
id: null,
principal: “admin@ipa,
result: null,
version: 3.0.0
* Closing connection #0
Any suggestion?
You need to set the referrer.
-H referer:https://ipa.mybox/ipa/ui/index.html
--
/ Alexander Bokovoy
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Second batch of ipatests fixes and improvements
On 02/06/2014 07:25 PM, Nathaniel McCallum wrote: On Thu, 2014-02-06 at 07:06 +0100, Tomas Babej wrote: Hi, the attached patches fix the following tickets https://fedorahosted.org/freeipa/ticket/4134 https://fedorahosted.org/freeipa/ticket/4132 and some additional errors as well. Comments in the commit messages. 0146: ACK 0147: ACK 0148: ACK 0149: ACK 0150: ACK Nathaniel Pushed to: master: daf2d64f83c4bd4d0fe60323f51d63e8355652b7 ipa-3-3: b99de765f942d4c4bcdf164d666aa997f593343e -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Clarifying Pilsner/Beer Exchange/Deferred Trac milestones
Hello, I would to follow up on a core devel team discussion we had last week. Part of it were changes to milestones as we currently use it. 1) Pilsner/Beer Exchange/Deferred Currently, we have 3 levels of deferring feature request and bug fix tickets to later releases: a) Pilsner barrel: when planning next release, most of the tickets will come from this release, based on priority or topic of the next release b) Beer Exchange: tickets we do not plan to complete any time soon as we do not consider it critical enough to devote our limited development resources to it. However, it does not mean we do not welcome our community to contact us and provide patches! More details in [1]. It may still happen though, that we will pick a ticket from this milestone to next release, but it is much less likely than with Pilsner c) Deferred: we surely do not plan to complete those and we do not recommend community to look at those either (unless strongly justified). More information about Roadmap in [2]. As discussed, this naming is not very transparent and obvious for people outside of core development team. Thus, to narrow the expectations, we would like to rename it to become more obvious. Here are my proposals: a) Pilsner - Future releases (with appropriate milestone description to set the expectations right) b) Beer Exchange - Backlog (with better description) c) Deferred - can stay as is. If there are any objections or better suggestions, please let me know. [1] http://www.freeipa.org/page/Contribute/Code [2] http://www.freeipa.org/page/Roadmap -- Martin Kosek mko...@redhat.com Supervisor, Software Engineering - Identity Management Team Red Hat Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES 0024, 0025] Classless support for reverse domains
On 10.2.2014 08:50, Petr Spacek wrote:
On 7.2.2014 10:42, Martin Basti wrote:
On Thu, 2014-02-06 at 17:04 +0100, Martin Basti wrote:
On Thu, 2014-02-06 at 16:37 +0100, Jan Cholasta wrote:
On 6.2.2014 15:57, Martin Basti wrote:
On Thu, 2014-02-06 at 10:59 +0100, Jan Cholasta wrote:
Hi,
On 31.1.2014 16:06, Martin Basti wrote:
Reverse domain names in form 0/28.0.10.10.in-addr.arpa. are now
allowed.
Ticket: https://fedorahosted.org/freeipa/ticket/4143
Patches attached.
I add Petr2 to CC, to inspect RFC issues, with allowing '/' in IPv6
I think the validation should be more strict. IPv4 reverse zones
should
allow slash only in the label for the last octet (i.e.
0/25.1.168.192 is
valid, 0.1/25.168.192 is not). IPv6 reverse zones should not allow
slash
at all.
I havent found anything about IPv6, RFCs don't forbids it.
AFAIK the RFCs do not forbid anything, but we do validation anyway, so
we might as well do it right, otherwise there is no point in doing it.
OK, I leave there only IPv4
For the record, we discussed this off-line with Martin and Petr and
figured out it would be best to allow slashes in IPv6 reverse zones
after all.
1.0/25.1.168.192.in-addr.arpa. is also valid, it could be used to
CNAME
records
Yes, obviously. It's 1.0.1/25.168.192.in-addr.arpa. I'm concerned
about.
http://tools.ietf.org/html/rfc6672#section-6.2
This can give a very strange positions of / in FQDN
Point taken.
Optionally, I could permit only 1 slash in domain name, but I have to
inspect first if user can do something useful with subnet of subnet in
DNS, like 1.0/25.128/25.168.192.in-addr.arpa
Multiple slashes has to be allowed, without limitation to last octet.
Imagine situation when split subnet is later split to even smaller pieces.
Guys, do not over-engineer it. IMHO this validator should produce a
warning is something is not as we expect but it should not block user
from adding a record.
We have had enough problems with too strict validators in the past and
IMHO warning is the way to go.
I agree, but it's too late to get such change into 3.3.x.
Petr^2 Spacek
The slashes in domain names are referenced as the best practise in
RFC,
there are not strict rules.
+def _cname_hostname_validator(ugettext, value):
Can you name this _bind_cname_hostname_validator, so that it is
clear it
is related to _bind_hostname_validator?
I will rename it
+#classless reverse zones can contain slash '/'
+if not zone_is_reverse(normalized_zone) and
(normalized_zone.count('/') 0):
+raise errors.ValidationError(name='name',
+error=_(Only reverse zones can contain
'/' in
labels))
This should be handled in _domain_name_validator. Validation in
pre_callback should be done only when the validation depends on
values
of multiple parameters, which is not this case.
I will move it
+def _reverse_zone_pre_callback(self, ldap, dn, entry_attrs,
*keys,
**options):
Rename this to _idnsname_pre_callback and you won't have to call it
explicitly in run_precallback_validators.
I will rename it
+if addr.count('/') 0:
I think if '/' in addr: would be better.
I will change it
-def validate_dns_label(dns_label, allow_underscore=False):
+def validate_dns_label(dns_label, allow_underscore=False,
allow_slash=False):
IMO instead of adding a new boolean argument, it would be nicer to
replace allow_underscore with an argument (e.g. allowed_chars) which
takes a string of extra allowed characters.
But I have to handle not only allowed chars, but position of the chars
in the label string too.
Why? Is there a RFC that forbids it?
My point is, adding a new argument for each extra character is bad,
there should be a better way of doing that.
I agree, but for example: _ should be at start (it is not required be
at the start in IPA), / and - in the middle.
OK then. (But I still don't like it.)
Updated patch attached.
Patch for tests is the same as previos.
+validate_domain_name(value, allow_slash=True)
+
+#classless reverse zones can contain slash '/'
+normalized_zone = normalize_zone(value)
+if not zone_is_reverse(normalized_zone) and ('/' in
normalized_zone):
+return uOnly reverse zones can contain '/' in labels
You don't need to enclose x in y in parentheses. Also I don't think
there is any value in pointing out that slash can be used for reverse
zones when giving an error for non-reverse zones. I would prefer
something like this instead:
normalized_zone = normalize_zone(value)
validate_domain_mame(value,
allow_slash=zone_is_reverse(normalized_zone))
+def _idnsname_pre_callback(self, ldap, dn, entry_attrs, *keys,
**options):
+#in reverse zone can a record name contains /, (and -)
+
+if self.is_pkey_zone_record(*keys):
+addr = u''
+else:
+addr = keys[-1]
+
+zone = keys[-2]
+zone =
Re: [Freeipa-devel] [PATCHES 0024, 0025] Classless support for reverse domains
On Mon, 2014-02-10 at 12:22 +0100, Jan Cholasta wrote:
On 10.2.2014 08:50, Petr Spacek wrote:
On 7.2.2014 10:42, Martin Basti wrote:
On Thu, 2014-02-06 at 17:04 +0100, Martin Basti wrote:
On Thu, 2014-02-06 at 16:37 +0100, Jan Cholasta wrote:
On 6.2.2014 15:57, Martin Basti wrote:
On Thu, 2014-02-06 at 10:59 +0100, Jan Cholasta wrote:
Hi,
On 31.1.2014 16:06, Martin Basti wrote:
Reverse domain names in form 0/28.0.10.10.in-addr.arpa. are now
allowed.
Ticket: https://fedorahosted.org/freeipa/ticket/4143
Patches attached.
I add Petr2 to CC, to inspect RFC issues, with allowing '/' in IPv6
I think the validation should be more strict. IPv4 reverse zones
should
allow slash only in the label for the last octet (i.e.
0/25.1.168.192 is
valid, 0.1/25.168.192 is not). IPv6 reverse zones should not allow
slash
at all.
I havent found anything about IPv6, RFCs don't forbids it.
AFAIK the RFCs do not forbid anything, but we do validation anyway, so
we might as well do it right, otherwise there is no point in doing it.
OK, I leave there only IPv4
For the record, we discussed this off-line with Martin and Petr and
figured out it would be best to allow slashes in IPv6 reverse zones
after all.
1.0/25.1.168.192.in-addr.arpa. is also valid, it could be used to
CNAME
records
Yes, obviously. It's 1.0.1/25.168.192.in-addr.arpa. I'm concerned
about.
http://tools.ietf.org/html/rfc6672#section-6.2
This can give a very strange positions of / in FQDN
Point taken.
Optionally, I could permit only 1 slash in domain name, but I have to
inspect first if user can do something useful with subnet of subnet in
DNS, like 1.0/25.128/25.168.192.in-addr.arpa
Multiple slashes has to be allowed, without limitation to last octet.
Imagine situation when split subnet is later split to even smaller pieces.
Guys, do not over-engineer it. IMHO this validator should produce a
warning is something is not as we expect but it should not block user
from adding a record.
We have had enough problems with too strict validators in the past and
IMHO warning is the way to go.
I agree, but it's too late to get such change into 3.3.x.
Petr^2 Spacek
The slashes in domain names are referenced as the best practise in
RFC,
there are not strict rules.
+def _cname_hostname_validator(ugettext, value):
Can you name this _bind_cname_hostname_validator, so that it is
clear it
is related to _bind_hostname_validator?
I will rename it
+#classless reverse zones can contain slash '/'
+if not zone_is_reverse(normalized_zone) and
(normalized_zone.count('/') 0):
+raise errors.ValidationError(name='name',
+error=_(Only reverse zones can contain
'/' in
labels))
This should be handled in _domain_name_validator. Validation in
pre_callback should be done only when the validation depends on
values
of multiple parameters, which is not this case.
I will move it
+def _reverse_zone_pre_callback(self, ldap, dn, entry_attrs,
*keys,
**options):
Rename this to _idnsname_pre_callback and you won't have to call it
explicitly in run_precallback_validators.
I will rename it
+if addr.count('/') 0:
I think if '/' in addr: would be better.
I will change it
-def validate_dns_label(dns_label, allow_underscore=False):
+def validate_dns_label(dns_label, allow_underscore=False,
allow_slash=False):
IMO instead of adding a new boolean argument, it would be nicer to
replace allow_underscore with an argument (e.g. allowed_chars) which
takes a string of extra allowed characters.
But I have to handle not only allowed chars, but position of the chars
in the label string too.
Why? Is there a RFC that forbids it?
My point is, adding a new argument for each extra character is bad,
there should be a better way of doing that.
I agree, but for example: _ should be at start (it is not required be
at the start in IPA), / and - in the middle.
OK then. (But I still don't like it.)
Updated patch attached.
Patch for tests is the same as previos.
+validate_domain_name(value, allow_slash=True)
+
+#classless reverse zones can contain slash '/'
+normalized_zone = normalize_zone(value)
+if not zone_is_reverse(normalized_zone) and ('/' in
normalized_zone):
+return uOnly reverse zones can contain '/' in labels
You don't need to enclose x in y in parentheses. Also I don't think
there is any value in pointing out that slash can be used for reverse
zones when giving an error for non-reverse zones. I would prefer
something like this instead:
normalized_zone = normalize_zone(value)
validate_domain_mame(value,
allow_slash=zone_is_reverse(normalized_zone))
+def _idnsname_pre_callback(self, ldap, dn, entry_attrs,
[Freeipa-devel] Organizing upstream development in Trac
Hello, FreeIPA core devel team had a discussion about how to organize our development milestones better. Currently, all next release development tickets are put into monthly milestones and then worked in based on priorities. However, this does does not fly well with the non-critical tickets as when the development gets behind schedule, there is a lot of moving tickets around, moving them to $month+1 milestone, causing confusing churn in the ticket history. As agreed on the meeting, we need to improve the situation, this is the proposal: 1) Monthly release milestones will only contain a limited set of scheduled core critical feature that will be a priority for the developer to work on. 2) We will create a new next feature backlog which will contain the less important features and bug fixes, i.e. FreeIPA 3.4 Backlog. When developer has done all his this-month tickets, he can start with the backlog ones, according to priority. 3) Besides these 2 next-release milestone types, there will be a second train for bug fixing current release (we currently have 2014 Month 2 - February (3.3.x bug fixing)). I am thinking this does not need be divided to months as these tickets need to be done asap anyway. So I would name it simply FreeIPA 3.3.5. Note the change from 3.3.x to 3.3.5 - I found that 3.3.x is confusing that it is more difficult to see the exact version where the patch landed. This means that each month, a developer should watch following 3 milestones (in this order): * current release bug fixing milestone: FreeIPA 3.3.5 * next-release monthly milestone: FreeIPA 3.4 - 2014/2 * next-release backlog milestone: FreeIPA 3.4 Backlog If there are no strong objections, I will create new milestones, rename existing ones and sanitize current distribution of 3.4 tickets. IMO this would make the milestone clear, but I am open to other suggestions. -- Martin Kosek mko...@redhat.com Supervisor, Software Engineering - Identity Management Team Red Hat Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Organizing upstream development in Trac
On 02/10/2014 01:22 PM, Martin Kosek wrote: Hello, FreeIPA core devel team had a discussion about how to organize our development milestones better. Currently, all next release development tickets are put into monthly milestones and then worked in based on priorities. However, this does does not fly well with the non-critical tickets as when the development gets behind schedule, there is a lot of moving tickets around, moving them to $month+1 milestone, causing confusing churn in the ticket history. As agreed on the meeting, we need to improve the situation, this is the proposal: 1) Monthly release milestones will only contain a limited set of scheduled core critical feature that will be a priority for the developer to work on. 2) We will create a new next feature backlog which will contain the less important features and bug fixes, i.e. FreeIPA 3.4 Backlog. When developer has done all his this-month tickets, he can start with the backlog ones, according to priority. 3) Besides these 2 next-release milestone types, there will be a second train for bug fixing current release (we currently have 2014 Month 2 - February (3.3.x bug fixing)). I am thinking this does not need be divided to months as these tickets need to be done asap anyway. So I would name it simply FreeIPA 3.3.5. Note the change from 3.3.x to 3.3.5 - I found that 3.3.x is confusing that it is more difficult to see the exact version where the patch landed. Please name it e.g. FreeIPA 3.3.5 (bug fixing) or FreeIPA 3.3.5 (maintenance) for clarity. Numbers have a tendency to get mixed up. This means that each month, a developer should watch following 3 milestones (in this order): * current release bug fixing milestone: FreeIPA 3.3.5 * next-release monthly milestone: FreeIPA 3.4 - 2014/2 * next-release backlog milestone: FreeIPA 3.4 Backlog If there are no strong objections, I will create new milestones, rename existing ones and sanitize current distribution of 3.4 tickets. IMO this would make the milestone clear, but I am open to other suggestions. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Using the Reviewed-by git tag
On 02/10/2014 01:32 PM, Martin Kosek wrote:
Hello,
I would like to follow up on a core devel team discussion we had last week. We
found out, that it would be beneficial to see a reviewer of the patches that
land in our git.
This will serve both as a nice way to both generate statistics who is devoted
to both writing new code, but also to reviewing other people's code (and win
prizes ;-), but it will also offer the git history archaeologist 2 names of
developers which should be the most knowledgeable about the patch.
We will use the current de-facto standard Reviewed-By tag. Example:
commit da70c6d9353cd29531c8e2c135db81a97f22293c
Author: Martin Kosek mko...@redhat.com
Date: Mon Jan 27 12:28:12 2014 +0100
Migration does not add users to default group
When users with missing default group were searched, IPA suffix was
not passed so these users were searched in a wrong base DN. Thus,
no user was detected and added to default group.
https://fedorahosted.org/freeipa/ticket/4141
Reviewed-By: Petr Viktorin pvikt...@redhat.com
Currently, I used to add the tag via git commit --amend. Does anybody have a
nice helper scripts or snippets to semi-automate it? Note that we will be able
to fully automate it when we start with an CI merging system.
I usually hack tasks like these with a special editor for git. I've
attached one for Reviewed-By.
Usage:
REVIEWER='I Myself me@ego.example' GIT_EDITOR=add-reviewed-by.py git
commit --amend -e
I'll use some time this week to write a better patch-pushing helper
that'll incorporate this.
(For the record, now we usually use
https://github.com/mkosek/ipa-tools/blob/master/pushpatch.py)
--
Petr³
#! /usr/bin/python2
import os
import re
import sys
reviewer = os.environ['REVIEWER']
assert re.match('(\w+) ([\w ]+) .*@.*', reviewer), 'wrong format of $REVIEWER'
with open(sys.argv[1]) as infile:
lines = [line for line in infile.readlines() if not line.startswith('#')]
with open(sys.argv[1], 'w') as outfile:
outfile.writelines(lines + ['Reviewed-By: %s' % reviewer])
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Using the Reviewed-by git tag
On 02/10/2014 01:55 PM, Petr Viktorin wrote: On 02/10/2014 01:32 PM, Martin Kosek wrote: Hello, I would like to follow up on a core devel team discussion we had last week. We found out, that it would be beneficial to see a reviewer of the patches that land in our git. This will serve both as a nice way to both generate statistics who is devoted to both writing new code, but also to reviewing other people's code (and win prizes ;-), but it will also offer the git history archaeologist 2 names of developers which should be the most knowledgeable about the patch. We will use the current de-facto standard Reviewed-By tag. Example: commit da70c6d9353cd29531c8e2c135db81a97f22293c Author: Martin Kosek mko...@redhat.com Date: Mon Jan 27 12:28:12 2014 +0100 Migration does not add users to default group When users with missing default group were searched, IPA suffix was not passed so these users were searched in a wrong base DN. Thus, no user was detected and added to default group. https://fedorahosted.org/freeipa/ticket/4141 Reviewed-By: Petr Viktorin pvikt...@redhat.com Currently, I used to add the tag via git commit --amend. Does anybody have a nice helper scripts or snippets to semi-automate it? Note that we will be able to fully automate it when we start with an CI merging system. I usually hack tasks like these with a special editor for git. I've attached one for Reviewed-By. Usage: REVIEWER='I Myself me@ego.example' GIT_EDITOR=add-reviewed-by.py git commit --amend -e Thanks. I'll use some time this week to write a better patch-pushing helper that'll incorporate this. (For the record, now we usually use https://github.com/mkosek/ipa-tools/blob/master/pushpatch.py) That may be the best option for the short term. I would envision something like: $ pushpatch.py freeipa-somebody-1-great.patch ... Reviewed by: 0) Me 1) Petr Vobornik 2) Martin Kosek 3) Petr Viktorin 4) ... 99) Others: Reviewed-By choice [0]: _ Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0032] Update ACIs to permit users to add/delete their own tokens
On Thu, 06 Feb 2014, Nathaniel McCallum wrote:
On Thu, 2014-01-09 at 16:32 -0500, Nathaniel McCallum wrote:
This patch is independent from my patches 0028-0031 and can be merged in
any order.
This patch has a bug, but I can't figure it out. We need to set
nsslapd-access-userattr-strict on cn=config to off. However, during
the rpm installation, I get this error:
DEBUG Unhandled LDAPError: UNWILLING_TO_PERFORM: {'info': 'Deleting
attributes is not allowed', 'desc': 'Server is unwilling to perform'}
ERROR Update failed: Server is unwilling to perform: Deleting attributes
is not allowed
I'm not sure what is causing this. Does anyone have any suggestions?
Attached is a new revision of this patch. It uses the new SELFDN support
present in 389-ds-base 1.3.2.11 that was a result of the previous review
of this patch.
It currently depends on the HOTP patch (0033-2). However, if we wish to
merge this first, this could be easily rebased.
Could you please rebase it? It would be good to merge it first because
0033-2 depends on otp infrastructure patches.
--
/ Alexander Bokovoy
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Using the Reviewed-by git tag
On Mon, Feb 10, 2014 at 01:59:27PM +0100, Martin Kosek wrote: On 02/10/2014 01:55 PM, Petr Viktorin wrote: On 02/10/2014 01:32 PM, Martin Kosek wrote: Hello, I would like to follow up on a core devel team discussion we had last week. We found out, that it would be beneficial to see a reviewer of the patches that land in our git. This will serve both as a nice way to both generate statistics who is devoted to both writing new code, but also to reviewing other people's code (and win prizes ;-), but it will also offer the git history archaeologist 2 names of developers which should be the most knowledgeable about the patch. We will use the current de-facto standard Reviewed-By tag. Example: commit da70c6d9353cd29531c8e2c135db81a97f22293c Author: Martin Kosek mko...@redhat.com Date: Mon Jan 27 12:28:12 2014 +0100 Migration does not add users to default group When users with missing default group were searched, IPA suffix was not passed so these users were searched in a wrong base DN. Thus, no user was detected and added to default group. https://fedorahosted.org/freeipa/ticket/4141 Reviewed-By: Petr Viktorin pvikt...@redhat.com Currently, I used to add the tag via git commit --amend. Does anybody have a nice helper scripts or snippets to semi-automate it? Note that we will be able to fully automate it when we start with an CI merging system. I usually hack tasks like these with a special editor for git. I've attached one for Reviewed-By. Usage: REVIEWER='I Myself me@ego.example' GIT_EDITOR=add-reviewed-by.py git commit --amend -e Thanks. I'll use some time this week to write a better patch-pushing helper that'll incorporate this. (For the record, now we usually use https://github.com/mkosek/ipa-tools/blob/master/pushpatch.py) That may be the best option for the short term. I would envision something like: $ pushpatch.py freeipa-somebody-1-great.patch ... Reviewed by: 0) Me 1) Petr Vobornik 2) Martin Kosek 3) Petr Viktorin 4) ... 99) Others: Reviewed-By choice [0]: _ Martin For SSSD I simply added a ~/.vimrc snippet based on: https://wiki.samba.org/index.php/CodeReview It currently includes: function! CommitMessages() nmap R iReviewed-by: Jakub Hrozek jhro...@redhat.comCRESC iab #R Reviewed-by: iab JH JakubSPACEHrozekSPACEjhro...@redhat.com (and similar entries for other developers) endf autocmd BufWinEnter COMMIT_EDITMSG,*.diff,*.patch,*.patches.txt call CommitMessages() Of course, this wouldn't work if you're using an inferior editor :-] ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES 0024, 0025] Classless support for reverse domains
On 10.2.2014 13:14, Martin Basti wrote:
On Mon, 2014-02-10 at 12:22 +0100, Jan Cholasta wrote:
On 10.2.2014 08:50, Petr Spacek wrote:
On 7.2.2014 10:42, Martin Basti wrote:
On Thu, 2014-02-06 at 17:04 +0100, Martin Basti wrote:
On Thu, 2014-02-06 at 16:37 +0100, Jan Cholasta wrote:
On 6.2.2014 15:57, Martin Basti wrote:
On Thu, 2014-02-06 at 10:59 +0100, Jan Cholasta wrote:
Hi,
On 31.1.2014 16:06, Martin Basti wrote:
Reverse domain names in form 0/28.0.10.10.in-addr.arpa. are now
allowed.
Ticket: https://fedorahosted.org/freeipa/ticket/4143
Patches attached.
I add Petr2 to CC, to inspect RFC issues, with allowing '/' in IPv6
I think the validation should be more strict. IPv4 reverse zones
should
allow slash only in the label for the last octet (i.e.
0/25.1.168.192 is
valid, 0.1/25.168.192 is not). IPv6 reverse zones should not allow
slash
at all.
I havent found anything about IPv6, RFCs don't forbids it.
AFAIK the RFCs do not forbid anything, but we do validation anyway, so
we might as well do it right, otherwise there is no point in doing it.
OK, I leave there only IPv4
For the record, we discussed this off-line with Martin and Petr and
figured out it would be best to allow slashes in IPv6 reverse zones
after all.
1.0/25.1.168.192.in-addr.arpa. is also valid, it could be used to
CNAME
records
Yes, obviously. It's 1.0.1/25.168.192.in-addr.arpa. I'm concerned
about.
http://tools.ietf.org/html/rfc6672#section-6.2
This can give a very strange positions of / in FQDN
Point taken.
Optionally, I could permit only 1 slash in domain name, but I have to
inspect first if user can do something useful with subnet of subnet in
DNS, like 1.0/25.128/25.168.192.in-addr.arpa
Multiple slashes has to be allowed, without limitation to last octet.
Imagine situation when split subnet is later split to even smaller pieces.
Guys, do not over-engineer it. IMHO this validator should produce a
warning is something is not as we expect but it should not block user
from adding a record.
We have had enough problems with too strict validators in the past and
IMHO warning is the way to go.
I agree, but it's too late to get such change into 3.3.x.
Petr^2 Spacek
The slashes in domain names are referenced as the best practise in
RFC,
there are not strict rules.
+def _cname_hostname_validator(ugettext, value):
Can you name this _bind_cname_hostname_validator, so that it is
clear it
is related to _bind_hostname_validator?
I will rename it
+#classless reverse zones can contain slash '/'
+if not zone_is_reverse(normalized_zone) and
(normalized_zone.count('/') 0):
+raise errors.ValidationError(name='name',
+error=_(Only reverse zones can contain
'/' in
labels))
This should be handled in _domain_name_validator. Validation in
pre_callback should be done only when the validation depends on
values
of multiple parameters, which is not this case.
I will move it
+def _reverse_zone_pre_callback(self, ldap, dn, entry_attrs,
*keys,
**options):
Rename this to _idnsname_pre_callback and you won't have to call it
explicitly in run_precallback_validators.
I will rename it
+if addr.count('/') 0:
I think if '/' in addr: would be better.
I will change it
-def validate_dns_label(dns_label, allow_underscore=False):
+def validate_dns_label(dns_label, allow_underscore=False,
allow_slash=False):
IMO instead of adding a new boolean argument, it would be nicer to
replace allow_underscore with an argument (e.g. allowed_chars) which
takes a string of extra allowed characters.
But I have to handle not only allowed chars, but position of the chars
in the label string too.
Why? Is there a RFC that forbids it?
My point is, adding a new argument for each extra character is bad,
there should be a better way of doing that.
I agree, but for example: _ should be at start (it is not required be
at the start in IPA), / and - in the middle.
OK then. (But I still don't like it.)
Updated patch attached.
Patch for tests is the same as previos.
+validate_domain_name(value, allow_slash=True)
+
+#classless reverse zones can contain slash '/'
+normalized_zone = normalize_zone(value)
+if not zone_is_reverse(normalized_zone) and ('/' in
normalized_zone):
+return uOnly reverse zones can contain '/' in labels
You don't need to enclose x in y in parentheses. Also I don't think
there is any value in pointing out that slash can be used for reverse
zones when giving an error for non-reverse zones. I would prefer
something like this instead:
normalized_zone = normalize_zone(value)
validate_domain_mame(value,
allow_slash=zone_is_reverse(normalized_zone))
+def _idnsname_pre_callback(self, ldap, dn, entry_attrs, *keys,
**options):
+#in reverse zone can a record name contains /, (and -)
+
+if self.is_pkey_zone_record(*keys):
+addr = u''
+
Re: [Freeipa-devel] [PATCH] 531-541 OTP UI
On Mon, 2014-02-10 at 14:12 +0100, Petr Vobornik wrote: On 13.1.2014 17:09, Petr Vobornik wrote: Hi, these patches implements the OTP Web UI. Last 5 patches is the OTP UI. First 6 patches is a little refactoring/bug fixes needed for them. General password dialog is introduced to avoid another implementation. Self-service UI is implemented to be very simple. Atm user can choose only token name. Admin interface allows to enter all values. It's based on the RCUE work - we need to push RCUE first. Thanks Nathaniel for review of the last font package. It will speed things up. Know bugs: - there is clash in id's of checkboxes preventing editation of subsequently displayed ones with the same name. Will be fixed in separate patch. - bugs caused by bugs in API (adding/removal of own tokens in self-service, inability to enter key on token creation - https://fedorahosted.org/freeipa/ticket/4099) - datetime format (widget+validator) will be implemented in separate patch - no support of not reviewed CLI patches (HOTP..) Cgit: http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp https://fedorahosted.org/freeipa/ticket/3369 patch 540-1 has been updated - QR code is centered - QR code correction level was lowered from H to M All other current patches from sub-threads are attached as well (it was getting hard to keep track of them). Another nit-pick: in the top menu bar we have the item OTP tokens. However, other two-word menu items are capitalized. Shouldn't this be OTP Tokens? Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 531-541 OTP UI
On Mon, 2014-02-10 at 14:12 +0100, Petr Vobornik wrote: On 13.1.2014 17:09, Petr Vobornik wrote: Hi, these patches implements the OTP Web UI. Last 5 patches is the OTP UI. First 6 patches is a little refactoring/bug fixes needed for them. General password dialog is introduced to avoid another implementation. Self-service UI is implemented to be very simple. Atm user can choose only token name. Admin interface allows to enter all values. It's based on the RCUE work - we need to push RCUE first. Thanks Nathaniel for review of the last font package. It will speed things up. Know bugs: - there is clash in id's of checkboxes preventing editation of subsequently displayed ones with the same name. Will be fixed in separate patch. - bugs caused by bugs in API (adding/removal of own tokens in self-service, inability to enter key on token creation - https://fedorahosted.org/freeipa/ticket/4099) - datetime format (widget+validator) will be implemented in separate patch - no support of not reviewed CLI patches (HOTP..) Cgit: http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp https://fedorahosted.org/freeipa/ticket/3369 patch 540-1 has been updated - QR code is centered - QR code correction level was lowered from H to M All other current patches from sub-threads are attached as well (it was getting hard to keep track of them). When specifying a token using the admin user, the token URI generated is invalid. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 531-541 OTP UI
On 10.2.2014 17:09, Nathaniel McCallum wrote: On Mon, 2014-02-10 at 14:12 +0100, Petr Vobornik wrote: On 13.1.2014 17:09, Petr Vobornik wrote: Hi, these patches implements the OTP Web UI. Last 5 patches is the OTP UI. First 6 patches is a little refactoring/bug fixes needed for them. General password dialog is introduced to avoid another implementation. Self-service UI is implemented to be very simple. Atm user can choose only token name. Admin interface allows to enter all values. It's based on the RCUE work - we need to push RCUE first. Thanks Nathaniel for review of the last font package. It will speed things up. Know bugs: - there is clash in id's of checkboxes preventing editation of subsequently displayed ones with the same name. Will be fixed in separate patch. - bugs caused by bugs in API (adding/removal of own tokens in self-service, inability to enter key on token creation - https://fedorahosted.org/freeipa/ticket/4099) - datetime format (widget+validator) will be implemented in separate patch - no support of not reviewed CLI patches (HOTP..) Cgit: http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp https://fedorahosted.org/freeipa/ticket/3369 patch 540-1 has been updated - QR code is centered - QR code correction level was lowered from H to M All other current patches from sub-threads are attached as well (it was getting hard to keep track of them). When specifying a token using the admin user, the token URI generated is invalid. Yes, but that's API issue: https://fedorahosted.org/freeipa/ticket/4169 -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 531-541 OTP UI
On 10.2.2014 17:03, Nathaniel McCallum wrote:
On Mon, 2014-02-10 at 14:12 +0100, Petr Vobornik wrote:
On 13.1.2014 17:09, Petr Vobornik wrote:
Hi,
these patches implements the OTP Web UI.
Last 5 patches is the OTP UI.
First 6 patches is a little refactoring/bug fixes needed for them.
General password dialog is introduced to avoid another implementation.
Self-service UI is implemented to be very simple. Atm user can choose
only token name. Admin interface allows to enter all values.
It's based on the RCUE work - we need to push RCUE first. Thanks
Nathaniel for review of the last font package. It will speed things up.
Know bugs:
- there is clash in id's of checkboxes preventing editation of
subsequently displayed ones with the same name. Will be fixed in
separate patch.
- bugs caused by bugs in API (adding/removal of own tokens in
self-service, inability to enter key on token creation -
https://fedorahosted.org/freeipa/ticket/4099)
- datetime format (widget+validator) will be implemented in separate patch
- no support of not reviewed CLI patches (HOTP..)
Cgit:
http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp
https://fedorahosted.org/freeipa/ticket/3369
patch 540-1 has been updated
- QR code is centered
- QR code correction level was lowered from H to M
All other current patches from sub-threads are attached as well (it was
getting hard to keep track of them).
Another nit-pick: in the top menu bar we have the item OTP tokens.
However, other two-word menu items are capitalized. Shouldn't this be
OTP Tokens?
ipalib issues as well:
otptoken.py:
object_name = _('OTP tokens')
object_name_plural = _('OTP tokens')
--
Petr Vobornik
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0032] Update ACIs to permit users to add/delete their own tokens
On Mon, 2014-02-10 at 15:11 +0200, Alexander Bokovoy wrote:
On Thu, 06 Feb 2014, Nathaniel McCallum wrote:
On Thu, 2014-01-09 at 16:32 -0500, Nathaniel McCallum wrote:
This patch is independent from my patches 0028-0031 and can be merged in
any order.
This patch has a bug, but I can't figure it out. We need to set
nsslapd-access-userattr-strict on cn=config to off. However, during
the rpm installation, I get this error:
DEBUG Unhandled LDAPError: UNWILLING_TO_PERFORM: {'info': 'Deleting
attributes is not allowed', 'desc': 'Server is unwilling to perform'}
ERROR Update failed: Server is unwilling to perform: Deleting attributes
is not allowed
I'm not sure what is causing this. Does anyone have any suggestions?
Attached is a new revision of this patch. It uses the new SELFDN support
present in 389-ds-base 1.3.2.11 that was a result of the previous review
of this patch.
It currently depends on the HOTP patch (0033-2). However, if we wish to
merge this first, this could be easily rebased.
Could you please rebase it? It would be good to merge it first because
0033-2 depends on otp infrastructure patches.
Done.
Nathaniel
From 3b97eec3a17fec3883520a1cee35fdfa3d529cc9 Mon Sep 17 00:00:00 2001
From: Nathaniel McCallum npmccal...@redhat.com
Date: Thu, 6 Feb 2014 11:27:29 -0500
Subject: [PATCH] Update ACIs to permit users to add/delete their own tokens
---
freeipa.spec.in| 6 +++---
install/share/default-aci.ldif | 1 +
install/updates/40-otp.update | 1 +
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/freeipa.spec.in b/freeipa.spec.in
index c28928c1c5c2d20e2dfe6112750c70bfb0b55894..486cd6156be62d4656c181c8739fc5f7e24711cd 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -21,7 +21,7 @@ Source0:freeipa-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
%if ! %{ONLY_CLIENT}
-BuildRequires: 389-ds-base-devel = 1.3.2.10
+BuildRequires: 389-ds-base-devel = 1.3.2.11
BuildRequires: svrcore-devel
BuildRequires: policycoreutils = %{POLICYCOREUTILSVER}
BuildRequires: systemd-units
@@ -97,7 +97,7 @@ Group: System Environment/Base
Requires: %{name}-python = %{version}-%{release}
Requires: %{name}-client = %{version}-%{release}
Requires: %{name}-admintools = %{version}-%{release}
-Requires: 389-ds-base = 1.3.2.10
+Requires: 389-ds-base = 1.3.2.11
Requires: openldap-clients 2.4.35-4
%if 0%{?fedora} == 18
Requires: nss = 3.14.3-2
@@ -153,7 +153,7 @@ Requires: zip
Requires: policycoreutils = %{POLICYCOREUTILSVER}
Requires: tar
Requires(pre): certmonger = 0.65
-Requires(pre): 389-ds-base = 1.3.2.10
+Requires(pre): 389-ds-base = 1.3.2.11
Requires: fontawesome-fonts
Requires: open-sans-fonts
diff --git a/install/share/default-aci.ldif b/install/share/default-aci.ldif
index 9af9ab28c72e35f7912795e5280170cc6e1bdd80..b7df72109aacdb5cfba9f190da2935917eccaeaa 100644
--- a/install/share/default-aci.ldif
+++ b/install/share/default-aci.ldif
@@ -103,3 +103,4 @@ add: aci
aci: (targetfilter = (objectClass=ipaToken))(targetattrs = objectclass || ipatokenUniqueID || description || ipatokenOwner || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial)(version 3.0; acl Users can read basic token info; allow (read, search, compare) userattr = ipatokenOwner#USERDN;)
aci: (targetfilter = (objectClass=ipaToken))(targetattrs = ipatokenUniqueID || description || ipatokenOwner || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial)(version 3.0; acl Users can write basic token info; allow (write) userattr = ipatokenOwner#USERDN;)
aci: (targetfilter = (objectClass=ipatokenTOTP))(targetattrs = ipatokenOTPkey || ipatokenOTPalgorithm || ipatokenOTPdigits || ipatokenTOTPclockOffset || ipatokenTOTPtimeStep)(version 3.0; acl Users can add TOTP token secrets; allow (write, search) userattr = ipatokenOwner#USERDN;)
+aci: (target = ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX;)(targetfilter = (objectClass=ipaToken))(version 3.0; acl Users can create and delete tokens; allow (add, delete) userattr = ipatokenOwner#SELFDN;)
diff --git a/install/updates/40-otp.update b/install/updates/40-otp.update
index 83dfab7c03bfeb121756410d79143c3812146de6..8e1300fb3d38970e106ac03dce4ce3cb776cd7d1 100644
--- a/install/updates/40-otp.update
+++ b/install/updates/40-otp.update
@@ -7,6 +7,7 @@ dn: $SUFFIX
add: aci:'(targetfilter = (objectClass=ipaToken))(targetattrs = objectclass || ipatokenUniqueID || description || ipatokenOwner || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial)(version 3.0; acl Users can read basic token info; allow (read, search, compare) userattr = ipatokenOwner#USERDN;)'
add: aci:'(targetfilter = (objectClass=ipaToken))(targetattrs = ipatokenUniqueID || description || ipatokenOwner || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial)(version
[Freeipa-devel] [PATCH 0037] Fix OTP token names/labels
This is a typo patch and is therefore an easy review for an aspiring
reviewer. :)
Nathaniel
From 17a85a5e5b620c581c6f70a639240738b2b6794c Mon Sep 17 00:00:00 2001
From: Nathaniel McCallum npmccal...@redhat.com
Date: Mon, 10 Feb 2014 11:39:53 -0500
Subject: [PATCH] Fix OTP token names/labels
---
ipalib/plugins/otptoken.py | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/ipalib/plugins/otptoken.py b/ipalib/plugins/otptoken.py
index 67f24859583bb9c72da1faf2f5fdaa1faf69f437..5a5d35d153e7b3698aeebe1e93831b48a8b8f91e 100644
--- a/ipalib/plugins/otptoken.py
+++ b/ipalib/plugins/otptoken.py
@@ -99,8 +99,8 @@ class otptoken(LDAPObject):
OTP Token object.
container_dn = api.env.container_otp
-object_name = _('OTP tokens')
-object_name_plural = _('OTP tokens')
+object_name = _('OTP Token')
+object_name_plural = _('OTP Tokens')
object_class = ['ipatoken']
possible_objectclasses = ['ipatokentotp']
default_attributes = [
@@ -110,8 +110,8 @@ class otptoken(LDAPObject):
]
rdn_is_primary_key = True
-label = _('OTP tokens')
-label_singular = _('OTP token')
+label = _('OTP Tokens')
+label_singular = _('OTP Token')
takes_params = (
Str('ipatokenuniqueid',
--
1.8.5.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 531-541 OTP UI
On Mon, 2014-02-10 at 17:17 +0100, Petr Vobornik wrote:
On 10.2.2014 17:03, Nathaniel McCallum wrote:
On Mon, 2014-02-10 at 14:12 +0100, Petr Vobornik wrote:
On 13.1.2014 17:09, Petr Vobornik wrote:
Hi,
these patches implements the OTP Web UI.
Last 5 patches is the OTP UI.
First 6 patches is a little refactoring/bug fixes needed for them.
General password dialog is introduced to avoid another implementation.
Self-service UI is implemented to be very simple. Atm user can choose
only token name. Admin interface allows to enter all values.
It's based on the RCUE work - we need to push RCUE first. Thanks
Nathaniel for review of the last font package. It will speed things up.
Know bugs:
- there is clash in id's of checkboxes preventing editation of
subsequently displayed ones with the same name. Will be fixed in
separate patch.
- bugs caused by bugs in API (adding/removal of own tokens in
self-service, inability to enter key on token creation -
https://fedorahosted.org/freeipa/ticket/4099)
- datetime format (widget+validator) will be implemented in separate patch
- no support of not reviewed CLI patches (HOTP..)
Cgit:
http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp
https://fedorahosted.org/freeipa/ticket/3369
patch 540-1 has been updated
- QR code is centered
- QR code correction level was lowered from H to M
All other current patches from sub-threads are attached as well (it was
getting hard to keep track of them).
Another nit-pick: in the top menu bar we have the item OTP tokens.
However, other two-word menu items are capitalized. Shouldn't this be
OTP Tokens?
ipalib issues as well:
otptoken.py:
object_name = _('OTP tokens')
object_name_plural = _('OTP tokens')
Fixed here:
https://www.redhat.com/archives/freeipa-devel/2014-February/msg00090.html
Nathaniel
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 531-541 OTP UI
On Mon, 2014-02-10 at 17:16 +0100, Petr Vobornik wrote: On 10.2.2014 17:09, Nathaniel McCallum wrote: On Mon, 2014-02-10 at 14:12 +0100, Petr Vobornik wrote: On 13.1.2014 17:09, Petr Vobornik wrote: Hi, these patches implements the OTP Web UI. Last 5 patches is the OTP UI. First 6 patches is a little refactoring/bug fixes needed for them. General password dialog is introduced to avoid another implementation. Self-service UI is implemented to be very simple. Atm user can choose only token name. Admin interface allows to enter all values. It's based on the RCUE work - we need to push RCUE first. Thanks Nathaniel for review of the last font package. It will speed things up. Know bugs: - there is clash in id's of checkboxes preventing editation of subsequently displayed ones with the same name. Will be fixed in separate patch. - bugs caused by bugs in API (adding/removal of own tokens in self-service, inability to enter key on token creation - https://fedorahosted.org/freeipa/ticket/4099) - datetime format (widget+validator) will be implemented in separate patch - no support of not reviewed CLI patches (HOTP..) Cgit: http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp https://fedorahosted.org/freeipa/ticket/3369 patch 540-1 has been updated - QR code is centered - QR code correction level was lowered from H to M All other current patches from sub-threads are attached as well (it was getting hard to keep track of them). When specifying a token using the admin user, the token URI generated is invalid. Yes, but that's API issue: https://fedorahosted.org/freeipa/ticket/4169 I agree there is an API issue part of this. However, I think the UI would be cleaner without the default radio button. Putting on my admin hat, when I look at that page I immediately think What is the default!? I think it would be better to leave out the default option and just have the actual default value selected by default. Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0038] Fix generation of invalid OTP URIs
Patch attached.
From e7eac9997750ee1a8ce864746dbc6faa54de766b Mon Sep 17 00:00:00 2001
From: Nathaniel McCallum npmccal...@redhat.com
Date: Mon, 10 Feb 2014 12:07:51 -0500
Subject: [PATCH] Fix generation of invalid OTP URIs
---
ipalib/plugins/otptoken.py | 9 +
1 file changed, 9 insertions(+)
diff --git a/ipalib/plugins/otptoken.py b/ipalib/plugins/otptoken.py
index 5a5d35d153e7b3698aeebe1e93831b48a8b8f91e..ff92efa11776171b09993060e0805c8ffa6806da 100644
--- a/ipalib/plugins/otptoken.py
+++ b/ipalib/plugins/otptoken.py
@@ -202,6 +202,15 @@ class otptoken_add(LDAPCreate):
)
def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options):
+# These are values we always want to write to LDAP. So if they are
+# specified as a value that evaluates to False (i.e. None), delete them
+# and fill in the defaults below.
+for attr in ('ipatokentotpclockoffset', 'ipatokentotptimestep',
+ 'ipatokenotpalgorithm', 'ipatokenotpdigits',
+ 'ipatokenotpkey'):
+if attr in entry_attrs and not entry_attrs[attr]:
+del entry_attrs[attr]
+
# Set defaults. This needs to happen on the server side because we may
# have global configurable defaults in the near future.
options.setdefault('type', TOKEN_TYPES[0])
--
1.8.5.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 531-541 OTP UI
On Mon, 2014-02-10 at 11:49 -0500, Nathaniel McCallum wrote: On Mon, 2014-02-10 at 17:16 +0100, Petr Vobornik wrote: On 10.2.2014 17:09, Nathaniel McCallum wrote: On Mon, 2014-02-10 at 14:12 +0100, Petr Vobornik wrote: On 13.1.2014 17:09, Petr Vobornik wrote: Hi, these patches implements the OTP Web UI. Last 5 patches is the OTP UI. First 6 patches is a little refactoring/bug fixes needed for them. General password dialog is introduced to avoid another implementation. Self-service UI is implemented to be very simple. Atm user can choose only token name. Admin interface allows to enter all values. It's based on the RCUE work - we need to push RCUE first. Thanks Nathaniel for review of the last font package. It will speed things up. Know bugs: - there is clash in id's of checkboxes preventing editation of subsequently displayed ones with the same name. Will be fixed in separate patch. - bugs caused by bugs in API (adding/removal of own tokens in self-service, inability to enter key on token creation - https://fedorahosted.org/freeipa/ticket/4099) - datetime format (widget+validator) will be implemented in separate patch - no support of not reviewed CLI patches (HOTP..) Cgit: http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp https://fedorahosted.org/freeipa/ticket/3369 patch 540-1 has been updated - QR code is centered - QR code correction level was lowered from H to M All other current patches from sub-threads are attached as well (it was getting hard to keep track of them). When specifying a token using the admin user, the token URI generated is invalid. Yes, but that's API issue: https://fedorahosted.org/freeipa/ticket/4169 I agree there is an API issue part of this. However, I think the UI would be cleaner without the default radio button. Putting on my admin hat, when I look at that page I immediately think What is the default!? I think it would be better to leave out the default option and just have the actual default value selected by default. API-side of this problem is fixed here: https://www.redhat.com/archives/freeipa-devel/2014-February/msg00093.html Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 531-541 OTP UI
On 10.2.2014 17:49, Nathaniel McCallum wrote:
On Mon, 2014-02-10 at 17:16 +0100, Petr Vobornik wrote:
On 10.2.2014 17:09, Nathaniel McCallum wrote:
On Mon, 2014-02-10 at 14:12 +0100, Petr Vobornik wrote:
On 13.1.2014 17:09, Petr Vobornik wrote:
Hi,
these patches implements the OTP Web UI.
Last 5 patches is the OTP UI.
First 6 patches is a little refactoring/bug fixes needed for them.
General password dialog is introduced to avoid another implementation.
Self-service UI is implemented to be very simple. Atm user can choose
only token name. Admin interface allows to enter all values.
It's based on the RCUE work - we need to push RCUE first. Thanks
Nathaniel for review of the last font package. It will speed things up.
Know bugs:
- there is clash in id's of checkboxes preventing editation of
subsequently displayed ones with the same name. Will be fixed in
separate patch.
- bugs caused by bugs in API (adding/removal of own tokens in
self-service, inability to enter key on token creation -
https://fedorahosted.org/freeipa/ticket/4099)
- datetime format (widget+validator) will be implemented in separate patch
- no support of not reviewed CLI patches (HOTP..)
Cgit:
http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp
https://fedorahosted.org/freeipa/ticket/3369
patch 540-1 has been updated
- QR code is centered
- QR code correction level was lowered from H to M
All other current patches from sub-threads are attached as well (it was
getting hard to keep track of them).
When specifying a token using the admin user, the token URI generated is
invalid.
Yes, but that's API issue: https://fedorahosted.org/freeipa/ticket/4169
I agree there is an API issue part of this. However, I think the UI
would be cleaner without the default radio button. Putting on my admin
hat, when I look at that page I immediately think What is the
default!? I think it would be better to leave out the default option
and just have the actual default value selected by default.
Nathaniel
I agree with the What's the default? part. However The Web UI should
be consistent with CLI. In this case the default is not clearly defined
and both options are defined as optional, i.e. I would change the UI to
your proposal if the ipalib definition was:
IntEnum('ipatokenotpdigits',
cli_name='digits',
label=_('Display length'),
values=(6, 8),
default=6,
flags=('no_update'),
),
Btw, why are these two options optional? In one otptoken.py comment you
proposed to introduce global configuration in near future. With it,
every global configuration change might break existing tokens. So in any
case the value should be written to LDAP (which is not happening atm).
--
Petr Vobornik
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Clarifying Pilsner/Beer Exchange/Deferred Trac milestones
On 02/10/2014 05:03 AM, Martin Kosek wrote: Hello, I would to follow up on a core devel team discussion we had last week. Part of it were changes to milestones as we currently use it. 1) Pilsner/Beer Exchange/Deferred Currently, we have 3 levels of deferring feature request and bug fix tickets to later releases: a) Pilsner barrel: when planning next release, most of the tickets will come from this release, based on priority or topic of the next release b) Beer Exchange: tickets we do not plan to complete any time soon as we do not consider it critical enough to devote our limited development resources to it. However, it does not mean we do not welcome our community to contact us and provide patches! More details in [1]. It may still happen though, that we will pick a ticket from this milestone to next release, but it is much less likely than with Pilsner c) Deferred: we surely do not plan to complete those and we do not recommend community to look at those either (unless strongly justified). More information about Roadmap in [2]. As discussed, this naming is not very transparent and obvious for people outside of core development team. Thus, to narrow the expectations, we would like to rename it to become more obvious. Here are my proposals: a) Pilsner - Future releases (with appropriate milestone description to set the expectations right) Next release backlog b) Beer Exchange - Backlog (with better description) General ticket pool c) Deferred - can stay as is. If there are any objections or better suggestions, please let me know. [1] http://www.freeipa.org/page/Contribute/Code [2] http://www.freeipa.org/page/Roadmap -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Organizing upstream development in Trac
On 02/10/2014 07:28 AM, Petr Viktorin wrote: On 02/10/2014 01:22 PM, Martin Kosek wrote: Hello, FreeIPA core devel team had a discussion about how to organize our development milestones better. Currently, all next release development tickets are put into monthly milestones and then worked in based on priorities. However, this does does not fly well with the non-critical tickets as when the development gets behind schedule, there is a lot of moving tickets around, moving them to $month+1 milestone, causing confusing churn in the ticket history. As agreed on the meeting, we need to improve the situation, this is the proposal: 1) Monthly release milestones will only contain a limited set of scheduled core critical feature that will be a priority for the developer to work on. 2) We will create a new next feature backlog which will contain the less important features and bug fixes, i.e. FreeIPA 3.4 Backlog. When developer has done all his this-month tickets, he can start with the backlog ones, according to priority. 3) Besides these 2 next-release milestone types, there will be a second train for bug fixing current release (we currently have 2014 Month 2 - February (3.3.x bug fixing)). I am thinking this does not need be divided to months as these tickets need to be done asap anyway. So I would name it simply FreeIPA 3.3.5. Note the change from 3.3.x to 3.3.5 - I found that 3.3.x is confusing that it is more difficult to see the exact version where the patch landed. Please name it e.g. FreeIPA 3.3.5 (bug fixing) or FreeIPA 3.3.5 (maintenance) for clarity. Numbers have a tendency to get mixed up. +1 This means that each month, a developer should watch following 3 milestones (in this order): * current release bug fixing milestone: FreeIPA 3.3.5 * next-release monthly milestone: FreeIPA 3.4 - 2014/2 * next-release backlog milestone: FreeIPA 3.4 Backlog If there are no strong objections, I will create new milestones, rename existing ones and sanitize current distribution of 3.4 tickets. IMO this would make the milestone clear, but I am open to other suggestions. +1 -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Clarifying Pilsner/Beer Exchange/Deferred Trac milestones
- Original Message - From: Dmitri Pal d...@redhat.com To: freeipa-devel@redhat.com Sent: Monday, February 10, 2014 9:21:41 PM Subject: Re: [Freeipa-devel] Clarifying Pilsner/Beer Exchange/Deferred Trac milestones ... a) Pilsner - Future releases (with appropriate milestone description to set the expectations right) Next release backlog b) Beer Exchange - Backlog (with better description) General ticket pool Yeah, that would work too. I vouched for backlog as it is shorter to spell (e.g. during triage meeting), has the same meaning (at least for me) and is already used in other projects like bind-dyndb-ldap. But if people want General ticket pool, I can live with that. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Samba FS ticket
Hi, We have a ticket [1] about Samba FS documentation. Alexander added a comment recently but I know Sumit is working on this effort now. Should we pull ticket in and/or merge it with some other ticket wit have? [1] https://fedorahosted.org/freeipa/ticket/3999 -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0039] Enable FAST support in SSSD by default
https://fedorahosted.org/freeipa/ticket/4173
I do have one question. Do we ever try to upgrade the SSSD config? If
so, should we try to upgrade the SSSD config to enable FAST by
default?
Nathaniel
From f3ee3e6b4aaddd4636fdee1e2ffad28a7e23559f Mon Sep 17 00:00:00 2001
From: Nathaniel McCallum npmccal...@redhat.com
Date: Mon, 10 Feb 2014 16:03:56 -0500
Subject: [PATCH] Enable FAST support in SSSD by default
https://fedorahosted.org/freeipa/ticket/4173
---
ipa-client/ipa-install/ipa-client-install | 2 ++
1 file changed, 2 insertions(+)
diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa-install/ipa-client-install
index 0d6037bd16d9c0e5f544d033382571226488815d..62e43882e2dd231d3761680ab9a97cf47f354c29 100755
--- a/ipa-client/ipa-install/ipa-client-install
+++ b/ipa-client/ipa-install/ipa-client-install
@@ -1151,6 +1151,8 @@ def configure_sssd_conf(fstore, cli_realm, cli_domain, cli_server, options, clie
domain.set_option('ipa_domain', cli_domain)
domain.set_option('ipa_hostname', client_hostname)
+domain.set_option('krb5_use_fast', 'try')
+domain.set_option('krb5_fast_principal', 'host/%s' % client_hostname)
if cli_domain.lower() != cli_realm.lower():
domain.set_option('krb5_realm', cli_realm)
--
1.8.5.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Web services in freeIPA
On 02/07/2014 04:33 AM, Alexandre Santos wrote:
Hi Martin,
I´ve tried your example and i get this error:
curl -v \
-H Content-Type:application/json \
-H Accept:applicaton/json\
--negotiate -u : \
--delegation always \
--cacert /etc/ipa/ca.crt \
-d '{method:user_find,params:[[],{}],id:0}' \
-X POST https://ipa/ipa/json
...
User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7
NSS/3.13.6.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Host: pi
Content-Type:application/json
Accept:applicaton/json
Content-Length: 48
HTTP/1.1 200 Success
Date: Thu, 06 Feb 2014 16:42:26 GMT
Server: Apache/2.2.15 (CentOS)
Connection: close
Transfer-Encoding: chunked
Content-Type: application/json; charset=utf-8
{
error: {
code: 911,
message: Missing or invalid HTTP Referer, missing,
name: {
__base64__: UmVmZXJlckVycm9y
}
},
id: null,
principal: admin@ipa,
result: null,
version: 3.0.0
* Closing connection #0
Any suggestion?
That is the CSRF check.
Explicitly set the referrer header to the same URL as the web server and
you should be OK
Alexandre Santos
On 06 Feb 2014, at 15:12, Martin Kosek mko...@redhat.com
mailto:mko...@redhat.com wrote:
As Petr said, we do not have a proper documentation for using RPC for
controlling IPA. But I think you can start with looking at [1] to see the
template and try running our commands with -vv which will show you
how we
call the API:
$ ipa -vv user-show admin
Martin
[1]
http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/
On 02/06/2014 04:04 PM, Alexandre Santos wrote:
Is there any examples that can guide me.
Thanks
Alexandre Santos
On 06 Feb 2014, at 14:33, Petr Vobornik pvobo...@redhat.com
mailto:pvobo...@redhat.com wrote:
On 6.2.2014 15:22, Alexandre Santos wrote:
Hi,
I´m starting in freeIPA and I would like to know what web apps are
available for use, like create user, delete user and so on. I´ve
seen that when i use the command ipa -vv user-add a url for the
app if given.
I would like to know if there is any information about that.
Thanks
Alexandre Santos
The url you saw is most-likely for XML RPC API.
You can check:
https://hostname/ipa/xml - XML RPC API
https://hostname/ipa/json - JSON RPC API
https://hostname/ipa/session/xml XML RPC API with session support
https://hostname/ipa/session/json JSON RPC API with session support
https://hostname/ipa/ui - Web UI
https://hostname/ipa/config/unauthorized.html - some config and
error pages
We don't have docs for the APIs yet.
--
Petr Vobornik
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0039] Enable FAST support in SSSD by default
On Mon, Feb 10, 2014 at 04:06:37PM -0500, Nathaniel McCallum wrote: https://fedorahosted.org/freeipa/ticket/4173 I do have one question. Do we ever try to upgrade the SSSD config? If so, should we try to upgrade the SSSD config to enable FAST by default? Nathaniel What if we changed the SSSD defaults instead? Would enabling FAST by default break backwards compatibility in any way if we set it to try ? I would prefer to keep the config as clean as possible and only rely on sane defaults. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Contribute to Freeipa
Hi all, I would like to help contribute some to the FreeIPA project. I am an Infrastructure engineer and not a developer by trade, and I am familiar with the IPA product. I can do some basic things (which may not be that much help) such as documentation, some simple code (trivial and some minor tickets), grammar consistency in ipa help commands, etc. I was looking at some of the documentation tickets and have created a couple of patches that I can attach for review. Let me know what you guys think. Thanks, Gabe ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Contribute to Freeipa
On 02/11/2014 05:49 AM, Darth Vader wrote: Hi all, I would like to help contribute some to the FreeIPA project. I am an Infrastructure engineer and not a developer by trade, and I am familiar with the IPA product. I can do some basic things (which may not be that much help) such as documentation, some simple code (trivial and some minor tickets), grammar consistency in ipa help commands, etc. I was looking at some of the documentation tickets and have created a couple of patches that I can attach for review. Let me know what you guys think. Thanks, Gabe Hi Gabe, I think that it's a great idea. By contributing you will not only learn more about FreeIPA and this technology, but also help us move this project forward. See [1] and especially [2] and [3] for help and guide how to contribute code or documentation. To see what are the current milestones and most wanted tasks to be completed, check [4]. If you want to start with easier tickets, you can search for easyfix in ticket keywords, but we do not always set it for the easy ones. If you questions, feel free to ask on this list. May the Force be with you, Martin [1] http://www.freeipa.org/page/Contribute [2] http://www.freeipa.org/page/Contribute/Documentation [3] http://www.freeipa.org/page/Contribute/Code [4] http://www.freeipa.org/page/Roadmap ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
