Re: [Freeipa-devel] [PATCH] Permission MOD command fix
On 18.2.2014 21:03, Martin Kosek wrote: On 02/18/2014 06:52 PM, Petr Viktorin wrote: On 02/18/2014 06:46 PM, Jan Cholasta wrote: Hi, On 18.2.2014 18:40, Nathaniel McCallum wrote: On Tue, 2014-02-18 at 12:31 -0500, Adam Misnyovszki wrote: Hi, this patch fixes permission-mod command returning duplicate memberships. https://fedorahosted.org/freeipa/ticket/4175 NACK This patch does not apply to master. Nathaniel The ticket is for 3.3. ACK on the patch. Honza Thanks! Welcome to FreeIPA. +1! I've added a few more words and the ticket URL to the commit message. Next time, please be a bit more verbose. Pushed to ipa-3-3: 2ae2e9b142f1e34f5c95da93ec74ccaa90af2d27 Yes, please see the guidelines we have on our wiki: http://www.freeipa.org/page/Contribute/Code http://www.freeipa.org/page/Contribute/Patch_Format Note to code itself - it would be better to check for memberofindirect_ instead of memberofindirect so that it is consistent with already used member_ part. Or even better, one could work with self.obj.attribute_members to see all the possible memberships. Actually I think just memberindirect is correct here, because unlike member, both memberindirect and memberindirect_* are not real attributes. But this is just a nitpick, this patch lives in ipa-3-3 only anyway. Martin -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0025] Add support to ipa-kdb for keyless principals
On 02/18/2014 09:02 PM, Alexander Bokovoy wrote: On Tue, 12 Nov 2013, Nathaniel McCallum wrote: https://fedorahosted.org/freeipa/ticket/3779 ACK Pushed to master: b769d1c18678b5eede7505dec7938f6836070044 -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0025] Add support to ipa-kdb for keyless principals
On Tue, 2013-11-12 at 10:59 -0500, Nathaniel McCallum wrote:
diff --git a/util/ipa_krb5.c b/util/ipa_krb5.c
index
934fd27d80cdd846f4de631b2dd587b0ad0f325c..cc84f9920a7b105c926cb765b435c0fbdfac
100644
--- a/util/ipa_krb5.c
+++ b/util/ipa_krb5.c
@@ -296,6 +296,9 @@ void ipa_krb5_free_key_data(krb5_key_data *keys,
int num_keys)
{
int i;
+if (keys == NULL)
+return;
+
for (i = 0; i num_keys; i++) {
/* try to wipe key from memory,
* hopefully the compiler will not optimize it away */
--
This part is useless and can be dropped.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0025] Add support to ipa-kdb for keyless principals
On Wed, 2014-02-19 at 15:24 +0200, Alexander Bokovoy wrote:
On Wed, 19 Feb 2014, Simo Sorce wrote:
On Tue, 2013-11-12 at 10:59 -0500, Nathaniel McCallum wrote:
diff --git a/util/ipa_krb5.c b/util/ipa_krb5.c
index
934fd27d80cdd846f4de631b2dd587b0ad0f325c..cc84f9920a7b105c926cb765b435c0fbdfac
100644
--- a/util/ipa_krb5.c
+++ b/util/ipa_krb5.c
@@ -296,6 +296,9 @@ void ipa_krb5_free_key_data(krb5_key_data *keys,
int num_keys)
{
int i;
+if (keys == NULL)
+return;
+
for (i = 0; i num_keys; i++) {
/* try to wipe key from memory,
* hopefully the compiler will not optimize it away */
--
This part is useless and can be dropped.
If ever num_key is not 0 and yet keys == NULL, we'll get crash in the
line
if (keys[i].key_data_length[0]) {
because there are no checks at all before that.
If num_keys do not reflect the number of keys in the structure at all
times you have bigger problems.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 0468 permission-mod: Do not copy member attributes to new entry
Hello, This fixes https://fedorahosted.org/freeipa/ticket/4178 -- Petr³ From 85222e02ce57224ea661c990c69efecbf7907a74 Mon Sep 17 00:00:00 2001 From: Petr Viktorin pvikt...@redhat.com Date: Wed, 19 Feb 2014 14:18:58 +0100 Subject: [PATCH] permission-mod: Do not copy member attributes to new entry Fixes: https://fedorahosted.org/freeipa/ticket/4178 --- ipalib/plugins/permission.py | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/ipalib/plugins/permission.py b/ipalib/plugins/permission.py index 3382525337ede044804adb90b741aa15571cd9a9..670e3f1c65452fef26838558ad115ebc2aeda87a 100644 --- a/ipalib/plugins/permission.py +++ b/ipalib/plugins/permission.py @@ -928,7 +928,9 @@ def pre_callback(self, ldap, dn, entry, attrs_list, *keys, **options): # it cannot be used directly to generate an ACI. # First we need to copy the original data into it. for key, value in old_entry.iteritems(): -if key not in options and key != 'cn': +if (key not in options and +key != 'cn' and +key not in self.obj.attribute_members): entry.setdefault(key, value) filter_ops = context.filter_ops -- 1.8.5.3 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0015] Add wait_for_dns option to default.conf
On 18.2.2014 17:34, Nathaniel McCallum wrote:
On Tue, 2014-02-18 at 17:06 +0100, Petr Viktorin wrote:
On 02/18/2014 04:45 PM, Petr Spacek wrote:
Hello,
Add wait_for_dns option to default.conf.
This option makes record changes in DNS tree synchronous.
IPA calls will wait until new data are visible over DNS protocol.
It is intended only for testing - it should prevent tests from
failing if there is bigger delay between change in LDAP and DNS.
I would recommend value like 10 seconds.
Here are a few Python nitpicks you requested.
Thank you very much. This new version solves problems you found + adds proper
handling for real DNS timeouts.
It seems to me like a more general TimeoutError would be useful in a
broader context. DNSTimeout seems overly narrow to me, unless I'm
missing something.
I would like to keep them separate. DNSTimeout shouldn't be handled at all
because it means that your DNS server or database is dead or broken in some
interesting way.
I assume that generic TimeoutError could be interpreted as 'try it
again'/'failover' or something like that.
Maybe the DNSTimeout is not the best name, I'm open to suggestions.
--
Petr^2 Spacek
From 7ad81ab266754afb1e5b33b459bc92399ff2f09c Mon Sep 17 00:00:00 2001
From: Petr Spacek pspa...@redhat.com
Date: Fri, 14 Feb 2014 15:33:24 +0100
Subject: [PATCH] Add wait_for_dns option to default.conf.
This option makes record changes in DNS tree synchronous.
IPA calls will wait until new data are visible over DNS protocol.
It is intended only for testing - it should prevent tests from
failing if there is bigger delay between change in LDAP and DNS.
---
ipa-client/man/default.conf.5 | 3 +
ipalib/constants.py | 1 +
ipalib/errors.py | 18 ++
ipalib/plugins/dns.py | 145 --
4 files changed, 163 insertions(+), 4 deletions(-)
diff --git a/ipa-client/man/default.conf.5 b/ipa-client/man/default.conf.5
index 5d5a48db62cb97e7424b42b6cb70d0c872b2bc34..7e3e02858732789776b9225ae6e9cffeac4004d1 100644
--- a/ipa-client/man/default.conf.5
+++ b/ipa-client/man/default.conf.5
@@ -178,6 +178,9 @@ Used internally in the IPA source package to verify that the API has not changed
.B verbose boolean
When True provides more information. Specifically this sets the global log level to info.
.TP
+.B wait_for_dns time in seconds
+Controls whether the IPA commands dnsrecord\-{add,mod,del} work synchronously or not. The DNS commands will wait up to the specified time until the DNS server returns an up\-to\-date answer to a query for modified records. The DNS commands will return a DNSTimeout exception if the answer doesn't match the expected value after the specified timeout. The DNS queries will be sent to the resolver configured in /etc/resolv.conf on the IPA server. Do not enable this in production! It could cause problems if the resolver on IPA server uses a caching server instead of a local authoritative server. The default is disabled (the option is not present).
+.TP
.B xmlrpc_uri URI
Specifies the URI of the XML\-RPC server for a client. This may be used by IPA, and is used by some external tools, such as ipa\-getcert. Example: https://ipa.example.com/ipa/xml
.TP
diff --git a/ipalib/constants.py b/ipalib/constants.py
index ae0827729764983675d5ae59bbd16bad1c0805ce..d6955f8cb62822d123f6debcefa4a2f35e40aa96 100644
--- a/ipalib/constants.py
+++ b/ipalib/constants.py
@@ -139,6 +139,7 @@ DEFAULT_CONFIG = (
('debug', False),
('startup_traceback', False),
('mode', 'production'),
+('wait_for_dns', False),
# CA plugin:
('ca_host', FQDN), # Set in Env._finalize_core()
diff --git a/ipalib/errors.py b/ipalib/errors.py
index 716decb2b41baf5470a1dc23c0cfb5d1c995e5ff..e6563c0a0ea0f65457b942426e45283dd237ed6e 100644
--- a/ipalib/errors.py
+++ b/ipalib/errors.py
@@ -1512,6 +1512,24 @@ class DatabaseTimeout(DatabaseError):
format = _('LDAP timeout')
+class DNSTimeout(ExecutionError):
+
+**4212** Raised when an DNS query didn't return expected answer
+in expected time period
+
+For example:
+
+ raise DNSTimeout(expected=zone3.test. 86400 IN A 192.0.2.1, \
+ got=zone3.test. 86400 IN A 192.168.1.1)
+Traceback (most recent call last):
+ ...
+DNSTimeout: DNS query timeout: Expected {zone3.test. 86400 IN A 192.0.2.1} got {zone3.test. 86400 IN A 192.168.1.1}
+
+
+errno = 4212
+format = _('DNS query timeout: Expected {%(expected)s} got {%(got)s}')
+
+
class CertificateError(ExecutionError):
**4300** Base class for Certificate execution errors (*4300 - 4399*).
diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py
index e7301a9f78466e9a790d26f03bfab757de501ed6..ee330df93e02e895971b7b1090ea969080e072e4 100644
--- a/ipalib/plugins/dns.py
+++ b/ipalib/plugins/dns.py
@@ -24,6 +24,7 @@ import netaddr
import time
import re
import dns.name
+import dns.resolver
from
Re: [Freeipa-devel] [PATCH] 0468 permission-mod: Do not copy member attributes to new entry
On 19.2.2014 14:45, Petr Viktorin wrote: Hello, This fixes https://fedorahosted.org/freeipa/ticket/4178 Thanks, ACK. -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0153] ipatests: Fix incorrect order of operations when restoring
Hi,
When restoring files from backup, we do use an incorrect order of
operations - we first restore SELinux context and then copy the
files from backup, when we need to do the exact opposite.
https://fedorahosted.org/freeipa/ticket/4133
From 3c1da9e7265bfb303cd4b9751c5b32b04d502431 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Wed, 19 Feb 2014 16:31:12 +0100
Subject: [PATCH] ipatests: Fix incorrect order of operations when restoring
backup
When restoring files from backup, we do use an incorrect order of
operations - we first restore SELinux context and then copy the
files from backup, when we need to do the exact opposite.
https://fedorahosted.org/freeipa/ticket/4133
---
ipatests/test_integration/tasks.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ipatests/test_integration/tasks.py b/ipatests/test_integration/tasks.py
index 9a6ea3fa548a53d6e5ab6d19783227c2d956a001..b785f28190ed39a0ac45ff5b69e3b474e2634278 100644
--- a/ipatests/test_integration/tasks.py
+++ b/ipatests/test_integration/tasks.py
@@ -137,7 +137,7 @@ def restore_files(host):
# Run both commands in one session. For more information, see:
# https://fedorahosted.org/freeipa/ticket/4133
-host.run_command('%s ; (%s ||:)' % (restorecon_command, copyfiles_command))
+host.run_command('%s ; (%s ||:)' % (copyfiles_command, restorecon_command))
# Remove all the files that did not exist and were 'backed up'
host.run_command(['xargs', '-d', r'\n', '-a', rmname, 'rm', '-vf'],
--
1.8.4.2
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] ipactl can not restart ipa services if current status is stopped
Hi,
fixed by starting the directory server in the beginning of restarting if it is
not currently running to enable fetching running services, although former
restart script didn't check that. Also added a check, that if the directory
server started at the beginning, there is no need to restart it.
https://fedorahosted.org/freeipa/ticket/4050
Thanks
Adam
From 5863e7a8e6296dabc5ed0d90f081b836bd37ab85 Mon Sep 17 00:00:00 2001
From: Misnyovszki Adam amisn...@redhat.com
Date: Wed, 19 Feb 2014 16:41:39 +0100
Subject: [PATCH] ipactl can not restart ipa services if current status is
stopped
fixed by starting the directory server when restarting if it is not
currently running to enable fetching running services
later restart didn't check that
also added a check, that if the directory server started at the
beginning, there is no need to restart it
https://fedorahosted.org/freeipa/ticket/4050
---
install/tools/ipactl | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/install/tools/ipactl b/install/tools/ipactl
index df0d6f57e5a862006f7266a04d36ccdb02bc17b7..3f5417464e62ec29e478d0dce981ca55a413b6ba 100755
--- a/install/tools/ipactl
+++ b/install/tools/ipactl
@@ -291,6 +291,15 @@ def ipa_stop(options):
def ipa_restart(options):
dirsrv = ipaservices.knownservices.dirsrv
new_svc_list = []
+dirsrv_restart = True
+if not dirsrv.is_running():
+try:
+print Starting Directory Service
+dirsrv.start(capture_output=get_capture_output('dirsrv', options.debug))
+dirsrv_restart = False
+except Exception, e:
+raise IpactlError(Failed to start Directory Service: + str(e))
+
try:
new_svc_list = get_config(dirsrv)
except Exception, e:
@@ -339,8 +348,9 @@ def ipa_restart(options):
emit_err(Failed to stop %s Service % svc)
try:
-print Restarting Directory Service
-dirsrv.restart(capture_output=get_capture_output('dirsrv', options.debug))
+if dirsrv_restart:
+print Restarting Directory Service
+dirsrv.restart(capture_output=get_capture_output('dirsrv', options.debug))
except Exception, e:
emit_err(Failed to restart Directory Service: + str(e))
emit_err(Shutting down)
--
1.8.5.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0153] ipatests: Fix incorrect order of operations when restoring
On Wed, Feb 19, 2014 at 04:37:05PM +0100, Tomas Babej wrote:
Hi,
When restoring files from backup, we do use an incorrect order of
operations - we first restore SELinux context and then copy the
files from backup, when we need to do the exact opposite.
https://fedorahosted.org/freeipa/ticket/4133
From 3c1da9e7265bfb303cd4b9751c5b32b04d502431 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Wed, 19 Feb 2014 16:31:12 +0100
Subject: [PATCH] ipatests: Fix incorrect order of operations when restoring
backup
When restoring files from backup, we do use an incorrect order of
operations - we first restore SELinux context and then copy the
files from backup, when we need to do the exact opposite.
https://fedorahosted.org/freeipa/ticket/4133
---
ipatests/test_integration/tasks.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ipatests/test_integration/tasks.py
b/ipatests/test_integration/tasks.py
index
9a6ea3fa548a53d6e5ab6d19783227c2d956a001..b785f28190ed39a0ac45ff5b69e3b474e2634278
100644
--- a/ipatests/test_integration/tasks.py
+++ b/ipatests/test_integration/tasks.py
@@ -137,7 +137,7 @@ def restore_files(host):
# Run both commands in one session. For more information, see:
# https://fedorahosted.org/freeipa/ticket/4133
-host.run_command('%s ; (%s ||:)' % (restorecon_command,
copyfiles_command))
+host.run_command('%s ; (%s ||:)' % (copyfiles_command,
restorecon_command))
ACK -- having the files in place is definitely useful if we then want
to find them there.
However: since this is about restoring a backup, can't the backup
contain the extended attributes, so that the SELinux context gets
restored to the original state (which could be different from what
the restorecon will give you)?
--
Jan Pazdziora
Principal Software Engineer, Identity Management Engineering, Red Hat
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0464-0466 Multivalued targetfilter
On 02/19/2014 10:44 AM, Petr Viktorin wrote: On 02/18/2014 08:02 PM, Petr Viktorin wrote: On 02/18/2014 09:42 AM, Martin Kosek wrote: On 02/13/2014 01:12 PM, Petr Viktorin wrote: Hello, These patches fix https://fedorahosted.org/freeipa/ticket/4074 Design: http://www.freeipa.org/page/V3/Multivalued_target_filters_in_permissions Since --type, affects only targetfilter values in the form (objectclass=...) and leaves others alone, and in the -mod command we don't fetch the existing entry until the pre_callback, I had to put the adds/removes in the context. I don't think the approach is too terrible given the limitations. 464: 1) Internal Error: # ipa permission-mod can_write2 --filter='foo=bar' ipa: ERROR: an internal error has occurred Thanks for the catch! Fixed added to tests. 2) ACI target filter I would relabel targetfilter from ACI target filter to Target filter to make it consistent with other ACI attributes. We are sort of hiding there are any underlying ACIs anyway... Fixed. 3) I am now thinking about the behavior of --memberof and --filter options and how they interact. It looks OK except for the case when I set filter to None: The same would happen when setting --filter to any other value(s) that don't include existing memberOf filters. # ipa permission-mod can_write2 --memberof=bar Modified permission can_write2 Permission name: can_write2 Permissions: write Effective attributes: description Bind rule type: permission Subtree: dc=example,dc=com ACI target filter: (foo=bar), (memberOf=cn=bar,cn=groups,cn=accounts,dc=example,dc=com) Member of group: bar # ipa permission-mod can_write2 --filter= Modified permission can_write2 Permission name: can_write2 Permissions: write Effective attributes: description Bind rule type: permission Subtree: dc=example,dc=com Then both memberOf and filter is erased. Are we ok with that? Shouldn't we keep memberOf part until that is set to None? I am not insisting, just trying to discuss the best behavior. Memberof affects the filter; this is even pointed out in --help output. The alternative would be to make --filter= exclude filters affected by other options, which I think would be even more confusing. Keep in mind --type sets (objectclass=...) filters in exactly the same way as --memberof works for (memberof=...). The --memberof, --targetgroup, --type options are just shortcuts for setting other permission attributes. I'm hoping we can get this message across, in --help, and in the docs, well enough to reduce the confusion. 465: I know this was already discussed previously, but I am now having second thoughts - should we use posixAccount as THE objectclass for user targetfilter? # ipa permission-add can_write --permissions write --attrs=description --type=user Added permission can_write Permission name: can_write Permissions: write Effective attributes: description Bind rule type: permission Subtree: cn=users,cn=accounts,dc=example,dc=com ACI target filter: (objectclass=posixaccount) Type: user What if we add system users at some point which would miss the posixaccount objectclass? Wouldn't it be better to use the inetOrgPerson structural objectclass instead of posixAccount? Simo or Ludwig, any opinion on this? I'm not opposed. (I don't think it should block this patchset though. We'll have to add canonical objectclasses to all the types that don't currently have them. Deciding it for `user` can be a part of that effort.) Apologies, I've sent a slightly wrong version of the tests. Here's the fixed patchset. Thanks. New check works fine, but the attribute name in the error message seems inconsistent: # ipa permission-mod can_write --filter=foo=bar ipa: ERROR: invalid 'filter': must be enclosed in parentheses # ipa permission-mod can_write --filter=(foo=bar)) ipa: ERROR: invalid 'ipapermtargetfilter': Bad search filter If you fix that, it's ACK for all. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] ipactl can not restart ipa services if current status is stopped
On 02/19/2014 04:43 PM, Adam Misnyovszki wrote: Hi, fixed by starting the directory server in the beginning of restarting if it is not currently running to enable fetching running services, although former restart script didn't check that. Also added a check, that if the directory server started at the beginning, there is no need to restart it. https://fedorahosted.org/freeipa/ticket/4050 Thanks Adam I think this is fine - works OK. ACK, pushed to master. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0015] Add wait_for_dns option to default.conf
On Wed, 2014-02-19 at 17:10 +0100, Petr Spacek wrote:
On 19.2.2014 15:11, Petr Spacek wrote:
On 18.2.2014 17:34, Nathaniel McCallum wrote:
On Tue, 2014-02-18 at 17:06 +0100, Petr Viktorin wrote:
On 02/18/2014 04:45 PM, Petr Spacek wrote:
Hello,
Add wait_for_dns option to default.conf.
This option makes record changes in DNS tree synchronous.
IPA calls will wait until new data are visible over DNS protocol.
It is intended only for testing - it should prevent tests from
failing if there is bigger delay between change in LDAP and DNS.
I would recommend value like 10 seconds.
Here are a few Python nitpicks you requested.
Thank you very much. This new version solves problems you found + adds
proper
handling for real DNS timeouts.
It seems to me like a more general TimeoutError would be useful in a
broader context. DNSTimeout seems overly narrow to me, unless I'm
missing something.
I would like to keep them separate. DNSTimeout shouldn't be handled at all
because it means that your DNS server or database is dead or broken in some
interesting way.
I assume that generic TimeoutError could be interpreted as 'try it
again'/'failover' or something like that.
Maybe the DNSTimeout is not the best name, I'm open to suggestions.
I have sent the old version with new name, gggrrr.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Tests failed:
test_dns[92]: dnsrecord_add: Add A record to u'ns2' in zone
u'zone3.test' ... ok
File /usr/lib/python2.7/site-packages/nose/case.py, line 197, in
runTest
self.test(*self.arg)
File /root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py, line 291, in
lambda
func = lambda: self.check(nice, **test)
File /root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py, line 309, in
check
self.check_output(nice, cmd, args, options, expected, extra_check)
File /root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py, line 348, in
check_output
got = api.Command[cmd](*args, **options)
File /root/freeipa/ipalib/frontend.py, line 436, in __call__
ret = self.run(*args, **options)
File /root/freeipa/ipalib/frontend.py, line 761, in run
return self.forward(*args, **options)
File /root/freeipa/ipalib/frontend.py, line 782, in forward
return self.Backend.rpcclient.forward(self.name, *args, **kw)
File /root/freeipa/ipalib/rpc.py, line 836, in forward
return self._call_command(command, params)
File /root/freeipa/ipalib/rpc.py, line 813, in _call_command
return command(*params)
File /root/freeipa/ipalib/rpc.py, line 951, in _call
return self.__request(name, args)
File /root/freeipa/ipalib/rpc.py, line 945, in __request
raise error_class(message=error['message'])
DNSTimeout: DNS query timeout: Expected {_kerberos.zone2.test. 86400 IN
TXT IDM.LAB.ENG.BRQ.REDHAT.COM} got {SERVFAIL}
==
ERROR: test_dns[51]: dnsrecord_add: Add NS+DNAME record to u'zone2.test'
zone record using dnsrecord_add
--
Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/nose/case.py, line 197, in
runTest
self.test(*self.arg)
File /root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py, line 291, in
lambda
func = lambda: self.check(nice, **test)
File /root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py, line 309, in
check
self.check_output(nice, cmd, args, options, expected, extra_check)
File /root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py, line 348, in
check_output
got = api.Command[cmd](*args, **options)
File /root/freeipa/ipalib/frontend.py, line 436, in __call__
ret = self.run(*args, **options)
File /root/freeipa/ipalib/frontend.py, line 761, in run
return self.forward(*args, **options)
File /root/freeipa/ipalib/frontend.py, line 782, in forward
return self.Backend.rpcclient.forward(self.name, *args, **kw)
File /root/freeipa/ipalib/rpc.py, line 836, in forward
return self._call_command(command, params)
File /root/freeipa/ipalib/rpc.py, line 813, in _call_command
return command(*params)
File /root/freeipa/ipalib/rpc.py, line 951, in _call
return self.__request(name, args)
File /root/freeipa/ipalib/rpc.py, line 945, in __request
raise error_class(message=error['message'])
DNSTimeout: DNS query timeout: Expected {zone2.test. 86400 IN NS
ns1.dnszone.test.
zone2.test. 86400 IN NS ns1.zone2.test.} got {SERVFAIL}
configuration was: wait_for_dns=10
All tests passed without wait_for_dns option.
Sometimes at first run, I get only error and testing is interrupted.
--
Martin^2 Basti
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH]Add -f option to ipactl
Hi, I reviewed this old patch: If an error occurs in the start up sequence in ipactl start/restart, all the services are stopped. Using the --force/-f option prevents stopping of services that have successfully started. https://fedorahosted.org/freeipa/ticket/3509 Seems like fine to me. Thanks AdamFrom 1893484613cde5c1e3b89cf3b1114ea5561d8f32 Mon Sep 17 00:00:00 2001 From: Ana Krivokapic akriv...@redhat.com Date: Wed, 13 Mar 2013 11:50:24 -0400 Subject: [PATCH] Add --force option to ipactl If an error occurs in the start up sequence in ipactl start/restart, all the services are stopped. Using the --force option prevents stopping of services that have successfully started. https://fedorahosted.org/freeipa/ticket/3509 --- install/tools/ipactl | 87 +++--- install/tools/man/ipactl.8 | 6 2 files changed, 49 insertions(+), 44 deletions(-) diff --git a/install/tools/ipactl b/install/tools/ipactl index 3f5417464e62ec29e478d0dce981ca55a413b6ba..6d58d1f2fd7b3b6e5eccd07033805edba3d5074a 100755 --- a/install/tools/ipactl +++ b/install/tools/ipactl @@ -87,6 +87,8 @@ def parse_options(): parser.add_option(-d, --debug, action=store_true, dest=debug, help=Display debugging information) +parser.add_option(-f, --force, action=store_true, dest=force, + help=If ipactl action fails, do not stop the services that are already running) options, args = parser.parse_args() safe_options = parser.get_safe_opts(options) @@ -189,6 +191,23 @@ def get_config_from_file(): return ordered_list + +def stop_services(svc_list): +for svc in svc_list: +svc_off = ipaservices.service(svc) +try: +svc_off.stop(capture_output=False) +except: +pass + + +def stop_dirsrv(dirsrv): +try: +dirsrv.stop(capture_output=False) +except: +pass + + def ipa_start(options): if os.path.isfile(ipaservices.get_svc_list_file()): @@ -214,10 +233,10 @@ def ipa_start(options): except Exception, e: emit_err(Failed to data from service file: + str(e)) emit_err(Shutting down) -try: -dirsrv.stop(capture_output=False) -except: -pass + +if not options.force: +stop_dirsrv(dirsrv) + if isinstance(e, IpactlError): # do not display any other error message raise IpactlError(rval=e.rval) @@ -236,16 +255,11 @@ def ipa_start(options): except: emit_err(Failed to start %s Service % svc) emit_err(Shutting down) -for svc in svc_list: -svc_off = ipaservices.service(svc) -try: -svc_off.stop(capture_output=False) -except: -pass -try: -dirsrv.stop(capture_output=False) -except: -pass + +if not options.force: +stop_services(svc_list) +stop_dirsrv(dirsrv) + raise IpactlError(Aborting ipactl) def ipa_stop(options): @@ -354,16 +368,11 @@ def ipa_restart(options): except Exception, e: emit_err(Failed to restart Directory Service: + str(e)) emit_err(Shutting down) -for svc in reversed(svc_list): -svc_off = ipaservices.service(svc) -try: -svc_off.stop(capture_output=False) -except: -pass -try: -dirsrv.stop(capture_output=False) -except: -pass + +if not options.force: +stop_services(reversed(svc_list)) +stop_dirsrv(dirsrv) + raise IpactlError(Aborting ipactl) if len(svc_list) != 0: @@ -377,16 +386,11 @@ def ipa_restart(options): except: emit_err(Failed to restart %s Service % svc) emit_err(Shutting down) -for svc in reversed(svc_list): -svc_off = ipaservices.service(svc) -try: -svc_off.stop(capture_output=False) -except: -pass -try: -dirsrv.stop(capture_output=False) -except: -pass + +if not options.force: +stop_services(reversed(svc_list)) +stop_dirsrv(dirsrv) + raise IpactlError(Aborting ipactl) if len(new_svc_list) != 0: @@ -399,16 +403,11 @@ def ipa_restart(options): except: emit_err(Failed to start %s Service % svc) emit_err(Shutting down) -for svc in reversed(svc_list): -svc_off =
[Freeipa-devel] OpenSSH with PKCS#11 for key storage
Hello list, I just came across this page: http://www.gooze.eu/howto/using-openssh-with-smartcards/using-ssh-authentication-agent-ssh-add-with-smartcards If I understand correctly, it allows you to store use your personal SSH keys via PKCS#11 interface. It sounds like a killer feature to me! Imagine that you can log-in to any machine in IPA realm and you will have all your SSH keys with you, without any extra work. This extends seamless SSO outside the enterprise (we have Kerberos for inside, this doesn't change that). Petr^2 Spacek P.S. It is natively supported in OpenSSH v5.4p1 - we have PKCS#11 support in Fedora 20 already. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] OpenSSH with PKCS#11 for key storage
On 02/19/2014 01:49 PM, Petr Spacek wrote: Hello list, I just came across this page: http://www.gooze.eu/howto/using-openssh-with-smartcards/using-ssh-authentication-agent-ssh-add-with-smartcards If I understand correctly, it allows you to store use your personal SSH keys via PKCS#11 interface. It sounds like a killer feature to me! Imagine that you can log-in to any machine in IPA realm and you will have all your SSH keys with you, without any extra work. This extends seamless SSO outside the enterprise (we have Kerberos for inside, this doesn't change that). Petr^2 Spacek P.S. It is natively supported in OpenSSH v5.4p1 - we have PKCS#11 support in Fedora 20 already. What are the implications for SSSD and IPA? What needs to be changed if anything? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- 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] [PATCH]Add -f option to ipactl
On 19.2.2014 21:10, Dmitri Pal wrote: On 02/19/2014 11:58 AM, Adam Misnyovszki wrote: Hi, I reviewed this old patch: If an error occurs in the start up sequence in ipactl start/restart, all the services are stopped. Using the --force/-f option prevents stopping of services that have successfully started. https://fedorahosted.org/freeipa/ticket/3509 I have not read the code but looked at the patch and bug. I do not understand the -force option especially with help string being: If ipactl action fails, do not stop the services that are already running force usually means the reverse: if something did not happen force it to happen. I am not sure that --force option is the right name for the option with this help. I have proposed --no-rollback but it didn't fit to habits in IPA: https://fedorahosted.org/freeipa/ticket/3509#comment:2 -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH]Add -f option to ipactl
On 02/19/2014 11:58 AM, Adam Misnyovszki wrote: Hi, I reviewed this old patch: If an error occurs in the start up sequence in ipactl start/restart, all the services are stopped. Using the --force/-f option prevents stopping of services that have successfully started. https://fedorahosted.org/freeipa/ticket/3509 I have not read the code but looked at the patch and bug. I do not understand the -force option especially with help string being: If ipactl action fails, do not stop the services that are already running force usually means the reverse: if something did not happen force it to happen. I am not sure that --force option is the right name for the option with this help. Seems like fine to me. Thanks Adam ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- 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] OpenSSH with PKCS#11 for key storage
On 19.2.2014 21:13, Dmitri Pal wrote: On 02/19/2014 01:49 PM, Petr Spacek wrote: Hello list, I just came across this page: http://www.gooze.eu/howto/using-openssh-with-smartcards/using-ssh-authentication-agent-ssh-add-with-smartcards If I understand correctly, it allows you to store use your personal SSH keys via PKCS#11 interface. It sounds like a killer feature to me! Imagine that you can log-in to any machine in IPA realm and you will have all your SSH keys with you, without any extra work. This extends seamless SSO outside the enterprise (we have Kerberos for inside, this doesn't change that). Petr^2 Spacek P.S. It is natively supported in OpenSSH v5.4p1 - we have PKCS#11 support in Fedora 20 already. What are the implications for SSSD and IPA? What needs to be changed if anything? First of all, we need the PKCS#11 provider. We plan to write it for DNSSEC and CA rotation anyway, we just need to think about different use case during design phase. The rest should 'just work'. (As usual, nobody knows beforehand where the dead dog is buried :-)) -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] OTP Patches
On Mon, 17 Feb 2014, Alexander Bokovoy wrote:
On Thu, 13 Feb 2014, Alexander Bokovoy wrote:
On Wed, 12 Feb 2014, Nathaniel McCallum wrote:
Through the review process, patches are getting shifted around, added,
deleted, etc. So I'm now just going to be posting all the patches as an
ordered set. The set attached is ordered according to my preferred merge
order. It also places easy to review patches up front. I hope this helps
reviewers. This format will definitely help me manage the patches.
The first three patches should be very easy reviews and can be merged
independently.
All current patch critiques have, to my knowledge, been addressed in
this latest series of patches.
I have tested all the patches altogether, including Web UI patches, and
everything works.
I have set up a COPR repo for others to try:
http://copr.fedoraproject.org/coprs/abbra/freeipa-otp-unstable/
However, there is one issue which I was not yet able to pin-point in the
SLAPI plugins. During FreeIPA install and later on actual use I see
these in the dirsrv error log:
[13/Feb/2014:14:32:52 +0200] - slapi_search_internal_set_pb: NULL parameter
[13/Feb/2014:14:32:52 +0200] - allow_operation: component identity is NULL
[13/Feb/2014:14:32:52 +0200] - slapi_search_internal_set_pb: NULL parameter
[13/Feb/2014:14:32:52 +0200] - allow_operation: component identity is NULL
[13/Feb/2014:14:33:01 +0200] - SLAPI_PLUGIN_BE_TXN_POST_DELETE_FN plugin
returned error code -1
[13/Feb/2014:14:33:11 +0200] - slapi_search_internal_set_pb: NULL parameter
[13/Feb/2014:14:33:11 +0200] - allow_operation: component identity is NULL
[13/Feb/2014:14:45:53 +0200] - slapi_search_internal_set_pb: NULL parameter
[13/Feb/2014:14:45:53 +0200] - allow_operation: component identity is NULL
Additionally, when slapi-nis is enabled, LDAP bind with identity from
compat tree fails for OTP use and succeeds for password authentication.
In compat tree we are doing this trick:
1731 /* Otherwise force rewrite of the
SLAPI_BIND_TARGET_SDN 1732 * and
let other plugins to handle it.
1733 * slapi-nis should have plugin ordering set below standard 50
to succeed */
1734 slapi_pblock_get(pb, SLAPI_BIND_TARGET_SDN, sdn);
1735 if (sdn != NULL) {
1736 slapi_sdn_free(sdn);
1737 }
1738 sdn = slapi_sdn_new_dn_byref(ndn);
1739 slapi_pblock_set(pb, SLAPI_BIND_TARGET_SDN, (void*)sdn);
1740 ret = 0;
1741 }
I tried to play with plugin precedence and it didn't really help.
There is definitely a bug (or more) in ipa-pwd-extop in handling
authentication cases.
Some progress on this investigation.
Plugin precedence setting is broken in 389-ds. It is only set once,
before running init function provided by the plugin and does not take
into account all callbacks that the init function may register. As
result, all these functions get classified with default precedence (50)
and no configuration could change this, we get ipa-pwd-extop's pre-bind
callback called before schemacompat's one, thus working on the compat
entry DN instead of the new one. Since that entry has no userPassword
attribute, OTP code refuses to accept any password.
When user is allowed to use password auth along with OTP, the fact that
there is no userPassword get ipa-pwd-extop plugin through the failure.
schemacompat plugin rewrites the SLAPI_BIND_TARGET_SDN and the rest of
389-ds code checks actual password.
So we have two issues here: OTP code needs to gracefully ignore entries
without userPassword set, and we need to be able to re-arrange
schemacompat and ipa-pwd-extop precedence for pre-bind operation.
I've filed a ticket https://fedorahosted.org/389/ticket/47699 to work on
the latter.
The messages from the log are not yet solved...
Finally, I have a clue after tracing with debug level 1:
[19/Feb/2014:22:57:10 +0200] - Calling plugin 'ipa-otp-lasttoken' #3 type 461
[19/Feb/2014:22:57:10 +0200] - slapi_search_internal_set_pb: NULL parameter
[19/Feb/2014:22:57:10 +0200] - allow_operation: component identity is NULL
[19/Feb/2014:22:57:10 +0200] - Calling plugin 'IPA pwd pre ops betxn' #4 type
461
So I'd say it is somewhere in ipa-otp-lasttoken. I'll dig more.
--
/ Alexander Bokovoy
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] OTP Patches
On Wed, 19 Feb 2014, Alexander Bokovoy wrote:
On Mon, 17 Feb 2014, Alexander Bokovoy wrote:
On Thu, 13 Feb 2014, Alexander Bokovoy wrote:
On Wed, 12 Feb 2014, Nathaniel McCallum wrote:
Through the review process, patches are getting shifted around, added,
deleted, etc. So I'm now just going to be posting all the patches as an
ordered set. The set attached is ordered according to my preferred merge
order. It also places easy to review patches up front. I hope this helps
reviewers. This format will definitely help me manage the patches.
The first three patches should be very easy reviews and can be merged
independently.
All current patch critiques have, to my knowledge, been addressed in
this latest series of patches.
I have tested all the patches altogether, including Web UI patches, and
everything works.
I have set up a COPR repo for others to try:
http://copr.fedoraproject.org/coprs/abbra/freeipa-otp-unstable/
However, there is one issue which I was not yet able to pin-point in the
SLAPI plugins. During FreeIPA install and later on actual use I see
these in the dirsrv error log:
[13/Feb/2014:14:32:52 +0200] - slapi_search_internal_set_pb: NULL parameter
[13/Feb/2014:14:32:52 +0200] - allow_operation: component identity is NULL
[13/Feb/2014:14:32:52 +0200] - slapi_search_internal_set_pb: NULL parameter
[13/Feb/2014:14:32:52 +0200] - allow_operation: component identity is NULL
[13/Feb/2014:14:33:01 +0200] - SLAPI_PLUGIN_BE_TXN_POST_DELETE_FN plugin
returned error code -1
[13/Feb/2014:14:33:11 +0200] - slapi_search_internal_set_pb: NULL parameter
[13/Feb/2014:14:33:11 +0200] - allow_operation: component identity is NULL
[13/Feb/2014:14:45:53 +0200] - slapi_search_internal_set_pb: NULL parameter
[13/Feb/2014:14:45:53 +0200] - allow_operation: component identity is NULL
Additionally, when slapi-nis is enabled, LDAP bind with identity from
compat tree fails for OTP use and succeeds for password authentication.
In compat tree we are doing this trick:
1731 /* Otherwise force rewrite of the
SLAPI_BIND_TARGET_SDN 1732 * and
let other plugins to handle it.
1733 * slapi-nis should have plugin ordering set below standard 50
to succeed */
1734 slapi_pblock_get(pb, SLAPI_BIND_TARGET_SDN, sdn);
1735 if (sdn != NULL) {
1736 slapi_sdn_free(sdn);
1737 }
1738 sdn = slapi_sdn_new_dn_byref(ndn);
1739 slapi_pblock_set(pb, SLAPI_BIND_TARGET_SDN, (void*)sdn);
1740 ret = 0;
1741 }
I tried to play with plugin precedence and it didn't really help.
There is definitely a bug (or more) in ipa-pwd-extop in handling
authentication cases.
Some progress on this investigation.
Plugin precedence setting is broken in 389-ds. It is only set once,
before running init function provided by the plugin and does not take
into account all callbacks that the init function may register. As
result, all these functions get classified with default precedence (50)
and no configuration could change this, we get ipa-pwd-extop's pre-bind
callback called before schemacompat's one, thus working on the compat
entry DN instead of the new one. Since that entry has no userPassword
attribute, OTP code refuses to accept any password.
When user is allowed to use password auth along with OTP, the fact that
there is no userPassword get ipa-pwd-extop plugin through the failure.
schemacompat plugin rewrites the SLAPI_BIND_TARGET_SDN and the rest of
389-ds code checks actual password.
So we have two issues here: OTP code needs to gracefully ignore entries
without userPassword set, and we need to be able to re-arrange
schemacompat and ipa-pwd-extop precedence for pre-bind operation.
I've filed a ticket https://fedorahosted.org/389/ticket/47699 to work on
the latter.
The messages from the log are not yet solved...
Finally, I have a clue after tracing with debug level 1:
[19/Feb/2014:22:57:10 +0200] - Calling plugin 'ipa-otp-lasttoken' #3 type 461
[19/Feb/2014:22:57:10 +0200] - slapi_search_internal_set_pb: NULL parameter
[19/Feb/2014:22:57:10 +0200] - allow_operation: component identity is NULL
[19/Feb/2014:22:57:10 +0200] - Calling plugin 'IPA pwd pre ops betxn' #4 type
461
So I'd say it is somewhere in ipa-otp-lasttoken. I'll dig more.
There is an error in libotp's find() function which assumes that
get_basedn() always returns non-NULL value. This is not true for at
least cn=Directory Manager.
Patch attached.
--
/ Alexander Bokovoy
From c91c69fb05f5411ce2a583fc4678ce10cb31e894 Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy aboko...@redhat.com
Date: Wed, 19 Feb 2014 23:24:29 +0200
Subject: [PATCH 16/16] libotp: do not call internal search for NULL dn
---
daemons/ipa-slapi-plugins/libotp/libotp.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/daemons/ipa-slapi-plugins/libotp/libotp.c
b/daemons/ipa-slapi-plugins/libotp/libotp.c
index 31cc591..e7119f0 100644
---
Re: [Freeipa-devel] [PATCH]Add -f option to ipactl
On 02/19/2014 03:13 PM, Petr Spacek wrote: On 19.2.2014 21:10, Dmitri Pal wrote: On 02/19/2014 11:58 AM, Adam Misnyovszki wrote: Hi, I reviewed this old patch: If an error occurs in the start up sequence in ipactl start/restart, all the services are stopped. Using the --force/-f option prevents stopping of services that have successfully started. https://fedorahosted.org/freeipa/ticket/3509 I have not read the code but looked at the patch and bug. I do not understand the -force option especially with help string being: If ipactl action fails, do not stop the services that are already running force usually means the reverse: if something did not happen force it to happen. I am not sure that --force option is the right name for the option with this help. I have proposed --no-rollback but it didn't fit to habits in IPA: https://fedorahosted.org/freeipa/ticket/3509#comment:2 then it should be -fs/--force-start or something of this kind. -- 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] OpenSSH with PKCS#11 for key storage
On 02/19/2014 03:30 PM, Petr Spacek wrote: On 19.2.2014 21:13, Dmitri Pal wrote: On 02/19/2014 01:49 PM, Petr Spacek wrote: Hello list, I just came across this page: http://www.gooze.eu/howto/using-openssh-with-smartcards/using-ssh-authentication-agent-ssh-add-with-smartcards If I understand correctly, it allows you to store use your personal SSH keys via PKCS#11 interface. It sounds like a killer feature to me! Imagine that you can log-in to any machine in IPA realm and you will have all your SSH keys with you, without any extra work. This extends seamless SSO outside the enterprise (we have Kerberos for inside, this doesn't change that). Petr^2 Spacek P.S. It is natively supported in OpenSSH v5.4p1 - we have PKCS#11 support in Fedora 20 already. What are the implications for SSSD and IPA? What needs to be changed if anything? First of all, we need the PKCS#11 provider. We plan to write it for DNSSEC and CA rotation anyway, we just need to think about different use case during design phase. The rest should 'just work'. (As usual, nobody knows beforehand where the dead dog is buried :-)) Provider? You mean SSSD exposing data as a PKCS#11 provider? I understand it in the case when data comes from central server and needs to be passed to consumers via PKCS#11 interface but in this case data comes from a user and actually should not come from SSSD but rather a real smart card inserted by user. What am I missing? -- 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
