Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Why should I change from CentOS to Debian? (if any reason) - Page 2
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.

Why should I change from CentOS to Debian? (if any reason)

2

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.

  • tuxtux Member

    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?

  • prometeusprometeus Member, Host Rep
    edited January 2014

    @myhken said:
    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?

    try running the index page of the blog from a ssh session:

    cd /to/the/doc/root
    php index.php 
    

    and see if there are some warning/errors that can help you.

  • myhkenmyhken Member
    edited January 2014

    @CharlesA said:

    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?

    I can see the source code, but the page is "blank" on every web browser I have (Firefox, Chrome and IE 11)

    One test you could try doing is creating a phpinfo.php file with:

    It's also only is a blank page... http://test1.myhken.com/phpinfo.php

  • @prometeus said:

    [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:

    <?php
    phpinfo();
    ?>
    

    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.

  • @CharlesA said:
    Sounds like php is borked to me. Try running that phpinfo file from the command line and see what happens.

    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.

  • @CharlesA said:
    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

  • myhken said: No, it's blank:

    No, it's not blank. View source -- and you'll see plain text.

    So php files are not being sent to the php interpreter.

  • edited January 2014

    @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.

  • @TekStorm_James said:
    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?

  • myhkenmyhken Member
    edited January 2014

    @CharlesA said:
    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

    You can see the info here: http://test1.myhken.com/info1.txt
    it's allot.

  • edited January 2014

    myhken said: How?

    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.

    Thanked by 1myhken
  • 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.

    Thanked by 1myhken
  • 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:

    yum update
    
    64bit
    rpm -ivh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
    
    32bit
    rpm -ivh  http://dl.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm
    
    yum install yum-priorities
    
    edit epl priority to 10 -  /etc/yum.repos.d/epel.repo
    
    rpm -ivh http://rpms.famillecollet.com/enterprise/remi-release-6.rpm
    
    edit remi and change priority to 10 - /etc/yum.repos.d/remi.repo
    enabled=1
    priority=10
    
    
    [OPTIONAL]
    32bit 
    wget http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el6.rf.i686.rpm
    rpm -ivh rpmforge-release-0.5.3-1.el6.rf.i686.rpm
    64bit 
    wget http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el6.rf.x86_64.rpm
    rpm -ivh rpmforge-release-0.5.3-1.el6.rf.x86_64.rpm
    [/OPTIONAL]
    
    INSTALLATION
    yum --enablerepo=remi install httpd php php-common openssl-devel openssl mod_ssl rpm-build rpm-devel autoconf automake lynx gcc
    
    yum --enablerepo=remi install php-pecl-apc php-cli php-pear php-pdo php-mysql php-pecl-memcache php-pecl-memcached php-gd php-mbstring php-mcrypt php-xml
    
    

    Later, I simply do "yum update" and nothing breaks. :)

    Thanked by 1myhken
  • 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.

  • ahmiqahmiq Member
    edited January 2014

    edited got it

  • myhkenmyhken Member
    edited January 2014

    @ahmiq said:
    glad it worked. what was the fix though :p

    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.

    Thanked by 1myhken
Sign In or Register to comment.