Roundcube Community Forum
Release Support => Pending Issues => Topic started by: texas12 on June 25, 2010, 02:31:59 PM
-
I have Roundcube setup on IIS 7 with PHP 5.2 via FastCGI on Windows Server 2008 R2. I know this isn't a supported configuration, but I'm hoping I can find some help here.
The only change I had to make beyond the basic installation instructions was to edit where INSTALL_PATH is set to the root directory in the iniset file.
That line now reads:
if (!defined('INSTALL_PATH')) {
define('INSTALL_PATH', 'D:/clients/webmail/');
}
I passed all of the /installer/ tests and removed that folder, but when I try to actually run the package, I get a 501 error. Specifically, the error message reads:
SERVICE CURRENTLY NOT AVAILABLE!
Error No. [501]
The corresponding error from the log file is:
PHP Error: Error loading template for login in D:\clients\webmail\program\include\rcube_template.php on line 375 (GET /)
I then fired up ProcessMonitor (file system tracer utility for all running processes) to find out what was going on behind the scenes and found the following lines before the error is triggered:
1:00:32.7883136 PM php-cgi.exe 3568 CreateFile D:\clients\webmail SUCCESS Desired Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, Impersonating: ***, OpenResult: Opened
1:00:32.7883563 PM php-cgi.exe 3568 QueryDirectory D:\clients\webmail\installer NO SUCH FILE Filter: installer
1:00:32.7883938 PM php-cgi.exe 3568 CloseFile D:\clients\webmail SUCCESS
1:00:32.7885712 PM php-cgi.exe 3568 CreateFile D:\clients\webmail\installer NAME NOT FOUND Desired Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, Impersonating: ***
1:00:32.7886720 PM php-cgi.exe 3568 CreateFile D:\clients\webmail\installer\skins\ PATH NOT FOUND Desired Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, Impersonating: ***
1:00:32.7887407 PM php-cgi.exe 3568 CreateFile D:\clients\webmail\installer\skins\default\ PATH NOT FOUND Desired Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, Impersonating: ***
1:00:32.7888034 PM php-cgi.exe 3568 CreateFile D:\clients\webmail\installer\skins\default\templates\ PATH NOT FOUND Desired Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, Impersonating: ***
1:00:32.7888721 PM php-cgi.exe 3568 CreateFile D:\clients\webmail\installer\skins\default\templates\login.html PATH NOT FOUND Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: n/a, Impersonating: ***
As you can see, instead of looking in the D:\clients\webmail\skins\ directory, PHP is looking in the D:\clients\webmail\installer\skins directory. When it can't find the skin there, the error is triggered.
Any ideas on how I can fix this?
-
I am experiencing the same problem with the same files on a Windows Server 2008 (not R2). I'm using PHP 5.2.1.1 via FastCGI, IIS7, and MS SQL Server 2008 Express database running Roundcube 0.4beta.
I had some issues during installation that were only resolved by replacing the relative pathnames with absolute pathnames in INSTALL_PATH. Could this be a similar problem?
-
Does you install path include "installer" in it?
-
I don't see "installer" in either the INSTALL_PATH or $include_path.
-
Well that was my best guess based my logs above, I am no windows expert.
-
I've temporarily gotten this to work by copying the \bin, \plugins, \program and \skins folders underneath the \installer folder and deleting the original contents of \installer. :confused:
Obviously, this is NOT ideal, but it does allow me to successfully login and use RoundCube with my hMailServer.
It seems that something is referring to \installer in either one of the scripts or in one of the configuration files. I've searched for hours, but can't see anything obvious.
Perhaps someone a little more skilled than me in PHP will know what to suggest?
-
OK, I've spoken too soon.
My "workaround" only works if I immediately load RoundCube after running the installer. If I wait a few minutes and let the web site process die due to inactivity, then return to RoundCube, I'm back to the 501 error.
However, I CAN run the installer again (without changing anything) and then immediately load and run RoundCube again.
I think there's some environment variable that is being set by the installer that the main RoundCube scripts are using to determine where things are. This might also explain why everything appears to be "tied" to the \installer folder.
Any ideas?
-
Did you delete the installer directory after you finished installing, it maybe loading a global path from there.
-
I've temporarily gotten this to work by copying the \bin, \plugins, \program and \skins folders underneath the \installer folder and deleting the original contents of \installer. :confused:
As I said, I deleted the original contents of \installer.
-
I know but I was asking about the installer directory itself, not what was inside of it.
-
Sorry, I misunderstood your question.
I have tried several things. First, I left the original folder in place and just deleted the contents. Second, I tried deleting the original folder and creating a new folder named \installer. I appear to get the same results either way.
It appears the only way I can get into the program is to copy of the original contents of \installer from the distribution archive back into \installer, then run the installation (without changing any settings or creating new config files), then immediately run RoundCube with the installer files still in place and the other folders copied beneath \installer (as previously described). Once I delete the original \installer files, I can't get RoundCube to start at all - just a HTTP 501 error.
-
Try running RoundCube with any installer folder.
-
I have been eagerly following this thread in hopes of finding a solution.
I have tried to run RC with the installer folder deleted and I receive the same result.
-
did you disable the installer in main config??
-
Yes
$rcmail_config['enable_installer'] = false;
-
give logs from IIS
-
give logs from IIS
I'm not exactly sure what you're asking for. There is no IIS error. The error (whatever the source) is handled within PHP and the error log is written to the errors file in /logs/.
All of the tracing data I have is in the original post to this thread and, I believe, is quite extensive. If there is something else I can provide, please let me know.
-
I have Roundcube setup on IIS 7 with PHP 5.2 via FastCGI on Windows Server 2008 R2.
Give us errors from IIS... IIS has it own logs...
-
Below are IIS7 logs I generated after attempting to login twice (once locally at server, once remotely). Still getting the 501 error.
In this case, the /installer folder is not present on the site.
$rcmail_config['enable_installer'] = false in main.inc.php config file
System: Windows Server 2008, IIS 7, PHP v5.2.11 via FastCGI
Hopefully, this is what you're looking for, although it doesn't show any errors. I think what texas12 said is correct: the screen that shows "501 Error" is generated within the PHP code logic based on program conditions - the "501" itself doesn't appear to generated by IIS.
----------
#Software: Microsoft Internet Information Services 7.0
#Version: 1.0
#Date: 2010-07-27 01:06:33
#Fields: date time s-sitename s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status sc-bytes cs-bytes time-taken
2010-07-27 01:06:33 W3SVC17 174.121.41.203 GET / - 80 - 174.121.41.203 Mozilla/5.0+(Windows;+U;+Windows+NT+6.0;+en-US;+rv:1.9.2.3)+Gecko/20100405+Namoroka/3.6.3 200 0 0 944 471 2028
2010-07-27 01:06:37 W3SVC17 174.121.41.203 GET /favicon.ico - 80 - 174.121.41.203 Mozilla/5.0+(Windows;+U;+Windows+NT+6.0;+en-US;+rv:1.9.2.3)+Gecko/20100405+Namoroka/3.6.3 404 0 2 5461 533 0
2010-07-27 01:08:18 W3SVC17 174.121.41.203 GET / - 80 - 70.105.143.44 Mozilla/4.0+(compatible;+MSIE+8.0;+Windows+NT+5.1;+Trident/4.0;+Media+Center+PC+3.0;+.NET+CLR+1.0.3705;+.NET+CLR+1.1.4322;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.4506.2152;+.NET+CLR+3.5.30729) 200 0 0 873 746 436
2010-07-27 01:08:18 W3SVC17 174.121.41.203 GET /skins/default/common.css - 80 - 70.105.143.44 Mozilla/4.0+(compatible;+MSIE+8.0;+Windows+NT+5.1;+Trident/4.0;+Media+Center+PC+3.0;+.NET+CLR+1.0.3705;+.NET+CLR+1.1.4322;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.4506.2152;+.NET+CLR+3.5.30729) 200 0 0 9662 562 327
2010-07-27 01:08:18 W3SVC17 174.121.41.203 GET /favicon.ico - 80 - 70.105.143.44 Mozilla/4.0+(compatible;+MSIE+8.0;+Windows+NT+5.1;+Trident/4.0;+Media+Center+PC+3.0;+.NET+CLR+1.0.3705;+.NET+CLR+1.1.4322;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.4506.2152;+.NET+CLR+3.5.30729) 404 0 2 1405 469 93
----------
Contents of /logs/errors file:
[26-Jul-2010 21:06:33 -0400]: PHP Error: Error loading template for login in C:\HostingSpaces\Internal\roundcube.mail.somedomain.arvixevps.com\wwwroot\program\include\rcube_template.php on line 375 (GET /)
[26-Jul-2010 21:08:18 -0400]: PHP Error: Error loading template for login in C:\HostingSpaces\Internal\roundcube.mail.somedomain.arvixevps.com\wwwroot\program\include\rcube_template.php on line 375 (GET /)
-
Hopefully, this is what you're looking for, although it doesn't show any errors. I think what texas12 said is correct: the screen that shows "501 Error" is generated within the PHP code logic based on program conditions - the "501" itself doesn't appear to generated by IIS.
Exactly. The page returns a 200 (HTTP/OK) Header because the error handling is done (rather gracefully) by the code within RoundCube. The closest thing you'll get to an error message is what RC outputs to the /Logs/errors file and the closest thing to a stack trace is the process request trace in the original post.
IIS logs are irrelevant because as far as IIS is concerned everything is OK.
-
What version of RoundCube are you using?
-
I am experiencing the same problem with the same files on a Windows Server 2008 (not R2). I'm using PHP 5.2.1.1 via FastCGI, IIS7, and MS SQL Server 2008 Express database running Roundcube 0.4beta.
I'm using the 0.4 beta from the download link on the home page of roundcube.net.
-
I'm using the 0.4 beta from the download link on the home page of roundcube.net.
I am also using the beta.
-
Sorry for the late replay, I been busy lately and this got buried. Can you take the attached iniset.txt file and rename it iniset.php and replace the /program/include/iniset.php (make a backup of it first) Then go to RoundCube and post what it says here.
-
Array
(
- => INSTALL_PATH
[1] => D:\clients\webmail/
[2] => D:\clients\webmail/config
[3] => ;
[4] => D:\clients\webmail/;D:\clients\webmail/program;D:\clients\webmail/program/lib;D:\clients\webmail/program/include;.;c:\php-5.3.1\includes
)
-
Ok everything there looks fine, replace the iniset.php with the original iniset.php file and take the attached rcube_template.txt file and rename it rcube_template.php and replace the /program/include/rcube_template.php (make a backup of it first) Then go to RoundCube and post what it says here.
-
Array
(
- => login
[1] =>
[2] => skins/default
[3] =>
[4] => skins/default/templates/login.html
)
-
Ok replace /program/include/rcube_template.php with the attached rcube_template.txt file (rename it rcube_template.php) Then go to RoundCube and see if it works.
-
The login page loads now, but everything looks like crap.
-
What do you mean? Can you provide a screen shot?
-
I am NOT a PHP programmer.
With that said, I have spent a LOT of time looking at source code, and I think the bulk of the problems are with relative vs. absolute path names on the Windows platform.
I started by reading this excellent blog post on paths and Apache vs. IIS:
Finding the document root in PHP (http://www.helicron.net/php/)
Then, I made the following changes to the source code:
//File: /installer/index.php
//{near the top of the file}
//changed this line:
define('INSTALL_PATH', realpath(dirname(__FILE__) . '/../').'/');
//to this:
define('INSTALL_PATH', 'C:/PathToRoundcube/wwwroot/');
This change allows INSTALL_PATH to correctly be defined as the absolute path to the web on the server. This allows the installer to run while referencing the correct folder(s) internally.
With this change, I was able to successfully run the installer and test SMTP and IMAP functionality.
Then, I made these changes:
//File: /program/include/iniset.php
//{near the top of the file}
//changed this line:
define('INSTALL_PATH', dirname($_SERVER['SCRIPT_FILENAME']).'/');
//to this:
define('INSTALL_PATH', 'C:/PathToRoundcube/wwwroot/');
This change performs the same function as the change above performed for the installer.
//File: /program/include/rcube_html_page.php
//{in function include_script}
//changed this line:
$file = $this->scripts_path . $file . (($fs = @filemtime($this->scripts_path . $file)) ? '?s='.$fs : '');
//to this:
$file = $this->scripts_path . $file . (($fs = @filemtime(INSTALL_PATH . $this->scripts_path . $file)) ? '?s='.$fs : '');
This change is necessary because @filemtime expects an absolute path (at least, on Windows). This allows RC to accurately get the file information for the Javascript file being included.
//File: /program/include/rcube_html_page.php
//{in function file_callback}
//changed this if statement:
if (preg_match('/\.(js|css)$/', $file))
$file .= '?s=' . @filemtime($file);
//to this:
if (preg_match('/\.(js|css)$/', $file))
$file .= '?s=' . @filemtime(INSTALL_PATH . $file);
This change basically matches the change above so that the script callbacks match the script(s) included from function include_script.
//File: /program/include/rcube_template.php
//{in function template_exists}
//changed this line:
$filename = $this->config['skin_path'] . '/templates/' . $name . '.html';
//to this:
$filename = INSTALL_PATH . $this->config['skin_path'] . '/templates/' . $name . '.html';
This change allows the code that follows in the function to determine if the actual absolute filename actually exists. (On Windows, the is_file and is_readable function calls return false if fed relative filenames).
//File: /program/include/rcube_template.php
//{in function parse}
//changed this line:
$path = "$skin_path/templates/$name.html";
//to this line:
$path = INSTALL_PATH . "$skin_path/templates/$name.html";
This change by itself basically eliminates the 501 error because the code that follows this statement tries to include the file named here, but on Windows this file can't be read with a relative filename. This change makes the filename absolute.
//File: /program/include/rcube_template.php
//{in function xml_command, under the switch/case for 'include'}
//changed this line:
$path = realpath($this->config['skin_path'].$attrib['file']);
//to this line:
$path = INSTALL_PATH . $this->config['skin_path'].$attrib['file'];
This change allows the following call to is_readable to succeed by examining the absolute filename.
I have no idea what effect, if any, these changes would have on an Apache platform, but it would appear that they would continue to let the program function as expected. I would hope the programmers who are working on this project would consider making sufficient changes to the program to allow it to run on the Windows platform with IIS, as it would only open up this great software to a wider user base.
With the above changes, I can successfully load the skin and login to my hMailserver. I get the rough appearance of the mail window after logging in. However, I still don't see any messages, and navigating to the address book and/or settings screens doesn't cause any information to appear. Obviously, there are some additional changes within the source code that are needed to get everything to function correctly, but I don't know what else to look for. Perhaps someone who is more familiar with the inner workings of RoundCube can point me in the right direction?
By the way, I upgraded to the 0.4 STABLE version of RoundCube today and had the same results as with the 0.4 beta version.
-
I have no idea what effect, if any, these changes would have on an Apache platform, but it would appear that they would continue to let the program function as expected. I would hope the programmers who are working on this project would consider making sufficient changes to the program to allow it to run on the Windows platform with IIS, as it would only open up this great software to a wider user base.
RoundCube does work on Windows and ISS I know several who are running just fine and don't have this problem.
With the above changes, I can successfully load the skin and login to my hMailserver. I get the rough appearance of the mail window after logging in. However, I still don't see any messages, and navigating to the address book and/or settings screens doesn't cause any information to appear. Obviously, there are some additional changes within the source code that are needed to get everything to function correctly, but I don't know what else to look for. Perhaps someone who is more familiar with the inner workings of RoundCube can point me in the right direction?
Is there anything in your error log, and can you enable $rcmail_config['imap_debug'] in /config/main.inc.php
-
Shortly after my previous post, I found the two changes that needed to be made to get everything visible on Windows/IIS:
//File: /index.php
//{near the bottom under the comment: "include task specific functions"}
//changed this line:
if (is_file($incfile = 'program/steps/'.$RCMAIL->task.'/func.inc'))
//to this:
if (is_file($incfile = INSTALL_PATH . 'program/steps/'.$RCMAIL->task.'/func.inc'))
This change allows the correct function file to be included.
//File: /index.php
//{near the bottom under the comment: "include task specific functions"}
//changed this line:
else if (is_file($incfile = 'program/steps/'.$RCMAIL->task.'/'.$stepfile)) {
//to this:
else if (is_file($incfile = INSTALL_PATH . 'program/steps/'.$RCMAIL->task.'/'.$stepfile)) {
This change allows the correct step file to be included.
With these changes, I can see everything I couldn't see before (messages, address options, etc.)
-
RoundCube does work on Windows and ISS I know several who are running just fine and don't have this problem.
I will be the first to admit that I'm a total n00b when it comes to PHP, but I can only tell you what worked for me on a new, clean Windows Server 2008 with a new, clean installation of Roundcube 0.4. I'd guess there are probably others like me who just gave up after seeing the initial failure and seeing that Windows/IIS is not an officially supported platform.
I suppose it's possible that there's a global PHP or RoundCube setting somewhere that could be changed to make my code edits unnecessary, but nobody here has been willing/able to point that out as of yet.
For what it's worth, there are numerous SQL errors in the MS SQL script that creates the initial database as well (I'm using SQL Server 2008 R2 Express Edition) - I also had to fix them by hand, but fortunately, that's a platform I'm fairly familiar with.
-
For what it's worth, there are numerous SQL errors in the MS SQL script that creates the initial database as well (I'm using SQL Server 2008 R2 Express Edition) - I also had to fix them by hand, but fortunately, that's a platform I'm fairly familiar with.
What errors? You should open a ticket in Roundcube's bagtucker.
-
What errors? You should open a ticket in Roundcube's bagtucker.
As the MS SQL script is shipped, it throws a couple of errors related to the TEXTIMAGE_ON clause, which causes some of the tables not to be created. There are also several foreign keys which don't get created because only the column names from one table are specified.
I'll write these up in more detail and submit the corrections to the "bagtucker" as soon as I can get some free time.