|
"Infernal Server Error” (That’s NOT a sprelling mistake!)
Hi People,
Now been through some 16 re-attempts at Magento installation on a ‘HostingBay’ server in Oz (albeit I’m in the UK).
Initially there were three compatibility problems shown up by the magento-check.php which I referred to the server crew and they fixed.
The check now Congratulates me on using a compatible system.
So, I run the Install/Download extracted from the ‘magento-downloader-1.1.3.zip’ file and uploaded.
Whilst I can’t find any reference to suPHP or phpsuexec in the phpinfo report - the system goes directly to ‘Internal Server Error’ (500) If the Magento subdirectory has 777 rights OR any of the advised ‘uncomment’ changes to .htaccess.
With the directory set to 755, phase one will run ending with the “Download completed. You can proceed with installation” message, and [Continue Magento Installation Button]… But that’s it, Whatever I’ve tried regarding permissions and variations to .htaccess (from comments, suggestions and ideas springing from going through the destructions and forum posts) - I can’t get anything other than the ‘InFernal Server Error’ from there on.
The initial process log probably IS telling me where it hurts - but I’m not conversant with the CGI/pearl commands going on…
After the first line comment there are three warnings, everything else appears to download/install successfully.
Do the warnings declare the problem? Can any of you spot the obvious mistake… like User skipped brain engagement phase?
The warnings / initial part of log =
Did not download optional dependencies: pear/XML_RPC, use --alldeps to download automatically
Warning: popen() has been disabled for security reasons in /home/digit875/public_html/go/downloader/pearlib/php/OS/Guess.php on line 247
Warning: fgets(): supplied argument is not a valid stream resource in /home/digit875/public_html/go/downloader/pearlib/php/OS/Guess.php on line 248
Warning: pclose(): supplied argument is not a valid stream resource in /home/digit875/public_html/go/downloader/pearlib/php/OS/Guess.php on line 256
pear/PEAR can optionally use package “pear/XML_RPC” (version >= 1.4.0)
------------------------------------- all clear / ok from here -------------------------
Your help and comments would be appreciated.
Nigel
[tag Genisys (Generic Information Systems)]
------------------------------------------------
Update 25th August 2008
Problem Resolved: Directory Permissions, some more Directory Permissions, Yet More Directory Permissions (and maybe a few file permissions), and a php.ini problem.
It would seem that the server the site is on really doesn’t like you leaving a potential security threat in the form of 777 permissions.
Initially the Install would only produce an ‘Internal Server Error’ Page.
When that was cleared by changing the /Downloads directory (and its subs) permissions (chmod) from 777 to 755 - the download/install ran ok.
So, then you get the [proceed] button - but the download/install in the meantime has created a lot of new directories - all with 777 permissions, so you need to use FTP or cPanel to sort these out before clicking that [proceed] link.
Ok, so maybe you can now get as far as the configure screen. In my case I couldn’t.
During earlier searching through forum posts regarding compatibility, I had come across an item that suggested a fix (in relevant circumstances where the path to resources was causing the system to declare that essential modules didn’t exist) - was to add a php.ini file - within which should be the line “php_flag short_open_tag on”: This was still in my Magento subdirectory.
The result was that whilst the overall site passed the magento-check.php routine, the same check from the Magento subdirectory reported that there was no PDO/MySQL functionality.
The Directory permissions were 755, there were no obvious conflicts in the relevant .htaccess files - so why was it OK on the site, but not in the Magento Directory?… Removed the php.ini - and full compatibility returned.
Now - finally through to the Admin Screen (Dashboard)… But none of the links worked.
There are a number of threads on this subject elsewhere.
But in short… Directory permissions again. The Javascript directories had been missed in the earlier 777 to 755 chmod changes.
Hence the Drop-Down menus weren’t working. Changed those… And finally I can get into the site management.
Hoping this will help others with the same or similar problems.
It obviously depends on the Hosting set-up.
Mine (at HostingBay-Melbourne-Australia) is Linux, Apache, MySQL, PHP5 (all with compatible versions, extensions & modules).
But this protection against security risks (which is good… IF you know about it) has caused three very long days of struggle.
Good luck with yours.
-------------------------------------------------------------------------
Further update 5th September 2008
3 Days doing CHMODS ! - Why don’t the FTP client programs do recursive permission setting ?
The supposed command line CHMOD -R directory/file to do this - fails (on the server I’m using)
returning a ‘no such Directory’ response.
Found that some FTP progs do offer recursion… but then do both files & folders the same… UGH!
Ahh! - Found ‘FlashFTP’ (flashfxp.com) - and… THIS IS THE ANSWER
It will CHMOD the entire tree from where you want - setting folders to one selection and files to another !!!!
Gosh, I wish I’d found this two weeks ago.
regards to all,
Genisys
|