Re: [Freeipa-devel] [PATCH] 718 webui: better error reporting
On 12.8.2014 17:57, Endi Sukma Dewata wrote: On 8/5/2014 6:19 AM, Petr Vobornik wrote: On page: - styled to use proper line breaks - centered by .container class and not by huge padding Console: - proper line breaks - links in stack trace are clickable(Chrome) ACK. Pushed to ipa-4-0: * d3a7fecdaf7e8a8bd35713ff53a6e0dcbc9e webui: better error reporting ipa-4-1: * 23413e9daad540d3f23aedf124fba64a9b5a1904 webui: better error reporting master: * e995d2b827cae875245a479ee0a090c546f2858e webui: better error reporting -- Endi S. Dewata -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 719 webui-ci: fix table widget add
On 12.8.2014 17:58, Endi Sukma Dewata wrote: On 8/5/2014 6:20 AM, Petr Vobornik wrote: add_table_record call used old selector for add button which caused 3 fails in CI: - ERROR: Test automember rebuild membership feature for hosts - ERROR: Test automember rebuild membership feature for users - ERROR: Basic CRUD: dns related to: https://fedorahosted.org/freeipa/ticket/4258 ACK. -- Endi S. Dewata Pushed to: ipa-4-0: 4582f48806644a7088eb1cda9beff189c5aa2c68 ipa-4-1: 4fde71672eb22390480d40fb0ed3c27df040a1b3 master: a3c51e2383a0abc6ab09537734187f67356fea0b -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0635 Support delegating RBAC roles to service principals
On 08/19/2014 07:49 PM, Petr Viktorin wrote: On 08/19/2014 01:41 PM, Martin Kosek wrote: On 08/19/2014 01:28 PM, Petr Viktorin wrote: Services can now be added to roles. https://fedorahosted.org/freeipa/ticket/3164 I added a new integration test for checking that a service can actually use the right granted by a role. I don't think there's a good way to do this kind of thing in our Declarative test suite. 1) I think you also need to update service object's attribute_members so that it can properly show role membership. Right, added (with tests). Thanks! (especially for the tests) I am thinking about one usability improvement. All over the code, we allow to specify services without the REALM as the realm is pretty clear and we do not need it from the user: # ipa service-add test/`hostname` -- Added service test/ipa.mkosek-fedora20.t...@mkosek-fedora20.test -- Principal: test/ipa.mkosek-fedora20.t...@mkosek-fedora20.test Managed by: ipa.mkosek-fedora20.test However, the new --services option does not allow that: ]# ipa role-add-member foo --services test/`hostname` Role name: foo Description: foo Failed members: member user: member group: member host: member host group: member service: test/ipa.mkosek-fedora20.test: no such entry - Number of members added 0 - Could we just add the realm if it does not exists in the service-add-member precallback? Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0635 Support delegating RBAC roles to service principals
On 08/20/2014 10:59 AM, Martin Kosek wrote: On 08/19/2014 07:49 PM, Petr Viktorin wrote: ... Could we just add the realm if it does not exists in the service-add-member precallback? s/service-add-member/role-add-member/ Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] Change BuildRequires for Java
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Requiring a specific version of Java leads to breakages, like the one happening on nightly builds in Fedora Rawhide right now. We should use the more generic 'java' BuildRequires instead of the versioned one. This is breaking my nightly static analysis scans on Rawhide. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlP0jZoACgkQeiVVYja6o6OyNgCeL/x+CKnGMhuw8tGM/X3xi5Po L+8AoKI14SRizGxPmBpjhuZkxk8uZlLU =l8zE -END PGP SIGNATURE- From 19bdee103f9db004a3869cffd7ad516bc5661784 Mon Sep 17 00:00:00 2001 From: Stephen Gallagher sgall...@redhat.com Date: Wed, 20 Aug 2014 07:56:59 -0400 Subject: [PATCH] Change BuildRequires for Java Requiring a specific version of Java leads to breakages, like the one happening on nightly builds in Fedora Rawhide right now. We should use the more generic 'java' BuildRequires instead of the versioned one. --- freeipa.spec.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/freeipa.spec.in b/freeipa.spec.in index 6f22bc92f76f2e4bd732a995e392d6845dab27b7..47a14f4cfd9ab2e05ba6910cb85d2f34c965a8b5 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -65,7 +65,7 @@ BuildRequires: m2crypto BuildRequires: check BuildRequires: libsss_idmap-devel BuildRequires: libsss_nss_idmap-devel -BuildRequires: java-1.7.0-openjdk +BuildRequires: java BuildRequires: rhino BuildRequires: libverto-devel BuildRequires: systemd -- 2.0.4 0001-Change-BuildRequires-for-Java.patch.sig Description: PGP signature ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Change BuildRequires for Java
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/20/2014 07:59 AM, Stephen Gallagher wrote: Requiring a specific version of Java leads to breakages, like the one happening on nightly builds in Fedora Rawhide right now. We should use the more generic 'java' BuildRequires instead of the versioned one. This is breaking my nightly static analysis scans on Rawhide. It was pointed out on IRC that we should be using java-headless as well. Updated patch attached. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlP0kb0ACgkQeiVVYja6o6PpRQCeMwFoK+Pm1YILMhGqW6gxPF8B f54AmgPufg9fMKo2/l4h3yh5/13S6SHW =lFv4 -END PGP SIGNATURE- From 660a209df59fec3108466bbf10bdb5f37b17fbaa Mon Sep 17 00:00:00 2001 From: Stephen Gallagher sgall...@redhat.com Date: Wed, 20 Aug 2014 07:56:59 -0400 Subject: [PATCH] Change BuildRequires for Java Requiring a specific version of Java leads to breakages, like the one happening on nightly builds in Fedora Rawhide right now. We should use the more generic 'java' BuildRequires instead of the versioned one. --- freeipa.spec.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/freeipa.spec.in b/freeipa.spec.in index 6f22bc92f76f2e4bd732a995e392d6845dab27b7..163f2a476bccc4a06e13c3f78e7204755d2b03af 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -65,7 +65,7 @@ BuildRequires: m2crypto BuildRequires: check BuildRequires: libsss_idmap-devel BuildRequires: libsss_nss_idmap-devel -BuildRequires: java-1.7.0-openjdk +BuildRequires: java-headless BuildRequires: rhino BuildRequires: libverto-devel BuildRequires: systemd -- 2.0.4 0001-Change-BuildRequires-for-Java.patch.sig Description: PGP signature ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0061] Ensure ipaUserAuthTypeClass when needed on user creation
On 08/19/2014 10:46 PM, Nathaniel McCallum wrote: Also, remove the attempt to load the objectClasses when absent. This never makes sense during an add operation. https://fedorahosted.org/freeipa/ticket/4455 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Hello Nathaniel, Reading the patch I have one novice remark. In the previous code, 'objectclass' was added to 'entry_attr' in the case it was missing in 'entry_attr' (at the condition 'ipatokenradiusconfiglink' was defined). In the new code, if 'objectclass' is missing it is not added. Is it ok ? Also, regarding the 'user life cycle'. Staging users are candidate to become Active users. I wonder if Staging users should also contain your fix that add the ipaUserAuthTypeClass. thanks thierry ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] - Add DRM to IPA
On 08/18/2014 07:36 PM, Ade Lee wrote:
[...]
After discussion with Endi, I also removed some functions in dogtag.py
(the plugin) which basically just wrapped calls to the keyclient. There
is no need to do this wrapping and it is much more flexible for IPA code
to call the keyclient directly. Accordingly, I have added a method to
get the keyclient. Your test code would look like this now:
from ipalib import api
from pki.key import KeyClient
api.bootstrap(context='server')
api.finalize()
keyclient = api.Backend.kra.get_keyclient()
keyclient.archive_key('test', KeyClient.PASS_PHRASE_TYPE,'tkey')
I added a couple of directives in the proxy file to allow it to progress
further and it now fails in trying to do the archive_key due to
authentication issues.
It was never the intention of this patch to get the plugin completely
working though. That was the goal of a follow on patch being written by
Endi. This patch is already pretty long and touches a lot of code. I
propose we let Endi fix the above issue.
I understand. However, I don't know another way to do a functional test.
Without the plugin the best I can do is look if there are some extra
entries in DS, and since I don't know KRA internals I can't check if
they're correct.
With the above script, I get:
from ipalib import api
from pki.key import KeyClient
api.bootstrap(context='server')
api.finalize()
keyclient = api.Backend.kra.get_keyclient()
keyclient.archive_key('test', KeyClient.PASS_PHRASE_TYPE,'tkey')
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/lib/python2.7/site-packages/pki/__init__.py, line 253, in
handler
return fn_call(inst, *args, **kwargs)
File /usr/lib/python2.7/site-packages/pki/key.py, line 616, in
archive_key
key_size=key_size)
File /usr/lib/python2.7/site-packages/pki/__init__.py, line 253, in
handler
return fn_call(inst, *args, **kwargs)
File /usr/lib/python2.7/site-packages/pki/key.py, line 669, in
archive_encrypted_data
return self.create_request(request)
File /usr/lib/python2.7/site-packages/pki/__init__.py, line 253, in
handler
return fn_call(inst, *args, **kwargs)
File /usr/lib/python2.7/site-packages/pki/key.py, line 527, in
create_request
response = self.connection.post(url, key_request, self.headers)
File /usr/lib/python2.7/site-packages/pki/client.py, line 70, in post
params=params)
File /usr/lib/python2.7/site-packages/requests/sessions.py, line
377, in post
return self.request('POST', url, data=data, **kwargs)
File /usr/lib/python2.7/site-packages/requests/sessions.py, line
335, in request
resp = self.send(prep, **send_kwargs)
File /usr/lib/python2.7/site-packages/requests/sessions.py, line
438, in send
r = adapter.send(request, **kwargs)
File /usr/lib/python2.7/site-packages/requests/adapters.py, line
331, in send
raise SSLError(e)
requests.exceptions.SSLError: [Errno 1] _ssl.c:1419: error:140943F2:SSL
routines:SSL3_READ_BYTES:sslv3 alert unexpected message
I have squashed the drm- kra changes and created just a single patch,
which is attached. This is the only patch needed.
I didn't find any issues except the error above.
I'm also starting a new COPR build, just to be sure we all have the most
up-to-date dogtag build.
Things are working nicely for the most part. However I still did manage
to break my installation:
- Install master and replica, both with CA and KRA
- Remove KRA on both hosts
At this point, trying to instal KRA on the replica fails:
$ sudo ipa-kra-install replica-info-file.gpg
Usage: ipa-kra-install [options] [replica_file]
ipa-kra-install: error: Too many parameters provided. No replica file
is required.
$ sudo ipa-kra-install
Directory Manager password:
===
This program will setup Dogtag KRA for the FreeIPA Server.
Configuring KRA server (pki-tomcatd): Estimated time 2 minutes 6 seconds
[1/5]: configuring KRA instance
failed to configure KRA instance Command ''/usr/sbin/pkispawn' '-s'
'KRA' '-f' '/tmp/tmp_FKfkR'' returned non-zero exit status 1
Your system may be partly configured.
Run ipa-kra-install --uninstall to clean up.
Configuration of KRA failed
This seems to cripple the installation: ipa-kra-install --uninstall will
complain that KRA is not installed. Also, ipa-kra-install on the master
will complain that it wasn't given a replica file.
I understand this is an edge case, but we should handle it if we support
uninstallation.
I'd be okay with disabling --uninstall for now and filing a ticket for
later. (After all, ipa-ca-install doesn't have --uninstall at all.)
--
Petr³
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0061] Ensure ipaUserAuthTypeClass when needed on user creation
On Wed, 2014-08-20 at 14:35 +0200, thierry bordaz wrote: On 08/19/2014 10:46 PM, Nathaniel McCallum wrote: Also, remove the attempt to load the objectClasses when absent. This never makes sense during an add operation. https://fedorahosted.org/freeipa/ticket/4455 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Hello Nathaniel, Reading the patch I have one novice remark. In the previous code, 'objectclass' was added to 'entry_attr' in the case it was missing in 'entry_attr' (at the condition 'ipatokenradiusconfiglink' was defined). In the new code, if 'objectclass' is missing it is not added. Is it ok ? I don't think objectClass is ever missing. It must be specified in an add operation. Attempting to load the attribute doesn't make sense when you are adding the object. Also, regarding the 'user life cycle'. Staging users are candidate to become Active users. I wonder if Staging users should also contain your fix that add the ipaUserAuthTypeClass. What code is this in? Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0061] Ensure ipaUserAuthTypeClass when needed on user creation
On 08/20/2014 03:48 PM, Nathaniel McCallum wrote: On Wed, 2014-08-20 at 14:35 +0200, thierry bordaz wrote: On 08/19/2014 10:46 PM, Nathaniel McCallum wrote: Also, remove the attempt to load the objectClasses when absent. This never makes sense during an add operation. https://fedorahosted.org/freeipa/ticket/4455 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Hello Nathaniel, Reading the patch I have one novice remark. In the previous code, 'objectclass' was added to 'entry_attr' in the case it was missing in 'entry_attr' (at the condition 'ipatokenradiusconfiglink' was defined). In the new code, if 'objectclass' is missing it is not added. Is it ok ? I don't think objectClass is ever missing. It must be specified in an add operation. Attempting to load the attribute doesn't make sense when you are adding the object. Yes I agree. Also, regarding the 'user life cycle'. Staging users are candidate to become Active users. I wonder if Staging users should also contain your fix that add the ipaUserAuthTypeClass. What code is this in? Well it is not yet into master. stageuser plugin is still under review (design is http://www.freeipa.org/page/V3/User_Life-Cycle_Management) Now parts of stageuser_add code are close to user_add. When a stage user is activated (stage user entry is move to Active container), it becomes a full IPA user. This is why if a IPA user needs to be 'ipauserauthtypeclass' it impacts stage user. Either stageuser_add does the same as user_add or stageuser_activate checks the need of 'ipauserauthtypeclass. thanks thierry Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Change BuildRequires for Java
On 20.8.2014 14:17, Stephen Gallagher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/20/2014 07:59 AM, Stephen Gallagher wrote: Requiring a specific version of Java leads to breakages, like the one happening on nightly builds in Fedora Rawhide right now. We should use the more generic 'java' BuildRequires instead of the versioned one. This is breaking my nightly static analysis scans on Rawhide. It was pointed out on IRC that we should be using java-headless as well. Updated patch attached. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlP0kb0ACgkQeiVVYja6o6PpRQCeMwFoK+Pm1YILMhGqW6gxPF8B f54AmgPufg9fMKo2/l4h3yh5/13S6SHW =lFv4 -END PGP SIGNATURE- ACK Pushed to: ipa-4-0: 52f7bb4de98b4c43828668222b14d8f490d61bb7 ipa-4-1: a6927994a0fd17f0fa7446f037d9840f21bcb445 master: fa8f180ff5d68d0f492af258785a06e4c8079e1b Tested on f20 and rawhide. -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0107-0108] Fix DNS wildcard validation
Patches attached.
Ticket: https://fedorahosted.org/freeipa/ticket/4488
--
Martin Basti
From f8e26732ed07466c9fb19d921154b444c393f829 Mon Sep 17 00:00:00 2001
From: Martin Basti mba...@redhat.com
Date: Wed, 20 Aug 2014 15:14:12 +0200
Subject: [PATCH 1/2] FIX DNS wildcard records (RFC4592)
Make validation more strict
* DS, NS, CNAME, DNAME owners should not be a wildcard domanin name
* zone name should not be a wildcard domain name
Ticket: https://fedorahosted.org/freeipa/ticket/4488
---
ipalib/plugins/dns.py | 22 ++
1 file changed, 22 insertions(+)
diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py
index fdcccb0b74a2b044a1ad917d22d2fe9696d7584c..c301e0fb20381c89ed059266992d25dadb19a6bc 100644
--- a/ipalib/plugins/dns.py
+++ b/ipalib/plugins/dns.py
@@ -489,6 +489,14 @@ def _hostname_validator(ugettext, value):
return None
+def _no_wildcard_validator(ugettext, value):
+Disallow usage of wildcards as RFC 4592 recommends
+
+assert isinstance(value, DNSName)
+if value.is_wild():
+return _('should not be a wildcard domain name (RFC 4592)')
+return None
+
def is_forward_record(zone, str_address):
addr = netaddr.IPAddress(str_address)
if addr.version == 4:
@@ -1731,6 +1739,7 @@ class DNSZoneBase(LDAPObject):
takes_params = (
DNSNameParam('idnsname',
+_no_wildcard_validator, # RFC 4592 section 4
only_absolute=True,
cli_name='name',
label=_('Zone name'),
@@ -2619,6 +2628,19 @@ class dnsrecord(LDAPObject):
error=unicode(_('out-of-zone data: record name must '
'be a subdomain of the zone or a '
'relative name')))
+# dissallowed wildcard (RFC 4592)
+no_wildcard_rtypes = ['CNAME', 'DNAME', 'DS', 'NS']
+if (keys[-1].is_wild() and
+any(entry_attrs.get('%srecord' % r.lower())
+for r in no_wildcard_rtypes)
+):
+raise errors.ValidationError(
+name='idnsname',
+error=(_('owner of %(types)s records '
+'should not be a wildcard domain name (RFC 4592)') %
+{'types': ', '.join(no_wildcard_rtypes)}
+)
+)
def _ptrrecord_pre_callback(self, ldap, dn, entry_attrs, *keys, **options):
assert isinstance(dn, DN)
--
1.8.3.1
From 1b991efa650c8e286f4cce55285a2325c043ec0e Mon Sep 17 00:00:00 2001
From: Martin Basti mba...@redhat.com
Date: Wed, 20 Aug 2014 17:26:34 +0200
Subject: [PATCH 2/2] Tests: DNS wildcard records
Ticket: https://fedorahosted.org/freeipa/ticket/4488
---
ipatests/test_xmlrpc/test_dns_plugin.py | 58 -
1 file changed, 57 insertions(+), 1 deletion(-)
diff --git a/ipatests/test_xmlrpc/test_dns_plugin.py b/ipatests/test_xmlrpc/test_dns_plugin.py
index 50b4d2ec7bf4d55f7d138f45993184f1bf7790bd..f4111b0086f49f80e34be0e879d247cd9a89007e 100644
--- a/ipatests/test_xmlrpc/test_dns_plugin.py
+++ b/ipatests/test_xmlrpc/test_dns_plugin.py
@@ -263,6 +263,7 @@ zone_findtest_forward = u'forward.find.test.'
zone_findtest_forward_dnsname = DNSName(zone_findtest_forward)
zone_findtest_forward_dn = DN(('idnsname', zone_findtest_forward), api.env.container_dns, api.env.basedn)
+zone_fw_wildcard = u'*.wildcardforwardzone.test.'
class test_dns(Declarative):
@@ -289,7 +290,8 @@ class test_dns(Declarative):
revzone3_classless1, revzone3_classless2,
idnzone1, revidnzone1, zone_findtest_master],
{'continue': True}),
-('dnsforwardzone_del', [fwzone1, zone_findtest_forward],
+('dnsforwardzone_del', [fwzone1, zone_findtest_forward,
+zone_fw_wildcard],
{'continue': True}),
('dnsconfig_mod', [], {'idnsforwarders' : None,
'idnsforwardpolicy' : None,
@@ -2736,6 +2738,50 @@ class test_dns(Declarative):
dict(
+desc='Try to add NS record to wildcard owner %r in zone %r' % (wildcard_rec1, zone1),
+command=('dnsrecord_add', [zone1, wildcard_rec1], {'nsrecord': zone2_ns, 'force': True}),
+expected=errors.ValidationError(
+name='idnsname',
+error=(u'owner of CNAME, DNAME, DS, NS records '
+'should not be a wildcard domain name (RFC 4592)')
+)
+),
+
+
+dict(
+desc='Try to add CNAME record to wildcard owner %r in zone %r' % (wildcard_rec1, zone1),
+command=('dnsrecord_add', [zone1, wildcard_rec1], {'cnamerecord': u'cname.test.'}),
+expected=errors.ValidationError(
+name='idnsname',
+error=(u'owner of CNAME, DNAME, DS, NS records '
+'should not be a wildcard domain name (RFC 4592)')
+)
+
Re: [Freeipa-devel] [PATCH] 0635 Support delegating RBAC roles to service principals
On 08/20/2014 10:59 AM, Martin Kosek wrote:
On 08/19/2014 07:49 PM, Petr Viktorin wrote:
On 08/19/2014 01:41 PM, Martin Kosek wrote:
On 08/19/2014 01:28 PM, Petr Viktorin wrote:
Services can now be added to roles.
https://fedorahosted.org/freeipa/ticket/3164
I added a new integration test for checking that a service can actually use the
right granted by a role. I don't think there's a good way to do this kind of
thing in our Declarative test suite.
1) I think you also need to update service object's attribute_members so that
it can properly show role membership.
Right, added (with tests).
Thanks! (especially for the tests)
I am thinking about one usability improvement. All over the code, we allow to
specify services without the REALM as the realm is pretty clear and we do not
need it from the user:
# ipa service-add test/`hostname`
--
Added service test/ipa.mkosek-fedora20.t...@mkosek-fedora20.test
--
Principal: test/ipa.mkosek-fedora20.t...@mkosek-fedora20.test
Managed by: ipa.mkosek-fedora20.test
However, the new --services option does not allow that:
]# ipa role-add-member foo --services test/`hostname`
Role name: foo
Description: foo
Failed members:
member user:
member group:
member host:
member host group:
member service: test/ipa.mkosek-fedora20.test: no such entry
-
Number of members added 0
-
Could we just add the realm if it does not exists in the service-add-member
precallback?
Looks like we want to add it any time we look up a service, right?
This additional patch should do that.
--
Petr³
From 84837621c9be1ff31df8fea5e91c306d653a2b71 Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Wed, 20 Aug 2014 15:34:34 +0200
Subject: [PATCH] service: Normalize service principal in get_dn
This will make any lookup go through the normalization.
---
ipalib/plugins/service.py | 3 +++
ipatests/test_xmlrpc/test_service_plugin.py | 10 ++
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/ipalib/plugins/service.py b/ipalib/plugins/service.py
index 69b2cc6c3c667c07fdcac46d9bb36e9f5e2830c1..3ca5066f300a004c993660e0a5e220c364e38cbf 100644
--- a/ipalib/plugins/service.py
+++ b/ipalib/plugins/service.py
@@ -406,6 +406,9 @@ def validate_ipakrbauthzdata(self, entry):
raise errors.ValidationError(name='ipakrbauthzdata',
error=_('NONE value cannot be combined with other PAC types'))
+def get_dn(self, *keys, **kwargs):
+keys = (normalize_principal(k) for k in keys)
+return super(service, self).get_dn(*keys, **kwargs)
@register()
diff --git a/ipatests/test_xmlrpc/test_service_plugin.py b/ipatests/test_xmlrpc/test_service_plugin.py
index 5be27af9eab29dd2235db8a275b902f1e486b472..40eb7eca5532d39e10db9711e7e41221519815cf 100644
--- a/ipatests/test_xmlrpc/test_service_plugin.py
+++ b/ipatests/test_xmlrpc/test_service_plugin.py
@@ -33,7 +33,8 @@
fqdn1 = u'testhost1.%s' % api.env.domain
fqdn2 = u'testhost2.%s' % api.env.domain
fqdn3 = u'TestHost3.%s' % api.env.domain
-service1 = u'HTTP/%s@%s' % (fqdn1, api.env.realm)
+service1_no_realm = u'HTTP/%s' % fqdn1
+service1 = u'%s@%s' % (service1_no_realm, api.env.realm)
hostprincipal1 = u'host/%s@%s' % (fqdn1, api.env.realm)
service1dn = DN(('krbprincipalname',service1),('cn','services'),('cn','accounts'),api.env.basedn)
host1dn = DN(('fqdn',fqdn1),('cn','computers'),('cn','accounts'),api.env.basedn)
@@ -667,7 +668,7 @@ class test_service_in_role(Declarative):
dict(
desc='Create %r' % service1,
-command=('service_add', [service1], dict(force=True)),
+command=('service_add', [service1_no_realm], dict(force=True)),
expected=dict(
value=service1,
summary=u'Added service %s' % service1,
@@ -698,7 +699,8 @@ class test_service_in_role(Declarative):
dict(
desc='Add %r to %r' % (service1, role1),
-command=('role_add_member', [role1], dict(service=service1)),
+command=('role_add_member', [role1],
+ dict(service=service1_no_realm)),
expected=dict(
failed=dict(
member=dict(
@@ -721,7 +723,7 @@ class test_service_in_role(Declarative):
dict(
desc='Verify %r is member of %r' % (service1, role1),
-command=('service_show', [service1], {}),
+command=('service_show', [service1_no_realm], {}),
expected=dict(
value=service1,
summary=None,
--
1.9.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCHES 0109-0110] DNS: fix DS record validation
Part of DNSSEC
Patches attached.
--
Martin Basti
From f5e3b504911a1729546e45f33d2008e7ab1c421d Mon Sep 17 00:00:00 2001
From: Martin Basti mba...@redhat.com
Date: Wed, 20 Aug 2014 18:51:25 +0200
Subject: [PATCH 1/2] DNSSEC: fix DS record validation
Part of: https://fedorahosted.org/freeipa/ticket/3801
---
ipalib/plugins/dns.py | 19 +++
1 file changed, 19 insertions(+)
diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py
index c301e0fb20381c89ed059266992d25dadb19a6bc..f134f2c67b222876103da1c8bbaa009208f3c163 100644
--- a/ipalib/plugins/dns.py
+++ b/ipalib/plugins/dns.py
@@ -2610,6 +2610,14 @@ class dnsrecord(LDAPObject):
doc=_('Parse all raw DNS records and return them in a structured way'),
)
+def _dsrecord_pre_callback(self, ldap, dn, entry_attrs, *keys, **options):
+assert isinstance(dn, DN)
+dsrecords = entry_attrs.get('dsrecord')
+if dsrecords and self.is_pkey_zone_record(*keys):
+raise errors.ValidationError(
+name='dsrecord',
+error=unicode(_('DS record must not be in zone apex (RFC 4035 section 2.4)')))
+
def _nsrecord_pre_callback(self, ldap, dn, entry_attrs, *keys, **options):
assert isinstance(dn, DN)
nsrecords = entry_attrs.get('nsrecord')
@@ -2917,6 +2925,17 @@ class dnsrecord(LDAPObject):
'NS record except when located in a zone root '
'record (RFC 6672, section 2.3)'))
+# DS record validation
+dsrecords = rrattrs.get('dsrecord')
+nsrecords = rrattrs.get('nsrecord')
+# DS record cannot be in zone apex, checked in pre-callback validators
+if dsrecords and not nsrecords:
+raise errors.ValidationError(
+name='dsrecord',
+error=_('DS record requires to coexist with an '
+ 'NS record (RFC 4529, section 4.6)'))
+
+
def _entry2rrsets(self, entry_attrs, dns_name, dns_domain):
'''Convert entry_attrs to a dictionary {rdtype: rrset}.
--
1.8.3.1
From 15ea9a3e9b69fb49fa802199f959d3fe479c2153 Mon Sep 17 00:00:00 2001
From: Martin Basti mba...@redhat.com
Date: Wed, 20 Aug 2014 18:53:49 +0200
Subject: [PATCH 2/2] Tests: DNS dsrecord validation
Part of: https://fedorahosted.org/freeipa/ticket/3801
---
ipatests/test_xmlrpc/test_dns_plugin.py | 61 +
1 file changed, 61 insertions(+)
diff --git a/ipatests/test_xmlrpc/test_dns_plugin.py b/ipatests/test_xmlrpc/test_dns_plugin.py
index f4111b0086f49f80e34be0e879d247cd9a89007e..6b9cbe2d57b8e528a0d83974429c6e9d1b2b77e7 100644
--- a/ipatests/test_xmlrpc/test_dns_plugin.py
+++ b/ipatests/test_xmlrpc/test_dns_plugin.py
@@ -147,6 +147,12 @@ dlv_dn = DN(('idnsname', dlv), zone1_dn)
dlvrec = u'60485 5 1 2BB183AF5F22588179A53B0A98631FAD1A292118'
+ds = u'ds'
+ds_dnsname = DNSName(ds)
+ds_dn = DN(('idnsname', ds), zone1_dn)
+
+ds_rec = u'0 0 0 00'
+
tlsa = u'tlsa'
tlsa_dnsname = DNSName(tlsa)
tlsa_dn = DN(('idnsname', tlsa), zone1_dn)
@@ -1323,6 +1329,61 @@ class test_dns(Declarative):
dict(
+desc='Try to add DS record to zone %r apex, using dnsrecord_add' % (zone1),
+command=('dnsrecord_add', [zone1, zone1_absolute], {'dsrecord': ds_rec}),
+expected=errors.ValidationError(
+name=dsrecord,
+error=u'DS record must not be in zone apex (RFC 4035 section 2.4)'
+),
+),
+
+
+dict(
+desc='Try to add DS record %r without NS record in RRset, using dnsrecord_add' % (ds),
+command=('dnsrecord_add', [zone1, ds], {'dsrecord': ds_rec}),
+expected=errors.ValidationError(
+name=dsrecord,
+error=u'DS record requires to coexist with an NS record (RFC 4529, section 4.6)'
+),
+),
+
+
+dict(
+desc='Add NS record to %r using dnsrecord_add' % (ds),
+command=('dnsrecord_add', [zone1, ds],
+ {'nsrecord': zone1_ns}),
+expected={
+'value': ds_dnsname,
+'summary': None,
+'result': {
+'objectclass': objectclasses.dnsrecord,
+'dn': ds_dn,
+'idnsname': [ds_dnsname],
+'nsrecord': [zone1_ns],
+},
+},
+),
+
+
+dict(
+desc='Add DS record to %r using dnsrecord_add' % (ds),
+command=('dnsrecord_add', [zone1, ds],
+ {'dsrecord': ds_rec}),
+expected={
+'value': ds_dnsname,
+'summary': None,
+'result': {
+'objectclass': objectclasses.dnsrecord,
+'dn': ds_dn,
+'idnsname': [ds_dnsname],
+
Re: [Freeipa-devel] [PATCH] 730-732 webui: Login pages usability improvements
On 12.8.2014 22:58, Endi Sukma Dewata wrote: On 8/5/2014 6:36 AM, Petr Vobornik wrote: [PATCH] 730 webui: display expired session notification in a more visible area The notification is a primary information of the page. It should be more highlighted. https://fedorahosted.org/freeipa/ticket/4470 ACK. [PATCH] 731 webui: improved info msgs on login/token sync/reset pwd pages - add info icons to distinguish and classify the messages. - add info text for OTP fields - fix login instruction inaccuracy related to position of login button https://fedorahosted.org/freeipa/ticket/4470 Just one thing, instead of enter them in the fields nearby how about enter them in the corresponding fields? Otherwise it's ACKed. Changed, pushed using trivial/one-liner rule [PATCH] 732 webui: login screen - improved button switching - added cancel button to reset password view of login screen - re-implemented buttons hiding mechanism - switching between 'Reset Password' and 'Reset Password and Login' according to presence of value in OTP field https://fedorahosted.org/freeipa/ticket/4470 The code seems to be fine so it's ACKed, but see comments below: 1. It looks like the OTP token needs to be synchronized before it can be used for the first time. Is that true for all types of tokens (hardware/software, TOTP/HOTP)? If possible the synchronization should be part of the token creation process, so the admin can provide a token that can be used right away, so we may need an interface in the UI to sync the tokens. If the sync can only be done by users themselves, there should be a message on the login screen for first time OTP users to synchronize the token first. Synchronization right away won't hurt but it's not always required. TOTP works for me if the device has properly synchronized time. I haven't noticed any sync issue with HOTP. Synchronization right from the UI is covered by: https://fedorahosted.org/freeipa/ticket/4365 https://fedorahosted.org/freeipa/ticket/4366 2. Try logging in with an incorrect password/OTP. After you get a login error click Sync OTP Token. Once the sync is completed it will go back to the login page with a Token was synchronized message that disappears in a few seconds, but the old login error still appears which is confusing. Error messages in the UI should only reflect the last executed operation. I'll fix it in separate patch. -- Endi S. Dewata Pushed to: master: * a94fc09b5747ff5ffc632d95b330470ed78ee0f5 webui: display expired session notification in a more visible area * cba5247f99bca6eb8ed73b73f20cb9e9b3a45e91 webui: improved info msgs on login/token sync/reset pwd pages * 4832f2986d1a457acf3ff000433aa0732364c19c webui: login screen - improved button switching ipa-4-1: * 6f8dc9dba488caba7be2afc17b9e2b5191ffa585 webui: display expired session notification in a more visible area * 68647276ed58cb46c64884c2944cbd90979faf79 webui: improved info msgs on login/token sync/reset pwd pages * b37854051d6afd3f57ce28d059105797d13f0c22 webui: login screen - improved button switching -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] - Add DRM to IPA
Ade Lee wrote:
On Thu, 2014-08-14 at 14:29 +0200, Petr Viktorin wrote:
On 08/14/2014 10:53 AM, Martin Kosek wrote:
On 08/13/2014 09:54 PM, Ade Lee wrote:
In Dogtag, we have decided to revert the name of the DRM to the old name
KRA.
DRM was really only used in docs/marketing, whereas KRA is all over the
code.
Soon, the code and the marketing/docs will match.
The following patch changes all references to the DRM to KRA.
so for example, you need to run ipa-kra-install etc.
Please apply this on top of the previous patch. I'll go ahead and squash
them
before commit.
Thanks,
Ade
Ah, thanks for unifying that one. I changed DRM component in FreeIPA Trac to
KRA and assigned respective tickets to that. Let us use the KRA term for the
Vault then.
Martin
ipa_drm_install.py: No newline at end of file
ipa_drm_install.DRMInstaller.FAIL_MESSAGE: the command is
ipa-drm-install (with hyphens)
fixed
The error I got previously was when running ipa-kra-install on a replica
that didn't have CA yet. It would be nice to provide a better message
for this case.
agreed. the problem here was that the check to see whether a ca was
already installed locally was not working as expected.
I have since added a new check - which should fail if a CA is not
installed locally.
On a replica with KRA, I get:
$ sudo ipa-kra-install --uninstall
Usage: ipa-kra-install [options] [replica_file]
ipa-kra-install: error: Cannot uninstall. There is no KRA
installed on this system.
Not sure what happened there. With the latest code, that does not
appear to happen for me. Let me know if it recurs.
I tested the kra plugin with this Python script:
from ipalib import api
api.bootstrap(context='server', kra_host='localhost')
api.finalize()
api.Backend.kra.store_secret('test', 'tkey')
which gives me:
Traceback (most recent call last):
File stdin, line 1, in module
File ipaserver/plugins/dogtag.py, line 2012, in store_secret
self._setup()
File ipaserver/plugins/dogtag.py, line 1965, in _setup
connection = PKIConnection('https', self.kra_host,
self.kra_port, 'kra')
File /usr/lib/python2.7/site-packages/pki/client.py, line 36,
in __init__
self.hostname + ':' + self.port + '/' + \
TypeError: coercing to Unicode: need string or buffer, int found
Apparently, PKIConnection requires the port to be a string, but we pass
an int. I'd consider this an issue in pki.
Agreed. I will open a ticket to fix it in pki. For now though, I have
cast to str().
The kra_host='localhost' option to api.bootstrap is necessary because
kra_host is not added to default.conf on install. How is this planned to
work when the plugin is done?
I followed what was done for ca_host, but did not set the required
default in constants.py. Thats fixed, so this should work now.
After discussion with Endi, I also removed some functions in dogtag.py
(the plugin) which basically just wrapped calls to the keyclient. There
is no need to do this wrapping and it is much more flexible for IPA code
to call the keyclient directly. Accordingly, I have added a method to
get the keyclient. Your test code would look like this now:
from ipalib import api
from pki.key import KeyClient
api.bootstrap(context='server')
api.finalize()
keyclient = api.Backend.kra.get_keyclient()
keyclient.archive_key('test', KeyClient.PASS_PHRASE_TYPE,'tkey')
I added a couple of directives in the proxy file to allow it to progress
further and it now fails in trying to do the archive_key due to
authentication issues.
It was never the intention of this patch to get the plugin completely
working though. That was the goal of a follow on patch being written by
Endi. This patch is already pretty long and touches a lot of code. I
propose we let Endi fix the above issue.
I have squashed the drm- kra changes and created just a single patch,
which is attached. This is the only patch needed.
I'm also starting a new COPR build, just to be sure we all have the most
up-to-date dogtag build.
It doesn't look like the --no-host-dns option is used anywhere.
I'm kinda with Petr, I don't know that an uninstall option is needed.
On a single master install I successfully did a kra install, uninstall,
re-install, so maybe the issue that Petr saw was related to cloning.
There is no man page for ipa-kra-install
Functionally the KRA itself seems to be working ok.
rob
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] - Add DRM to IPA
On Wed, 2014-08-20 at 15:35 -0400, Rob Crittenden wrote:
Ade Lee wrote:
On Thu, 2014-08-14 at 14:29 +0200, Petr Viktorin wrote:
On 08/14/2014 10:53 AM, Martin Kosek wrote:
On 08/13/2014 09:54 PM, Ade Lee wrote:
In Dogtag, we have decided to revert the name of the DRM to the old name
KRA.
DRM was really only used in docs/marketing, whereas KRA is all over the
code.
Soon, the code and the marketing/docs will match.
The following patch changes all references to the DRM to KRA.
so for example, you need to run ipa-kra-install etc.
Please apply this on top of the previous patch. I'll go ahead and
squash them
before commit.
Thanks,
Ade
Ah, thanks for unifying that one. I changed DRM component in FreeIPA Trac
to
KRA and assigned respective tickets to that. Let us use the KRA term for
the
Vault then.
Martin
ipa_drm_install.py: No newline at end of file
ipa_drm_install.DRMInstaller.FAIL_MESSAGE: the command is
ipa-drm-install (with hyphens)
fixed
The error I got previously was when running ipa-kra-install on a replica
that didn't have CA yet. It would be nice to provide a better message
for this case.
agreed. the problem here was that the check to see whether a ca was
already installed locally was not working as expected.
I have since added a new check - which should fail if a CA is not
installed locally.
On a replica with KRA, I get:
$ sudo ipa-kra-install --uninstall
Usage: ipa-kra-install [options] [replica_file]
ipa-kra-install: error: Cannot uninstall. There is no KRA
installed on this system.
Not sure what happened there. With the latest code, that does not
appear to happen for me. Let me know if it recurs.
I tested the kra plugin with this Python script:
from ipalib import api
api.bootstrap(context='server', kra_host='localhost')
api.finalize()
api.Backend.kra.store_secret('test', 'tkey')
which gives me:
Traceback (most recent call last):
File stdin, line 1, in module
File ipaserver/plugins/dogtag.py, line 2012, in store_secret
self._setup()
File ipaserver/plugins/dogtag.py, line 1965, in _setup
connection = PKIConnection('https', self.kra_host,
self.kra_port, 'kra')
File /usr/lib/python2.7/site-packages/pki/client.py, line 36,
in __init__
self.hostname + ':' + self.port + '/' + \
TypeError: coercing to Unicode: need string or buffer, int found
Apparently, PKIConnection requires the port to be a string, but we pass
an int. I'd consider this an issue in pki.
Agreed. I will open a ticket to fix it in pki. For now though, I have
cast to str().
The kra_host='localhost' option to api.bootstrap is necessary because
kra_host is not added to default.conf on install. How is this planned to
work when the plugin is done?
I followed what was done for ca_host, but did not set the required
default in constants.py. Thats fixed, so this should work now.
After discussion with Endi, I also removed some functions in dogtag.py
(the plugin) which basically just wrapped calls to the keyclient. There
is no need to do this wrapping and it is much more flexible for IPA code
to call the keyclient directly. Accordingly, I have added a method to
get the keyclient. Your test code would look like this now:
from ipalib import api
from pki.key import KeyClient
api.bootstrap(context='server')
api.finalize()
keyclient = api.Backend.kra.get_keyclient()
keyclient.archive_key('test', KeyClient.PASS_PHRASE_TYPE,'tkey')
I added a couple of directives in the proxy file to allow it to progress
further and it now fails in trying to do the archive_key due to
authentication issues.
Did some more investigation on this. It turns out that the problem is
in the PEM file that is generated (/etc/httpd/aliad/agent.pem)
There are in fact two problems. One is that the agent.pem that is
available there is for the IPA RA agent, who is not an agent on the KRA.
Also, it appears that the PEM file itself may have some weirdness in its
format.
The PEM file is generated by the code _generate_pem_file() in dogtag.py.
That code will need to be re-examined and fixed. I would like to leave
that task to Endi - as he needs to decide how/which agent will be used
to communicate with the KRA.
If you use a valid agent PEM, then the above test code works.
Here is what I did:
$ openssl pkcs12 -in /root/ca_agent.p12 -out /etc/httpd/alias/agent.pem -nodes
And then I ran the following without issues:
from ipalib import api
from pki.key import KeyClient
api.bootstrap(context='server')
api.finalize()
keyclient = api.Backend.kra.get_keyclient()
infos = keyclient.list_keys()
for info in infos.key_infos:
print {0} {1}.format(info.client_key_id, info.key_url)
keyclient.archive_key('test3',
