Hi,
i have a webserver (apache 2.4/php5/mysql 5.6) and i want to be sure it is setup to use FastCGI.
when i execute phpinfo(); i can see (in loaded modules): [CODE] mod_proxy_fcgi mod_proxy_scgi mod_cgi mod_php5 [/CODE]
however using my standard fedora user account, Ii still can not edit/remove/move files/folders owned by apache user account.
while searching on internet i discovered that fastCGI should allow me (using my fedora user account) to do such thing, even if files/folders are owned by apache user account.
therefore i deduced that fastCGI doesn't work properly on my webserver.
Please, could you tell me how can i be sure that fastCGI runs well on my webserver and that i use it correctly ? thx
Am 14.06.2013 12:35, schrieb Rafnews:
however using my standard fedora user account, Ii still can not edit/remove/move files/folders owned by apache user account. while searching on internet i discovered that fastCGI should allow me (using my fedora user account) to do such thing, even if files/folders are owned by apache user account
this has *nothing* to with mod_php oder fastcgi the permissions are how they are
* man setfacl * man chown * man chgrp * man chmod
and by the way - the apache user should *not* own the files because typically a webserver should not be able to rewrite his content files in case of a security breach
On 14.06.2013 13:18, Reindl Harald wrote:
Am 14.06.2013 12:35, schrieb Rafnews:
however using my standard fedora user account, Ii still can not edit/remove/move files/folders owned by apache user account. while searching on internet i discovered that fastCGI should allow me (using my fedora user account) to do such thing, even if files/folders are owned by apache user account
this has *nothing* to with mod_php oder fastcgi the permissions are how they are
- man setfacl
- man chown
- man chgrp
- man chmod
and by the way - the apache user should *not* own the files because typically a webserver should not be able to rewrite his content files in case of a security breach
2 of our webserver hosting companies told us that if we want to have files own by some other user account than apache, it is needed to have fastCGI..if not, than we need suPHP or suExec.
However it has been told that FastCGI provide also a performance increase so, we would like to reach it also :)
Am 14.06.2013 13:21, schrieb Rafnews:
On 14.06.2013 13:18, Reindl Harald wrote:
Am 14.06.2013 12:35, schrieb Rafnews:
however using my standard fedora user account, Ii still can not edit/remove/move files/folders owned by apache user account. while searching on internet i discovered that fastCGI should allow me (using my fedora user account) to do such thing, even if files/folders are owned by apache user account
this has *nothing* to with mod_php oder fastcgi the permissions are how they are
- man setfacl
- man chown
- man chgrp
- man chmod
and by the way - the apache user should *not* own the files because typically a webserver should not be able to rewrite his content files in case of a security breach
2 of our webserver hosting companies told us that if we want to have files own by some other user account than apache, it is needed to have fastCGI..if not, than we need suPHP or suExec.
fire the company if they said this really in this way
CGI is needed instead mod_php to have own processes which is the base for suPHP and suExec but that has *nothing* to do with your problem above on your local test-setup which would be solved with the right permissions / ACL's
However it has been told that FastCGI provide also a performance increase so, we would like to reach it also :)
ok, fire them really
it is impossible that the webserver speaking via CGI/FCGI with a standalone PHP binary is faster than having PHP inside the httpd process and this sounds like a typical "webserver hosting company" knowing zero to nothing
On 14.06.2013 13:29, Reindl Harald wrote:
Am 14.06.2013 13:21, schrieb Rafnews:
On 14.06.2013 13:18, Reindl Harald wrote:
Am 14.06.2013 12:35, schrieb Rafnews:
however using my standard fedora user account, Ii still can not edit/remove/move files/folders owned by apache user account. while searching on internet i discovered that fastCGI should allow me (using my fedora user account) to do such thing, even if files/folders are owned by apache user account
this has *nothing* to with mod_php oder fastcgi the permissions are how they are
- man setfacl
- man chown
- man chgrp
- man chmod
and by the way - the apache user should *not* own the files because typically a webserver should not be able to rewrite his content files in case of a security breach
2 of our webserver hosting companies told us that if we want to have files own by some other user account than apache, it is needed to have fastCGI..if not, than we need suPHP or suExec.
fire the company if they said this really in this way
CGI is needed instead mod_php to have own processes which is the base for suPHP and suExec but that has *nothing* to do with your problem above on your local test-setup which would be solved with the right permissions / ACL's
However it has been told that FastCGI provide also a performance increase so, we would like to reach it also :)
ok, fire them really
it is impossible that the webserver speaking via CGI/FCGI with a standalone PHP binary is faster than having PHP inside the httpd process and this sounds like a typical "webserver hosting company" knowing zero to nothing
So to clear the statement:
Goal: i'm trying to create at home a webserver for testing purposes, having the same behavior as webhosting companies offers. the purpose behind that it's to have a representative environment when testing to not have particular "surprises" with web application i developed when migrating them to production servers.
Situation: i installed on Fedora 18 a webserver where i need: - FastCGI - to use my standard fedora user account (let's say "rafnews") to edit/move/delete files/folder in my webroot /var/www/html folders, where files have 644 as permissions and folders : 705.
for now, all files/folders have correct permissions but owner is apache:apache
1. FastCGI settings: my webserver was running (on PHP 5.4, _not php-fpm_) correctly using the standard Apache 2.4 handler, now i'm trying to make use of FastCGI bit without success. Here is my php.conf file setting from apache 2.4.4:
DirectoryIndex index.php
php_value session.save_handler "files" php_value session.save_path "/var/lib/php/session"
i removed the addtype and handler as suggested on internet. I added in myvhosts.conf the following thing (withing <VirtualHost *:80> tag): <IfModule proxy_module> ProxyPassMatch ^/(.*.php(/.*)?)$ fcgi://127.0.0.1/var/www/html/info/$1 </IfModule>
where info is 1 subdirectoy of my webroot.
Apache starts, however when i want to access to webpage i get the following error (in vhost log dedicated to my website): [Fri Jun 14 14:16:07.827425 2013] [proxy:error] [pid 24500] (111)Connection refused: AH00957: FCGI: attempt to connect to 127.0.0.1:8000 (*) failed [Fri Jun 14 14:16:07.827539 2013] [proxy_fcgi:error] [pid 24500] [client 127.0.0.1:40982] AH01079: failed to make connection to backend: 127.0.0.1
Q1: my webserver (even if it is a local webserver for testing) has a fixe IP address. Should i use it in <ifModule proxy_module> tag instead of 127.0.0.1 ? Q2: port in error log is 8000, where can i set it ? is it possible to tell fastCGI to use standard 80 and to not conflict with standard http ? if yes how ?
2. suExec: While checking httpd logs i discovered that: [suexec:notice] [pid 24705] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
so it mean suExec is running on server. if i change all files/folders owner to "rafnews:rafnews" (files/folders in /var/www/html) apache do not work and no webpage is displayed.
so where is my mistake ?
thx.
Al.
Am 14.06.2013 14:33, schrieb Rafnews:
i'm trying to create at home a webserver for testing purposes, having the same behavior as webhosting companies offers. the purpose behind that it's to have a representative environment when testing to not have particular "surprises" with web application i developed when migrating them to production servers
which does not need more than having the same PHP version and the same settings in "php.ini" which can easily found out in the output of phpinfo() on the prouction server
you do not need a mass hosting environment to behave PHP scripts the same way as on wahtever server
Le 14/06/2013 14:33, Rafnews a écrit :
Situation: i installed on Fedora 18 a webserver where i need:
- FastCGI
- to use my standard fedora user account (let's say "rafnews") to
edit/move/delete files/folder in my webroot /var/www/html folders, where files have 644 as permissions and folders : 705.
for now, all files/folders have correct permissions but owner is apache:apache
Once again : apache don't need to "own" the files, only to be able to read them.
- FastCGI settings:
my webserver was running (on PHP 5.4, _not php-fpm_) correctly using the standard Apache 2.4 handler, now i'm trying to make use of FastCGI bit without success. Here is my php.conf file setting from apache 2.4.4:
DirectoryIndex index.php php_value session.save_handler "files" php_value session.save_path "/var/lib/php/session"i removed the addtype and handler as suggested on internet. I added in myvhosts.conf the following thing (withing <VirtualHost *:80> tag):
<IfModule proxy_module> ProxyPassMatch ^/(.*\.php(/.*)?)$ fcgi://127.0.0.1/var/www/html/info/$1 </IfModule>
Obviously when you use mod_proxy_fgid, you need to run FPM (the FastCgi Process Manager)
Apache starts, however when i want to access to webpage i get the following error (in vhost log dedicated to my website): [Fri Jun 14 14:16:07.827425 2013] [proxy:error] [pid 24500] (111)Connection refused: AH00957: FCGI: attempt to connect to 127.0.0.1:8000 (*) failed [Fri Jun 14 14:16:07.827539 2013] [proxy_fcgi:error] [pid 24500] [client 127.0.0.1:40982] AH01079: failed to make connection to backend: 127.0.0.1
qed.
Note default FPM port is 9000, not 8000. So you need to adapt ProxyPassMatch or FPM configuration.
Remi.
On Fri, Jun 14, 2013 at 03:07:16PM +0200, Remi Collet wrote:
for now, all files/folders have correct permissions but owner is apache:apache
Once again : apache don't need to "own" the files, only to be able to read them.
And in fact, letting apache write to files it doesn't need to is a big security risk.
Allegedly, on or about 14 June 2013, Rafnews sent:
Goal: i'm trying to create at home a webserver for testing purposes, having the same behavior as webhosting companies offers. the purpose behind that it's to have a representative environment when testing to not have particular "surprises" with web application i developed when migrating them to production servers.
And that is something I did years ago, for the same reasons you outline.
The files I serve from my webserver are owned by me. The CGI scripts the webserver runs are owned be me.
The directory permissions for the webserver, right back to the first directory in the path, have the "other" user permissions of readable and executable (user and group permissions don't matter, because they pertain to me, not the webserver). e.g. rwx---r-x This needs to be done with the /var directory, the /var/www/ directory, and any further sub-directories.
The file permissions for the webserver, for the files it will serve, have the "other" user permissions of readable and executable (again, user and group permissions don't matter, because they pertain to me, not the webserver). e.g. rw----r--
The script permissions *may* have to have the executable bit set, too, but that hasn't been the case with the scripts I were playing with. That'll probably depend on whatever handles the scripts.
If SELinux is enforcing restrictions on your server, then the SELinux contexts have to be appropriately set to allow it. This will be done, by default, if you directly create your webfiles in the normal places for serving them (in ~/public_html/ or in /var/www/html/), or if you copy files from somewhere else to either of those locations. The contexts will be wrong if you *move* files to those locations. In that case you will need to reset the SELinux attributes on those files to their defaults, after putting the files in place.
I have served files from ~/public_html/ and /var/www/html/ in this way for many years. To make life easier for me, I've either changed the ownership of /var/www/html/ to myself, so I can easily write files in the web root directories. Or, I've created a subdirectory that I own in /var/www/html/, for the same reason, and that's where I serve my test files from.
for now, all files/folders have correct permissions but owner is apache:apache
This is a VERY BAD IDEA. As various messages have said, mine included, servable files should be owned by the author, not apache. There are three file permission groups, owner, group, and other. The third group, "other," is what everyone else is allowed to do with the files, everyone else being whoever is not the individual-owner or the group-owner. These are the permissions that let apache read *your* files.
I'm not familiar with FastCGI, but just looking quickly at it, it looks like a replacement program so that *it* runs your CGI instead of Apache doing it. I don't know if that's a real advantage, or just a perceived one.
- FastCGI settings:
my webserver was running (on PHP 5.4, _not php-fpm_) correctly using the standard Apache 2.4 handler, now i'm trying to make use of FastCGI bit without success. Here is my php.conf file setting from apache 2.4.4:
DirectoryIndex index.php php_value session.save_handler "files" php_value session.save_path "/var/lib/php/session"i removed the addtype and handler as suggested on internet. I added in myvhosts.conf the following thing (withing <VirtualHost *:80> tag):
<IfModule proxy_module> ProxyPassMatch ^/(.*\.php(/.*)?)$ fcgi://127.0.0.1/var/www/html/info/$1 </IfModule>
where info is 1 subdirectoy of my webroot.
Apache starts, however when i want to access to webpage i get the following error (in vhost log dedicated to my website): [Fri Jun 14 14:16:07.827425 2013] [proxy:error] [pid 24500] (111)Connection refused: AH00957: FCGI: attempt to connect to 127.0.0.1:8000 (*) failed [Fri Jun 14 14:16:07.827539 2013] [proxy_fcgi:error] [pid 24500] [client 127.0.0.1:40982] AH01079: failed to make connection to backend: 127.0.0.1
Q1: my webserver (even if it is a local webserver for testing) has a fixe IP address. Should i use it in <ifModule proxy_module> tag instead of 127.0.0.1 ?
My guess would be that if it's acting as a proxy listening on 127.0.0.1 then you need to access your webbrowser through http://127.0.0.1/. If you prefer to use it's actual network IP address, then your configuration probably needs to specify that it listens on that address, too.
You may need to open up your firewall, too. It's probably blocking access. By this, I mean open up appropriate holes through it, not switch the entire firewall off.
If SELinux is enforcing restrictions on your computer, then you may also need to set options to allow access to the webserver on the ports that you're using. The defaults are probably to disallow it. They used to be, but I haven't looked at such settings on more recent Fedora releases to see what the defaults are.
Q2: port in error log is 8000, where can i set it ? is it possible to tell fastCGI to use standard 80 and to not conflict with standard http ? if yes how ?
If it's acting as a proxy, it may need to be on a different port than the webserver.
- suExec:
While checking httpd logs i discovered that: [suexec:notice] [pid 24705] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
so it mean suExec is running on server. if i change all files/folders owner to "rafnews:rafnews" (files/folders in /var/www/html) apache do not work and no webpage is displayed.
so where is my mistake ?
Probably permissions of the files you're trying to work with.
Before you start playing with CGI, or other scripting, first get flat file serving to work (i.e. static .html pages). Then, move onto the more complex things.
On Sat, Jun 15, 2013 at 12:20:16AM +0930, Tim wrote:
I'm not familiar with FastCGI, but just looking quickly at it, it looks like a replacement program so that *it* runs your CGI instead of Apache doing it. I don't know if that's a real advantage, or just a perceived one.
It's a real advantage when using any scripting language with startup overhead.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Le 14/06/2013 13:29, Reindl Harald a écrit :
However it has been told that FastCGI provide also a performance increase so, we would like to reach it also :)
Faster than CGI, probably, but nearly nobody use CGI nowadays ;)
ok, fire them really
it is impossible that the webserver speaking via CGI/FCGI with a standalone PHP binary is faster than having PHP inside the httpd process and this sounds like a typical "webserver hosting company" knowing zero to nothing
I agree. Especially when you have are mostly serving dynamic PHP files.
When you serve a lot of static files, and only a few PHP scripts, it could be faster to use FPM as this allow you to switch Apache in threaded mode (worker of event instead of prefork) where the mod_php is not really supported (even if still provided in Fedora).
But mod_php still the most flexible solution as it's the only one which allow you to use simply: alias (else you need 1 Proxy config per alias) multiviews (/foo/bar calling /foo.php) directoryindex (index.php) access right per directory ...
Remi.
On 14.06.2013 13:21, Rafnews wrote:
On 14.06.2013 13:18, Reindl Harald wrote:
Am 14.06.2013 12:35, schrieb Rafnews:
however using my standard fedora user account, Ii still can not edit/remove/move files/folders owned by apache user account. while searching on internet i discovered that fastCGI should allow me (using my fedora user account) to do such thing, even if files/folders are owned by apache user account
this has *nothing* to with mod_php oder fastcgi the permissions are how they are
- man setfacl
- man chown
- man chgrp
- man chmod
and by the way - the apache user should *not* own the files because typically a webserver should not be able to rewrite his content files in case of a security breach
2 of our webserver hosting companies told us that if we want to have files own by some other user account than apache, it is needed to have fastCGI..if not, than we need suPHP or suExec.
However it has been told that FastCGI provide also a performance increase so, we would like to reach it also :)
thx everybody for helping me. that's really interesting topic. till now i understood that suPHP or suExec exist just in order to allow user not having permissions to save/edit or remove files/folder from public_html where only apache had such permissions. it seems that my understanding was wrong.
thx
A.
On 06/14/2013 08:40 AM, Rafnews issued this missive:
On 14.06.2013 13:21, Rafnews wrote:
On 14.06.2013 13:18, Reindl Harald wrote:
Am 14.06.2013 12:35, schrieb Rafnews:
however using my standard fedora user account, Ii still can not edit/remove/move files/folders owned by apache user account. while searching on internet i discovered that fastCGI should allow me (using my fedora user account) to do such thing, even if files/folders are owned by apache user account
this has *nothing* to with mod_php oder fastcgi the permissions are how they are
- man setfacl
- man chown
- man chgrp
- man chmod
and by the way - the apache user should *not* own the files because typically a webserver should not be able to rewrite his content files in case of a security breach
2 of our webserver hosting companies told us that if we want to have files own by some other user account than apache, it is needed to have fastCGI..if not, than we need suPHP or suExec.
However it has been told that FastCGI provide also a performance increase so, we would like to reach it also :)
thx everybody for helping me. that's really interesting topic. till now i understood that suPHP or suExec exist just in order to allow user not having permissions to save/edit or remove files/folder from public_html where only apache had such permissions. it seems that my understanding was wrong.
For clarification, FastCGI runs PHP as a separate process rather than as part of Apache ("mod_php5"). It forks PHP off, then communicates with the PHP instance via either Unix-domain sockets or TCP connections. PHP returns results back over that pipe which Apache then presents to the browser.
This permits you to use one of the multithreaded MPM models of Apache (e.g. "worker" or "event"), thereby giving you the increased performance. Note that you are HIGHLY cautioned to NOT use one of the multithreaded MPMs when running PHP as a part of Apache. The problem is that PHP is not thread safe (well, PHP itself is, but depending on what PHP is built with, some of the libraries it uses aren't thread safe). Running PHP as a separate process permits you to run Apache multithreaded but keep PHP single-threaded.
You can also run PHP as a different user than Apache is. For example, we typically run Apache as user "apache" but PHP as user "admin". You can then have different file ownerships for static content (owned by "apache") and dynamic content (owned by "admin"). Since files would be written by PHP, the directories that might be poked would only have to have write permissions granted for "admin".
If you want even more security, you can have PHP run on a physically separate box than Apache is running on. You use TCP connections to communicate between them. Only the machine running PHP needs write access to the content, so you put the dynamic content on the PHP box and use an NFS read-only export to the web server boxes. That way the webservers can't poke the content at all. If you manage the security on the PHP box well (e.g. don't expose it to the Internet), then you are fairly secure.
"Just because I'm paranoid doesn't mean they aren't out to get me!"
In our experiments, we've also found that using PHP-FPM to manage PHP is superior to using the various other methods. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Political Correctness: The insane doctrine that postulates that it - - is entirely possible to pick up a turd by the clean end. - ----------------------------------------------------------------------
-
Matthew Miller -
Rafnews -
Reindl Harald -
Remi Collet -
Rick Stevens -
Tim