[Freeipa-devel] [Transifex] File submitted via email to FreeIPA | master
Hello freeipa, this is Transifex at http://www.transifex.net. The following attached files were submitted to FreeIPA | master by beckerde Please, visit Transifex at http://www.transifex.net/projects/p/freeipa/c/master/ in order to see the component page. Thank you, Transifex # Fedora Spanish translation of freeipa.master.ipa. # This file is distributed under the same license as the freeipa.master.ipa package. # # Héctor Daniel Cabrera , 2010. # msgid "" msgstr "" "Project-Id-Version: freeipa.master.ipa\n" "Report-Msgid-Bugs-To: https://hosted.fedoraproject.org/projects/freeipa/newticket\n"; "POT-Creation-Date: 2010-02-15 14:55-0500\n" "PO-Revision-Date: \n" "Last-Translator: Domingo Becker \n" "Language-Team: Fedora Spanisg \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "X-Poedit-Language: Spanish\n" "X-Poedit-Country: ARGENTINA\n" "Plural-Forms: nplurals=2; plural=(n != 1);\n" #: ../../ipalib/parameters.py:224 msgid "incorrect type" msgstr "tipo incorrecto" #: ../../ipalib/parameters.py:227 msgid "Only one value is allowed" msgstr "Sólo se permite un valor" #: ../../ipalib/parameters.py:791 msgid "must be True or False" msgstr "debe ser True o False" #: ../../ipalib/parameters.py:892 msgid "must be an integer" msgstr "debe ser un entero" #: ../../ipalib/parameters.py:943 #, python-format msgid "must be at least %(minvalue)d" msgstr "debe ser como mínimo %(minvalue)d" #: ../../ipalib/parameters.py:953 #, python-format msgid "can be at most %(maxvalue)d" msgstr "puede ser como máximo %(maxvalue)d" #: ../../ipalib/parameters.py:963 msgid "must be a decimal number" msgstr "debe ser un número decimal" #: ../../ipalib/parameters.py:985 #, python-format msgid "must be at least %(minvalue)f" msgstr "debe ser como mínimo %(minvalue)f" #: ../../ipalib/parameters.py:995 #, python-format msgid "can be at most %(maxvalue)f" msgstr "puede ser como máximo %(maxvalue)f" #: ../../ipalib/parameters.py:1055 #, python-format msgid "must match pattern \"%(pattern)s\"" msgstr "debe coincidir con el modelo \"%(pattern)s" #: ../../ipalib/parameters.py:1073 msgid "must be binary data" msgstr "debe ser un dato binario" #: ../../ipalib/parameters.py:1088 #, python-format msgid "must be at least %(minlength)d bytes" msgstr "debe ser como mínimo de %(minlength)d bytes" #: ../../ipalib/parameters.py:1098 #, python-format msgid "can be at most %(maxlength)d bytes" msgstr "puede ser a lo sumo de %(maxlength)d bytes" #: ../../ipalib/parameters.py:1108 #, python-format msgid "must be exactly %(length)d bytes" msgstr "debe ser exactamente de %(length)d bytes" #: ../../ipalib/parameters.py:1126 msgid "must be Unicode text" msgstr "debe ser texto Unicode" #: ../../ipalib/parameters.py:1156 #, python-format msgid "must be at least %(minlength)d characters" msgstr "debe tener como mínimo %(minlength)d caracteres" #: ../../ipalib/parameters.py:1166 #, python-format msgid "can be at most %(maxlength)d characters" msgstr "puede tener a lo sumo %(maxlength)d caracteres" #: ../../ipalib/parameters.py:1176 #, python-format msgid "must be exactly %(length)d characters" msgstr "debe tener exactamente %(length)d caracteres" #: ../../ipalib/parameters.py:1215 #, python-format msgid "must be one of %(values)r" msgstr "debe ser uno de %(values)r" #: ../../ipalib/cli.py:505 #, python-format msgid "Enter %(label)s again to verify: " msgstr "ngrese %(label)s nuevamente para su verificación: " #: ../../ipalib/cli.py:509 msgid "Passwords do not match!" msgstr "¡Las contraseñas no coinciden!" #: ../../ipalib/cli.py:514 msgid "Cancelled." msgstr "Cancelado." #: ../../ipalib/frontend.py:377 msgid "Results are truncated, try a more specific search" msgstr "Los resultados se encuentran truncados, intente realizar una búsqueda más específica" #: ../../ipalib/errors.py:297 #, python-format msgid "%(cver)s client incompatible with %(sver)s server at %(server)r" msgstr "el cliente %(cver)s no es compatible con el servidor %(sver)s en %(server)r" #: ../../ipalib/errors.py:315 #, python-format msgid "unknown error %(code)d from %(server)s: %(error)s" msgstr "error %(code)d desconocido de %(server)s: %(error)s" #: ../../ipalib/errors.py:331 msgid "an internal error has occurred" msgstr "ha ocurrido un error interno" #: ../../ipalib/errors.py:353 #, python-format msgid "an internal error has occurred on server at %(server)r" msgstr "ha ocurrido un error interno en el servidor en %(server)r" #: ../../ipalib/errors.py:369 #, python-format msgid "unknown command %(name)r" msgstr "comando desconocido %(name)r" #: ../../ipalib/errors.py:386 #: ../../ipalib/errors.py:411 #, python-format msgid "error on server %(server)r: %(error)s" msgstr "error en el servidor %(server)r: %(error)s" #: ../../ipalib/errors.py:402 #, python-format msgid "cannot connect to %(uri)r: %(error)s" msgstr "no es posible conectar con %(uri)r: %(error)s" #: ../../ipalib/errors.py:420 #, python-format msgi
Re: [Freeipa-devel] JSON problems (the woes of binary data)
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.
Asking the question what should the UI be displaying for binary data is
a good question to ask. In the specific case of certificates I think
displaying it in PEM format is pretty reasonable, a user could
cut-n-paste that and have it be useful. I think it would also be good to
have a link as you suggest for the user to click on that would perform a
download and store the data in a file (probably with a choice of PEM
format or DER binary).
As for the other binary data we have yet to deal with, but for which we
think there might be a a future need, I think we'll just have to deal
with that in the UI on a case by case basis depending on what the data
is. Would keytabs be one possible example of such a future need for
binary data available via the UI?
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)}
Yes, that's a good idea and one I hadn't thought of. My understanding of
what you're proposing is this:
For JSON *only* we pre-scan the object to be JSON encoded and any place
we discover a str object we replace that str object in the object
containing it with a dict {'__base64__': base64_ecoded_value}.
We then send this through the JSON transport.
On the JSON receiving end after JSON decodes back into a Python object
we scan the object and every place we find a dict with a '__base64__'
key we replace that dict with the base64 decoded value of the
'__base64__' key.
I have started to develop a prototype of this code and it seems to work.
The functions modify the data "in place" replacing objects within their
containers.
I should by the end of the day have enough working to see if this solves
the exception generating the backtrace on the Services page.
However, even though this would get us over the hump with regards to
passing binary data through JSON, which I think we should do I continue
to believe we should not be passing certificates and certficate requests
as DER binary data. Based on prior responses there seems to be consensus
that certificates should be passed as PEM encoded strings. That's
something which can be patched later.
So my general plan is to get binary data working in JSON, then later
patch things so that certs and csr's are PEM encoded. This gives us two
good things: the ability to pass binary data in a general way which is
probably a worthwhile thing to support in the framework even though we
won't be using once certs are passed in PEM format, but may be useful
down the road for other items, and then a consistent PEM format for
certs. How does this sound?
--
John Dennis
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] jderose 049 Consolidate to single WSGI entry point
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 ___ 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
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*
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.
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
Re: [Freeipa-devel] [PATCH] Code cleanup: remove unused stuff, take 1.
Pavel Zuna wrote: Removes most of the deprecated output code from plugins. "take 1" because there might be more patches like this in the near future. Pavel ack, pushed to master ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] full Spanish translations as of 20100225
John Dennis wrote: ipa.pot has 133 messages. There are 6 po translation files. bn_IN:14/133 10.5% 106 po untranslated, 13 missing, 119 untranslated es: 133/133 100.0%0 po untranslated,0 missing,0 untranslated id: 107/133 80.5% 13 po untranslated, 13 missing, 26 untranslated kn: 20/133 15.0% 113 po untranslated,0 missing, 113 untranslated pl: 133/133 100.0%0 po untranslated,0 missing,0 untranslated ru: 120/133 90.2%0 po untranslated, 13 missing, 13 untranslated ack, pushed to master ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] More Kannada translations
John Dennis wrote: More Kannada translations Current translation status: ipa.pot has 133 messages. There are 6 po translation files. bn_IN:14/133 10.5% 106 po untranslated, 13 missing, 119 untranslated es: 133/133 100.0%0 po untranslated,0 missing,0 untranslated id: 107/133 80.5% 13 po untranslated, 13 missing, 26 untranslated kn: 133/133 100.0%0 po untranslated,0 missing,0 untranslated pl: 133/133 100.0%0 po untranslated,0 missing,0 untranslated ru: 120/133 90.2%0 po untranslated, 13 missing, 13 untranslated ack, pushed to master ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] Fix JSON binary encode and decode errors
Fix JSON binary encode and decode errors
Traverse the objects passed to JSON for encoding and decoding.
When binary data is seen during encode replace the binary
data with a dict {'__base64__' : base64_encoding_of_binary_value}.
On decode if a dict is seen whose single key is '__base64__' replace
that dict with the base64 decoded value of the key's value.
Thanks to Jason for the suggestion (no pun intended :-)
--
John Dennis
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
>From f45be23b3c5f41ee012c51a6d6d3759f92ee48ee Mon Sep 17 00:00:00 2001
From: John Dennis
Date: Mon, 1 Mar 2010 18:55:39 -0500
Subject: [PATCH] Fix JSON binary encode and decode errors
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Traverse the objects passed to JSON for encoding and decoding.
When binary data is seen during encode replace the binary
data with a dict {'__base64__' : base64_encoding_of_binary_value}.
On decode if a dict is seen whose single key is '__base64__' replace
that dict with the base64 decoded value of the key's value.
---
ipaserver/rpcserver.py | 100 +++-
1 files changed, 99 insertions(+), 1 deletions(-)
diff --git a/ipaserver/rpcserver.py b/ipaserver/rpcserver.py
index 4a5040e..96c4d29 100644
--- a/ipaserver/rpcserver.py
+++ b/ipaserver/rpcserver.py
@@ -31,7 +31,7 @@ from ipalib.request import context, Connection, destroy_context
from ipalib.rpc import xml_dumps, xml_loads
from ipalib.util import make_repr
from ipalib.compat import json
-
+import base64
def read_input(environ):
"""
@@ -216,6 +216,102 @@ class xmlserver(WSGIExecutioner):
return xml_dumps(response, methodresponse=True)
+def json_encode_binary(val):
+'''
+ JSON cannot encode binary values. We encode binary values in Python str
+ objects and text in Python unicode objects. In order to allow a binary
+ object to be passed through JSON we base64 encode it thus converting it to
+ text which JSON can transport. To assure we recognize the value is a base64
+ encoded representation of the original binary value and not confuse it with
+ other text we convert the binary value to a dict in this form:
+
+ {'__base64__' : base64_encoding_of_binary_value}
+
+ This modification of the original input value cannot be done "in place" as
+ one might first assume (e.g. replacing any binary items in a container
+ (e.g. list, tuple, dict) with the base64 dict because the container might be
+ an immutable object (i.e. a tuple). Therefore this function returns a copy
+ of any container objects it encounters with tuples replaced by lists. This
+ is O.K. because the JSON encoding will map both lists and tuples to JSON
+ arrays.
+ '''
+
+if isinstance(val, dict):
+new_dict = {}
+for k,v in val.items():
+if isinstance(v, str):
+new_dict[k] = {'__base64__' : base64.b64encode(v)}
+else:
+new_dict[k] = json_encode_binary(v)
+del val
+return new_dict
+elif isinstance(val, (list, tuple)):
+new_list = []
+n = len(val)
+i = 0
+while i < n:
+v = val[i]
+if isinstance(v, str):
+new_list.append({'__base64__' : base64.b64encode(v)})
+else:
+new_list.append(json_encode_binary(v))
+i += 1
+del val
+return new_list
+elif isinstance(val, str):
+return {'__base64__' : base64.b64encode(val)}
+else:
+return val
+
+def json_decode_binary(val):
+'''
+JSON cannot transport binary data. In order to transport binary data we
+convert binary data to a form like this:
+
+ {'__base64__' : base64_encoding_of_binary_value}
+
+ see json_encode_binary()
+
+After JSON had decoded the JSON stream back into a Python object we must
+recursively scan the object looking for any dicts which might represent
+binary values and replace the dict containing the base64 encoding of the
+binary value with the decoded binary value. Unlike the encoding problem
+where the input might consist of immutable object, all JSON decoded
+container are mutable so the conversion could be done in place. However we
+don't modifying objects in place has side effects which may be
+dangerous. Thus we elect to spend a few more cycles and avoid the
+possibility of unintended side effects in favor of robustness.
+'''
+
+if isinstance(val, dict):
+if val.has_key('__base64__'):
+return base64.b64decode(val['__base64__'])
+else:
+new_dict = {}
+for k,v in val.items():
+if isinstance(v, dict) and v.has_key('__base64__'):
+new_dict[k] = base64.b64decode(v['__base64__'])
+else:
+new_dict[k] = json_decode_binary(v)
+del val
+return new_dict
+
[Freeipa-devel] [PATCH] update POT
This updates the POT file. This can be immediately committed via the .po files require no ACK rule. Explanation: the POT file is auto generated on demand, there is nothing to review. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ >From ee0c763dff6db808e0006a677ba4d9ab3df7aa58 Mon Sep 17 00:00:00 2001 From: John Dennis Date: Mon, 1 Mar 2010 19:57:39 -0500 Subject: [PATCH] update POT Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit --- install/po/ipa.pot | 939 1 files changed, 867 insertions(+), 72 deletions(-) diff --git a/install/po/ipa.pot b/install/po/ipa.pot index f211ce7..b08f749 100644 --- a/install/po/ipa.pot +++ b/install/po/ipa.pot @@ -9,7 +9,7 @@ msgstr "" "Project-Id-Version: ipa\n" "Report-Msgid-Bugs-To: https://hosted.fedoraproject.org/projects/freeipa/"; "newticket\n" -"POT-Creation-Date: 2010-02-15 14:55-0500\n" +"POT-Creation-Date: 2010-03-01 19:57-0500\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" @@ -18,104 +18,104 @@ msgstr "" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=INTEGER; plural=EXPRESSION;\n" -#: ../../ipalib/parameters.py:224 +#: ../../ipalib/parameters.py:295 msgid "incorrect type" msgstr "" -#: ../../ipalib/parameters.py:227 +#: ../../ipalib/parameters.py:298 msgid "Only one value is allowed" msgstr "" -#: ../../ipalib/parameters.py:791 +#: ../../ipalib/parameters.py:862 msgid "must be True or False" msgstr "" -#: ../../ipalib/parameters.py:892 +#: ../../ipalib/parameters.py:963 msgid "must be an integer" msgstr "" -#: ../../ipalib/parameters.py:943 +#: ../../ipalib/parameters.py:1014 #, python-format msgid "must be at least %(minvalue)d" msgstr "" -#: ../../ipalib/parameters.py:953 +#: ../../ipalib/parameters.py:1024 #, python-format msgid "can be at most %(maxvalue)d" msgstr "" -#: ../../ipalib/parameters.py:963 +#: ../../ipalib/parameters.py:1034 msgid "must be a decimal number" msgstr "" -#: ../../ipalib/parameters.py:985 +#: ../../ipalib/parameters.py:1056 #, python-format msgid "must be at least %(minvalue)f" msgstr "" -#: ../../ipalib/parameters.py:995 +#: ../../ipalib/parameters.py:1066 #, python-format msgid "can be at most %(maxvalue)f" msgstr "" -#: ../../ipalib/parameters.py:1055 +#: ../../ipalib/parameters.py:1126 #, python-format msgid "must match pattern \"%(pattern)s\"" msgstr "" -#: ../../ipalib/parameters.py:1073 +#: ../../ipalib/parameters.py:1144 msgid "must be binary data" msgstr "" -#: ../../ipalib/parameters.py:1088 +#: ../../ipalib/parameters.py:1159 #, python-format msgid "must be at least %(minlength)d bytes" msgstr "" -#: ../../ipalib/parameters.py:1098 +#: ../../ipalib/parameters.py:1169 #, python-format msgid "can be at most %(maxlength)d bytes" msgstr "" -#: ../../ipalib/parameters.py:1108 +#: ../../ipalib/parameters.py:1179 #, python-format msgid "must be exactly %(length)d bytes" msgstr "" -#: ../../ipalib/parameters.py:1126 +#: ../../ipalib/parameters.py:1197 msgid "must be Unicode text" msgstr "" -#: ../../ipalib/parameters.py:1156 +#: ../../ipalib/parameters.py:1227 #, python-format msgid "must be at least %(minlength)d characters" msgstr "" -#: ../../ipalib/parameters.py:1166 +#: ../../ipalib/parameters.py:1237 #, python-format msgid "can be at most %(maxlength)d characters" msgstr "" -#: ../../ipalib/parameters.py:1176 +#: ../../ipalib/parameters.py:1247 #, python-format msgid "must be exactly %(length)d characters" msgstr "" -#: ../../ipalib/parameters.py:1215 +#: ../../ipalib/parameters.py:1286 #, python-format msgid "must be one of %(values)r" msgstr "" -#: ../../ipalib/cli.py:505 +#: ../../ipalib/cli.py:507 #, python-format msgid "Enter %(label)s again to verify: " msgstr "" -#: ../../ipalib/cli.py:509 +#: ../../ipalib/cli.py:511 msgid "Passwords do not match!" msgstr "" -#: ../../ipalib/cli.py:514 +#: ../../ipalib/cli.py:516 msgid "Cancelled." msgstr "" @@ -348,106 +348,475 @@ msgstr "" msgid "Certificate operation cannot be completed: %(error)s" msgstr "" -#: ../../ipalib/plugins/rolegroup.py:50 +#: ../../ipalib/plugins/config.py:45 +msgid "Max username length" +msgstr "" + +#: ../../ipalib/plugins/config.py:50 +msgid "Home directory base" +msgstr "" + +#: ../../ipalib/plugins/config.py:51 +msgid "Default location of home directories" +msgstr "" + +#: ../../ipalib/plugins/config.py:55 +msgid "Default shell" +msgstr "" + +#: ../../ipalib/plugins/config.py:56 +msgid "Default shell for new users" +msgstr "" + +#: ../../ipalib/plugins/config.py:60 +msgid "Default users group" +msgstr "" + +#: ../../ipalib/plugins/config.py:61 +msgid "Default group for new users" +msgstr "" + +#: ../../ipalib/plugins/config.py:65 +msgid "Default e-mail domain" +msgstr "" + +#: ../../ipalib/plugins/config.py:66 +msgid "Default e-mail domain new users" +
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
[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 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
