Apache/PHP/SquirrelMail producing Blank Pages but no errors found in the logs

I have been beating my head against SquirrelMail's (SM) config files and plugins for days now, I should have posted here earlier I guess.

I am installing SM for the first time and I am also reasonably new to Linux, I am running fc6 with Apache 2.2.0, PHP 5.1.6 and I have installed (via 'yum') SM.noarch 1.4.8-2.fc6.  After I started experiencing problems I followed advice on SM's website and manually installed (not sure if I could/should have use 'yum' again?!) the following plugins:

- Firstly "debugger-1.2-1.4" with no success,
- then "compatibility-2.0.14-1.0" along with "squirrel_logger-2.3-1.2.7", but still nothing.

The Apache log (/var/log/httpd/error_log) has no errors listed, the Squirrel Logger hasn't even created it logfile (/var/lib/squirrelmail/squirrelmail_access_log) I guess because SM fails before it even gets started.

I have followed all the instructions here: http://squirrelmail.org/docs/admin/admin-11.html enabling PHP Error Reporting, hacking in the old PHP Error Reporting Envelope below and a lot more besides, but I have gotten nowhere it seems.

I am starting to think this is an Apache config issue, PHP is working as far as I know (I don't make extensive use of it currently on this server, but phpinfo() back reports ok).  Maybe I should start looking for info on "Apache blank PHP pages"...

If someone could point me in the right (or any other useful) direction it would be most appreciated.
// index.php - relaces the SM index.php, which is renamed 'sm_index.php' and included below.
ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting (E_ALL);

Open in new window

Who is Participating?
Steve BinkCommented:
Your vhost looks ok.  I would put it under a different directory altogether, as opposed to keeping it in a subdirectory of the main site, but that's just me.  IIRC, SquirrelMail is a "drop-in" kind of application.  It can sit anywhere, with just some minor editing of config.php to make it work right.  I'm not familiar with Matrix, so I have no idea how it will impact your environment.  
Steve BinkCommented:
Some tests for you, from basic through the start of troubleshooting the SM app:

1) Make a simple 'Hello World' HTML page and put in SM's root directory.  If you can browse to it, then basic Apache config should be OK.
2) Create a phpinfo() page and do the same.  If you can browse to it, you know PHP is responding properly on the site.  Familiarize yourself with those settings.  Pay special attention to the "error_log" and "error_reporting" directives.
3) Change your php.ini file in a noticeable way, then try step 2 again.  Can you see the changes reflected in phpinfo()?
4) Edit your new index.php (as you posted) to write to the error log at least once.  Make sure the log is being written.  Use grep to find which log, if necessary.  Moving forward becomes much more difficult if you have no error reporting.

When PHP displays a blank page, I've found the common reason is a parse error.  That shouldn't be the case with a pre-packaged app like SM, but you never know.
TommyGunnerAuthor Commented:
Ok good stuff, step one passed no problem, but step 2 fails with a blank page again, so I then encapsulated 'info.php' in my Error Reporting Envelope script 'testinfo.php' and still nothing displayed, just the same old default page source (included below).

Unfortunately nothing new in '/var/log/httpd/error_log', I assume this is the only place PHP errors are logged, 'php.ini' has:
  - safe_mode = Off,
  - error_reporting  =  E_ALL,
  - display_errors = Off,
  - display_startup_errors = Off,
  - log_errors = On,
  - and 'error_log' doesn't have a definition uncommented so I gather that by default the Apache 'httpd/error_log' is assigned as destination for PHP errors as I had assumed already.

The 'info.php' script is the same as that working within another virtual hosts' web space, but for some reason it didn't work in the shared ('/usr/share/squirrelmail') area of the server, owner and group are 'root', as it was installed by 'yum' so should be good here.  But then I noticed that the permissions on all the .php files with in the SM folder read-only and not 'r-x', so I have tried changing this for the 'testinfo.php' and 'info.php' files in SM folder, but again it made no difference.  If I remember PHP files don't need execute permissions, is that correct?  I have reset them to their previous state '-rw-r--r--', but the SM directories have execute permissions as they were installed.

So does that mean it is definately something to do with the 'httpd.conf' directives?  I know there are issues there as my Perl CGI scripts don't work at the moment, but that is off at a tangent, an issue for another day.  I couldn't find any relevant references to '/usr/share/' in 'httpd.conf' but I have found some confusing other bits in othe '.conf' files (see further snippets below) and a whole new copy of SM in another similare location '/usr/local/smail/www', I am getting really confused now.

Since the '/usr/local/smail/www' references are commented out I assume this is an old installation, confirmed in the ReleaseNotes file as 'SquirrelMail 1.4.10a' so a more recent release but installed over 2 years ago?!  My brain is struggling with all this, sorry this is a lot of info to process I know, so I have increased the Point Value to reflect the time consumed.

So what is the difference between '/usr/local' and '/usr/share' and which should be used to store SM or other shared web apps?  Any explainations I have read in the past on the *nix file system structure are ambiguous at best and some areas of the directory structure are completely grey areas to me.  This is another example it seems.

So I have started looking at the Apache config directives, not that i know much about them or how they work really, its always been a bit of a mystery to me.  Thanks for you help so far, I feel we are nearly there on this one...
---  HTML blank page output:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<META http-equiv=Content-Type content="text/html; charset=utf-8"></HEAD>
---  File '/etc/httpd/conf.d/squirrelmail.conf' contains just:
Alias /webmail /usr/share/squirrelmail
--- (Which is established as a working Alias through step 1: Hello World.)
---  In '/etc/httpd/conf/vhost.conf' I have the following for the test
---  domain I am first installing SM (looking forward to adding the
---  SM plugin for VHOSTS, that should be fun?!
<VirtualHost xxx.xxx.xxx.xxx:80>
  ServerName mytestdomain.co.uk
  ServerAlias www... vairous other domains here...
  ServerAdmin webmaster@mytestdomain.co.uk
  DocumentRoot /home/DomainGroup/mytestdomain.co.uk/user/htdocs
  ErrorLog /home/DomainGroup/mytestdomain.co.uk/user/logfiles/error_log
  TransferLog /home/DomainGroup/mytestdomain.co.uk/user/logfiles/access_log
  php_admin_value open_basedir /tmp:/home/DomainGroup/mytestdomain.co.uk
  SuexecUserGroup mytestdomain matrixdomain
  ScriptAlias /cgi-bin/ /home/DomainGroup/mytestdomain.co.uk/user/htdocs/cgi-bin/
  AddHandler server-parsed .shtml
  AddType text/html .shtml
  <Location />
    Options +Includes
# Begin user directives <--
#    Alias /smail /usr/local/smail/www^M
#    <Directory /usr/local/smail/www>^M
#        Options Indexes^M
#        AllowOverride None^M
#        DirectoryIndex index.php^M
#        Order allow,deny^M
#        allow from all^M
#    </Directory>^M
# --> End user directives
---  mytestdomain.co.uk has been substituted to protect the innocent ;o)

Open in new window

Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

TommyGunnerAuthor Commented:
After posting the last comment I noticed the 'ErrorLog' in directive in the 'vhosts.conf' file and low and behold the log '/home/DomainGroup/mytestdomain.co.uk/user/logfiles/error_log' holds the answers.  But the messages are very cryptic (to me anyway) in their makeup; 3 messages for one error?!  I guess the first is the most pertinent.

"PHP Warning:  Unknown: open_basedir restriction in effect.", means very little to me, 'open_basedir' is listed by the 'phpinfo()' script as '/tmp:/home/DomainGroup/mytestdomain.co.uk' and I have found it in a couple of places.  Firstly in 'php.ini' but it's commented out there.  Then secondly (after I woke up)in 'vhosts.conf' again as 'php_admin_value open_basedir /tmp:/home/DomainGroup/mytestdomain.co.uk', so I guess I need to add ':/usr/share/squirrelmail' to the end of that and restart Apache...

Ok, 'phpinfo()' now works... yey!

I guess I should close this question now, but if you feel so inclined to claim 'full marks' maybe you could spare the time to fill in some of the gaps in my knowledge from my previous posting, any further insight would be greatly appreciated.

Thanks again, Tom.
[Sat May 02 20:12:55 2009] [error] [client xxx.xxx.xxx.xxx] PHP Warning:  Unknown: open_basedir restriction in effect. File(/usr/share/squirrelmail/index.php) is not within the allowed path(s): (/tmp:/home/DomainGroup/mytestdomain.co.uk) in Unknown on line 0
[Sat May 02 20:12:55 2009] [error] [client xxx.xxx.xxx.xxx] PHP Warning:  Unknown: failed to open stream: Operation not permitted in Unknown on line 0
[Sat May 02 20:12:55 2009] [error] [client xxx.xxx.xxx.xxx] PHP Warning:  Unknown: Failed opening '/usr/share/squirrelmail/index.php' for inclusion (include_path='.:/root/PEAR') in Unknown on line 0

Open in new window

Steve BinkCommented:
My apologies for the late reply.  Let's see if I can't fill in some of those blank areas...

>>> step one passed no problem, but step 2 fails with a blank page again

This was not a good sign, but it was likely a result of you putting more in the file than just phpinfo().  PHP generates a blank page when it encounters a fatal error during or before parsing the file.  The entire contents of the test file should be:

<? phpinfo(); ?>

The goal of this step was to access the configuration under which your PHP installation will run for this particular site.  As you saw later, the phpinfo() output includes references to open_basedir, error_log, and all other options that could give you a clue as to where to start your troubleshooting.  It even tells you which php.ini it is loading for the current site, which can be important.  As you've seen, old installations can litter a server with extraneous and misleading information.  There's nothing like current data to keep troubleshooting times to a minimum.  

>>> Unfortunately nothing new in '/var/log/httpd/error_log', I assume this is the only place PHP errors are logged

By default, PHP logs to the server's log.  It is common practice to create a log just for PHP using the error_log directive.  In this particular case, you do not appear to have a PHP-specific error log, and Apache's ErrorLog directive was set to a specific location.  This is the log you needed to find, which ended up being /home/DomainGroup/mytestdomain.co.uk/user/logfiles/error_log.  Note that this is the *server* error log, not the PHP error log...it just happens that PHP is using it.

>>> If I remember PHP files don't need execute permissions, is that correct?

That is correct.  The files only need read permission in the context of the Apache server's runtime user, which is set by Apache's "User" directive.  It normally runs as nobody, www-data, or apache, but it could be anything.  If you're ever in doubt and need to know, check the httpd.conf file.  The permissions on the PHP files themselves, at a minimum, require only 400 (directories need 500) as long as they are owned by the Apache user.  Any other permissions are simply for the convenience of other processes (such as editing by a developer).  

>>> So what is the difference between '/usr/local' and '/usr/share' and which should be used to store SM or other shared web apps

The Linux file system has always held a few mysteries for me, as well.  IIRC, the difference between local and share refers to multi-user intentions, but it seemed to me to be an arbitrary distinction.  The fact is that you can store your site content (document root) anywhere you want, though some places are definitely better than others.  Any directory holding the document root must be accessible by the Apache user, as well as any user accounts that will edit or manage the content.  With that in mind, /etc is probably not a good choice, but /home, /var/www, and /usr are as good as any.  Most flavors of Linux have their own idea of the best default location, as does Apache if you download and install it yourself.  

As you have discovered with your open_basedir edit, that directive tells PHP which directories it should be using to pull content.  This is above and beyond file system permissions, and is managed within PHP itself.  If you have an open_basedir set, all files PHP tries to access *must* resolve to somewhere under that directory.

If you have any further questions, I'll still be monitoring this question.  In the meantime, you can find almost all the answers you need with a little research and reading.  Keep these links handy:


Here's some specific links based on info in this question so far:

TommyGunnerAuthor Commented:
It seems I was slightly premature with my celebrations the other day.

Don't worry about delay any response is good, I haven't been able to give the issue as much attention as I would like either.  But thanks, great stuff, loads of really useful info there.  Unfortunately I still have a similar problem occurring, but at least I know where to look for error logging now!

I am getting my 'phpinfo()' script running properly (after adding SM directory to 'open_basedir' path), but SM is having trouble finding it's dependencies, see the Error Message and Error_Log below.  Specifically (or currently) its 'config.php' file which actually exists in '/etc/squirrelmail':
    -rw-r-----  1 root apache  6918 Apr 30 12:06 config.php

...but is 'linked' to from the main SM directory '/usr/share/squirrelmail' (which I added to PHP's 'open_basedir' list of paths) via a symlink as follows:
    lrwxrwxrwx  1 root root     39 Apr 29 10:59 config.php -> ../../../../etc/squirrelmail/config.php

Another area that is very grey to me is permissions on files that are linked to, I think I have some grasp  on the basics of that but it gets very confusing.  One thing that sticks out is the Owner of these files/links being 'root' should I 'chown -R apache' (and 'chgrp') the whole SM and '/etc/squirrelmail' directory trees or is that overkill?  It also seems unrelated to the PHP Error that is shown in the error_log.

So after researching a but I'm starting to think that just adding the SM path to 'open_basedir' wasn't any part of a solution it just had an overriding effect on the permissions/ownership so I will try removing the SM path from 'open_basedir' and changing the owner/group of both (maybe just SM directory first) directories and all contents to the 'apache' user/group...
--- From SM index.php: this is just the response when file_exists() fails
ERROR: Config file "config/config.php" not found. You need to configure SquirrelMail before you can use it.
--- From error_log: /home/DomainGroup/mytestdomain.co.uk/user/logfiles/error_log
[Wed May 06 11:13:44 2009] [error] [client xxx.xxx.xxx.xxx] PHP Warning:  file_exists() [<a href='function.file-exists'>function.file-exists</a>]: open_basedir restriction in effect. File(config/config.php) is not within the allowed path(s): (/tmp:/home/DomainGroup/mytestdomain.co.uk:/usr/share/squirrelmail) in /usr/share/squirrelmail/index.php on line 15

Open in new window

TommyGunnerAuthor Commented:
I edited '/etc/httpd/conf/vhost.conf' to remove SM path from 'open_basedir', now 'phpinfo() has stopped again...  And I'm back to a similar error as before (below), they come in three's, but the last two are meaningless to me (full of 'Unknown' whatever that means) only the first message is useful as I see it, again with 'Unknown' not sure why but referring to 'open_basedir' again.

So I might 'chown/chgrp -R apache' the 'etc/squirrelmail' branch and see if that helps...
[Wed May 06 12:40:23 2009] [error] [client xxx.xxx.xxx.xxx] PHP Warning:  Unknown: open_basedir restriction in effect. File(/usr/share/squirrelmail/src/configtest.php) is not within the allowed path(s): (/tmp:/home/DomainGroup/mytestdomain.co.uk) in Unknown on line 0
[Wed May 06 12:40:23 2009] [error] [client xxx.xxx.xxx.xxx] PHP Warning:  Unknown: failed to open stream: Operation not permitted in Unknown on line 0
[Wed May 06 12:40:23 2009] [error] [client xxx.xxx.xxx.xxx] PHP Warning:  Unknown: Failed opening '/usr/share/squirrelmail/src/configtest.php' for inclusion (include_path='.:/root/PEAR') in Unknown on line 0

Open in new window

TommyGunnerAuthor Commented:
So I did 'chown -R apache /etc/squirrelmail/' and 'chgrp -R apache /etc/squirrelmail/', but unsurprisingly (since 'phpinfo()' had previously stopped working) no change in output or log entries, same messages as before.

Now I will add both the SM and the '/etc/squirrelmail/' paths to the 'open_basedir' in the 'vhosts.conf' file and see if that does the trick...
TommyGunnerAuthor Commented:
Well it worked!  So far... I have the login screen for SM, but I hope I haven't done something to expose my site/server?  I will keep this thread updated as I test SM further.
TommyGunnerAuthor Commented:
After running SM's 'configtest.php' script a few times... I also added both '/var/lib/squirrelmail' and '/var/spool/squirrelmail/attach' to the 'open_basedir' directive in 'vhosts.conf', now this seemed a little excessive with respect to what I have read on squirrelmail.org but it made the script work, a bit more anyway, andit follows what is described at:

I quote, "When a script tries to open a file with, for example, fopen() or gzopen(), the location of the file is checked. When the file is outside the specified directory-tree, PHP will refuse to open it. All symbolic links are resolved, so it's not possible to avoid this restriction with a symlink. If the file doesn't exist then the symlink couldn't be resolved and the filename is compared to (a resolved) open_basedir."

So that made sense but now the 'configtest.php' script throws an error stating it can't find 'sendmail' in the following folder '/usr/sbin/' where it most certainly resides?!  Do I have to add '/usr/sbin/' to my 'open_basedir' directive as well?  This is getting silly, is there something else wrong here?  Maybe there is another issue with Apache that is restricting access?

I will add '/usr/sbin/' and any others that end up being required in order to test SM, but I am looking for some reassurance that I am not going too far with this.  Any ideas?

Having said that I just noticed '/usr/sbin/sendmail' is a symlink to '/etc/alternatives/mta', which in turn is a symlink to '/usr/sbin/sendmail.postfix'.  My head is ready to pop!!

But since I added just '/usr/sbin' to the 'open_basedir' list and the 'configtest.php' script then declared itself happy!  Hooray!  So I didn't need to add '/etc/alternatives/', but still this is much more convoluted than it should be I'm sure?!
Steve BinkCommented:

I believe the problem here is that you shouldn't be using open_basedir on a squirrelmail installation.  :)  The purpose of using open_basedir would be to restrict PHP from reading things like /etc and /usr/sbin, so defining that setting and adding them back is just counter-productive at best.

At the same time, there may have been a good reason to have an open_basedir declaration for the main web site, so it could be risky to just arbitrarily decide you don't need it.

I would resolve this by creating a new vhost definition, such as webmail.mydomain.co.uk, creating the appropriate A record for it in DNS, and allowing SM to run from that domain.  That allows you to give SM the freedom it needs to find files, and still restricts the main website the same way it was originally intended.  You're likely to run into further directory problems with SM once you start using it, since it will also need access to the mailbox directories for the users.
TommyGunnerAuthor Commented:
I thought something was amiss with adding all these paths to 'open_basedir' as I haven't seen it in any of the examples I have found online.  Oh and yes, I am having problems with SM accessing mail directories, it is retrieving and processing mail in a basic fashion, but I have a "Query: CREATE 'Sent'. Reason Given: Invalid mailbox name." which is heavily documented but not for my scenario I fear.

As for 'open_basedir' I don't think it was added by the SM installation (as far as I know), my server uses Matrix SA which handles virtual host config, as well as a few other admin chores and I guess it is responsible for this.  After a bit of snooping around I found Webmin (http://webmin.com/) to be highly rated, but I certainly (god help me!) don't want to get into replacing Matrix SA at the moment.

What are the main issues with commenting out 'open_basedir', (I would hope!) only my code ends up on this server, so as long as I don't write some wreckless PHP script...  I will test it quickly...

Nope, didn't help SM access my mail folder, I assume its either a SM or Apache config issue then, so I'll start a new thread on each as and when I get some more substance together.

So how do I go about what you recommended, creating a new vhost definition?  I think I have the wrong end of the stick...

I have limited knowledge in this area (but am keen to learn), but I have knocked up something I think should work in terms of 'httpd.conf' below.  Although I will just add it to the end of 'httpd.conf' using 'Include nbvhost.conf', rather than editing 'vhost.conf' as MatrixSA manipulates that and may overwrite my entries.

I will leave out the 'open_basedir' directive, but I'm a bit unsure where I should point the 'DocumentRoot', I assume it needs to go to the same directory as SM was already set up an alias for '/webmail/' which redirects to '/usr/share/squirrelmail/' so I have pointed it at that '/webmail/' directory of 'mytestdomain.co.uk'.  But obviosly it will still be as accessible ('mytestdomain.co.uk/webmail/') as it is now, unless I use some access control, but the PHP script is already a form of that.
I also assume that, since this directory is a level below the web root for this domain, this directory inherits the previously assigned directives.

As for adding A Records I have only done this through control panels previously, so I will have to look into that as Matrix SA doesn't appear to have any facility to manipulate domain/DNS records in this manner.
## nbvhost.conf
<VirtualHost xxx.xxx.xxx.xxx:80>
  ServerName webmail.mytestdomain.co.uk
  DocumentRoot /home/DomainGroup/mytestdomain.co.uk/user/htdocs/webmail
  ##php_admin_value open_basedir /tmp...
  <Location />
    Options +Includes

Open in new window

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.