On 14.06.2013 13:18, Reindl Harald wrote: 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 :)

On 14.06.2013 13:29, Reindl Harald wrote: 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.

Le 14/06/2013 14:33, Rafnews a écrit : Once again : apache don't need to "own" the files, only to be able to read them. Obviously when you use mod_proxy_fgid, you need to run FPM (the FastCgi Process Manager) qed. Note default FPM port is 9000, not 8000. So you need to adapt ProxyPassMatch or FPM configuration. Remi.

Allegedly, on or about 14 June 2013, Rafnews sent: 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. 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. 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. If it's acting as a proxy, it may need to be on a different port than the webserver. 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. -- [tim@localhost ~]$ uname -rsvp Linux 3.8.13-100.fc17.x86_64 #1 SMP Mon May 13 13:36:17 UTC 2013 x86_64 All mail to my mailbox is automatically deleted, there is no point trying to privately email me, I will only read messages posted to the public lists. George Orwell's '1984' was supposed to be a warning against tyranny, not a set of instructions for supposedly democratic governments.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 14/06/2013 13:29, Reindl Harald a écrit : Faster than CGI, probably, but nearly nobody use CGI nowadays ;) 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 06/14/2013 08:40 AM, Rafnews issued this missive: 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(a)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. - ----------------------------------------------------------------------