[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 jder...@redhat.com 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 jder...@redhat.com - 1.99-14 +- Require python-wehjit = 0.2.0 + * Fri Dec 4 2009 Rob Crittenden rcrit...@redhat.com - 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] 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 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 jder...@redhat.com 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 @@ class test_host(Declarative): # It is intuitive for --all to return additional attributes, # but not to return existing attributes under different # names. -l=[u'Undisclosed location 1'], +
Re: [Freeipa-devel] Why do we have so much duplicated code?
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?) No, we don't intentionally add duplicate code. Details would be helpful. 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? Yes. We did a tremendous amount of code reorganization many months ago, it is possible that some of this duplication is a result of that. There may be some dead code too. We completely replaced the entire XML-RPC subsystem but we didn't do it all at once, we slowly replaced it, so unused code may still exist as a result of that transition. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] jderose 035 Update spec to require python-wehjit = 0.2.0
Jason Gerard DeRose wrote: The webui now requires wehjit 0.2.0. ack, pushed to master ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] Fix schema loading in the ldap backend.
Recent version of DS requires to specify the attributeTypes and objectClasses attributes explicitly when retrieving them. Pavel 0001-Fix-schema-loading-in-the-ldap-backend.patch Description: application/mbox ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] Fix File parameter validation when prompting.
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 0001-Fix-File-parameter-validation-when-prompting.patch Description: application/mbox ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Why do we have so much duplicated code?
On 01/27/2010 06:00 AM, Jason Gerard DeRose wrote: 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. Well, you've helped answer one question, ipapython is deprecated, I didn't know that, what else is deprecated? Is the contents of the source tree documented somewhere so one can tell what's supposed to be imported by what, what's the target goal, etc? This isn't a complete list, just off the top of my head: Duplicate functions: client_auth_data_callback() ipapython/nsslib.py ipaserver/install/cainstance.py ipaserver/install/certs.py get_fqdn() ipalib/util.py ipaserver/install/installutils.py get_gsserror() ipapython/ipautil.py ipaserver/ipautil.py get_serial() ipalib/plugins/cert.py ipalib/plugins/service.py needs_base64() ipapython/ipautil.py ipaserver/ipautil.py openLocked() contrib/RHEL4/ipachangeconf.py ipa-client/ipaclient/ipachangeconf.py realm_to_suffix() ipalib/util.py ipapython/ipautil.py ipaserver/ipautil.py unwrap_binary_data() ipapython/ipautil.py ipaserver/ipautil.py utf8_encode_value() ipapython/entity.py ipaserver/ipautil.py utf8_encode_values() ipapython/entity.py ipaserver/ipautil.py validate_host() ipalib/plugins/host.py ipaserver/plugins/join.py wrap_binary_data() ipapython/ipautil.py ipaserver/ipautil.py Duplicate Classes: class CIDict ipapython/ipautil.py ipaserver/ipautil.py class IPAChangeConf contrib/RHEL4/ipachangeconf.py ipa-client/ipaclient/ipachangeconf.py class SSLFile ipalib/rpc.py ipapython/ipasslfile.py ipapython/nsslib.py Logic for HTTP requests duplicated in: nsslib.py rpc.py cainstance.py ipapython/dogtag.py plugins/dogtag.py certs.py -- John Dennis jden...@redhat.com Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 355 allow named to use ldapi
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 freeipa-355-named.patch Description: application/mbox ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] what's deprecated what's in use in our tree?
When you check out an IPA tree apparently you get the kitchen sink. I need to figure out what is deprecated in the tree and what is supposed to be in use installed code. According to Jason everything under ipapython is deprecated right? Is everything under ipaserver/install deprecated too? Is everything under ipaclient deprecated too? Working on the assumption nothing should be importing from ipapython I did a little search. Under ipaserver the only imports for ipapython are in the ipaserver/install directory, which is o.k. because install is deprecated. EXCEPT for ipaserver/plugins/dogtag.py which imports nsslib from ipapython. We seem to have some problems with ipalib importing from ipapython: rpc.py: from ipapython import ipautil rpc.py: from ipapython.ipasslfile import SSLFile rpc.py: from ipapython.ipasslfile import FakeSocket ./plugins/cert.py: from ipapython import dnsclient ./rpc.py: from ipapython import ipautil ./rpc.py: from ipapython.ipasslfile import SSLFile ./rpc.py: from ipapython.ipasslfile import FakeSocket We seem to have some problems with ipaclient importing from ipapython but since ipaclient is deprecated (right?) that's not a problem, right? If ipapython and ipaclient are deprecated why are we still building the ipa-python and ipa-client rpms? -- John Dennis jden...@redhat.com Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 356 update dogtag configuration to work with NSS CVE-2009-3555 fixes
NSS is going to disallow all SSL renegotiation by default. Because of this we need to always use the agent port of the dogtag server which always requires SSL client authentication. The end user port will prompt for a certificate if required but will attempt to re-do the handshake to make this happen which will fail with newer versions of NSS. This fixed version of NSS is currently in Fedora updates-testing but this patch should work with either release. rob freeipa-356-dogtag.patch Description: application/mbox ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] what's deprecated what's in use in our tree?
John Dennis wrote: When you check out an IPA tree apparently you get the kitchen sink. I need to figure out what is deprecated in the tree and what is supposed to be in use installed code. The only code that is really deprecated is the radius work you did for v1. It was carried along into the v2 tree to serve as a starting point in case anyone wanted to try to re-add radius support. There is also some code from the old XML-RPC server that seems to be left over. This is, for example, why there are two SSLFile classes. One is for OpenSSL, the other for python-nss. Newer versions of httplib changed enough that made it necessary to pull SSLFile into our tree from older versions because we need to override certain pieces so we can stick in our authorization headers IIRC. A lot of this was written prior to python-nss and may be a candidate for being rewritten/removed. Additional code such as the CIDict and ipaldap are the legacy LDAP code that Pavel is working to replace. We significantly restructed the code at some point and this is explains the one-for-one duplication, some files were simply not removed. According to Jason everything under ipapython is deprecated right? No. Is everything under ipaserver/install deprecated too? No. This is the server installer code. Is everything under ipaclient deprecated too? No. This is the client installer. Working on the assumption nothing should be importing from ipapython I did a little search. Under ipaserver the only imports for ipapython are in the ipaserver/install directory, which is o.k. because install is deprecated. No, this is where we put common code that is not part of the framework. EXCEPT for ipaserver/plugins/dogtag.py which imports nsslib from ipapython. ipapython is sort of common client/server code that lives outside the management framework that Jason did (ipalib). We seem to have some problems with ipalib importing from ipapython: rpc.py:from ipapython import ipautil rpc.py:from ipapython.ipasslfile import SSLFile rpc.py:from ipapython.ipasslfile import FakeSocket ./plugins/cert.py:from ipapython import dnsclient ./rpc.py:from ipapython import ipautil ./rpc.py:from ipapython.ipasslfile import SSLFile ./rpc.py:from ipapython.ipasslfile import FakeSocket We seem to have some problems with ipaclient importing from ipapython but since ipaclient is deprecated (right?) that's not a problem, right? If ipapython and ipaclient are deprecated why are we still building the ipa-python and ipa-client rpms? Because they aren't deprecated. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 356 update dogtag configuration to work with NSS CVE-2009-3555 fixes
On 01/27/2010 03:35 PM, Rob Crittenden wrote: NSS is going to disallow all SSL renegotiation by default. Because of this we need to always use the agent port of the dogtag server which always requires SSL client authentication. The end user port will prompt for a certificate if required but will attempt to re-do the handshake to make this happen which will fail with newer versions of NSS. This fixed version of NSS is currently in Fedora updates-testing but this patch should work with either release. ACK -- John Dennis jden...@redhat.com Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] what's deprecated what's in use in our tree?
Thanks Rob, a couple more questions: According to Jason everything under ipapython is deprecated right? No. Is everything under ipaserver/install deprecated too? No. This is the server installer code. Earlier today Jason said this: the legacy code from v1 (ipapython, the installer) and the new plugable v2 code (ipalib, ipaserver) Then what did Jason mean when he used the term legacy? I took that to mean deprecated, or did he mean it's just older vintage? Under ipaserver the only imports for ipapython are in the ipaserver/install directory, which is o.k. because install is deprecated. No, this is where we put common code that is not part of the framework. ipapython is sort of common client/server code that lives outside the management framework that Jason did (ipalib). O.K. I'm still confused :-) Above you state ipaserver/install *and* ipapython is where common code outside the framework belongs. Is there a fine distinction being drawn between the two import areas such that they can't live together? Can you define the term framework? -- John Dennis jden...@redhat.com Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Fix schema loading in the ldap backend.
Pavel Zuna wrote: Recent version of DS requires to specify the attributeTypes and objectClasses attributes explicitly when retrieving them. Pavel ack, pushed to master It would be nice if there were a way for the server to blow up if no schema was available but this is working for me for now. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] what's deprecated what's in use in our tree?
John Dennis wrote: Thanks Rob, a couple more questions: According to Jason everything under ipapython is deprecated right? No. Is everything under ipaserver/install deprecated too? No. This is the server installer code. Earlier today Jason said this: the legacy code from v1 (ipapython, the installer) and the new plugable v2 code (ipalib, ipaserver) Then what did Jason mean when he used the term legacy? I took that to mean deprecated, or did he mean it's just older vintage? I think he meant from v1. Huge gobs of code was completely dropped when we transitioned. Under ipaserver the only imports for ipapython are in the ipaserver/install directory, which is o.k. because install is deprecated. No, this is where we put common code that is not part of the framework. ipapython is sort of common client/server code that lives outside the management framework that Jason did (ipalib). O.K. I'm still confused :-) Above you state ipaserver/install *and* ipapython is where common code outside the framework belongs. Is there a fine distinction being drawn between the two import areas such that they can't live together? No ipaserver/install is the server installer, ipapython is the client/server/installer common code. Can you define the term framework? It basically equates to the client/server model for the plugin system. It supports JSON and XML-RPC (though the later is what we mostly use). The core of this is in ipalib. Plugins shared between the client and server are in ipalib/plugins. Things that are server-specific are found in ipaserver. ipaserver/install is used only during installation. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 357 ipa-server-install man updates
Bring ipa-server-install man page up-to-date, fix some syntax errors: Remove a bunch of trailing spaces Add the --ca option Add the --no-host-dns option Add the --subject option Fix the one-character option for --no-ntp, should be -N not -n Add missing line break between --no-ntp and --uninstall rob freeipa-357-man.patch Description: application/mbox ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] convert SAFE_STRING_PATTERN from string to integer sequence to prevent xgettext from aborting when it sees a non-ascii string
--- ipapython/ipautil.py | 16 +++- ipaserver/ipautil.py | 16 +++- 2 files changed, 30 insertions(+), 2 deletions(-) diff --git a/ipapython/ipautil.py b/ipapython/ipautil.py index 1399c70..3768fa0 100644 --- a/ipapython/ipautil.py +++ b/ipapython/ipautil.py @@ -293,7 +293,21 @@ class CIDict(dict): # It was extracted because ipaldap.py is naughtily reaching into the ldif # module and squashing this regexp. # -SAFE_STRING_PATTERN = '(^(\000|\n|\r| |:|)|[\000\n\r\200-\377]+|[ ]+$)' +# This is the original definition of SAFE_STRING_PATTERN +# SAFE_STRING_PATTERN = '(^(\000|\n|\r| |:|)|[\000\n\r\200-\377]+|[ ]+$)' +# +# But the regular expression string is neither ASCII nor UTF-8 +# which causes xgettext to fail because xgettext expects all strings it +# finds in a file to be either ASCII or UTF-8. To prevent xgettext from +# aborting when it sees this string we build it from integers using this code: +# +# print SAFE_STRING_PATTERN = \\\n'%s' %% \\\n(%s) % \ +# (%c * len(SAFE_STRING_PATTERN), +# ,.join([%d % ord(c) for c in SAFE_STRING_PATTERN])) + +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) safe_string_re = re.compile(SAFE_STRING_PATTERN) def needs_base64(s): diff --git a/ipaserver/ipautil.py b/ipaserver/ipautil.py index 7042c1c..968d392 100644 --- a/ipaserver/ipautil.py +++ b/ipaserver/ipautil.py @@ -125,7 +125,21 @@ class CIDict(dict): # It was extracted because ipaldap.py is naughtily reaching into the ldif # module and squashing this regexp. # -SAFE_STRING_PATTERN = '(^(\000|\n|\r| |:|)|[\000\n\r\200-\377]+|[ ]+$)' +# This is the original definition of SAFE_STRING_PATTERN +# SAFE_STRING_PATTERN = '(^(\000|\n|\r| |:|)|[\000\n\r\200-\377]+|[ ]+$)' +# +# But the regular expression string is neither ASCII nor UTF-8 +# which causes xgettext to fail because xgettext expects all strings it +# finds in a file to be either ASCII or UTF-8. To prevent xgettext from +# aborting when it sees this string we build it from integers using this code: +# +# print SAFE_STRING_PATTERN = \\\n'%s' %% \\\n(%s) % \ +# (%c * len(SAFE_STRING_PATTERN), +# ,.join([%d % ord(c) for c in SAFE_STRING_PATTERN])) + +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) safe_string_re = re.compile(SAFE_STRING_PATTERN) def needs_base64(s): -- 1.6.6 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
