I wanted to setup PHP on my IIS server (Server 2012). Used the Web Platform Installer (because my server knowledge is nearly none) to install some PHP versions and activated 5.4.24 as the current one. Afterwards I enabled CGI by going into Handler Mappings. When I then try to run a basic php script just an echo "test" or phpinfo() I get a 500 server error.
I've gone through several of the topics already on google or stackoverflow but so far I haven't really found a point to start looking into this further. Can this be something related to rights? Because after I installed PHP plesk also failed which was due to rights not being set.
One possible cause is that when the PHP handler was configured on IIS, the access to the PHP CGI executable (C:\Users\lextudio\Downloads\php-8.1.9-nts-Win32-vs16-x64\php-cgi.exe) was not properly set up.
One quick solution is to grant IIS_IUSRS group read access on the folder (C:\Users\lextudio\Downloads\php-8.1.9-nts-Win32-vs16-x64).
Related
Let me begin by saying that I am very new to Microsoft's Internet Information Service. I need to setup IIS on my PC and it should also execute PHP files. So far I got everything installed and running - the latest PHP and enabled IIS service. I can view the Default Webpages (*.html) files ONLY. It will not execute PHP files. If I try to request any PHP files, I get 403 error.
I have been researching online and seems to be more confused about setting up PHP (extension) on IIS. Some websites say you need to configure PHP through its MANAGER. Others say I need to add Role and FastCGImodule through IIS manager. According to Microsoft I need to rename php.ini-development to php.ini and point php to some DLL file.
I am using Windows 8, IIS 8.5 and PHP 5.6. I hope someone could point me in the direction.
You can set this up manually or with the IIS Manager. I would set this up my own, so you know whats going on.
You will need to setup the CGI role feature. This includes FastCGI. Here is some information how to do that: http://www.iis.net/configreference/system.webserver/cgi
Then you will need the PHP package somewhere. Lets say in C:\PHP. You can change that if you want.
You will need the fastCGI settings. You can easily set this up by commandline:
%windir%\system32\inetsrv\appcmd set config /section:system.webServer/fastCGI /+[fullPath='C:\php\php-cgi.exe',activityTimeout='1200',requestTimeout='1200',arguments='-c%20C:\php\php.ini']
This example uses a timeout of 20min.
This will set the handler:
%windir%\system32\inetsrv\appcmd set config /section:handlers /+[name='PHP_FastCGI',path='*.php',verb='*',modules='FastCgiModule',scriptProcessor='"C:\php\php-cgi.exe|-c%20C:\php\php.ini"',responseBufferLimit='0',resourceType='Either']
php.ini setup:
[cgi-fcgi]
fastcgi.impersonate=1
cgi.force_redirect=0
cgi.fix_pathinfo=1
For write access you will need to grant "modify" access for the the IURS.
More Information: http://php.net/manual/de/install.windows.iis7.php
I did try the answer posted to heart, but I kept running into problems. In fact, I also followed the Microsoft step by step PHP setup tutorial to the TEETH. I still couldn't get PHP working on my IIS. Although Microsoft warned against using Windows Platform Installer(WPI), I downloaded WPI and ran the installer. Under frameworks, I found PHP 5.6 and clicked on Add button. Then, clicked on the Install button. It took only about 30 seconds to install. Just to be sure. I checked IIS manager and there it was PHP Manager. After opening PHP manager I noticed that all the settings were there and enabled and it already had 15 different extension enabled. Plus, it also had about 35 extension disabled, but it gives you option to enable them right there.
Now, my PHP files are rendered as expected. I even did phpinfo(); and the browser displayed all the PHP settings and information. :)
Firstly forgive me if my terminology isn't entirely accurate. I have only limited knowledge on this subject, but will best try to convey the problems we are having. My server administrator is trying to deploy php 5.5.9 on a live server. Originally the intention was to install php 5.4.x, but we opted for the latest version instead (a manual compile is required regardless due to the o/s)
The O/S is OpenSuse 12.1 and the server is a Plesk server (Plesk Version 11.0.9) with Apache 2.2.1. This particular o/s does not have the ability to update php automatically so everything has to be done manually. Since we didn't want to risk screwing up the server (currently running with php 5.3.8), we opted to install a second version of php alongside the current one. The instructions we followed are outlined here: http://kb.parallels.com/en/114753
After numerous failed attempts due to missing libraries during compilation, we were finally able to compile php 5.5.9 without error and then proceeded to run tests with 'make test'
Unfortunately, the test results came back with 32 failures and 20% of the total tests were skipped. A total of 13011 tests were done, 10410 of which were completed. The TEST SUMMARY can be downloaded from here: http://uploaded.net/file/v6ug55l8
Anyway, deciding we might aswell give it a try, we applied the changes as indicated in the first link above to the vhost.conf. However, it didn't work, and the vhost then returned Internal Server Errors for every page regardless of script or extension. The errors logs sadly do not indicate any errors, only a whole ton of internal server errors recorded by mod_security. We did notice a huge number of these in the error log: Warning: SuexecUserGroup directive requires SUEXEC wrapper. But, it doesn't seem to be related, as the same error goes back several weeks.
So, we're stuck without any idea what to do next. Our next attempt will be to try and compile a php 5.4.x instead, as perhaps something is bumping heads with 5.5.9...
Any and all advice will be appreciated. As per the opening statement, I'm not an expert here, so if you need any additional information about the machine and it's server, feel free to ask. Thankyou for your attention!
Problem solved. The vhost's CGI-BIN needed to be CHMOD 755 and not 775.
I run simpleSamlPHP 1.9 on a PHP 5.3.9 installation in EasyPHP, on a Windows XP machine. SimpleSamlPHP is serving as a SAML identity provider, fetching users in a local MySQL database.
My problem is that when requesting authentication against this IdP, Apache crashes throwing a "violation access" error, a.k.a. segfault. The problem is similar to this thread except that the child process exits with status 0 (but isn't this a Windows-specific feature of PHP regarding exit codes ?).
The common fix, copying libmysql.dll and php5apache2.dll in C:\Windows\system32, doesn't help.
Running VC++6 just-in-time debugger doesn't give me any information about which module is incriminated :'(
I tried to disable as much PHP extensions as I could. SimpleSamlPHP needs openSSL and PDO/MySQL, thus I kept only those 2 enabled, and crash happens anyway. I checked separately that using openSSL and MySQL works fine.
Finally I have to precise that the machine hosts 3 instances of PHP, including 2 in EasyPHP (2 separate installs), but only the concerned instance is active when the crash happens.
Any leads ?
Cheers
Did you run php with apache's mod_php? I had the same situation here. It always crashes when a sp authentication comes in. I have no idea how this happened. But at the end, I avoided the problem by running php in FastCGI mode.
I am trying to get a trial copy of the aMember membership management system running on my local dev machine, which is Windows 7 64-bit with IIS 7.5. I have MySQL 5.5.10 and PHP 5.3.6, the latter which I installed using the Windows installer package. It seems fine.
The aMember package has a tester.php script which I ran, and it gave an 'OK' result, despite its output being full of error messages related to Function eregi() is deprecated. I then ran the setup.php script, which seemed to run properly. It took me through one or two screens of gathering e.g. login information for MySQL, and then said it was completed and offered me links to some aMember admin pages. None of these links work, and clicking any of them results in an Internal Server error (HTTP 500): An unexpected condition was encountered while the server was attempting to fulfill the request.
What can I do to further diagnose this error, short of placing lots of diagnostic writes in the php pages themselves? Tools at my disposal are Aptana Studio and Visual Studio, although I doubt the latter is any use here. I have logged the issue with aMember support, who quickly asked for my server logs, and then disappeared.
My first port of call here would be to enable Failed Request Tracing:
Troubleshooting Failed Requests Using Tracing in IIS 7
Troubleshoot with Failed Request Tracing
I am also suspicious about your PHP install. As a rule of thumb never use the installers. They never seem to do the right thing.
I would tear down your PHP install and start from scratch using these steps:
Using FastCGI to Host PHP Applications on IIS 7
FastCGI + the Non-threadsafe build of PHP (5.2 or 5.3) is the definitive way to install and configure PHP on IIS7.
The aMember trial software uses encoded PHP which requires IonCube to decode. I had installed this, but it seems the installation had failed, as a subsequent installation remedied the problem. I was initially stumped because after installing IonCube, I ran the aMember test script which told me IonCube was installed. aMember support responded that:
unfortunately tester script is not handle situation with dynamic loading correctly.
PHP from 5 version do not allow to load libraries dynamically if these libraries are not in php lib folder. So you have to install IonCube or Zend into server php.ini'
I don't know why that can't build a warning into the test script.
PHP v5.2.8
Windows Server 2003 SP2 (IIS 6, I believe, though I can't find a version # anywhere in IIS manager)
The full error is:
"CGI Error
The specified CGI application misbehaved by not returning a complete set of HTTP headers."
I installed the WAMP stack from bitnami.org, and the PHP pages work completely fine when visiting via Apache, which I have running on port 8888. However, due to network configuration and firewall reasons, I have to get this working on the IIS server on port 80. There are other websites running on port 80, including a default website that can't be changed. Unfortunately, I also have to have this running as a virtual directory, such as www.myserver.com/phpapp, instead of as it's own website such as phpapp.myserver.com. The reason for this is that the firewall, beyond my control, requires new passthrough rules to allow access on a new subdomain.
This same WAMP stack from Bitnami is working fine on another server when the php app runs as it's own "website" in IIS, since I can add a new PHP ISAPI filter - but that tab/option is not available on virtual directories.
I've installed the php "Web Service Extension" in IIS Manager. I have tried both php-cgi and the php5isapi.dll in the web-service-extensions. Furthermore, I have tried both of those as the "application extension" under the websites "configuration" mappings.
I've also tried mix/match combinations of the php5isapi.dll and php-cgi.exe for the "web service extensions" and the websites "configuration" extension mappings.
I've tried tweaking a few things in php.ini, (including making sure the doc_root is blank). However, as I mentioned before, this website works fine when visited via the Apache port. IIS points to the exact same directory.
What on earth is causing this error? I've spent quite a bit of time searching online, and it seems this error pops up for a few different reasons. If one had a PHP app that did a raw write to the response without writing the headers first would cause this error. Some PHP apps can cause this error when there is a PHP error resulting in some malformed redirect.
My php error logs are missing in action. In my php.ini I have
error_reporting = E_ALL
display_errors = On
log_errors = On
display_startup_errors = On
error_log = "c:\temp\php.error.log"
But there is never a log file in c:\temp. I also tried escaping the slashes, and tried forward slashes in the path, and the log file never shows up.
Again, I feel compelled to mention that this all works fine via apache, so it doesn't seem like PHP itself is bailing due to some strange configuration (even though I can't find the log file) Not to mention this is the same php.ini that I use on the other computer where this is working fine via IIS (where the php app is it's own "website" instead of a virtual directory).
I don't know what other info to provide - but I'm at my wits end after battling this off and on for several days. If I drop an HTML page in, I can visit that just fine via IIS under this virtual directory. What can be causing this?
The app I'm trying to run is vBulletin. Not sure that it matters a whole lot other than to give credence to the correctness of the PHP in the app.
This should have solve all it, takes care of these issues.
IIS Aid PHP Installer
http://www.iis-aid.com/iis_aid_php_installer