Roundcube 0.9 released

Yes, but I just noticed some minutes ago that it didn't give a problem on our CentOS 6.x server. Only on our CentOS 5.x servers it gives the problem.
 
Strange, do you have a difference in php and/or mysql versions you are running on the centos 5 and 6 servers?
Because I got it on both 5 and 6.
 
CentOS 5: PHP 5.3, MySQL 5.1, Apache 2.2 (CustomBuild 1.2.38)
CentOS 6: PHP 5.4, MySQL 5.5, Apache 2.4 (CustomBuild 2.0.0-RC4)
 
I got php 5.3.25 and mysql 5.5.31 on all servers (Centos 5 and 6) combined with mod_ruid2 and Custombuild 1.2.

DA Support has login credentials for one of the servers hope they can find what's going wrong and maybe this will fix you issue too. I informed them in my email reply to them of your issue on the Centos 5 servers. So I'm sure it will get solved.
 
I just checked the custombuild 1.2 and 2.0 and this is normally not the problem.
They all 2 starts in the directory /var/www/html/roundcubemail-0.9.1/config to run the update.sh script
 
Not yet. DA Support has investigated on one of our servers only to discover that some strange things were happening, which shouldn't happen. They said they would think about it.
As far as I understood there could be a solution but when that would be used, people couldn't use "disabled_functions = system" in their php.ini. And normally Roundcube should be able to install/upgrade without using php.
 
To expand on the isssue:

1) The default interpreter for the update.sh is
Code: 
#!/usr/bin/env php
which will use the default php.ini.

2) Since many people do (and should) have "system", in their disable functions, the system() call made in the update.sh will fail.

3) So.. as a workaround, we run this code, to swap out the interpreter to load php with the -n option, so no php.ini is used at all
Code: 
perl -pi -e 's#^\#\!/usr/bin/env php#\#\!/usr/local/bin/php \-n#' ${REALPATH}/bin/update.sh
which should work just fine.. right?

4) In some random cases, we've found that using /usr/local/bin/php -n as the interpreter has some strange effects.
I was able to debug it down to the system call (one of many in the update.sh):
Code: 
   system(INSTALL_PATH . "bin/updatedb.sh --package=roundcube --version=" . $opts['version']      . " --dir=" . INSTALL_PATH . DIRECTORY_SEPARATOR . "SQL", $res);
where the INSTALL_PATH defined variable is not using the correct value.

The kicker is that I added this line immediately before that system call:
Code: 
echo "Install path is INSTALL_PATH\n";
which echo'ed the exact correct path.

BUT.. for whatever reason, once system get's it's hands on it, the variable becomes:
Code: 
[COLOR=#333333]/usr/local/php[/COLOR]
instead of
Code: 
/var/www/html/roundcubemail-0.9.1
inside the system() command and we get the error:
Code: 
sh: /usr/local/php/bin/updatedb.sh: No such file or directory
sh: /usr/local/php/bin/indexcontacts.sh: No such file or directory
Why? That's beyond me. It doesn't make much sense. Could be a php bug, not sure.

5) I went one step further and used this as the interpreter:
Code: 
#!/usr/local/bin/php -c /usr/local/lib/php.ini
which should essentially do the exact same thing as
Code: 
#!/usr/bin/env php
.. but, it doesn't. It throws the same error.
My only guess right now is that something in the environment is playing a major role in the INSTALL_PATH variable.


Any hints are welcome :)


6) The next thing to try would be to see if:
Code: 
#!/usr/bin/env php -n
works.. which might be the proper solution... but I'm still confused why we can call php directly without php deciding it wants to re-label INSTALL_PATH to a wrong value.
EDIT: This does not work.. the extra -n can't be used on a shebang line.


Just as a note, it's defined higher up in the script:
Code: 
define('INSTALL_PATH', realpath(dirname(__FILE__) . '/..') . '/' );
and *does* have the correct path for all tests... until system() runs it, and it's changed within the system call.




For anyone who are playing with this you'd need to edit the "build" script, and in the doroundcube() function comment out the line
Code: 
rm -rf ${ALIASPATH}/installer
so that after you run ./build roundcube, everythinh is left behind, so the update.sh can be run manually.

John
 
Hello,

I've come up with a solution, which doesn't address the php bug (or whatever is going on), but should be a "best guess" method of getting around it, considering the issue seems to be somewhat random (or based on something I don't know.. more likely)

In any case, I've added a check for the ^disable_functions in the /usr/local/bin/php.ini, and to see if system is in that list.
If system is blocked, the shebang line will be swapped out with the /usr/local/bin/php -n option.
If it's not blocked, it will leave it alone, and use the /usr/bin/env php option.

So.. for now, if you have this error:
Code: 
sh: /usr/local/php/bin/updatedb.sh: No such file or directory
sh: /usr/local/php/bin/indexcontacts.sh: No such file or directory
edit your /usr/local/bin/php.ini, and remove system from the disable_functions line.
Then type:
Code: 
./build update
./build roundcube
Note the change only exists on files1.directadmin.com (as of the time of this post).. so please allow up to 24 hours if you're using any other downloadserver as specified in your options.conf.. or just set it to files1.directadmin.com.

Hope this sorts out the issue for most of the few cases out there.

John
 
Just for your information.... it seems the check does not really fix the problem.

I've just tried this with a php.ini which has only this:
Code: 
disable_functions =
So I did a ./build update and after that ./build roundcube and all works fine.

Now we've got another server which has (amongst other things) disable_functions = system.

Did a ./build update and ./build roundcube, and the same error still occurs.
So it seems to me the /usr/local/bin/php -n option will not fix the problem is "system" is in disabled_functions.

So I will remove system from the line as you suggested.
 
Last edited:
I tried to change the disable_functions in /usr/local/lib/php.ini and found it doesn't work.

The workaround resolved only while I made change to /usr/local/etc/php5/cgi/php.ini.

Now my DA server is updated successfully.
 
You are probably running suphp or php in cgi mode and in that case you need to adjust the php.ini you mentioned.
Thank you for pointing us to it.
 
It will not, if you copied customized files to /usr/local/directadmin/custombuild/custom/ap2/conf/extra folder.
 
Richard G said:
On 2 servers there are made custom settings, which are in fact only adding some options to the "disable_functions =" line and changing the date.timezone to date.timezone = "Europe/Amsterdam"
However, on 1 server only has the date.timezone change.
Alle php.ini's have short_open_tag set to On again.
Other changes are only made by custombuild by adding zend and ioncube.

But all of these things are not things which would change path-related things.

Edit: Just tried with a new php.ini (taken the production php.ini from the tar.gz file in custombuild), restarted httpd but same problem.
Click to expand...
ditto said:
I have now tested. It does not work. Also it creates new problems.

I am running cb 2.0 rc4. I changed use_hostname_for_alias=no to be use_hostname_for_alias=yes, then I did ./build rewrite_confs

After that server.hostname.com/phpmyadmin does not work anymore, only server.hostname.com/phpMyAdmin (with capital letter M and A) still work. To fix this I must add back this in /etc/httpd/conf/extra/httpd-alias.conf

Code: 
Alias /roundcube /var/www/html/roundcube/
Alias /phpmyadmin /var/www/html/phpMyAdmin/

I also had to add back the roundcube alias, all the alias was overwritten/deleted.

Next, I would now expect domain.com/phpmyadmin or domain.com/roundcube to redirect to server hostname.com/phpmyadmin and server.hostname.com/roundcube - but it does not redirect, so still it does not work.

It only creates new problems because of the changes to /etc/httpd/conf/extra/httpd-alias.conf

Please fix these bugs.

Edit: Here is some of my settings in options.conf, if it helps replicate the bug (let me know if you need more information about my setup):

Code: 
use_hostname_for_alias=yes
redirect_host=server.hostname.com
redirect_host_https=yes
Click to expand...



We have a lot of servers still running php 5.2. Is there a way to stop receiving the daily emails about roundcube updates from custombuild?
 
Code: 
cd /usr/local/directadmin/custombuild
./build set roundcube no

That's it :)
 
You must log in or register to reply here.
Back
Top