Re: [Freeipa-devel] [PATCH] 436 make service/chkconfig more fault tolerant
On Thu, 2010-05-06 at 15:39 -0400, Rob Crittenden wrote: > If we try to use service/chkconfig in the client installer on a service > that doesn't exist then it would throw lots of bogus errors. This is an > attempt to be a little smarter about it. > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 437 detect client installation
On Thu, 2010-05-06 at 16:51 -0400, Rob Crittenden wrote: > Detect if the IPA client is already configured and bail if it is. This > should help prevent problems, particularly with certmonger. It will > refuse to generate a new CSR for a certificate it is already tracking > (and this is a good thing). So if you configure the client, then > configure the client again bad things could happen, don't allow it. > > If things every got out-of-sync a user could always remove > /var/lib/ipa-client/sysrestore/* to be able to install again. > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 435 more client install/uninstall fixes
On Wed, 2010-05-05 at 14:57 -0400, Rob Crittenden wrote: > Lots of small fixes in the client installer/uninstaller to make it work > nicer (or at all): > > - Move the ipa-getcert request to after we set up /etc/krb5.conf > - Don't try removing certificates that don't exist > - Don't tell certmonger to stop tracking a cert that doesn't exist > - Allow --password/-w to be the kerberos password > - Print an error if prompting for a password would happen in unattended mode > - Still support echoing a password in when in unattended mode > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 434 fix ipa-join segfault
On Wed, 2010-05-05 at 11:14 -0400, Rob Crittenden wrote: > I set MALLOC_PERTURB_ and ipa-join generated a segfault. This was caused > by some uninitialized XML-RPC structures. This patch should fix it up. > > I also re-arrange some code around determining the server. I got a bit > overzealous in my previous attempt to not spew bogus error messages when > we don't need to read /etc/ipa/default.conf. > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 431 better CSR header handling
On Mon, 2010-05-03 at 17:41 -0400, Rob Crittenden wrote: > Properly handle CSRs whether they have NEW in the header block or not. > The code was looking for headers without NEW in it but in that case > would cut the first 4 characters of the request off, causing decoding to > fail. > > I also consolidate some duplicate code. > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 430 AccessTime tests
On Fri, 2010-04-30 at 12:04 -0400, Rob Crittenden wrote: > I added some tests for the AccessTime parameter type. During test > development I fixed a few bugs in the parameter and hopefully added some > improved error messages to nudge the user in the right direction. The > time syntax is quite difficult to understand. > > I noticed that the 'weekly' periodic type wasn't implemented. I'm not > sure if this was an oversight or not. > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 429 enhance installer/uninstaller
On Thu, 2010-04-29 at 17:38 -0400, Rob Crittenden wrote: > We have had a state file for quite some time that is used to return the > system to its pre-install state. We can use that to determine what has > been configured. > > This patch: > - uses the state file to determine if dogtag was installed > - prevents someone from trying to re-install an installed server > - displays some output when uninstalling > - re-arranges the ipa_kpasswd installation so the state is properly saved > - removes pkiuser if it was added by the installer > - fetches and installs the CA on both masters and clients > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 428 set socket reuse
On Thu, 2010-04-29 at 17:38 -0400, Rob Crittenden wrote: > Set SO_REUSEADDR when determining socket availability > > The old perl DS code for detection didn't set this so was often confused > about port availability. We had to match their behavior so the > installation didn't blow up. They fixed this a while ago, this catches > us up. > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 426 fix output
On Mon, 2010-04-26 at 17:43 -0400, Rob Crittenden wrote: > Summaries were printing as "Gettext(...)". > > Embedded dictionaries were just a dump because we weren't passing in the > list of labels. > > Now things like -add-member looks right again. > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 425 client installer fixes
On Mon, 2010-04-26 at 15:53 -0400, Rob Crittenden wrote: > This addresses a couple of minor client issues I discovered: > > - Don't run nscd with sssd. nscd conflicts with the sssd caching > - Set the minimum version of sssd to 1.1.1 to pick up a needed hbac fix. > I did some basic hbac testing and it seems to work ok. > - Don't try to read the IPA configuration if the server is passed on the > command-line. Chances are this file doesn't exist so an error will be > displayed. So no need to confuse things if we already have the data we > need to enroll. > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 422 reorder some things in client installer
On Fri, 2010-04-16 at 17:39 -0400, Rob Crittenden wrote: > Reorder some things in the client installer > > - Fetch the CA cert before running certmonger > - Delete entries from the keytab before removing /etc/krb5.conf > - Add and remove the IPA CA to /etc/pki/nssdb > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 420 use proper subject when requesting certs using certmonger
On Mon, 2010-04-05 at 16:51 -0400, Rob Crittenden wrote: > When using the dogtag CA we can control what the subject of an issued > certificate is regardless of what is in the CSR, we just use the CN > value. The selfsign CA does not have this capability. The subject format > must match the configured format or certificate requests are rejected. > > The default format is CN=%s,O=IPA. certmonger by default issues requests > with just CN so all requests would fail if using the selfsign CA. > > This subject base is stored in cn=ipaconfig so we can just fetch that > value in the enrollment process and pass it to certmonger to request the > right thing. > > Note that this also fixes ipa-join to work with the new argument passing > mechanism. > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 419 fix external CA installation
On Thu, 2010-04-01 at 17:25 -0400, Rob Crittenden wrote: > I guess I did all my testing by passing in all arguments on the > command-line. We weren't caching them properly. > > Also fix handling of cached boolean values and require an absolute path > on the CA and certificate files passed in. > > I updated the documentation on doing an install wiht an > externally-signed CA at http://freeipa.org/page/Certificate_Authority > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 413 fix ca location
On Tue, 2010-03-30 at 15:44 -0400, Rob Crittenden wrote: > For consistency I had changed ca.p12 to cacert.p12 in a few places. I > missed two in ipa-replica-install. > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] jderose 053 XML-RPC signature change
On Fri, 2010-03-26 at 09:22 -0400, John Dennis wrote: > On 03/26/2010 07:24 AM, Jason Gerard DeRose wrote: > > This quick patch changes the XML-RPC signature to match the > > complementary change being made in certmonger. > > > > The signature is now: > > > > [args, options] > > > > This doesn't yet include the [args, options, extra] change... that is > > coming in my rpcserver patch once it's done. But this provides what > > needed for current IPA<=> certmonger compatibility. > > NAK > > Is there a reason for the type inconsistency? Why is it a list in one > case and a tuple in the other? I realize they'll both operate the same > way but the inconsistency is confusing especially if there is no reason > to use different type objects (e.g. no need for a mutable sequence). We use lists and tuples interchangeability. Tuple are nice because they aren't mutable and are a bit more efficient in terms of memory use, but both json.loads() and xmlrpclib.loads() return lists. My general plan has been to move to using just lists. json.dumps() and xmlrpclib.dumps() also treat tuples and lists the same... both are serialized to a list type. So there's no type change of any consequence in this patch. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] jderose 053 XML-RPC signature change
This quick patch changes the XML-RPC signature to match the
complementary change being made in certmonger.
The signature is now:
[args, options]
This doesn't yet include the [args, options, extra] change... that is
coming in my rpcserver patch once it's done. But this provides what
needed for current IPA <=> certmonger compatibility.
>From b802442d7a62ac6f9a87a87bd6ed58623cbb2f09 Mon Sep 17 00:00:00 2001
From: Jason Gerard DeRose
Date: Fri, 26 Mar 2010 03:56:53 -0600
Subject: [PATCH] XML-RPC signature change
---
ipalib/rpc.py |2 +-
ipaserver/rpcserver.py |7 +++
tests/test_ipalib/test_rpc.py |2 +-
tests/test_ipaserver/test_rpcserver.py |6 ++
4 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/ipalib/rpc.py b/ipalib/rpc.py
index 62f1d77..e7f3338 100644
--- a/ipalib/rpc.py
+++ b/ipalib/rpc.py
@@ -401,7 +401,7 @@ class xmlclient(Connectible):
)
self.info('Forwarding %r to server %r', name, self.env.xmlrpc_uri)
command = getattr(self.conn, name)
-params = args + (kw,)
+params = [args, kw]
try:
response = command(*xml_wrap(params))
return xml_unwrap(response)
diff --git a/ipaserver/rpcserver.py b/ipaserver/rpcserver.py
index 967ee33..657f5fb 100644
--- a/ipaserver/rpcserver.py
+++ b/ipaserver/rpcserver.py
@@ -72,12 +72,11 @@ def read_input(environ):
def params_2_args_options(params):
-assert type(params) is tuple
if len(params) == 0:
return (tuple(), dict())
-if type(params[-1]) is dict:
-return (params[:-1], params[-1])
-return (params, dict())
+if len(params) == 1:
+return (params[0], dict())
+return (params[0], params[1])
def nicify_query(query, encoding='utf-8'):
diff --git a/tests/test_ipalib/test_rpc.py b/tests/test_ipalib/test_rpc.py
index 83092b5..a87b65a 100644
--- a/tests/test_ipalib/test_rpc.py
+++ b/tests/test_ipalib/test_rpc.py
@@ -204,7 +204,7 @@ class test_xmlclient(PluginTester):
(o, api, home) = self.instance('Backend', user_add, in_server=False)
args = (binary_bytes, utf8_bytes, unicode_str)
kw = dict(one=binary_bytes, two=utf8_bytes, three=unicode_str)
-params = args + (kw,)
+params = [args, kw]
result = (unicode_str, binary_bytes, utf8_bytes)
conn = DummyClass(
(
diff --git a/tests/test_ipaserver/test_rpcserver.py b/tests/test_ipaserver/test_rpcserver.py
index 294d349..2f52662 100644
--- a/tests/test_ipaserver/test_rpcserver.py
+++ b/tests/test_ipaserver/test_rpcserver.py
@@ -79,10 +79,8 @@ def test_params_2_args_options():
args = ('Hello', u'world!')
options = dict(one=1, two=u'Two', three='Three')
assert f(tuple()) == (tuple(), dict())
-assert f(args) == (args, dict())
-assert f((options,)) == (tuple(), options)
-assert f(args + (options,)) == (args, options)
-assert f((options,) + args) == ((options,) + args, dict())
+assert f([args]) == (args, dict())
+assert f([args, options]) == (args, options)
class test_session(object):
--
1.7.0
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 397 raise exception on empty mod
On Fri, 2010-03-19 at 09:48 -0400, Rob Crittenden wrote: > Jason Gerard DeRose wrote: > > On Fri, 2010-03-05 at 13:47 -0500, Rob Crittenden wrote: > >> Raise an error if no modifications were performed in an update. > >> > >> This will alert the user that nothing was done and is handy when used > >> with --attr=''. This can be used to delete a non-required attribute but > >> can be set to any valid attribute, present or not. We should alert the > >> user if they attempt to delete a non-existant value. > >> > >> rob > > > > Tiny conflict, but I'm not going to guess. :) Can you rebase this? > > > > error: patch failed: ipalib/plugins/baseldap.py:272 > > > > > > Re-based patch attached. > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 407 make ipautil.run() logging more flexible
On Mon, 2010-03-15 at 17:08 -0400, Rob Crittenden wrote: > Provide mechanism in ipautil.run() to not log all arguments. > > This is primarily designed to not log passwords but it could have other > uses. > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 406 add option for pam_mkhomedirs to client installer
On Mon, 2010-03-15 at 13:42 -0400, Rob Crittenden wrote: > Add a new option, --mkhomedirs, to the ipa-client-install script. We > pass this along to authconfig so that pam_mkhomedirs is configured. > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 405 Fix the client make target
On Mon, 2010-03-15 at 13:41 -0400, Rob Crittenden wrote: > Fix the client make target. It was broken due to the addition of the > i18n code which lives inside the server code. > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 404 ensure priority is unique
On Fri, 2010-03-12 at 18:01 -0500, Rob Crittenden wrote: > Ensure that the group policy priority is unique. > > We use CoS to determine the order in which group policy is applied. The > behavior in CoS is undefined for multiple entries with the same > cospriority. > > This likely relies on some other outstanding pwpolicy patches. > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 399 Include params in Method.output_params
On Tue, 2010-03-09 at 16:50 -0500, Rob Crittenden wrote: > Pavel Zuna wrote: > > Rob Crittenden wrote: > >> Method overrides the Command get_output_params() method and only > >> returns the object params, not anything defined within the method > >> itself. Return > >> those as well so they are displayed in output. Some care needs to be > >> taken to avoid returning duplicate values. In the case of duplicates > >> the value in obj.params wins. > >> > >> I tested this with the pwpolicy plugin which is a Method and defines > >> its own takes_options. I need this to display the priority to the user. > >> > >> rob > >> > > Applies with minor modifications due to recent gettext patches. > > Shouldn't there be a check for 'no_output' when going through > > self.obj.params? > > > > Pavel > > Yup, new patch attached, good catch. > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 400 fix pwpolicy plugin
On Fri, 2010-03-05 at 16:15 -0500, Rob Crittenden wrote: > This patch relies on patch #399 > > Fix a number of bugs in the pwpolicy plugin > > This fixes: > - Consistent usage of priority vs cospriority in options > - Fixes bug introduced with recent patch where global policy couldn't be > updated > - Doesn't allow cospriority to be removed for groups (#570536) > - returns the priority with group policy so it can be displayed > - Properly unicode encode group names for display > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 402 location of root CA
On Wed, 2010-03-10 at 11:59 -0500, Rob Crittenden wrote: > Make CA PKCS#12 location arg for ipa-replica-prepare, default > /root/cacert.p12 > > pki-silent puts a copy of the root CA into /root/tmp-ca.p12. Rename this > to /root/cacert.p12. > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 401 fix ipa-server-certinstall
On Wed, 2010-03-10 at 11:17 -0500, Rob Crittenden wrote: > This command was broken because the api needed to be bootstrapped. I > also switched to a new function in certs that makes it easier to trust > all CAs found in a PKCS#12 file. > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 403 correct installation CA output
On Wed, 2010-03-10 at 12:00 -0500, Rob Crittenden wrote: > Better customize the message regarding the CA based on the install options. > > There are now 3 cases: > > - Install a dogtag CA and issue server certs using that > - Install a selfsign CA and issue server certs using that > - Install using either dogtag or selfsign and use the provided PKCS#12 > files for the server certs. The installed CA will still be used by the > cert plugin to issue any server certs. > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 397 raise exception on empty mod
On Fri, 2010-03-05 at 13:47 -0500, Rob Crittenden wrote: > Raise an error if no modifications were performed in an update. > > This will alert the user that nothing was done and is handy when used > with --attr=''. This can be used to delete a non-required attribute but > can be set to any valid attribute, present or not. We should alert the > user if they attempt to delete a non-existant value. > > rob Tiny conflict, but I'm not going to guess. :) Can you rebase this? error: patch failed: ipalib/plugins/baseldap.py:272 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 394 Catch empty updates
On Mon, 2010-03-08 at 09:27 -0500, Rob Crittenden wrote: > Martin Nagy wrote: > > On 03/04/2010 10:25 PM, Rob Crittenden wrote: > >> Currently if you pass in an empty update on the cli it won't throw an > >> error and can be a bit confusing. > >> > >> rob > > > > I think the change in pwpolicy.py won't preserve the original behaviour: > > +if 'group' in options: > > +group_cn = options['group'] > > +del options['group'] > > +else: > > group_cn = _global > > + > > +if not 'group' in options: > > ... > > else: > > ... > > > > Notice that at the second if, 'group' will never be in options no matter > > what. > > > > Martin > > Yes, I discovered this too. It is fixed in my patch "400 fix pwpolicy > plugin" along with a few other things. > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 392 retrieve schema using kerberos credentials
On Wed, 2010-03-17 at 10:02 -0400, Rob Crittenden wrote: > Jason Gerard DeRose wrote: > > On Fri, 2010-02-26 at 11:26 -0500, Rob Crittenden wrote: > >> Retrieve the LDAP schema using kerberos credentials. > >> > >> This is required so we can disable anonymous access in 389-ds. > >> > >> rob > > > > I'm getting a merge conflict with the migration plugin: > > > > error: patch failed: ipalib/plugins/migration.py:30 > > > > Sorry this patch slipped through the cracks for so long. > > > > Updated patch attached. thanks. ack, pushed to master. > rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 392 retrieve schema using kerberos credentials
On Fri, 2010-02-26 at 11:26 -0500, Rob Crittenden wrote: > Retrieve the LDAP schema using kerberos credentials. > > This is required so we can disable anonymous access in 389-ds. > > rob I'm getting a merge conflict with the migration plugin: error: patch failed: ipalib/plugins/migration.py:30 Sorry this patch slipped through the cracks for so long. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 372 check for group but no user
On Tue, 2010-03-16 at 17:57 -0400, Rob Crittenden wrote: > Handle the case where the DS group exists but the user does not > > If the group exists but the user doesn't then useradd blows up > trying to create the user and group. So test to see if the group > exists and if it does pass along the -g argument to useradd. > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 369 fix word usage in installer
On Wed, 2010-02-03 at 14:57 -0500, Rob Crittenden wrote: > Proper use of "set up" vs "setup". > > rob > ___ > Freeipa-devel mailing list > Freeipa-devel@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] jderose 052 Finish deferred translation mechanism
On Fri, 2010-03-12 at 11:31 -0500, John Dennis wrote:
> On 03/08/2010 11:25 PM, Jason Gerard DeRose wrote:
> > This patch finishes the the LazyText functionality in the ipalib.text
> > module. This patch includes extensive docstrings in text.py that should
> > hopefully explain everything pretty well. There's also now pretty darn
> > complete test coverage. Still to do:
> >
> >1. Have Backend.session extract the locale and set
> > context.languages... I have an rpcserver cleanup patch I've been
> > working on which will include this change.
> >
> >2. Remove deprecated gettext stuff in ipalib.request... this is a
> > small change, but I left it out of this patch so it's easier to
> > review
> >
> > I'll have these next two patches later this week.
>
> I've tested this and it works for me and seems pretty clean, a good
> patch. Thank you Jason. However I do have one thing which I'd like to
> see cleaned up, it's a few naming issues (see below).
Well, naming issues aside, is this an ack? Do you mind if I push this
patch and then possibly push a tune-up patch?
> In a moment I'm going to follow up with a patch that extends
> tests/test_ipalib/test_text.py to utilize the test language you asked
> for and is currently in install/po. That test is implemented and working
> so look for the patch in a moment.
>
> Naming Issues:
>
> The thread local object can be assigned attributes directly and it's
> attributes can be referenced directly. Using context.__dict__ seems odd
Although it isn't usually standard to use an instance dictionary like
this, the Python threading.local documentation specifically endorses it.
After reading the docstring in /usr/lib64/python2.6/_threading_local.py,
my impression is that threading.local is indented to be used both as an
instance to store thread-local attributes, and as a dict to store
thread-local items (regardless of whether the keys are valid attribute
names).
John, could you take a look at this documentation and let me know if you
concur?
> and unnecessary to store the language keys. I presume you're doing that
> because you can't have a tuple as an attribute name on the context.
> Directly accessing the __dict__ of an object feels like something we
> should avoid if possible. Also we're stuffing unrelated items in
> context.__dict__, for example the Connection and language keys are being
> stored together. Wouldn't be cleaner to keep the language keys in their
> own "name space" and to use constructs like this:
>
> context = threading.local()
> context.connection = Connection()
> context.language_keys = {}
> context.language_keys[key] = translation
> if key in context.language_keys
As you have it above, context.language_keys only exists in the current
thread. So each time we would have to check if the language_keys dict
has been created in the current thread, then check if the key is
present.
If you want these separated, I personally think a second threading.local
instance should be used, something like:
language_keys = threading.local()
I actually had them separated like this initially but decided to combine
them so there is only one threading.local instance we need to clear()
after processing a request.
Also, though it seems messy to combine all of these in the context, the
name-spaces don't overlap... a tuple will never equal an attribute name
(str), so the translations can't conflict with any attributes we store
on the context.
> rather than
>
> context.__dict__[key] = translation
> if key in context.__dict__
>
> This also means when you clear the context you don't have to iterate
> over the members of context.__dict__ and special case the values as is
> currently being done with:
>
> for (name, value) in context.__dict__.items():
> if isinstance(value, Connection):
> value.disconnect()
>
> Wouldn't this be cleaner as:
>
> if context.connection:
> context.connection.disconnect()
We can have multiple connections, which is why we do this iteration with
type checking. An LDAP connection is always created, but other
connections might also be created. Currently the only place we are
doing this is for a connection to the certificate server, but we should
allow plugins to create additional connections, and have them explicitly
disconnected by request.destroy_context().
> Keeping the language keys separately would also allow us to clear the
> language keys independently of anything else in the context without
> having to worry about what else we might clobber in the context.
I have no problem using a separate threading.local() instance for the
translations if you feel that is the better approach. Small change.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] jderose 052 Finish deferred translation mechanism
This patch finishes the the LazyText functionality in the ipalib.text
module. This patch includes extensive docstrings in text.py that should
hopefully explain everything pretty well. There's also now pretty darn
complete test coverage. Still to do:
1. Have Backend.session extract the locale and set
context.languages... I have an rpcserver cleanup patch I've been
working on which will include this change.
2. Remove deprecated gettext stuff in ipalib.request... this is a
small change, but I left it out of this patch so it's easier to
review
I'll have these next two patches later this week.
>From 1b86cff2e402393c0ea8fdb472bb9cc665d2cda7 Mon Sep 17 00:00:00 2001
From: Jason Gerard DeRose
Date: Mon, 8 Mar 2010 20:42:26 -0700
Subject: [PATCH] Finish deferred translation mechanism
---
ipalib/__init__.py |2 +-
ipalib/parameters.py |6 +-
ipalib/request.py |5 +-
ipalib/text.py | 447 ++--
tests/test_ipalib/test_text.py | 135 +++-
tests/util.py |6 +-
6 files changed, 560 insertions(+), 41 deletions(-)
diff --git a/ipalib/__init__.py b/ipalib/__init__.py
index 51b63c9..6545bf7 100644
--- a/ipalib/__init__.py
+++ b/ipalib/__init__.py
@@ -881,7 +881,7 @@ from crud import Create, Retrieve, Update, Delete, Search
from parameters import DefaultFrom, Bool, Flag, Int, Float, Bytes, Str, Password,List
from parameters import BytesEnum, StrEnum, AccessTime, File
from errors import SkipPluginModule
-from text import _, gettext, ngettext
+from text import _, ngettext, GettextFactory, NGettextFactory
# We can't import the python uuid since it includes ctypes which makes
# httpd throw up when run in in mod_python due to SELinux issues
diff --git a/ipalib/parameters.py b/ipalib/parameters.py
index a598690..606a574 100644
--- a/ipalib/parameters.py
+++ b/ipalib/parameters.py
@@ -73,14 +73,14 @@ web-UI. The *label* should start with an initial capital. For example:
... label=_('Last name'),
... )
>>> sn.label
-Gettext('Last name')
+Gettext('Last name', domain='ipa', localedir=None)
The *doc* is a longer description of the parameter. It's used on the CLI when
displaying the help information for a command, and as extra instruction for a
form input on the web-UI. By default the *doc* is the same as the *label*:
>>> sn.doc
-Gettext('Last name')
+Gettext('Last name', domain='ipa', localedir=None)
But you can override this with the *doc* kwarg. Like the *label*, the *doc*
should also start with an initial capital and should not end with any
@@ -92,7 +92,7 @@ punctuation. For example:
... doc=_("The user's last name"),
... )
>>> sn.doc
-Gettext("The user's last name")
+Gettext("The user's last name", domain='ipa', localedir=None)
Demonstration aside, you should always provide at least the *label* so the
various UIs are translatable. Only provide the *doc* if the parameter needs
diff --git a/ipalib/request.py b/ipalib/request.py
index f21ac03..86b6433 100644
--- a/ipalib/request.py
+++ b/ipalib/request.py
@@ -52,10 +52,11 @@ def destroy_context():
"""
Delete all attributes on thread-local `request.context`.
"""
-# need to use .items(), 'cos value.disconnect modifies the dict
-for (name, value) in context.__dict__.items():
+# need to use .values(), 'cos value.disconnect modifies the dict
+for value in context.__dict__.values():
if isinstance(value, Connection):
value.disconnect()
+context.__dict__.clear()
def ugettext(message):
diff --git a/ipalib/text.py b/ipalib/text.py
index cabca43..96770ad 100644
--- a/ipalib/text.py
+++ b/ipalib/text.py
@@ -18,73 +18,480 @@
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
"""
-Thread-local lazy gettext service.
+Defers gettext translation till request time.
-TODO: This aren't hooked up into gettext yet, they currently just provide
-placeholders for the rest of the code.
+IPA presents some tricky gettext challenges. On the one hand, most translatable
+message are defined as class attributes on the plugins, which means these get
+evaluated at module-load time. But on the other hand, each request to the
+server can be in a different locale, so the actual translation must not occur
+till request time.
+
+The `text` module provides a mechanism for for deferred gettext translation. It
+was designed to:
+
+1. Allow translatable strings to be marked with the usual ``_()`` and
+ ``ngettext()`` functions so that standard tools like xgettext can still
+ be used
+
+2. Allow programmers to mark strings in a natural way without burdening t
Re: [Freeipa-devel] [PATCH 5/5] localize doc strings
On Fri, 2010-03-05 at 16:21 -0500, John Dennis wrote: > A number of doc strings were not localized, wrap them in _(). > Some messages were not localized, wrap them in _() > > Fix a couple of failing tests: > The method name in RPC should not be unicode. > The doc attribute must use the .msg attribute for comparison. > > Also clean up imports of _() The import should come from > ipalib or ipalib.text, not ugettext from request. > > Pavel: You'll need to make a fix to plugins/migration.py, look for the > FIXME comment. What you're doing with the doc string won't work with our > localization framework. I implemented a workaround for the time being. ack. pushed to master. John, for me your 'the_method' change broke the test, which was previously working. I pushed this anyway as this patch touches a lot of files and I don't want us to get into merge hell. We can fix this small issue in a separate patch. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] jderose 050 Run ipaserver under mod_wsgi
On Mon, 2010-03-01 at 14:56 -0500, Rob Crittenden wrote:
> Jason Gerard DeRose wrote:
> > This patch completes the transition to running under mod_wsgi. It
> > requires my previous "049 Consolidate to single WSGI entry point" patch.
> >
> > This is pretty strait forward, but a few things need highlighting:
> >
> > 1. mod_wsgi requires an entry point script (you can't give it a Python
> > package name like we were doing with mod_python). Based on my reading
> > of the Filesystem Hierarchy Standard, it seems this should be in
> > share/ipa, so that's what I did. The script is /usr/share/ipa/wsgi.py
> > I was expecting this to cause SELinux problems, but things seem to work
> > fine.
> >
> > 2. We are running mod_wsgi in daemon mode, which is the preferred way of
> > deploying it. The mod_wsgi daemon has both multi-process and
> > multi-threading capabilities. As we haven't actually used threaded code
> > much in IPA thus far (although lite-server.py is threaded), for now I
> > have the daemon running 2 processes and 1 thread (aka it's not
> > threaded). For production I think we probably should run something like
> > 4 processes and 8 threads per process. This can be a later change (just
> > requires a change in our ipa.conf Apache config file).
> >
> > 3. As ipaserver is now running inside the mod_wsgi daemon, we can
> > changed from using the Apache "prefork" MPM to using "worker", which is
> > far superior for static content. I haven't changed this yet, but we
> > should put this on our TODO.
> >
> > I pretty much had this patch all done last Friday, but I've let things
> > slow-roast for several days to make sure it's stable. I feel confident
> > that this is a low risk change. All the same, I think we should get
> > this pushed as soon as possible so we can shake out any remaining
> > issues.
> >
>
> I'm going to go ahead and ack this if you fix one thing before you push.
>
> In ipa.spec.in you need to change:
> -%{_usr}/share/ipa/wsgi.py
> +%{_usr}/share/ipa/wsgi.py*
pushed to master, along with my 051 patch making the changes you asked
for.
> I don't think we need the Location entries at the top of ipa.conf
> setting no handler. It worked ok for me without them, the similar
> setting in the Directory should take care of things. More testing is
> probably needed.
In my testing, the Location tag with "Handler none" was the only way I
could prevent the WSGI handler from gobbling up these URIs. I think
this is because of the order in which Directory and Location are
applied.
> This doesn't work on my F-11 box, I think primarily because
> /var/run/httpd/ has the wrong permissions. I'll investigate fixing this
> up but since F-11 won't be supported for a whole lot longer I'm not
> going to worry about this too much. I'll fix this in a follow-up patch.
>
> rob
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 051 Fix spec
This has already been pushed to master. This is a follow up to Rob's
conditional ack of my 050 patch.
>From 3b4c4acfd24fcfd1d4b34a355a684f0683edee38 Mon Sep 17 00:00:00 2001
From: Jason Gerard DeRose
Date: Mon, 1 Mar 2010 21:41:41 -0700
Subject: [PATCH] Fixed ipa.spec.in to include share/ipa/wsgi.py*
---
ipa.spec.in |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/ipa.spec.in b/ipa.spec.in
index f7f3a29..154bac6 100644
--- a/ipa.spec.in
+++ b/ipa.spec.in
@@ -384,7 +384,7 @@ fi
%{python_sitelib}/ipaserver/*
%{python_sitelib}/ipawebui/*
%dir %{_usr}/share/ipa
-%{_usr}/share/ipa/wsgi.py
+%{_usr}/share/ipa/wsgi.py*
%{_usr}/share/ipa/*.ldif
%{_usr}/share/ipa/*.uldif
%{_usr}/share/ipa/*.template
@@ -499,6 +499,9 @@ fi
%endif
%changelog
+* Mon Mar 1 2010 Jason Gerard DeRose - 1.99-18
+- Fixed share/ipa/wsgi.py so .pyc, .pyo files are included
+
* Wed Feb 24 2010 Jason Gerard DeRose - 1.99-17
- Added Require mod_wsgi, added share/ipa/wsgi.py
--
1.6.3.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] jderose 049 Consolidate to single WSGI entry point
On Mon, 2010-03-01 at 14:53 -0500, Rob Crittenden wrote: > Jason Gerard DeRose wrote: > > This is part1 of the mod_wsgi transition. It provides a new plugin: > > api.Backend.session. This is a WSGI middleware component that will > > create the LDAP connection and then route the request to the appropriate > > WSGI application (/xml or /json or /ui). > > > > The end result is that we have a single entry point (/ipa) instead of 3, > > and we also use the exact same code path to create and destroy the LDAP > > connection (which is obviously good for security). > > > > All this still is running under mod_python, but my next patch switches > > things to mod_wsgi (still have a few issues on that front). > > Ack. > > rob pushed to master. thanks for the review. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] JSON problems (the woes of binary data)
On Fri, 2010-02-26 at 15:59 -0500, John Dennis wrote:
> The Problem:
>
>
> I've been looking at the encoding exception which is being thrown when
> you click on the "Services" menu item in our current implementation. By
> default we seem to be using JSON as our RPC mechanism. The exception is
> being thrown when the JSON encoder hits a certificate. Recall that we
> store certificates in LDAP as binary data and in our implementation we
> distinguish binary data from text by Python object type, text is
> *always* a unicode object and binary data is *always* a str object.
> However in Python 2.x str objects are believed to be text and are
> subject to encoding/decoding in many parts of the Python world.
The CLI communicates to the server over XML-RPC, but the webUI
communicates to the server over JSON-RPC. Dealing with JSON on the web
client is fast and easy, XML difficult and slow.
> Unlike XML-RPC JSON does *not* have a binary type. In JSON there are
> *only* unicode strings. So what is happening is that that when the JSON
> encoder sees our certificate data in a str object it says "str objects
> are text and we have to produce a UTF-8 unicode encoding from that str
> object". There's the problem! It's completely nonsensical to try and
> encode binary to to UTF-8.
Yeah, I do wish JSON had a binary literal type. This is obviously a bug
in my JSON-RPC code, but also an issue we need to solve for the UI.
When we send binary to the webUI, what is our intent? I think that
displaying it as base64 encoded text is not generally what the user
wants. I think displaying a link that will allow them to download the
file is generally a better idea. Perhaps the Param should indicate how
it should be handled in the webUI.
> The right way to handle this is to encode the binary data to base64
> ASCII text and then hand it to JSON. FWIW our XML-RPC handler does this
> already because XML-RPC knows about binary data and elects to
> encode/decode it to base64 as it's marshaled and unmarshaled. But JSON
> can't do this during marhasling and unmarshaling because the JSON
> protocol has no concept of binary data.
>
> The python JSON encoder class does give us the option to hook into the
> encoder and check if the object is a str object and then base64 encode.
> But that doesn't help us at the opposite end. How would we know when
> unmarshaling that a given string is supposed to be base64 decoded back
> into binary data? We could prepend a special string and hope that string
> never gets used by normal text (yuck). Keeping a list of what needs
> base64 decoding is not an option within JSON because at the time of
> decoding we have no information available about the context of the JSON
> objects.
I think sending it as a dict with a special key, something like:
{'__base64__': b64encode(my_str)}
> That means if we want to use JSON we really should push the base64
> encode/decode to the parts of the code which have a priori knowledge
> about the objects they're pushing through the command interface. This
> would mean any command which passes a certificate should base64 encode
> it prior to sending it and base64 decode after it come back from a
> command result. Actually it would be preferable to use PEM encoding, and
> by the way, the whole reason why PEM encodings for certificates was
> developed was exactly for this scenario: transporting a certificate
> through a text based interchange mechanism!
>
> Possible Solutions:
> ---
>
> As I see it we have these options in front of us for how to deal with
> this problem:
>
> * Drop support for JSON, only use XML-RPC
We can't do this and keep the flexibility we need in the UI. Also,
there is a strong trend to use JSON over XML lately (RPC or otherwise),
so I think we do ourselves a disservice by dropping the JSON-RPC.
> * Once we read a certificate from LDAP immediately convert it to PEM
> format. Adopt the convention that anytime we exchange certificates it
> will be in PEM format. Only convert from PEM format when the target
> demands binary (e.g. storing it in LDAP, passing it to a library
> expecting DER encoded data, etc.).
>
> * Come up with some hacky protocol on top of JSON which signals "this
> string is really binary" and check for it on every JSON encode/decode
> and cross our fingers no one tries to send a legitimate string which
> would trigger the encode/decode.
>
> Question: Are certificates the one and only example of binary data we
> exchange?
At this time, I believe so. But it would be nice to have a plan for how
do deal with this in the future for other binary data.
> Recommendation:
> ---
>
> My personal recommendation is we adopt the convention that certificates
> are always PEM encoded. We've already run into many problems trying to
> deduce what format a certificate is (e.g. binary, base64, PEM) I think
> it would be good if we just put a stake in the gro
Re: [Freeipa-devel] commit policy for translations (.po files)
On Fri, 2010-02-26 at 13:19 -0500, John Dennis wrote: > I'd like to propose that for translations (e.g. .po files) we skip the > review process on the patch and just push them to master. Realistically > few of us will be able to verify whether the string translations are > correct or not. +1. Whoever pushes it can just make sure it isn't touching anything code related and push the patch. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] jderose 050 Run ipaserver under mod_wsgi
This patch completes the transition to running under mod_wsgi. It requires my previous "049 Consolidate to single WSGI entry point" patch. This is pretty strait forward, but a few things need highlighting: 1. mod_wsgi requires an entry point script (you can't give it a Python package name like we were doing with mod_python). Based on my reading of the Filesystem Hierarchy Standard, it seems this should be in share/ipa, so that's what I did. The script is /usr/share/ipa/wsgi.py I was expecting this to cause SELinux problems, but things seem to work fine. 2. We are running mod_wsgi in daemon mode, which is the preferred way of deploying it. The mod_wsgi daemon has both multi-process and multi-threading capabilities. As we haven't actually used threaded code much in IPA thus far (although lite-server.py is threaded), for now I have the daemon running 2 processes and 1 thread (aka it's not threaded). For production I think we probably should run something like 4 processes and 8 threads per process. This can be a later change (just requires a change in our ipa.conf Apache config file). 3. As ipaserver is now running inside the mod_wsgi daemon, we can changed from using the Apache "prefork" MPM to using "worker", which is far superior for static content. I haven't changed this yet, but we should put this on our TODO. I pretty much had this patch all done last Friday, but I've let things slow-roast for several days to make sure it's stable. I feel confident that this is a low risk change. All the same, I think we should get this pushed as soon as possible so we can shake out any remaining issues. >From dca4ee9920b8e9f323847486a5e80b0168d87b8a Mon Sep 17 00:00:00 2001 From: Jason Gerard DeRose Date: Wed, 24 Feb 2010 11:29:23 -0700 Subject: [PATCH] Run ipaserver under mod_wsgi --- install/conf/ipa.conf | 103 +-- install/share/Makefile.am |1 + install/share/wsgi.py | 13 +++ ipa.spec.in |5 + ipaserver/__init__.py | 206 - 5 files changed, 59 insertions(+), 269 deletions(-) create mode 100644 install/share/wsgi.py diff --git a/install/conf/ipa.conf b/install/conf/ipa.conf index f5987fb..dba47c5 100644 --- a/install/conf/ipa.conf +++ b/install/conf/ipa.conf @@ -4,7 +4,6 @@ # LoadModule auth_kerb_module modules/mod_auth_kerb.so ProxyRequests Off -PythonImport ipaserver main_interpreter # ipa-rewrite.conf is loaded separately @@ -12,79 +11,47 @@ PythonImport ipaserver main_interpreter AddType application/java-archivejar +# FIXME: WSGISocketPrefix is a server-scope directive. The mod_wsgi package +# should really be fixed by adding this its /etc/httpd/conf.d/wsgi.conf: +WSGISocketPrefix /var/run/httpd/wsgi - - AuthType Kerberos - AuthName "Kerberos Login" - KrbMethodNegotiate on - KrbMethodK5Passwd off - KrbServiceName HTTP - KrbAuthRealms $REALM - Krb5KeyTab /etc/httpd/conf/ipa.keytab - KrbSaveCredentials on - Require valid-user - ErrorDocument 401 /ipa/errors/unauthorized.html - - SetHandler python-program - PythonInterpreter main_interpreter - PythonHandler ipaserver::handler - PythonDebug Off - PythonOption SCRIPT_NAME /ipa - PythonAutoReload Off - - - -# -# SetHandler python-program -# PythonInterpreter main_interpreter -# PythonHandler ipaserver::xmlrpc -# PythonDebug Off -# PythonOption SCRIPT_NAME /ipa/xml -# PythonAutoReload Off -# - -# -# SetHandler python-program -# PythonInterpreter main_interpreter -# PythonHandler ipaserver::jsonrpc -# PythonDebug Off -# PythonOption SCRIPT_NAME /ipa/json -# PythonAutoReload Off -# - -# -# SetHandler python-program -# PythonInterpreter main_interpreter -# PythonHandler ipaserver::webui -# PythonDebug Off -# PythonOption SCRIPT_NAME /ipa/ui -# PythonAutoReload Off -# -Alias /ipa-assets/ "/var/cache/ipa/assets/" - - Allow from all - AllowOverride None - # add Indexes to Options to allow browsing - Options FollowSymLinks - ExpiresActive On - ExpiresDefault A31536000 - +# Configure mod_wsgi handler for /ipa +WSGIDaemonProcess ipa processes=2 threads=1 maximum-requests=500 +WSGIProcessGroup ipa +WSGIApplicationGroup ipa +WSGIImportScript /usr/share/ipa/wsgi.py process-group=ipa application-group=ipa +WSGIScriptAlias /ipa /usr/share/ipa/wsgi.py +WSGIScriptReloading Off +# Turn off mod_msgi handler for errors, config, crl: SetHandler None - SetHandler None - SetHandler None +# Protect /ipa with Kerberos + + AuthType Kerberos + AuthName "Kerberos Login" + KrbMethodNegotiate on + KrbMethodK5Passwd off + KrbServiceName HTTP + KrbAuthRealms $REALM + Krb5KeyTab /etc/httpd/conf/ipa.keytab + KrbSaveCredentials on + Require valid-user + ErrorDocument 401 /ipa/errors/unauthorized.html + + + # This is where we redirect on failed auth Alias /ipa/errors "/u
Re: [Freeipa-devel] [PATCH] jderose 048 Translatable Param.label, Param.doc
On Tue, 2010-02-23 at 14:39 -0500, John Dennis wrote: > On 02/19/2010 11:15 AM, Jason Gerard DeRose wrote: > > This patch: > > > > 1. Changes Param.label, Param.doc so they can be either text.Gettext or > > str instances. This is transitional till we get any outstanding patches > > merged in, then they will only allow text.Gettext instances. > > > > 2. Adds a docstring to the ipalib/parameters.py module explaining the > > difference between cli_name, label, and doc. It also has some style > > guidelines for the label and doc. > > > > 3. Marks all Param.label and Param.doc for translation, does some > > cleanup to hopefully make things a bit more consistent. > > > > 4. Various small changes needed to adjust to Param.label, Param.doc > > being text.Gettext instances. > > ACK > > Sometime in the near future (it can be part of another patch) I'd like > to see the doc for cli_name expanded upon to explain it's only purpose > is to provide a name for the command line argument (e.g. --foo) and how > this is completely independent of the label used for prompts and > displaying a value. Also the text.FixMe class needs some documentation > on how we plan on using it to find unstranslated strings. pushed to master. thanks for the review. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] jderose 049 Consolidate to single WSGI entry point
This is part1 of the mod_wsgi transition. It provides a new plugin:
api.Backend.session. This is a WSGI middleware component that will
create the LDAP connection and then route the request to the appropriate
WSGI application (/xml or /json or /ui).
The end result is that we have a single entry point (/ipa) instead of 3,
and we also use the exact same code path to create and destroy the LDAP
connection (which is obviously good for security).
All this still is running under mod_python, but my next patch switches
things to mod_wsgi (still have a few issues on that front).
>From 541616b0290d309a686bf66febb370ef0cade06a Mon Sep 17 00:00:00 2001
From: Jason Gerard DeRose
Date: Tue, 23 Feb 2010 10:53:47 -0700
Subject: [PATCH] Consolidate to single WSGI entry point
---
install/conf/ipa.conf | 81 +++--
ipalib/constants.py|2 +-
ipaserver/__init__.py |4 +
ipaserver/plugins/xmlserver.py | 10 +--
ipaserver/rpcserver.py | 149 +---
ipawebui/__init__.py | 11 +--
lite-server.py |6 +-
tests/test_ipaserver/test_rpcserver.py | 96 -
8 files changed, 276 insertions(+), 83 deletions(-)
diff --git a/install/conf/ipa.conf b/install/conf/ipa.conf
index b956293..f5987fb 100644
--- a/install/conf/ipa.conf
+++ b/install/conf/ipa.conf
@@ -11,14 +11,6 @@ PythonImport ipaserver main_interpreter
# This is required so the auto-configuration works with Firefox 2+
AddType application/java-archivejar
-# This is where we redirect on failed auth
-Alias /ipa/errors "/usr/share/ipa/html"
-
-# For the MIT Windows config files
-Alias /ipa/config "/usr/share/ipa/html"
-
-# For CRL publishing
-Alias /ipa/crl "/var/lib/pki-ca/publish"
@@ -32,34 +24,42 @@ Alias /ipa/crl "/var/lib/pki-ca/publish"
KrbSaveCredentials on
Require valid-user
ErrorDocument 401 /ipa/errors/unauthorized.html
-
-
SetHandler python-program
PythonInterpreter main_interpreter
- PythonHandler ipaserver::xmlrpc
+ PythonHandler ipaserver::handler
PythonDebug Off
- PythonOption SCRIPT_NAME /ipa/xml
+ PythonOption SCRIPT_NAME /ipa
PythonAutoReload Off
-
-
- SetHandler python-program
- PythonInterpreter main_interpreter
- PythonHandler ipaserver::jsonrpc
- PythonDebug Off
- PythonOption SCRIPT_NAME /ipa/json
- PythonAutoReload Off
-
- SetHandler python-program
- PythonInterpreter main_interpreter
- PythonHandler ipaserver::webui
- PythonDebug Off
- PythonOption SCRIPT_NAME /ipa/ui
- PythonAutoReload Off
-
+#
+# SetHandler python-program
+# PythonInterpreter main_interpreter
+# PythonHandler ipaserver::xmlrpc
+# PythonDebug Off
+# PythonOption SCRIPT_NAME /ipa/xml
+# PythonAutoReload Off
+#
+
+#
+# SetHandler python-program
+# PythonInterpreter main_interpreter
+# PythonHandler ipaserver::jsonrpc
+# PythonDebug Off
+# PythonOption SCRIPT_NAME /ipa/json
+# PythonAutoReload Off
+#
+
+#
+# SetHandler python-program
+# PythonInterpreter main_interpreter
+# PythonHandler ipaserver::webui
+# PythonDebug Off
+# PythonOption SCRIPT_NAME /ipa/ui
+# PythonAutoReload Off
+#
Alias /ipa-assets/ "/var/cache/ipa/assets/"
@@ -72,14 +72,39 @@ Alias /ipa-assets/ "/var/cache/ipa/assets/"
+
+ SetHandler None
+
+
+
+ SetHandler None
+
+
+
+ SetHandler None
+
+
+
+# This is where we redirect on failed auth
+Alias /ipa/errors "/usr/share/ipa/html"
+
+# For the MIT Windows config files
+Alias /ipa/config "/usr/share/ipa/html"
+
# Do no authentication on the directory that contains error messages
+ SetHandler None
AllowOverride None
Satisfy Any
Allow from all
+
+# For CRL publishing
+Alias /ipa/crl "/var/lib/pki-ca/publish"
+
+ SetHandler None
AllowOverride None
Options Indexes FollowSymLinks
Satisfy Any
diff --git a/ipalib/constants.py b/ipalib/constants.py
index 79ddbca..a942076 100644
--- a/ipalib/constants.py
+++ b/ipalib/constants.py
@@ -108,7 +108,7 @@ DEFAULT_CONFIG = (
('mount_ipa', '/ipa/'),
('mount_xmlserver', 'xml'),
('mount_jsonserver', 'json'),
-('mount_webui', 'ui/'),
+('mount_webui', 'ui'),
('mount_webui_assets', '/ipa-assets/'),
# WebUI stuff:
diff --git a/ipaserver/__init__.py b/ipaserver/__init__.py
index 1b62255..874ac3e 100644
--- a/ipaserver/__init__.py
+++ b/ipaserver/__init__.py
@@ -222,3 +222,7 @@ def webui(req):
mod_python handler for web-UI requests (place holder).
"""
return adapter(req, ui)
+
+
+def handler(req):
+return adapter(req, api.Backend.session)
diff --git a/ipaserver/plugins/xmlserver.py b/ipaserver/plugins/xmlserver.py
index cbbf148..290bef6 100644
--- a/ipaser
[Freeipa-devel] mod_wsgi troubles
So I've been working on migrating freeIPA from mod_python to mod_wsgi. This isn't a big change as the IPA server is already all WSGI internally, but I've run into 2 unexpected problems. mod_wsgi daemon mode First, the easy problem. The mod_wsgi documentation clearly states that the daemon mode is the preferred way to deploy. See the "Defining Process Groups" section in: http://code.google.com/p/modwsgi/wiki/ConfigurationGuidelines In daemon mode, Apache starts mod_wsgi in a separate process and communicates with it via a Unix socket. Unfortunately, Fedora12 doesn't support daemon mode nicely out of the box and tries create the socket in /etc/httpd/run, which of course make selinux mad (as it should). I believe Apache is being run with the Apache home set to /etc/httpd (which itself seems weird to me, not sure if this is a bug). Anyway, we can fix this with the WSGISocketPrefix directive. But this directive is server-scope (can't be virtual-host-scope), so we really need to fix this in the mod_wsgi package. We just need to add this to /etc/httpd/conf.d/wsgi.conf: WSGISocketPrefix /var/run/httpd/wsgi This config file is owned by mod_wsgi, not IPA, so I don't think IPA should be writing stuff to this during it's install. Again, needs to be fixed in the mod_wsgi package. I haven't tried this under Fedora11 yet, so I don't know if the same problem is present there. Simplify Kerberos protected URLs Currently in our URL space we have: /ipa/xml - Kerberos protected /ipa/json - Kerberos protected /ipa/ui- Kerberos protected /ipa/errors - Not protected /ipa/config - Not protected /ipa/crl- Not protected Under mod_python, we have separate handlers for the xml, json, and ui URLs. My upcoming patch has a new WSGI middleware component this is a single entry point at /ipa. I did this so that the LDAP auth and session stuff is handled in exactly the same way regardless of which app is the final target. Anyway, right now we have to handle stuff in a pretty funky way (including under mod_python). We turn on Kerb auth for /ipa, then turn it off for /ipa/errors and friends. I would really like us to have two base URLs, something like this: /ipa/*- Kerberos projected /ipa-static/* - Not projected Doesn't have to be called ipa-static, just throwing a name out there. We can work around this (as we already do), but there 2 reasons I think we should do this: 1. Security - our current approach is confusing and opens us up to mistakes (our mistakes or a sysadmin's). 2. Extensibility - in the V2 cycle we have added several new things in /ipa/*, some Kerberos protected, some not. I'm sure this will happen again in the future, so we might as well clean this up now. What do people think? I'm not sure I explained this well, but look in install/conf/ipa.conf and you'll see what I mean. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] minor makefile cleanup
On Mon, 2010-02-22 at 16:54 -0500, John Dennis wrote: > Nalin correctly identified two minor issues in the install/po/Makefile > he noticed after my last patch. > > The empty rule for the all target is bad style. > > The newly added target "mo-files" should have been listed in the .PHONY > list. > > Neither one should cause problem, but they should be cleaned up. ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] fix i18n build problem
On Mon, 2010-02-22 at 16:21 -0500, John Dennis wrote: > There was a typo in install/po/Makefile.in which caused (some) of > the .po files to be overwritten because the test to see if a po > file existed had a typo in it. > > This patch also removes the unnecessary rebuilding of the pot which was > happening when using the "all" target (the default). The pot file now > must be manually remade, which is what we want. > > Added a new target "mo-files" to manually generate the .mo files. > This is useful to run before checking in a new .po file just to > assure it "compiles" and we don't have to discover this during a > build. ack. pushed to master. I confirmed that this fixes the build problem in my tree. Thanks. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] jderose 048 Translatable Param.label, Param.doc
This patch:
1. Changes Param.label, Param.doc so they can be either text.Gettext or
str instances. This is transitional till we get any outstanding patches
merged in, then they will only allow text.Gettext instances.
2. Adds a docstring to the ipalib/parameters.py module explaining the
difference between cli_name, label, and doc. It also has some style
guidelines for the label and doc.
3. Marks all Param.label and Param.doc for translation, does some
cleanup to hopefully make things a bit more consistent.
4. Various small changes needed to adjust to Param.label, Param.doc
being text.Gettext instances.
>From c3cfcd0f73d6078146b2785c4f0f35692883fec6 Mon Sep 17 00:00:00 2001
From: Jason Gerard DeRose
Date: Fri, 19 Feb 2010 09:08:16 -0700
Subject: [PATCH] Translatable Param.label, Param.doc
---
ipalib/frontend.py |2 +-
ipalib/parameters.py | 91 ++
ipalib/plugins/aci.py| 31 +++
ipalib/plugins/automount.py | 23 +
ipalib/plugins/baseldap.py | 42 +++-
ipalib/plugins/cert.py | 50 ++-
ipalib/plugins/config.py | 41 +++
ipalib/plugins/dns.py| 79 ++
ipalib/plugins/group.py | 22
ipalib/plugins/hbac.py | 25 ++
ipalib/plugins/host.py | 40 ---
ipalib/plugins/hostgroup.py | 14 +++---
ipalib/plugins/krbtpolicy.py | 11 +++--
ipalib/plugins/migration.py | 17 ---
ipalib/plugins/netgroup.py | 14 ++---
ipalib/plugins/passwd.py |4 +-
ipalib/plugins/pwpolicy.py | 43 +---
ipalib/plugins/rolegroup.py | 13 ++---
ipalib/plugins/service.py|8 ++--
ipalib/plugins/taskgroup.py | 13 ++---
ipalib/plugins/user.py | 28 +-
ipalib/text.py | 23 -
tests/test_ipalib/test_parameters.py |6 +-
23 files changed, 363 insertions(+), 277 deletions(-)
diff --git a/ipalib/frontend.py b/ipalib/frontend.py
index 6ed388f..4d0df3a 100644
--- a/ipalib/frontend.py
+++ b/ipalib/frontend.py
@@ -844,7 +844,7 @@ class Command(HasParam):
if options.get('raw', False):
labels = None
else:
-labels = dict((p.name, p.label) for p in self.output_params())
+labels = dict((p.name, unicode(p.label)) for p in self.output_params())
for o in self.output:
if 'no_display' in self.output[o].flags:
diff --git a/ipalib/parameters.py b/ipalib/parameters.py
index 3911d6e..8c6a7e7 100644
--- a/ipalib/parameters.py
+++ b/ipalib/parameters.py
@@ -20,13 +20,83 @@
"""
Parameter system for command plugins.
-TODO:
-
- * Change rule call signature to rule(_, value, **kw) so that rules can also
-validate relative to other parameter values (e.g., login name as it relates
-to first name and last name)
-
- * Add the _rule_pattern() methods to `Bytes` and `Str`
+A `Param` instance can be used to describe an argument or option that a command
+takes, or an attribute that a command returns. The `Param` base class is not
+used directly, but there are many subclasses for specific Python data types
+(like `Str` or `Int`) and specific properties (like `Password`).
+
+To create a `Param` instance, you must always provide the parameter *name*,
+which should be the LDAP attribute name if the parameter describes the attribute
+of an LDAP entry. For example, we could create an `Str` instance describing the user's last-name attribute like this:
+
+>>> from ipalib import Str
+>>> sn = Str('sn')
+>>> sn.name
+'sn'
+
+When creating a `Param`, there are also a number of optional kwargs which
+which can provide additional meta-data and functionality. For example, every
+parameter has a *cli_name*, the name used on the command-line-interface. By
+default the *cli_name* is the same as the *name*:
+
+>>> sn.cli_name
+'sn'
+
+But often the LDAP attribute name isn't user friendly for the command-line, so
+you can override this with the *cli_name* kwarg:
+
+>>> sn = Str('sn', cli_name='last')
+>>> sn.name
+'sn'
+>>> sn.cli_name
+'last'
+
+Note that the RPC interfaces (and the internal processing pipeline) always use
+the parameter *name*, regardless of what the *cli_name* might be.
+
+A `Param` also has two translatable kwargs: *label* and *doc*. These must both
+be `Gettext` instances. They both default to a place-holder `FixMe` instance,
+a subclass of `Gettext` used to mark a missing translatable string:
+
+>>> sn.label
+FixMe('sn')
+>>> sn.doc
+FixMe('sn')
+
+The *label*
[Freeipa-devel] [PATCH] jderose 047 Fix tests
This fixes some tests (non XML-RPC) that got broken in the last few
days.
Please please update tests in the same patch if your patch breaks
them. :)
>From b3e6ccfefd18e41714b48b4a1e733162516136d3 Mon Sep 17 00:00:00 2001
From: Jason Gerard DeRose
Date: Fri, 19 Feb 2010 03:13:11 -0700
Subject: [PATCH] Fix non XML-RPC tests
---
ipalib/cli.py |9 -
ipalib/crud.py |4 ++--
tests/test_ipalib/test_crud.py | 21 +
3 files changed, 15 insertions(+), 19 deletions(-)
diff --git a/ipalib/cli.py b/ipalib/cli.py
index 213a9c4..715f2e1 100644
--- a/ipalib/cli.py
+++ b/ipalib/cli.py
@@ -293,15 +293,6 @@ class textui(backend.Backend):
one_value_per_line=True):
"""
Print an ldap entry dict.
-
-For example:
-
->>> entry = dict(sn='Last', givenname='First', uid='flast')
->>> ui = textui()
->>> ui.print_entry(entry)
- givenname: First
- sn: Last
- uid: flast
"""
assert isinstance(entry, dict)
assert isinstance(attr_map, dict)
diff --git a/ipalib/crud.py b/ipalib/crud.py
index 77c97f3..fa8b9ad 100644
--- a/ipalib/crud.py
+++ b/ipalib/crud.py
@@ -76,7 +76,7 @@ us:
>>> list(api.Command.user_add.args)
['login']
>>> list(api.Command.user_add.options)
-['first', 'last']
+['first', 'last', 'all', 'raw']
Notice that ``'ipauniqueid'`` isn't included in the options for our ``user_add``
plugin. This is because of the ``'no_create'`` flag we used when defining the
@@ -94,7 +94,7 @@ class created them for us:
>>> list(api.Command.user_show.args)
['login']
>>> list(api.Command.user_show.options)
-[]
+['all', 'raw']
As you can see, `Retrieve` plugins take a single argument (the primary key) and
no options. If needed, you can still specify options for your `Retrieve` plugin
diff --git a/tests/test_ipalib/test_crud.py b/tests/test_ipalib/test_crud.py
index 969fb4f..b8399e5 100644
--- a/tests/test_ipalib/test_crud.py
+++ b/tests/test_ipalib/test_crud.py
@@ -74,12 +74,12 @@ class test_Create(CrudChecker):
"""
api = self.get_api()
assert list(api.Method.user_verb.options) == \
-['givenname', 'sn', 'initials']
+['givenname', 'sn', 'initials', 'all', 'raw']
for param in api.Method.user_verb.options():
assert param.required is True
api = self.get_api(options=('extra?',))
assert list(api.Method.user_verb.options) == \
-['givenname', 'sn', 'initials', 'extra']
+['givenname', 'sn', 'initials', 'extra', 'all', 'raw']
assert api.Method.user_verb.options.extra.required is False
@@ -104,9 +104,12 @@ class test_Update(CrudChecker):
"""
api = self.get_api()
assert list(api.Method.user_verb.options) == \
-['givenname', 'initials', 'uidnumber']
+['givenname', 'initials', 'uidnumber', 'all', 'raw']
for param in api.Method.user_verb.options():
-assert param.required is False
+if param.name in ['all', 'raw']:
+assert param.required is True
+else:
+assert param.required is False
class test_Retrieve(CrudChecker):
@@ -129,8 +132,7 @@ class test_Retrieve(CrudChecker):
Test the `ipalib.crud.Retrieve.get_options` method.
"""
api = self.get_api()
-assert list(api.Method.user_verb.options) == []
-assert len(api.Method.user_verb.options) == 0
+assert list(api.Method.user_verb.options) == ['all', 'raw']
class test_Delete(CrudChecker):
@@ -178,9 +180,12 @@ class test_Search(CrudChecker):
"""
api = self.get_api()
assert list(api.Method.user_verb.options) == \
-['givenname', 'sn', 'uid', 'initials']
+['givenname', 'sn', 'uid', 'initials', 'all', 'raw']
for param in api.Method.user_verb.options():
-assert param.required is False
+if param.name in ['all', 'raw']:
+assert param.required is True
+else:
+assert param.required is False
class test_CrudBackend(ClassChecker):
--
1.6.3.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] jderose 046 Add buildrequires script
I want to make our development process more easily automated and repeatable, so I started on this script to install all the packages a person would likely need to hack on the server. I'm using this to bootstrap fresh VMs. Plus this lowers the barrier for new developers. >From 08d97541088df605f87447df4bce6946e64eed9b Mon Sep 17 00:00:00 2001 From: Jason Gerard DeRose Date: Thu, 18 Feb 2010 18:43:54 -0700 Subject: [PATCH] Add buildrequires script to help new developers --- contrib/install-buildrequires.sh | 48 ++ 1 files changed, 48 insertions(+), 0 deletions(-) create mode 100755 contrib/install-buildrequires.sh diff --git a/contrib/install-buildrequires.sh b/contrib/install-buildrequires.sh new file mode 100755 index 000..81faec8 --- /dev/null +++ b/contrib/install-buildrequires.sh @@ -0,0 +1,48 @@ +#!/bin/sh + +# This should install pretty much everything you might need to work on FreeIPA, +# and then some. Let's try to keep this up-to-date to make things easier for +# new developers. + +packages="\ +389-ds-base-devel \ +autoconf \ +automake \ +bzr \ +e2fsprogs-devel \ +epydoc \ +gettext \ +git \ +krb5-devel \ +libcap-devel \ +libtool \ +m4 \ +make \ +mozldap-devel \ +nspr-devel \ +nss-devel \ +openldap-clients \ +openldap-devel \ +openssl-devel \ +policycoreutils \ +popt-devel \ +pyOpenSSL \ +python-configobj \ +python-devel \ +python-docutils \ +python-genshi \ +python-kerberos \ +python-krbV \ +python-ldap \ +python-lxml \ +python-nose \ +python-pyasn1 \ +python-pygments \ +python-sqlalchemy \ +python-wehjit \ +rpm-build \ +svrcore-devel \ +xmlrpc-c-devel \ +" + +yum install $packages -- 1.6.3.3 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] jderose 045 Remove bugfix widgets
We were overriding some wehjit builtins with bugfix widgets, but these
have all been fixed as of wehjit 0.2.1, so we don't need them anymore.
>From ed78ef79d33b9cf60eff3611cf05a7fac9afdb62 Mon Sep 17 00:00:00 2001
From: Jason Gerard DeRose
Date: Thu, 18 Feb 2010 17:29:31 -0700
Subject: [PATCH] Remove bugfix widgets
---
ipawebui/widgets.py | 152 ---
1 files changed, 0 insertions(+), 152 deletions(-)
diff --git a/ipawebui/widgets.py b/ipawebui/widgets.py
index d05b5b4..9d6170f 100644
--- a/ipawebui/widgets.py
+++ b/ipawebui/widgets.py
@@ -246,154 +246,6 @@ class LandingPage(base.Widget):
"""
-class Form(builtins.Form):
-js_class = 'Form'
-
-javascript = """
-Wehjit.bases.Form = new Class({
-Extends: Wehjit.bases.Widget,
-
-post_init: function() {
-this.focused = null;
-$each(this.el.elements, function(field) {
-field.connect('focus', this);
-}, this);
-var parent = this.get_parent();
-if (parent && parent.klass == 'Dialog') {
-parent.addEvent('run', this.on_run.bind(this));
-this.parent = parent;
-}
-this.formdata = null;
-},
-
-on_focus: function(field, event) {
-this.focused = field;
-},
-
-on_run: function(dialog, params) {
-console.assert(dialog == this.parent);
-this.refocus();
-},
-
-refocus: function() {
-console.log('refocus', this.id, this.focused);
-if (this.focused) {
-this.focused.focus();
-return true;
-}
-if (this.el.elements.length > 0) {
-this.el.elements[0].focus();
-return true;
-}
-return false;
-},
-
-get_data: function() {
-console.log('Form.get_data');
-var rawdata = this.el.get_data();
-var data = {};
-
-if (this.formdata == null) {
-$each(rawdata, function(value, key) {
-if (value !== '') {
-data[key] = value;
-}
-});
-}
-else {
-$each(rawdata, function(value, key) {
-var old = this.formdata[key];
-if (old == undefined && value === '') {
-return;
-}
-if (old != value) {
-console.log('changed: %s = %s', key, value);
-data[key] = value;
-}
-}, this);
-}
-
-return data;
-
-},
-
-set_data: function(data) {
-console.log('Form.set_data', data);
-this.focused = null;
-if ($type(data) == 'object') {
-this.formdata = data;
-}
-else {
-this.formdata = null;
-}
-this.el.set_data(data);
-},
-
-reset: function() {
-this.formdata = null;
-this.focused = null;
-this.el.reset();
-},
-
-});
-"""
-
-
-class CRUDS(builtins.CRUDS):
-display_cols = Static('display_cols', json=True, default=tuple())
-
-
-class Display(builtins.Display):
-cols = None
-
-javascript = """
-Wehjit.bases.Display = new Class({
-Extends: Wehjit.bases.Widget,
-
-post_init: function() {
-var parent = this.get_parent();
-console.assert(parent);
-parent.addEvent('run', this.on_run.bind(this));
-this.cruds = Wehjit.get('cruds');
-this.cols = this.cruds.data.display_cols;
-console.assert(this.cols);
-if (this.cols.length == 0) {
-this.cols = Wehjit.data.grid.cols;
-}
-},
-
-on_run: function(dialog, row) {
-console.log('Display.on_run(%s, %s)', dialog, row);
-this.el.empty();
-if ($type(row) != 'object') {
-return;
-}
-this.cols.each(function(col) {
-var tr = new Element('tr');
-var th = new Element('th');
-th.textContent = col.label + ':';
-tr.appendChild(th);
-this.el.appendChild(tr);
-var td = new Element('td');
-var value = row[col.name];
-if ($type(value) == 'array') {
-var value = value.join(',');
-
Re: [Freeipa-devel] [PATCH] 383 reverse special handling for it
On Wed, 2010-02-17 at 10:59 -0500, Rob Crittenden wrote: > Well this hack lasted less time than I expected. This backs out special > handling for ints. > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 382 fix pwpolicy output
On Tue, 2010-02-16 at 23:01 -0500, Rob Crittenden wrote: > Convert the pwpolicy plugin to use the new output system. Otherwise some > of these commands output nothing at all, or at best something not quite > useful. > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 381 fix output of integers
On Tue, 2010-02-16 at 23:00 -0500, Rob Crittenden wrote: > Integers are included in the list of things to convert to str > internally. This makes them be considered binary by > ipalib.cli.encode_binary(). Add a hackish test for now to see if we have > an integer or not. I know that Pavel is working on more graceful way to > handle encoding and I can live with this for now. > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Use unicode instead of str for environmental variables in Env.
On Thu, 2010-02-11 at 15:20 +0100, Pavel Zuna wrote: > The patch is not far from trivial, but... > > It makes the assumption, that IPA config files are utf-8 encoded (or > compatible > like ASCII). Is that OK? > > Pavel Ack, but I wonder if we should wait till after the alpha to push this? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 380 Use the Output settings to determine output order
On Fri, 2010-02-12 at 16:41 -0500, Rob Crittenden wrote: > This patch does a number of things. I considered breaking it up but it > is so interdependent I thought that would make more work. > > The core of this is using the Output tuple defined for the command to > determine the order of output. This is a very broad brush, controlling > only the summary, entry and value order, but it's a start. > > This also fixes displaying group membership and failed membership > modifications. I added a bit of recursion to support that. It may need > some more beautification work but the basics are there. > > I've also got all tests passing at 100%. The only thing left to do is to > get the framework to return the dn again. Once that works we can remove > the hash for all the #dn entries in the tests. > > rob ack. pushed to master. Nice patch, Rob. The only thing I'd like us to add (in a separate patch) is to change Output.flags to be a frozenset. I'm a big fan of using immutable data types to prevent multi-threading gotchas. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 379 fix automountlocation-tofiles
On Fri, 2010-02-12 at 16:29 -0500, Rob Crittenden wrote: > The command automountlocation-tofiles hadn't been ported to the new > return value format. It should work again. I also added a few labels to > make the output more readable. > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 379 fix automountlocation-tofiles
On Mon, 2010-02-15 at 13:38 -0500, John Dennis wrote: > On 02/15/2010 01:33 PM, Jason Gerard DeRose wrote: > > On Mon, 2010-02-15 at 13:28 -0500, John Dennis wrote: > >> On 02/15/2010 01:22 PM, Jason Gerard DeRose wrote: > >>> On Sat, 2010-02-13 at 08:55 -0500, John Dennis wrote: > >>>> On 02/12/2010 04:29 PM, Rob Crittenden wrote: > >>>>> The command automountlocation-tofiles hadn't been ported to the new > >>>>> return value format. It should work again. I also added a few labels to > >>>>> make the output more readable. > >>>> > >>>> Shouldn't the labels be localized? > >>>> > >>> > >>> Yes, this is fixed in a patch I have in the works, but I was saving it > >>> for post-alpha. > >>> > >> > >> I was going to go through and find all labels not marked for translation > >> and mark them. Have you already done this? > >> > >> I don't think we should postpone patches to post-alpha whose purpose is > >> to mark strings for translation because we've asked the community of > >> translators to start working on our translations and in fairness to them > >> the pot file should be as complete as possible when they begin work, > >> plus I think marking strings for translation is very low risk > >> (especially in the context of an alpha release). > > > > > > This change requires some changes to the Params (to change the type of > > the label), which is a bit more disruptive, why I was waiting. > > > > How about the answer to the first question. Have you gone through the > code and marked all labels for translation? Yes, this patch marks all the Param.labels for translations. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 379 fix automountlocation-tofiles
On Mon, 2010-02-15 at 13:28 -0500, John Dennis wrote: > On 02/15/2010 01:22 PM, Jason Gerard DeRose wrote: > > On Sat, 2010-02-13 at 08:55 -0500, John Dennis wrote: > >> On 02/12/2010 04:29 PM, Rob Crittenden wrote: > >>> The command automountlocation-tofiles hadn't been ported to the new > >>> return value format. It should work again. I also added a few labels to > >>> make the output more readable. > >> > >> Shouldn't the labels be localized? > >> > > > > Yes, this is fixed in a patch I have in the works, but I was saving it > > for post-alpha. > > > > I was going to go through and find all labels not marked for translation > and mark them. Have you already done this? > > I don't think we should postpone patches to post-alpha whose purpose is > to mark strings for translation because we've asked the community of > translators to start working on our translations and in fairness to them > the pot file should be as complete as possible when they begin work, > plus I think marking strings for translation is very low risk > (especially in the context of an alpha release). This change requires some changes to the Params (to change the type of the label), which is a bit more disruptive, why I was waiting. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 379 fix automountlocation-tofiles
On Sat, 2010-02-13 at 08:55 -0500, John Dennis wrote: > On 02/12/2010 04:29 PM, Rob Crittenden wrote: > > The command automountlocation-tofiles hadn't been ported to the new > > return value format. It should work again. I also added a few labels to > > make the output more readable. > > Shouldn't the labels be localized? > Yes, this is fixed in a patch I have in the works, but I was saving it for post-alpha. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 378 allow one-character Param names
On Fri, 2010-02-12 at 11:03 -0500, Rob Crittenden wrote: > Loosen up the variable name restrictions in Params so we can handle the > attribute l (localityname). > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] jderose 044 Add sha1, md5 to compat
This patch adds `sha1` and `md5` classes to the `compat` module. These
will work in Python 2.4 - 2.5 without raising a `DeprecationWarning`.
>From fc8710cf1371d0b71341ec3cb162e19699090ffb Mon Sep 17 00:00:00 2001
From: Jason Gerard DeRose
Date: Fri, 12 Feb 2010 13:03:14 -0700
Subject: [PATCH] Add sha1, md5 to compat
---
ipalib/compat.py | 38 ++
1 files changed, 34 insertions(+), 4 deletions(-)
diff --git a/ipalib/compat.py b/ipalib/compat.py
index 70f098b..fcf33fd 100644
--- a/ipalib/compat.py
+++ b/ipalib/compat.py
@@ -18,11 +18,14 @@
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
"""
-Abstracts some compatability issues for Python2.4 - Python2.6.
+Abstracts some compatibility issues for Python 2.4 - Python 2.6.
-The ``json`` module was added in Python2.6, which previously was in a seperate
-package and called ``simplejson``. This hack abstracts the difference so you
-can use the ``json`` module generically like this:
+Python 2.6
+==
+
+The ``json`` module was added in Python 2.6, which previously was in an external
+package and called ``simplejson``. The `compat` module abstracts the difference
+so you can use the ``json`` module generically like this:
>>> from compat import json
>>> json.dumps({'hello': 'world'})
@@ -40,6 +43,28 @@ future-proofing here so you can import ``parse_qs()`` generically like this:
For more information, see *What's New in Python 2.6*:
http://docs.python.org/whatsnew/2.6.html
+
+
+Python 2.5
+==
+
+The ``hashlib`` module was added in Python2.5, after which use of the ``sha``
+and ``md5`` modules is deprecated. You can generically import a ``sha1`` class
+from the `compat` module like this:
+
+>>> from compat import sha1
+>>> sha1('hello world').hexdigest()
+'2aae6c35c94fcfb415dbe95f408b9ce91ee846ed'
+
+And generically import an ``md5`` class like this:
+
+>>> from compat import md5
+>>> md5('hello world').hexdigest()
+'5eb63bbbe01eeed093cb22bb8f5acdc3'
+
+For more information, see *What's New in Python 2.5*:
+
+http://python.org/doc/2.5/whatsnew/whatsnew25.html
"""
import sys
@@ -49,3 +74,8 @@ if sys.version_info[:2] >= (2, 6):
else:
import simplejson as json
from cgi import parse_qs
+try:
+from hashlib import sha1, md5
+except ImportError:
+from sha import new as sha1
+from md5 import new as md5
--
1.6.3.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 377 fix deprecation warning
On Fri, 2010-02-12 at 10:56 -0500, Rob Crittenden wrote: > Fix a deprecation warning importing sha. > > rob nack. There is no `sha` attribute in the `hashlib` module; instead, you'll need to use `hashlib.sha1`, like this: try: from hashlib import sha1 as sha except ImportError: from sha import sha I'd like to start consolidating these Python compatibility hacks in the `ipalib.compat` module. But in the case of the `uuid` module, with its funky imports inside of functions, we should probably keep our modifications to a minimum. So I agree with your approach. ack once you fix the import. ;) ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] jderose 042 Fix ctypes SELinux problem
On Thu, 2010-02-11 at 14:57 -0500, Rob Crittenden wrote: > Jason Gerard DeRose wrote: > > Under Fedora12, the httpd SELinux policy causes IPA to bomb when the > > Python `ctypes` module gets imported. The `ctypes` module is used by > > python-pygments, which in turn is used by python-wehjit. > > > > I just made a python-wehjit 0.2.2 bugfix release with a hack to prevent > > wehjit from importing pygments. This also disables the pygments-based > > source code highlighting plugins, but we aren't using those in IPA at > > the moment anyway. > > > > This patch changes the .spec to require python-wehjit >= 0.2.2 and adds > > the pygments disabling hack in ipawebui/__init__.py > > > > Ack. Lets hold off on pushing this until the library gets into the > Fedora update stream. > > rob python-wehjit 0.2.2 has landed in Fedora 11 & 12. Pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] jderose 042 Fix ctypes SELinux problem
On Thu, 2010-02-11 at 14:57 -0500, Rob Crittenden wrote: > Jason Gerard DeRose wrote: > > Under Fedora12, the httpd SELinux policy causes IPA to bomb when the > > Python `ctypes` module gets imported. The `ctypes` module is used by > > python-pygments, which in turn is used by python-wehjit. > > > > I just made a python-wehjit 0.2.2 bugfix release with a hack to prevent > > wehjit from importing pygments. This also disables the pygments-based > > source code highlighting plugins, but we aren't using those in IPA at > > the moment anyway. > > > > This patch changes the .spec to require python-wehjit >= 0.2.2 and adds > > the pygments disabling hack in ipawebui/__init__.py > > > > Ack. Lets hold off on pushing this until the library gets into the > Fedora update stream. Agreed. > rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] jderose 042 Fix ctypes SELinux problem
Oops, the subject should have been "jderose 043...". This does not replace my 042 patch in anyway. ;) On Thu, 2010-02-11 at 02:46 -0700, Jason Gerard DeRose wrote: > Under Fedora12, the httpd SELinux policy causes IPA to bomb when the > Python `ctypes` module gets imported. The `ctypes` module is used by > python-pygments, which in turn is used by python-wehjit. > > I just made a python-wehjit 0.2.2 bugfix release with a hack to prevent > wehjit from importing pygments. This also disables the pygments-based > source code highlighting plugins, but we aren't using those in IPA at > the moment anyway. > > This patch changes the .spec to require python-wehjit >= 0.2.2 and adds > the pygments disabling hack in ipawebui/__init__.py > ___ > 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
[Freeipa-devel] [PATCH] jderose 042 Fix ctypes SELinux problem
Under Fedora12, the httpd SELinux policy causes IPA to bomb when the
Python `ctypes` module gets imported. The `ctypes` module is used by
python-pygments, which in turn is used by python-wehjit.
I just made a python-wehjit 0.2.2 bugfix release with a hack to prevent
wehjit from importing pygments. This also disables the pygments-based
source code highlighting plugins, but we aren't using those in IPA at
the moment anyway.
This patch changes the .spec to require python-wehjit >= 0.2.2 and adds
the pygments disabling hack in ipawebui/__init__.py
>From 1ccd57880a891f4592f695791672f5db1e1accd4 Mon Sep 17 00:00:00 2001
From: Jason Gerard DeRose
Date: Thu, 11 Feb 2010 02:27:00 -0700
Subject: [PATCH] Add fix for wehjit (ctypes) SELinux problem
---
ipa.spec.in |9 ++---
ipawebui/__init__.py |7 +++
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/ipa.spec.in b/ipa.spec.in
index 3de1a2a..0607dd7 100644
--- a/ipa.spec.in
+++ b/ipa.spec.in
@@ -85,7 +85,7 @@ Requires: mod_nss
Requires: python-ldap
Requires: python-krbV
Requires: python-assets
-Requires: python-wehjit >= 0.2.0
+Requires: python-wehjit >= 0.2.2
Requires: acl
Requires: python-pyasn1 >= 0.0.9a
Requires: libcap
@@ -497,6 +497,9 @@ fi
%endif
%changelog
+* Thu Feb 11 2010 Jason Gerard DeRose - 1.99-16
+- Require python-wehjit >= 0.2.2
+
* Wed Feb 3 2010 Rob Crittenden - 1.99-15
- Add sssd and certmonger as a Requires on ipa-client
@@ -655,7 +658,7 @@ fi
* Thu Jan 24 2008 Rob Crittenden 0.99-3
- Included LICENSE and README in all packages for documentation
-- Move user-modifiable content to /etc/ipa and linked back to
+- Move user-modifiable content to /etc/ipa and linked back to
/usr/share/ipa/html
- Changed some references to /usr to the {_usr} macro and /etc
to {_sysconfdir}
@@ -702,7 +705,7 @@ fi
- Convert to autotools-based build
* Tue Sep 25 2007 Karl MacMillan - 0.4.0-2
-
+
* Fri Sep 7 2007 Karl MacMillan - 0.3.0-1
- Added support for libipa-dna-plugin
diff --git a/ipawebui/__init__.py b/ipawebui/__init__.py
index c7ebaa8..037fc76 100644
--- a/ipawebui/__init__.py
+++ b/ipawebui/__init__.py
@@ -20,6 +20,13 @@
IPA web UI.
"""
+# Special wehjit initialization to prevent it from loading the plugins that
+# require pygments, which uses ctypes, which makes the httpd SELinux policy
+# crazy:
+import wehjit
+wehjit.builtins._skip_pygments = True
+wehjit.init_builtins()
+
from ipalib.backend import Executioner
from ipalib.request import destroy_context
from ipaserver.rpcserver import extract_query
--
1.6.3.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] jderose 042 output_params
As discussed with Rob on IRC, this patch changes the
Command.get_output_params() method so that by default your
Command.output_params will be the same as your Command.params.
This make the behavior similar to how Method.get_output_params() fills
your Method.params with the params in the corresponding Object.params.
If you have args or options that you *don't* want in output_params, add
the 'no_output' flag, like this:
Str('foo', flags=['no_output'])
This is similar to the 'no_create', 'no_update', and 'no_search' flags
for Method plugins.
If you need output that wont be in your args or options, add them in a
`has_output_params` tuple, like this:
has_output_params = (
'bar',
'baz',
)
I'll add docstrings in another patch, but this is blocking Rob, so I
made it a quickie.
>From 0ff22e4a0fa946e6011e77554fd55f005d40d8d2 Mon Sep 17 00:00:00 2001
From: Jason Gerard DeRose
Date: Wed, 10 Feb 2010 21:15:47 -0700
Subject: [PATCH] Command.output_params not contains params in Command.params
---
ipalib/frontend.py |7 +++
tests/test_ipalib/test_frontend.py | 27 +++
2 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/ipalib/frontend.py b/ipalib/frontend.py
index 1cc2ea2..0abb35b 100644
--- a/ipalib/frontend.py
+++ b/ipalib/frontend.py
@@ -810,6 +810,13 @@ class Command(HasParam):
def get_output_params(self):
for param in self._get_param_iterable('output_params', verb='has'):
yield param
+if self.params is None:
+return
+for param in self.params():
+if 'no_output' in param.flags:
+continue
+yield param
+
def output_for_cli(self, textui, output, *args, **options):
if not isinstance(output, dict):
diff --git a/tests/test_ipalib/test_frontend.py b/tests/test_ipalib/test_frontend.py
index b5ecd05..7c67d6c 100644
--- a/tests/test_ipalib/test_frontend.py
+++ b/tests/test_ipalib/test_frontend.py
@@ -28,6 +28,7 @@ from ipalib.constants import TYPE_ERROR
from ipalib.base import NameSpace
from ipalib import frontend, backend, plugable, errors, parameters, config
from ipalib import output
+from ipalib.parameters import Str
def test_RULE_FLAG():
assert frontend.RULE_FLAG == 'validation_rule'
@@ -654,6 +655,32 @@ class test_Command(ClassChecker):
'nested', 'Subclass', 'world', 4, dict, tuple, nope
)
+def test_get_output_params(self):
+"""
+Test the `ipalib.frontend.Command.get_output_params` method.
+"""
+class example(self.cls):
+has_output_params = (
+'one',
+'two',
+'three',
+)
+takes_args = (
+'foo',
+)
+takes_options = (
+Str('bar', flags='no_output'),
+'baz',
+)
+
+inst = example()
+assert list(inst.get_output_params()) == ['one', 'two', 'three']
+inst.finalize()
+assert list(inst.get_output_params()) == [
+'one', 'two', 'three', inst.params.foo, inst.params.baz
+]
+assert list(inst.output_params) == ['one', 'two', 'three', 'foo', 'baz']
+
class test_LocalOrRemote(ClassChecker):
"""
--
1.6.3.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH[ 376 fix ipa-join segfault
On Tue, 2010-02-09 at 23:04 -0500, Rob Crittenden wrote: > Make sure incoming data isn't NULL before trying to strdup() it. Bad > things happen otherwise. > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 375 selinux fix for CRLs
On Tue, 2010-02-09 at 17:25 -0500, Rob Crittenden wrote: > Fix an SELinux permissions problem when retrieving CRLs via Apache. > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] Bring back old outputting functionality
On Wed, 2010-02-10 at 10:30 -0500, Rob Crittenden wrote: > Pavel Zuna wrote: > > What I'm saying is that the Env object stores all strings as str and the > > env command uses the same output_for_cli as LDAP commands, that only use > > str for binary. So, we either need to override output_for_cli or switch > > to unicode in Env. > > Not exactly sure what to do here though using unicode seems like the > best route. > Yes, we should store the env as `unicode`... this is something I've been meaning to do. I originally left them as `str` because I was having problems using `unicode` somewhere (maybe it was python-ldap), but we should just fix this special case in the appropriate place. As I wrote the latest Env version (using Martins work as a starting point), I can make this change. Should this be post-alpha? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] jderose 041 Fix logging
On Mon, 2010-02-08 at 11:38 -0500, Rob Crittenden wrote: > Jason Gerard DeRose wrote: > > I lied one, more. > > > > Rob, I see you changed how the log level on the root logger is set in > > API.bootstrap()... unfortunately, under the server and CLI, the result > > is that the root logger always stays at its default level of > > logging.WARNING, so none of our info() nor debug() messages are going > > into the server log nor out to stderr (even with --debug). > > > > My solution is to unconditionally set the root logger to logging.DEBUG, > > the most verbose we use, and then configure the levels on individual > > handlers as appropriate (which we already do). > > > > Rob, I know you make this change because of problems with logging from > > the installer, so can you see if still works the way you want it to with > > this patch? By the way, are you setting up your own logging handler in > > the installer, or using the ones configured in API.bootstrap()? > > > > Anyway, we really shouldn't release our alpha with broken logging. Not > > nice to our brave and helpful testers. ;) > > Jason, I think we can instead test for len(log.handlers) == 0 to > determine if we have already configured a file handler for it. Can you > confirm this? So if there are no handlers configured we set the log > level, otherwise we skip it. > > rob Yep, that fixes it. Updated patch attached (replaces my original 041 patch). >From d441e08c356f5003dafef409a9dc059b75bf4f3d Mon Sep 17 00:00:00 2001 From: Jason Gerard DeRose Date: Tue, 9 Feb 2010 04:57:23 -0700 Subject: [PATCH] Fix logging in CLI and server (take 2) --- ipalib/plugable.py | 15 ++- 1 files changed, 10 insertions(+), 5 deletions(-) diff --git a/ipalib/plugable.py b/ipalib/plugable.py index 6b2c6f7..4473409 100644 --- a/ipalib/plugable.py +++ b/ipalib/plugable.py @@ -365,11 +365,16 @@ class API(DictProxy): self.env._finalize_core(**dict(DEFAULT_CONFIG)) log = logging.getLogger() object.__setattr__(self, 'log', log) -if log.level == logging.NOTSET: -if self.env.debug: -log.setLevel(logging.DEBUG) -else: -log.setLevel(logging.INFO) + +# If logging has already been configured somewhere else (like in the +# installer), don't add handlers or change levels: +if len(log.handlers) > 0: +return + +if self.env.debug: +log.setLevel(logging.DEBUG) +else: +log.setLevel(logging.INFO) # Add stderr handler: stderr = logging.StreamHandler() -- 1.6.3.3 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 371 add status to ipactl
On Wed, 2010-02-03 at 16:33 -0500, Rob Crittenden wrote: > We had an RFE for adding status to ipactl, seemed like low-hanging fruit > (bug 503437) > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 368 remove some duplicate code
On Mon, 2010-02-08 at 11:03 -0500, Rob Crittenden wrote: > John Dennis wrote: > > On 02/02/2010 10:56 PM, Rob Crittenden wrote: > >> Move the dogtag HTTP and HTTPS request functions to a common library to > >> remove duplication. > >> > >> I'm next planning on moving the XML parsing code into ipapython/dogtag > >> because that is needed by the installer as well to identify errors. This > >> is going to be quite a bit messier I think. > > > > There are a couple of minor things which need cleaning up. > > > > The new functions https_request and http_request are not general request > > mechanisms because the request type is hardcoded to POST and the headers > > are hardcoded as well. We need to either change the names to https_post > > and http_post -or- add parameters specifying the request type and > > headers. POST is specialized enough and called often enough I think the > > first option is best, just rename the function to what it actually is, a > > post request. > > > > The logging statements still refer to the old function names, they > > should be updated to match the name of the function. > > > > If all you do is just edit the names I don't think you need to repost > > the patch, I'll ACK it now. > > > > Yeah, I had the same thoughts on the naming. I decided to go with them > since the context is within dogtag and not a general HTTP/S client. I'm > ok with renaming them again for clarity/maintainability. > > rob ack. pushed to master. We can rename these functions for greater clarity in a subsequent patch, but in the mean time we should move forward with this code consolidation. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 361 fix cert tests
On Thu, 2010-01-28 at 16:18 -0500, Rob Crittenden wrote: > This fixes some problems with the cert plugin tests. > > - It checks to see if a self-signed CA is available in ~/.ipa/alias. If > not the tests are skipped > - Be a bit smarter about cleaning up by moving it to a separate test > - This relies on patch the service fix in 360. Some binary certs were > being decoded as base64 resulting in an unparsable cert for the ASN.1 > parser. > > I also added a bit of documentation on how to set up the self-signed CA. > It is a one-time thing. > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] jderose 041 Fix logging
On Mon, 2010-02-08 at 11:38 -0500, Rob Crittenden wrote: > Jason Gerard DeRose wrote: > > I lied one, more. > > > > Rob, I see you changed how the log level on the root logger is set in > > API.bootstrap()... unfortunately, under the server and CLI, the result > > is that the root logger always stays at its default level of > > logging.WARNING, so none of our info() nor debug() messages are going > > into the server log nor out to stderr (even with --debug). > > > > My solution is to unconditionally set the root logger to logging.DEBUG, > > the most verbose we use, and then configure the levels on individual > > handlers as appropriate (which we already do). > > > > Rob, I know you make this change because of problems with logging from > > the installer, so can you see if still works the way you want it to with > > this patch? By the way, are you setting up your own logging handler in > > the installer, or using the ones configured in API.bootstrap()? > > > > Anyway, we really shouldn't release our alpha with broken logging. Not > > nice to our brave and helpful testers. ;) > > Jason, I think we can instead test for len(log.handlers) == 0 to > determine if we have already configured a file handler for it. Can you > confirm this? So if there are no handlers configured we set the log > level, otherwise we skip it. > > rob The logging levels range in numeric value from 0 (NOTSET) to 50 (CRITICAL). Setting the the root logger to log level DEBUG (10) doesn't actually change the effective level (in our case) because the effective level at a given handler is max(logger.level, handler.level). API.bootstrap() by default sets the stderr handler to WARNING (30) and the file handler to INFO (20). --verbose sets the stderr handler to INFO. --debug sets both the stderr and file handlers to DEBUG (10). Anyway, would it be possible to have the installer use the same file handler that API.bootstrap() sets up? You can change what log file is used like this: api.env.log = '/the/installer/log.txt' api.bootstrap() api.finalize() Would that work? I'm open to tweaking API.bootstrap() as needed so we can have a uniform logging setup. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] jderose 041 Fix logging
I lied one, more. Rob, I see you changed how the log level on the root logger is set in API.bootstrap()... unfortunately, under the server and CLI, the result is that the root logger always stays at its default level of logging.WARNING, so none of our info() nor debug() messages are going into the server log nor out to stderr (even with --debug). My solution is to unconditionally set the root logger to logging.DEBUG, the most verbose we use, and then configure the levels on individual handlers as appropriate (which we already do). Rob, I know you make this change because of problems with logging from the installer, so can you see if still works the way you want it to with this patch? By the way, are you setting up your own logging handler in the installer, or using the ones configured in API.bootstrap()? Anyway, we really shouldn't release our alpha with broken logging. Not nice to our brave and helpful testers. ;) >From 8353bce4e6fc9ffce8dbee5dfeca06eb1ba34866 Mon Sep 17 00:00:00 2001 From: Jason Gerard DeRose Date: Mon, 8 Feb 2010 06:04:47 -0700 Subject: [PATCH] Fix logging in CLI and server --- ipalib/plugable.py | 11 ++- 1 files changed, 6 insertions(+), 5 deletions(-) diff --git a/ipalib/plugable.py b/ipalib/plugable.py index 51c09fc..d73894b 100644 --- a/ipalib/plugable.py +++ b/ipalib/plugable.py @@ -382,11 +382,12 @@ class API(DictProxy): self.env._finalize_core(**dict(DEFAULT_CONFIG)) log = logging.getLogger() object.__setattr__(self, 'log', log) -if log.level == logging.NOTSET: -if self.env.debug: -log.setLevel(logging.DEBUG) -else: -log.setLevel(logging.INFO) + +# By default log.level is WARNING, so instead of testing against NOSET +# here (as we previously did), we'll just set the level of the root +# logger to the lowest level we use, DEBUG. Set the level as approprate +# on individual handlers. +log.setLevel(logging.DEBUG) # Add stderr handler: stderr = logging.StreamHandler() -- 1.6.3.3 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] jderose 040
This is (knock on wood) a low risk change that adds an Object.label
attribute that is exposed through the webUI, cleans up some UI
funkiness.
I was accidentally making post-alpha changes in the same branch as my
error and other string cleanups, which is taking me a bit to sort out,
so this is the last patch from me till after the alpha.
>From 0446b7858c533d5c15e423c540bdbec768fe6333 Mon Sep 17 00:00:00 2001
From: Jason Gerard DeRose
Date: Mon, 8 Feb 2010 05:03:28 -0700
Subject: [PATCH] Add Object.label class attribute, enable in webUI
---
ipalib/frontend.py |3 +++
ipalib/plugable.py | 17 +
ipalib/plugins/aci.py |3 +++
ipalib/plugins/automount.py|6 +-
ipalib/plugins/dns.py |4 +++-
ipalib/plugins/group.py|2 ++
ipalib/plugins/hbac.py |3 +++
ipalib/plugins/host.py |2 ++
ipalib/plugins/hostgroup.py|2 ++
ipalib/plugins/netgroup.py |4 +++-
ipalib/plugins/rolegroup.py|2 ++
ipalib/plugins/service.py |2 ++
ipalib/plugins/taskgroup.py|2 ++
ipalib/plugins/user.py |2 ++
ipalib/text.py | 20 +---
ipawebui/engine.py |2 +-
tests/test_ipalib/test_text.py | 19 +++
17 files changed, 88 insertions(+), 7 deletions(-)
diff --git a/ipalib/frontend.py b/ipalib/frontend.py
index 1cc2ea2..8a0b51d 100644
--- a/ipalib/frontend.py
+++ b/ipalib/frontend.py
@@ -1103,6 +1103,9 @@ class Property(Attribute):
def __init__(self):
super(Property, self).__init__()
+# FIXME: This is a hack till Param.label is updated to require a
+# LazyText instance:
+self.label = None
self.rules = tuple(
sorted(self.__rules_iter(), key=lambda f: getattr(f, '__name__'))
)
diff --git a/ipalib/plugable.py b/ipalib/plugable.py
index 6b2c6f7..51c09fc 100644
--- a/ipalib/plugable.py
+++ b/ipalib/plugable.py
@@ -37,9 +37,13 @@ import optparse
import errors
from config import Env
import util
+import text
from base import ReadOnly, NameSpace, lock, islocked, check_name
from constants import DEFAULT_CONFIG, FORMAT_STDERR, FORMAT_FILE
+# FIXME: Updated constants.TYPE_ERROR to use this clearer format from wehjit:
+TYPE_ERROR = '%s: need a %r; got a %r: %r'
+
class SetProxy(ReadOnly):
"""
@@ -155,6 +159,8 @@ class Plugin(ReadOnly):
Base class for all plugins.
"""
+label = None
+
def __init__(self):
self.__api = None
cls = self.__class__
@@ -177,6 +183,17 @@ class Plugin(ReadOnly):
self.name, name, getattr(self, name))
)
setattr(self, name, getattr(log, name))
+if self.label is None:
+self.label = text.FixMe(self.name + '.label')
+if not isinstance(self.label, text.LazyText):
+raise TypeError(
+TYPE_ERROR % (
+self.fullname + '.label',
+text.LazyText,
+type(self.label),
+self.label
+)
+)
def __get_api(self):
"""
diff --git a/ipalib/plugins/aci.py b/ipalib/plugins/aci.py
index ea5b3e4..a722d76 100644
--- a/ipalib/plugins/aci.py
+++ b/ipalib/plugins/aci.py
@@ -197,6 +197,9 @@ class aci(Object):
"""
ACI object.
"""
+
+label = _('ACIs')
+
takes_params = (
Str('aciname',
cli_name='name',
diff --git a/ipalib/plugins/automount.py b/ipalib/plugins/automount.py
index 051f6d0..56f2c0b 100644
--- a/ipalib/plugins/automount.py
+++ b/ipalib/plugins/automount.py
@@ -88,6 +88,7 @@ from ipalib import api, errors
from ipalib import Object, Command
from ipalib import Flag, Str
from ipalib.plugins.baseldap import *
+from ipalib import _, ngettext
class automountlocation(LDAPObject):
@@ -224,6 +225,8 @@ class automountmap(LDAPObject):
),
)
+label = _('Automount Maps')
+
api.register(automountmap)
@@ -312,6 +315,8 @@ class automountkey(LDAPObject):
),
)
+label = _('Automount Keys')
+
api.register(automountkey)
@@ -381,4 +386,3 @@ class automountkey_show(LDAPRetrieve):
"""
api.register(automountkey_show)
-
diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py
index b31ded6..49d073e 100644
--- a/ipalib/plugins/dns.py
+++ b/ipalib/plugins/dns.py
@@ -66,6 +66,7 @@ import time
from ipalib import api, crud, errors, output
from ipalib import Object, Command
from ipalib import Flag, Int, Str, StrEnum
+from ipalib import _, ngettext
# parent DN
_zone_container_dn = api.env.container_dns
@@ -110,6 +111,8 @@ def _get_record_dn(ldap, zone, idnsname):
class dns(Object):
[Freeipa-devel] FYI: python-wehjit and python-assets in Fedora 11
python-wehjit 0.2.0 and python-assets 0.1.1 have landed in Fedora 11. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] jderose 039 Add support for the 'no_create', 'no_update', and 'no_search' Param flags
This feature will help restore some missing CLI functionality. It's
also a step toward making sure all our attribute metadata is plugable
with a per-attribute granularity.
See the new module docstring in ipalib/crud.py for details.
>From b8a67200ba1b2b7ce843dda7e3765bc921f03dcb Mon Sep 17 00:00:00 2001
From: Jason Gerard DeRose
Date: Thu, 4 Feb 2010 09:52:33 -0700
Subject: [PATCH] Add support for the 'no_create', 'no_update', and 'no_search' Param flags
---
ipalib/crud.py | 112 ++-
tests/test_ipalib/test_crud.py |8 ++-
2 files changed, 114 insertions(+), 6 deletions(-)
diff --git a/ipalib/crud.py b/ipalib/crud.py
index 173fefc..77c97f3 100644
--- a/ipalib/crud.py
+++ b/ipalib/crud.py
@@ -16,14 +16,114 @@
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+
"""
Base classes for standard CRUD operations.
+
+These base classes are for `Method` plugins that provide standard
+Create, Retrieve, Updated, and Delete operations (CRUD) for their corresponding
+`Object` plugin. In particuar, these base classes provide logic to
+automatically create the plugin args and options by inspecting the params on
+their corresponding `Object` plugin. This provides a single point of definition
+for LDAP attributes and enforces a simple, consistent API for CRUD operations.
+
+For example, say we want CRUD operations on a hypothetical "user" entry. First
+we need an `Object` plugin:
+
+>>> from ipalib import Object, Str
+>>> class user(Object):
+... takes_params = (
+... Str('login', primary_key=True),
+... Str('first'),
+... Str('last'),
+... Str('ipauniqueid', flags=['no_create', 'no_update']),
+... )
+...
+
+Next we need `Create`, `Retrieve`, `Updated`, and `Delete` plugins, and
+optionally a `Search` plugin. For brevity, we'll just define `Create` and
+`Retrieve` plugins:
+
+>>> from ipalib import crud
+>>> class user_add(crud.Create):
+... pass
+...
+>>> class user_show(crud.Retrieve):
+... pass
+...
+
+Now we'll register the plugins and finalize the `plugable.API` instance:
+
+>>> from ipalib import create_api
+>>> api = create_api()
+>>> api.register(user)
+>>> api.register(user_add)
+>>> api.register(user_show)
+>>> api.finalize()
+
+First, notice that our ``user`` `Object` has the params we defined with the
+``takes_params`` tuple:
+
+>>> list(api.Object.user.params)
+['login', 'first', 'last', 'ipauniqueid']
+>>> api.Object.user.params.login
+Str('login', primary_key=True)
+
+Although we defined neither ``takes_args`` nor ``takes_options`` for our
+``user_add`` plugin, the `Create` base class automatically generated them for
+us:
+
+>>> list(api.Command.user_add.args)
+['login']
+>>> list(api.Command.user_add.options)
+['first', 'last']
+
+Notice that ``'ipauniqueid'`` isn't included in the options for our ``user_add``
+plugin. This is because of the ``'no_create'`` flag we used when defining the
+``ipauniqueid`` param. Often times there are LDAP attributes that are
+automatically created by the server and therefor should not be supplied as an
+option to the `Create` plugin. Often these same attributes shouldn't be
+update-able either, in which case you can also supply the ``'no_update'`` flag,
+as we did with our ``ipauniqueid`` param. Lastly, you can also use the ``'no_search'`` flag for attributes that shouldn't be search-able (because, for
+example, the attribute isn't indexed).
+
+As with our ``user_add` plugin, we defined neither ``takes_args`` nor
+``takes_options`` for our ``user_show`` plugin; instead the `Retrieve` base
+class created them for us:
+
+>>> list(api.Command.user_show.args)
+['login']
+>>> list(api.Command.user_show.options)
+[]
+
+As you can see, `Retrieve` plugins take a single argument (the primary key) and
+no options. If needed, you can still specify options for your `Retrieve` plugin
+with a ``takes_options`` tuple.
+
+Flags like ``'no_create'`` remove LDAP attributes from those that can be
+supplied as *input* to a `Method`, but they don't effect the attributes that can
+be returned as *output*. Regardless of what flags have been used, the output
+entry (or list of entries) can contain all the attributes defined on the
+`Object` plugin (in our case, the above ``user.params``).
+
+For example, compare ``user.params`` with ``user_add.output_params`` and
+``user_show.o
Re: [Freeipa-devel] Implementing --all as a global option
On Thu, 2010-02-04 at 15:55 +0100, Pavel Zuna wrote:
> Pavel Zuna wrote:
> > I've run into a little problem when implementing --all as a global
> > option. The problem is that I can't see a way, to propagate it to the
> > server side. Plugins could always retrieve all attributes and the client
> > would choose what to display, but that would be very ineffective
> > (especially when executing *-find commands).
> >
> > Either we add a way to pass additional information over XML-RPC (command
> > independent flags) or we go back to non-global --all options.
> >
> > Thoughts?
> >
> > Pavel
> >
>
> Hey Jason,
> we talked about this a bit on Tuesday meeting and you mentioned having some
> plans about extending the information being transmitted over XML-RPC. I
> remember
> something about "extras" and "cookies", but that's pretty much it. If you
> could
> just summarize what you had in mind, I'll start figuring stuff out and
> implementing it.
>
> Pavel
>
Sure. XML-RPC arguments are supplied in a single params list (this is
the XML-RPC spec, not an IPA specific thing). Right now our calling
signature is:
[arg1, arg2, ..., argN, ]
We make an educated guess as to whether the last argument is in fact an
options dict based on its type. This works for now as the parameter
system doesn't yet support compound dict values (it only supports
compound list values, which you create using multivalue=True). I'm sure
it's only a matter of time till we need compound dict values, so we
really need to change the XML-RPC signature before we release v2 and
become obligated to stay backward compatible.
I propose we change the signature to:
[args, options, extra]
Where:
`args` is a list of arguments for the command (can be empty)
`options` is a dict of options for the command (can be empty)
`extra` is a dict of extensible special variables (can be empty)
We really need the `extra` dict because a lot of XML-RPC libraries don't
make it especially easy (if even possible) to set HTTP headers (the
Python implementation included). So my main use case for `extra` is to
pass things like cookies and the locale when they can't be supplied in
the HTTP headers. Global options like --all are also a great use case
for `extra`, and I'm sure we'll have more down the road. If something
like the locale is present in both the HTTP headers and in `extra`, the
value in `extra` should take precedence.
We should allow `extra`, `options`, and `args` to be missing in the call
so that all of these would be valid calls:
[] # Implies [[], {}, {}]
[['foo']] # Implies [['foo'], {}, {}]
[[], {'foo': 'bar'}] # Implies [[], {'foo': 'bar'}, {}]
[[], {}, {'foo': 'bar'}]
Make sense? Does anyone disagree with this approach, have suggestions?
The JSON-RPC call signature is already [args, options]... and I'll
change this to [args, options, extra] shorty after the alpha release.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] jderose 038 Fix ipalib doctest
This patch fixes doctests in ipalib/__init__.py that were broken by
Rob's "364 base64-encode binary data..." patch.
This patch also removes the unneeded use of textui.encode_binary() in
the textui.print_keyval() method. repr('cannot print me') will escape
non-ascii characters using the Python \xHH hexadecimal literal
notation... so the output will be terminal safe even without base64
encoding.
textui.print_keyval() isn't being used at the moment, AFAIK, but it's
indented for developer-centric debugging type commands where printing
the repr() is helpful.
P.S.: I think it might have got lost in the shuffle, but could someone
ack my 037 patch? With 037 and this patch, all the unit tests should be
working again.
>From 0a6d49498c59337e66685102bfd03a822f037910 Mon Sep 17 00:00:00 2001
From: Jason Gerard DeRose
Date: Wed, 3 Feb 2010 04:03:58 -0700
Subject: [PATCH] Fixed doctests for ipalib package docstring; fixed unneeded use of textui.encode_binary() in textui.print_keyval()
---
ipalib/__init__.py | 20 ++--
ipalib/cli.py |4 +++-
2 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/ipalib/__init__.py b/ipalib/__init__.py
index 83956e1..beaf0ab 100644
--- a/ipalib/__init__.py
+++ b/ipalib/__init__.py
@@ -584,9 +584,9 @@ For example, say we setup a command like this:
...
... def execute(self, key, **options):
... items = dict(
-... fruit='apple',
-... pet='dog',
-... city='Berlin',
+... fruit=u'apple',
+... pet=u'dog',
+... city=u'Berlin',
... )
... if key in items:
... return dict(result=items[key])
@@ -627,9 +627,9 @@ through the ``ipa`` script basically will do the following:
---
show-items:
---
- city = 'Berlin'
- fruit = 'apple'
- pet = 'dog'
+ city = u'Berlin'
+ fruit = u'apple'
+ pet = u'dog'
---
3 items
---
@@ -641,9 +641,9 @@ Similarly, calling it with ``reverse=True`` would result in the following:
---
show-items:
---
- pet = 'dog'
- fruit = 'apple'
- city = 'Berlin'
+ pet = u'dog'
+ fruit = u'apple'
+ city = u'Berlin'
--
3 items (in reverse order)
--
@@ -652,7 +652,7 @@ Lastly, providing a ``key`` would result in the following:
>>> result = api.Command.show_items(u'city')
>>> api.Command.show_items.output_for_cli(textui, result, 'city', reverse=False)
-city = 'Berlin'
+city = u'Berlin'
See the `ipalib.cli.textui` plugin for a description of its methods.
diff --git a/ipalib/cli.py b/ipalib/cli.py
index b398094..124b625 100644
--- a/ipalib/cli.py
+++ b/ipalib/cli.py
@@ -244,7 +244,9 @@ class textui(backend.Backend):
Also see `textui.print_indented`.
"""
for (key, value) in rows:
-self.print_indented('%s = %r' % (key, self.encode_binary(value)), indent)
+# Note that self.encode_binary(value) isn't needed as repr(value)
+# will escape an `str` using \xHH hexidicimal:
+self.print_indented('%s = %r' % (key, value), indent)
def print_attribute(self, attr, value, indent=1, one_value_per_line=True):
"""
--
1.6.3.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Remove (un)wrap_binary_data cruft from */ipautil.py
On Thu, 2010-01-28 at 12:35 -0500, John Dennis wrote: > Remove SAFE_STRING_PATTERN, safe_string_re, needs_base64(), > wrap_binary_data(), unwrap_binary_data() from both instances > of ipautil.py. This code is no longer in use and the > SAFE_STRING_PATTERN regular expression string was causing xgettext > to abort because it wasn't a valid ASCII string. > --- > ipapython/ipautil.py | 62 > -- > ipaserver/ipautil.py | 62 > -- > 2 files changed, 0 insertions(+), 124 deletions(-) Patch looks good, but I get an error when trying to apply with `git am`: Patch does not have a valid e-mail address. Did you figure out your attachment problem? For what it's worth, I prepare patches with `git format-patch -1` and then manually attach the patch to an email (I'm using Evolution). Could you submit this again? Or if someone with more git experience could instruct me as to a work-around. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 355 allow named to use ldapi
On Wed, 2010-01-27 at 14:53 -0500, Rob Crittenden wrote: > Add SELinux rules so named can communicate to the DS over ldapi. > > This should fix the installation error when --setup-dns is set and > SELinux is enforcing. > > rob I'm trying to test this out, but I'm not sure what I need to enter for the DNS forwarder: """ Enter IP address for a DNS forwarder (empty to stop): """ Any advice? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Fix File parameter validation when prompting.
On Wed, 2010-01-27 at 17:53 +0100, Pavel Zuna wrote: > cli.prompt_interactively now loads files before validating the parameter > value. > It also populates a list of already loaded files, so that cli.load_files > knows > when a parameter already contains the file contents. > > Fix #557163 > > Pavel ack. This looks reasonable to me, but I'd really like you to add some tests for this, especially testing that it works correctly for a command with multiple File params. Rob and John, do you see any problems with this approach? Does this address the needs of the cert plugins? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] jderose 037 Fix broken unit tests
This patch gets (almost) all the XML-RPC tests working again under Fedora12. Some may not pass under Fedora11 due to 389 schema changes, but Fedora12 should be our primary test target at this point, IHMO. Does anyone disagree? 3 cert tests still fail, but I'm not familiar enough with the cert plugins to confidently decide whether the tests need to be updated or whether something is broken. Rob or John, could you take a look at these when you get a chance? We really need to get strict about patches with regard to tests. If a patch breaks a test, the test needs to be updated in that same patch (or if the test is correct, the code needs to be updated). If a patch introduces new functionality, it must be accompanied by tests. Rob and Pavel, I'm looking at you. If tests no passy, no acky-acky. ;) I know I've been at fault too, but I've already scolded myself off-list. >From b7c5a456693cae3d6ecbb717114c5a6bbf205acd Mon Sep 17 00:00:00 2001 From: Jason Gerard DeRose Date: Wed, 27 Jan 2010 07:16:06 -0700 Subject: [PATCH] Fix broken XML-RPC tests --- tests/test_xmlrpc/objectclasses.py |1 + tests/test_xmlrpc/test_group_plugin.py |6 -- tests/test_xmlrpc/test_host_plugin.py | 20 ++-- tests/test_xmlrpc/test_hostgroup_plugin.py | 17 + tests/test_xmlrpc/test_rolegroup_plugin.py |8 +--- tests/test_xmlrpc/test_taskgroup_plugin.py |9 ++--- tests/test_xmlrpc/test_user_plugin.py |8 ++-- 7 files changed, 41 insertions(+), 28 deletions(-) diff --git a/tests/test_xmlrpc/objectclasses.py b/tests/test_xmlrpc/objectclasses.py index 5f95cd7..857147d 100644 --- a/tests/test_xmlrpc/objectclasses.py +++ b/tests/test_xmlrpc/objectclasses.py @@ -29,6 +29,7 @@ user = [ u'inetuser', u'posixaccount', u'krbprincipalaux', +u'krbticketpolicyaux', u'radiusprofile', u'ipaobject', ] diff --git a/tests/test_xmlrpc/test_group_plugin.py b/tests/test_xmlrpc/test_group_plugin.py index a6d98f6..b794f44 100644 --- a/tests/test_xmlrpc/test_group_plugin.py +++ b/tests/test_xmlrpc/test_group_plugin.py @@ -110,6 +110,7 @@ class test_group(Declarative): ), expected=dict( result=dict( +cn=[group1], description=[u'New desc 1'], ), summary=u'Modified group "testgroup1"', @@ -143,8 +144,8 @@ class test_group(Declarative): result=dict( cn=[group1], description=[u'New desc 1'], -objectclass=objectclasses.group + [u'posixgroup'], -ipauniqueid=[fuzzy_uuid], +#objectclass=objectclasses.group + [u'posixgroup'], +#ipauniqueid=[fuzzy_uuid], gidnumber=[fuzzy_digits], ), value=group1, @@ -261,6 +262,7 @@ class test_group(Declarative): ), expected=dict( result=dict( +cn=[group2], description=[u'New desc 2'], ), summary=u'Modified group "testgroup2"', diff --git a/tests/test_xmlrpc/test_host_plugin.py b/tests/test_xmlrpc/test_host_plugin.py index 167481a..4127663 100644 --- a/tests/test_xmlrpc/test_host_plugin.py +++ b/tests/test_xmlrpc/test_host_plugin.py @@ -73,14 +73,13 @@ class test_host(Declarative): summary=u'Added host "%s"' % fqdn1, result=dict( dn=dn1, -cn=[fqdn1], # FIXME: we should only return fqdn fqdn=[fqdn1], description=[u'Test host 1'], -localityname=[u'Undisclosed location 1'], -krbprincipalname=[u'host/%...@%s' % (fqdn1, api.env.realm)], -serverhostname=[u'testhost1'], +#localityname=[u'Undisclosed location 1'], +#krbprincipalname=[u'host/%...@%s' % (fqdn1, api.env.realm)], +#serverhostname=[u'testhost1'], objectclass=objectclasses.host, -managedby=[dn1], +#managedby=[dn1], ipauniqueid=[fuzzy_uuid], ), ), @@ -109,7 +108,7 @@ class test_host(Declarative): dn=dn1, fqdn=[fqdn1], description=[u'Test host 1'], -localityname=[u'Undisclosed location 1'], +#localityname=[u'Undisclosed location 1'], ), ), ), @@ -130,7 +129,7 @@ c
[Freeipa-devel] [PATCH] jderose 036 Remove PluginProxy hold-overs
This patch removes some cruft left over from when we were still using my
ill-fated PluginProxy to wrap Plugin instances. This patch:
1. Removes special __public__ class attribute from Plugin and its
descendants
2. Removes special __proxy__ class attribute from same
3. Removes the Plugin.implements() and Plugin.implemented_by()
methods
4. Updates unit-tests where they expected any of the above
None of these features were being used except by the unit-tests, so this
should be a very safe change.
>From f46c45293b8f44a3a0a54e326d1d0c3edd7b3769 Mon Sep 17 00:00:00 2001
From: Jason Gerard DeRose
Date: Wed, 27 Jan 2010 05:59:09 -0700
Subject: [PATCH] Remove __public__ and __proxy__ hold-overs from Plugin class
---
ipalib/backend.py |2 -
ipalib/frontend.py | 35
ipalib/plugable.py | 73 +-
tests/test_ipalib/test_backend.py |1 -
tests/test_ipalib/test_frontend.py | 16 --
tests/test_ipalib/test_plugable.py | 101
6 files changed, 1 insertions(+), 227 deletions(-)
diff --git a/ipalib/backend.py b/ipalib/backend.py
index 8aa0578..03f4ce3 100644
--- a/ipalib/backend.py
+++ b/ipalib/backend.py
@@ -32,8 +32,6 @@ class Backend(plugable.Plugin):
Base class for all backend plugins.
"""
-__proxy__ = False # Backend plugins are not wrapped in a PluginProxy
-
class Connectible(Backend):
"""
diff --git a/ipalib/frontend.py b/ipalib/frontend.py
index 2c1168a..1cc2ea2 100644
--- a/ipalib/frontend.py
+++ b/ipalib/frontend.py
@@ -359,20 +359,6 @@ class Command(HasParam):
ipalib.frontend.my_command()
"""
-__public__ = frozenset((
-'get_default',
-'convert',
-'normalize',
-'validate',
-'execute',
-'__call__',
-'args',
-'options',
-'params',
-'params_2_args_options',
-'args_options_2_params',
-'output_for_cli',
-))
takes_options = tuple()
takes_args = tuple()
args = None
@@ -875,16 +861,6 @@ class LocalOrRemote(Command):
class Object(HasParam):
-__public__ = frozenset((
-'backend',
-'methods',
-'properties',
-'params',
-'primary_key',
-'params_minus_pk',
-'params_minus',
-'get_dn',
-))
backend = None
methods = None
properties = None
@@ -1011,10 +987,6 @@ class Attribute(Plugin):
only the base class for the `Method` and `Property` classes. Also see
the `Object` class.
"""
-__public__ = frozenset((
-'obj',
-'obj_name',
-))
__obj = None
def __init__(self):
@@ -1112,7 +1084,6 @@ class Method(Attribute, Command):
attribute-to-object association. Also see the `Object` and the
`Property` classes.
"""
-__public__ = Attribute.__public__.union(Command.__public__)
extra_options_first = False
extra_args_first = False
@@ -1125,12 +1096,6 @@ class Method(Attribute, Command):
class Property(Attribute):
-__public__ = frozenset((
-'rules',
-'param',
-'type',
-)).union(Attribute.__public__)
-
klass = Str
default = None
default_from = None
diff --git a/ipalib/plugable.py b/ipalib/plugable.py
index ecccb79..b6ba732 100644
--- a/ipalib/plugable.py
+++ b/ipalib/plugable.py
@@ -154,11 +154,9 @@ class Plugin(ReadOnly):
"""
Base class for all plugins.
"""
-__public__ = frozenset()
-__proxy__ = True
-__api = None
def __init__(self):
+self.__api = None
cls = self.__class__
self.name = cls.__name__
self.module = cls.__module__
@@ -189,75 +187,6 @@ class Plugin(ReadOnly):
return self.__api
api = property(__get_api)
-@classmethod
-def implements(cls, arg):
-"""
-Return True if this class implements ``arg``.
-
-There are three different ways this method can be called:
-
-With a argument, e.g.:
-
->>> class base(Plugin):
-... __public__ = frozenset(['attr1', 'attr2'])
-...
->>> base.implements('attr1')
-True
->>> base.implements('attr2')
-True
->>> base.implements('attr3')
-False
-
-With a argument, e.g.:
-
-With any object that has a `__public__` attribute that is
-, e.g.:
-
-Unlike ProxyTarget.implemented_by(), this returns an abstrac
Re: [Freeipa-devel] Why do we have so much duplicated code?
On Tue, 2010-01-26 at 18:55 -0500, John Dennis wrote: > I constantly find identical code spread across multiple files. Is there > a reason for this code duplication? (Perhaps trying to keep import name > spaces isolated?) > > It seems to me code duplication is bad software practice for obvious > reasons. > > If there isn't a compelling design justification for the duplication can > we start moving some of this stuff to common libraries? John, where's the duplication you're talking about? We know there's a lot of lingering duplication between the legacy code from v1 (ipapython, the installer) and the new plugable v2 code (ipalib, ipaserver). We've slowly been migrating away from this legacy code, but the process obviously isn't yet complete. AFAIK, there isn't really any duplication within the v2 code itself, but if you've spotted some, I'd like to know about it. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] jderose 035 Update spec to require python-wehjit >= 0.2.0
The webui now requires wehjit 0.2.0. >From 6f7aa9f687de72c16ef9b0883a0f2de8b2089a3d Mon Sep 17 00:00:00 2001 From: Jason Gerard DeRose Date: Wed, 27 Jan 2010 00:44:00 -0700 Subject: [PATCH] Update spec to require python-wehjit >= 0.2.0 --- ipa.spec.in |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/ipa.spec.in b/ipa.spec.in index 5f792e1..85ea6f8 100644 --- a/ipa.spec.in +++ b/ipa.spec.in @@ -83,7 +83,7 @@ Requires: mod_nss Requires: python-ldap Requires: python-krbV Requires: python-assets -Requires: python-wehjit +Requires: python-wehjit >= 0.2.0 Requires: acl Requires: python-pyasn1 >= 0.0.9a Requires: libcap @@ -490,6 +490,9 @@ fi %endif %changelog +* Wed Jan 27 2010 Jason Gerard DeRose - 1.99-14 +- Require python-wehjit >= 0.2.0 + * Fri Dec 4 2009 Rob Crittenden - 1.99-13 - Add ipa-rmkeytab tool -- 1.6.3.3 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] not ascii, not utf-8, what's a parser supposed to do?
On Tue, 2010-01-26 at 17:28 -0500, John Dennis wrote: > I've run into a small problem with xgettext. By default xgettext expects > all strings in an input file to be encoded in ascii. It will also allow > you to override that by specifying the strings in the input file are utf-8. > > In ipappython/ipautil.py line 296 is the following string: > > SAFE_STRING_PATTERN = '(^(\000|\n|\r| |:|<)|[\000\n\r\200-\377]+|[ ]+$)' ipapython still has a lot of legacy code, so first thing we should do is check if we even use SAFE_STRING_PATTERN. Rob, do you know off hand? > In it's default ascii mode xgettext throws an error claiming the string > is not ascii. In fact xgettext is correct, the string is not ascii. (You > may be wondering why xgettext even cares since it's not marked as > translatable, but xgettext fully parses the input before deciding what > is marked as translatable, bottom line: all strings get parsed and decoded). > > If I override the default ascii input by telling xgettext the input > strings are encoded in utf-8 xgettext stops complaining, the string is > properly skipped. > > But ... the string isn't really utf-8 either and I'm not sure how > comfortable I feel about telling xgettext every string in IPA is encoded > in utf-8 (when it isn't) just to get around this failure, especially > since the offending string isn't even utf-8. (However, maybe we should > allow utf-8 as an input format since ascii is a subset of utf-8, we > might want to use utf-8 in the future and we can just hold our noses > with respect to the above regular expression). > > Do we have a stake in the ground as to what our input strings are > encoded in? > > Can you think of another way to express the offending string such that > it doesn't trigger the non-ascii error? The only thing I could think of > and get to work was this: > > SAFE_STRING_PATTERN='%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c' > > % \ > (40,94,40,0,124,10,124,13,124,32,124,58,124,60,41,124,91,0,10,13,128,45,255,93,43,124,91,32,93,43,36,41) > > Which is pretty unreadable, but with sufficient comments could be > acceptable. > > ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] jderose 034 Enable WebUI CRUDS using wehjit 0.2.0
This patch enables webUI Create-Retrieve-Updated-Delete-Search
operations for all api.Object plugins that:
1. implement all the required CRUDS methods
2. have a primary_key
Last night I realized that the upgrade to wehjit 0.2.0 broke the
installer, so I hurried this patch a bit, left out some niceties that
still need a bit more testing and tweaking.
>From 073cea91cca082ec0f8d4d0644ff9db1961bfba9 Mon Sep 17 00:00:00 2001
From: Jason Gerard DeRose
Date: Tue, 26 Jan 2010 06:39:00 -0700
Subject: [PATCH] Enabled CRUDS in webUI using wehjit 0.2.0
---
ipalib/plugable.py |2 +
ipalib/plugins/baseldap.py |7 +-
ipalib/plugins/user.py |3 +
ipaserver/rpcserver.py |3 +
ipawebui/engine.py | 124 +++---
ipawebui/widgets.py| 301 ++--
6 files changed, 241 insertions(+), 199 deletions(-)
diff --git a/ipalib/plugable.py b/ipalib/plugable.py
index 3ee2bd5..ecccb79 100644
--- a/ipalib/plugable.py
+++ b/ipalib/plugable.py
@@ -531,6 +531,8 @@ class API(DictProxy):
value = getattr(options, key, None)
if value is not None:
overrides[key] = value
+if hasattr(options, 'prod'):
+overrides['webui_prod'] = options.prod
if context is not None:
overrides['context'] = context
self.bootstrap(**overrides)
diff --git a/ipalib/plugins/baseldap.py b/ipalib/plugins/baseldap.py
index 17db048..eeea7a6 100644
--- a/ipalib/plugins/baseldap.py
+++ b/ipalib/plugins/baseldap.py
@@ -133,6 +133,7 @@ class LDAPCreate(crud.Create):
"""
Create a new entry in LDAP.
"""
+
takes_options = (
Flag('raw',
cli_name='raw',
@@ -142,6 +143,7 @@ class LDAPCreate(crud.Create):
Flag('all',
cli_name='all',
doc='retrieve all attributes',
+exclude='webui',
),
Str('addattr*', validate_add_attribute,
cli_name='addattr',
@@ -291,14 +293,17 @@ class LDAPUpdate(LDAPQuery, crud.Update):
"""
Update an LDAP entry.
"""
+
takes_options = (
Flag('raw',
cli_name='raw',
doc='print entries as they are stored in LDAP',
+exclude='webui',
),
Flag('all',
cli_name='all',
doc='retrieve all attributes',
+exclude='webui',
),
Str('addattr*', validate_add_attribute,
cli_name='addattr',
@@ -456,6 +461,7 @@ class LDAPModMember(LDAPQuery):
Flag('raw',
cli_name='raw',
doc='print entries as they are stored in LDAP',
+exclude='webui',
),
)
@@ -751,4 +757,3 @@ class LDAPSearch(crud.Search):
def post_callback(self, ldap, entries, truncated, *args, **options):
pass
-
diff --git a/ipalib/plugins/user.py b/ipalib/plugins/user.py
index 97641a4..1686d67 100644
--- a/ipalib/plugins/user.py
+++ b/ipalib/plugins/user.py
@@ -113,6 +113,9 @@ class user(LDAPObject):
cli_name='password',
label='Password',
doc='Set the user password',
+# FIXME: This is temporary till bug is fixed causing updates to
+# bomb out via the webUI.
+exclude='webui',
),
Int('uidnumber?',
cli_name='uid',
diff --git a/ipaserver/rpcserver.py b/ipaserver/rpcserver.py
index a42c3d0..e84cb07 100644
--- a/ipaserver/rpcserver.py
+++ b/ipaserver/rpcserver.py
@@ -273,4 +273,7 @@ class jsonserver(WSGIExecutioner):
raise JSONError(
error='params[1] (aka options) must be a dict'
)
+options = dict((str(k), v) for (k, v) in options.iteritems())
+print 'args = %r' % (args,)
+print 'options = %r' % (options,)
return (method, args, options, _id)
diff --git a/ipawebui/engine.py b/ipawebui/engine.py
index a90a450..01b271a 100644
--- a/ipawebui/engine.py
+++ b/ipawebui/engine.py
@@ -65,7 +65,17 @@ class ParamMapper(object):
)
+def filter_params(namespace):
+for param in namespace():
+if param.exclude and 'webui' in param.exclude:
+continue
+yield param
+
+
class Engine(object):
+
+cruds = frozenset(['add', 'show', 'mod', 'del', 'find'])
+
def __init__(self, api, app):
self.api = api
self.app = app
@@ -86,11 +96,21 @@ class Engine(object):
)
def build(self):
-for cmd in self
Re: [Freeipa-devel] Announcing wehjit 0.2.0
FYI, wehjit 0.2.0 has landed in Fedora 12. Just `yum install
python-wehjit`.
On Thu, 2010-01-21 at 09:46 -0700, Jason Gerard DeRose wrote:
> Whats new
> =
>
> This release adds significant client-side functionality and several new
> widgets. The Python API remains mostly unchanged, with the exception of
> one major addition: you can now make any state variable available
> client-side by simply creating the state descriptor with a `json=True`
> kwarg.
>
> For example, say you have a widget with a state variable called `stuff`:
>
> class MyWidget(wehjit.Widget):
> stuff = wejhit.Static('stuff')
>
> To make `stuff` available client-side, just add `json=True` like this:
>
> class MyWidget(wehjit.Widget):
> stuff = wejhit.Static('stuff', json=True)
>
> As far as new widgets, highlights include:
>
> * Grid: an AJAX table with client-side sorting, row select (click) and
>activate (double click) events, and asynchronous updates via
>JSON-RPC.
>
> * Dialog: a generic widget for transient client-side dialog boxes.
>
> * DialogSet: controls the available Dialogs in a page.
>
> * CRUDS: works in combination with Grid, Dialog, and DialogSet for AJAX
>Create, Retrieve, Update, Delete, and Search operations.
>
> There is likewise quite a bit of new supporting JavaScript for the above
> widgets.
>
> The demo has a new "AJAX Demo" example. However, as CRUDS must talk to
> a live JSON-RPC server, it doesn't work in the statically rendered demo.
> But you can run the demo from the source tree like this:
>
> ./wehjit-demo
>
> Then just point your browser to http://127.0.0.1:8080/e4_grid
>
> Lastly, the Menu widget has changed and wont display the MenuItems till
> you click on the Menu (previously it displayed on mouse over).
>
>
> Download
>
>
> The source tarball, API documentation, and statically rendered demo are
> all available here:
>
> http://jderose.fedorapeople.org/wehjit/0.2.0/
>
> Updated packages for Fedora 12 and rawhide will be available in the next
> several days (yum install python-wehjit).
>
> An unofficial Ubuntu Karmic package is available in my PPA (apt-get
> install python-wehjit):
>
> https://edge.launchpad.net/~jderose/+archive/ppa
>
> Finally, you can use Bazaar to get my current code from either my
> fedorapeople page:
>
> bzr branch http://jderose.fedorapeople.org/bzr/wehjit/
>
> Or from Launchpad:
>
> bzr branch lp:wehjit
>
>
> ___
> 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
[Freeipa-devel] Announcing wehjit 0.2.0
Whats new
=
This release adds significant client-side functionality and several new
widgets. The Python API remains mostly unchanged, with the exception of
one major addition: you can now make any state variable available
client-side by simply creating the state descriptor with a `json=True`
kwarg.
For example, say you have a widget with a state variable called `stuff`:
class MyWidget(wehjit.Widget):
stuff = wejhit.Static('stuff')
To make `stuff` available client-side, just add `json=True` like this:
class MyWidget(wehjit.Widget):
stuff = wejhit.Static('stuff', json=True)
As far as new widgets, highlights include:
* Grid: an AJAX table with client-side sorting, row select (click) and
activate (double click) events, and asynchronous updates via
JSON-RPC.
* Dialog: a generic widget for transient client-side dialog boxes.
* DialogSet: controls the available Dialogs in a page.
* CRUDS: works in combination with Grid, Dialog, and DialogSet for AJAX
Create, Retrieve, Update, Delete, and Search operations.
There is likewise quite a bit of new supporting JavaScript for the above
widgets.
The demo has a new "AJAX Demo" example. However, as CRUDS must talk to
a live JSON-RPC server, it doesn't work in the statically rendered demo.
But you can run the demo from the source tree like this:
./wehjit-demo
Then just point your browser to http://127.0.0.1:8080/e4_grid
Lastly, the Menu widget has changed and wont display the MenuItems till
you click on the Menu (previously it displayed on mouse over).
Download
The source tarball, API documentation, and statically rendered demo are
all available here:
http://jderose.fedorapeople.org/wehjit/0.2.0/
Updated packages for Fedora 12 and rawhide will be available in the next
several days (yum install python-wehjit).
An unofficial Ubuntu Karmic package is available in my PPA (apt-get
install python-wehjit):
https://edge.launchpad.net/~jderose/+archive/ppa
Finally, you can use Bazaar to get my current code from either my
fedorapeople page:
bzr branch http://jderose.fedorapeople.org/bzr/wehjit/
Or from Launchpad:
bzr branch lp:wehjit
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Improve modlist generation in ldap2. Some code cleanup as bonus.
On Tue, 2010-01-05 at 15:01 +0100, Pavel Zuna wrote: > ldap2._generate_modlist now uses more sophisticated means to decide when to > use > MOD_ADD+MOD_DELETE instead of MOD_REPLACE. Before it did MOD_REPLACE only on > attributes explicitly specified in ldap2._FORCE_REPLACE_ON_UPDATE_ATTRS. Now > it > does MOD_REPLACE for all single value attributes and never for multi value. > > This patch also silently fixes a bug: ldap2 didn't check for the existence of > attributes that were being deleted by setting them to None. > > Pavel ack. pushed to master. This patch looks fine and doesn't appear to break anything, but we *really* need tests for ldap2. It's low in our stack and almost every plugin uses it, so problems here have a high cost for us time-wise. So, Pavel, please provide tests in subsequent patch. I think this modlist functionality should be split out into functions that can be tested easily without requiring an LDAP connection. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] jderose 033 Fix fuzzy digigits under Fedora12
I'm not sure why the difference, but the uidnumber, gidnumber, etc. are
being returned as `unicode` instead of `str` under Fedora12. Returning
as `unicode` is correct, but this patch allows the test to still work
under Fedora11 for the time being.
>From dafbfc22cccff32ff847a2e2eced09ac8c881378 Mon Sep 17 00:00:00 2001
From: Jason Gerard DeRose
Date: Sun, 10 Jan 2010 17:47:15 -0700
Subject: [PATCH] Fixed xmlrpc_test.fuzzy_digits for Fedora12
---
tests/test_xmlrpc/xmlrpc_test.py |2 +-
tests/util.py|2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/test_xmlrpc/xmlrpc_test.py b/tests/test_xmlrpc/xmlrpc_test.py
index 02b1f92..61fca50 100644
--- a/tests/test_xmlrpc/xmlrpc_test.py
+++ b/tests/test_xmlrpc/xmlrpc_test.py
@@ -32,7 +32,7 @@ from ipalib import errors
# Matches a gidnumber like '1391016742'
# FIXME: Does it make more sense to return gidnumber, uidnumber, etc. as `int`
# or `long`? If not, we still need to return them as `unicode` instead of `str`.
-fuzzy_digits = Fuzzy('^\d+$', type=str)
+fuzzy_digits = Fuzzy('^\d+$', type=basestring)
# Matches an ipauniqueid like u'784d85fd-eae7-11de-9d01-54520012478b'
fuzzy_uuid = Fuzzy(
diff --git a/tests/util.py b/tests/util.py
index ed8ecad..4d5fea6 100644
--- a/tests/util.py
+++ b/tests/util.py
@@ -210,7 +210,7 @@ class Fuzzy(object):
self.re = re.compile(regex)
if type is None:
type = unicode
-assert type in (unicode, str)
+assert type in (unicode, str, basestring)
self.regex = regex
self.type = type
self.test = test
--
1.6.3.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Allow creation of new connections by unshared instances of backend.Connectible.
On Tue, 2010-01-05 at 14:10 +0100, Pavel Zuna wrote: > The backend.Connectible base class was designed, so that only one instance of > each subclass is used at a time. Connectible generates a Connection object > for > each thread and stores it in thread-local storage (context). Subclasses > access > this object through the Connectible.conn property. > > This is a good thing, because one instance of the class can be shared by all > threads and each thread has its own connection. Unfortunately, this is also a > limitation. If a thread needs a second connection (to a different host for > example) - it can't do it. Not even by creating a new instance of the > Connectible subclass. > > Ok, let's move from theory to practice: > > The LDAP backend is currently only used by the Executioner backend, so that > plugins can connect to the IPA DS. > > In the migration plugin, we need a second connection to the DS we're > migrating > from. The last version had to use low level python-ldap calls to achieve this. > > In the installer we're still using legacy code from v1. Using ldap2 would be > simpler and we could drop ~1000 lines code. (I already started rewriting a > few > parts to see if it would work.) > > Proposed solution: > > Make it possible to create unshared instances of Connectible subclasses. > > This would be achieved by passing shared_instance=False (couldn't come up > with a > better name) to the object constructor explicitly. Normally, Connection > objects > are stored in thread-local storage under the subclass name (e.g. "ldap2"). > Unshared instances would store their Connection objects under subclass name + > unique instances ID (e.g. "ldap2_218adsfka7"). > > This is the only solution I could come up with, that doesn't involve breaking > a > lot of stuff - it just adds a new way of using the code we already have. > > The attached patches show how it would be done. > > Pavel I'm fine with this approach as the solution you propose is quite unobtrusive. Is this the final patch then, or will you make further changes or bundle it with another patch? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 342 control the certificate subject in dogtag
On Fri, 2009-12-18 at 11:05 -0500, Rob Crittenden wrote: > Use the caIPAserviceCert profile for issuing service certs. > > This profile enables subject validation and ensures that the subject > that the CA issues is uniform. The client can only request a specific > CN, the rest of the subject is fixed. > > This is the first step of allowing the subject to be set at installation > time. > > Also fix 2 more issues related to the return results migration. > > Note that with the selfsign plugin it will still issue the subject that > was in the CSR. > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 341 remove hardcoded example.com domain name
On Fri, 2009-12-18 at 10:59 -0500, Rob Crittenden wrote: > Remove hardcoded domain name so tests will pass on systems not > configured with example.com. > > Note that I left example.com as the nisdomainname in the netgroup test > because this won't affect the tests themselves. > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 339 fix some certificate issues
On Fri, 2009-12-18 at 08:32 -0500, John Dennis wrote: > On 12/18/2009 07:45 AM, Jason Gerard DeRose wrote: > > On Thu, 2009-12-17 at 11:32 -0500, Rob Crittenden wrote: > >> Found a few problems with certificate handling with certmonger. Add a > >> try/except to handle base64-encoded certificates more gracefully. I had > >> also missed a function import causing things to blow up in some cases. > >> > >> rob > > > > ack. pushed to master. > > Hmm... maybe this should have been NAK'ed. The issues were under active > discussion. I don't think the patch is doing any harm but I'm not sure > it's the right solution. Maybe the patch shouldn't have been applied. Ah, sorry about that... I got the impression that this was an innocent stop-gap till we decide upon the details here. > We have to be careful with our data types. > > The patch effectively was trying to determine if a certificate was > encoded in binary DER format as opposed to base64 encoded PEM format by > trying to base64 decode the certificate, if it successfully decoded it > was assumed to be PEM. That's not the right way to handle this IMHO. > > We either need to: > > * adopt the convention that all certificates are in pem format when > exchanged at an interface boundary > > * Have a method to unambiguously identify the certificate encoding, this > could be done in one of two ways. > > 1. Always associate an encoding format attribute with the certificate > > 2. We do have the ability to unambiguously distinguish between binary > objects and text objects. We could adopt the convention that if the data > type of the certificate object is binary it is in DER format and if the > data type of the certificate is TEXT then it's in PEM format. > > The distinction between binary and text is based on whether the object > is a str class or a unicode class. The downside of this approach is > we've haven't been rigorous with enforcing the correct data types, a > problem compounded by the fact Python happily converts between str and > unicode silently. Provided we're careful with using the right data type > then the following would work: > > if type(cert) is unicode: > cert_der = base64.b64decode(cert) > else: > cert_der = cert > > -or- > > if type(cert) is str: > cert_pem = cert > else: > cert_pem = der_cert_to_pem(cert) > > What we don't want to do is start employing heuristics to guess the > encoding, format, or data type of objects, it's not robust defensive > coding practice. > ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 340 suspect looping when deleting principals from keytab
On Thu, 2009-12-17 at 14:31 -0500, Rob Crittenden wrote: > ipa-rmkeytab stopped working in F12. Turns out I'm supposed to disable > looping when removing a keytab entry. Not sure why this worked in F-11 > though, luck perhaps. > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 339 fix some certificate issues
On Thu, 2009-12-17 at 11:32 -0500, Rob Crittenden wrote: > Found a few problems with certificate handling with certmonger. Add a > try/except to handle base64-encoded certificates more gracefully. I had > also missed a function import causing things to blow up in some cases. > > rob ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
