Dependancy Detection / Reporting

[AlbinoGeek]

Simple enough really, if you require GD, check for it.

if (!function_exists('gd_info')){
  die('PHP Extension GD is required!');
};

[PetaByet]

The script requires pretty much nothing other than php core / php cli. Mcrypt and mail are both optional.

[AlbinoGeek]

You don't specify the kind of PHP or Apache modules required. Your .htaccess requires a few modules enabled in Apache for it to work, so many so in fact that this is the reason the default PHP563 Docker image didn't work with CDP.me

[PetaByet]

The only required Apache module is PHP and nothing else. To allow .htaccess to work you need to turn on AllowOverride in Apache's config file.

[alexandreteles]

@AlbinoGeek, can you provide the errors returned and what PHP/Apache modules you installed to resolve the dependencies issues?

[AlbinoGeek]

We need some unit tests up in here :). I'll put up some tests in a moment, please hold on.

[AlbinoGeek]

own1 cdp # git clone https://github.com/PetaByet/cdp.git
Initialized empty Git repository in /home/docker/cdp/cdp/.git/
remote: Counting objects: 511, done.
remote: Compressing objects: 100% (11/11), done.
remote: Total 511 (delta 2), reused 0 (delta 0)
Receiving objects: 100% (511/511), 1.24 MiB | 918 KiB/s, done.
Resolving deltas: 100% (213/213), done.
own1 cdp # cd cdp
own1 cdp # mkdir files && chmod -R 777 files
own1 cdp # chmod -R 777 db/*.json
own1 cdp # mv htaccess.txt .htaccess
own1 cdp # cd ..
own1 cdp # docker run -d --name cdp -p 8080:80 -v /home/docker/cdp/cdp/:/var/www/html/ php:5.6-apache
ba5af0fd01036065adbac9ed466ebda82979d6c5bcd8eacaa901cb7b8a62f6ac

own1 cdp # docker ps -a
CONTAINER ID        IMAGE               COMMAND                CREATED             STATUS              PORTS                  NAMES
ba5af0fd0103        php:5.6-apache      "apache2 -DFOREGROUN   39 seconds ago      Up 36 seconds       0.0.0.0:8080->80/tcp   cdp   

own1 cdp # docker attach cdp
207.xxx.yyy.zzz - - [17/Dec/2014:01:32:35 +0000] "GET / HTTP/1.1" 500 357 "-" "Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36"
own1 cdp # docker exec -ti cdp bash
root@b01f1a1872be:/var/www/html# ls -l
total 92
-rw-r--r-- 1 root root 18027 Dec 17 01:28 LICENSE
-rw-r--r-- 1 root root  2519 Dec 17 01:28 README.md
drwxr-xr-x 6 root root    63 Dec 17 01:28 bootstrap
-rw-r--r-- 1 root root  3632 Dec 17 01:28 config.php
-rw-r--r-- 1 root root 24679 Dec 17 01:28 cron.php
drwxr-xr-x 2 root root  4096 Dec 17 01:28 db
drwxrwxrwx 2 root root     6 Dec 17 01:30 files
drwxr-xr-x 2 root root  4096 Dec 17 01:28 includes
-rw-r--r-- 1 root root 11410 Dec 17 01:28 index.php
drwxr-xr-x 9 root root   154 Dec 17 01:28 libs
-rw-r--r-- 1 root root  9565 Dec 17 01:28 restore.php
drwxr-xr-x 2 root root  4096 Dec 17 01:28 templates
root@b01f1a1872be:/var/www/html# chown -R www-data:www-data *
root@b01f1a1872be:/var/www/html# cat /var/log/apache2/
access.log               error.log                other_vhosts_access.log
root@b01f1a1872be:/var/www/html# cat /var/log/apache2/*

Nothing in the logs at all, trying with a different image now.

This is the 100% official PHP5.6.3-apache image from PHP Group: https://registry.hub.docker.com/_/php/

[AlbinoGeek]

I also tried with fedora:latest , then installing httpd php via yum.

bash-4.3# cat /var/log/httpd/error_log
[Tue Dec 16 20:44:17.902899 2014] [suexec:notice] [pid 59] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Tue Dec 16 20:44:17.931978 2014] [auth_digest:notice] [pid 60] AH01757: generating secret for digest authentication ...
[Tue Dec 16 20:44:17.933020 2014] [lbmethod_heartbeat:notice] [pid 60] AH02282: No slotmem from mod_heartmonitor
[Tue Dec 16 20:44:17.954254 2014] [mpm_prefork:notice] [pid 60] AH00163: Apache/2.4.10 (Fedora) PHP/5.6.3 configured -- resuming normal operations
[Tue Dec 16 20:44:17.954308 2014] [core:notice] [pid 60] AH00094: Command line: 'httpd'

bash-4.3# cat /var/log/httpd/access_log
207.xxx.yyy.zzz - - [16/Dec/2014:20:44:37 -0500] "GET / HTTP/1.1" 500 - "-" "Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36"

Looks like you've got something wrong here :). I'll try with debug PHP next, and give you an strace.

[AlbinoGeek]

In the fedora:latest image still, here's some more information:

bash-4.3# grep error php.ini | grep = | grep -v \;
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
display_errors = Off
display_startup_errors = Off
log_errors = On
log_errors_max_len = 1024
ignore_repeated_errors = Off
track_errors = Off
html_errors = On
mssql.min_error_severity = 10

bash-4.3# find / | grep php | grep error

Errors should be logging to Apache, if there were any. Seems like one of those dropout mechanisms without a die/exit message might be tricking up the pages. I am still getting completely blank pages when trying to browse to the port.

[alexandreteles]

If I'm not wrong, if you are running Apache and PHP under a non-root user you can blank logs (or just apache initialization messages) because apache log files are root owned and is only writable by root:root. Can you check this out?

[AlbinoGeek]

Tried with all the error reporting and error log set, and on:

bash-4.3# sed -i 's/display_errors = Off/display_errors = On/' /etc/php.ini
bash-4.3# sed -i 's/\;error_log = php_errors.log/error_log = php_errors.log/' /etc/php.ini
bash-4.3# pkill -9 httpd
bash-4.3# httpd

And then:

bash-4.3# grep error php.ini | grep = | grep -v \;
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
display_errors = On
display_startup_errors = Off
log_errors = On
log_errors_max_len = 1024
ignore_repeated_errors = Off
track_errors = Off
html_errors = On
error_log = php_errors.log
mssql.min_error_severity = 10

Which gave me, empty index again, as well as the following log entries:

bash-4.3# cat /var/log/httpd/access_log
207.xxx.yyy.zzz - - [16/Dec/2014:20:53:58 -0500] "GET / HTTP/1.1" 500 - "-" "Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36"

bash-4.3# cat /var/log/httpd/error_log
[Tue Dec 16 20:52:11.366632 2014] [suexec:notice] [pid 90] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Tue Dec 16 20:52:11.396002 2014] [auth_digest:notice] [pid 91] AH01757: generating secret for digest authentication ...
[Tue Dec 16 20:52:11.397061 2014] [lbmethod_heartbeat:notice] [pid 91] AH02282: No slotmem from mod_heartmonitor
[Tue Dec 16 20:52:11.413966 2014] [core:warn] [pid 91] AH00098: pid file /run/httpd/httpd.pid overwritten -- Unclean shutdown of previous Apache run?
[Tue Dec 16 20:52:11.418925 2014] [mpm_prefork:notice] [pid 91] AH00163: Apache/2.4.10 (Fedora) PHP/5.6.3 configured -- resuming normal operations
[Tue Dec 16 20:52:11.418975 2014] [core:notice] [pid 91] AH00094: Command line: 'httpd'

And on a search for any php_errors.log files created:

bash-4.3# find / | grep php_errors.log

No file(s) created there.

[AlbinoGeek]

Checked the file permissions for the log files, here you go:

bash-4.3# ls -lisa /var/log/httpd/
total 16
532105 4 drwx------ 2 root root 4096 Dec 16 20:44 .
531590 4 drwxr-xr-x 5 root root 4096 Dec 16 20:42 ..
531653 4 -rw-r--r-- 1 root root 1130 Dec 16 20:53 access_log
531630 4 -rw-r--r-- 1 root root 1330 Dec 16 20:52 error_log

And then tried as 0777 / www-data owned:

bash-4.3# chmod 0777 /var/log/httpd/*
bash-4.3# chown apache:apache /var/log/httpd/*

(yes, the user is called apache in Fedora:latest , not www-data or nobody, suEXEC apache by default.)

And upon loading the pages again to generate more logs:

bash-4.3# cat /var/log/httpd/error_log
[Tue Dec 16 20:59:10.388239 2014] [suexec:notice] [pid 112] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Tue Dec 16 20:59:10.417220 2014] [auth_digest:notice] [pid 113] AH01757: generating secret for digest authentication ...
[Tue Dec 16 20:59:10.418258 2014] [lbmethod_heartbeat:notice] [pid 113] AH02282: No slotmem from mod_heartmonitor
[Tue Dec 16 20:59:10.435155 2014] [core:warn] [pid 113] AH00098: pid file /run/httpd/httpd.pid overwritten -- Unclean shutdown of previous Apache run?
[Tue Dec 16 20:59:10.440351 2014] [mpm_prefork:notice] [pid 113] AH00163: Apache/2.4.10 (Fedora) PHP/5.6.3 configured -- resuming normal operations
[Tue Dec 16 20:59:10.440398 2014] [core:notice] [pid 113] AH00094: Command line: 'httpd'

bash-4.3# cat /var/log/httpd/access_log
207.xxx.yyy.zzz - - [16/Dec/2014:20:59:14 -0500] "GET / HTTP/1.1" 500 - "-" "Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36"

bash-4.3# find / | grep php | grep error

And still nothing displayed :).

[alexandreteles]

This is really strange.

You are using: error_log = php_errors.log/error_log. Could you try: error_log = /var/log/php_error.log? Don't forget to create the file and set temporary permissions to 0777.

PHP has problems to log errors if you are not providing a full path on this directive. Please, disable logging from config.php and enable it using the php.ini file. I think this can solve the logging problem.

[AlbinoGeek]

bash-4.3# sed -i 's/error_log = php_errors.log/error_log = \/var\/log\/php_error.log/' /etc/php.ini
bash-4.3# cat /etc/php.ini | grep "error_log = /var/log/php_error.log"
error_log = /var/log/php_error.log
bash-4.3# touch /var/log/php_error.log
bash-4.3# chmod 0777 /var/log/php_error.log
bash-4.3# pkill -9 httpd
bash-4.3# httpd

And then after reloading the index a few times:

bash-4.3# ls -lisa /var/log/php_error.log
531660 0 -rwxrwxrwx 1 root root 0 Dec 16 21:11 /var/log/php_error.log
bash-4.3# cat /var/log/php_error.log

Unfortunately, there's still nothing being logged.

[PetaByet]

@AlbinoGeek Create test.php with the following:

<?php
echo 'It works <br>';
phpinfo();
?>

Visit it from your web browser, does it show anything?

[AlbinoGeek]

@PetaByet Of course that works, here you go:

bash-4.3# echo "<?php echo 'It works <br>'; phpinfo(); ?>" > test.php
bash-4.3# cat test.php

<?php echo 'It works <br>'; phpinfo(); ?>

And when browsed to:

https://gist.github.com/AlbinoGeek/8a8e2a651fa8cd23eaf8

(Full PHPinfo)

[PetaByet]

Prepend the same code in index.php and try again please.

[AlbinoGeek]

@PetaByet This also works exactly as expected.

Full PHPinfo, and then the following (expected) errors:

Warning: session_start(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /var/www/html/index.php on line 4

Warning: session_start(): Cannot send session cache limiter - headers already sent (output started at /var/www/html/index.php:1) in /var/www/html/index.php on line 4

Note the strong wording of REQUIRED to set a timezone might be a nitpicky issue in the latest PHP? But I doubt that is the only issue at play here.

[PetaByet]

What if you add the code to the end of the file?

[AlbinoGeek]

For completeness, here's what print_r($config);exit; gives:

Array
(
    [adminemail] => someone@test.com
    [sendnotification] => 1
    [emailfrom] => someone@test.com
    [smtp] => 
    [smtpserver] => 
    [smtpusername] => 
    [smtppassword] => 
    [smtpsecure] => tls
    [smtpport] => 587
    [path] => /var/www/html
    [version] => 1.0
    [logintimeout] => 1800
    [debug] => 
    [debuglevel] => 2
    [errorlevels] => E_ALL | E_STRICT
    [logerrors] => 1
    [timezone] => UTC
)

As per adding the phpinfo to the end of the file...

If I place the phpinfo at the end of the file, I get a blank screen / 500 error again.

[PetaByet]

Is $config['debug'] true? Is there anything in $_SESSION?

[AlbinoGeek]

If I set debug to true, then the output of the index page is:

Debug info
$_REQUEST
Array
(
)
$_SESSION
Array
(
)

[PetaByet]

Replace include($config['path'] . '/includes/login.php'); with require($config['path'] . '/includes/login.php'); and add echo 'hi'; below it.

[AlbinoGeek]

@PetaByet Same output:

Debug info
$_REQUEST
Array
(
)
$_SESSION
Array
(
)

[PetaByet]

It should have something to do with the PHP version. Can you try running CDP on PHP 5.3/5.4?

[AlbinoGeek]

Hello @PetaByet ,

Sure, for completeness (and because I love that docker lets me test this) I can try this with many different versions of PHP/apache builds from the official PHP group. I will keep the index.php modified like it is right now, and post what version(s) (if any) let the output work as expected:

Here is what we get with php:5.4-apache:

Debug info
$_REQUEST
Array
(
    [PHPSESSID] => 26ddb74825563f07e4866c41191a7d44
)
$_SESSION
Array
(
)

5.3 is still compiling...

[PetaByet]

What's the Apache version?

[AlbinoGeek]

Here is what we get with php:5.3-apache:

cx15 cdp # curl http://127.0.0.1:8080/
<pre>Debug info
$_REQUEST
Array
(
)
$_SESSION
Array
(
)
</pre>

I tried this one on a completely new physical server / docker install.

As per the Apache2 version in the 5.3-apache:

root@c944c8a6e753:/var/www/html# apache2 -v
Server version: Apache/2.4.10 (Debian)
Server built:   Sep 28 2014 20:54:22

[PetaByet]

Try Apache 2.2.

[AlbinoGeek]

Fedora only has 2.4!

Available Packages
httpd.i686                          2.4.10-9.fc21                         fedora
httpd.x86_64                        2.4.10-9.fc21                         fedora

That being said, I'm manually compiling 2.2 now to try it out, will get back to you.

[AlbinoGeek]

I can't actually install 2.2 on Fedora:latest, as the following remains after solving other dependencies manually:

bash-4.3# rpm -Uhv *.rpm
warning: httpd-2.2.15-39.el6.centos.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID c105b9de: NOKEY
error: Failed dependencies:
        libdb-4.7.so()(64bit) is needed by httpd-2.2.15-39.el6.centos.x86_64
        libpcre.so.0()(64bit) is needed by httpd-2.2.15-39.el6.centos.x86_64
        libdb-4.7.so()(64bit) is needed by httpd-tools-2.2.15-39.el6.centos.x86_64
        libpcre.so.0()(64bit) is needed by httpd-tools-2.2.15-39.el6.centos.x86_64

[PetaByet]

I can't help you with that sorry. The script had been tested & working on CentOS, Debian and Ubuntu.