Hi,
I'm currently cleaning up the php-eaccelerator package. It has been in Fedora since the very beginning and I'm pretty sure it never went through any review (straight from freshrpms).
The major change I have to do is "fix" the version : "5.2.3_0.9.5.1" has to become plain "0.9.5.1"
...so I'll have to introduce and epoch :-(
The problem is historical, as the module had to track the main php package's version quite closely, back when the zend_abi version wasn't provided by the php package, and this ugly trick was an easy way for end users to know if the package was the correct one.
Anyway, I'll be doing that unless someone objects ;-)
The next issue is that the cache files created by the module are stored in /var/cache/php-eaccelerator/ and the ownership of that directory is hardcoded to apache:apache in the package. This is a problem when using php with another web server, lighttpd for instance (which I do a lot). It's even worse when using multiple web servers on the same machine...
I'd like the find a clean solution for this. The only one I can think of is to have php-eaccelerator create its own group in which it'll put apache, lighttpd and eventually others, and have the cache directory owned by "root:eacceler" (it's better with only 8 chars, right?) and set g+S. This way, all web servers should be able to write and read cache files. I was also thinking of adding the web server users to the group by using triggers in the php-eaccelerator package.
Does this seem sane to do?
Matthias
On Fri, Jun 22, 2007 at 02:49:38PM +0200, Matthias Saou wrote:
The only one I can think of is to have php-eaccelerator create its own group in which it'll put apache, lighttpd and eventually others,
This package will be installable w/o pulling in all those packages and some of them create their user at package installation time. Which means that when php-eaccelerator is installed, but say lighttpd not, how would php-eaccelerator be able to add lighttpd into its group?
Sounds like you would end up with %triggers.
Axel Thimm wrote :
On Fri, Jun 22, 2007 at 02:49:38PM +0200, Matthias Saou wrote:
The only one I can think of is to have php-eaccelerator create its own group in which it'll put apache, lighttpd and eventually others,
This package will be installable w/o pulling in all those packages and some of them create their user at package installation time. Which means that when php-eaccelerator is installed, but say lighttpd not, how would php-eaccelerator be able to add lighttpd into its group?
Sounds like you would end up with %triggers.
That's what I wrote :-) You trimmed this part :
"I was also thinking of adding the web server users to the group by using triggers in the php-eaccelerator package."
The other "middle ground" solution I can think of is to have the cache directory be owned by "apache:eacceler" and mode g+wS as it would then work out-of-the-box with apache, and would only require adding any other web server users to the "eacceler" group for them to start working too. (note that all cache directories and files are created world readable/writable, which is why I currently "protect" the main cache directory with a restrictive mode, as it would be a big security issue otherwise)
Matthias
On Fri, Jun 22, 2007 at 04:27:26PM +0200, Matthias Saou wrote:
Axel Thimm wrote :
On Fri, Jun 22, 2007 at 02:49:38PM +0200, Matthias Saou wrote:
The only one I can think of is to have php-eaccelerator create its own group in which it'll put apache, lighttpd and eventually others,
This package will be installable w/o pulling in all those packages and some of them create their user at package installation time. Which means that when php-eaccelerator is installed, but say lighttpd not, how would php-eaccelerator be able to add lighttpd into its group?
Sounds like you would end up with %triggers.
That's what I wrote :-) You trimmed this part :
"I was also thinking of adding the web server users to the group by using triggers in the php-eaccelerator package."
/me apologizes and goes read a book on "learning to read". :)
But obviously I agree with your approach ;)
On Friday 22 June 2007, Matthias Saou wrote:
The next issue is that the cache files created by the module are stored in /var/cache/php-eaccelerator/ and the ownership of that directory is hardcoded to apache:apache in the package. This is a problem when using php with another web server, lighttpd for instance (which I do a lot). It's even worse when using multiple web servers on the same machine...
Are the cache files written by (multiple instances of) php-eaccelerator clash free? Ie. always the same for file /path/to/foo.php (I don't know if the caching works at that level, but to illustrate the point), no matter which web server it's being run with, or use a different filename/path for differing cached versions of something?
Ville Skyttä wrote :
On Friday 22 June 2007, Matthias Saou wrote:
The next issue is that the cache files created by the module are stored in /var/cache/php-eaccelerator/ and the ownership of that directory is hardcoded to apache:apache in the package. This is a problem when using php with another web server, lighttpd for instance (which I do a lot). It's even worse when using multiple web servers on the same machine...
Are the cache files written by (multiple instances of) php-eaccelerator clash free? Ie. always the same for file /path/to/foo.php (I don't know if the caching works at that level, but to illustrate the point), no matter which web server it's being run with, or use a different filename/path for differing cached versions of something?
I *think* it'll always be the same. I'll do a bit of testing to be sure, and if there's any kind of problem, I will simply add some README indicating the few corner-cases to avoid.
Matthias
packaging@lists.fedoraproject.org