New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Here is the info you want (I hope)
84.92.xxx.xxx - - [12/Jan/2014:15:52:42 +0100] "GET / HTTP/1.1" 200 418 "http://lowendtalk.com/discussion/19859/why-should-i-change-from-centos-to-debian-if-any-reason#latest" "Mozilla/5.0 (Linux; U; Android 4.3; en-gb; GT-N7100 Build/JSS15J) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30" 81.152.xxx.xxx - - [12/Jan/2014:15:55:45 +0100] "GET /wp-admin/ HTTP/1.1" 200 5980 "http://lowendtalk.com/discussion/19859/why-should-i-change-from-centos-to-debian-if-any-reason" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36" 81.152.xxx.xxx - - [12/Jan/2014:15:55:45 +0100] "GET /favicon.ico HTTP/1.1" 404 209 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36" 217.171.xxx.xxx - - [12/Jan/2014:16:06:15 +0100] "GET /wp-admin/ HTTP/1.1" 200 5980 "http://lowendtalk.com/discussion/19859/why-should-i-change-from-centos-to-debian-if-any-reason" "Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.72 Safari/537.36" 217.171.xxx.xxx - - [12/Jan/2014:16:06:15 +0100] "GET /favicon.ico HTTP/1.1" 404 209 "-" "Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.72 Safari/537.36" 217.170.xxx.xxx - - [12/Jan/2014:16:37:12 +0100] "GET / HTTP/1.1" 304 - "-" "Mozilla/5.0 (Windows NT 6.2; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0" 217.170.xxx.xxx - - [12/Jan/2014:16:37:58 +0100] "GET /wp-admin/ HTTP/1.1" 304 - "-" "Mozilla/5.0 (Windows NT 6.2; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0" 217.170.xxx.xxx - - [12/Jan/2014:16:38:18 +0100] "GET / HTTP/1.1" 304 - "-" "Mozilla/5.0 (Windows NT 6.2; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0" 217.170.xxx.xxx - - [12/Jan/2014:16:38:19 +0100] "GET / HTTP/1.1" 304 - "-" "Mozilla/5.0 (Windows NT 6.2; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0" 217.170.xxx.xxx - - [12/Jan/2014:16:38:20 +0100] "GET / HTTP/1.1" 304 - "-" "Mozilla/5.0 (Windows NT 6.2; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0"
and error log
[Sun Jan 12 15:37:41 2014] [error] [client 217.170.xxx.xxx] File does not exist: /home/test1/public_html/favicon.ico [Sun Jan 12 15:37:41 2014] [error] [client 217.170.xxx.xxx] File does not exist: /home/test1/public_html/favicon.ico [Sun Jan 12 15:37:48 2014] [error] [client 217.170.xxx.xxx] File does not exist: /home/test1/public_html/install [Sun Jan 12 15:52:13 2014] [error] [client 84.92.xxx.xxx] File does not exist: /home/test1/public_html/favicon.ico, referer: http://test1.myhken.com/wp-admin/ [Sun Jan 12 15:55:45 2014] [error] [client 81.152.xxx.xxx] File does not exist: /home/test1/public_html/favicon.ico [Sun Jan 12 16:06:15 2014] [error] [client 217.171.xxx.xxx] File does not exist: /home/test1/public_html/favicon.ico
I spot some difference (using Word 2010 and compare files), you or somebody else mention
short_open_tag =
that was set to off on CentOS and on on Debian. Changed it, rebooted, still only a blank page.Then I copied to whole php.ini from Debian to Centos, rebooted, but still only a blank page.
One other difference from Debian to CentOS is that on Debian I have three php.ini files:
/etc/php5/apache2/php.ini Configuration for mod_php
/etc/php5/cgi/php.ini Configuration for scripts run via CGI
/etc/php5/cli/php.ini Configuration for command-line scripts
But on CentOS I have only one file:
/etc/php.ini Global PHP configuration
Have only compared /etc/php5/apache2/php.ini with /etc/php.ini
Any other good ideas? If not, I'm will try IUS Community, and if that don't work, I will continue using the "old" PHP version in CentOS.
If there is no security reason to why I should go from CentOS to Debian, I will stop this project now.
PHP 5.3.x is soon EOL, so you need upgrade to newer version.
I have done some more testing with Virtualmin. And Virtualmin do not want to install on a server with PHP 5.4 or 5.5 installed on it. First I tried only installing PHP and Mysql before the Virtualmin installation. That did not work. Then I reset the VPS, then I installed LAMP with this guide: https://www.digitalocean.com/community/articles/how-to-install-linux-apache-mysql-php-lamp-stack-on-centos-6 then I updated PHP with Remi. But again, I cant even install Virtualmin on a server with updated PHP.
So I think the problem maybe is Virtualmin related?
Perhaps, but as I don't use Virtualmin, I wouldn't know what to check. It seems strange that a clean install of Wordpress wouldn't work on a clean install of CentOS with the latest PHP 5 packages. One test you could try doing is creating a phpinfo.php file with:
<?php phpinfo(); ?>
And seeing it it'll run on your test server. If you view the source of the "blank" page, do you see the PHP code or is it just completely empty?
try running the index page of the blog from a ssh session:
and see if there are some warning/errors that can help you.
I can see the source code, but the page is "blank" on every web browser I have (Firefox, Chrome and IE 11)
It's also only is a blank page... http://test1.myhken.com/phpinfo.php
[root@test1 public_html]# php index.php PHP Warning: Cannot modify header information - headers already sent by (output started at /home/test1/public_html/wp-config.php:1) in /home/test1/public_html /wp-includes/pluggable.php on line 896
Sounds like php is borked to me. Try running that phpinfo file from the command line and see what happens.
I'd suggest you simplify things. Create a test site without Wordpress. Put a php file in place, e.g., info.php:
Browse to it.
Does it render? If yes, there's lots of useful info there. e.g., the path to the active php.ini file.
Does it download or display as plain text? Then there's a PHP setup issue.
Wordpress does all kinds of sh*t. Before dealing with that, ensure that you have basic PHP working.
I got lots of info, to much to post. (can't see everything in SSH, it too much text)
Ok, try accessing the file in a browser and see if it shows all that info or not.
No, it's blank:
http://test1.myhken.com/phpinfo.php
Ok, I would look at Apache to see what's going on. Php is working from the command line, so I think it's fine now. You could try piping the output of phpinfo to less or more so you can scroll through it and see if there are anything unusual in there.
php phpinfo.php | less
No, it's not blank. View source -- and you'll see plain text.
So php files are not being sent to the php interpreter.
@myhken : As I can see the PHP source code of your pages in my Web browser, ensure that your Web server is configured to interpret PHP files.
How? You know that everything is working fine before I try to upgrade PHP with Remi repository. All I do is upgrading PHP with
yum --enablerepo=remi update -y
Then nothing is working anymore. So I'm sure my server can interpret PHP files, since all is working fine before the upgradring to PHP 5.4.x or 5.5.x?
Or do I miss something?
You can see the info here: http://test1.myhken.com/info1.txt
it's allot.
Have a look here for some further information. While the posts there are a couple years old, the steps are still more-or-less the same; just adjust the module names/paths as necessary.
If enabling that repo updated Apache, you should check to make sure modphp is enabled and running in Apache. This might help.
I have a feeling modphp isn't loaded or isn't running correctly.
wow, @prometeus have fixed the problem, and I will get a report later on about how.
Now http://test1.myhken.com/phpinfo.php is working, and wordpress is working: http://test1.myhken.com/
Thats why I'm using Prometeus, the little extra that you don't expect.
The solution:
after you update the php rename the php.conf file and remove any reference to the php_* commands in the httpd.conf.
Spinning up a new server now to test this out.
Huh. I wonder if that is something specific to RH or CentOS, as I don't think I've dealt with that with Apache on Debian. Hopefully that fixes it!
Will test it on one of my production servers tomorrow. I will close down the test server now, so any links to test1.myhken.com will not work anymore.
@myhken I make sure my web apps, if required, they're using the appropriate version for ioncube.com/loaders.php.
Here is my usual Centos configuration built:
Later, I simply do "yum update" and nothing breaks.
Another thing to test out. The best thing is to actually updating my PHP without breaking anything.
Upgraded all my productions servers today, and do now have PHP 5.5.8 and MySQL 5.5.35. With @Prometeus fix, all is working good. Have not have the time to test the other input in this thread yet.
But I have a question, is there any problems running PHP 5.5 on my main servers and PHP 5.3 on my backup servers? I'm using Rsync to sync the files, and Navicat MySQL to sync the MySQL databases. If my main server goes down, will my sites still run on PHP 5.3.x on the backup server?
Or will the best thing be to upgrade my backup servers also?
The reason I ask, is because if I find any issues at all on my upgraded servers, I can route traffic to one of my backup servers while i fix the issue. If I upgrade all my servers, I have no fall back.
edited got it
after you update the php, rename the php.conf file (to php.conf.no) and remove any reference to the php_* commands in the httpd.conf.
Then restart httpd.
These are stats that are updated daily:
http://wordpress.org/about/stats/
Using php 5.5 in a production system is risky. It hasn't been tested in the wild as well as earlier versions.
The only practical reason to use Debian is that by default it takes up less memory than CentOS.