Installation script can't find index.php file (wrong path)

Next topic

Author	Message
Ben Devonport	Sunday 03 July 2005 3:09:18 pm Hello, May is there some one who can help me with this issue. After I was uploading all files on to the server and tryed to install eZ, ez can't find the image files and dont let me intall eZ looks like brocken links but this can't be the case. It's just pointing (jumping) into the wrong directory or so ?!? http://67.15.60.59/67.15.60.59/protech-golf.com More details http://67.15.60.59/67.15.60.59/protech-golf.com/phpinfo.php my provider told me to change the .htaccess into <Files "/home/httpd/vhosts/protech-golf.com/httpdocs/index.php"> Options +Includes SetOutputFilter INCLUDES AcceptPathInfo On </Files> but I have still no luck :-() After this he told me I had to change the eZ script: >> Judging from what I saw previously it is not an AcceptPathInfo issue, rather that the actual scripts configuration is for the domain name not hte IP, which would cause issues. The best way to procced is to point the domain and access the script directly or change the scripts config to match the URL you are accessing it from. " May has some one an idea what I have to change ? Thanks a lot for your help. Ben pixeltransfer design studio Auckland New Zealand Aotearoa pixeltransfer (at) yahoo.de
Daniel Beyer	Monday 04 July 2005 8:30:16 am Hi Ben, form your phpinfo() it looks like you're using php4 not as a module. One of the requirements of eZ publish is, that you use php as a module. The CGI-Version just won't work. See: http://ez.no/ez_publish/info/requirements_for_ez_publish Actually there is some issues with those variables set by php (found in your phpinfo()): _SERVER["REQUEST_URI"] /phpinfo.php _SERVER["SCRIPT_NAME"] /phpinfo.php _SERVER["PHP_SELF"] /phpinfo.php This simply is false. It has to be: _SERVER["REQUEST_URI"] /67.15.60.59/protech-golf.com/phpinfo.php _SERVER["SCRIPT_NAME"] /67.15.60.59/protech-golf.com/phpinfo.php _SERVER["PHP_SELF"] /67.15.60.59/protech-golf.com/phpinfo.php Seems like something is wrong with your configuration - either in apache or in php. Or this is beacuse you use php4 not as a module in apache. At least it could be something your provider had done to php or apache, too. Tell him that especially those vars are set wrong by php and you don't have a clue how to fix that. Daniel Beyer _________________________________ YMC AG Kreuzlingen, Switzerland web: www.ymc.ch ____________________________________
Björn Dieding@xrow.de	Monday 04 July 2005 10:36:35 am ----------- One of the requirements of eZ publish is, that you use php as a module. The CGI-Version just won't work. ----------- eZ also works under CGI. Though you could be facing various other problems. Like permission issues... Looking for a new job? http://www.xrow.com/xrow-GmbH/Jobs Looking for hosting? http://hostingezpublish.com ----------------------------------------------------------------------------- GMT +01:00 Hannover, Germany Web: http://www.xrow.com/
Daniel Beyer	Monday 04 July 2005 11:25:52 am Hi, if Björn says eZ publish works with php4_cgi than you can trust him. The problem lays in the wrong variables in which some part of the path is missing. I suggest you talk to your provider, maybe he knows whats wrong with it. But hacking eZ publish to solve this issue isn't really a good idea... Daniel Beyer _________________________________ YMC AG Kreuzlingen, Switzerland web: www.ymc.ch ____________________________________
Ben Devonport	Monday 04 July 2005 4:20:29 pm Hallo Many thanks for that, I went back to my provider and he told me: " That is not the path of the 'eZ_setup_top.png' file being shown on 360sports.co.nz/ the CURRENT path: http://67.15.60.59/design/standard/images/setup/eZ_setup_top.png The one you provided: http://67.15.60.59/67.15.60.59/360sports.co.nz/design/standard/images/setup/eZ_setup_top.png As the domain is pointing to the server you do not need to use the temp URL, you can instead simply use the domain. You can most likely fix this by opening the config file and changing the configuration. " I'm not sure what else I can ask him to do ?!? :-() I was looking into setup.ini and kickstart.ini and getting totally lost - I'm worry if start to make any changes there the whole site will not work any more ... Could some one help a me please !!!? before I'm running mad :-() Many thanks/danke/merci Ben pixeltransfer design studio Auckland New Zealand Aotearoa pixeltransfer (at) yahoo.de
Daniel Beyer	Monday 04 July 2005 8:04:24 pm Good morning Ben, if I get your provider right the address "http://67.15.60.59/67.15.60.59/360sports.co.nz/" is only a temporary one. I think this address is created by using some weird rewrite-rules, that apache or php can't understand. The problem will solve itself if you connect a domain to 67.15.60.59. Actually the domain 360sports.co.nz is connected on server 210.55.4.14 and not on 67.15.60.59.. I told my notebook that it should use 67.15.60.59 for 360sports.co.nz and that solved your problem. What you have to do is connecting the domain to server 67.15.60.59. This is done via DNS-entries to which you probably have no access. Talk to your provider(s) to change that for you. But -as me- you can force your computer to think 360sports.co.nz is connected on 67.15.60.59. To do that you can add this line to your hosts-file (in most Linux-Distribution located at /etc/hosts): 67.15.60.59 360sports.co.nz After that clean your dns-cache or reboot your computer. If you're using Windows you can do this,too. The hosts-file in Windows is located at \WINDOWS\system32\drivers\etc\hosts. The layout of this file is almost the same as in linux. And the same entry should do the job: 67.15.60.59 360sports.co.nz After that you need to restart your computer. This is the only way I know to get windows to clean its dns-cache. If you now access http://360sports.co.nz/index.php you should see the setup-page with all its nice images. Note: Forcing your computer to use an other IP for a domain might not work. A reason for this is probably a proxy between your computer and the remote server. Attention: You might discover that 8MB script-limit in php will result in a Fatal Error in eZ publish. But this is an other issue. I suggest you ask your provider for some more memory... Daniel Beyer _________________________________ YMC AG Kreuzlingen, Switzerland web: www.ymc.ch ____________________________________
Ben Devonport	Wednesday 06 July 2005 4:40:20 pm Many Thanks for all this information so far - to get eZ installed on a external linux webserver is like David vs. Goliath I belive - I had no idea before :-()?!?@ I mean I was installing eZ before on my own server without any changes of anny default settings - so I was very optimistic to get this also done on a external box - but now it's more ending up in a battle with the system I will keep you posted :-) Cheers Ben pixeltransfer design studio Auckland New Zealand Aotearoa pixeltransfer (at) yahoo.de
Ben Devonport	Thursday 07 July 2005 2:10:31 pm Hello all, after I was gettign Ez up and running after 1 week hard work,I received an email from my webhost admin: " I was watching our server load and whenever webbellis.co.nz is invoked it attempts to use 100% of the available CPU, if it was on a dedicated server that would be fine but on a shared server that means other sites are affected when it starts using 90%+ of the available CPU for a single apache instance. Unfortunatly this means we cannot host this script and it must be removed immediatly. Regrettably this is not negotiable. Here is some evidence: 22796 apache 23 0 42716 41M 7860 R 88.9 4.1 0:22 0 httpd (The 88.9 is the % CPU usage from process 22796) And here is the site responsible for the 22796 PID: 11-0 22796 0/42/42 W 12.81 22 0 0.0 0.42 0.42 219.89.194.16 webbellis.co.nz GET /index.php/plain_admin/content/view/full/43 HTTP/1.1 I'm stucked - has some on an idea what to do ? I mean this website is not the website of the BBC with 1.5 mio hit per day or so ? I don't no what to do any more :-() Ben pixeltransfer design studio Auckland New Zealand Aotearoa pixeltransfer (at) yahoo.de
Daniel Beyer	Thursday 07 July 2005 3:58:09 pm Hi Ben, three things you can do: 1. Get in contact with your provider and suggest him to use a php-accelerator. This will lower his cpu usage and increase the speed of eZ publish. 2. Get an own server or search for an other provider. 3. Setup eZ publish correct. To 1.: He will tell you, that he can't install such a thing as it might break the php-scripts of other users. (Not every php-script is compatible with an php-accelerator). To 2.: There are some hosters out there, that have full support for eZ publish. You can find some of them on ez.no. We are acctually running own servers for eZ publish (professional ones with dual-Xeon CPUs, SCSII-Raids, tons of RAM, etc.). It's just fun to have eZ publish on these as it is very fast - especially with a php-accelerator. And no one complains of too much CPU-load! A tip might be a hoster like http://www.vserver.de . They provide a virtual own server with full root-access. Those server might be kind of slow, but nobody complains about the CPU-usage. And you can install what ever you want on them. To 3.: Did you chmod your directories? When I visited your site it take much time to display a page. This might be because of a very slow server. But it's more likely, that you simply forgot to chmod some directories in eZ publish. If you didn't do that eZ publish can't store the cache. So everytime the page is loaded the cache has to be generated, what takes time _and_ much CPU-load. If you have shell access to the remote server, than run at least bin/modfix.sh from the eZ publish root - or better follow the chown-suggestions "bin/modfix.sh" makes. If you do not have shell access than chmod 777 the following directories (e.g. with a FTP-Client): var/cache (delete everything what is in this directory) var/storage (and every folder/file in there) var/log (and every folder/file in there) var/webdav (Create this directory if you want to use webdav.) Daniel Beyer _________________________________ YMC AG Kreuzlingen, Switzerland web: www.ymc.ch ____________________________________
Ben Devonport	Thursday 07 July 2005 10:54:29 pm Hi Daniel, many thanks for your suggestions - I forwarded your comments to my web admin and we will see what he can do. He gave me the spec of the server as : The server you are on is a 2.4Ghz Pentium IV with 1GB ram and is located in the US. is this is not fast enough ? Cheers Ben pixeltransfer design studio Auckland New Zealand Aotearoa pixeltransfer (at) yahoo.de
Ben Devonport	Sunday 10 July 2005 6:33:45 pm Hi Daniel, I've done the changes you asking for but I have still the problem of the server load, ms sysadmin came back to me with the advice below: "I invoke open www.webbellis.co.nz, this was done when the server load was around 0.3. 8240 apache 21 0 43588 37M 7940 R 96.0 3.7 0:08 0 httpd 96.0 is the % of CPU the script is attempting to use." Do you have any idea what else I can do re server load ? Cheers Ben pixeltransfer design studio Auckland New Zealand Aotearoa pixeltransfer (at) yahoo.de
Daniel Beyer	Monday 11 July 2005 12:20:56 am Sorry Ben, there is nothing more you can do. Your eZ publish is loading quite fast. As you can see in the debug the server need about 1 second to generate the html-view. This shouldn't be a problem for you provider, as you generate high cpu load only for a short moment. Even in a shared environment this shouldn't be a problem. The only thing to reduce the CPU-Load would be a multi-processor system. If your provider allows access to php on his servers, than he has to live with the fact, that some scripts will always generate some cpu-load. It his his job to guarantee, that his customers have a stable an fast environment. If a system gets slow he has to make sure, that it keeps usable for all of his customers - either by limiting ressource (eg. limiting the total runtime of php) or by buying better or more hardware. A friend of mine had a similar problem with his provider. He had a self-scripted cms running in a shared environment. And his provider started to make problems, when his site became pretty popular with several thousands hits a day. But in fact the provider couldn't do anything about it, as my friend used his account just in the way he bought it from him. The end of that story was, that the provider made an offer for an own server for his account to a pretty low price, just to get him off of the shared environment. One thing may left for you to reduce the cpu load: You could make use of the static cache. But this needs some server-side configuration. And it will take very high cpu-load each time the static cache is generated. But the load the page itself generates would be reduced to a minimum, as php won't be used any longer to display pages from the static cache (the static cache consists of simple html-pages). Daniel Beyer _________________________________ YMC AG Kreuzlingen, Switzerland web: www.ymc.ch ____________________________________