On 06/19/2010 12:22 AM, Adam Young wrote:
On 06/18/2010 05:53 PM, Simo Sorce wrote:
On Fri, 18 Jun 2010 17:28:19 -0400
Adam Young<ayo...@redhat.com> wrote:
On 06/18/2010 04:51 PM, Rob Crittenden wrote:
Adam Young wrote:
Pavel's current code base tries to write
to /var/cache/ipa/assets/ from within httpd, which is forbidden
by SELinux. I suspect the code in the mainline might be doing
this as well. The work around is:
chcon -R -t httpd_sys_content_rw_t /var/cache/ipa/assets
semanage fcontext -a -t httpd_sys_content_rw_t 'assets'
If we are going to do this kind of code generation, we might want
to do it at install time, or as part of something like
I'd think this rule would cover it in ipa_httpd.fc:
Before I open a bug I want to review with Pavel. I wasn't seeing
this before I merged in his changes, and it wasn't for code in the
main git repo, so no bug yet.
As a general rule I don't like that apache gets to write to the file
system, esp if that means changing code that different users use at
the same time. It's a too big risk.
Simo, I agree. I'm thinking that anything doing one time code generation
should be done outside the apache process. I'm not sure we are even
going to take this approach long term. The code doing the generatrion
is, I think left over from Jason's last effort.
This is a possibility that we will want to script code based on the meta
data of the plugins. We have three points we could do this: at plugin
deploiy time, inside the server at http fetch , or in the broswer (via
/var.... should be done at plugin deploy time instead, or should be done
This has nothing to do with code generation.
/var/cache/ipa/assets is the IPA location managed by Jason's assetslib
(python-assets). It's used to store static data like images, css, etc. linked by
the webUI. All normal files are copied there at installation time and only
symbolic links are created "on the fly" when something changes. The goal is to
achieve maximum caching. You can read more about the concept here:
We're going to drop this code. Jason wrote it a long time ago, it has some
issues and I don't want to maintain it anymore (it's misunderstood and causes
more trouble than it saves).
Freeipa-devel mailing list